Open Source: Was halten wir davon?

Open Source: Was denken wir?

Seit dem Start von Cal.com haben wir unzählige Nachrichten von Gründern erhalten, die sich fragen, ob Open Source die richtige Richtung für ihr Startup wäre, und deshalb wollten wir über den Entscheidungsprozess schreiben, Cal.com als Open-Source-Unternehmen zu gründen, um anderen bei einer ähnlichen Entscheidung zu helfen.

Es gab seit 2021 viel Hype um Open Source, und einige Tech-Magazine schreiben über die "Renaissance of Open Source", aber wir wollen sicherstellen, dass ihr die richtigen Dinge aus den richtigen Gründen tut – oder zumindest über eure Gründe nachdenkt.

Wir erhalten in letzter Zeit ziemlich oft ähnliche Variationen der obigen Frage (aufgrund des Wachstums und der Berichterstattung über cal.com), weshalb wir einen Beitrag schreiben wollten, der erläutert, wie wir über SaaS vs. Open Source denken und wann man Open Source machen sollte.

Obwohl wir beide zuvor viele Open-Source-Projekte genutzt und die Arbeit, die sie leisten, enorm geschätzt haben, würden wir uns nicht als glühende Open-Source-Fans bezeichnen. Cal.com ist das erste OSS-Projekt, an dem einer von uns gearbeitet hat, da alle Projekte, an denen wir zuvor gearbeitet haben, Closed Source waren. Meist gab es einen sehr guten Grund, warum diese Projekte nicht Open Source waren.

Warum haben wir Cal.com überhaupt erst gebaut?

Als Peer an seinem früheren Unternehmen, leanhire.com, arbeitete, stellte er fest, dass es dringend ein leistungsfähigeres Terminplanungstool benötigte.

Anders als im typischen Anwendungsfall, in dem Peer oder seine Mitarbeiter Buchungen vornehmen würden (etwa im Vertrieb oder Recruiting), brauchten sie ein Terminplanungsprodukt für ihren Hiring-Marketplace. In jedem zweiseitigen Marktplatz interagieren eure Nutzer mit anderen Nutzern, was nicht gut zu dem typischen Modell passt, das bestehende Terminplanungsprodukte anbieten.

Terminplanungstools wie Calendly, SavvyCal und Motion sind großartige Produkte, die euch bei Buchungen helfen. Allerdings sind sie nicht in der Lage, die Terminplanungsinfrastruktur für fortgeschrittenere Anwendungsfälle wie Hiring-Marketplaces, Telehealth und mehr bereitzustellen. Es wäre zum Beispiel nicht realistisch, wenn ein Hiring-Marketplace bei über 5.000 Nutzern 19 US-Dollar pro Monat und Sitz bezahlen müsste, wie Peer es bei Lean Hire hatte.

Bestehende SaaS-Terminplanungsprodukte liefern außerdem nur wenige Einblicke in das, was im Inneren passiert. Im Onboarding für Lean Hire baten sie ihre Kunden früher einfach, ihren Terminplanungslink per Copy & Paste einzufügen, und die Plattform fügte ihn automatisch in die Outreach-E-Mails ein. Sobald der Empfänger jedoch auf den Terminplanungslink klickte, hatte die Lean-Hire-Plattform keine Möglichkeit nachzuverfolgen, was als Nächstes passierte.

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 ausgelöst werden. Daher 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 konnte er kein einziges Projekt finden, das das tat, wonach Lean Hire suchte. Zufällig suchten zu dieser Zeit Hunderte anderer Menschen genau nach demselben. Foren-Threads, Reddit-Diskussionen und mehr wurden von Leuten eröffnet, die fragten, ob es ein Open-Source-Terminplanungsprodukt gebe, das mit den beliebtesten SaaS-Lösungen konkurrieren 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 geschlossenes SaaS-Produkt grundsätzlich schwerer umzusetzen als als Open Source.

Der entscheidende Punkt hier ist, dass die Einschränkungen bestehender Terminplanungsprodukte nur durch Open Source gelöst werden konnten. Viele Gründer gehen den falschen Weg und denken, sie sollten eine Open-Source-Alternative zu einem bestehenden Produkt bauen und dass ihr Produkt allein deshalb erfolgreich sein wird, weil es Open Source ist. Stattdessen solltet ihr euer Projekt nur dann Open Source machen, wenn Open Source tatsächlich die Herausforderungen löst, die ihr angehen wollt (z. B. Anpassbarkeit, Self-Hosting). Wenn ihr diesen Weg bewertet, 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önntet ihr eine Open-Source-Alternative zu Twitter bauen, aber es ist unwahrscheinlich, dass sie sich durchsetzt, weil soziale Netzwerke nicht wirklich vom Open-Source-Charakter profitieren. Es gibt viele Beispiele für Projekte, die nur um des Open-Source-Seins willen Open Source sind.

Wenn ihr euch jedoch zum Beispiel die E-Commerce-Branche anschaut, die größtenteils von SaaS-Produkten wie Shopify oder BigCommerce dominiert wird, könntet ihr sehen, dass eine Open-Source-Alternative es ermöglichen würde, Shops selbst zu hosten, vollständig anzupassen und mit einer White-Label-Lösung zu versehen sowie auf eine Weise zu erweitern, die mit einem Closed-Source-Produkt nicht möglich ist. Das wäre ein gutes Beispiel dafür, warum ihr euer Projekt Open Source machen solltet.

Darüber hinaus gibt es bei jeder offenen, zugänglichen und freien Software offensichtliche und nicht offensichtliche Nachteile. Open Source hat viele Vorteile, die ihr wahrscheinlich kennt, aber Open Source hat auch seine Nachteile.

Monetarisierung

Kommerzielle Open-Source-Software (COSS) ist ein trendiges Unternehmensmodell, bei dem euer Kernprodukt Open Source ist, ihr aber auch kommerzielle Angebote habt, die Umsatz bringen. Solche Unternehmen können unglaubliches Wachstum erzielen. Es liegt in der Natur freier und offener Software, dass sie früh eine massive Verbreitung erreicht. Entwickler lieben Open Source. Sie lieben es, in die Codebasis schauen zu können, einfache Fehler zu beheben, die sie stören könnten, oder insgesamt einfach hilfreich zu sein und etwas zurückzugeben. Wer mag es nicht, hilfreich zu sein?

Aber das massive Wachstum und die Wertschöpfung haben einen Preis: Wertabschöpfung. Praktisch 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 zahlende Kunden. Und das Verhältnis ist meist sehr gut. Zum Beispiel:

„Webflow unterstützt mehr als 100.000 Websites für große und kleine Unternehmen." – https://webflow.com/customers

Die jüngste Bewertung von Webflow wird mit 2,1 Mrd. US-Dollar angegeben.

Ein Open-Source-Unternehmen sieht dagegen grundlegend anders aus, mit einer Menge von Self-Hostern und kostenlosen Kunden, die manchmal nicht einmal wissen, dass hinter dem Projekt ein kommerzielles Unternehmen steht.

Zum Beispiel betreibt WordPress seit 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 Wesentlichen, das langfristige Spiel zu spielen. Ihr werdet keine Einnahmen von Menschen erzielen, die euer Produkt selbst hosten, aber ihr hofft, dass die Zugkraft von Open Source euch auf den Radar großer Unternehmen bringt, die mit euch einen größeren Deal abschließen könnten.

Daher ist es wichtig, über die finanzielle Reichweite zu nachzudenken, die euer Unternehmen hat. Es wird wahrscheinlich lange dauern, euer Unternehmen zu starten, das Produkt auf einen Stand zu bringen, an dem es mit Closed-Source-Alternativen konkurrenzfähig ist, dann Zugkraft aufzubauen und schließlich große Deals abzuschließen. Das bedeutet: Wenn ihr nicht die Finanzierung habt, um weiter am Produkt zu arbeiten, während es anfangs nur wenig Umsatz generiert, könnt ihr 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 haben einige erstaunliche Beiträge aus der Community erhalten, für die wir unglaublich dankbar sind. Einige davon sind kleine Fehlerbehebungen, andere können aber auch riesige Funktionen sein.

Wenn Menschen 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 geben, damit wir diese Funktionalität im Projekt selbst haben können.

Die meisten Engineers in unserem Team waren zuvor Menschen, die in ihrer Freizeit zum Projekt beigetragen haben, was für uns großartig ist, weil wir ihre Arbeit sofort als Beispiele sehen können, sie mit der Codebasis bereits vertraut sind und bereits eine Leidenschaft für die Arbeit am Projekt haben.

Diebstahl

Einer der größten Nachteile von Open Source ist, dass Menschen mit eurem frei im Internet verfügbaren Code Nachahmungen eures Produkts erstellen und euren Code stehlen werden.

Trotz der Tatsache, dass wir unter der AGPL lizenziert sind und alle Änderungen am Code wieder Open Source gemacht werden müssen, gibt es immer noch Leute, die diese Lizenzen verletzen, und das auch weiterhin tun werden. Außerdem hindert nichts einen unserer Wettbewerber daran, in unseren Code zu schauen, zu sehen, wie wir Funktionen gebaut haben, und diesen Code dann für ihr eigenes Closed-Source-Projekt zu verwenden. Wenn sie das gut genug machen, wird niemand wissen, dass es gestohlen wurde, da ihre Produkte Closed Source sind.

Wir können das eigentlich nicht wirklich verhindern. Deshalb versuchen wir, das Problem der Cal.com-Nachahmungen einfach mit einer prominenten, starken Marke anzugehen. Wir hoffen, dass jemand, der den Cal.com-Code nehmen und eine eigene Nachahmung daraus machen würde, damit keine Zugkraft gewinnt, weil die Leute wissen, dass es eine Nachahmung 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 ihr versuchen würdet, ihren Quellcode zu nehmen und eine Nachahmungs-Version von Twitch zu starten, würdet ihr damit nicht weit kommen.

Also, sollte ich X Open Source machen?

Wenn ihr euch diese Frage selbst stellt, solltet ihr es wahrscheinlich nicht tun. Wie wir oben erwähnt haben, ist es normalerweise sehr offensichtlich, ob ihr eine Lösung braucht, die offen, zugänglich und erweiterbar ist, oder nicht. Wenn ihr sie nicht braucht – macht sie nicht einfach um des Open Source willen Open Source.

Wenn ihr jedoch in enterprise verkaufen wollt, in stark regulierte Branchen oder einfach eine Lösung für die schiere Masse an Menschen bauen wollt (455 Mio. WordPress vs. 100.000 Webflow-Websites), dann macht Open Source eine Menge Sinn.

Stellt außerdem sicher, dass ihr euch darauf konzentriert, das beste Produkt zu bauen. Die meisten Verbraucher kümmern sich nicht wirklich darum, ob ihr Open Source seid oder nicht.

Ihnen geht es um das beste Preis-Leistungs-Verhältnis. Open Source hilft enorm bei der Wertschöpfung: Der Feedback-Zyklus ist super schnell, Community-Mitglieder beheben Fehler, helfen bei Übersetzungen und vieles andere, aber vergesst nie, ein überlegenes Produkt gegenüber eurem SaaS-Wettbewerber zu bauen.

Denn am Ende des Tages ist das alles, was zählt: Baut etwas, das Menschen brauchen. Wenn ihr daran interessiert seid, wie sich unser Denken über Open Source weiterentwickelt, lest eine Nachricht von unserem Gründer zu unserem nächsten Kapitel.

Cal.com ist jetzt KOSTENLOS für Einzelpersonen - hier anmelden