Open source: co myślimy?
Open source: co myślimy?
Od momentu startu Cal.com dostaliśmy niezliczone wiadomości od założycieli, którzy pytali, czy open source to właściwy kierunek dla ich startupu, więc chcieliśmy opisać proces podejmowania decyzji o stworzeniu cal.com jako firmy open source, żeby pomóc innym podjąć podobną decyzję.
Wokół open source kręci się od 2021 sporo szumu, a niektóre magazyny technologiczne piszą o „renesansie open source”, ale chcemy się upewnić, że robisz właściwe rzeczy z właściwych powodów — albo przynajmniej zastanawiasz się nad swoimi powodami.
Ostatnio dostawaliśmy całkiem często podobne wariacje powyższego pytania (przez rozwój i zasięg cal.com), dlatego chcieliśmy napisać wpis wyjaśniający, jak myślimy o SaaS vs open source i kiedy warto otworzyć projekt.
Mimo że oboje korzystaliśmy wcześniej z wielu projektów open source i ogromnie ceniliśmy ich pracę, żadne z nas nie uważa się za zagorzałego fana open source. Cal.com to pierwszy projekt OSS, przy którym pracował którekolwiek z nas, bo wszystkie projekty, przy których pracowaliśmy wcześniej, były closed source. Przez większość czasu był bardzo dobry powód, dla którego tamte projekty nie były open source.
Dlaczego w ogóle zbudowaliśmy Cal.com?
Kiedy Peer pracował nad swoją poprzednią firmą, leanhire.com, uznał, że bardzo potrzebują mocniejszego narzędzia do planowania.
W przeciwieństwie do typowego przypadku użycia, gdzie Peer albo jego pracownicy umawialiby spotkania (na przykład w sprzedaży czy rekrutacji), oni potrzebowali produktu do planowania dla swojego rynku rekrutacyjnego. W każdym rynku dwustronnym użytkownicy wchodzą w interakcje z innymi użytkownikami, co średnio pasuje do typowego modelu oferowanego przez istniejące produkty do planowania.
Narzędzia do planowania takie jak Calendly, SavvyCal i Motion to świetne produkty do umawiania spotkań. Jednak nie potrafią zapewnić infrastruktury planowania dla bardziej zaawansowanych zastosowań, takich jak rynki rekrutacyjne, telemedycyna i wiele innych. Na przykład, przy ponad 5,000 użytkowników, jak miał Peer w Lean Hire, nie byłoby wykonalne płacenie $19/miesiąc za każde miejsce.
Istniejące SaaS-owe produkty do planowania też nie dają wielu wglądów w to, co dzieje się wewnątrz. W onboardingu Lean Hire proszono wcześniej klientów, żeby po prostu skopiowali i wkleili swój scheduling link, a platforma automatycznie dodawała go do maili outreachowych. Ale gdy odbiorca kliknął w scheduling link, platforma Lean Hire nie miała możliwości śledzenia, co dzieje się dalej.
Nie wiedzieli, czy i kiedy wydarzenia się odbyły oraz czy zostały przełożone albo anulowane. Nie było sposobu, by zmienić workflow rezerwacji, projekt ani wywołania API wykonywane podczas rezerwacji. Potrzebne było więc otwarte, dostępne, rozszerzalne rozwiązanie, które mogli self-hostować.
Peer od razu wyszukał w Google „Calendly open source”, bo właśnie to oznacza open source: otwarte, dostępne, rozszerzalne i możliwe do self-hostingu.
Ku jego zaskoczeniu nie mógł znaleźć ani jednego projektu, który robiłby to, czego szukał Lean Hire. Nawiasem mówiąc, w tym samym czasie setki innych osób szukały dokładnie tego samego. Wątkami na forach, dyskusjami na Reddicie i nie tylko dzielili się ludzie pytający, czy istnieje open-source'owy produkt do planowania, który mógłby rywalizować z najpopularniejszymi rozwiązaniami SaaS.
Dlaczego zrobiliśmy Cal.com open source?
Od pierwszego dnia było dla nas oczywiste, że Cal.com będzie projektem open source. To, co chcieliśmy robić, było fundamentalnie trudniejsze jako zamknięty produkt SaaS niż jako open source.
Klucz jest taki, że ograniczenia istniejących produktów do planowania dało się rozwiązać tylko przez open source. Wiele założycieli idzie złą ścieżką, myśląc, że powinni zbudować open-source'ową alternatywę dla istniejącego produktu, zakładając, że ich produkt odniesie sukces wyłącznie dlatego, że jest open source. Zamiast tego powinieneś rozważać zrobienie projektu open source tylko wtedy, gdy open source naprawdę rozwiązuje wyzwania, które chcesz adresować (np. możliwość dostosowania, self-hosting). Jeśli oceniasz tę drogę, warto zrozumieć jak projekty open source przechodzą na modele closed source i co z czasem napędza takie decyzje.
Na przykład możesz zbudować open-source'ową alternatywę dla Twittera, ale mało prawdopodobne, że wystartuje, bo social networking nie korzysta tak naprawdę na byciu open source. Istnieje wiele projektów open source tylko po to, żeby były open source.
Jeśli jednak spojrzałbyś na branżę e-commerce, którą w dużej mierze dominują produkty SaaS jak Shopify czy BigCommerce, zobaczyłbyś, że open-source'owa alternatywa pozwoliłaby sklepom być self-hostowanymi, w pełni dostosowanymi i whitelabelowanymi oraz rozwijanymi w sposób, który nie jest możliwy przy closed-source'owym produkcie. To byłby dobry przykład, dlaczego warto otworzyć swój projekt.
Do tego przy każdym otwartym, dostępnym i darmowym oprogramowaniu są oczywiste i mniej oczywiste minusy. Open source ma wiele zalet, które pewnie znasz, ale open source nie jest pozbawiony swoich wad.
Monetyzacja
Komercyjne oprogramowanie open source (COSS) to modny model firmy, w którym podstawowy produkt jest open source, ale masz też ofertę komercyjną, która przynosi przychód. Takie firmy mogą rosnąć niesamowicie szybko. Z natury darmowego i otwartego oprogramowania wynika ogromna adopcja na początku. Deweloperzy kochają open source. Kochają możliwość zajrzenia do kodu, naprawienia prostych błędów, które ich irytują, albo ogólnie bycia pomocnym i oddania czegoś z powrotem. Kto nie lubi być pomocny?
Ale ogromny wzrost i tworzenie wartości mają swoją cenę: przechwytywanie wartości. Praktycznie każdy założyciel COSS, z którym rozmawiam, myśli o pojęciu tworzenia wartości i przechwytywania wartości.
Freemiumowy biznes SaaS ma dwóch klientów: darmowy poziom i płatny. I ten stosunek zwykle jest bardzo dobry. Na przykład:
„Webflow napędza ponad 100,000 stron internetowych dla firm dużych i małych." – https://webflow.com/customers
Najnowsza wycena Webflow podobno wynosi $2.1B.
Z kolei firma open source wygląda fundamentalnie inaczej, z masą osób self-hostujących i darmowych klientów, którzy czasem nawet nie wiedzą, że istnieje komercyjna firma stojąca za projektem.
Na przykład: WordPress obsługuje ponad 455 milionów stron internetowych od 2021 roku, a ta liczba wciąż rośnie.
„Spółka-matka WordPress.com, Tumblra i innych, Automattic, ogłasza nową rundę finansowania, podnosząc całkowitą wycenę firmy do 7.5 miliarda dolarów” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Gdyby Webflow napędzał 455 milionów stron internetowych — albo gdyby WordPress był scentralizowanym biznesem SaaS z ekonomią i mechanizmem przechwytywania wartości Webflow, to prawdopodobnie byłyby to największe firmy na świecie.
Bycie startupem COSS to w zasadzie gra długoterminowa. Nie zarobisz na ludziach, którzy self-hostują twój produkt u siebie, ale liczysz, że impet open source sprawi, że pojawisz się na radarze dużych firm, które mogłyby podpisać z tobą większą umowę.
Dlatego myślenie o runwayu twojej firmy jest ważne. Prawdopodobnie minie dużo czasu, zanim wystartujesz z firmą, zbudujesz produkt do poziomu, w którym będzie konkurencyjny wobec closed-source'owych alternatyw, potem zaczniesz budować traction i w końcu zaczniesz domykać duże deale. To oznacza, że jeśli nie masz finansowania, by dalej pracować nad produktem, gdy na początku generuje mało przychodu, możesz nie przechwycić wystarczającej wartości, by przetrwać.
Wkład społeczności
Jedną z ważnych korzyści open source są wkłady społeczności. Dostaliśmy od społeczności kilka świetnych kontribucji, za które jesteśmy niesamowicie wdzięczni. Niektóre z nich to drobne poprawki błędów, ale inne to duże funkcje.
Zazwyczaj, jeśli ludzie w firmie rozszerzają Cal.com pod własne potrzeby, na przykład żeby napisać integrację z Microsoft Exchange, to najpewniej wrzucą ten kod jako pull request, żebyśmy mogli mieć tę funkcjonalność w samym projekcie.
Większość inżynierów w naszym zespole to wcześniej osoby, które dokładały się do projektu w swoim czasie wolnym, co działa dla nas świetnie, bo od razu widzimy przykłady ich pracy, są już zaznajomieni z codebase'em i mają już pasję do pracy nad projektem.
Kradzież
Jednym z głównych minusów open source jest to, że kiedy twój kod jest swobodnie dostępny w internecie, ludzie zrobią podróbki twojego produktu i ukradną twój kod.
Mimo że mamy licencję AGPL i wszelkie modyfikacje kodu muszą zostać otwarte jako open source, wciąż są ludzie, którzy łamią te licencje i będą to robić dalej. Poza tym nic nie powstrzymuje jednego z naszych konkurentów przed zajrzeniem do naszego kodu i zobaczeniem, jak zbudowaliśmy funkcje, a potem przeniesieniem tego kodu do własnego closed-source'owego projektu. Jeśli zrobią to wystarczająco dobrze, nikt nie będzie wiedział, że to zostało skradzione, bo ich produkty są closed source.
Tak naprawdę nic nie możemy z tym zrobić, żeby to powstrzymać. Dlatego próbujemy mierzyć się z problemem podróbek Cal.com po prostu przez mocną, rozpoznawalną markę. Mamy nadzieję, że jeśli ktoś wziąłby kod Cal.com i stworzył własną podróbkę, to nie zyskałaby ona żadnej trakcji, bo ludzie wiedzą, że to podróbka, a społeczność zgłosiłaby to nam, żebyśmy mogli podjąć kroki prawne.
Na przykład kod źródłowy Twitcha został przejęty w 2021 roku, ale gdybyś próbował wziąć ich kod i zacząć robić podróbkę Twitcha, nigdzie byś nie zaszedł.
Więc czy powinienem zrobić X open source?
Jeśli sam zadajesz sobie to pytanie, to prawdopodobnie nie powinieneś tego robić. Jak wspomnieliśmy wyżej, zwykle jest bardzo oczywiste, czy potrzebujesz rozwiązania otwartego, dostępnego i rozszerzalnego, czy nie. Jeśli go nie potrzebujesz — nie rób z tego open source tylko dla samej idei.
Jeśli jednak chcesz sprzedawać do enterprise, do mocno regulowanych branż albo po prostu chcesz zbudować rozwiązanie dla ogromnej skali ludzi (455M WordPress vs 100,000 stron Webflow), to pójście w open source ma ogromny sens.
Dodatkowo upewnij się, że skupiasz się na budowaniu najlepszego produktu. Większości klientów tak naprawdę nie obchodzi, czy jesteś open source, czy nie.
Obchodzi ich najlepsza wartość za ich pieniądze. Open source bardzo pomaga w tworzeniu wartości: cykl feedbacku jest super szybki, członkowie społeczności naprawiają błędy, pomagają w tłumaczeniach i wielu innych rzeczach, ale nigdy nie zapominaj budować lepszego produktu niż twój konkurent SaaS.
Bo na końcu dnia to właśnie się liczy: zbuduj coś, czego ludzie potrzebują. Jeśli interesuje cię, jak nasze myślenie o open source dalej się rozwija, przeczytaj wiadomość od naszego założyciela o naszym kolejnym rozdziale.
Cal.com jest teraz DARMOWY dla osób prywatnych - zarejestruj się tutaj