- Supabase entschied sich schon in der frühen Gründungsphase für Open Source und erzielte durch den öffentlichen Aufbau des Produkts unerwartet große Vorteile bei Community, Recruiting und Produkterweiterung
- Typische Sorgen betreffen Kritik an der Codequalität, die Offenlegung von Sicherheitslücken und Kopien durch Wettbewerber; Offenheit kann aber auch zu Beteiligung an Verbesserungen und schneller Iteration führen
- Beim Recruiting zeigen Beiträge im Repository den tatsächlichen Code und die Art der Zusammenarbeit eines Kandidaten; Supabase begann erst nach der Einstellung von 32 Entwicklern mit Outbound-Recruiting
- Funktionen für kleinere Nutzergruppen, Integrationen und Adapter können direkt von der Community erstellt werden, wodurch der Produktumfang wächst und die Prioritätsgrenzen des internen Teams ergänzt werden
- Die Verteidigungsfähigkeit eines Open-Source-Unternehmens entsteht weniger durch das Verbergen von Code als durch den langfristigen Aufbau von Ausführungsgeschwindigkeit, Marke, Team und Community
Warum Supabase von Anfang an auf Open Source setzte
- Supabase war vom ersten Tag an Open Source; weil die Gründer langjährige Nutzer und Unterstützer offener Projekte wie PostgreSQL, Python, Bitcoin und React waren, fühlte sich das damals nicht wie eine schwierige Entscheidung an
- Entgegen der Erwartung, dass der öffentliche Aufbau eines Unternehmens belastend sein würde, zeigten sich beim Wachstum von Produkt und Unternehmen mehrere unerwartete Vorteile
- Auch wenn es sich um die Erfahrung eines Developer-Tools- oder PaaS-Unternehmens handelt, lässt sich vieles davon auf Softwareunternehmen allgemein übertragen
- Die wiederkehrenden Sorgen, die eine Umstellung auf Open Source verhindern, lassen sich grob in drei Punkte einteilen
- Menschen könnten schmutzigen oder unfertigen Code kritisieren
- Hacker könnten Sicherheitslücken finden und ausnutzen
- Wettbewerber könnten geistiges Eigentum stehlen
Die Sorge: „Mein Code ist schlecht“
- Die Angst vor schlechtem Code ist meist eher eine Frage des Egos; wenn sich jemand die Zeit nimmt, hineinzuschauen, hat er darin vermutlich etwas gefunden, das es zu verfolgen lohnt
- Wie in der Geschichte von Stone Soup können andere eine gute Idee aufgreifen und gemeinsam verbessern, wenn man sie mit der Community teilt
- Die Community kann schlechten Code refaktorisieren oder ersetzen und neue Qualitätsrichtlinien für Code einführen, wodurch auch der spätere Beitragsprozess besser wird
- Toxische Mitglieder, die sich nur über Code beschweren und keine Verbesserungsvorschläge machen, sind ohnehin nicht die Art von Community-Mitgliedern, die man haben möchte
- Open-Source-Mitwirkende haben ihre „Friedhöfe“ alter Projekte, die für Menschen, die Ähnliches bauen wollen, zu einer Bibliothek von Ideen und Ansätzen werden
- Jemand kann sich von einer bestimmten Art der Problemlösung inspirieren lassen
- Zumindest lässt sich die Zeit reduzieren, in der dieselben Fehler wiederholt werden
- Es ist wahrscheinlicher, dass ein altes Projekt nützlich verwendet oder gar nicht beachtet wird, als dass es den Ruf ruiniert
Öffentlicher Code und Sicherheit
- Die größte Angst beim Betrieb einer Hosting-Lösung mit öffentlichem Code ist das Szenario, dass böswillige Akteure den Code lesen, Schwachstellen finden und den Dienst hacken
- Nach Supabases Erfahrung gilt Linus's law – „Given enough eyeballs, all bugs are shallow“ – auch für Sicherheitsprobleme
- Von Anfang an halfen Sicherheitsforscher, häufig anonym, dabei, Code und Plattform zu untersuchen und potenzielle Probleme zu finden
- Wenn man SaaS anbietet, sollte man unter
/.well-known/security.txteinfache Hinweise bereitstellen, damit wohlmeinende Forscher wissen, wie sie potenzielle Probleme offenlegen sollen - Als Beispiel dafür, dass ein öffentliches Projekt sicherer sein kann als eine proprietäre Codebasis, wird Bitcoin genannt
- Andreas M. Antonopoulos sagte in einem Vortrag von 2015, dass geschlossene Bankensysteme softwareseitig ein schwaches Immunsystem hätten
- In geschlossenen Systemen können große Sicherheitslücken lange verborgen bleiben und letztlich großen Schaden anrichten, wenn sie ausgenutzt werden
- In Open-Source-Protokollen wie Bitcoin sind Sicherheitslücken für alle sichtbar; Exploits werden früh und häufig entdeckt und anschließend gepatcht
- Erfolgreiche Softwareunternehmen können über mehr als 10 Jahre entstehen, sodass Open-Source-Systeme langfristig einem sicheren Zustand näherkommen können als geheime proprietäre Systeme
- In Zeiten, in denen der Wettbewerb um hervorragende Security Engineers extrem intensiv ist, wird der Wert öffentlicher Prüfung noch größer
Sorgen rund um Wettbewerber und geistiges Eigentum
- In Software sind Ideen billig; der Wert entsteht fast immer durch die Umsetzung der Ideen
- Wenn man eine Idee mit der Welt teilt, kann man sich darauf konzentrieren, schneller zu iterieren, statt sich darum zu sorgen, wer Zugriff auf die Codebasis bekommt
-
Eine Experten-Community aufbauen
- Um ein erfolgreiches Unternehmen aufzubauen, muss man über einen langen Zeitraum, zum Beispiel 10 Jahre, gut ausführen und eine Kundenbasis aufbauen
- In diesem Langstreckenrennen ist der Vorteil, den Wettbewerber durch Einblicke in die Codebasis erhalten, über die gesamten 10 Jahre betrachtet wahrscheinlich nicht groß
- In diesem Zeitraum wird die Codebasis vermutlich mehrfach iteriert und refaktorisiert
- Langfristig gewinnt, wer das Team und die Community aufbaut, die die eigene Lösung weltweit am besten iterativ verbessern
-
Im Markt gewinnen
- Wenn ein großer und wachsender Total Addressable Market (TAM) wirklich verfolgenswert ist, handelt es sich wahrscheinlich nicht um eine Winner-takes-all-Situation
- Man sollte zuerst ein Nutzersegment finden, das man begeistern kann, und schnell iterieren
- Zeit, die man auf Wettbewerber richtet, ist Zeit, die in Produkt- oder Teamverbesserungen fließen könnte
- Wenn ein Wettbewerber ein Open-Source-Projekt forken und schneller launchen kann, war man in diesem Wettbewerb ohnehin zum Verlieren bestimmt
- IP und Patente sind in der Software bekanntlich schwer durchzusetzen; wer sich weniger darum sorgt, Softwareideen mit Anwälten zu schützen, spart Zeit, Geld und mentale Energie
- Ein Unternehmen lässt sich besser schützen, indem es Softwareideen weltweit am besten umsetzt
-
Cloud-Wettbewerb in einer späteren Phase
- Wenn ein Projekt eine erhebliche Größe erreicht, kann es passieren, dass große Cloud-Anbieter wie bei Elastic oder Mongo das Produkt mit einem stärkeren Distributionsmodell anbieten
- Das größte Problem eines gerade gestarteten Unternehmens ist zunächst, überhaupt erst an diesen Punkt zu gelangen
- Wenn AWS Ressourcen aus einem seiner milliardenschweren Produktbereiche abzieht, um mit einem Hosting-Produkt zu konkurrieren, ist man bereits in einer sehr guten Position
- Eine konstruktivere Reaktion besteht darin, frühzeitig Bereiche zu finden, in denen man jedem Wettbewerber voraus sein kann
- Viele Cloud-Anbieter haben häufig keine gute Developer Experience (DX), daher kann man DX zur Kernkompetenz machen
- Wenn Google in 6 Jahren versucht, einem das Mittagessen wegzunehmen, sollten Marke, Team und Community in den Jahren davor auf einen Kampf David gegen Goliath vorbereitet worden sein
- Man sollte von Anfang an planen, um von einer solchen Situation nicht überrascht zu werden, und Zeit sowie Fokus nutzen, um eine Gewinnstrategie zu entwickeln
- Wenn Wettbewerber nach Ideen suchen, sind sie immer einen Schritt zurück; besonders in der frühen Phase, wenn Ressourcen knapp sind, kostet die Sorge um Wettbewerb zusätzliche Energie
Wirkung beim Recruiting von Entwicklern
- Eines der großen Probleme, die Startups unabhängig von ihrer Größe haben, ist die Schwierigkeit beim Recruiting von Entwicklern
- Sourcing ist schwierig
- Die Bewertung von Entwicklern ist schwierig
- Es ist schwierig, das Niveau zukünftiger Kollegen überzeugend zu vermitteln
- Open Source kann helfen, das Recruiting-Problem bei Entwicklern zu reduzieren
-
Öffentliches Sourcing
- Alle Entwickler profitieren von Open Source, und viele möchten diesen Nutzen zurückgeben, indem sie zu interessanten Open-Source-Projekten beitragen
- Gründe für Beiträge können eine gute Community, das Erlernen neuer Technologien oder die Freude daran sein, in einer unbekannten Codebasis schwierige technische Probleme zu lösen
- Wenn man die Einstiegshürde für Codebeiträge zu einem Open-Source-Projekt senkt, ist es wahrscheinlich, dass gute Entwickler das Projekt finden
- Mitwirkende können an Issue-Diskussionen, Bugfixes, der Identifikation von Problemen und PR-Reviews teilnehmen
- Nicht alle Mitwirkenden sind auf Jobsuche, aber viele können von der Aussicht angezogen werden, sich in Vollzeit mit Open-Source-Code zu beschäftigen
- Supabase war über 2 Jahre in Betrieb und stellte 32 Entwickler ein, bevor es mit Outbound-Recruiting begann
- Open Source war Supabases wichtigster Kanal zur Talententdeckung und wird es auch künftig sein
- In Remote- und asynchronen Unternehmen sorgt eine Open-Source-Recruiting-Strategie dafür, dass Kandidaten ihre Fähigkeiten selbst sichtbar machen, was deren Überprüfung erleichtert
-
Echte Beiträge statt LeetCode und Take-Home-Tests
- Einer der größten Frustpunkte für Entwickler bei der Suche nach dem nächsten Job ist, im Interviewprozess LeetCode-Aufgaben lösen oder Take-Home-Tests machen zu müssen
- Diese Methoden sind zeitaufwendig und anstrengend und repräsentieren oft nicht die Arbeit, die später tatsächlich gemacht wird
- Wenn jemand zu einem Repository beiträgt, entstehen bereits folgende Materialien
- Beispiele dafür, wie die Person in einem Remote- und asynchronen Umfeld mit Team- und Community-Mitgliedern kommuniziert
- Beispiele für echte Codebeiträge
- Auch Kandidaten können das Unternehmen beurteilen
- Sie können sehen, ob das Team Codequalität wichtig nimmt
- Sie können sehen, ob effektiv kommuniziert wird
- Sie können einschätzen, ob gute technische Entscheidungen getroffen werden
- Die über Supabase-Repositories eingestellten Personen machten sich selbst unentbehrlich; manche leiteten die Entwicklung bestehender Repositories oder starteten neue Client-Bibliotheken und SDKs
- Sie mussten keine LeetCode-Aufgaben auf Zoom lösen
Funktionen und Integrationen für kleinere Nutzergruppen erweitern
- Beim Aufbau eines Startups hat man oft nur Zeit, die größten Probleme zu lösen
- Um schnell voranzukommen, muss man sich auf das konzentrieren, was 80 % der Nutzerbasis anfordern {p:80}
- Funktionen, die nur von kleineren Nutzergruppen gewünscht werden, werden leicht auf unbestimmte Zeit verschoben
- Wenn das System Open Source ist, können diese Nutzer die Funktionen selbst beitragen, wodurch die Nützlichkeit der Software steigt
- Dieser Effekt zeigt sich häufig bei Integrationen und Adaptern
- Nutzer wünschen sich möglicherweise eine Azure- oder Vercel-Integration
- Wenn jemand anderes die Entwicklungsressourcen bereitstellt, um diese Verbindung zu bauen, profitieren alle Nutzer des Projekts
Das Rad nicht immer wieder neu erfinden
- In einer Welt ohne Open Source würden Tech-Unternehmen immer wieder das Rad neu erfinden
- Supabase veröffentlicht neue Projekte nicht nur als Open Source, sondern versucht auch, bestehende Open-Source-Projekte zu unterstützen, bevor es etwas neu baut
- Eine Situation, in der Autohersteller proprietäre Funktionen, proprietäre UI-Elemente, proprietäre Windowing-Bibliotheken, proprietäre Betriebssysteme und proprietäre Treiber verwenden, um Fehlermeldungen anzuzeigen, die kaum jemand je sieht, ist eine Verschwendung von Entwicklerzeit und -aufwand
- Die Supabase Launch Week ist die Sammlung dessen, woran Team und Community in den vergangenen 3 Monaten gearbeitet haben; die Vorteile des Betriebs eines Open-Source-Unternehmens zeigen sich im Tempo der Community
- Weitere Details gibt es im Launch Week 4 post; wer mitmachen möchte, kann Supabase GitHub besuchen
1 Kommentare
Meinungen auf Hacker News
Hier steckt eine große Annahme über nachhaltige Profitabilität drin, die sich insbesondere angesichts von Realitäten wie US-Entwicklergehältern nicht ganz mit der Praxis deckt.
Kurz gesagt: Ein Open-Source-Unternehmen muss zweimal vom Blitz getroffen werden. Einmal beim Open-Source-Projekt und ein weiteres Mal beim Unternehmen.
Das Graphistry-Team liebt und nutzt Open Source jeden Tag, hat den Start von Projekten mit angestoßen, die zu Apache Arrow und Nvidia RAPIDS geführt haben, und hat auch Python-/JS-Clients als Open Source veröffentlicht. PyGraphistry[AI] ist so etwas wie ein Schweizer Taschenmesser für Graphen und umfasst auch Werkzeuge wie GFQL, das eine Cypher-ähnliche Graph-Abfragesprache einbettbar, dataframe-nativ und sogar GPU-beschleunigt umsetzt.
Nachhaltiges Wachstum entsteht bei uns aber vor allem dadurch, dass wir Cloud-/On-Premises-Self-Hosting-Lizenzen für unseren GPU-Graph-Visualisierungsserver an Unternehmen, Behörden und Datenfirmen verkaufen. Nach einigen Jahren des Durchhaltens wächst dieses Geschäft glücklicherweise gut, und allein die SaaS-Hosting-Umsätze reichen zwar, um ein kleines Team zu halten, aber nicht für den Großteil des Teams. Ohne Umsätze aus Self-Hosting-Lizenzen würde der größte Teil unseres Innovationszyklus verschwinden.
Der Artikel scheint die Schnittmenge aus lotterieartigem Glück, Eigenschaften des SaaS-Markts und technischer Verteidigungsfähigkeit zu übersehen. Die Veröffentlichungen von Louie.AI und GFQL verändern in unserem Fall die geschäftlichen Möglichkeiten von Open Source, es ist also nicht unmöglich; aber nach allem, was wir bis hierhin erlebt haben, mache ich mir Sorgen um neue Gründer, die diesen Artikel lesen.
[1] https://graphviz.org/
Mit anderen Worten: Entscheidend ist, ob es Kunden sind, die sagen würden: „Schön, dann kündigen wir den Vertrag“, sobald man sagt: „Wir veröffentlichen jetzt den Source.“
Es hieß: „Wenn ich mit anderen Gründern über Open-Source-Geschäftsmodelle spreche, tauchen immer wieder drei Sorgen auf: Man könnte für unordentlichen, schlechten oder unfertigen Code kritisiert werden; Hacker könnten Sicherheitslücken finden und ausnutzen; Wettbewerber könnten geistiges Eigentum stehlen.“ Meiner Meinung nach fehlt eine vierte.
Amazon/AWS kann auf Basis meines Codes einen Dienst kommerzialisieren und verkaufen, ohne mir irgendetwas zu zahlen.
Im Austausch mit Nutzern und bei Feedback bleibe ich höflich, aber innerlich denke ich: „Reden ist leicht. Ich habe es tatsächlich gebaut. Sei still oder schick einen PR.“ Wenig überraschend schicken solche Leute so gut wie nie einen PR.
Man sollte weiter tatsächlich Dinge bauen und die Nörgler abschütteln.
[0] - https://heywillow.io/
Wenn große Unternehmen versuchen, einen zu kopieren, gewinnt man im Grunde schon; man braucht aber einen Vorabplan, um das abzufedern. Wenn ich den Artikel richtig verstanden habe, soll das jedoch kein Thema sein, auf das man sich in der Anfangsphase konzentrieren oder über das man sich dann Sorgen machen sollte.
Dass Cloud-Unternehmen andere Open-Source-Produkte schlucken, liegt daran, dass diese Produkte keine Lizenz gewählt haben, die ihre Arbeit angemessen schützt.
Ein wirklich tiefgehender, guter Artikel, aber viele Projekte übersehen eines: Verkauft an den zivilen Regierungssektor.
Die US-Regierung hat viele Technologieprogramme wie NSF-Zuschüsse, und weil zivile Behörden, Nachrichtendienste und Bundesstaaten voneinander fragmentiert sind, entsteht am Ende eine enorm große Landschaft für Softwarebeschaffung. Die Eintrittsbarrieren durch Regulierung und Compliance sind auch nicht so hoch, wie man denkt, besonders wenn man die ersten paar Aufträge gemeinsam mit Partnern gewinnt. Üblicherweise handelt es sich um stabile, abgesicherte Umsätze, mit denen sich Projekte über 3–5 Jahre finanzieren lassen, und die Profitabilität ist außerordentlich hoch.
Ich wünschte, mehr Open-Source-Unternehmen würden das nutzen. Denn oft bauen rein private Unternehmen Open-Source-Bibliotheken in ihre Produkte ein, verkaufen sie mit riesigen Margen weiter und streichen alles ein.
Beispiel: https://x.com/ssankar/status/1749202248700420587?s=20
Während meiner Zeit in der Regierung habe ich viel Software gesehen, die im Grunde aus Open-Source-Karten plus Open-Source-DB bestand und trotzdem 12 Millionen Dollar kostete. Als weitere Anhaltspunkte habe ich PDF-OCR für 2 Millionen Dollar pro Jahr gesehen und Tools wie weights & biases für 30 Millionen Dollar pro Jahr.
Neben der Softwarebereitstellung gibt es weitere Anreize. Zum Beispiel die priorisierte Behebung bestimmter Bugs oder Sicherheitsmängel. Nachrichtendienste haben wahrscheinlich viel Geld für safetensors bezahlt.
Für Supabase gäbe es vier Wege: Direktverkauf an Cybercom, Direktverkauf an DOS oder Team-Verträge, Verkauf an die VA über ein PWS, oder Direktverkauf an große Softwareanbieter für Regierungsaufträge.
Die Umsetzung besteht darin, Cold Emails an GS 14/15 oder Gleichrangige zu schicken, einen ehemaligen GS15 einzustellen, auf SAM.gov passende Ausschreibungen zu finden und dann mit GovPro.ai als Full-Service oder mit rogue in Eigenregie Angebote zu erstellen.
Bis die Regierungsbürokratie einen Vertrag endgültig genehmigt, ist den meisten Startups wahrscheinlich schon das Geld ausgegangen.
Verträge können profitabel sein, aber die Bürokratie ist enorm, und man braucht jemanden, der Erfahrung im Umgang damit hat. Das ist nicht für jeden der richtige Weg und kostet viel Zeit und Verhandlung.
Abgesehen von der riesigen Bürokratie ist die Bundesregierung die größte, langsamste und am schwersten zu handhabende Regierungsorganisation. Allein in den USA gibt es Zehntausende andere staatliche Akteure: Schulen, Städte, Countys, Bundesstaaten, Wasser- und Feuerwehrbezirke, Bibliotheken usw.
Wenn man in den öffentlichen Sektor einsteigen will, ist es besser, klein und breit anzusetzen, statt alles auf die größte Stelle zu setzen.
Der profitabelste Regierungssektor der Welt ist das US-Verteidigungsministerium.
Allerdings ist das Verteidigungsministerium unglaublich bürokratisch, extrem terminempfindlich und besessen von Geheimhaltung.
Das Geschäftsmodell von Supabase besteht darin, sich als Open-Source-Unternehmen zu vermarkten, aber in der Praxis würde niemand bei klarem Verstand versuchen, es für die Produktion selbst zu hosten.
Wegen Dingen wie subtil fehlender Dokumentation, subtilen Bugs und subtil fehlenden wichtigen Funktionen. So bekommt man Lob für Open Source, aber praktisch ist es nicht wirklich; ich sehe es einfach als Marketinginstrument.
Erstens ist da die Gelassenheit. Auch wenn man es derzeit nicht selbst hostet, hat man einen zusätzlichen Ausweg, wenn einem der Service nicht mehr gefällt. Natürlich muss auch Zugriff auf die Rohdaten geboten werden.
Zweitens geht es um Codequalität. Wer schon einmal mit Code zu tun hatte, der nach außen gut funktioniert, intern aber wirklich schlimm ist, weiß, wie wichtig es ist, Code zu haben, dessen Veröffentlichung einem nicht peinlich wäre.
Drittens ist da die Möglichkeit beizutragen. Früher hielt ich das für keine große Sache, aber nachdem ich es tatsächlich mehrfach erlebt habe, ist es enorm, bei fehlenden Features, Bugs oder Performance-Problemen etwas anfragen oder selbst beitragen zu können. Bei den meisten Closed-Source-Projekten kann man sich schon glücklich schätzen, wenn es überhaupt einen transparenten Kanal für Feature Requests gibt.
Ab einem bestimmten Schwellenwert können Menschen beschließen, Aufwand in einen Fork zu stecken. MariaDB ist so ein Beispiel.
Es gab auch Leute, die uns direkt gesagt haben, dass sie unseren Managed Service genau deshalb mit gutem Gefühl nutzen.
Es scheint viel einfacher zu sein, ein legitimes und echtes Open-Source-Unternehmen zu sein.
Falls das nicht gemeint war und ich es falsch gelesen habe, lässt der restliche Text Supabase im Gegenteil sehr positiv erscheinen.
Kommerziell mag das vielleicht nicht machbar sein, aber der aktuelle Zustand untergräbt stark die Standards, die man von Open-Source-Software erwarten kann, und ich sehe auch keinen klaren langfristigen Vorteil für die Unternehmen, die diesen Weg wählen.
Es ermöglicht Entwicklern, den Code zu sehen, der tatsächlich läuft, auch wenn sie ihn nicht selbst ausführen.
Ich mag Supabase, ich mag kommerzielle Open Source im Allgemeinen, und ich stimme vielem im Artikel zu.
Aber die Stelle „In Software sind Ideen billig. Der Wert entsteht fast immer bei der Umsetzung der Idee“ fühlt sich für mich etwas schief an.
Diese Formulierung kenne ich aus Situationen wie: „Ich habe eine großartige Startup-Idee, würdest du vor dem Erzählen ein NDA unterschreiben?“
Wenn man Software aber als Open Source veröffentlicht, liefert man nicht nur die Idee, sondern auch einen erheblichen Teil der Umsetzung dieser Idee.
Natürlich ist Code nicht die gesamte Umsetzung; sie reicht weiter in Vertrieb, Marketing, Support und so weiter. Trotzdem behandelt der Artikel den Wert des Codes zu leichtfertig und deutet an, er sei ohne Vertrieb, Marketing usw. wertlos. Das halte ich nicht für richtig.
Wenn ich den Wert aufteilen müsste, sähe ich ihn bei etwa 90 % Vertrieb/Marketing/Kundenvalidierung und 10 % Code. Ich betreibe ein gebootstrapptes SaaS mit Umsatz im niedrigen siebenstelligen Bereich und kann sagen: Der Code ist größtenteils ein Durcheinander und entwickelt sich ständig weiter.
Ein Haus kann man nicht kostenlos kopieren, Software schon.
Entwickler werden für den Prozess bezahlt, Code zu erstellen, und dafür, unsichtbare kleine Probleme zu lösen.
Deshalb ist Softwareverkauf so profitabel. Wenn man die Software nicht verkauft, kann man damit kein Geld verdienen. Software ist nicht wie ein physisches Objekt in der gemeinsamen Realität, in der wir leben.
Für mich ist die zentrale Frage nicht, ob der Code gut genug ist oder ob Wettbewerber ihn kopieren, sondern ob man genug Geld verdienen kann, um ein nachhaltiges Geschäft aufzubauen.
Die zitierten und geliebten Open-Source-Projekte sind keine guten Geschäfte: PostgreSQL, Python, Bitcoin, React.
Mongo und Elastic sind großartig, aber Ausnahmen. Es gibt mehr erfolgreiche Closed-Source-Datenbankunternehmen als Open-Source-Datenbankunternehmen.
Ein Open-Source-Unternehmen zu führen ist schwierig. Für Nutzer ist es aber sehr wertvoll.
Wenn man die Debatte darüber beiseitelässt, welche Lizenz „Open Source“ ist, ist der wichtige Punkt, dass diese Unternehmen zu dem Schluss kamen, dass weit verbreitete Lizenzen wie (A)GPL, Apache und MIT Wettbewerbern viel Spielraum lassen, Managed- bzw. Hosting-Services aufzubauen und über Skalierung zu konkurrieren. Ein Beispiel ist, dass Amazons OpenSearch ElasticSearch günstiger angeboten hat.
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Diese Frage scheint im Sinne von „Soll unser Unternehmen den Source Code unserer Software offenlegen?“ gemeint zu sein.
Für mich bietet jedoch die Beantwortung der ursprünglichen Frage einen Weg, auch die umformulierte Frage zu beantworten. Die ursprüngliche Frage betrifft nicht die Software, die ein Unternehmen verkauft, sondern die Art der Software, die es verwendet.
Persönlich würde ich immer ein Open-Source-Produkt wählen, wenn es eine Alternative gibt. Selbst wenn ich gern für Support zahle oder an das Projekt spende. Der freie Zugang zum Source Code ist für mich grundsätzlich wichtig, selbst bei Software, die ich niemals zu verändern beabsichtige.
Ich weiß, dass das vielen Menschen wie eine extreme Haltung erscheint. Aber ich mag die Vorstellung nicht, eine Mikrowelle, eine Türklinke oder ein Getriebe nicht zerlegen zu können. Vielleicht kann ich es danach nicht wieder richtig zusammensetzen, aber vielleicht finde ich auch ein Zahnrad mit fehlendem Zahn und kann statt eines Austauschs für 90 Dollar eine Reparatur für 2 Dollar machen. Oder ich baue eine Frankenstein-Mikrowelle mit Getriebe.
Für mich ist es wichtig, die Funktionalität eines Webservers zu erweitern oder zu verstehen, warum mein Plugin die Host-App zum Absturz bringt. Ich denke, das ist auch für die Gesellschaft wichtig. Deshalb halte ich an meinem Open-Source-Extremismus fest. Wenn man mir einen modernen winzigen Webserver zeigt, der mit eingebauter KI HTTPS/4 in 5 KB verarbeitet, wäre ich zwar interessiert, aber wenn er nicht Open Source ist, würde ich weiterhin den bestehenden Stack nutzen.
Wegen dieser Haltung ist die Software, die ich baue, Open Source, und manchmal bezahlen Menschen dafür.
Zu der Passage „Wenn Google in sechs Jahren versuchen sollte, einem das Mittagessen zu stehlen, sollte man eine Marke, ein Team und eine Community haben, die sich in den letzten Jahren auf einen David-gegen-Goliath-Kampf vorbereitet haben“: Meiner Erfahrung nach zählen für Einkaufsverantwortliche Dinge wie Marke, Community, Team und Developer Experience im Vergleich zu Compliance so gut wie nichts.
Das gilt besonders, wenn man frontal gegen einen etablierten Anbieter wie Google antritt.
Im Fall von Supabase haben wir uns in den letzten Jahren tatsächlich auf Compliance-Anforderungen wie SOC2, HIPAA und GDPR vorbereitet, daher ist der Hinweis absolut zutreffend.
Auch unser Produkt beschäftigt sich mit dieser Frage. Irgendwann werden wir alles als Open Source veröffentlichen, unter MIT oder Apache, je nachdem, welche Lizenz uns dann besser gefällt; das haben wir auch auf der Website öffentlich gemacht. Es ist kein AGPL- oder Open-Core-Ansatz.
Aber es fühlte sich völlig unmöglich an, mit einem Produkt in einer solchen Struktur Geld zu verdienen, und meine früheren Erfahrungen waren genauso. Consulting ist möglich, aber ein Produkt ist etwas anderes. Supabase hat enorme Venture-Investments erhalten, und fast alle „großen“ Open-Source-Projekte ebenfalls.
Wenn man bootstrapped ist, kann man eine Zeit lang keine Rechnungen stellen, besonders bei ambitionierten und schwierigen Projekten. Menschen können nur für eine begrenzte Zeit kostenlos arbeiten, und wenn ein kleines Team eng und kontinuierlich an nicht öffentlichem Code kommuniziert, kann es den Overhead vermeiden, den ein erfolgreiches Open-Source-Projekt erfordert, und sich deutlich schneller bewegen.
Ich würde gern Beispiele für Projekte ähnlicher Größenordnung hören: 0 Dollar Investment, in den letzten fünf Jahren gestartet, mindestens zwei Vollzeit-Teammitglieder, seit mehr als drei Jahren aktiv und weiterhin mit Empfehlung für diesen Ansatz. Mich interessiert, wie sie ihren Lebensunterhalt bestreiten. Ich glaube, so etwas wie Redis passiert heute nicht mehr. Zumindest habe ich es nicht gesehen. Selbst ein simples Projekt wie langchain hat zig Millionen Dollar Venture Capital bekommen, obwohl ich gerade solche Projekte für Kandidaten gehalten hätte, bei denen ein kleines Team mit mehreren Einnahmequellen Geld verdienen könnte.
Meine gesamte Software veröffentliche ich als Public Domain, also als freie Software, aber nichts davon ist zu einem erfolgreichen Open-Source-Projekt oder einer Community geworden. Freie Software ist vor allem zuerst eine Ideologie und erst danach Praxis oder Funktion.
Ein Unternehmen zu Open Source zu machen ergibt meiner Ansicht nach keinen Sinn, es sei denn, man richtet sich an Entwickler oder baut ein Produkt, das realistischerweise niemand selbst hosten wird.
Supabase ist ein Paradebeispiel für beides. Ein Beispiel für Letzteres ist Plausible Analytics: Man kann es selbst hosten. Ich mache das mit Coolify.io auch so. Aber wenn man kein eigenes CI/CD-System baut, das Updates aus Releases holt und zusammenführt, verpasst man Updates.