Uniwersalny problem

Bez względu na to, czy pływacie po morzu, czy wysyłacie rakiety w przestrzeń kosmiczną, często musicie wykonywać korekty kursu. W ostatnim czasie, w prasie i w trakcie prywatnych rozmów, które odbyłem, kilka osób stwierdziło, że ludzie potrzebują „korekty kursu”.

Jedna z głośniejszych dyskusji dotyczyła liczby błędów lub problemów z bezpieczeństwem, które istnieją w „otwartym kodzie” (i używam tu tego terminu z premedytacją, zamiast „wolnego oprogramowania”), oraz tego, że jest to w jakiś sposób bardzo ważna wiadomość. To doprowadziło do kolejnej dyskusji o potrzebie utworzenia listy komponentów oprogramowania (SBOM – Software Bill of Materials), która określałaby jakie części otwartego kodu pojawiają się w produktach poszczególnych firm. Nie zrozumcie mnie źle, uważam, że SBOM to dobry pomysł, szczególnie jeśli może być zrealizowana łatwo i niemal automatycznie w procesie budowania oprogramowania. Jednak ludzie opowiadają o „problemie błędów”, jakby był to tylko problem otwartego kodu i nie dotyczył całego oprogramowania w historii.

Kiedyś oprogramowanie było prostsze, a ludzie mogli analizować kod oraz (mając grupę dobrych inżynierów) utrzymywać biblioteki i środowiska. Jednak z mojego doświadczenia z pracy w firmach zajmujących się zamkniętym oprogramowaniem wiem, że duże części kodu nie są przeglądane przez inżynierów oprogramowania przez długi czas, ponieważ nie ma ku temu zasobów. Widziałem wiele linii kodu nieobjętych przez skrypty testowe lub testy regresji. Dotyczyło to zarówno otwartego i wolnego oprogramowania (FOSS), jak i własnościowych narzędzi, ale to „FOSS” i „Linux” zwracają na siebie uwagę.

Różnica jest taka, że otwarty kod (a szczególnie wolne oprogramowanie) to kod, który przegląda wiele oczu i można go załatać, kiedy zrozumie się problem. Zamknięty kod (lub zamknięty, ale korzystający z otwartych komponentów) nie może być załatany przez użytkownika końcowego, który musi czekać, aż firma, która wyprodukowała narzędzie, opublikuje łatkę i to przy założeniu, że w ogóle firma się tym zajmie.

Nie przeszkadza mi to, że prasa i eksperci wskazują na to, że w FOSS znajdują się błędy. Przeszkadza mi, że w pewien sposób sugerują, że jest to problem FOSS, a nie zamkniętego oprogramowania.

Częściowo jest to powiązane z ostatnim incydentem, kiedy to deweloper otwartych źródeł umyślnie opublikował kod z błędem, rzekomo w formie protestu wobec tego, że firmy zarabiają duże pieniądze na kodzie FOSS, jaki tworzą ludzie. W rezultacie pojawił się apel do firm, aby wynagradzały twórców związanych z FOSS za ich pracę w tej społeczności.

Chociaż jestem za tym, aby ludzie poświęcający swój czas i wysiłek na rzecz projektów FOSS byli za to wynagradzani i rozumiem frustrację związaną z tym, że multimiliarderzy bogacą się, zarabiając dziesiątki tysięcy razy więcej niż „ich pracownicy”, to muszę też powiedzieć, że w FOSS nie chodzi o otrzymywanie zapłaty za oprogramowanie, z którego ktoś skorzysta, ale o tworzenie narzędzi, których sami potrzebujemy.

Dawniej nie było zbyt wielu, o ile w ogóle byli, „profesjonalnych programistów”, ludzi, którym płacono za programy. Pisano wtedy narzędzia do rozwiązywania własnych problemów i często się nimi dzielono, aby pomóc innym. Czasami ci inni ludzie pomagali ulepszyć dany program.

Byli też tacy, którzy nie wiedzieli, jak programować, a którzy też potrzebowali tych programów... i wszystko było w porządku. Narzędzia, z których nikt nie korzysta, są bezużyteczne.

Niedługo po tym, jak uruchomiony został projekt jądra Linuksa, pewna część deweloperów podniosła kwestię „firm zarabiających na oprogramowaniu, które piszemy za darmo” i proponowała różne sposoby zmuszenia tych firm do płacenia za dane oprogramowanie. Zauważono jednak, że jeśli pójdziemy tą ścieżką, to FOSS będzie szedł do przodu bardzo powoli, niczym lodowiec. Niektórzy odeszli z projektu, inni zostali zatrudnieni przez firmy, które uznały, że opłaci się im mieć takich pracowników, a jeszcze inni dalej pisali oprogramowanie na własne potrzeby.

Kiedy rozmawiam z programistami o zaangażowaniu w FOSS, sugeruję im, że najpierw powinni wybrać obszar, który jest ich pasją: audio, wideo, gry, bazy i hurtownie danych, przetwarzanie tekstu... lista nie ma końca. Więcej nauczą się o swoich zainteresowaniach i być może dostaną zatrudnienie w firmach, które potrzebują ekspertów opierających się na danej pasji.

Może też być tak, że narzędzie, nad którym pracujemy, ułatwia wykonywanie zadań w danej dziedzinie i można to spieniężyć, ale jest to dużo trudniejsze i musimy być ostrożni, aby nie zbudować projektu, którego nie da się utrzymać, ani samemu, ani z pomocą użytkowników. Jednak nie powinniśmy umyślnie karać użytkowników, jeśli tworzenie tego oprogramowania nie daje nam już satysfakcji.

Prasa i eksperci sugerują, że dotyczy to tylko „otwartych źródeł”, a prawda jest taka, że to problem ogólny.

Bądźmy uczciwi.

Jon „maddog” Hall jest autorem, wykładowcą, informatykiem i jednym z pionierów Wolnego Oprogramowania. Od 1994 roku, kiedy po raz pierwszy spotkał Linusa Torvaldsa i ułatwił przeniesienie jądra na systemy 64-bitowe, pozostaje orędownikiem Linuksa. Obecnie jest prezesem Linux International®.