Zastąpienie działającego w firmie oprogramowania komercyjnego rozwiązaniami open source jest kuszące - dopóki nie pozna się wszystkich konsekwencji owej przesiadki.

Zdeterminowany chwilową niestabilnością systemu komputerowego, zacząłem rozważać, czy nie użyć w naszej infrastrukturze elementów tworzonych na zasadach open source. W związku z tym, że nigdy nie miałem zainstalowanego u siebie ani jednego linuxowego bajta, ani nawet nie pracowałem na takim systemie, postanowiłem poszukać udanych i nieudanych wdrożeń zarówno całych systemów, jak i ich fragmentów. Historie, na które się natknąłem, nawet jeśli były trochę przesadzone, zmusiły mnie do rozważań nad pewnymi zagadnieniami pracy działu IT w opensourcowej rzeczywistości. Ostateczna konkluzja artykułu, w porównaniu do wcześniejszych zamierzeń, zaskoczyła nawet mnie.

Wedle humoru i możliwości

Wszystko zaczęło się jak zwykle, czyli to, co pracowało przez kilka miesięcy zupełnie bezawaryjnie, nagle odmówiło posłuszeństwa. Jak się później okazało, fragment systemu był dziurawy jak ser szwajcarski, a łatka systemowa pojawiła się później, niż atak ją wykorzystujący. W ramach rozważań, jak poprawić bezpieczeństwo naszego systemu (oczywiście, już po żmudnych i nie wiadomo czy do końca skutecznych próbach zażeganiu problemu), jeden z moich pracowników zaproponował wdrożenie rozwiązania bazującego na programie powstającym na zasadach open source. Co prawda, nikt z nas nigdy nie pracował na tym systemie, ale przecież wszyscy doskonale wiedzą, że Windows jest brzydki, a Linux wręcz przeciwnie. Sam też regularnie wygłaszam takie tezy, oczywiście niepoparte żadnymi praktycznymi doświadczeniami. Jednak całą infrastrukturę firmy, w której pracuję, opieram na programach z Redmond.

W związku z tym, że w różnych periodykach czytałem już peany na temat udanych wdrożeń Linuxa w różnych przedsiębiorstwach i urzędach, zacząłem się rozglądać za tymi nieudanymi przypadkami, bo w końcu to one świadczą o rzeczywistych problemach, na które można się natknąć. Poza tym nie ma co ukrywać, że jeśli o udanym wdrożeniu opowiada przedstawiciel firmy, która takiego wdrożenia dokonała, to zawsze można się niepokoić o to, czy niuanse (które mogły napsuć sporo nerwów w czasie, kiedy się pojawiły) będą w tym opowiadaniu właściwie naświetlone.

Ruszyłem więc do poszukiwań firm, które miały jakiekolwiek doświadczenia w prowadzeniu wdrożeń Linuxa u swoich klientów. Tu miałem trochę szczęścia. W jednej z firm znajomy informatyk opowiedział, jak wdrażali rozwiązanie dla 150 klientów. Firma sprzedawała i wdrażała dotychczas jedynie rozwiązania Microsoftu. Możliwe więc, a nawet pewne, że patrzyli na wdrożenie przez pryzmat dotychczasowych doświadczeń. A tu natknęli się na spory szok kulturowy. W przypadku Linuxa nie ma bowiem, poza pojedynczymi dystrybucjami, jakiegoś centrum wsparcia technicznego, do którego dałoby się zadzwonić czy napisać z prośbą o wyjaśnienie problemu. Wiedza na ten temat jest rozproszona. Na pudełku czy w licencji nie ma więc podanego konkretnego punktu kontaktowego, gdzie należy się zgłaszać w przypadku pytań czy wątpliwości.

Firma przebrnęła jednak przez etap wyboru dystrybucji, bazując na informacjach z różnych periodyków i z sieci. Zrobiła testową instalację na 10 stanowisk i wszystko ruszyło jak należy. Rozpoczęła więc instalację produkcyjną i ta instalacja... nie zadziałała. I tu zaczęły się schody. Spośród różnych osób, do których firmie udało się dotrzeć, każda twierdziła, że konfiguracja jest jak najbardziej poprawna. Wiele osób mówiło, że ma dokładnie takie same instalacje, które pracują poprawnie. Żadna z nich nie miała jednak więcej niż 50 końcówek.

Wreszcie, po odsyłaniu od jednego autora fragmentu kodu do innego, udało się odszukać właściwego człowieka. "Jestem autorem tego fragmentu i on nie ma prawa poprawnie działać w tej sytuacji. Nie przewidziałem takiej liczby końcówek i zakodowałem ją na jednym bajcie, przy czym najstarszy bit jest flagą poprawności, więc w tej konfiguracji ruszy tak naprawdę poniżej 128 klientów. Poprawka zajmie mi kilka dni, ale nie będę się mógł za to zabrać wcześniej niż za 2 tygodnie... Rodzice położyli mi szlaban na komputer za to, że się za słabo uczę. Zbliża się koniec semestru i jestem zagrożony z biologii" - wyjawił. Gdy w końcu twórca systemu odezwał się do nich z poprawką, instalacja na "brzydkim" Windowsie pracowała od kilku dni...

Już to jedno zdarzenie otworzyło mi oczy na potencjalne problemy związane z wdrożeniami oprogramowania open source. Jednak jak na zamówienie zadzwonił do mnie dawno niesłyszany kolega i zapytał, czy znam kogoś, kto mógłby mu pomóc. Problem dotyczył budowy klastra obliczeniowego. I sytuacja była niemal identyczna jak we wcześniejszym przypadku. Klaster działał poprawnie w konfiguracji do kilkudziesięciu komputerów, ale przy stukilkudziesięciu zaczynały się kłopoty. I znów po wielu perypetiach właściwy autor został namierzony i z rozbrajającym uśmiechem odpowiedział, że nie ma bladego pojęcia, co się może dziać, bo w trakcie testów udało mu się zgromadzić w szkole niecałe pięćdziesiąt komputerów i taki był największy klaster przetestowany przez niego. I gdyby mógł zgromadzić kilkaset komputerów na kilka tygodni, to pewnie by sobie poradził z tym problemem.

Opisane przypadki nie są wcale wyssane z palca. Na konferencji OSCON w 2004 r. przykładem dużej instalacji PostgreSQL był serwer dwuprocesorowy, który w mojej firmie zostałby użyty wyłącznie jako maszyna dla podręcznej, małoznaczącej bazy danych. Na marginesie kwestii bazodanowych warto zwrócić uwagę, że darmowa wersja Microsoft SQL Server 2000 oferuje możliwości porównywalne do baz SQL open source (podobnie zresztą jest z Oracle i DB2). Tak więc przewaga produktów otwartych - polegająca na możliwości bezpłatnego ich używania - jest bardzo iluzoryczna.

Chęć czy obowiązek

Mając w pamięci opisane wcześniej przypadki, zacząłem się zastanawiać, jakie trudności organizacyjno-mentalne stoją przed szefem działu IT odpowiedzialnym za poprawne funkcjonowanie systemu bazującego na modelu open source w porównaniu z modelem komercyjnym. Dla uproszczenia rozważań skróciłem łańcuch powiązań między autorem a użytkownikiem końcowym do jednego tylko ogniwa. Wydłużanie tego łańcucha tak naprawdę nie wpływa bowiem na zmniejszenie ryzyka funkcjonowania analizowanego fragmentu systemu, ponieważ nie zachodzi tu żaden rodzaj jego dywersyfikacji. Oczywiście, można wydzielać coraz mniejsze fragmenty systemu i zlecać ich obsługę coraz większej liczbie firm outsourcingowych, specjalizujących się w tych fragmentach. Załóżmy jednak, że analizujemy fragment systemu, którego nie da się już podzielić na mniejsze i niezależne części - nasze rozważania zupełnie na tym nie ucierpią.

Pierwszą kwestią, nad którą należy się zastanowić, jest wsparcie producenta. Kupując system od firmy, która go tworzy, możemy mieć pewność, że producent jest w stanie dotrzeć do źródła błędu i go skorygować (pod warunkiem wszakże, że zawrzemy taki zapis w umowie). W przypadku dużych producentów, takich jak Microsoft, Sun czy IBM, czas reakcji może być dość długi, ale najczęściej wynika on ze złożoności produktu. Mamy jednak nadzieję (historycznie uzasadnioną), że producent zastosował odpowiedni system tworzenia kodu i jest go w stanie poprawić na podstawie zaobserwowanych objawów.

Zupełnie inaczej ma się sprawa z dystrybucją pakietu tworzonego w modelu open source. Często spora część kodu jest pisana poza firmą przez programistów robiących to dla przyjemności, po godzinach pracy. Można mieć nadzieję, że firma tworząca dystrybucję zna kod na tyle dobrze, że jest w stanie zlokalizować miejsce powstawania błędu, ale czy jest go w stanie poprawić - co do tego pewności już nie ma. Osoba odpowiedzialna za fragment kodu może pracować u producenta dystrybucji, albo też nie. Może trzeba dopiero poszukać autora wątpliwego fragmentu i skłonić go do poprawki, która wyeliminuje zaistniały błąd?

Pojawia się jednak pytanie, jak go do tego skłonić, jeśli człowiek ten pracuje za darmo? Co zrobić, jeśli znudziła mu się taka praca, rodzice zabronili mu dostępu do klawiatury przez miesiąc? Biznes nie może według mnie opierać się na dobrej woli ludzi pracujących za darmo. Co by się bowiem zdarzyło, gdyby autorem kodu był jakiś antyglobalista, który nie poprawi błędu, jeśli usłyszy, że ujawnił się on w sieci McDonald's? Tak na marginesie, podobno anty- i alterglobalistów jest statystycznie więcej wśród programistów tworzących oprogramowanie open source, niż wśród innych informatyków.