Na co umierają projekty?

Tyle wspaniałych projektów rozstało się z naszą rzeczywistością w czasie mojego użytkownika Linuksa na desktopie… I nie piszę tego tylko ze względu na nutkę nostalgii, która może się każdemu przytrafić w listopadowe wieczory pod znakiem zadumy nad sensem egzystencji. Używamy programu i nagle szast prast – 5 lat minęło i nie da się go już używać. Powody doprowadzające program do stanu bezużyteczności są różne – zniknięcie z repozytoriów w nowej wersji systemu, zniknięcie z sieci źródeł, niekompatybilność z nowymi komponentami systemu, niepoprawione błędy, niedokończone opcje, niedopisane funkcjonalności. Można by powiedzieć, typowe przypadki, które mogą się przytrafić każdemu programowi. W którymś momencie twórca zarzuca projekt – znudził się nim, dotarł do kresu swoich możliwości, znalazł ciekawsze zajęcia, dostał absorbującą pracę, woli z dziećmi chodzić do parku, musi ciężej pracować na utrzymanie swoje i rodziny. Niepotrzebne skreślić.

Niniejszego tekstu nie należy oczywiście łączyć w bezpośredni sposób z obchodami i charakterem 1 listopada. To zupełnie inny wymiar przemyśleń i priorytetów. Niemniej, zanim po raz kolejny zaczniemy wyliczać osoby które dołożyły swoją cegiełkę do rozwoju Linuksa i opensource i już kolejnej nie dołożą, zastanówmy się, czy zawsze tylko kategoryczny kres istnienia jest przeszkodą w realizacji wzniosłych celów.

Aby radośnie rozpocząć smętne narzekanie rozpocznijmy od pocieszenia, że użytkownicy płatnych programów mają jeszcze gorzej. Gdy producent zadecyduje, że kończy wsparcie dla systemu lub zwija interes, na nic nasze dolary wyrzucone na licencje. Otwarte oprogramowanie ma tę przewagę, że przy odrobinie szczęścia znajdzie się ktoś, kto pociągnie projekt dalej. Niemniej jest jeszcze jedna zmienna którą należy w tym wszystkim uwzględnić. Otóż niekiedy developerzy nie mają już czasu lub ochoty na wprowadzanie w swoich programach poprawek uwzględniających zmiany w bibliotekach czy samym kernelu. Rozwój Linuksa wygląda jak wygląda – ogromny warsztat po którym kręcą się mechanicy, potykając się co chwilę o porozrzucane narzędzia, od czasu do czasu przekładając je w inne miejsca. Taka praca „na żywioł” ma swoje zalety (co nie oznacza całkowitego braku planowania) – a raczej miała w początkowym okresie zdobywania przez Linuksa pulpitów komputerów domowych. Powiew świeżości, co rusz jakaś nowinka, ogromne możliwości dostrajania, poprawiania, układania systemu pod swoje wymagania. Dzięki temu wielu odrzuciło precz kajdany i z uśmiechem powędrowało doliną wolności. Lecz gdy się już wszyscy nacieszyli widokami, okazało się, że by przeżyć potrzebne są narzędzia. Inaczej dolina pozostanie śliczna i kusząca lecz jałowa.

Chętnych do pisania programów jest całe mnóstwo – wystarczy przejrzeć ilość projektów na github.com, sourceforge.net, bitbucket.org czy innych serwisach pozwalających uzewnętrzniać się ze swoimi źródłami. Oczywiście 70% deweloperów to studenci piszący pracę zaliczeniową, napaleni na kodowanie gimnazjaliści lub osoby próbujące nabrać wprawy w programowaniu. Jednak pozostała część osób ze sobie znanych względów próbuje stworzyć coś bardziej trwałego i użytecznego niż kolejny generator liczb losowych. Lecz gdy wpadną w strumień wiecznej bryzy przemian, wielu nie wytrzymuje mimo chęci. Nie są w stanie dotrzymać kroku tej całej maszynie, którą kieruje Ktoś i prowadzi Dokądś. Ktoś jest typowym mechanikiem i interesuje go tylko dłubanie w silniku – aby jechało, wygoda to termin zarezerwowany dla gładkolicych estetów.

Właśnie w takich niesprzyjających warunkach muszą przetrwać deweloperzy. Lecz choć jest ciężko to można śmiało zaryzykować twierdzenie, że w znoju i trudzie wykuwają się najlepsze charaktery. I projekty. Owszem, przepisanie swojego dzieła np. z GTK2 do GTK3 lub Qt5 to nielichy wysiłek. Pestką przy tym jest tworzenie paczek i uwzględnianie nowej nomenklatury nazw zależności. A apetyt rośnie w miarę jedzenia. Dziś już nie wystarczą nam proste programy wykonujące jedną czynność. Wszyscy z zazdrością spoglądamy na płatne rozwiązania, które oprócz wątpliwego blichtru zawierają niekiedy całkiem sensowny zestaw funkcji. Dla pojedynczego programisty opensource rzecz nie do wykonania w jeden ani dwa wieczory. Ba, niekiedy i dziesięciolecia to mało (vide GIMP). W obecnych czasach aby otrzymać program o gruntownej użyteczności i przewidywalnej stabilności ktoś musi spędzić nad nim wiele roboczogodzin. Wszystko po to, aby użytkownik opensource nie wlókł się w ogonie postępu. Od zniechęcenia wiedzie już prosta droga do zapomnienia. A zapomniane projekty wiadomo jak kończą.

Dlatego dbajmy i szanujmy projekty opensource, bo tak nagle i znienacka mogą przestać się kompilować na naszej nowej dystrybucji. Okażmy wsparcie ich deweloperom, traktujmy ich jak swoich bliskich. Służmy dobrą radą oraz wskażmy palcem co nam się nam w nich (projektach, nie deweloperach) nie podoba lub powoduje błędy. Nie utyskujmy na różnorodność, wszak jaki nudny byłby ten świat gdybyśmy wszyscy wyglądali i zachowywali się tak samo. Nie każdy też dysponuje takim samym gustem. Nie wszyscy żenimy się z kobietami o blond włosach i sprecyzowanych wymiarach tak samo jak nie wszystkie kobiety pożądają wysmukłych, wysportowanych i obłędnie inteligentnych panów. Coś co podoba się komuś i uzna to za wybitne osiągnięcie niekoniecznie musi przekonać inną osobę. Zaakceptujemy opensource takim, jaki jest. Pozwólmy projektom ewoluować, zmieniać się i wić się w meandrach nieprzebranej pomysłowości ludzkiej. Dodajmy sobie wszyscy otuchy.