Spis treści
- 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.
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:
Kontrybucja dokumentacji jest często cenniejsza od kodu, a przede wszystkim łatwiejsza do oceny dla opiekuna niż kodu.
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.
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.
G_MESSAGES_DEBUG Tuba zwraca dużo więcej informacji.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.
Dodaj komentarz