Spis treści

• Testowanie wersji rozwojowych aplikacji
  • Wydania nightly
  • Przy użyciu GNOME Buildera
  • Z ręcznym budowaniem pakietów flatpak
  • Kod spoza głównej gałęzi repozytorium
  • Jak testować?
• Pomaganie innym osobom używającym WiOO i advocacy
• Wsparcie finansowe osób rozwijających FOSS

– –

Testowanie wersji rozwojowych aplikacji

O wyłapywaniu błędów w czasie używania programów i ich zgłaszaniu pisałem w pierwszej części, tym razem opowiem o używaniu niewydanych jeszcze wersji, samodzielnym budowaniu i instalowaniu oprogramowania prosto z repozytorium, po to, by przetestować nowe funkcje i wychwycić błędy jeszcze zanim program zostanie udostępniony zwykłym użytkownikom.

To zagadnienie bardziej zaawansowane, wymagające umiejętności korzystania z trybu tekstowego i instalowania potrzebnych programów i bibliotek. Jeżeli jeszcze nie masz tych umiejętności w swoim repertuarze, to może być właśnie dobra okazja na uzupełnienie braków.

O ile stosunkowo często zdarza mi się zgłaszanie błędów w różnych programach, to za testowanie wersji rozwojowych biorę się tylko w przypadku programów, które naprawdę lubię i rozwijają się na tyle szybko między wydaniami, żeby było warto sprawdzać, co ciekawego się w nich dzieje.

Robiłem tak np. z Tubą (klientem fediwersum), Scratchmarkiem (edytorem Markdown, w którym piszę wszystkie teksty na bloga), a ostatnio z Tonearm, natywnym klientem Tidala.

Wymaga to trochę więcej pracy niż zwykłe używanie i ewentualne zgłaszanie zauważonych błędów, ale jest też bardzo satysfakcjonujące, zwłaszcza jeżeli jest się osobą, którą cieszy zdobywanie nowych umiejętności i lubi dłubać w terminalu.

Wiadomości, którymi się poniżej podzielę, pewnie będą banalne dla bardziej zaawansowanych, ale sam nieraz musiałem się naszukać i nadłubać, zanim załapałem co i jak. Przyznaję, że mimo zebranego doświadczenia i tak zdarza się, że w niektórych przypadkach działam trochę po omacku, co zresztą jest dla mnie sporą częścią frajdy, jaką mam z tej całej zabawy.

– –

Korzystanie z wydań niestabilnych

Zanim zabierzecie się za samodzielne budowanie niewydanych jeszcze wersji programów, sprawdźcie czy czasem osoby tworzące aplikację nie udostępniają wydań niestabilnych, często budowanych codziennie. Jeżeli się nie mylę, to Firefox wprowadził nazwę nightly na takie wydania i od tego czasu widuję ją używaną w innych projektach.

Czasem nie są dostępne w jakimś rzucającym się w oczy miejscu na stronie projektu, tylko trzeba się do nich doklikać. W przypadku Tonearm osoby rozwijające program włączyły automatyczne budowanie pakietów, do których można się dostać po wybraniu interesującej nas zmiany w repozytorium w sekcji Actions.

Takie rozwiązanie bardzo ułatwia życie osób chcących testować aplikacje w czasie ich rozwoju. Niestety, zazwyczaj nie jest dostępne i trzeba radzić sobie samodzielnie.

– –

Budowanie przy pomocy GNOME Builder

W wielu przypadkach, zwłaszcza gdy mowa o aplikacjach tworzonych dla ekosystemu GNOME, najłatwiej będzie do ich budowania i instalacji wykorzystać program GNOME Builder. To zintegrowane środowisko programistyczne (IDE) najprościej zainstalować z Flathuba.

Po odpaleniu Buildera otwiera się okno powitalne, w którym można stworzyć nowy projekt albo otworzyć znajdujący się już na dysku, ale nas interesuje pobranie źródeł programu z jego repozytorium, które umożliwia znajdujący się na dole okna przycisk „Sklonuj repozytorium…”.

Dostępny w tej chwili Builder jest spolszczony w 36%, ale dopiero co skończyłem jego pełne tłumaczenie, które w tej chwili musi zostać przejrzane przez koordynatorkę zespołu przekładającego GNOME na język polski i po poprawkach będzie mogło zostać włączone do następnego wydania.

W następnym oknie wklejacie adres repozytorium i wybieracie, do jakiego folderu mają trafić źródła. Możecie tam też podać swoje dane, na wypadek, gdybyście chcieli zmieniać kod i wysyłać poprawki.

Adres URL repozytorium ma formę https://serwis/autor/projekt.git. Na GitHubie schowany jest pod zielonym przyciskiem „Code”, a na GitLabie pod niebieskim. Po jego kliknięciu zobaczycie adres HTTPS, a obok ikonkę kopiowania go do schowka. Na Codebergu nie trzeba nic rozwijać, można od razu klikać przycisk kopiowania znajdujący się obok pola z adresem.

Po zatwierdzeniu klonowania Builder pobierze źródła z głównej gałęzi programu i otworzy projekt. Dla osób niezaznajomionych z edytorami dla programistów interfejs Buildera może wydawać się nieprzyjazny i skomplikowany. Najważniejsze dla nas rzeczy kryją się na górze w centrum ekranu. Znajdziecie tam ikonkę młotka, która uruchamia budowanie projektu. Na prawo od niej jest strzałka w dół rozwijająca listę działań. Warto rozpocząć od kliknięcia „Update Dependencies…”, co zainstaluje pakiety potrzebne do zbudowania programu.

Gdy ten proces zakończy się sukcesem, można kliknąć młotek lub wybrać „Zbuduj” z menu. W dolnej części ekranu zaczną wyświetlać się proces budowania, który powinien przelecieć bez problemów, o ile w systemie macie wszystkie potrzebne narzędzia. Czasem wywali się z informacją o nieznalezionym poleceniu czy bibliotece, wtedy będzie trzeba użyć narzędzia zarządzania oprogramowaniem waszej dystrybucji i doinstalować potrzebne rzeczy.

Jeżeli wszystko się powiedzie, to na pasku na lewo od młotka wyświetli się napis „Pomyślnie zbudowano”. W tym momencie możecie kliknąć ikonkę trójkąta po prawej, by uruchomić program, co zazwyczaj wystarcza do testowania. Można też stworzyć pakiet flatpak, wybierając „Export” z menu.

– –

Ręczne budowanie

Niektóre programy nie dawały mi się zbudować w powyższy sposób, całkiem możliwe, że przez mój brak umiejętności i wiedzy do tego potrzebnej. W takich wypadkach załatwiam to ręcznie.

Jeżeli nie macie kopii repozytorium utworzonej w Builderze, można to zrobić bez niego. Otwieramy terminal w katalogu, w którym ma znaleźć się kod źródłowy i używamy polecenia git clone. Na przykład w przypadku Tonearm to

git clone https://codeberg.org/dergs/Tonearm.git

Następny krok to sprawdzenie na stronie projektu, czy są tam zamieszczone instrukcje budowania/instalacji. Niekiedy znajdziecie tam dokładne polecenie i wystarczy je skopiować do terminala, by zbudować program, oczywiście, jeżeli macie zainstalowane wszystkie zależności.

Niektóre programy mają skrypty zajmujące się budowaniem i instalowaniem. Na przykład w katalogu build-aux źródeł Scratchmark znajduje się skrypt generate_flatpak.sh, którego wywołanie buduje pakiet Scratchmark.flatpak, który można potem zainstalować poleceniem

flatpak install Scratchmark.flatpak --user

Opcja --user powoduje zainstalowanie pakietu wyłącznie dla aktywnego użytkownika. Dzięki temu jeżeli dzielimy komputer z innymi osobami, nie będą widziały w swoim menu potencjalnie niestabilnej wersji aplikacji.

Czasem jednak instrukcji nie ma i trzeba sobie radzić bez nich. Tak było właśnie w przypadku Tonearm, gdy zaczynałem kręcić się przy tej aplikacji. Na szczęście po wcześniejszych doświadczeniach wiedziałem, co zrobić. Rozejrzałem się za zawierającym manifest budowania plikiem .json lub .yaml, który znalazłem w build/flatpak, a potem wydałem polecenie

flatpak-builder --force-clean --install-deps-from=flathub --user --install build dev.dergs.Tonearm.yaml

Dodanie --install-deps-from=flathub spowoduje, że brakujące zależności zostaną dociągnięte z repozytorium flathuba, a --force-clean usunie pliki wygenerowane w czasie poprzedniego budowania.

Jeżeli proces budowania i instalowania przebiegnie bez błędów, można się zabrać za testowanie.

– –

Kod spoza głównej gałęzi repozytorium

Zazwyczaj opisane powyżej sposoby instalacji programów ze źródeł pobranych z repozytorium wystarczają do testowania wersji rozwojowej. Czasem jednak rozwój nowych funkcjonalności odbywa się poza główną gałęzią repo (najczęściej nazywającą się main lub master) i kod ją zawierający trafia do niej dopiero po doszlifowaniu.

Niektóre projekty mają stałą gałąź w rodzaju dev lub devel, w większości przypadków gałęzie powstają na potrzeby konkretnych zmian i mają zazwyczaj dość oczywiste nazwy, np. feat/nowy-edytor albo fix/wycieki-pamieci. Żeby przetestować taką wersję programu, trzeba przełączyć źródła na wybraną gałąź.

W Builderze po lewej stronie pola, w którym były wyświetlane komunikaty budowania aplikacji, znajduje się kolumna ikonek. Druga od góry przełącza na terminal, w którym wpisujemy polecenie git switch. Po naciśnięciu klawisza TAB pokaże się lista dostępnych gałęzi, na której odszukujemy tą, która nas interesuje i dopisujemy do polecenia

git switch feat/nowy-edytor

Przy ręcznym budowaniu po prostu używamy tego samego polecenia w terminalu, po wejściu do katalogu ze źródłami.

Po przełączeniu na wybraną gałąź dalsze budowanie jest takie samo, jak opisałem powyżej.

Jeżeli od sklonowania repozytorium do chwili budowania programu minęło trochę czasu, można je zaktualizować, pobierając zmienione pliki poleceniem git pull wydanym w główny katalogu repo, a ponowne przestawienie repozytorium z bocznej gałęzi na główną załatwiamy oczywiście poleceniem git switch main.

– –

Jak testować?

Niezależnie od tego, w jaki sposób zainstalowaliście testową wersje programu, testowanie wygląda tak samo. Najprostsza opcją jest po prostu używanie programu jak zazwyczaj, z jednoczesnym zwracaniem uwagi na zamykanie się aplikacji, skoki zajęcia pamięci, zamulenie, niedziałające elementy. Po natrafieniu na takie problemy zgłaszamy je w sekcji Issues strony programu, co opisałem już w poprzedniej części. Pamiętajcie o wcześniejszym upewnieniu się, że problem jeszcze nie został zgłoszony.

Bardziej zaawansowaną opcją jest sprawdzenie, co się zmieniło od ostatniego wydania i testowanie rzeczy z tej listy. Żeby to zrobić trzeba wejść na zakładkę Wydania (Relases) na stronie projektu i wybrać najnowsze, a po jego otwarciu poszukać odnośnika w rodzaju „15 commits to master since this release”, który otworzy stronę zawierające listę wszystkich zmian, które zaszły w repozytorium od tego czasu.

Lista, którą zobaczycie, może w pierwszej chwili może wydawać się nieczytelna i przytłaczająca, zwłaszcza jeżeli w repozytorium sporo się wydarzyło od czasu ostatniego wydania. Na szczęście da się to dość łatwo ogarnąć, o ile osoby rozwijające program dbają o sensowne opisywanie zmian.

Zazwyczaj można zignorować aktualizacje tłumaczeń oraz zmiany oznaczane jako chore, które z reguły dotyczą np. aktualizacji zależności i podobnych zabiegów związanych z utrzymaniem kodu. Te, które nas interesują, często są mają oznaczenia fix dla zmian łatających błędy oraz feat dla dodających nowe funkcjonalności lub zmieniających działanie dotychczasowych.

Testowanie pierwszych jest bardziej oczywiste, zwłaszcza jeżeli dotyczy błędów, które zgłaszaliśmy. Odtwarzamy okoliczności, w których błąd występował i sprawdzamy, czy nadal tak się dzieje. Jeżeli jest już naprawiony, warto w komentarzu pod konkretną zmianą napisać, że poprawka zadziałała. Jeżeli błąd pojawia się nadal, tym bardziej warto dać o tym znać.

Te drugie pewnie są najbardziej atrakcyjne – ja sam mam wielką frajdę, gdy mogę używać rzeczy, które są jeszcze niedostępne dla osób korzystających tylko ze stabilnych wydań i często robię to jako pierwsza osoba po bezpośrednio zaangażowanych w rozwój programu. Poza sprawdzeniem, czy dodany/zmieniony element aplikacji działa tak, jak powinna, warto spojrzeć na to, jak łączy się z jej resztą i czy np. nie psuje używalności, albo jeżeli się sprawdza, czy nie pasowałby też w innych miejscach.

Przykład 1: Niedawno do Scratchmark doszła możliwość zmiany rozmiaru tekstu w edytorze za pomocą skrótów Ctrl+ i Ctrl-. Osoba rozwijająca Scratchmarka uznała, że skoro można ustawić rozmiar czcionki w ten sposób, to może usunąć ustawianie rozmiaru w preferencjach. Zgłosiłem w pokoju Matrix aplikacji, że IMHO to nie jest najlepszy pomysł, bo skoro możemy tam zmienić krój czcionki, to dziwne będzie, jeżeli nie będziemy mogli zmienić tam również jej rozmiaru. Za to jak najbardziej powinna się tam znaleźć informacja, że wielkość tekstu można zmienić też w czasie pisania za pomocą skrótów klawiszowych.

Przykład 2: Zaproponowałem dodanie do Tonearm podglądu okładek albumów, co dość szybko zostało zrealizowane. Gdy przetestowałem wersję z tą zmianą odkryłem, że działa to wyłącznie po kliknięciu z okładkę obecnie odtwarzanego utworu, która i tak jest dość powiększona w panelu odtwarzacza, za to nie działa z okładkami na stronach albumów, jeżeli ich nie odtwarzamy, a tam przydałoby się bardziej, bo okładki są dużo mniejsze, więc słabiej widoczne. W tym przypadku również zasugerowałem zmianę na Matriksie.

Matrix jest sposobem komunikacji popularnym w świecie FOSS. To taki Discord dla geeków – otwarty i niezależny od korporacji. Mniej wybajerzony, ale IMHO bardziej wygodny. Gorąco zachęcam do korzystania z niego, bo jest dobrym sposobem na bezpośrednią komunikację z osobami rozwijającymi WiOO, mniej formalną niż wypełnianie issues na stronach projektów. Jeżeli zdecydujecie się spróbować, to polecam polski serwer noevil, na którym mam swoje konto oraz klienta o nazwie Fractal.

– –

Pomaganie innym osobom używającym WiOO i advocacy

Jeżeli propozycje, które przedstawiłem w poprzedniej części i powyżej to dla was za dużo zachodu, to teraz pokażę działalność, która w przeciwieństwie do powyższych nie wymaga dłubania, a jedynie chwili wolnego czasu.

Sporą częścią całego środowiska WiOO jest wzajemne pomaganie. Kiedyś było to dużo łatwiejsze, po prostu siedzieliśmy na usenetowej grupie (alt.pc.comp.os.linux.newbie na zawsze w moim sercu, jeżeli ktoś z a.p.c.o.l.n. to czyta, to pozdrawiam serdecznie) i w miarę możliwości odpowiadaliśmy na pytania, które się na niej pojawiały. Polecaliśmy programy, kompatybilny sprzęt, podpowiadaliśmy sposoby rozwiązywania problemów, dzieliliśmy się sztuczkami, skryptami, pisaliśmy FAQ itd.

Usenet niestety odszedł w niepamięć, ustępując pola forom dyskusyjnym, które z kolei prawie wyginęły po nastaniu czasu mediów społecznościowych i discordów, przetrwały chyba głównie w formie poświęconej konkretnym dystrybucjom, np. Arch, Debian, Fedora, Mint, openSUSE, Ubuntu. To bardzo dobre miejsca, aby pomóc osobom zaczynającym przygodę z Linuksem i szukających rozwiązania jakiegoś problemu. Jeżeli tylko macie wiedzę, którą możecie się podzielić, to z pewnością znajdziecie tam osoby, którym się ona przyda.

Jeżeli nie macie ochoty zaglądać na fora, to zostają jeszcze media społecznościowe. Co prawda na takim Facebooku czy Twitterze raczej nie będzie okazji do zaangażowania się w taką działalność (no chyba, że są jakieś grupy okołoFOSSowe na fb), ale w fediwersum to dość popularny temat, więc na pewno trafi się okazja polecić jakiś program, podpowiedzieć rozwiązanie problemu, a może nawet zagadać bezpośrednio do osób rozwijających WiOO. Fedi zresztą jest świetne jako sposób do trzymania palca na pulsie świata FOSS, sam śledzę w ten sposób np. dystrybucje Linuksa, klienty Mastodona i innych platform oraz garść innych programów WiOO.

Poza pomaganiem przy rozwiązywaniu problemów, można w takich miejscach zająć się głoszeniem dobrej nowiny o FOSS, czyli tak zwanym advocacy. Można np. pokazywać zalety używania Linuksa zamiast zamkniętych systemów operacyjnych czy polecać ciekawe aplikacje WiOO, na które natrafiliście. Warto to robić nienachalnie i bez pogardy dla innych systemów. Na a.p.c.o.l.n. mieliśmy zasadę, że skoro nie chcemy, żeby ktoś pisał o „Linuchu”, to my nie mówimy o „Winshicie” itd. (obecnie zrobiłbym wyjątek od tej zasady dla „Microslopu”, jego użycie jest jak najbardziej uzasadnione, podobnie jak deadname’owanie Twittera).

Pamiętajcie przy tym, że odwieczna tradycja flejmów (flame wars) o wyższość jednej dystrybucji nad drugą, jak bardzo rozrywkowa by nie była, raczej nie przysłuży się celowi. Lepiej zamiast tego pokazać np. jak można wykorzystać Linuksa do grania (dzięki Steamowi i Protonowi) czy przedłużenia życia starszego sprzętu, niewspieranego już przez Windows.

Masa aplikacji FOSS jest pisana także na inne systemy, więc można polecać je bez namawiania do przesiadki na Linuksa.

– –

Wsparcie finansowe osób tworzących WiOO

Sporym problemem wśród osób rozwijających WiOO jest zmęczenie, a nawet wypalenie. Więcej o tym możecie przeczytać np. w artykule w serwisie „It’s FOSS”, opartym na badaniu Mirandy Heath z The University of Edinburgh, tu pozwolę sobie nawiązać tylko do jednego fragmentu.

Raport zawiera sześć czynników, które powodują stan wypalenia u osób rozwijających FOSS i ich odchodzenie od rozwijanych projektów. W skrócie to stres związany z przytłaczającym obciążeniem, poczuciem odpowiedzialności i potrzebą udowadniania własnej wartości. Osoby utrzymujące popularne oprogramowanie są zasypywane zgłoszeniami, a że często pracują solo, nie są w stanie sobie z tym poradzić. Jednocześnie czują zobowiązanie do dalszej pracy, bo porzucenie projektu byłoby jak zdrada.

Do tego dochodzi często toksyczne zachowanie społeczności: bezrefleksyjne wymaganie nowych funkcjonalności, bez zastanowienia się, czy osoba tworząca projekt ma czas i możliwości na ich realizację oraz bezwzględne krytykowanie wszelkich wpadek, podczas gdy dobra praca jest niedoceniania.

Kolejną kwestią jest fakt, że utrzymywanie istniejącego projektu jest mniej wynagradzające od tworzenia: programowanie nowej aplikacji czy biblioteki jest źródłem frajdy, ale utrzymywanie ich, naprawa błędów, aktualizacja zależności itp. to po prostu uciążliwa, powtarzalna praca.

Ostatnim czynnikiem są kwestie finansowe. Według raportu 60% osób utrzymujących przy życiu WiOO nie otrzymuje za to żadnego wynagrodzenia. Muszą najpierw wykonywać swoją pracę zarobkową, a po niej często odrabiają kolejny etat pracując przy jakimś projekcie FOSS, poświęcając swój czas przeznaczony na życie prywatne, rodzinę i przyjaciół.

Wszyscy lubimy fajne programy WiOO, chcemy by były dobrze zaprojektowane i działające, regularnie aktualizowane i naprawiane. Ale tak przywykliśmy do tego, że są dostępne za darmo, że rzadko myślimy, że ktoś płaci za ich rozwój swoim czasem. Nie jestem w stanie załatwić tym osobom etatów polegających na pracy nad FOSS, dlatego staram się co jakiś czas, w miarę możliwości, wesprzeć jakiś projekt, np. z okazji kolejnego wydania. To samo z osobami lub organizacjami utrzymującymi ważną infrastrukturę np. serwer Matriksa. Moje parę złotych dużo nie zmienia, ale jeżeli takich wpłat zbierze się więcej, mogą naprawdę pomóc. Jeżeli tylko możecie, to gorąco zachęcam, nawet jeżeli będzie to tylko równoważność jednej kawy czy innego napoju.

Jeżeli się na to zdecydujecie, to najlepszym sposobem będzie poszukanie na stronie ulubionego oprogramowania odnośników do serwisów w rodzaju Ko-Fi czy Liberapay, często wykorzystywanych jako metody na przekazywanie finansowego wsparcia.

– –

To koniec drugiej części, trzecia powinna pojawić się wkrótce. Tymczasem zapraszam do rozmowy – jeżeli macie jakieś pytania dotyczące poruszonych zagadnień lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a może nawet są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie.

• Czym jest WiOO?
• Po co?
• Moje początki
• O wpisie
• Programowanie
• Dokumentacja
• Grafika
• Zgłaszanie błędów
• Pomysły na nowe funkcjonalności

Czym jest WiOO?

Skrót WiOO oznacza Wolne i Otwarte Oprogramowanie i jest polskim odpowiednikiem angielskiego FOSS (Free and Open-Source Software).

Wolne oprogramowanie to takie, „które może być uruchamiane, kopiowane, rozpowszechniane, analizowane oraz zmieniane i poprawiane przez użytkowników, oraz dające użytkownikom wolność do dzielenia się tym oprogramowaniem bez ograniczeń prawa autorskiego” (za Wikipedią).

Żeby spełniać warunki do uznania za wolne, oprogramowanie musi zapewniać użytkownikowi cztery wolności:

• Wolność do uruchamiania programu jak chcecie, w dowolnym celu (wolność 0).
• Wolność do analizowania, jak działa program i zmieniania go, aby robił co i jak potrzebujecie (wolność 1). Warunkiem koniecznym jest dostęp do kodu źródłowego.
• Wolność do rozpowszechniania kopii, byście mogli pomóc innym (wolność 2).
• Wolność do udoskonalania programu i publicznego rozpowszechniania własnych ulepszeń, dzięki czemu może z nich skorzystać cała społeczność (wolność 3). Warunkiem koniecznym jest tu dostęp do kodu źródłowego.

(Lista pochodzi ze strony gnu.org).

Otwarte oprogramowanie to z kolei takie, „w którym kod źródłowy jest wydawany na podstawie licencji, na mocy której właściciel praw autorskich przyznaje użytkownikom prawa do badania, zmiany i rozpowszechniania oprogramowania w ramach licencji wolnego oprogramowania” (cytat z Wikipedii).

Pierwszy termin dotyczy bardziej ideowego podejścia, a drugi bardziej technicznego. Praktycznie każdy program spełniający wymogi bycia wolnym oprogramowaniem będzie też otwarty, ale nie zawsze działa to w drugą stronę.

Przykłady znanego oprogramowania, które jest w ten sposób rozwijane:

• Edytor grafiki Gimp,
• Pakiet biurowy LibreOffice,
• Program do grafiki i animacji 3D Blender,
• Odtwarzacz wideo VLC,
• Edytor plików audio Audacity.

Przyznaję, że sam używam tych terminów zamiennie, bez przywiązywania uwagi do różnic, lub sięgam po skrót FOSS. W oczach osób z Free Software Foundation i okolic to pewnie myślozbrodnia, ale się tym nie przejmuję.

Niezależnie od terminu, będę w tym wpisie opowiadał o ruchu, czy może raczej środowisku osób wspólnie tworzących oprogramowanie, którego każdy może używać i modyfikować. Głównym celem, który mi przyświeca jest zachęcenie jak największej liczby osób do włączenia się, dlatego spróbuję pokazać, jak można to zrobić, niezależnie od posiadanych umiejętności.

– –

Po co?

Z wielu powodów. Dla kogoś może to być okazja na zyskanie nowych umiejętności i doświadczeń, czy to dla siebie, czy jako czegoś, co można wpisać do CV. Nie chodzi tu tylko o same techniczne umiejętności, jak obsługa repozytorium z oprogramowaniem, ale też np. pracę w zespole.

Dla innych to szansa na poznanie nowych osób, o podobnych zainteresowaniach, zwłaszcza jeżeli trudno im znaleźć kogoś takiego w swoim otoczeniu.

Czasem zaletą może być zwykła chęć tworzenia wspólnego dobra albo satysfakcja którą czujesz, gdy widzisz, że ludzie używają aplikacji, do której powstania się przyczyniasz.

Motywacją może być ochota pokazania, że w zgównowaconym świecie zalewanym AI-slopem przez korporacje Big Tech, nadal jest miejsce na ludzi tworzących razem coś fajnego.

Jeżeli napędza cię coś jeszcze innego, daj znać w komentarzu.

– –

Moje początki

Sam zostałem fanem tej idei około 25 lat temu, gdy w czasie pierwszych podejść do Linuksa (wtedy był to Slackware albo Red Hat), postanowiłem zainstalować port Quake’a, o którym przeczytałem w jakimś magazynie (pewnie „Chip Special Linux” lub „Linux+”). Gra była chyba na płycie dołączonej do magazynu, bo nie sądzę, żebym ją ściągał na dial-upie, zamieszczona w postaci kodu źródłowego i żeby pograć, musiałem ją skompilować.

Zupełnie nie miałem pojęcia, co robię i po prostu przepisywałem polecenia literka po literce (klasyczne ./configure, make, make install), ale nie rozumiałem, co się wyświetla w ich wyniku. A że zwracały jakieś błędy, to gra się nie budowała.

W pliku README znalazłem adres e-mail autora i bez większego przekonania, że to coś da, postanowiłem wysłać do niego pytanie. Ku mojemu zdziwieniu nie tylko odpisał, ale i krok po kroku przeprowadził mnie przez cały proces instalowania zależności, kompilacji i instalacji.

Już nie pamiętam, jak się grało w tamten port Quake’a, ale na zawsze zostało ze mną wrażenie, jakie zrobił na mnie fakt, że komuś nie tylko chciało się stworzyć jakieś oprogramowanie i udostępnić je za darmo, ale też potem całkowitemu newbie z drugiego końca świata cierpliwie wyjaśniać, jak go używać.

Od tamtego momentu chciałem zostać częścią tego świata i myślę, że jakoś mi się to udaje, a tym przydługim tekstem chcę zaprosić was do dołączenia.

– –

O wpisie

Wpis składa się z rozdziałów poświęconych różnym sposobom angażowania się w WiOO. Jeżeli po przeczytaniu tytułu lub kilku pierwszych zdań któregoś z nich dojdziesz do wniosku, że nie ten aspekt cię nie interesuje, zapraszam do przeskoczenia do następnego rozdziału, może w nim uda mi się podsunąć coś, co bardziej ci się spodoba.

Gdy w czasie pisania przekroczyłem granicę 3 tysięcy słów, a końca nie było widać, postanowiłem podzielić wpis na części, żeby łatwiej się go czytało.

Pierwsza z nich zawiera informacje o wejściu w WiOO jako osoba programująca, tworząca dokumentację lub grafikę, zgłaszająca błędy i podsuwająca pomysły na nowe funkcjonalności. Drugą poświęciłem testowaniu aplikacji w czasie ich powstawaniu, pomaganiu innym osobom używającym otwartego oprogramowania oraz wspieraniu osób rozwijających FOSS, a trzecia opowiada o tłumaczeniu aplikacji.

Cytaty, które zobaczycie poniżej dostałem na Fediwersum po zapytaniu o porady dla osób wchodzących w świat FOSS. Bardzo dziękuję i pozdrawiam wszystkie osoby, które odpowiedziały na tamto pytanie.

I jeszcze uwaga techniczna: o ile ogólna tematyka jak najbardziej może dotyczyć różnych systemów operacyjnych, to ze względu na to, że od lat używam wyłącznie Linuksa (w tej chwili openSUSE Tumbleweed), konkretne przykłady programów i poleceń będą pochodziły z tego środowiska. Przy budowaniu i instalowaniu pakietów z programami używam flatpaka, jako że jest niezależny od dystrybucji i praca z nim wszędzie wygląda tak samo.

Dosyć już tych wstępów, pora na właściwą część tekstu.

– –

Programowanie

Najłatwiej oczywiście mają osoby potrafiące programować, bo mogą po prostu swoją aplikację udostępnić na którejś z otwartych licencji. Najpopularniejsze z nich to GNU General Public Licence (GPL), MIT oraz BSD. Więcej o nich możecie poczytać np. na stronie Open Source Initiative. Różnice między nimi w prosty sposób pokazuje strona Open Licence Helper, na której znajduje się też wizard, w którym można wyklikać najbardziej pasującą licencję, po odpowiedzeniu na kilka pytań.

Jeżeli nie macie pomysłu na własny program lub szukacie czegoś prostszego, niż tworzenie całej aplikacji, to może zainteresować was pisanie poprawek lub dodawanie funkcjonalności do istniejących już aplikacji. Najlepiej w takim przypadku wybrać program, którego używacie regularnie i dobrze go znacie. I zacząć od czegoś niewielkiego, a nie porywać się na rzeczy zmieniające pół aplikacji.

– –

Osobom mającym doświadczenie z programowaniem, raczej nie muszę tłumaczyć jak działają serwisy z repozytoriami kodu w rodzaju Codeberga czy GitHuba.

Jeżeli jednak tak nie jest, to warto się zapoznać z tematem, bo znajomość obsługi repozytoriów git jest absolutnie kluczowa i bez niej będzie ci trudno. Nie wyobrażam sobie zabierania się za współpracę w jakimś projekcie bez umiejętności stworzenia forka, pracy na swoim repozytorium, zapisywania zmian w nim i tworzenia pull request, w celu scalenia twojego kodu z oryginalną aplikacją. Sama umiejętność kodowania nie wystarczy, jeżeli nie potrafisz obsłużyć repo.

– –

Niezależnie od tego, czy masz doświadczenie w komercyjnym tworzeniu oprogramowania w zespołach, czy nie, musisz pamiętać o bardzo ważnej rzeczy – osoby tworzące FOSS robią to zazwyczaj w swoim wolnym czasie, godząc to z pracą i życiem osobistym. Jeżeli będziesz natarczywie domagać się natychmiastowej reakcji np. na swoją łatkę, to może się to po prostu skończyć jej odrzuceniem, a może nawet zablokowaniem cię.

To samo dotyczy osób wchodzących w istniejące projekty „z buta”, domagając się np. zmiany konwencji zapisu kodu, filozofii działania programu, korzystania z innej biblioteki albo przepisania na inny język (a widziałem kilka takich zagrywek ze strony fanów Rust), czy po prostu zachowujących się jak buc.

Zanim zabierzesz się za pisanie kodu, sprawdź najpierw, czy w repo aplikacji nie ma informacji dla osób chcących przy niej współpracować, na przykład w pliku CONTRIBUTING.md. Warto też rozejrzeć się za czymś w rodzaju „Code of Conduct”, który często znajduje się w repozytoriach projektów związanych z GNOME. To dokument zawierający standardy i wytyczne dla społeczności, łącznie z przykładami niewłaściwych zachowań, które nie są tolerowane w GNOME.

Szanujmy się wszyscy, bez tego nie ma mowy o owocnej współpracy. W FOSS wchodzi się, by współtworzyć, nie narzucać swoją jedynie słuszną wizję.

Jeszcze jedno: nawet jeżeli zachowamy się odpowiednio, nie ma gwarancji, że osoby zarządzające danym projektem przyjmą nasze zmiany. Przeszkodą może być coś niedużego i zostaniemy poproszeni o jakieś poprawki, a po ich wprowadzeniu łatka zostanie przyjęta. Może się jednak zdarzyć, że nie pasuje do konkretnej wizji projektu, planu jego rozwijania, sposobu działania programu itp.

Paweł Gronowski radzi:

Czasem może się zdarzyć, że Twój PR działa, ale nie możemy go przyjąć z różnych względów – np. jest to brzydki hack albo nie pasuje do długoterminowej wizji projektu.
Zanim spędzisz czas, pracując nad implementacją bardzo dużej funkcjonalności, warto najpierw przedyskutować czy jest to dobre rozwiązanie i czy zostanie ono przyjęte.

Jeżeli bardzo będzie zależało wam na konkretnych zmianach, można taki program sforkować, czyli zrobić swoją wersję, bazując kodzie oryginału, a potem regularnie brać zaktualizowany kod macierzystego programu i nakładać łatki dopasowujące go do własnej wizji.

– –

Dokumentacja

Wśród rad dla początkujących, jakie dostałem na fedi od osób już działających w takich projektach powtarzała się jedna, o której sam nie pomyślałem. Poza pisaniem kodu, bardzo ważne jest tworzenie dokumentacji:

Paweł Gronowski:

Kontrybucja dokumentacji jest często cenniejsza od kodu, a przede wszystkim łatwiejsza do oceny dla opiekuna niż kodu.

Marcin Juszkiewicz:

Wybrać coś, czego używają. […] Gdzie wiedzą czego brakuje w dokumentacji i chcą to dodać. Pisanie kodu to nie jest umiejętność, którą trzeba posiadać, by pomóc w projektach FOSS.

dopelover:

No i jest jeszcze kwestia tworzenia, nazwijmy to nieprogramistycznych zasobów, oczywiście zależnych od rodzaju projektu np. szablony dokumentów, dokumentacja dla użytkowników, tutoriale, wiki itp. itd.

Sam się tym nigdy nie zajmowałem, ale rzeczywiście tworzenie dokumentacji wygląda na całkiem dobry sposób na wejście w jakiś projekt i poznanie sposobu jego działania.

Oczywiście, zanim się za to zabierzecie, warto porozmawiać na ten temat z osobami tworzącymi oprogramowanie i zapoznać się z tym jak wygląda dotychczasowa dokumentacja, żeby zachować spójność.

– –

Grafika

Nie macie ochoty grzebać się w kodzie, ale macie za to artystyczne zacięcie? Świetnie się składa, każda aplikacja potrzebuje ikony, część także ilustracji, a gry całej masy rozmaitej grafiki.

Jeżeli natraficie na nowy projekt, który używa tymczasowej ikony i moglibyście zaproponować coś bardziej dopracowanego – śmiało zgłaszajcie się z propozycją. Może uważacie, że obecną ikonę jakiegoś programu można by poprawić, podnosząc np. jej czytelność? w takim wypadku skontaktujcie się z kimś z osób tworzących aplikację i przedstawcie swoją sugestię.

Warto się przed tym zapoznać z wytycznymi dotyczącymi ikon i kolorów aplikacji z serwisu Flathub, który jest najpopularniejszym źródłem oprogramowania w pakietach flatpak. A jeżeli program, który chcecie wspomóc swoją grafiką, jest przeznaczony głównie dla środowiska GNOME, lekturą obowiązkową będzie odpowiednia sekcja GNOME Human Interface Guidelines, która zawiera porady dotyczące rozmiarów, kształtu, wykorzystania perspektywy i szegółowości ikon.

– –

Zgłaszanie błędów

Tak samo, jak oprogramowanie produkowane przez korporacje, tak i aplikacje tworzone przez społeczność WiOO nie są wolne od błędów. Te pierwsze jednak mogą zatrudnić testerów, drugie polegają na zgłoszeniach od użytkowników.

Jeżeli traficie na błąd, zwłaszcza jeżeli to coś dużego, jak np. wywalanie się aplikacji, dobrze zgłosić go osobom tworzącym projekt. Czasem wydaje się, że problem jest tak dokuczliwy, że na pewno ktoś już go zgłosił i nie ma co się tym przejmować. Warto jednak sprawdzić, czy rzeczywiście jest już zgłoszenie, bo być może wszyscy pomyśleli podobnie i nie zgłosił nikt.

Żeby ustalić, jak to zrobić, najprościej zajrzeć do okna informacji o programie, które w aplikacjach dla ekosystemu GNOME jest zazwyczaj ostatnią pozycją w menu głównym. Poza informacją o osobach rozwiajającyn program, powinna tam się znaleźć opcja „Zgłaszanie błędów”, której kliknięcie otworzy w przeglądarce stronę zgłoszeń (issues) w repozytorium projektu, na którymś z serwisów w rodzaju Codeberga, GitHuba czy Gitlaba.

Niestety, wszystkie z nich wymagają założenia konta przed wysłaniem zgłoszenia, ale warto to zrobić, bo jeżeli się wciągniecie w taką działalność, to przyda się wam niejednokrotnie. Poza raportowaniem konto pozwala też m.in. na otrzymanie informacje o reakcji i ewentualnym rozwiązaniu problemu oraz śledzenie projektów, by np. dowiedzieć się o nowym wydaniu jeszcze zanim paczka z nim pojawi się w repozytorium twojej dystrybucji lub na Flathubie.

Zanim zabierzesz się za raportowanie błędu, sprawdź listę zgłoszeń, czy ktoś już czasem tego nie zrobił. Może nawet jest już pod nim informacja o rozwiązaniu i tym, czy pojawi się ono w nadchodzącym wydaniu.

– –

Samo zgłaszanie jest dość proste i polega na wypełnieniu kilku pól formularza. Sporo projektów ma je dopasowane do własnych potrzeb, tak by raport dawał jak najwięcej pomocnych informacji.

W przypadku androidowego klienta Mastodona o nazwie Pachli wszystko zawarte jest w jednym polu: opis błędu, sposób odtworzenia go, co się powinno dziać zamiast błędu oraz zrzuty lub nagrania demonstrujące wystąpienie błędu i wersja aplikacji, w której występuje.

Z kolei Tuba (też klient fediwersum, tyle że dla Linuksa) ma to rozbite na osobne pola, z dodatkowym miejscem na rodzaj platformy, z której korzystamy z Tubą, system operacyjny i sposób instalacji samego programu.

Ciekawe pole, którego nie widziałem w innych formularzach, ma Tonearm, klient Tidala, którego niedawno polecałem na blogu. Przy zgłaszaniu błędu możemy wybrać, jak duży ma wpływ na używalność programu (Impact on usability).

Jednym z najważniejszych elementów zgłoszenia są Steps to reproduce czy kroki prowadzące do wystąpienia błędu. Czasem jest to dość oczywiste: „kliknij to, to i gotowe”, ale nie zawsze jest to takie proste i problem wydaje się losowy. Warto jednak się przyjrzeć dokładniej i sprawdzić, czy są jakieś powtarzające się okoliczności, np. Tuba wywalała się przy odpowiadaniu na wpis zawierający czyjąś nazwę użytkownika, a Tonearm pada po otworzeniu elementu z wyników wyszukiwania i późniejszym powrocie do nich.

Przydatne są również troubleshooting information, czyli informacje debuggowania. O ile program je udostępnia, to znajdziecie je w oknie „O programie” i zawierają informacje o środowisku, w jakim działa aplikacja. Wystarczy je skopiować i wkleić w odpowiednie pole formularza zgłaszania błędów.

– –

W większości przypadków wypełnienie takiego formularza powinno wystarczyć do udanego zgłoszenia błędu. Czasem jednak może się okazać, że będą potrzebne dodatkowe informacje i osoba tworząca aplikację zapyta np. o to, jakie opcje mamy włączone i poprosi o przetestowanie po ich wyłączeniu. Bywa, że przydają się dodatkowe informacje, które program wyświetla po uruchomieniu w emulatorze terminala, takim jak Konsola albo Terminal GNOME.

W przypadku Tuby zainstalowanej z Flathuba robi się to wpisując polecenie flatpak run dev.geopjr.Tuba.

Ciąg dev.geopjr.Tuba jest identyfikatorem pakietu flatpak, który można znaleźć np. na stronie programu na Flathubie lub wyszukując go w wyniku polecenia flatpak list, które wypisuje wszystkie zainstalowane pakiety (`flatpak list | grep Tuba“ wyświetli wyłącznie linie zawierające słowo Tuba).

Po uruchomieniu programu w ten sposób doprowadzamy do wystąpienia błędu i wysyłamy osobie rozwijającego apkę to, co pojawiło się w terminalu.

Okno emulatora terminala z komunikatami z uruchomionej Tuby.

Bywa, że zwykłe komunikaty z terminala to za mało i przydałoby się uruchomić program w sposób dający więcej informacji, np. tak: G_MESSAGES_DEBUG=Tuba flatpak run dev.geopjr.Tuba

Na początek nie ma co się tym przejmować. Jeżeli osoba rozwijająca program poprosi nas o dodatkowe informacje, a my nie będziemy wiedzieli, jak je uzyskać, to wystarczy zapytać. Nie ma w tym żadnego wstydu, każdy ma prawo czegoś nie wiedzieć, a w interesie twórców oprogramowania jest pomoc w dostarczeniu potrzebnych danych.

Wiem, że to wszystko może wydawać się dużą ilością informacji dla kogoś, kto chce tylko spokojnie używać jakiegoś programu. Ostatecznie jednak zgłaszanie błędów pomaga zarówno osobom tworzącym, jak i używającym programów. I zazwyczaj naprawdę jest proste i rzadko wymaga większego dłubania, o którym (może niepotrzebnie) wspomniałem wyżej.

– –

Pomysły na nowe funkcjonalności

Raportowanie błędów to nie jedyne, do czego można wykorzystać sekcję „Issues” w repozytoriach programów. Inną możliwością jest zgłaszanie zapotrzebowania na nowe funkcje, czyli feature requests, po sprawdzeniu, czy już nie zostały zgłoszone.

Edytor Markdown nie ma możliwości ustawienia używanej czcionki? Klient fediwersum nie wspiera sprawdzania pisowni przy edycji alt tekstu? Odtwarzacz nie pokazuje, która piosenka na liście jest aktualnie grana? Nie ma problemu – jeżeli brakująca funkcjonalność ma sens, pasuje do wizji osoby tworzącej program i jest możliwa do zaimplementowania, to jest spora szansa, że się pojawi w którymś z przyszłych wydań.

Pamiętajcie jednak, że nikt nie jest wam winny dodania do swojego programu rzeczy, które potrzebujecie i nie ma co się awanturować, gdy się to nie stanie. Zamiast tego możecie spróbować lepiej uzasadnić swoją propozycję, albo poszukać innego programu, który ma funkcję, której potrzebujecie.

– –

Na tym kończę część pierwszą, druga powinna pojawić się niedługo. Jest już w większości napisana, została mi korekta i dodanie ilustracji.

Jeżeli macie jakieś pytania dotyczące poruszonych zagadnień lub uważacie, że podane przeze mnie informacje wymagają uzupełnienia, a może nawet są błędne, to proszę dajcie znać w komentarzach. Z chęcią poznam wasze zdanie.

Natrafienie na niego nie mogło przyjść w lepszym momencie, bo High Tide, czyli klient Tidala, którego używałem do tej pory, aktualnie ma problemy i zapętla w kółko jedną piosenkę. Podobno dzieje się tak tylko na PipeWire, u mnie jednak zmiana wyjścia dźwięku w preferencjach nic nie dawała, a nie chciałem grzebać w ustawieniach audio w całym systemie, żeby obejść błąd w jednym programie. Wróciłem więc do używania strony Tidala zapakowanej w przeglądarkę i udającej samodzielną aplikację.

Może jest używalna, ale wygląda nieporywająco i słabo pasuje do reszty moich aplikacji.

– –

I wtedy właśnie znalazłem Tonearm, na samym początku jego drogi, świeżo po pierwszym publicznym wydaniu.

Poużywałem go przez chwilę, spodobało mi się i zacząłem wypełniać issue trackera na stronie projektu na Codebergu zgłoszeniami błędów i prośbami o nowe funkcjonalności.

Gdy okazało się, że osoby tworzące Tonearm (dwa sympatyczne smoki ze Szwajcarii) nie tylko nie zablokowały mnie za ten spam, ale też są otwarte na współpracę i reagują na zgłoszenia, naprawiając i dodając różne rzeczy oraz wyjaśniając, na czym polega problem, postanowiłem się zaangażować bardziej i przygotowałem polskie tłumaczenie, bazując na terminach używanych przez tidal.com.

Tonearm nie miał wtedy jeszcze integracji z żadnymi serwisami ułatwiającymi tworzenie wersji językowych (po mojej sugestii już jest podczepiony do Weblate), więc całość odbywała się przez pracę na forku repozytorium i wysyłaniu pull requestów ze zmianami, co przynajmniej wymusiło na mnie odświeżenie lekko zardzewiałej znajomości obsługi gita.

Dość szybko zostało naprawione kilka najbardziej dokuczliwych błędów: z wyświetlaniem większych kolekcji i dłuższych playlist, czy wywalaniem programu po kilkukrotnym przełączaniu utworów. Smoki pracują naprawdę błyskawicznie, czasem ledwo zdążyłem napisać znajomym nerdom, że znowu coś znalazłem, a już przychodził mejl z info o zamknięciu zgłoszenia.

Najdłużej czekałem na naprawienie błędu powodowanego przez nowsze API Tidala, które dla niektórych albumów zwracało tylko część utworów. Ten wpis miałem prawie gotowy ponad tydzień przed publikacją i odkładałem jego wrzucenie, aż będzie można słuchać całej biblioteki Tidala.

– –

Wystarczy jeden rzut oka na okno Tonearm, żeby było wiadomo, dlaczego program tak bardzo mi się spodobał. GUI wykorzystujące Gtk4 i bibliotekę Adwaita idealnie pasuje do całej reszty mojego gnomowego biurka.

Oczywiście obsługuje również ciemny styl oraz zmianę koloru akcentu.

Te delikatne paski ostrzegawcze na górze okna oznaczają, że używam aplikacji w wersji rozwojowej, a nie ostatecznego wydania, to taki standard wśród aplikacji dla GNOME.

– –

Dobry wygląd to nie wszytko i na szczęście się na nim nie kończy. Tonearm obsługuje przeglądanie i odtwarzanie muzyki ze strony głównej Tidala, jego biblioteki i kolekcji użytkownika (śledzonych artystów oraz polubionych płyt i utworów), a także feedu, czyli „treści dla ciebie”, ukrywającego się tu pod ikonką dzwonka.

W przeciwieństwie do High Tide potrafi skorzystać z Tidalowej funkcji autoplay, czyli odtwarzania powiązanych utworów po zakończeniu albumu/playlisty, co dla mnie jest dość istotną opcją, dzięki której często odkrywam nową muzykę.

Jak widać na zrzucie powyżej, w preferencjach możemy włączyć scrobblowanie do ListenBrainz oraz Last.fm. Dzięki temu mogłem wyłączyć zajmującego się tym do tej pory demona rescrobbled. Przy okazji mogę go szczerze polecić, bo pracuje ze wszystkimi odtwarzaczami obsługującymi MPRIS, dzięki czemu można niezależnie od tego, którego programu używa się do słuchania muzyki, czy to streamowanej, czy z lokalnej biblioteki, wszystko automagicznie ląduje na Last.fm.

Scrobblowanie (od nazwy serwisu Audioscrobbler) to wysyłanie danych o słuchanej muzyce do serwisu, który na tej podstawie tworzy statystyki i rekomendacje. Last.fm używam w tym celu już od 2005 roku.

Tonearm pozwala też na wyświetlenie tekstu utworu (o ile jest dostępny) i zarządzaniem kolejką odtwarzania. Obie funkcjonalności są dostępne przez przyciski na spodzie panelu, w którym znajduje się odtwarzacz.

Przydatną możliwością jest wybór jakości dźwięku serwowanego z Tidala (do wyboru cztery poziomy) oraz sposobu normalizowania dźwięku utworów, czyli ReplayGain: automatycznie, dla całych albumów (AlbumGain) i pojedynczych piosenek (TrackGain).

– –

Poza tym wszystkim, co już pojawiło się w Tonearm, poprosiłem również o dodanie powiększania okładek albumów i zmiany layoutu aplikacji, tak by lepiej dopasowywał się do dostępnego miejsca i dzięki temu był przyjaźniejszy dla urządzeń mobilnych.

Z rzeczy zgłoszonych przez innych czekam jeszcze na tworzenie i edycję playlist oraz filtrowanie i sortowanie artystów, albumów i playlist w kolekcji.

Jak widać z powyższej listy zostały rzeczy mniej istotne dla codziennego korzystania z Tidala, dlatego mogę śmiało polecić tę aplikację, mimo że jest naprawdę świeża.

Najnowsze wydanie 1.3.1 możecie znaleźć na Flathubie. Nie zawiera jeszcze obejścia problemu API Tidala z niektórymi utworami, ale pewnie pojawi się ono niedługo.

Jeżeli chcielibyście spróbować wersji rozwojowych, to źródła programu znajdują się na Codebergu. Tonearm od niedawna bardzo ładnie buduje się w GNOME Builderze, ale jeśli wolicie uniknąć samodzielnego tworzenia flatpaka, na stronie akcji znajdują się testowe pakiety generowane automatycznie po każdej zmianie w głównej gałęzi repozytorium.

W lutym udało się dwa razy wyskoczyć na Małą Pętlę Notecką, ale poza tym zajmowałem się głównie zawożeniem roweru do serwisu, najpierw na przegląd, z potem z kolejnymi reklamacjami. W rezultacie nie pojeździłem za dużo, a na dodatek rozstałem się z warsztatem, do którego woziłem wszystkie swoje rowery od dekady.

W marcu zabrałem się za odrabianie zaległości i od tego czasu miesięczne dystanse przewyższały te sprzed roku. Wszystko szło świetnie i zapowiadało się, że mimo słabego początku poprawię zeszłoroczny wynik – liczyłem nawet na przekroczenie progu ośmiu tysięcy. Niestety, pod koniec sierpnia powrócił ból kolan, który zniweczył mi rowerowe plany w 2017 i „skończyło się rumakowanie”. Po zastrzykach z osocza cały wrzesień nie ruszałem roweru i ostrożnie wróciłem do jazdy dopiero w październiku i powoli kulałem się już do końca roku.

Moje pierwsze zdjęcie z trasy w 2025 pochodzi z szóstego lutego i przedstawia idealnie czysty rower, świeżo po jednej z wizyt w serwisie. Ostatnie to brudna klamkomanetka uszkodzona w czasie porządnej gleby na oblodzonej leśnej drodze 29 grudnia.

To niezła klamra dla minionego roku.

– –

Lista przebojów

• Najdłuższa trasa: ponad 220 kilometrów do Poznania na ramen i podziwianie tamtejszej infrastruktury rowerowej w czerwcu.
• Najbardziej satysfakcjonująca trasa: wyczekiwany od kilku lat przejazd Starym Kolejowym Szlakiem z Kołobrzegu do Piły w sierpniu.
• Największe osiągnięcie: zrzucenie 14 kilogramów od kwietnia.

– –

Koszty

2025 niestety nie był tanim rokiem. Poza zwykłym utrzymaniem roweru w stanie pozwalającym na jazdę kupiłem też trochę części i ciuchów rowerowych. Gdy teraz siadłem do podsumowania, złapałem się za głowę, gdy zobaczyłem, ile wydałem przez ten czas.

Na początku sezonu mój gravel Ridleya zaliczył centrowanie kół, regulację napędu, wymianę kasety, łańcucha i klocków hamulcowych, a jesienią musiałem ponownie założyć nowy łańcuch. Poza tym wymieniłem owijkę na taśmę BT Gravel z Ergonu o grubości 3 milimetrów. Kapitalnie się ją trzyma i amortyzuje lepiej, niż jej poprzedniczka. Razem z owijką (afair 120 zł) i resztą części serwisowanie kosztowało mnie około 1000 złotych.

Prawie zapomniałem, że kupiłem też nowe pedały – zajechane przez dziesięć lat pracy PD-M520 zastąpiłem nowymi PD-M8120 (360 zł), ale nie jestem do końca zadowolony z tej zmiany. Powinienem był kupić kolejne M520 i zaoszczędzić ponad dwie setki.

Z tej samej firmy co owijkę, mam też nowe siodełko, model SR Allroad (290 zł). Chyba dobrze trafiłem, bo jest wyraźnie bardziej wygodne od poprzedniego. Siodło sprawdza się zwłaszcza z kupionymi w tym roku spodenkami Van Rysel EDR, które okazały się tak wygodne, że gdy trafiła się promka, kupiłem drugie (240 i 215 zł).

Spodenki to nie jedyne ciuchy, które kupiłem. Poza tym doszły mi dwie cieplejsze bluzy base layer z długim rękawem Van Rysel Racer 2 (razem 260 złotych), zimowe spodnie Van Rysel Racer (255 zł) i kompaktowa wiatrówka Van Rysel Racer Ultralight (140 zł) w miejsce takiej samej, rozdartej gdzieś w lesie na gałęzi.

Jak już wymieniam zakupy z Decathlonu, to kupiłem tam też super lekką (50 g!) kuchenkę Forclaz MT900 i tytanowy kubek do gotowania wody (razem 290 złotych), by móc zalewać liofilizaty i zjeść porządny obiad w czasie dłuższego jeżdżenia po lasach. Sprawdzają się świetnie.

Disclaimer: Decathlon mnie nie sponsoruje, po prostu nie stać mnie na kupowanie rzeczy bardziej lansiarskich brandów. A jeżeli ktoś z Deca tu trafił i chce nawiązać współpracę, to zapraszam, akurat szukam nowego roweru xD

Zmieniłem też zajeżdżone opony, zostając przy tym samym modelu Continental Terra Speed, ale tym razem w wersji całkowicie czarnej (345 złotych za dwie sztuki). Do pracy i trwałości samych gum nie miałem żadnych zastrzeżeń, wkurzało mnie tylko to, jak brudzą się ich jasne, brązowe boki.

A pod koniec roku dorobiłem się w końcu porządnych butów zimowych, Shimano MW702, zamiast dotychczasowego kombinowania z owijkami na letnim obuwiu (795 złotych).

Mój ponadtrzydziestoletni trekking, którym jeżdżę na zakupy, też coś dostał. Kupiłem mu nowe opony Schwalbe Smart Sam (140 zł za parę) i przedłużyłem błotniki dopinając odpowiednie Ass Savery (67 zł za obie przedłużki).

Razem wychodzi około 4400 złotych, ponad 365 na miesiąc. A to bez doliczenia jedzenia i picia wciąganego w czasie jazd oraz biletów kolejowych na przewóz roweru. Nie ma to jak mieć hobby, cholera jasna.

Pocieszają mnie dwie rzeczy. Po pierwsze, większość tych wydatków (jakieś ⅔) będzie pracować całe lata (ubrania, buty, pedały, siodło i kuchenka), a tylko część to bieżące utrzymanie roweru, czyli serwis, łańcuch, kaseta i opony. Po drugie, to tylko pół paczki papierosów dziennie, czyli mógłbym mieć bardziej niezdrowy i droższy nałóg.

– –

Statystyki

W 2025 zarejestrowałem w sumie 174 aktywności o łącznej długości 6421 kilometrów (dziewięć setek mniej niż 2024), które zajęły mi razem 310 godzin i 5 minut, co oznacza, że spędziłem na rowerach prawie 13 dni – o dwie doby mniej niż przed rokiem.

W przeciwieństwie do zeszłego roku, gdy większość zarejestrowanych przejazdów była wyjazdami na zakupy itp., w tym roku większość to jazdy dla frajdy. Ich stosunek to 75 do 99. Różnica między dystansami jest jeszcze większa, 786 kilometrów na zakupy, 5635 dla frajdy.

Tak jak przed rokiem, najdłuższy dystans wykręciłem w czerwcu, gdy przekroczyłem próg 1100 kilometrów – to najlepszy wynik od ośmiu lat. Najgorzej oczywiście wypadł wrzesień, gdy nie jeździłem wcale.

Moje średnie tempo jazd dla frajdy w tym roku nieźle skakało. Zaczęło się poniżej 20 km/h, stopniowo rosło, by w maju i czerwcu zbliżyć się do 24 km/h (wyżej niż w najlepszym miesiącu 2024), a potem ostro spadło do niecałych 18 km/h w październiku, gdy ostrożnie wracałem na rower, po czym odrobinę podskoczyło do okolic 20 km/h.

Średnią długość jazdy miałem wyraźnie krótszą niż rok wcześniej, gdy w 9 miesiącach przekraczała 60 kilometrów. Tym razem miałem tylko trzy takie miesiące (kwiecień, czerwiec i sierpień), a w trzech kolejnych średnia była wyższa niż 50 km (marzec, maj i lipiec).

To wynik mojej decyzji o zwiększeniu ilości krótkich i częstszych treningów, głównie by wspomóc odchudzanie. Około 58% jazd było krótszych niż 50 kilometrów, podczas gdy przed rokiem było to niecałe 44%.

Zaskoczyło mnie trochę, że tak mało jazd miało między 75 a 100 kilometrów, bo zakładałem, że liczby tras w kolejnych progach będą się kolejno zmniejszać. Najwyraźniej to dystans, który mi nie pasuje, albo zakładam, że skoro mam jechać powyżej 75, to równie dobrze mogę zrobić setkę.

– –

Mapa

Na mapie najbardziej rzuca się w oczy Stary Kolejowy Szlak z Kołobrzegu do Piły, a ten oderwany od reszty tras szlaczek w okolicy Chojnic, to przejazd dwiema trasami Kaszubskiej Marszruty.

Przy tworzeniu heatmapy skorzystałem z Strava Multiple Ride Mapper Jonathana O’Keeffe.

– –

Squadrats

W 2025 powiększyłem mój übersquadrat (największy kwadrat ułożony z odwiedzonych squadratów) z 17×17 do 20×20, głównie dzięki trzem nastawionym na kwadratowanie wyjazdom w marcu i kwietniu.

Liczba odwiedzonych kwadratów wzrosła o 323, do czego najbardziej przyczyniły się długie wyjazdy: Kaszubska Marszruta (+69) i Stary Kolejowy Szlak (+145).

Muszę przyznać, że po tym, jak na początku roku skupiłem się na powiększaniu übersquadratu, to później kwadraty zupełnie wypadły mi z głowy i nie pojechałem dwóch zaplanowanych tras, dzięki którym przeskoczyłbym do 22×22. Może w tym roku to nadrobię.

– –

Porównanie z całością „kariery”

Chociaż w porównaniu z poprzednim rok 2025 wypadł gorzej, to ogólnie jest krokiem w dobrą stronę. Całoroczny dystans jest moim czwartym najlepszym wynikiem (po kolejno 2016, 2024 i 2017).

Pod względem ilości jazd miniony rok uplasował się na trzecim miejscu (po 2016 i 2024). Tym razem nie podskoczyłem wyżej dzięki wyjazdom na zakupy, bo po ich odliczeniu okazuje się, że licząc wyłącznie jazdy dla frajdy, 2025 nadal łapie się na podium (po 2016 i 2017).

Średnia prędkość jazd dla frajdy tym razem lekko opadła (z 21,8 km/h w 2024 do 21,3 km/h), zamiast nadrabiać straty do rekordowych lat z początków mojego rowerowania, gdy sięgała nawet 27 km/h. Wiek i kontuzje robią swoje i już jakiś czas temu pogodziłem się z tym, że „lepiej już było”.

Średni dystans wyraźnie spadł, co mnie bardzo cieszy, bo zeszłoroczny znaczny przyrost trochę mnie zaniepokoił i wydawał się niezdrowy. Szkoda, że to i tak nie powstrzymało powrotu bólu kolan. Może powinienem zjechać jeszcze niżej, poniżej 50 km?

Jeżeli ktoś jest ciekaw, jak udało mi się obrobić dane, żeby stworzyć te statystyki i wykresy, to gorąco polecam mój ulubiony serwis do rejestrowania i planowania aktywności, czyli Ride with GPS. Można z niego bardzo prosto pobrać plik CSV z wszystkimi zarejestrowanymi jazdami, a późniejsza obróbka w arkuszu kalkulacyjnym jest już banalna.

– –

Plany

Rok temu planowałem ostrożniejsze jeżdżenie, żeby zapobiec problemom ze zdrowiem. Najwyraźniej i tak byłem zbyt beztroski, więc w 2026 powinienem jeszcze bardziej uważać. To główny powód, dla którego nie mam żadnych konkretnych planów na dłuższe trasy. Skoro ciągle nie wiem, w jakiej formie będą moje nogi, to nie mam co rysować śladów na mapie.

To, co chciałbym zrobić na pewno, to sesja bike fittingu, a raczej bike sizingu, dzięki której chciałbym dokładnie wiedzieć jakiej wielkości rower powinienem kupić i jaką ustawić na nim geometrię przez dopasowanie wysokości siodła, długości mostka, ramion korby, szerokości kierownicy itp. Odkładam fundusze i czaję się na następną maszynę już jakiś czas i chciałbym, żeby była jak najbardziej do mnie dopasowana.

Muszę zacząć się rozglądać za jakimiś dobrymi fitterami, najlepiej takimi z doświadczeniem w temacie fizjoterapii, żeby potrafili wziąć pod uwagę moje trefne nogi. Z tego, co zdążyłem się zorientować, w Bydgoszczy nie ma nikogo takiego, może w Poznaniu albo Trójmieście?

Na razie uzupełniam i studiuję arkusz, w którym wypisuję sobie potencjalne nowe rowery, razem z danymi na temat ceny, materiału ramy, napędów, zakresów przełożeń, kół i maksymalnej szerokości opon.

Rzuciło mi sie w oczy kilku faworytów, ale nic konkretnego jeszcze nie wybrałem. Jedno jest pewne – jeżeli uda mi się w tym roku kupić rower, to sekcja „Koszty” w następnym rocznym podsumowaniu będzie jeszcze bardziej brutalna.

Mam tylko nadzieję, że nie okaże się, że zamiast cieszyć się nowym rowerem, będę dochodził do siebie po artroskopii…

Odpuszczenie Świątecznej Pięćsetki nie oznacza, że nie jeździłem wcale. Wręcz przeciwnie, nakręciłem ponad dwieście kilometrów więcej niż w listopadzie.

– –

Pierwszy tydzień to dwie krótsze jazdy w okolicach 35 km każda i jedno dłuższe wykulanie. Ostatnio jeździłem prawie wyłącznie nad Notecią, więc tym razem wybrałem się w dawno nieodwiedzane okolice na północny wschód ode mnie. Pogoda była w miarę przyjemna, więc udało się nakręcić 75 kilometrów, w większości po szosie.

– –

Drugi tydzień grudnia to znowu dwa krótkie wyjazdy, 41 i 35 kilometrów. Na ten pierwszy zdecydowałem się za późno i po raz pierwszy Małą Pętlę Notecką przejechałem w całości po ciemku. Zupełnie inne doświadczenie i całkiem fajna sprawa.

Trzecia jazda była trochę dłuższa – najpierw wzdłuż Noteci z przejazdem przez bardzo błotnisty rezerwat „Borek”, a później przeskoczyłem na północną stronę DK10 i dokręciłem do sześćdziesięciu kilometrów po wsiach.

– –

Trzeci tydzień to tylko jeden wyjazd, ale za to bardzo fajny. Korzystając z tego, że w środku tygodnia nie było polowań, przejechałem się jedną z najfajniejszych tras dla graveli w mojej okolicy, czyli 30 kilometrów po szutrach od Gromadna do Turu + po dwie dychy dojazdu do i z lasu.

– –

Tuż przed nadejściem świąt i mrozu, wyskoczyłem na pięćdziesiąt kilometrów po okolicy w piękny, słoneczny dzień. Planowałem trzydzieści, ale było za ładnie, żeby tak wcześnie wracać do domu.

W drugie święto nie wytrzymałem i wybrałem się na kolejne kręcenie, ale musiałem odpuścić i skrócić jazdę do dwudziestu kilometrów, bo gęsta mgła zamarzała mi na okularach i ledwo widziałem drogę przed sobą.

– –

Na koniec grudnia wyskoczyłem na jeszcze jedną dłuższą jazdę. W planach miałem dojechanie szlakiem Pętli Noteckich do Krostkowa, odwiedzenie tamtejszego punktu widokowego i wjechanie do lasu dookoła Dębowej Góry „od tyłu”, czyli drogą, którą zazwyczaj z niego wyjeżdżam. Pogoda była idealna, słonecznie i z temperaturą tuż nad zerem i jechało się świetnie. Nawet błocko w „Borku” tym razem nie było takie upierdliwe. Pomyślałem więc o wjechaniu na samą Dębową Górę, co wydłużyłoby mi nieco trasę i więcej czasu spędziłbym w lesie, a nie na szosach.

Niestety, dość szybko po wjechaniu do lasu zaliczyłem potężną glebę. Okazało się, że w przeciwieństwie do całej reszty trasy, drogi w tym lesie pokryte są cienką warstwą lodu i wystarczyła jedna oblodzona koleina, żebym stracił przyczepność. Musiałem odpuścić wjazd na Dębową Górę i wyjechałem z lasu jak najkrótszą drogą, prowadząc rower w kilku bardziej śliskich miejscach.

Na szosie znowu były idealne warunki, więc mimo poobijania (bolała lewa noga i łokieć) i uszkodzenia klamkomanetki, dokręciłem do 72 kilometrów.

– –

W sumie w grudniu zarejestrowałem ponad 600 km, z czego niecałe 106 w czasie wyjazdów na zakupy, a prawie pięć setek dla frajdy. Na rowerze spędziłem 31 godzin i 43 minuty. Podjechałem łącznie na 3818 metrów, co jest najlepszym wynikiem od lipca.

Po tej glebie na oblodzonej leśnej drodze znowu włączył mi się tryb przesadnej ostrożności i w czasie ostatniej w roku jazdy na zakupy panikowałem na widok mokrej szosy, mimo że miałem na niej idealną przyczepność. Podejrzewam, że skończy się to mniejszą aktywnością rowerową w styczniu, skoro jednak w prognozach nie widać sensownej pogody, to jakoś bardzo nad tym nie rozpaczam.