Open source: wat vinden we ervan?
Sinds de lancering van Cal.com hebben we talloze berichten ontvangen van oprichters die vroegen of open source de juiste richting zou zijn voor hun startup, en daarom wilden we graag schrijven over het besluitvormingsproces van het starten van cal.com als een open-source bedrijf, om anderen te helpen een soortgelijke beslissing te nemen.
Er is veel hype geweest rond open source sinds 2021, en sommige techmagazines schrijven over de "Renaissance van Open Source", maar we willen ervoor zorgen dat je de juiste dingen doet om de juiste redenen – of in ieder geval reflecteert op je redenen.
We hebben de laatste tijd veel soortgelijke varianten van de bovenstaande vraag ontvangen (door de groei en berichtgeving over cal.com), wat de reden is waarom we een bericht wilden schrijven waarin we uitlegden hoe we denken over SaaS versus open source en wanneer je open source moet maken.
Ondanks dat we beiden veel open source-projecten hebben gebruikt en enorm waarderen wat ze doen, beschouwen geen van ons zichzelf als fervente open source-fans. Cal.com is het eerste OSS-project waaraan één van ons heeft gewerkt, aangezien alle projecten waaraan we eerder hebben gewerkt gesloten source waren. Meestal was er een heel goede reden waarom die projecten niet open source waren.
Waarom hebben we Cal.com in de eerste plaats gebouwd?
Toen Peer werkte aan zijn vorige bedrijf, leanhire.com, ontdekte hij dat er dringend behoefte was aan een krachtiger planningsinstrument.
In tegenstelling tot de typische gebruikssituatie waarin Peer, of zijn werknemers, reserveringen zouden maken (zoals in verkoop of werving), hadden ze een planningsproduct nodig voor hun wervingsplatform. In elk tweezijdig platform interageren je gebruikers met andere gebruikers, wat niet goed past bij het typische model dat door bestaande planningsproducten wordt aangeboden.
Planningshulpmiddelen zoals Calendly, SavvyCal en Motion zijn geweldige producten om je te helpen reserveringen te maken. Ze hebben echter niet de mogelijkheid om de planningsinfrastructuur te bieden voor meer geavanceerde planningsuse cases, zoals wervingsplatforms, telehealth en meer. Bijvoorbeeld, het zou niet haalbaar zijn voor een wervingsplatform om $19/maand per plek te betalen als je meer dan 5.000 gebruikers hebt, zoals Peer had bij Lean Hire.
Bestaande SaaS-planningsproducten bieden ook niet veel inzichten in wat er binnenin gebeurt. Tijdens de onboarding voor Lean Hire vroegen ze hun klanten eerder gewoon om hun planningslink te kopiëren/plakken en het platform zou het automatisch aan de outreach-e-mails toevoegen. Echter, zodra de ontvanger op de planningslink klikte, had het Lean Hire-platform niet de mogelijkheid om te volgen wat er daarna gebeurde.
Ze wisten niet of of wanneer evenementen plaatsvonden, en of ze werden verplaatst of geannuleerd. Er was geen manier om de boekingsworkflow, het ontwerp of de API-aanroepen die worden gedaan bij het boeken te wijzigen. Daarom was er behoefte aan een open, toegankelijk, uitbreidbaar oplossing die ze zelf konden hosten.
Peer zocht meteen op Google naar "Calendly open source" omdat dat waar open source voor staat: open, toegankelijk, uitbreidbaar en zelf-hostbaar.
Tot zijn verbazing kon hij geen enkel project vinden dat deed wat Lean Hire zocht. Toevallig waren op dat moment honderden andere mensen op zoek naar precies hetzelfde. Forumdiscussies, Reddit-discussies en meer werden geopend door mensen die vroegen of er een open-source planningsproduct was dat kon concurreren met de populairste SaaS-oplossingen.
Waarom hebben we Cal.com open source gemaakt?
Vanaf de eerste dag was het voor ons duidelijk dat Cal.com een open-source project zou zijn. De dingen die we van plan waren te doen, waren fundamenteel moeilijker als een gesloten SaaS-product dan als open-source.
Het belangrijkste punt hier is dat de beperkingen van bestaande planningsproducten alleen konden worden opgelost door open-source. Veel oprichters gaan de verkeerde weg 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 alleen overwegen om je project open source te maken als open source daadwerkelijk de uitdagingen oplost die je wilt aanpakken (bijvoorbeeld aanpasbaarheid, zelf-hosting).
Bijvoorbeeld, je zou een open source Twitter-alternatief kunnen bouwen, maar het is onwaarschijnlijk dat het zal slagen, omdat sociale netwerken niet echt profiteren van open source. Er zijn veel voorbeelden van projecten die open source zijn alleen om het open source te zijn.
Echter, als je bijvoorbeeld naar de e-commerce-industrie kijkt, die voornamelijk wordt gedomineerd door SaaS-producten zoals Shopify of BigCommerce, zou je kunnen zien dat het hebben van een open-source alternatief zou toestaan dat winkels zelf gehost, volledig aangepast en witgelabeld zouden kunnen worden, en op manieren die niet mogelijk zijn met een gesloten-source product. Dit zou een goed geval zijn waarom je je project open source zou moeten maken.
Bovendien zijn er bij elke open, toegankelijke en gratis software zowel duidelijke als minder duidelijke nadelen. Open source heeft veel voordelen waarvan je waarschijnlijk op de hoogte bent, maar open source is niet zonder zijn nadelen.
Monetisatie
Commerciële open source-software (COSS) is een trending bedrijfsmodel waarbij je kernproduct open source is, maar je ook commerciële aanbiedingen hebt die inkomsten genereren. Deze soorten bedrijven kunnen ongelooflijke groei hebben. Het is de aard van gratis en open software om in het begin een enorme adoptie te hebben. Ontwikkelaars houden van open source. Ze houden ervan om in de codebase te kijken, eenvoudige bugs te verhelpen die hen kunnen irriteren, of gewoon nuttig te zijn en iets terug te geven. Wie houdt er niet van om nuttig te zijn?
Maar de enorme groei en waardecreatie komt met een kosten: waarde captatie. Bijna elke COSS-oprichter met wie ik praat, denkt na over het concept van waardecreatie en waarde captatie.
Een freemium SaaS-bedrijf heeft twee klanten: gratis en betaald. En de verhouding is meestal erg goed. Bijvoorbeeld:
“Webflow is verantwoordelijk voor meer dan 100.000 websites voor grote en kleine bedrijven." – https://webflow.com/customers
De laatste waardering van Webflow wordt gerapporteerd op $2,1 miljard.
Een open-source bedrijf daarentegen ziet er fundamenteel anders uit, met een heleboel zelf-hosters en gratis klanten, die soms niet eens weten dat er een commercieel bedrijf achter het project bestaat.
Bijvoorbeeld: WordPress is verantwoordelijk voor meer dan 455 miljoen websites in 2021, en dat aantal blijft alleen maar groeien.
“Het moederbedrijf van WordPress.com, Tumblr, en meer, Automattic, kondigt een nieuwe financieringsronde aan die de totale waardering van het bedrijf op $7,5 miljard brengt” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Als Webflow 455 miljoen websites zou ondersteunen – of – als WordPress een gecentraliseerd SaaS-bedrijf zou zijn met de economieën en waarde-captatiemechanismen van Webflow, zouden ze waarschijnlijk de grootste bedrijven ter wereld zijn.
Als een COSS-startup speel je in wezen het lange spel. Je zult geen inkomsten genereren van mensen die je product zelf hosten, maar je hoopt dat de tractie van open source je op de radar zet 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 lange tijd duren om je bedrijf te lanceren, het product op te bouwen tot een staat waarin het concurrerend is met gesloten-source alternatieven, dan tractie op te bouwen en uiteindelijk grote deals te sluiten. Dit betekent dat als je niet de financiering hebt om aan het product te blijven werken terwijl het aanvankelijk weinig inkomsten genereert, je misschien niet genoeg waarde kunt vastleggen om te overleven.
Bijdragen
Een van de belangrijke voordelen van open source is de bijdragen van de gemeenschap. We hebben enkele geweldige bijdragen van de gemeenschap gehad waarvoor we ongelooflijk dankbaar zijn. Sommige hiervan zijn kleine bugfixes, maar anderen kunnen enorme functies zijn.
Meestal, als mensen binnen een bedrijf Cal.com uitbreiden voor hun eigen behoeften, bijvoorbeeld om een Microsoft Exchange-integratie te schrijven, zullen ze waarschijnlijk deze code in een pull request plaatsen zodat we deze functionaliteit in het project zelf kunnen krijgen.
De meeste ingenieurs in ons team waren eerder mensen die in hun eigen tijd aan het project bijdroegen, wat geweldig voor ons werkt omdat we hun werk meteen kunnen zien, ze al bekend zijn met de codebase, en ze al een passie hebben voor het werken aan het project.
Diefstal
Een van de grootste nadelen van open source is dat, met je code die vrij beschikbaar is op internet, mensen rip-offs van je product zullen creëren en je code zullen stelen.
Ondanks het feit dat we AGPL-gelicentieerd zijn en alle wijzigingen aan de code open source moeten zijn, zijn er nog steeds mensen die deze licenties schenden en dat zullen blijven doen. Bovendien is er niets wat een van onze concurrenten kan stoppen om naar onze code te kijken en te zien hoe we functies hebben gebouwd, en deze code vervolgens te gebruiken in hun eigen gesloten-source project. Als ze het goed genoeg doen, zal niemand weten dat het gestolen is, omdat hun producten gesloten source zijn.
Er is niets wat we echt kunnen doen om dit te stoppen. Daarom proberen we het probleem van Cal.com-rip-offs aan te pakken door simpelweg een prominente, sterke merknaam te hebben. We hopen dat als iemand de Cal.com-code zou nemen en een eigen rip-off versie zou maken, ze geen tractie zullen krijgen omdat mensen weten dat het een rip-off is, en dat de gemeenschap het ons zou melden zodat we juridische stappen kunnen ondernemen.
Bijvoorbeeld, de source code van Twitch werd gecompromitteerd in 2021, maar als je hun source code zou proberen te nemen en een rip-off versie van Twitch zou starten, zou je nergens komen.
Dus, moet ik X open source maken?
Als je jezelf deze vraag stelt, zou je het waarschijnlijk niet moeten 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 gewoon om het open source te maken.
Echter, als je wilt verkopen in ondernemingen, sterk gereguleerde industrieën of gewoon een oplossing wilt bouwen voor de sheer masses van mensen (455M WordPress versus 100.000 Webflow-websites) dan maakt open-source absoluut veel zin.
Bovendien, zorg ervoor dat je je richt op het bouwen van het beste product. De meerderheid van de consumenten maakt het eigenlijk niet uit 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 verhelpen bugs, helpen met vertalingen en nog veel meer, maar vergeet nooit om een superieur product te bouwen boven je SaaS-concurrent.
Want aan het einde van de dag is dat alles wat ertoe doet: bouw iets dat mensen nodig hebben.
