Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak zarabiać na open source? O monetyzacji pracy

Mateusz Jarosz Redakcja Bulldogjob
Poznaj najpopularniejsze modele spieniężenia open source oraz jak ocenić ryzyko tej operacji.
Jak zarabiać na open source? O monetyzacji pracy

Trudno sobie współcześnie wyobrazić rozwijanie oprogramowania i usług bez użycia komponentów open source. Słynne porównania Linuksa do nowotworu, autorstwa Steve Ballmera, zostały wręcz ośmieszone przez czas, zaś dziś szefowany niegdyś przez niego Microsoft ma niebagatelny wpływ na pracę nad wieloma wolnymi narzędziami, a także coraz częściej udostępnia kod własnych rozwiązań.

Największe korporacje mogą sobie jednak pozwolić na takie działania bez większego wysiłku, między innymi gdyż świetnie zarabiają na tym w swoich usługach chmurowych. Trudno sobie wyobrazić Amazon Web Services czy Microsoft Azure, gdyby nie oprogramowanie rozwijane przez lata pro bono. 


Zupełnie sytuacja ma się jednak w przypadku mniejszych zespołów deweloperskich czy samotnych wilków, którym rozwijanie kodu z czystej pasji czy też dla idei często oznacza dodatkową nieodpłatną pracę po godzinach spędzonych w firmach rozwijających soft komercyjny. Nie zawsze musi tak być – przyjrzyjmy się zatem metodom dającym możliwość zarabiania na pracy nad wolnym oprogramowaniem.


Ocena ryzyka 

Nie ma wątpliwości, że zmiana licencji oprogramowania dotąd komercyjnie na licencję open source wiąże się dla zespołów deweloperskich czy nawet małych software house’ów ze znaczącym ryzykiem biznesowym. Decyzja musi być więc poprzedzona jego analizą, a do tego przydatna może być ocena w zakresie czynników określających opensource’owy potencjał projektu. 


Popularność i społeczność

Według Ajaya Kulkarniego, współzałożyciela i dyrektora wykonawczego firmy rozwijającej popularne oprogramowanie bazodanowe Timescale, sukces przedsięwzięcia zależy w pierwszej kolejności o jego popularności czy też zasięgu. Według Kulkarniego najważniejszym czynnikiem w zakresie spieniężania projektu open source jest duża baza użytkowników oraz społeczność. Ma to być warunek podstawowy, gdyż firmy rozwijające wolne oprogramowanie są w stanie uzyskać za jego rozwój jedynie małą część jego faktycznej wartości. 

Współczynnik konwersji wartości oprogramowanie na zysk ma jednak rosnąć proporcjonalnie właśnie do liczby użytkowników i wielkości społeczności. To właśnie skala popularności i aktywność użytkowników miała się przełożyć na komercyjne sukcesy największych opensource’owych przedsięwzięć. To także czynniki, które mogą zachęcić do inwestycji dużych graczy. Tak się na przykład stało z Kubernetes i Google, a przykład można mnożyć.


Zasada primary credibility

Drugim ważnym czynnikiem według Kulkarniego jest tzw. zasada primary credibility. Jest ona nie mniej ważniejsza o zasięgu danego projektu, gdyż ma bezpośrednie przełożenie na procesy marketingowe i nie mniej niż popularność zwiększa współczynnik konwersji. Primary credibility oznacza w tym przypadku działania zmierzające do tego, aby klienci w pierwszej kolejności zwracali się w pierwszej kolejności do firmy produkującej oprogramowanie open source.

Dlaczego to tak ważne? Budowanie wiarygodności i solidności projektu ma kluczowe znaczenie dla spieniężania. Dziś primary credibility osiąga się przede wszystkim przez wkład w całe przedsięwzięcie firmy, która patronuje nad projektem. Wystarczy wziąć przykład Google i przeglądarki Chromium. Co prawda Chromium jest oprogramowaniem wolnym, ale Google, za sprawą tego, że ma zdecydowanie największy wkład w rozwój tej przeglądarki, jest w stanie efektywnie ją spieniężać dzięki Google Chrome.

Podobnie jest z firmami w większej mierze skupiającymi wyłącznie na rozwoju wolnego oprogramowania, m.in. z Elastic czy MongoDB. Dzięki utrzymaniu zasady wiarygodności firmom tym się udało – mimo tego, że rozwijali swoje produkty pod wolnymi licencjami – zachować kontrolę nad projektem i najważniejszy głos w określaniu kierunku jego rozwoju. To umożliwiło im podejmowanie decyzji w budowaniu elastycznych modeli spieniężania, o których więcej za moment.


Strip mining

Do listy zagrożeń wymienionych przez współtwórcę TimescaleDB należy dodać nowe, którego zresztą sam Kulkarni stał się poniekąd ofiarą. Chodzi o zjawisko strip miningu, które wynika z niedostatecznej ochrony wolnych licencji (tych oficjalnie zaakceptowanych przez Open Source Inititative, która ma w tej kwestii decydujący głos) przed apetytem dużych komercyjnych graczy, którzy śmiało eksploatują (stąd termin strip mining odnoszący się do kopalni odkrywkowych) wolny kod i sprzedają efekty pracy firm open source i społeczności w swoich usługach.

Bodaj najśmielej na tym polu poczyna sobie Amazon. Między innymi w stosunku do produktów wspomnianej już firmy Elastic. Po tym jak twórcy m.in. Elasticsearch zdecydowali się na zmiany w licencjach (produkty są bardzo popularne w AWS, z czego Elastic nie czerpie zysków), Amazon postanowił… utworzyć fork rozwiązań Elastic i rozwijać własną wersję na potrzeby Amazon Web Services. Rzecz jasna jest to całkowicie legalne i zgodne z licencją. Nie brakuje nawet głosów, że to Amazon zdecydował się zachować opensource’owy charakter produktów Elastic, zaś zmiany w licencji produktów Elastic nie są zgodne z założeniami, którymi kieruje się Open Source Initiative. 

Sprawa jest złożona, z podobnymi problemami boryka się MongoDB czy właśnie Timescale, i zapewne jeszcze wiele wody upłynie, zanim zapisy licencyjne i relacje dostawcami dużych usług chmurowych zostaną uporządkowane. Jest to jednak ryzyko, którego z całą pewnością świadomy powinien być zespół chcący rozwijać produkt na wolnej licencji.


Najpopularniejsze modele spieniężania open source

Same modele spieniężania podzielimy na potrzeby naszego omówienia na dwie grupy. W pierwszej z nich, a zatem w niniejszej publikacji wskażemy metody monetyzacji wolnego oprogramowania o długiej tradycji i solidnej pozycji na rynku. Są to takie modele biznesowe, które firmy wykorzystują z sukcesami od wielu lat, i której skuteczności dowiódł sukces wielu z nich. 

W drugim artykule z niniejszej serii skupimy się na rozwiązaniach bardziej nowatorskich, które zdobyły popularność w ciągu ostatnich lat, co wynikło między innymi w wyniku gigantycznej ekspansji usług chmurowych kosztem rozwiązań on-premises.


Open-core

Model open-core przebojem wkroczył w światek open source i dziś jest z powodzeniem wykorzystywany w wielu projektach. Jak wskazuje sama nazwa, zakłada on rozdzielenie kodu oprogramowania na funkcje rdzenne, odpowiadające podstawowej funkcjonalności oraz pozostałe, które roboczo możemy nazwać możemy funkcjami dodatkowymi, niemniej w określonych zastosowaniach mogą one się okazać kluczowe dla specyficznych klientów. Jak nietrudno się domyślić, to właśnie ten element będzie kluczowy w spieniężaniu produktu.

Open-core zakłada bowiem, że „rdzenna” część kodu udostępniania jest na wolnej licencji, za darmo. Rzeczone funkcje „dodatkowe” są już jednak objęte licencją własnościową i za dostęp do nich trzeba płacić ich producentowi. Ogromną zaletą (ale też wyzwanie, o czym za moment) stanowi elastyczność tego modelu. To twórcy decydują o tym, jakie funkcje mają stanowić opensource’owy rdzeń, a które udostępniane będą odpłatnie. 

O sukcesie monetyzacji w modelu open-core może więc zdecydować ich odpowiednia identyfikacja – z jednej strony pochylić należy się w stronę społeczności, która nadal powinna mieć możliwość dostępu do wolnego oprogramowania w zastosowaniach niekomercyjnych. Potencjał tkwi w takim zrównoważeniu funkcji rdzennych i dodatkowych, aby zachowując opensource’owy charakter całego przedsięwzięcia, potrafić zarabiać na dużych klientach komercyjnych. 

Rzecz jasna selekcja ta wynika ściśle z charakteru i zastosowań danego rozwiązania. Trudno wszak oczekiwać, by tymi samymi czynnikami mieli się kierować twórcy niszowego rozszerzenia do pakietu Office i twórcy rozbudowanego oprogramowania serwerowego. Można jednak założyć, że duży klienci biznesowi potrzebować będą możliwości skalowania rozwiązania na dużą liczbę instancji, czy to stacji roboczych, serwerów, czy maszyn wirtualnych. Ten przykład dobrze obrazuje, jak efektywnie wykorzystywać model open-core.


Wsparcie, szkolenia i programy certyfikacyjne

Spieniężać można oczywiście nie tylko samo oprogramowanie. Przychody mogą zapewniać także usługi towarzyszące, np. pomoc techniczna. To bodaj jeden z najstarszych modeli spieniężania oprogramowania open source. W tym przypadku całość kodu pozostaje udostępniana na wolnych licencjach i nie ma tu żadnych ograniczeń w funkcjonalności, dostępności czy limitów wdrożeniowych. W takich przypadkach klient otrzymuje jednak wyłącznie samo oprogramowanie.

Gdy jednak zdecyduje się na pomoc ekspertów z zespołu rozwijającego dany produkt, będzie musiał za to zapłacić. Oczywiście wsparcie czy pomoc techniczną można rozumieć dowolnie szeroko – nie chodzi bowiem tylko o rozwiązywanie bieżących problemów, lecz w zasadzie o wsparcie na każdym etapie eksploatacji rozwiązania. Zarabiać można więc między innymi na wdrażaniu oprogramowania w środowisku danej organizacji, dostosowywaniu konfiguracji do konkretnych potrzeb czy optymalnym wykorzystaniu dostępnych zasobów. Pole do popisu jest więc pokaźne.

Model ten może także pomóc spieniężać oprogramowanie za sprawą współczesnych kanałów komunikacji z klientem czy narzędziami zdalnego dostępu. Wykorzystać można na przykład frameworki pozwalające na tworzenie zaawansowanych, inteligentnych botów, które pozwolą całkowicie zautomatyzować pomoc z najczęściej występującymi komplikacjami. 

W pewnym sensie w związku ze świadczeniem usług dodatkowych wyrasta kolejny model spieniężania oprogramowania open source. Oprócz bezpośredniego wsparcia można także uruchomić program szkoleniowy dla pracowników firm wdrażających nasze rozwiązanie bądź serii webinarów wprowadzający ich w tajniki konfiguracji. Może to być zachęcające dla tych klientów, którzy zamiast płacić za wsparcie jako za usługę, wolą wziąć udział w jednorazowym cyklu szkoleń i następnie sami zarządzać środowiskiem. 

Oprócz szkoleń do dyspozycji jest także możliwość uruchomienia programu certyfikacji, zupełnie jak to się odbywa na przykład na gruncie produktów i usług Microsoftu. Warto jednak zauważyć, że zarówno utrzymanie efektywnego programu szkoleniowego, który będzie spełniał oczekiwania końcowych użytkowników, jak i programu certyfikacji może okazać się wyzwaniem, jeśli nasz produkt będzie docierał do większego grona użytkowników.


Hosting

Większość klientów miała się okazję przekonać, jak wygodne w zarządzaniu są produkty i usługi działające na infrastrukturze producenta. Zapewne nigdy nie dojdzie do tego, ze chmura całkowicie zastąpi rozwiązania on-premises. Wszak już dziś głos zyskują popularyzatorzy edge computingu czy po prostu zacierania granic między tym, co działa lokalnie a tym, co w chmurze. 

Możemy być jednak przekonani, że także w Polsce klienci coraz chętniej będą decydować się na delegowanie odpowiedzialności za utrzymanie (i bezpieczeństwo!) na dostawcę usługi. A to świetna okazja do tego, by spieniężyć, rzecz jasna także w przypadku oprogramowania. To może być bowiem całkowicie bezpłatne, zaś jego kod dostępny na wolnej licencji, niemniej klient może ponosić opłaty za wykorzystane zasoby. Może to być szczególnie interesujące dla tych organizacji, która nie dysponuje własnymi zasobami serwerowymi, bądź woli w całości outsource’ować jej utrzymanie. 


Monetyzacyjny patchwork

Rzecz jasna nie zachodzi konieczność decydowania się na jeden optymalny model. Wręcz przeciwnie, plan powinien zakładać utworzenie konglomeratu różnych metod dostosowany do specyfiki projektu. Ten monetyzacyjny patchwork można także uzupełnić o nieco bardziej nowatorskie metody spieniężania, które omówimy w drugiej części artykułu.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej