A.S.: Nie zapominajmy jednak, że w świecie open source wszystkie błędy i ataki są ujawniane. W świecie closed source o pewnych rzeczach się dowiadujemy, o innych nie. Znany jest przypadek polskiego informatyka, który wykrył poważny błąd w oprogramowaniu komercyjnym. Polski oddział firmy długo przekonywał go, by o błędzie nie informować. Mamy prawo przypuszczać, że przypadek ten nie był odosobniony.

T.K.: Zapewne zdarza się, że producenci oprogramowania komercyjnego zatajają informacje o błędach, ale sprzeciwiam się często głoszonemu poglądowi, że otwartość kodu sama przez się powoduje, iż oprogramowanie jest bezpieczniejsze od "zamkniętego". Minęło ok. 20 dni od włamania na serwery Debiana (rozmowa była przeprowadzona na początku grudnia ub.r. - przyp. red) i nadal nie udało się przywrócić do pracy wszystkich serwisów dotkniętych włamaniem. Dla komercyjnej firmy byłaby to kompromitacja w oczach klientów.

A.S.: Debian jest jedynym swego rodzaju projektem. W pewnym momencie pojawił się dylemat: albo dalej rozwijać się dynamicznie dzięki daleko posuniętej demokratyzacji, albo zacieśnić kontrolę w celu podniesienia jakości. Wybór padł na pierwszą opcję - utrzymanie demokracji. Nie da się ukryć, że w kryzysowym momencie procesy nadzoru Debiana zawiodły. Była to największa katastrofa, jaka przydarzyła się temu projektowi od początku jego istnienia. Wydaje mi się, że w tej chwili Debian wychodzi z fazy młodzieńczej i wkracza w dorosłość. Uczestnicy projektu zdali sobie sprawę, że należy podnieść bezpieczeństwo kosztem np. liczby rozwijanych pakietów.

T.K.: Dlatego uważam, że aby sprostać standardom bezpieczeństwa wymaganym przez poważanych użytkowników instytucjonalnych, należy zrezygnować z części ideałów open source na rzecz kontroli. Żaden z twórców Debiana nie otrzymuje wynagrodzenia za to, że dba o bezpieczeństwo kodu pisanego przez w gruncie rzeczy anonimowych programistów. Zamiast dbać o pisanie bezpiecznego kodu - co jest procesem żmudnym - woli rozwijać nowe funkcje systemu. Wcześniej czy później taka sytuacja musi skutkować podobnymi incydentami.

A.S.: W tym przypadku nie było kwestią, czy dostępem do konta na kluczowym serwerze dysponował zasłużony i budzący zaufanie środowiska programista Debiana, czy rasowy włamywacz. Nie chodzi też o wynagrodzenie, które miałoby być gwarancją uniknięcia podobnych uchybień. Mogę przyznać rację w jednym aspekcie - słabością wielu projektów open source jest organizacja infrastruktury. Przykładowo, kod źródłowy popularnego OpenBSD jest przechowywany na serwerze uniwersyteckim. Społeczność ma ograniczone środki przeciwdziałania sytuacji, w której włamywacz dostaje się do kodu i powoduje, że po trzech dniach rozprzestrzenia się koń trojański zaszyty w źródłach.

To problem, z którym szeroko rozumiana społeczność musi sobie poradzić jak najszybciej. Nie wykluczam, że doraźnym sposobem będzie przechowywanie kodu źródłowego najważniejszych projektów na specjalnie strzeżonych serwerach organizacji i firm, które są w stanie zapłacić ciężkie pieniądze za bezpieczeństwo danych. Mam na myśli np. serwery OSDL konsorcjum linuxowego sponsorowanego przez takie firmy, jak IBM, HP, Cisco, Novell.

T.K.: Docieramy do bardzo ważnego punktu. Okazuje się bowiem, że są zadania, które z pełną odpowiedzialnością można powierzyć tylko firmom. Zresztą zjawisko komercjalizacji open source postępuje także w innych obszarach. Kluczowe elementy Linuxa są rozwijane przez firmy. W moim przekonaniu występuje naturalne przeświadczenie, że do firm o uznanej marce i pozycji rynkowej można mieć większe zaufanie niż do anonimowego developera niezwiązanego żadnym kontraktem.

Notabene, ten trend już owocuje podnoszeniem jakości niektórych rozwiązań open source. Osoby odpowiedzialne za rozwój Linuxa i biorące za to pieniądze muszą podporządkować się procedurom obowiązującym w firmach software'owych.

A.S.: Często istnienie dwóch światów - open i closed source - jest przedstawiane na zasadzie czarno-białych kontrastów. Tak jest właśnie w tym przypadku. Ktoś zinterpretuje współpracę z koncernami jako dowód dojrzewania open source, ktoś inny - przeciwnie - jako schyłek. Tymczasem oba światy wzajemnie się przenikają i zapożyczają najlepsze cechy z "konkurencyjnego" modelu. Nie widzę w tym nic sprzecznego z ideałami open source.

4. Licencje i model biznesowy

Tworzenie oprogramowania niepoparte motywem zarobkowym należy do stałego repertuaru argumentów wysuwanych przeciw open source przez producentów oprogramowania komercyjnego. Twierdzą oni, że opozycja wobec tradycyjnego modelu ekonomicznego szkodzi rynkowi i hamuje postęp.

A.S.: Model biznesowy w świecie open source to rzecz trzecio-, a może nawet czwartorzędna. Z założenia open source to oprogramowanie tworzone z myślą o użytkowniku. Zindywidualizowany twórca nie jest ważny.

Przy tej okazji należy dokonać istotnego rozróżnienia. Możemy wierzyć, że istnieje ogromna liczba odmian Linuxa, ale tak naprawdę podział sprowadza się do dystrybucji autentycznie darmowych rozwijanych przez społeczność i dystrybucji komercyjnych, którymi zajmują się poszczególne firmy.