Rozterki formalne

Pójdźmy krok dalej. Może najlepiej byłoby zatrudnić człowieka, który jest autorem kodu open source, by mieć pewność, że pomoże nam w krytycznej sytuacji? Tu jednak mogą pojawić się wątpliwości na gruncie obowiązków pracowniczych. Jeśli bowiem zatrudniamy autora kodu otwartego jako administratora, to nie możemy od niego wymagać poprawiania kodu w godzinach pracy, bo to nie należy do jego obowiązków.

Aby obejść ten problem, możemy zatrudnić autora po to, żeby w czasie godzin pracy tworzył kod i udostępniał go do ogólnego użycia. Jest jeden problem: już widzę się przed biurkiem swojego prezesa, tłumaczącego mu, że zatrudniamy doskonałego programistę, który większość czasu będzie spędzał na pisaniu programu, z którego użytek może zrobić konkurencja. Cały czas się zastanawiam, czy najpierw wywali z hukiem tylko programistę, czy od razu nas obu.

Może więc zatrudnić pracownika, który w ciągu pracy tworzy aplikacje dla potrzeb firmy, w której pracuje, a wieczorami - w ramach odpoczynku - pisuje sobie fragmenty systemu, który używamy, tyle że bezpłatnie? Przez wiele lat myślałem, że taki model pracy może się doskonale sprawdzać. Myślałem tak, bo prowadziłem własną działalność, w której efektywny czas spędzony przy komputerze w ramach pracy oscylował między dwoma i trzema godzinami w tygodniu. Po takiej pracy mogłem sobie odpoczywać, pisując artykuły czy programy, które rozdawałem za darmo (albo niemal bez opłat), ku tzw. mołojeckiej chwale.

Teraz, nawet gdy uda mi się skończyć dzień pracy już po ośmiu godzinach, to komputer jest ostatnim urządzeniem, które mogłoby mnie zainteresować jako forma rozrywki. I mam uwierzyć, że mój pracownik będzie miał inne podejście? Będzie po wyczerpującym dniu pracy ruszał do kolejnej, tyle że darmowej roboty? A jak przyjmę informację, że dziś mu nie idzie? Zinterpretuję to tak, że w nocy mocno się wyeksploatował, tworząc coś za darmo, a w pracy musi sobie po tym wysiłku odpocząć. W dniach, w których będzie intensywnie pracował, mogę mieć ochotę (jakkolwiek naprawdę staram się tego unikać w swojej pracy) zajrzeć mu przez ramię, czy kod, który tworzy, jest naprawdę kodem związanym z działalnością naszej firmy. Czy to pomoże?

W sidłach widzimisię

Wróćmy więc do ewentualnej dywersyfikacji działania związanej z obsługą systemów open source. Może jednak zamówić wdrożenie i serwisowanie takiego systemu w firmie, która się w tym specjalizuje i ma doświadczenie? No dobrze, ale jakie są zalety takiego rozwiązania w stosunku do zakupu jakiegoś systemu u tzw. normalnego producenta. W końcu też polegam na grupie ludzi, od których zależy, czy mój system będzie działał sprawnie, czy nie. Na sumie ich wiedzy, doświadczeń i dobrej woli, wspartej pieniędzmi przeznaczanymi na poszukiwanie najlepszych rozwiązań.

W czym pieniądze wydawane na szukanie i scalanie darmowych rozwiązań w większą całość są lepsze od wydawanych na bezpośrednie tworzenie porównywalnej całości? Poza tym z punktu widzenia większej firmy zawsze może istnieć niebezpieczeństwo, że mechanizmy służące biznesowi korporacyjnemu nie zostaną w darmowym oprogramowaniu zaimplementowane, np. ze względu na niską popularność systemu w korporacjach (i małą próbkę doświadczalną), albo też ze względu na niechęć twórców do rozwijania funkcjonalności w tym kierunku.

W końcu nawet ja jestem sobie w stanie wyobrazić, że robię coś za darmo, żeby przeciętny Kowalski czy Wiśniewski nie płacił Microsoftowi pieniędzy, których on ma i tak na miliardy. Ale czy z taką samą chęcią będę ruszał do pracy, jeśli pomyślę sobie, że bank, który już zarabia na prowadzeniu mojego rachunku, zgarnie dla swoich właścicieli jeszcze więcej, dzięki temu, że ja nie będę spał po nocach?

Komórkowe olśnienie

Tu nastąpiła przerwa w pisaniu artykułu, która potrwała kilka tygodni. Wyniknęła z kolejnych problemów z systemem, nowym, superważnym projektem, który należało jak najszybciej uruchomić i wynikającym z tego wstrętem do jakiegokolwiek kontaktu z monitorem. Niniejszy artykuł trafiłby pewnie tam, gdzie wszystkie inne zaczęte teksty, których nie udało mi się nigdy dokończyć - gdyby nie to, że stale męczyło mnie pytanie: Dlaczego tak wiele znanych firm zaczyna upubliczniać kod swoich systemów? Co zyskują na tym, że rozdają za darmo coś, co jeszcze wczoraj kosztowało grube pieniądze?

Olśnienie pojawiło się niespodziewanie. Przyszedł do nas akwizytor jednej z sieci komórkowych i zaproponował nam najnowsze na rynku, wspaniałe, cudowne (kosztujące poza promocją znacznie ponad 1000 zł) telefony. Za darmo! Wtedy właśnie otworzyły mi się oczy - przecież idea tego biznesu jest dokładnie taka sama: "Dajemy wam za darmo system, ale liczymy, że to my będziemy was wspierać w jego eksploatacji". Istnieje co prawda niebezpieczeństwo, że klient pójdzie po wsparcie do konkurencji, ale też nadzieja, że pozyska się klienta od konkurencji.

Saldo wszystkich zachowań klientów w odpowiednio dużej próbie będzie dodatnie. A przy okazji istnieje szansa na pozyskanie zapaleńców, którzy bezpłatnie, w imię idei, pomogą w rozwoju "rozdawanego" oprogramowania. Oczywiście, nie potępiam takiego podejścia - w końcu żyć trzeba, a poza tym w młodości sam też robiłem wiele rzeczy z nadzieją, że zmienię świat. Tyle że takiemu działaniu daleko jest do dawnej romantyczności tworzenia pierwszych wersji Linuxa.

Romantyczne pułapki

Artykuł w zamierzeniu miał opisywać moje rozterki w dążeniu do użycia systemu typu open source - z nadzieją na pozytywne rozwiązanie dylematu. Długi czas jego powstawania oraz zdarzenia, które wystąpiły w tym okresie, doprowadziły mnie do wniosku, że w firmie, w której odpowiadam za informatykę, na otwarte oprogramowanie nie ma miejsca - choćby nawet we fragmencie potrzeb. Możliwe, że tracę szansę na skok naprzód, zyskuję jednak stabilizację.

Co zyskałbym dzięki owemu skokowi? Kiedy zaczynałem pisać ten artykuł, kupiłem dystrybucję Linuxa z najnowszą wersją jądra. Gdy właśnie go kończę, to jądro jest już przestarzałe i w zasadzie powinienem zastąpić je nowszym - najprawdopodobniej łącznie z drobnymi poprawkami i rekompilacją używanych wcześniej programów. Pytanie tylko, czy te programy po rekompilacji będą działały z nowym jądrem, tak jak działały wcześniej? Wersji Linuxa jest bardzo dużo i wiele jest programów wspierających biznes, które mają certyfikaty zgodności z nimi. Co się stanie, jeśli będę chciał używać i zintegrować dwa różne produkty, z których każdy został certyfikowany dla innej wersji Linuxa?

Kwestią otwartą jest także brak spójnej wizji przyszłości Linuxa - nie tylko w zakresie rozwiązań biznesowych, ale czasem nawet i technologicznych. Jest to często podnoszony zarzut w przypadku rozwiązań rozwijanych na bazie niezależnych zespołów o nieformalnej strukturze. W tym świetle ospałość zmian w systemie Windows, którego filozofia w sumie nie zmieniła się od ponad 20 lat, wydaje się być zaletą.

Przy okazji warto podnieść brak spójnego systemu wprowadzania poprawek w systemie. Obecnie po wykryciu błędu mogę potencjalnie ten błąd naprawić samodzielnie, dokonać rekompilacji systemu i użyć tej poprawki u siebie. Ale co się stanie, jeśli poprawka ta opublikowana przeze mnie nie przyjmie się i ktoś inny napisze lepszą, ale za to niezgodną z moją? Nastąpi rozszczepienie wersji, które może skutkować problemami.

W tym świetle mechanizm Windows Update, jakkolwiek niezbyt bezpieczny, może mieć swoje zalety. Kolejnym problemem może się okazać wydajność rozwiązań darmowych. Cóż się bowiem stanie, jeśli rozwiązania te będą przetwarzały dane trochę wolniej niż ich pełne wersje komercyjne (a słyszy się takie głosy w stosunku do darmowych baz SQL)? Czy konieczność zakupu lepszego sprzętu nie zniweluje przewagi bezpłatności oprogramowania?

Przy okazji warto też zwrócić uwagę, że niektóre statystyki (zarówno bezpieczeństwa, jak i popularności) są nie do końca prawdziwe. Nie tak dawno niemal sturlałem się ze śmiechu pod biurko czytając, że coraz więcej Polaków kupuje komputery z zainstalowanym systemem Linux, a nie Windows. Nikt nie zwrócił uwagi na fakt, że kiedyś kupowało się komputery bez systemu operacyjnego i jakimś cudem, bliskim cudowi nad Wisłą, te komputery pracowały zupełnie poprawnie. Podobnie jest ze statystyką ataków hakerskich czy wirusowych. Jest ich o wiele mniej, ale też liczba instalacji podlegających domniemanym atakom też jest mniejsza. Więc może gdyby przyjąć jakiś przelicznik liczby niebezpiecznych sytuacji na liczbę używanych systemów, to przewaga nie byłaby już tak powalająca?

Jednak rozważnie

Biorąc pod uwagę wszystkie skutki ciągłych zmian (w tym zmian idei) oraz kwestię przewagi technologicznej (która nie wszędzie występuje), dochodzę do wniosku, że mając tyle problemów na już znanym i opanowanym gruncie, naprawdę nie potrzebuję ściągać sobie na głowę dodatkowych kłopotów. Zwłaszcza że ideologiczna wyższość oprogramowania otwartego nad zamkniętym jakoś mi po drodze wyparowała. A w dobie bezpłatnych ograniczonych wersji komercyjnych również przewaga finansowa tego rozwiązania nie jest już taka oczywista.

Ale mimo tego nieoczekiwanego, nawet dla mnie, zwrotu, nie zamierzam zmieniać swoich przyzwyczajeń. Dalej będę twierdził, że oprogramowanie otwarte jest dużo lepsze od obecnie używanego. I tylko zła wola mistycznych "onych" nie pozwala mi z niego korzystać w rozwiązaniach biznesowych.