Podczas rozmowy z dyrektorem technicznym pewnej firmy hostingowej usłyszałem od swojego rozmówcy, że spora część Wolnego Oprogramowania wykorzystywanego przez jego firmę jest usuwana z jądra Linuksa, ponieważ nie ma nikogo, kto mógłby nadal rozwijać ów podsystem i opiekować się nim. Choć nie posunął się do oskarżeń, można było odczuć, że w jego opinii pewnym częściom jądra nie poświęca się należytej uwagi – mimo roli, której odgrywają w świecie FOSS.
Takie rzeczy się zdarzają – historia zanotowała już kilka takich przypadków. Zwykle w ostatniej chwili społeczność FOSS się mobilizuje i pojawia się kilku programistów, którzy podejmują się wyzwania. Bywa i tak, że na sponsorowanie pracy programistów decyduje się jakaś firma, dzięki czemu mogą pełnoetatowo zajmować się czymś, co robili w czasie wolnym.
Prawdą jest zatem, że od czasu do czasu społeczność FOSS ma problem z zapewnieniem wystarczającej liczby programistów dla istotnych projektów bądź ich ważnych części. Prawda jest również, że oprogramowanie, z którego korzystamy, czasem przestaje być rozwijane – programiści porzucają projekt lub (niestety) umierają. I właśnie dlatego projekty potrzebują spędzać tyle samo czasu na „budowaniu społeczności” wokół siebie co na samym pisaniu kodu. Liderzy projektu powinni przyciągać nowych utalentowanych programistów, wzbudzać entuzjazm, a także pomagać w rozwijaniu kompetencji osobom, które jutro przejmą rolę nowych architektów i liderów.
Dopóki o tym nie wspomniałem, mojemu rozmówcy nie przyszło do głowy, że zamknięte oprogramowanie ma ten sam problem – trzeba było widzieć wtedy jego minę. Chodzi nie tylko o to, że znikają całe firmy – czasem bardzo duże – a ich produkty stają się bezużyteczne, ale często zdarza się, że poszczególne projekty bądź całe ich linie są porzucane jako nie przynoszące zysków (lub za mało zyskowne).
Różnica między „otwartymi” a „zamkniętymi” projektami polega na tym, że zwykle „otwarte” projekty wysyłają wcześniej sygnały, które są jasno widoczne dla tych, którzy potrafią je odczytywać. Aktywność projektu, data ostatniego wydania, liczba programistów, liczba wątków na liście dyskusyjnej – wszystkie te kwestie mogą być wskazówkami informującymi o stanie projektu. Trudno oczywiście wymagać, by mała firemka przeprowadzała podobne analizy, ale dyrektor techniczny mógłby.
Co więcej, jeśli biznes firmy zależy od funkcji, które mają zostać usunięte, dyrektor techniczny mógłby przeznaczyć zasoby na utrzymanie tych funkcji lub przynajmniej przejść na jądro z długim okresem wsparcia technicznego, by zyskać na czasie i móc znaleźć faktyczne rozwiązanie. To, że dana funkcja zostanie usunięta z jednego z przyszłych jąder, nie oznacza, że nagle zniknie z istniejących.
W całej tej sprawie chodzi jednak o coś więcej niż tylko sprzęt i oprogramowanie.
W „starych, dobrych czasach” na komputerach typu mainframe w danej chwili działało zazwyczaj tylko kilka aplikacji, zaś lista zależności była stosunkowo krótka. Natomiast we współczesnym świecie serwerów i chmur liczba zależności zdaje się rosnąć wykładniczo, zaś „koszmar zależności” spycha nas w stronę kontenerów, które umożliwiają jeszcze szybszy rozwój wspomnianego koszmaru. W pewnym momencie nadążanie za wszystkimi fragmentami kodu, od których zależy istnienie naszej firmy, wydaje się zadaniem bardzo trudnym, niemal niemożliwym.
Część problemu polega na tym, że programiści FOSS się starzeją. Kiedy zacząłem prace nad Linuksem, miałem „tylko” 43 lata. Kiedy spotkałem Linusa, miał 24 lata. W przyszłym roku skończę 69 lat, a Linus – 50. Kiedyś pojawiła się dyskusja o przyszłości Linuksa po Linusie, ale Linus szybko ją wygasił, mówiąc, że gdyby coś mu się przydarzyło, wielu z obecnych opiekunów jądra ma wystarczające kwalifikacje, by przejąć pałeczkę. Faktem jest jednak, że na zjazdach i konferencjach, w których kiedyś uczestniczyli dwudziestolatkowie, teraz widać coraz więcej siwych bród. Nie czarujmy się: sinobrodzi muszą uczynić dodatkowy wysiłek, by we właściwy sposób przekazać pałeczkę.
Nie martwię się o przyszłość Linuksa, wszyscy jednak zależymy od setek tysięcy projektów FOSS. Każdy lider projektu powinien pomyśleć nad strategią kontynuacji projektu po swoim odejściu, bez względu na przyczynę. Kto przejmie projekt? Kto kontroluje domenę? Kto jest właścicielem praw autorskich do elementów projektu innych niż kod? Czy wszyscy znają hasła niezbędne do dalszego rozwoju projektu? Czy udało się (choćby wstępnie) zidentyfikować kogoś, kto potrafiłby (i chciałby) przejąć projekt? Czy ta osoba dysponuje wszystkim, co niezbędne? Jeśli będziemy czekać z tym do ostatniej chwili, może się okazać, że jest już za późno.
Warto więc wyjść na poszukiwanie padawanów i ciężko popracować nad tym, by stworzyć nowe pokolenie rycerzy Jedi.
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®.
