Jak zarabia się na darmowym oprogramowaniu

To pytanie pada za każdym razem, kiedy tłumaczę klientowi, że oprogramowanie na jego nowym serwerze nic nie kosztuje. Skoro jest darmowe, to kto płaci ludziom, którzy je piszą, i co się ze mną stanie, kiedy przestaną? To dobre i sceptyczne pytanie, a uczciwa odpowiedź jest ciekawsza niż „darowizny".

Najczytelniejszy pojedynczy punkt: IBM kupił Red Hata, firmę, której cały produkt był złożony z oprogramowania możliwego do darmowego pobrania przez każdego, za około trzydzieści cztery miliardy dolarów. Ta transakcja zamyka teoretyczną część sporu. Jakikolwiek to model, nie jest dobroczynnością.

Co się właściwie kupuje

Nieporozumienie bierze się z założenia, że cena oprogramowania jest zapłatą za kod. Nie jest i nigdy tak naprawdę nie była. Jest zapłatą za pakiet: kod plus zapewnienie, że ktoś kompetentny go naprawi, plus ktoś odpowiedzialny, kiedy się zepsuje, plus gwarancja, że za pięć lat wciąż będzie utrzymywany.

Open source je rozdziela. Kod staje się darmowy. Cała reszta pozostaje rzadka, a cała reszta jest tym, za co organizacja mająca coś do stracenia faktycznie płaci. Bank nie kupuje systemu operacyjnego; kupuje czyjeś zobowiązanie do odebrania telefonu o trzeciej nad ranem.

To jest model Red Hata w jednym zdaniu i jest też, w zupełnie innej skali, moim. Nikt nie płaci mi za Nextcloud. Płacą mi, bo maszyna przyjeżdża skonfigurowana, bo dyski zostały przetestowane, bo backup już działa i bo jest osoba, do której można zadzwonić. To, że oprogramowanie jest darmowe, jest powodem, dla którego ten biznes może istnieć, a nie problemem, który musi obchodzić.

Modele, które działają, i co każdy kosztuje

Wsparcie i certyfikacja. Oprogramowanie jest darmowe; wspierana, przetestowana, gwarantowana na dekadę wersja nie. Działa tam, gdzie klient ma regulacyjne albo kontraktowe powody, żeby potrzebować kogoś odpowiedzialnego. To najtrwalszy model na tej liście.

Hosting. Ktoś to za Ciebie prowadzi. Oprogramowanie jest darmowe, a produktem jest jego prowadzenie. Tak zarabia spora część współczesnych firm software'owych, w tym kilka, których kod mógłbyś pobrać dziś po południu.

Open core. Baza jest otwarta, konkretne dodatki dla dużych organizacji nie — logowanie jednokrotne, logi audytowe, funkcje zgodności. Pragmatyczny i powszechny, a jednocześnie model z największym tarciem, bo granica między darmowym a płatnym z czasem się przesuwa, a użytkownicy zauważają, kiedy przesuwa się w ich stronę.

Zatrudnienie korporacyjne. Dużą część pracy nad kluczowymi projektami infrastrukturalnymi wykonują ludzie zatrudnieni przez firmy, którym zależy, żeby ta infrastruktura działała dobrze. Niczego nie sponsorują; utrzymują wspólną zależność, co jest tańsze niż utrzymywanie przez każdego z nich prywatnej kopii.

Fundacje. Neutralne organizacje trzymające znaki towarowe i infrastrukturę, finansowane przez firmy członkowskie, które chcą, żeby wspólna rzecz przetrwała bez kontroli którejkolwiek z nich. Nieefektowne i nośne.

Gdzie ten model naprawdę zgrzyta

Dwa tryby awarii, a zataiłbym je tylko wtedy, gdybym Ci coś sprzedawał.

Pierwszy to zmiany licencji. Kilka znanych projektów, po latach otwartego rozwoju i przy dużej bazie użytkowników, przeszło na warunki, które nie są już otwarte — zwykle po to, żeby powstrzymać dostawcę chmury przed sprzedawaniem ich oprogramowania jako usługi bez wnoszenia wkładu. Uzasadnienie bywa sympatyczne, a efekt dla użytkowników jest taki sam jak przy każdej innej zmianie warunków: rzecz, na której budowałeś, przestała być tym, na czym budowałeś. To najmocniejszy argument za preferowaniem projektów zarządzanych przez fundację, a nie przez jedną firmę, i mocno go ważę, wybierając, co postawić na maszynie klienta.

Drugi to rozkład pieniędzy, który jest mocno skrzywiony. Duże projekty infrastrukturalne z korporacyjnymi użytkownikami są dobrze finansowane. Małe biblioteki pod nimi — te, od których zależy każdy duży projekt, utrzymywane przez jedną czy dwie osoby po godzinach — często nie. Ta nierównowaga wyprodukowała realne incydenty i zasługuje na więcej niż akapit, dlatego ma własny tekst.

Co to znaczy dla Ciebie jako klienta

Jedna praktyczna rzecz. Wybierając oprogramowanie, sprawdź, jak projekt zarabia, bo to mówi Ci, co zrobi, kiedy będzie potrzebował pieniędzy. Projekt stojący za fundacją z członkami korporacyjnymi zachowuje się inaczej niż taki, który należy do spółki po rundzie inwestycyjnej i musi kiedyś pokazać zwrot. Żadne z tego nie dyskwalifikuje. Ale to drugie ma prawdopodobną przyszłość, w której warunki się zmieniają, a wiedza o tym z góry jest różnicą między decyzją a niespodzianką.

A odpowiadając na pierwotną obawę klienta: jeśli ludzie, którzy to piszą, przestaną, kod nie zniknie. Jest na Twojej maszynie, na licencji pozwalającej każdemu go kontynuować. To słabsza gwarancja niż umowa wsparcia i wyraźnie mocniejsza niż alternatywa, w której wygaszony produkt po prostu przestaje istnieć, a Tobie nigdy nie dano kopii czegokolwiek.