Jedną z głównych motywacji przyświecających firmom udostępniającym dotychczas zamknięte oprogramowanie na jednej z licencji open source jest zwiększenie popularności rozwijanego produktu, nawet kosztem utraty części bezpośredniego dochodu ze sprzedaży. Innym poważnym powodem otwarcia dotychczas "zamkniętego" kodu jest chęć przedłużenia jego obecności na rynku. Może to być interesujące rozwiązanie w sytuacji, gdy w związku z wprowadzeniem nowszej wersji przychody ze sprzedaży poprzedniej wersji spadają i jej dalsze pełne wspieranie staje się coraz mniej opłacalne. Nie oznacza to jednak, że wyznaczone cele zostają automatycznie osiągnięte dzięki udostępnieniu kodu. Sukces zależy od wielu czynników, począwszy od atrakcyjności produktu, skończywszy na właściwej komunikacji firmy ze społecznością potencjalnych użytkowników i deweloperów.

Niespełnione nadzieje

O tym, że upublicznienie kodu źródłowego nie jest gwarancją powodzenia, świadczą dwa bodaj najbardziej znane (oprócz Linuxa) projekty open source - Mozilla i OpenOffice. W obu przypadkach oczekiwania znacznie przewyższyły rezultaty, zaś zaangażowanie zewnętrznych deweloperów, zwłaszcza w początkowej fazie projektu, było znacznie mniejsze niż zakładano. Na oba projekty składa się ogromna ilość kodu, z którym muszą zapoznać się potencjalni deweloperzy. Na początku dokumentacja praktycznie nie istniała. Te i inne niedociągnięcia stworzyły barierę skutecznie opóźniającą wydanie pierwszych stabilnych wersji.

Borland zdecydował się udostępnić środowisku open source serwer baz danych InterBase. Decyzję podjęto przy sprzeciwie części kierownictwa firmy. Tak jak w przypadku Mozilli i OpenOffice, ogromna ilość złożonego kodu była dosyć wolno analizowana przez osoby zainteresowane współpracą. Dodatkowo, po kilku miesiącach w kodzie znaleziono lukę bezpieczeństwa, co odbiło się głośnym echem w prasie fachowej i wywołało zarówno pozytywne, jak i negatywne komentarze. Ostatecznie osoby zainteresowane zmieniły nazwę produktu na Firebird i dla firm korzystających z technologii Borlanda jest to dziś atrakcyjną alternatywą dla InterBase.

Korzyści lub straty spowodowane uwolnieniem kodu InterBase dla wyników finansowych Borlanda trudno określić jednoznacznie.

SAP udostępnił silnik bazodanowy SAP DB na licencji GPL głównie po to, by zapewnić klientom kupującym główny produkt ciągłość rozwoju alternatywy dla Oracle'a. SAP DB jest całkiem atrakcyjnym systemem zarządzania bazami danych z niespotykaną w świecie open source liczbą narzędzi pomocniczych. Mimo to serwer ten nie uzyskał tak dużej popularności jak oczekiwano - być może ze względu na złożoność procesu budowania wersji binarnej.

Sybase udostępnił na licencji open source kompilator Watcom (Open Watcom) - niegdyś niezwykle popularny produkt Powersoft. W tym przypadku największą bolączką był przedłużający się w nieskończoność (ponad 3 lata) proces udostępniania, w tym weryfikacji praw Sybase do udostępniania kodu. Open Watcom jest obecnie produktem przestarzałym, znacznie mniej atrakcyjnym dla masowego odbiorcy niż byłby kilka lat temu.

Najpierw uchyl, potem otwieraj

Z przedstawionych przykładów wynika, że do wzbudzenia zainteresowania środowiska programistów i klientów samo udostępnienie kodu nie wystarcza. Firma musi włożyć pewien, czasem nawet spory, wysiłek, aby uczynić go przystępnym. Przed udostępnieniem kodu warto zastanowić się nad długofalowymi konsekwencjami tego posunięcia. To, co producentowi oprogramowania może wydawać się atrakcyjne, nie musi się okazać interesujące dla środowiska open source. Kluczowym krokiem na drodze do udostępnienia kodu na zasadach open source jest analiza konsekwencji zastosowania konkretnej licencji. Decyzja w tym względzie może mieć kolosalne znaczenie dla przyszłości firmy.

<hr size=1 noshade>Dla Computerworld komentuje Adam Dawidziuk, przewodniczący powołanego przez ministra właściwego ds. informatyzacji Forum Rozwoju Wolnego Oprogramowania, prezes 7bulls.com sp. z o.o.

Z ręką na klamce

Przekazanie, bądź nie, kodu źródłowego wynika bezpośrednio z rodzaju relacji klient-producent. W pewnych sytuacjach jest to nieuniknione lub pomocne, w innych zaś bezcelowe lub niewskazane. Trudno o uogólnienia, można jednak wskazać pewne kierunki myślenia.

Nie przekazuje się kodu aplikacji o krótkim czasie "życia" i funkcjonalności, której opracowanie wymaga specjalistycznej wiedzy lub oryginalnego pomysłu. Przykładem jest tzw. oprogramowanie rozrywkowe. Gra przynosi dochód, jeśli spodoba się użytkownikom. Przekazywanie źródeł jest raczej niebezpieczne dla interesów producenta, a poza tym konsumenci nie mają takich roszczeń.

Inny skrajny przykład to tworzenie oprogramowania na zamówienie, wg specyfikacji funkcjonalnej dostarczonej przez klienta. Zdarza się, że kod tworzony na zamówienie jest niebanalny, np. z powodu wymagań wydajnościowych lub ograniczeń na wielkość plików binarnych - co oczywiście wymaga dodatkowych ustaleń dotyczących przekazywania źródeł i praw do nich. Prawo autorskie chroni również rutynowo napisany kod źródłowy, ale próba czerpania korzyści z tego tytułu przybiera czasem formy patologiczne. W kontaktach uczciwego producenta ze świadomym klientem przekazanie takiego kodu odbywa się zwykle za drobną opłatą.

Przekazywanie praw do kodu źródłowego oprogramowania tworzonego na zamówienie podnosi konkurencyjność oferty producenta i coraz częściej bywa kluczem do zdobycia kontraktu. Strategia taka wymaga jednak budowania długoterminowych relacji z klientem w oparciu o jakość oprogramowania i wsparcia technicznego. Jest to istotna zmiana w stosunku do dotychczasowych formalnych relacji rynkowych. W jej rezultacie firmy niepotrafiące zaoferować wysokiej jakości wsparcia po wdrożeniu są w długim okresie skazane na niebyt.

Decyzja o dostarczeniu kodu źródłowego powinna być podejmowana przed tworzeniem oprogramowania. Otwieranie źródeł produktów zamkniętych bywa procesem trudnym i kosztownym. Oprogramowanie zamknięte to łatwiejszy proces produkcji, ale również poważne kłopoty dla inwestora, jeśli pojawią się bezpłatne odpowiedniki tworzone przez społeczność open source. Przy ocenianiu ryzyka związanego z wprowadzeniem nowego produktu zamkniętego na rynek podstawową sprawą jest dziś unikalność pomysłu i kompetencji potrzebnych do jego realizacji. Szanse mają wyłącznie najlepsi.

Całkowity brak przychodów z opłat licencyjnych w związku z upowszechnieniem się modelu open source - to, czego obawiają się dziś firmy żyjące z licencji - jest jednak sprawą dyskusyjną. Zwiększenie dostępności systemów informatycznych stymuluje inwestycje i wytwarza popyt na sprzęt, usługi oraz licencje (tak!). Beneficjentami zachodzących zmian będą jednak przede wszystkim ci najbardziej efektywni i innowacyjni.