Nie pracuję w firmie Microsoft. Jednak, gdy przeczytałem, że 'filozofia systemu Windows nie zmieniła się od ponad 20 lat', postanowiłem sprawdzić fakty i stanąć w obronie producenta słynnych Windows.

Szybko dokonałem obliczeń - no tak, mamy rok 2005, a więc mowa o 1985 r.! Ponieważ spędziłem już parę lat na tym najwspanialszych ze Światów, zacząłem sprawdzać w pamięci - rzeczywiście, pierwsze Windowsy to połowa lat 80., ale twierdzić, że filozofia tego systemu nie zmieniła się od tego czasu - to obraza dla jego twórców! Jak można porównywać dość prymitywną nakładkę na DOS-a ze współczesnym wielozadaniowym systemem operacyjnym Windows XP? Przecież nawet w wersji 3.0 (uznawanej za pierwszą nadającą się do użytku) system Windows ignorował istnienie protokołu TCP/IP, a tym samym Internetu...

W swym artykule "Rozważnie czy romantycznie" Marek Wierzbicki (CW 31/2005) stara się udowodnić tezę, że "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".

Gdzie jest gwarancja?

Zaprezentowany tekst jest jednak pełen wewnętrznych sprzeczności. Rozpoczyna się opisem przyczyny, dla której zainteresował się możliwością wdrożenia open source: "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". I dalej: "fragment systemu okazał się dziurawy jak ser szwajcarski, a łatka systemowa pojawiła się później niż atak ją wykorzystujący" (cytat jest dosłowny). Czyżby ten system był oparty o open source? Z lektury artykułu wynika, że na pewno nie...

Jak to? A gdzie gwarancja? Kto poniósł odpowiedzialność za zatrzymanie systemu? Dlaczego potrzebne były "żmudne i nie wiadomo, czy do końca skuteczne próby zażegnania problemu"? Przecież na pudełku znajdował się zapewne numer telefonu do działu wsparcia technicznego (którego oczywiście brak na pudełku z Linuxem...). Dlaczego nie ma pewności, że problem rozwiązano skutecznie? Co na to dział wsparcia producenta?

I to właśnie krach komercyjnego oprogramowania stał się dla Marka Wierzbickiego impulsem do wykazania, że w przypadku open source zapewne byłoby jeszcze gorzej... Na poparcie tej tezy trzeba szybko podać efektowne przykłady - choćby rzekomego ucznia, który jest autorem błędnego kodu, ale nie może go teraz poprawić, "bo rodzice założyli mi szlaban na komputer ponieważ jestem zagrożony z biologii...". Przecież program był zapewne dostarczony z kodem źródłowym! Z lektury tekstu wynika, że wiadomo było, na czym polega błąd. Dlaczego więc go po prostu nie poprawiono, a czekano aż uczeń zda poprawkę z biologii?

Dalej Marek Wierzbicki roztacza katastroficzne wizje związane z brakiem testów w wielkich instalacjach - m.in. powołuje się na przykład klastra obliczeniowego, który "nie chciał" działać, bo "Autor jego oprogramowania nie mógł w szkole zebrać tylu komputerów naraz". No tu już całkiem przesadził, bo dziedzina klastrów obliczeniowych to właściwie nieprzerwane pasmo sukcesów Linuxa i open source - od NASA i Sandia Labs po gdański TASK i inne systemy działające także w Polsce. Wystarczy sprawdzić w Internecie lub na liście najszybszych komputerów świata.

Jak wynika z dalszej części artykułu wdrażania systemu opartego o open source nawet nie rozpoczęto, ponieważ w wyniku przeprowadzonej analizy potencjalnie możliwych niepowodzeń stwierdzono, że lepiej będzie pozostać przy dotychczasowym rozwiązaniu opartym na oprogramowaniu komercyjnym. Tak więc w założeniu bardzo ciekawy materiał, w którym mógłby znaleźć się opis napotkanych problemów, stał się zbiorem subiektywnych opinii niepopartych żadnymi konkretnymi własnymi doświadczeniami.

Zasadniczą część artykułu zajmuje dyskusja organizacji wsparcia technicznego dla oprogramowania. Autor stara się wykazać, że model open source wyklucza całkowicie możliwość świadczenia profesjonalnego serwisu. Nie mogę się zgodzić z taką opinią.

Na pomoc!

Świadczenie gwarancji i wsparcia technicznego zarówno w przypadku programów komercyjnych, jak i open source nie jest proste i wymaga znakomitej organizacji. Przez około dwa lata prowadziłem tzw. Authorised Support Centre dla jednej z największych firm dostarczających oprogramowanie systemowe. Podstawowym problemem, z jakim się wówczas borykałem, był dostęp do dokumentacji technicznej oprogramowania (nie mam bynajmniej na myśli podręczników użytkownika lub administratora), a bez dostępu do takiej dokumentacji kompetentne wsparcie techniczne jest właściwie niemożliwe. Pozostaje korzystanie z baz wiedzy (są oczywiście różne ich poziomy i autoryzacje dostępu), które zawierają odpowiedzi na typowe pytania. Jeśli odpowiedzi tam nie było, należało opisać problem i zgodnie z procedurą przekazać go "wyżej". Po około tygodniu nadchodziła zazwyczaj mniej więcej taka odpowiedź "problem (w tym miejscu oczywiście był długi numer) was reported to engineering department. It will be solved soon" (znaczyło to mniej więcej to samo, co słynne maniana lub bokra...).

Na zupełnie przeciwnym biegunie postawiłbym nieistniejącą już firmę XYLOGICS. Dostarczała ona kompletną dokumentację do swych serwerów komunikacyjnych. Co prawda zawierała ona ponad 600 stron, ale wraz z kodami źródłowymi oprogramowania (tak, one też były załączane) umożliwiała (pod warunkiem, że ktoś chciał do niej zajrzeć) szybkie rozwiązanie nieomal każdego pojawiającego się problemu.

I tu dochodzimy do sedna.

Niezależnie od tego, na jakich zasadach jest rozwijane oprogramowanie, to bez odpowiedniej dokumentacji nie może być ono właściwie serwisowane. Oczywiście można korzystać z odtwarzacza DVD i nie mieć pojęcia o modulacji impulsowo-kodowej oraz można korzystać z komputera, nie mając pojęcia o tym, czym jest system operacyjny. Jeśli wszystko idzie dobrze - nie będzie problemu. Jeśli jednak coś pójdzie źle - pozostaje zawołać fachowca. A fachowiec bez schematu i narzędzi może być bezradny. Przyznaje to sam Autor artykułu - to przecież niepewność, czy skutecznie zlikwidowano przyczynę krachu komercyjnego systemu stała się przyczyną jego zainteresowania open source. Jednym słowem coś jednak zazgrzytało w systemie wsparcia technicznego stosowanego oprogramowania, zaś narzędzia, które wykorzystano podczas naprawy awarii, lub braki w dokumentacji technicznej spowodowały, że nie udało się uzyskać pewności, że przyczyna defektu została ostatecznie usunięta.