Open source: wat vinden we ervan?
Open source: wat vinden we ervan?
Sinds de lancering van Cal.com hebben we talloze berichten gekregen van oprichters die vragen of open source de juiste richting is voor hun startup, en daarom wilden we schrijven over het besluitvormingsproces achter het starten van cal.com als een open-sourcebedrijf, om anderen te helpen een vergelijkbare beslissing te nemen.
Er is sinds 2021 veel hype rond open source, en sommige techmagazines schrijven over de "Renaissance of Open Source", maar we willen ervoor zorgen dat je de juiste dingen doet om de juiste redenen – of op zijn minst even stilstaat bij je redenen.
We krijgen de laatste tijd behoorlijk vaak vergelijkbare varianten van de vraag hierboven (door de groei en aandacht voor cal.com), en daarom wilden we een bericht schrijven waarin we uitleggen hoe we denken over SaaS versus open source en wanneer je open source moet maken.
Ondanks dat we beiden veel open-sourceprojecten hadden gebruikt en het werk dat ze doen enorm waardeerden, zouden we onszelf geen doorgewinterde open-sourcefans noemen. Cal.com is het eerste OSS-project waaraan we allebei hebben gewerkt, omdat alle projecten waaraan we eerder hebben gewerkt closed source waren. Meestal was daar een heel goede reden voor.
Waarom hebben we Cal.com in de eerste plaats gebouwd?
Toen Peer aan zijn vorige bedrijf, leanhire.com, werkte, merkte hij dat dat dringend behoefte had aan een krachtigere planningstool.
In tegenstelling tot het typische gebruiksscenario waarin Peer, of zijn medewerkers, boekingen zouden maken (zoals in sales of recruiting), hadden zij een planningsproduct nodig voor hun hiring marketplace. In elke tweezijdige marketplace gaan je gebruikers met andere gebruikers om, en dat past niet goed bij het typische model dat bestaande planningsproducten bieden.
Planningshulpmiddelen zoals Calendly, SavvyCal en Motion zijn geweldige producten om je te helpen boekingen te maken. Ze bieden echter niet de mogelijkheid om de scheduling infrastructure te leveren voor geavanceerdere planningsgebruiksscenario's, zoals hiring marketplaces, telezorg en meer. Het zou bijvoorbeeld niet haalbaar zijn voor een hiring marketplace om $19/maand per seat te betalen als je meer dan 5.000 gebruikers hebt, zoals Peer had bij Lean Hire.
Bestaande SaaS-planningsproducten geven ook weinig inzicht in wat er intern gebeurt. Bij de onboarding voor Lean Hire vroegen ze hun klanten eerder simpelweg om hun scheduling link te kopiëren/plakken, en het platform voegde die vervolgens automatisch toe aan de outreach-emails. Maar zodra de ontvanger op de scheduling link klikte, had het Lean Hire-platform niet de mogelijkheid om te volgen wat er daarna gebeurde.
Ze wisten niet of of wanneer events plaatsvonden, en ook niet of die werden verplaatst of geannuleerd. Er was geen manier om de booking workflow, het ontwerp of de API-aanroepen die bij het boeken werden gedaan, aan te passen. Daarom hadden ze een open, toegankelijke, uitbreidbare oplossing nodig die ze zelf konden hosten.
Peer zocht meteen op Google naar "Calendly open source" omdat dat is waar open source voor staat: open, toegankelijk, uitbreidbaar en zelf te hosten.
Tot zijn verbazing kon hij geen enkel project vinden dat deed wat Lean Hire zocht. Toevallig zochten op dat moment honderden andere mensen naar precies hetzelfde. Forumthreads, discussies op Reddit en meer werden geopend door mensen die vroegen of er een open-sourceplanningsproduct was dat kon wedijveren met de populairste SaaS-oplossingen.
Waarom hebben we Cal.com open source gemaakt?
Vanaf de allereerste dag was het voor ons duidelijk dat Cal.com een open-sourceproject zou worden. De dingen die we van plan waren te doen, waren fundamenteel moeilijker als closed SaaS-product dan als open source.
Het belangrijkste punt hier is dat de beperkingen van bestaande planningsproducten alleen met open source konden worden opgelost. Veel oprichters slaan de verkeerde weg in door te denken dat ze een open-source-alternatief voor een bestaand product moeten bouwen, in de veronderstelling dat hun product alleen zal slagen omdat het open source is. In plaats daarvan moet je een project alleen open source maken als open source daadwerkelijk de uitdagingen oplost die je wilt aanpakken (bijv. aanpasbaarheid, self-hosting). Als je dit pad evalueert, is het de moeite waard om te begrijpen hoe open-sourceprojecten overstappen naar closed-source modellen en wat die beslissingen na verloop van tijd drijft.
Je zou bijvoorbeeld een open source-alternatief voor Twitter kunnen bouwen, maar de kans is klein dat dat aanslaat, omdat social networking niet echt profiteert van open source. Er zijn veel voorbeelden van projecten die open source zijn puur om open source te zijn.
Maar als je bijvoorbeeld naar de e-commerce-industrie kijkt, die vooral wordt gedomineerd door SaaS-producten zoals Shopify of BigCommerce, kun je zien dat een open-sourcealternatief winkels in staat zou stellen om zelf te hosten, volledig aan te passen en whitelabel te maken, en op manieren uit te breiden die met een closed-sourceproduct niet mogelijk zijn. Dit zou een goed voorbeeld zijn van waarom je je project open source zou moeten maken.
Daarnaast zijn er bij elke open, toegankelijke en gratis software duidelijke en minder duidelijke nadelen. Open source heeft veel voordelen waarvan je waarschijnlijk al op de hoogte bent, maar open source heeft ook nadelen.
Monetisatie
Commerciële open-sourcesoftware (COSS) is een populair bedrijfsmodel waarbij je kernproduct open source is, maar je ook commerciële aanbiedingen hebt die inkomsten genereren. Dit soort bedrijven kan ongelooflijk snel groeien. Het zit in de aard van gratis en open software om al vroeg massale adoptie te krijgen. Ontwikkelaars houden van open source. Ze vinden het fijn om in de codebase te kunnen kijken, eenvoudige bugs op te lossen die hen misschien storen, of in het algemeen gewoon behulpzaam te zijn en iets terug te geven. Wie wil er nou niet behulpzaam zijn?
Maar de enorme groei en waardecreatie komt met een prijs: waarde vastleggen. Vrijwel elke COSS-oprichter met wie ik praat, denkt na over het concept van waardecreatie en waarde vastleggen.
Een freemium SaaS-bedrijf heeft twee klanten: gratis en betaald. En de verhouding is meestal heel goed. Bijvoorbeeld:
�3e “Webflow powers more than 100,000 websites for businesses large and small." – https://webflow.com/customers
De meest recente waardering van Webflow zou $2.1B zijn.
Een open-sourcebedrijf ziet er daarentegen fundamenteel anders uit, met een hoop self-hosters en gratis klanten, die soms niet eens weten dat er een commercieel bedrijf achter het project zit.
Bijvoorbeeld: WordPress draait sinds 2021 op meer dan 455 miljoen websites, en dat aantal blijft alleen maar groeien.
�3e “The parent company of WordPress.com, Tumblr, and more, Automattic, announcing a new funding round bringing the company's total valuation to $7.5 billion” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Als Webflow 455 miljoen websites zou aandrijven – of – als WordPress een gecentraliseerd SaaS-bedrijf was met de economie en het waardevasteleggingsmechanisme van Webflow, dan zouden ze waarschijnlijk de grootste bedrijven ter wereld zijn.
Een COSS-startup zijn betekent in wezen dat je de lange termijn speelt. Je haalt geen inkomsten uit mensen die je product zelf hosten, maar je hoopt dat de tractie van open source je op de radar brengt van grote bedrijven die een grotere deal met je zouden kunnen sluiten.
Daarom is het belangrijk om na te denken over de runway die je bedrijf heeft. Het zal waarschijnlijk lang duren om je bedrijf te lanceren, het product uit te bouwen tot een staat waarin het concurrerend is met closed-sourcealternatieven, vervolgens tractie op te bouwen en uiteindelijk grote deals te sluiten. Dat betekent dat als je niet de financiering hebt om door te blijven werken aan het product terwijl het in het begin weinig inkomsten genereert, je mogelijk niet genoeg waarde vastlegt om te overleven.
Bijdragen
Een van de grote voordelen van open source is de bijdragen van de community. We hebben een aantal geweldige bijdragen van de community gehad waar we ongelooflijk dankbaar voor zijn. Sommige daarvan zijn kleine bugfixes, maar andere kunnen enorme features zijn.
Meestal, als mensen binnen een bedrijf Cal.com uitbreiden voor hun eigen behoeften, bijvoorbeeld om een Microsoft Exchange-integratie te schrijven, zullen ze die code waarschijnlijk in een pull request plaatsen, zodat we die functionaliteit binnen het project zelf kunnen hebben.
De meeste engineers in ons team waren eerder mensen die in hun vrije tijd aan het project bijdroegen, wat voor ons geweldig werkt omdat we meteen voorbeelden van hun werk zien, ze al bekend zijn met de codebase, en ze al een passie hebben om aan het project te werken.
Stelen
Een van de grootste nadelen van open source is dat, met je code vrij beschikbaar op internet, mensen namaakversies van je product zullen maken en je code zullen stelen.
Ondanks het feit dat we een AGPL-licentie hebben en elke wijziging aan de code open source moet worden gemaakt, zijn er nog steeds mensen die deze licenties overtreden en dat zullen blijven doen. Ook houdt niets een van onze concurrenten tegen om in onze code te kijken en te zien hoe we features hebben gebouwd, en die code vervolgens te gebruiken in hun eigen closed-sourceproject. Als ze dat goed genoeg doen, zal niemand weten dat het gestolen is, omdat hun producten closed source zijn.
We kunnen hier eigenlijk niets aan doen om dit te stoppen. Daarom proberen we het probleem van Cal.com-namaak simpelweg aan te pakken door een prominente, sterke merknaam te hebben. We hopen dat als iemand de Cal.com-code zou nemen en daar zijn eigen namaakversie van zou maken, die geen tractie zou krijgen omdat mensen weten dat het een namaakversie is, en dat de community het bij ons zou melden zodat we juridische stappen kunnen ondernemen.
Twitch's source code werd bijvoorbeeld in 2021 gecompromitteerd, maar als je zou proberen hun source code te nemen en een namaakversie van Twitch te beginnen, zou je nergens komen.
Dus, moet ik X open source maken?
Als je jezelf deze vraag stelt, moet je dat waarschijnlijk niet doen. Zoals we hierboven hebben vermeld, is het meestal heel duidelijk of je een oplossing nodig hebt die open, toegankelijk en uitbreidbaar is of niet. Als je het niet nodig hebt – maak het dan niet open source alleen om het open source te maken.
Maar als je wilt verkopen aan enterprise, sterk gereguleerde sectoren, of gewoon een oplossing wilt bouwen voor de enorme massa mensen (455M WordPress versus 100,000 Webflow-websites), dan is open source gaan enorm logisch.
Zorg er daarnaast voor dat je je richt op het bouwen van het beste product. De meeste consumenten geven er eigenlijk niet om of je open source bent of niet.
Ze geven om de beste waarde voor hun geld. Open source helpt enorm bij waardecreatie: de feedbackcyclus is super snel, communityleden lossen bugs op, helpen met vertalingen en nog veel meer, maar vergeet nooit om een superieur product te bouwen ten opzichte van je SaaS-concurrent.
Want uiteindelijk is dat alles wat telt: bouw iets dat mensen nodig hebben. Als je geïnteresseerd bent in hoe onze denkwijze rond open source zich blijft ontwikkelen, lees dan een bericht van onze oprichter over ons volgende hoofdstuk.