W lutym 2024 roku Fundacja Cloud Native Computing Foundation (CNCF) zdecydowała się zarchiwizować nasz projekt OpenEBS, stawiając nas przed trudnym wyborem: albo się poddaliśmy, albo postanowiliśmy naprawić wykryte problemy i ponownie ubiegać się o przyjęcie do CNCF Sandbox. Oczywiście, najłatwiej byłoby odpuścić, ale skoro co miesiąc nasz projekt przyciągał 25 000 nowych użytkowników, nie mogliśmy tego zrobić. Postanowiliśmy więc podjąć wyzwanie i odbudować projekt od podstaw.
W artykule przedstawię, dlaczego CNCF zarchiwizowało nasz projekt, jak naprawiliśmy problemy oraz jak te działania przyczyniły się do stworzenia opłacalnego modelu biznesowego.
Problem z własnością i kontrolą
Kluczowy problem, z którym się mierzyliśmy, dotyczył dość powszechnego wyzwania związanego z zarządzaniem projektami open source. Około 60% projektów wspieranych przez CNCF posiada korporacyjnego sponsora — firmę, która finansuje rozwój projektu. Kiedy taka firma przekazuje projekt CNCF, staje się on własnością tej fundacji, a sponsor traci nad nim formalną kontrolę. Mimo to, dopóki społeczność nie przejmie aktywnej roli w rozwoju projektu, to najczęściej pracownicy sponsora pozostają głównymi jego rozwijającymi. Wielu CEO błędnie zakłada, że skoro ich zespół nadal pracuje nad projektem, to oni wciąż mogą decydować o jego kierunku. Tego rodzaju napięcia między własnością a kontrolą doprowadziły do naszego zarchiwizowania, a bez ich rozwiązania problem ten wciąż by się pojawiał.
Jak zarabiać, sponsorując projekt CNCF?
Zdecydowaliśmy się zapytać CNCF, jak rozwiązać ten problem. Jednym z cennych źródeł wiedzy okazała się Grupa Doradcza ds. Strategii Wkładu (TAG) w ramach CNCF, z którą współpracowaliśmy. Jak wyjaśnił jeden z jej przewodniczących, Josh Berkus: „Założenie open source polega na tym, że można osiągnąć ogromną adopcję, a następnie generować przychody od części tych użytkowników, co może przynieść większe zyski niż sprzedaż oprogramowania o zamkniętym kodzie”.
Ten model działa szczególnie dobrze w przypadku skomplikowanego oprogramowania, które wymaga specjalistycznego wsparcia, takiego jak instalacje Kubernetes. Dla projektów takich jak Kubernetes zazwyczaj skuteczne strategie monetyzacji pochodzą z trzech kluczowych źródeł:
1. Wsparcie i usługi profesjonalne.
2. Specjalistyczne dystrybucje (np. posiadające certyfikaty branżowe lub integracje z platformami).
3. Produkty towarzyszące, które dostarczają usługi związane z operacją oprogramowania w środowisku produkcyjnym (np. narzędzia do zarządzania lub raportowania).
Mniej powszechny jest model „open core”, polegający na tym, że część funkcji pozostaje otwartoźródłowa, a reszta zamknięta, co ponownie wprowadza problem własności i kontroli.
Założyliśmy, że większość użytkowników naszego projektu nie zapłaciłaby za korzystanie z niego, gdyby było to warunkiem. To właśnie ta rozbudowana baza użytkowników jest kluczem, który pozwala na utwardzanie oprogramowania i budowanie jego wiarygodności. Dla większych firm i organizacji płacenie za wsparcie lub specjalistyczną dystrybucję jest atrakcyjne, ponieważ skraca to czas wdrożenia, zmniejsza ryzyko i stanowi jedynie małą część całkowitych kosztów projektu.
Przekazywanie własności i kontroli społeczności
Rozwiązanie problemów związanych z monetyzacją, które nie wymaga kontroli nad projektem, było pierwszym krokiem w odpowiednim kierunku. Jednak dopóki firma-sponsor pozostaje głównym zespołem technicznym projektu, napięcia dotyczące własności i kontroli nadal będą występować. W tym miejscu kluczowe okazało się wsparcie ze strony społeczności Kubernetes, która umożliwiła rekrutację nowych opiekunów projektu oraz inżynierów spośród użytkowników.
Dzięki temu projekt zyskał dodatkowe zasoby, a firma-sponsor mogła znacząco zmniejszyć koszty związane z utrzymywaniem projektu, co dało możliwość przeniesienia części inżynierów do rozwijania produktów towarzyszących. Budowanie społeczności wokół projektu wymagało jednak pracy — samo szerokie przyjęcie projektu nie oznacza automatycznie, że społeczność zaangażuje się w jego rozwój. Nasz zespół musiał dążyć do transparentności i inkluzywności, a także aktywnie uczestniczyć w szerszej społeczności Kubernetes, pomagając innym w osiągnięciu sukcesu z ich projektami.
Wynik
Dzięki zmianie strategii monetyzacji nasz projekt zyskał klientów, którzy płacą za wsparcie i usługi profesjonalne. Dopiero zaczynamy rekrutować nowych opiekunów i inżynierów, ale już widzimy ogromny potencjał, jaki daje współpraca z szeroką bazą talentów. Firma-sponsor może teraz przenieść część kosztów, a jednocześnie zwiększa się zdolność inżynieryjna projektu. Oddając kontrolę i własność społeczności, zyskujemy znacznie więcej w zamian. Gdy zakończymy ten proces, projekt naprawdę stanie się wysiłkiem całej społeczności.
Kubernetes został założony na zasadzie, że nikt nie powinien posiadać ani kontrolować platformy, na której opiera się przyszła infrastruktura. Wszyscy razem dzielimy odpowiedzialność za jego rozwój i przyszłość.
Proces ten jest czasem niezręczny czy bolesny. Czasem można zostać zarchiwizowanym i trzeba zacząć od nowa. Wolne oprogramowanie nie jest darmowe — musimy współpracować, aby je tworzyć, budować wokół niego społeczność, chronić je, a czasem nawet chronić je przed nami samymi.
