To druga część wpisu, w którym zachęcam do dołączenia do społeczności tworzącej Wolne i Otwarte Oprogramowanie. W pierwszym odcinku opowiedziałem czym jest WiOO i pokazałem, jak można się zaangażować jako osoba programująca, tworząca dokumentację, zgłaszająca błędy i podsuwająca pomysły na nowe funkcjonalności. Ten będzie poświęcony testowaniu aplikacji w czasie ich powstawania, pomaganiu innym użytkownikom oraz wspieraniu osób tworzących FOSS, a w trzecim opowiem o tłumaczeniu aplikacji.

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.