Open Source: Was denken wir?
Open Source: Was denken wir?
Seit dem Start von Cal.com haben wir unzählige Nachrichten von Gründern erhalten, die fragen, ob Open Source der richtige Weg für ihr Startup wäre. Deshalb wollten wir über den Entscheidungsprozess schreiben, mit dem wir cal.com als Open-Source-Unternehmen gestartet haben, um anderen zu helfen, eine ähnliche Entscheidung zu treffen.
Seit 2021 gibt es rund um Open Source viel Hype, und manche Tech-Magazine schreiben über die „Renaissance von Open Source“. Aber wir wollen sicherstellen, dass du die richtigen Dinge aus den richtigen Gründen tust – oder zumindest über deine Gründe nachdenkst.
Wir haben in letzter Zeit ziemlich oft ähnliche Varianten der obigen Frage bekommen (wegen des Wachstums und der Berichterstattung über cal.com). Deshalb wollten wir einen Beitrag schreiben, der erklärt, wie wir über SaaS vs. Open Source denken und wann es sinnvoll ist, Open Source zu machen.
Obwohl wir beide schon viele Open-Source-Projekte genutzt und ihre Arbeit enorm geschätzt haben, würde sich keiner von uns als eingefleischter Open-Source-Fan bezeichnen. Cal.com ist das erste OSS-Projekt, an dem wir beide gearbeitet haben, denn alle Projekte, an denen wir zuvor gearbeitet haben, waren Closed Source. Meistens gab es einen sehr guten Grund dafür, dass diese Projekte nicht Open Source waren.
Warum haben wir Cal.com überhaupt gebaut?
Als Peer bei seinem früheren Unternehmen leanhire.com arbeitete, merkte er, dass dort dringend ein leistungsfähigeres Terminplanungstool gebraucht wurde.
Anders als im typischen Anwendungsfall, in dem Peer oder seine Mitarbeitenden Buchungen machen würden (etwa im Vertrieb oder Recruiting), brauchten sie ein Terminplanungsprodukt für ihren Hiring-Marktplatz. In jedem zweiseitigen Marktplatz interagieren eure Nutzer mit anderen Nutzern, was nicht gut zum typischen Modell passt, das bestehende Terminplanungsprodukte anbieten.
Terminplanungstools wie Calendly, SavvyCal und Motion sind großartige Produkte, um Buchungen zu machen. Sie haben jedoch nicht die Fähigkeit, die Terminplanungsinfrastruktur für fortgeschrittenere Anwendungsfälle zu liefern, etwa Hiring-Marktplätze, Telemedizin und mehr. Zum Beispiel wäre es nicht machbar, dass ein Hiring-Marktplatz für jeden Platz 19 $/Monat zahlt, wenn ihr über 5.000 Nutzer habt, wie Peer bei Lean Hire.
Bestehende SaaS-Terminplanungsprodukte liefern außerdem kaum Einblicke in das, was intern passiert. Beim Onboarding von Lean Hire sollten ihre Kunden früher einfach ihren Terminlink kopieren und einfügen, und die Plattform fügte ihn automatisch in die Outreach-E-Mails ein. Sobald der Empfänger jedoch auf den Terminlink klickte, konnte die Lean-Hire-Plattform nicht verfolgen, was als Nächstes geschah.
Sie wussten nicht, ob oder wann Termine stattfanden und ob sie verschoben oder storniert wurden. Es gab keine Möglichkeit, den Buchungs-Workflow, das Design oder die API-Aufrufe zu ändern, die beim Buchen ausgeführt werden. Deshalb brauchten sie eine offene, zugängliche, erweiterbare Lösung, die sie selbst hosten konnten.
Peer suchte sofort bei Google nach „Calendly Open Source“, denn genau dafür steht Open Source: offen, zugänglich, erweiterbar und selbst hostbar.
Zu seiner Überraschung fand er nicht ein einziges Projekt, das das tat, was Lean Hire suchte. Zufällig suchten zu dieser Zeit Hunderte anderer Menschen nach genau demselben. Von Leuten wurden Foren-Threads, Reddit-Diskussionen und mehr eröffnet, in denen gefragt wurde, ob es ein Open-Source-Terminplanungsprodukt gebe, das mit den beliebtesten SaaS-Lösungen mithalten könne.
Warum haben wir Cal.com Open Source gemacht?
Vom ersten Tag an war uns klar, dass Cal.com ein Open-Source-Projekt sein würde. Die Dinge, die wir vorhatten, waren als Closed-SaaS-Produkt grundlegend schwieriger als als Open Source.
Der Kernpunkt hier ist, dass sich die Einschränkungen bestehender Terminplanungsprodukte nur mit Open Source lösen ließen. Viele Gründer gehen den falschen Weg und denken, sie sollten eine Open-Source-Alternative zu einem bestehenden Produkt bauen, weil sie glauben, ihr Produkt werde allein deshalb erfolgreich sein, weil es Open Source ist. Stattdessen solltest du dein Projekt nur dann Open Source machen, wenn Open Source tatsächlich die Herausforderungen löst, die du angehen willst (z. B. Anpassbarkeit, Self-Hosting). Wenn du diesen Weg evaluierst, lohnt es sich zu verstehen, wie Open-Source-Projekte zu Closed-Source-Modellen übergehen und was diese Entscheidungen im Laufe der Zeit antreibt.
Zum Beispiel könntest du eine Open-Source-Alternative zu Twitter bauen, aber es ist unwahrscheinlich, dass sie durchstartet, weil soziale Netzwerke nicht wirklich davon profitieren, Open Source zu sein. Es gibt viele Fälle von Projekten, die nur des Open-Source-Seins wegen Open Source sind.
Wenn du dir jedoch zum Beispiel die E-Commerce-Branche ansiehst, die größtenteils von SaaS-Produkten wie Shopify oder BigCommerce dominiert wird, könntest du sehen, dass eine Open-Source-Alternative Shops selbst hostbar, vollständig anpassbar und whitelabel-fähig machen würde – und auf eine Weise erweiterbar wäre, die mit einem Closed-Source-Produkt nicht möglich ist. Das wäre ein gutes Beispiel dafür, warum du dein Projekt Open Source machen solltest.
Außerdem gibt es bei jeder offenen, zugänglichen und kostenlosen Software offensichtliche und nicht offensichtliche Nachteile. Open Source hat viele Vorteile, die dir wahrscheinlich bewusst sind, aber Open Source ist nicht ohne seine Nachteile.
Monetarisierung
Commercial Open Source Software (COSS) ist ein wachsendes Unternehmensmodell, bei dem dein Kernprodukt Open Source ist, du aber auch kommerzielle Angebote hast, die Umsatz bringen. Solche Unternehmen können unglaublich stark wachsen. Es liegt in der Natur freier und offener Software, früh massive Verbreitung zu erreichen. Entwickler lieben Open Source. Sie lieben es, in die Codebasis schauen zu können, kleine Fehler zu beheben, die sie nerven, oder insgesamt einfach hilfreich zu sein und etwas zurückzugeben. Wer will nicht hilfreich sein?
Aber das massive Wachstum und die Wertschöpfung haben ihren Preis: Wertabschöpfung. Nahezu jeder COSS-Gründer, mit dem ich spreche, denkt über das Konzept von Wertschöpfung und Wertabschöpfung nach.
Ein Freemium-SaaS-Geschäft hat zwei Kundengruppen: Free-Tier und Paid. Und das Verhältnis ist normalerweise sehr gut. Zum Beispiel:
„Webflow betreibt mehr als 100.000 Websites für Unternehmen jeder Größe.“ – https://webflow.com/customers
Die aktuelle Bewertung von Webflow soll bei 2,1 Mrd. $ liegen.
Ein Open-Source-Unternehmen hingegen sieht grundlegend anders aus, mit einer Menge Selbsthostern und kostenlosen Kunden, die manchmal nicht einmal wissen, dass es hinter dem Projekt ein kommerzielles Unternehmen gibt.
Zum Beispiel: WordPress betreibt Stand 2021 über 455 Millionen Websites, und diese Zahl wächst weiter.
„Die Muttergesellschaft von WordPress.com, Tumblr und mehr, Automattic, kündigt eine neue Finanzierungsrunde an, die die Gesamtbewertung des Unternehmens auf 7,5 Milliarden US-Dollar bringt“ – https://cheddar.com/media/automattic-announces-288-million-funding-round
Wenn Webflow 455 Millionen Websites betreiben würde – oder wenn WordPress ein zentralisiertes SaaS-Geschäft mit der Ökonomie und dem Wertabschöpfungsmechanismus von Webflow wäre, dann wären sie vermutlich die größten Unternehmen der Welt.
Ein COSS-Startup zu sein bedeutet im Grunde, das lange Spiel zu spielen. Du wirst keinen Umsatz von Leuten abschöpfen, die dein Produkt auf ihrem eigenen Server hosten, aber du hoffst, dass die Reichweite von Open Source dich auf den Radar großer Unternehmen bringt, mit denen du einen größeren Deal abschließen kannst.
Deshalb ist es wichtig, über die finanzielle Reichweite deines Unternehmens nachzudenken. Es wird wahrscheinlich lange dauern, dein Unternehmen zu starten, das Produkt auf einen Stand zu bringen, auf dem es mit Closed-Source-Alternativen konkurrenzfähig ist, dann Reichweite aufzubauen und schließlich große Deals abzuschließen. Das bedeutet: Wenn du nicht die Finanzierung hast, um weiter an dem Produkt zu arbeiten, während es anfangs nur wenig Umsatz generiert, könntest du möglicherweise nicht genug Wert abschöpfen, um zu überleben.
Beiträge
Einer der großen Vorteile von Open Source sind die Beiträge aus der Community. Wir hatten einige großartige Beiträge aus der Community, für die wir unglaublich dankbar sind. Einige davon sind kleine Bugfixes, andere können riesige Features sein.
Normalerweise gilt: Wenn Leute innerhalb eines Unternehmens Cal.com für ihre eigenen Bedürfnisse erweitern, zum Beispiel um eine Microsoft-Exchange-Integration zu schreiben, werden sie diesen Code wahrscheinlich in einen Pull Request stecken, damit wir diese Funktionalität direkt im Projekt selbst haben können.
Die meisten Engineers in unserem Team waren früher Leute, die in ihrer Freizeit zum Projekt beigetragen haben. Das ist für uns großartig, weil wir ihre Arbeit sofort als Beispiele sehen, sie die Codebasis schon kennen und bereits eine Leidenschaft dafür haben, am Projekt zu arbeiten.
Klauen
Einer der größten Nachteile von Open Source ist, dass dein Code frei im Internet verfügbar ist und Leute Kopien deines Produkts erstellen und deinen Code stehlen werden.
Trotz der Tatsache, dass wir unter der AGPL lizenziert sind und jede Änderung am Code Open Source gemacht werden muss, gibt es immer noch Leute, die diese Lizenzen verletzen und weiterhin verletzen werden. Außerdem hält nichts einen unserer Konkurrenten davon ab, unseren Code anzusehen und zu sehen, wie wir Features gebaut haben, und dann diesen Code zu nehmen, um ihn in ihrem eigenen Closed-Source-Projekt zu verwenden. Wenn sie das gut genug machen, wird niemand wissen, dass es gestohlen wurde, weil ihre Produkte Closed Source sind.
Wir können nichts tun, um das wirklich zu verhindern. Deshalb versuchen wir, dem Problem von Cal.com-Kopien einfach mit einer prominenten, starken Marke zu begegnen. Wir hoffen, dass jemand, der den Cal.com-Code nehmen und eine eigene Kopie daraus machen würde, damit keinen Anklang findet, weil die Leute wissen, dass es eine Kopie ist, und dass die Community es an uns meldet, damit wir rechtliche Schritte einleiten können.
Zum Beispiel wurde der Quellcode von Twitch 2021 kompromittiert, aber wenn du versuchen würdest, ihren Quellcode zu nehmen und eine Kopie von Twitch zu starten, würdest du damit nicht weit kommen.
Also, sollte ich X Open Source machen?
Wenn du dir diese Frage selbst stellst, solltest du es wahrscheinlich nicht tun. Wie wir oben erwähnt haben, ist es normalerweise sehr offensichtlich, ob du eine Lösung brauchst, die offen, zugänglich und erweiterbar ist, oder nicht. Wenn du sie nicht brauchst – mach sie nicht einfach nur um des Open Source willen Open Source.
Wenn du jedoch an Unternehmen verkaufen willst, in stark regulierte Branchen oder einfach eine Lösung für die schiere Masse an Menschen bauen willst (455 Mio. WordPress vs. 100.000 Webflow-Websites), dann ist Open Source sehr sinnvoll.
Stell außerdem sicher, dass du dich darauf konzentrierst, das beste Produkt zu bauen. Der Großteil der Kundschaft interessiert sich nicht wirklich dafür, ob du Open Source bist oder nicht.
Ihnen geht es um den besten Gegenwert für ihr Geld. Open Source hilft enorm bei der Wertschöpfung: Der Feedback-Zyklus ist super schnell, Community-Mitglieder beheben Fehler, helfen bei Übersetzungen und bei vielen anderen Dingen. Aber vergiss nie, ein überlegenes Produkt gegenüber deinem SaaS-Konkurrenten zu bauen.
Denn am Ende des Tages zählt nur das: Bau etwas, das Menschen brauchen. Wenn du dich dafür interessierst, wie sich unser Denken über Open Source weiterentwickelt, lies eine Nachricht unseres Gründers über unser nächstes Kapitel.
Cal.com ist jetzt KOSTENLOS für Einzelpersonen – melde dich hier an