Open source: wat denken we hiervan?

Open source: wat vinden wij?

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 schrijven over het besluitvormingsproces om cal.com te starten als een open-sourcebedrijf, om anderen te helpen een vergelijkbare beslissing te nemen.

Sinds 2021 is er 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 om de juiste redenen doet – of in ieder geval over je redenen nadenkt.

We krijgen de laatste tijd vrij veel vergelijkbare variaties van bovenstaande vraag (door de groei en aandacht voor cal.com), en daarom wilden we een artikel schrijven waarin we uiteenzetten hoe we denken over SaaS versus open source en wanneer we open source moeten maken.

Ondanks dat we allebei eerder veel open-sourceprojecten hebben gebruikt en het werk dat ze doen enorm hebben gewaardeerd, zouden geen van ons zichzelf zien als doorgewinterde fans van open source. Cal.com is het eerste OSS-project waaraan een van ons heeft gewerkt, aangezien alle projecten waaraan we daarvoor hebben gewerkt closed-source waren. Meestal was er een heel goede reden dat die projecten niet open source waren.

Waarom hebben we Cal.com in eerste instantie gebouwd?

Toen Peer bij zijn vorige bedrijf, leanhire.com, werkte, zag hij dat het dringend behoefte had aan een krachtigere planningstool.

In tegenstelling tot de typische use case waarin Peer, of zijn werknemers, boekingen zouden maken (zoals in sales of recruiting), hadden ze een planningsproduct nodig voor hun hiring marketplace. In elke tweezijdige marktplaats interageren je gebruikers met andere gebruikers, wat niet goed aansluit bij het typische model dat door bestaande planningsproducten wordt aangeboden.

Planningshulpmiddelen zoals Calendly, SavvyCal en Motion zijn geweldige producten om boekingen te maken. Ze kunnen echter niet de infrastructuur voor planning bieden voor geavanceerdere planningsgebruiksscenario's, zoals hiring marketplaces, telehealth 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 niet veel inzicht in wat er achter de schermen gebeurt. Bij de onboarding van Lean Hire vroegen ze hun klanten eerder gewoon om hun planningslink te kopiëren/plakken, waarna het platform die automatisch aan de outreach-e-mails toevoegde. Zodra de ontvanger op de planningslink klikte, had het Lean Hire-platform echter niet de mogelijkheid om te volgen wat er daarna gebeurde.

Ze wisten niet of en wanneer gebeurtenissen plaatsvonden, en of die opnieuw waren gepland of geannuleerd. Er was geen manier om de boekingsworkflow, het ontwerp of de API-aanroepen die worden gedaan bij het boeken aan te passen. Daarom was een open, toegankelijke, uitbreidbare oplossing die ze zelf konden hosten nodig.

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, Reddit-discussies 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 zijn. De dingen die we van plan waren te doen, waren fundamenteel moeilijker als gesloten SaaS-product dan als open-source.

Het belangrijkste hier is dat de beperkingen van bestaande planningsproducten alleen door open source konden worden opgelost. Veel oprichters slaan de verkeerde weg in door te denken dat ze een open-sourcealternatief 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 je project open source te maken als open source daadwerkelijk de uitdagingen oplost die je wilt aanpakken (bijv. aanpasbaarheid, zelf hosten). Als je deze route evalueert, is het de moeite waard om te begrijpen hoe open-sourceprojecten overgaan naar closed-sourcemodellen en wat die beslissingen in de loop van de tijd drijft.

Je zou bijvoorbeeld een open-source Twitter-alternatief kunnen bouwen, maar het is onwaarschijnlijk dat dat aanslaat, omdat sociale netwerken niet echt profiteren van open source. Er zijn veel gevallen van projecten die open source zijn puur om open source te zijn.

Als je bijvoorbeeld naar de e-commerce-industrie kijkt, die grotendeels wordt gedomineerd door SaaS-producten zoals Shopify of BigCommerce, kun je zien dat een open-sourcealternatief winkels in staat zou stellen om zelf gehost, volledig aangepast en white-label te zijn, en uitgebreid te worden op manieren die niet mogelijk zijn met een closed-source product. 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 op de hoogte bent, maar open source heeft ook 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 opleveren. Dit soort bedrijven kan ongelooflijke groei doormaken. Het is de aard van vrije en open software om al vroeg enorme adoptie te hebben. Ontwikkelaars houden van open source. Ze vinden het geweldig om in de codebase te kunnen kijken, eenvoudige bugs op te lossen die hen misschien ergeren, of gewoon over het algemeen behulpzaam te zijn en iets terug te geven. Wie wil er nou niet behulpzaam zijn?

Maar die enorme groei en waardecreatie komen met een prijs: waardevastlegging. Vrijwel elke COSS-oprichter met wie ik praat, denkt na over het concept van waardecreatie en waardevastlegging.

Een freemium-SaaSbedrijf heeft twee klanten: gratis gebruikers en betalende klanten. En de verhouding is meestal erg goed. Bijvoorbeeld:

“Webflow ondersteunt meer dan 100.000 websites voor grote en kleine bedrijven.” – 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 heleboel zelf-hosters en gratis klanten, die soms niet eens weten dat er een commercieel bedrijf achter het project zit.

Bijvoorbeeld: WordPress ondersteunt anno 2021 meer dan 455 miljoen websites, 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 dollar 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 was met de economie en het waardevastleggingsmechanisme van Webflow, dan zouden ze waarschijnlijk de grootste bedrijven ter wereld zijn.

Als COSS-startup zijn betekent in wezen het lange spel spelen. 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 nadenken over de runway die je bedrijf heeft belangrijk. Het zal waarschijnlijk lang duren om je bedrijf te lanceren, het product op te bouwen tot een staat waarin het concurrerend is met closed-source alternatieven, dan tractie op te bouwen en uiteindelijk grote deals te sluiten. Dit betekent dat als je niet de financiering hebt om door te blijven werken aan het product terwijl het aanvankelijk weinig inkomsten genereert, je mogelijk niet genoeg waarde vastlegt om te overleven.

Bijdragen

Een van de belangrijke voordelen van open source is de bijdragen van de community. We hebben enkele geweldige bijdragen van de community gekregen waarvoor we ongelooflijk dankbaar zijn. Sommige daarvan zijn kleine bugfixes, maar andere 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, plaatsen ze deze code waarschijnlijk in een pull request, zodat we deze functionaliteit binnen het project zelf kunnen hebben.

De meeste engineers in ons team waren eerder mensen die in hun eigen tijd aan het project hebben bijgedragen, wat voor ons geweldig werkt omdat we meteen voorbeelden van hun werk zien, ze al vertrouwd 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, omdat je code vrij beschikbaar is op internet, mensen namaakversies van je product zullen maken en je code zullen stelen.

Ondanks het feit dat we een AGPL-licentie hebben en alle wijzigingen aan de code open source moeten worden gemaakt, zijn er nog steeds mensen die deze licenties schenden en zullen blijven schenden. Ook staat niets een van onze concurrenten in de weg om in onze code te kijken en te zien hoe we functies hebben gebouwd, en die code vervolgens te gebruiken in hun eigen closed-source project. Als ze dat goed genoeg doen, zal niemand weten dat het gestolen was, aangezien hun producten closed source zijn.

Er is eigenlijk niets dat we kunnen doen om dit te stoppen. Daarom proberen we het probleem van Cal.com-kopieën simpelweg aan te pakken met een prominent, sterk merk. We hopen dat als iemand de code van Cal.com zou nemen en zijn eigen kopie zou maken, die geen tractie zou krijgen omdat mensen weten dat het een kopie is, en dat de community het aan ons zou melden zodat we juridische stappen kunnen ondernemen.

De broncode van Twitch werd in 2021 gecompromitteerd, maar als je hun broncode zou proberen te gebruiken om een kopie van Twitch te starten, zou je nergens komen.

Dus, moet ik X open source maken?

Als je jezelf deze vraag stelt, moet je het waarschijnlijk niet doen. Zoals we hierboven al 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 maar om het te doen.

Als je echter aan enterprise, sterk gereguleerde sectoren wilt verkopen of gewoon een oplossing wilt bouwen voor de massa's mensen (455M WordPress vs 100.000 Webflow-websites), dan is open source gaan enorm zinvol.

Daarnaast moet je je richten op het bouwen van het beste product. De meeste consumenten geven er echt niet om of je open source bent of niet.

Het enige waar ze om geven is de beste waarde voor hun geld. Open source helpt enorm bij het creëren van waarde: de feedbackcyclus is supersnel, communityleden lossen bugs op, helpen met vertalingen, en veel andere dingen, maar vergeet nooit een beter product te bouwen dan je SaaS-concurrent.

Want uiteindelijk is dat alles wat telt: bouw iets dat mensen nodig hebben. Als je geïnteresseerd bent in hoe ons denken over open source blijft evolueren, lees een bericht van onze oprichter over ons volgende hoofdstuk.

Cal.com is nu GRATIS voor particulieren - meld je hier aan