- Kommerzielle Open-Source-Unternehmen können sich kaum langfristig halten, wenn sie lediglich eine Alternative zu bestehenden Bezahlprodukten mit MIT-Lizenz anbieten; sie brauchen einen klaren Grund, warum sie Open Source sein müssen, oder ein überlegenes Produkt
- Anders als gemeinnützige oder sponsorenfinanzierte Projekte braucht ein Open-Source-Business Umsatz, um Einstellungen, Wachstum und kontinuierliche Weiterentwicklung zu ermöglichen
- Junge Unternehmen entscheiden sich leicht für ein Free Tier oder eine Open-Source-Version, und Großunternehmen verbuchen SaaS-Kosten als Budgetposten; allein mit günstigeren Preisen lässt sich eine Kaufentscheidung daher nur schwer kippen
- Open Source wird dort stark, wo Closed Source das Vertrauen der Kunden durch Transparenzprobleme erschüttert und wo viele Integrationen und Plug-ins Erweiterbarkeit erfordern
- Die Beispiele PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte und Elastic zeigen, dass Open Source durch Auditierbarkeit, Self-Hosting und Community-Beiträge zu besseren Produkten werden kann
Eine Open-Source-Alternative allein reicht nicht
- Beschreibungen wie „Open-Source-Version von Stripe Billing“ oder „Open-Source-Version von Chargebee“ sind nützlich, um ein Produkt schnell verständlich zu machen, aber als Grundlage für ein dauerhaftes Geschäft sind sie schwach
- Kommerzielle Open-Source-Tools können sich nur schwer allein auf die Positionierung als Open-Source-Alternative zu bereits erfolgreichen Bezahlprodukten stützen
- Es reicht nicht, wenn Entwickler ein Produkt nachbauen und eine MIT-Lizenz daraufsetzen; auch Open Source selbst garantiert keinen Erfolg
- Gegenstand der Diskussion sind kommerzielle Open-Source-Projekte, die mit beliebten kostenpflichtigen Lösungen konkurrieren
- Produkte wie React, TypeORM oder VSCode, die communityzentriert sind oder durch Sponsoring unterstützt werden, haben andere Prioritäten
- React wird von einer größeren Organisation wie Meta unterstützt, und TypeORM finanziert die Entwicklung über Spenden
- Solche Projekte sind im Kern keine Unternehmen
- Damit ein Open-Source-Unternehmen erfolgreich ist, muss es einen klaren Grund geben, warum es Open Source sein sollte, oder es muss die Konkurrenz übertreffen
Erfolg bemisst sich nicht an Nutzung, sondern an Umsatz
- Abgesehen von gemeinnützigen Projekten, die Spenden oder Unterstützung durch eine Muttergesellschaft erhalten, ist der letztliche Maßstab für ein typisches Open-Source-Business Umsatz
- Gewinnorientierte Unternehmen finanzieren über Umsatz Einstellungen, Wachstum, Nachhaltigkeit und kontinuierliche Entwicklung
- Unternehmen, die kostenlose Software entwickeln und trotzdem Umsatz erzielen, sind positive Beispiele; auch Open-Source-Unternehmen wollen Kunden nicht übermäßig ausbeuten, sondern ihr Geschäft fortführen
- MongoDB ist zu einem großen Datenbankunternehmen mit mehr als 4.600 Mitarbeitern gewachsen
- Später wechselte es zur SSPL-Lizenz, um einzuschränken, dass Cloud Provider Dienste bereitstellen, ohne zum Projekt beizutragen
- SSPL ist nicht von der OSI genehmigt, wird aber faktisch als Open Source nahestehend beschrieben
- Bei der Messung langfristigen Erfolgs muss man Akzeptanz und Umsatz unterscheiden
- Selbst bei hoher Projektakzeptanz kann ein Projekt verschwinden, wenn es keinen Umsatz generiert
- Für die Erwartung, dass die Community ein Projekt übernehmen wird, gibt es nach dieser Sichtweise kaum belastbare Belege
Günstiger zu sein ist kein nachhaltiger Wettbewerbsvorteil
- Eine Strategie, die nur auf preissensible Kunden zielt, kommt einem verlorenen Kampf nahe
- Im hypothetischen Beispiel einer Open-Source-Version von Amplitude ließe sich argumentieren, dass Amplitude teuer ist, junge Unternehmen belastet und auch Großunternehmen Kosten sparen könnten
- Doch junge Unternehmen sind preissensibel und entscheiden sich daher wahrscheinlich für eine Open-Source-Version oder ein Free Tier; das reicht nicht aus, um ein Geschäft zu tragen
- Die Strategie, eine günstigere Alternative zu bauen, ist meist eher ein Ticket in die künftige Insolvenz
- Auch Großunternehmen sorgen sich normalerweise nicht darum, wegen der Kosten für Amplitude unterzugehen
- In Vertragsverhandlungen kann der Preis innerhalb des Budgets eine Rolle spielen
- Aber die meisten SaaS-Produkte sind am Ende nur ein weiterer Kostenposten
- Wichtiger ist, ob es eine gute Lösung ist, ob sie langfristig bestehen wird und ob sie leicht zu verwalten ist
- Die Bereitstellung einer Open-Source-Lösung kann administrativ anspruchsvoll sein
- Eine Ausnahme besteht, wenn die Kosten der Lösung einen sehr großen Anteil am Gesamtbudget ausmachen
- Dazu gehören Unternehmen, bei denen Oracle-Kosten wegen der Datenbanknutzung stark gestiegen sind und die Oracle reduzieren mussten
- Die meisten Open-Source-Lösungen ersetzen jedoch keinen der drei größten Kostenposten, weshalb der Preis schwerlich zum wichtigsten Entscheidungskriterium wird
Der erste Weg, wie Open Source gewinnt: Transparenz
- Ein typischer Fall, in dem Open-Source-Lösungen stark werden, liegt vor, wenn Closed Source durch Transparenzprobleme Misstrauen zwischen Kunden und Anbieter erzeugt
- Eine Open-Source-Alternative zu Amplitude ist PostHog
- PostHog ist mit Kunden wie Airbus, DHL und Staples gewachsen
- Es kombiniert mehrere SaaS-Produktlösungen und wird als Open Source angeboten
- Sogar der Quellcode des Blogs und die Roadmap sind öffentlich
- PostHog positioniert sich gegenüber Konkurrenzprodukten als besseres Produkt, weil Analysetools sensible Kundendaten wie IP-Adressen, Namen und Session Recordings verarbeiten
- In einem Umfeld mit zunehmenden Datenvorschriften wie GDPR und CCPA kann es belastend sein, wenn Dritte solche Daten speichern
- PostHog bietet zwei Optionen
- Die Analytics-Lösung selbst self-hosten
- PostHog als Drittanbieter beauftragen, dabei aber Transparenz darüber erhalten, wie Daten gespeichert werden und wie man später zum Self-Hosting wechseln kann
- Selbst wenn Self-Hosting die datenschutzfreundlichste Methode ist, können viele Unternehmen weiterhin ein gehostetes Modell wählen
- Auch dann können sie zeilenweise sehen, wie die Software funktioniert
- Sie können nachvollziehen, wie sie bei Bedarf auf ein Self-Hosting-Modell umstellen
- Open-Source-Unternehmen gewinnen nicht, indem sie die Notwendigkeit eines Drittanbieters beseitigen, sondern indem sie Vertrauen schaffen, weil ihre Funktionsweise öffentlich auditiert werden kann
Produktbeispiele, bei denen Transparenz wichtig ist
- Medplum ist eine Open-Source-Plattform für elektronische Gesundheitsakten, die mit bestehenden Closed-Source-Anbietern konkurriert
- Weil sie Open Source ist, können Nutzer prüfen, was die Plattform genau unterstützt und was nicht
- SuperTokens ist eine Open-Source-Alternative zu Authentifizierungslösungen wie Auth0
- Login verarbeitet sensible Daten wie Name, E-Mail-Adresse und Passwort
- Open Source hilft dabei, mehr Vertrauen zu schaffen
- TableFlow ist eine Open-Source-Alternative zu CSV-Importplattformen wie Flatfile
- Entscheidend ist, dass die importierten Daten sensibel sind
- Minio ist eine Open-Source-Alternative zu AWS S3 Storage
- In S3 können Kunden-PII über Screenshots oder strukturierte JSON-Dateien gespeichert werden
- Für Unternehmen, denen wichtig ist, wer auf Nutzerdaten zugreifen kann, kann Minio eine Alternative sein
- AWS behauptet, dass AWS-Mitarbeiter nicht direkt auf Kundendaten zugreifen, doch bei Closed Source bleibt diese Behauptung eine Vertrauensfrage
- Auch Lago verarbeitet Abrechnungs- und Produktnutzungsinformationen; da diese Informationen sensiblen Inhalten nahekommen, kann Open Source nach dieser Sichtweise besser Nutzervertrauen schaffen
Der zweite Weg, wie Open Source gewinnt: Erweiterbarkeit
- Einer der großen Vorteile von Open Source ist, dass die Entwicklung von Nischenfunktionen für die Community offensteht
- Das Kernprodukt wird üblicherweise von einem zentralen Engineering-Team gepflegt, aber Integrationen oder Plug-ins werden von Community-Entwicklern erstellt und gelegentlich in den Main Branch gemergt
- Closed-Source-Lösungen müssen sich auf ihr eigenes Engineering-Team stützen und lassen sich deshalb nicht auf dieselbe Weise erweitern
- Für Open-Source-Unternehmen, die Systeme bauen, die mit vielen Libraries, Frameworks und Anwendungen verbunden werden müssen, ist dieser Punkt besonders vorteilhaft
- Airbyte ist eine Open-Source-ELT-Plattform, die dank von der Community hinzugefügter Connectoren stark gewachsen ist
- Auch Elastic ist ein größeres Unternehmen, das ursprünglich Open Source war und zahlreiche Datenintegrationen anbietet
- SuperTokens machte Erweiterbarkeit zu seinem zentralen Wertversprechen; Community-Mitglieder können Integrationen mit weniger verbreiteten Authentifizierungsanbietern bauen, was allen zugutekommt
Der dritte Weg, wie Open Source gewinnt: ein besseres Produkt
- Transparenz und Erweiterbarkeit tragen dazu bei, dass kommerzielle Open-Source-Angebote langfristig zu besseren Produkten werden
- Open-Source-Projekte können Feedback und Hilfe der Community nutzen und sich schneller entwickeln als Closed-Source-Lösungen
- PostHog begann als Alternative zu Amplitude und FullStory, wuchs später aber zu einer großen, umfassenden Lösung heran, die auch mit LaunchDarkly und Pendo konkurriert
- PostHog hat eine Series-B-Finanzierung in Höhe von 15 Millionen US-Dollar eingeworben
- Dieses Wachstum fand in den vergangenen Jahren statt, und PostHog sieht die Community als einen der zentralen Gründe dafür
- Open-Source-Projekte sind nicht auf kommerzielle Open-Source-Angebote beschränkt, sondern dienen seit Jahrzehnten als wichtiger Motor für Produktverbesserungen
- Manche Software kann aufgrund von First-Mover-Effekten proprietär bleiben
- In Bereichen, in denen Transparenz und Erweiterbarkeit problematisch sind, können Open-Source-Nachzügler jedoch zu einer echten Bedrohung werden
3 Kommentare
Ich bin beim Suchen zufällig darauf gestoßen und frage mich nun, wann die KI solche wortwörtlichen Übersetzungen aus dem Englischen wie „durch Billigkeit“ endlich korrigieren wird.
Das ist das Ergebnis einer heutigen Ausführung von Claude 4.5 Sonnet (2026-01-12)
„Open Source gewinnt nicht, weil sie günstiger ist“
Prompt
Open Source gewinnt nicht einfach deshalb, weil der Preis niedrig ist.
Die Erfolgsfaktoren von Open Source liegen nicht in niedrigen Kosten, sondern anderswo.
Open Source setzt sich nicht wegen eines niedrigen Preises durch.
Meinungen auf Hacker News
Der Begriff Gewinn (profit) wirkt hier seltsam und unklar.
Ich habe fast 24 Jahre lang Open-Source- und freie-Software-Projekte betrieben, davon etwa 17 Jahre auch mit Umsatz, aber es gab keinen „Gewinn“, nur Umsatz (revenue).
So wie Unternehmen oder Buchhalter es üblicherweise sehen, ist Gewinn das Geld, das übrig bleibt, nachdem Vergütungen und Kosten der am Projekt beteiligten Personen abgezogen wurden.
Open-Source-Projekte, die Gewinn in diesem Sinne brauchen, sind eigentlich nur solche, die Kapitalinvestitionen erhalten haben, bei denen Investoren eine „Rendite“ erwarten. Solche Projekte gibt es, aber sie sind nicht die Mehrheit.
Außerdem ist der Text, wie für HN-Beiträge typisch, insgesamt viel zu stark auf Web/SaaS ausgerichtet. Kaum zu glauben, aber es gibt auch andere Arten von Open-Source-Projekten.
In diesem Kontext ist das, was nach Einnahmen und bezahlten Kosten übrig bleibt, Gewinn; zu diesen Kosten gehören Dinge wie feste Gehälter, Arbeitsverträge und Gehaltsabrechnungen.
Wie ein Unternehmen seinen Gewinn verwendet, kann sehr unterschiedlich sein. Es kann ihn als Cash-Reserve aufbauen, um auch in Monaten mit niedrigerem Umsatz die Kosten zu decken, Vermögenswerte wie neue Hardware kaufen oder zusätzliche Einstellungen ermöglichen. Seltener, als man denkt, kann er auch als Dividende an die Eigentümer ausgeschüttet werden.
Zu deiner Situation kann man ohne viele Details nur mutmaßen, aber wenn du allein arbeitest, das Projekt klein ist und du keinen Bedarf oder Willen hast, Mitarbeiter aufzubauen, dann ist der Umsatz faktisch eher persönliches Einkommen. In manchen Monaten bekommst du mehr, in anderen weniger; in diesem Kontext ist es richtig, von Umsatz und nicht von „Gewinn“ zu sprechen.
Das gilt besonders bei Software, wenn es kaum sonstige Gemeinkosten gibt und das Nachverfolgen von Kosten für Steuerzwecke wenig Bedeutung hat; vielleicht führst du nicht einmal eine richtige Buchhaltung. Wenn das deine Situation ist, verstehe ich, warum der Artikel nicht bei dir verfängt. Er behandelt eine ziemlich andere Lage.
Wenn keine reinen Investoren laufende Renditen verlangen, nimmt der Druck deutlich ab, und es wird einfacher, das zu tun, was zum Projekt passt.
Aber in Produktbereichen, in denen man mit ambitionierten Unternehmen konkurriert, ist Wachstum ebenfalls nötig und wahrscheinlich vernünftig.
Gewinn zurückzubehalten, um auf Abschwünge, Chancen und große Ausgaben vorbereitet zu sein, ist nicht nur irgendwie rational. Je mehr Beteiligte und Kunden es gibt, desto mehr Gründe gibt es, nicht den gesamten eingehenden Umsatz zu verbrennen.
In großen Unternehmen sind diese beiden Zahlen tatsächlich oft unabhängig voneinander; jede wird danach definiert, wem sie übermittelt wird und welche Regeln für diese Übermittlung gelten.
Es kann auch so etwas wie „Management-Gewinn“ geben, ein Sammelbegriff für nicht standardisierte und nicht regulierte Kennzahlen. Ein Unternehmen kann zum Beispiel für Steuer- und Investorenberichte von der Kassenbuchführung abgekommen sein, während es für das bestehende Management weiter nützlich ist, die frühere Definition von Gewinn zu verfolgen. Das kann aus Gewohnheit so sein, weil sie den Cashflow gut abbildet oder weil sie auf andere Weise nützlich ist.
Das ist eines dieser postmodernen Probleme. Die SEC, der IRS oder der Bankbetreuer akzeptieren keine Formulierungen wie „SEC-Gewinn“, sondern verlangen den „echten“ Gewinn. Das erinnert an lokale Politiker, die ein Krankenhaus naiv fragen, wie viel es den Bauunternehmer „wirklich“ gekostet hat.
Jedenfalls verwendet auch der Autor Begriffe aus seiner eigenen Perspektive, ähnlich wie SEC oder IRS. Wenn er sagt: „Open Source gewinnt nicht, weil es billiger ist“, meint „Open Source“ hier Open-Source-Geschäfte nach einem Modell wie MongoDB. Deshalb werden Investoren, Wachstumsziele und Ähnliches vorausgesetzt.
Da der Artikel das selbst klarstellt, gibt es wenig Anlass für semantisches Knurren.
Das Problem dieses Geschäftsmodells ist, dass es Spannungen zwischen der OSS-Version und der Bezahlversion erzeugt.
Man möchte, dass die OSS-Version gut ist, aber sie darf nicht so gut sein, dass niemand mehr das Bedürfnis hat, für SaaS, Consulting usw. zu zahlen.
Diese Spannung scheint am Ende dazu zu führen, dass offensichtlich nötige Features fehlen oder dass Funktionen und Wissen, die für den Betrieb in großem Maßstab nötig sind, zur Monetarisierung des Sponsor-Unternehmens hinter Closed Source versteckt werden.
Wenn das Produkt Infrastruktur-Charakter hat, hat sich auch schon das Muster etabliert, wie bei Elastic oder Hashicorp auf eine Lizenz umzusteigen, die nur Anschauen erlaubt, aber kein Anfassen, damit große Cloud-Anbieter es nicht als One-Click-Service vereinnahmen können.
Das heißt nicht, dass der Artikel falsch ist, aber ich wünschte, kommerziell gesponserte OSS würde nicht so tun, als sei sie für alle ein kumbaya-artiges Win-win. In Wirklichkeit ähnelt die Struktur eher einem Startup, das Open Source als Growth Hack nutzt, um Vertrauen aufzubauen, und dann, wenn der Zeitpunkt kommt, Umsatz zu machen, die Community, die beim Wachstum geholfen hat, auf irgendeine Weise enger zieht.
Ich habe jahrelang ein kleines Modul gepflegt und dabei viele Feature Requests und Support-Anfragen bekommen. Bis ich genug verdiene, um meine Miete zu zahlen, habe ich nicht das geringste schlechte Gewissen, dafür Geld zu verlangen.
Sogar für das Drücken des Merge-Buttons bei einem Pull Request stelle ich eine Rechnung, wenn auch nur eine Sekunde meiner Zeit hineinfließt. In den Code habe ich Monate, Jahre gesteckt, und ich habe ihn der Welt kostenlos zugänglich gemacht.
Wenn man zusätzliche Features oder meine Zeit braucht, muss man bezahlen.
Dass viele Unternehmen das nicht schaffen, heißt nicht, dass dieses Geschäftsmodell nicht funktioniert, sondern eher, dass es sehr schwer ist, es richtig zu machen.
Wenn man aber davon ausgeht, dass die meisten Menschen im Großen und Ganzen gut sind, lohnt es sich auch, in Betracht zu ziehen, dass solche Unternehmen oder Leute ihren Marktzugang falsch angegangen sind. Es kann eher Unfähigkeit als böse Absicht sein.
Wenn vom ersten Tag an transparent gemacht wird, was für immer kostenlos ist und was irgendwann kostenpflichtig wird, würde ich das nicht als Verrat an der Community sehen.
Natürlich unter der Voraussetzung, dass die Roadmap eingehalten und anhand von Feedback und Beiträgen angepasst wird.
Bezahlter Support oder Erweiterungen können ohnehin in dem kommerziellen Bereich bleiben, in dem Software den Großteil des Geldes verdient.
Das passt nicht zu jedem Use Case, muss es aber auch nicht. Der Großteil des Computings sollte persönlich sein.
Es heißt, „MinIO ist eine gute Alternative für Unternehmen, denen wichtig ist, wer auf Nutzerdaten zugreift“. Aber könnte ein Unternehmen nicht behaupten, es hoste Open-Source-Software, während es tatsächlich interne Closed-Source-Software verwendet, die nur dieselben API-Endpunkte nachahmt?
Dann braucht man immer noch dieselbe Art von Vertrauen wie bei AWS.
Man sollte nicht annehmen, dass Self-Hosting ein hohes Sicherheitsbewusstsein bedeutet. In den meisten Unternehmen wird On-Premises-IT wie HVAC oder Elektroinstallation behandelt, nur lästiger.
Jeder in Arbeitskleidung kann sich am Empfang den Schlüssel zum Serverraum erschwindeln.
Es heißt nur, dass der Anbieter den Quellcode teilt, von dem er sagt, dass er hinter seinem Dienst läuft.
Selbst wenn dieser Code exakt stimmt, ist es unwahrscheinlich, dass er der einzige Code ist, der hinter dem „offiziellen“ Dienst läuft. Und Nutzer können ihn nicht selbst bauen und auf deren Server deployen.
Open Source hat nur dann wirklich Bedeutung, wenn man selbst hostet; andernfalls unterscheidet es sich praktisch nicht von proprietärer Software. Alles hängt vom Vertrauen in den Anbieter ab und, wenn möglich, vom Vertrag.
Wenn zum Beispiel im Vertrag steht, dass Daten in diesen Open-Source-Code hinein- und wieder herausgehen und nicht woandershin gelangen, und Verfahren aufgelistet sind, die das sicherstellen sollen, das Ganze aber eine unverhohlene Lüge ist, dann wird das auf klare und durchsetzbare Weise zu einem großen Problem.
Es wäre auch schwer, das vor internen Mitarbeitern zu verbergen, und Menschen kommen und gehen. Wenn es nicht der Realität entspricht, ist es unwahrscheinlich, dass man eine solche Behauptung aufstellt.
Der Autor stellt klar, dass er konkret von Open-Source-Lösungen spricht, die mit kostenpflichtigen Produkten konkurrieren.
Persönlich denke ich, dass in diesem Kontext noch nicht entschieden ist, ob Open Source „gewinnt“.
In den letzten zehn Jahren ist die Zahl der Open-Source-Produkte stark gewachsen, und in den letzten etwa fünf Jahren hat man auch gesehen, dass sich viele davon wieder von Open Source entfernen. MongoDB, der Hashicorp-Stack, Elastic, Red Hat, MinIO usw. sind Beispiele dafür.
Es gibt nicht mehr viele Produkte, die wirklich Open Source und zugleich kommerziell konkurrenzfähig sind, und viele davon versuchen gerade zu beweisen, dass dies ein tragfähiges Geschäftsmodell ist.
Vor ein paar Wochen habe ich bei einer internen Firmenveranstaltung zu diesem Thema gesprochen, und in ein paar Wochen werde ich es auch auf der GoWest erneut vorstellen.
Die zentrale Prämisse ist, dass eine Open-Source-Lizenz wörtlich genommen Freiheit gewährt, aber nicht die anderen Dinge liefert, für die Unternehmen zu zahlen bereit sind. Eine proprietäre Lizenz liefert, was Unternehmen brauchen, opfert dafür aber Freiheit.
Ich glaube, dass es ein drittes Modell gibt, das in der Mitte funktioniert, ohne bei Freiheit oder Vertrauenswürdigkeit Kompromisse zu machen. Indem man Open Source bleibt und die Lücke zu dem, was Unternehmen brauchen, durch Sponsoring füllt, kann das für manche Projekte funktionieren.
Wir gestalten die Caddy-Website gerade mit dieser Botschaft neu und hoffen, dass es gut funktioniert.
Ist das mit „sich von Open Source entfernen“ bei MinIO gemeint?
Der Titel ist dumm. Natürlich gewinnt Open Source, weil es günstiger ist.
Was der Autor sagen will, ist, dass ein Open-Source-Geschäft nicht gewinnt, weil es günstiger ist.
Eine Open-Source-Codebasis gewinnt immer, weil sie günstiger ist. Niemand bezahlt für Kompressionsalgorithmen, Network-Time-Daemons oder Media-Transcoder. Open Source hat solche Märkte vollständig ausgelöscht.
Nur ist es nervig, dass der Titel wörtlich genommen wegen eines einzigen Wortes falsch ist.
Ich habe die vorherigen Absätze noch einmal gelesen, weil ich dachte, ich hätte etwas übersehen.
Aus Sicht eines Engineers, der Einfluss auf die Einführung von Technologie hat, gewinnt Open Source durch Verständlichkeit.
Wenn meine Kollegen und ich den Quellcode einsehen können, können wir beurteilen, ob das Produkt die behaupteten Funktionen erfüllen wird.
Wenn wir im Einsatz auf einen Bug oder einen unerwarteten Anwendungsfall stoßen, können wir zumindest eine Lösung untersuchen und im Bugreport vorschlagen, oder sogar einen PR öffnen.
Dadurch kann man schnelle Workarounds bauen und in der Regel auch Bugreports einreichen.
Unternehmen interessiert der Code selbst nicht besonders. Selbst wenn doch, können Business-Continuity-Klauseln die meisten Bedenken gegenüber Closed Source ausräumen.
Wie viele Finanzunternehmen sind am Ende von Excel auf OpenOffice Calc umgestiegen?
Die Go-to-Market-Strategie von AWS beruhte darauf, Startups und einzelne Entwickler mit günstigen Pay-as-you-go-Diensten anzuziehen, und das hat sehr gut gepasst. Denn Airbnb, Stripe, Twitch usw. wuchsen zu großen Unternehmen heran und wuchsen mit AWS mit.
Es gibt nicht viel, das mit niedrigen Kosten oder kostenlos konkurrieren kann. Später kann man dann in den oberen Markt aufsteigen. Fragt ARM und Intel.
Für neue Unternehmen im Bereich Entwicklertools ist Open Source praktisch zur Standard-Go-to-Market-Strategie geworden. Wie der Artikel richtig feststellt, ist es aber kein Geschäftsmodell.
Wenn man also nicht auf Snowflake-Niveau herausragend ist und zugleich mit dem freien und Open-Source-Lager wie Databricks mithalten kann, ist das Open-Core-Modell besser.
Wenn sie es selbst kompilieren können, bevorzugen sie das deutlich.
Wenn man Postgres selbst auf physischen Servern betreibt, werden Investoren sich entweder nicht darum kümmern oder schwierige Fragen dazu stellen, wie viel Zeit man verschwendet hat. Dann braucht man eine ziemlich gute Antwort oder Investoren, die dafür Verständnis haben.
Es überrascht mich, dass Vendor Lock-in nicht erwähnt wurde. Das ist ein klares Verkaufsargument von Open Source.
Natürlich hängt es von Organisation und Personen ab, und viele kümmern sich bei einem Unternehmen, dem sie vertrauen, nicht um Lock-in, aber es ist definitiv nicht null.
Als ich bei Red Hat als OpenShift-Consultant gearbeitet habe, habe ich viele Führungskräfte getroffen, die sich wegen Vendor Lock-in sorgten. Für sie war die Wahl von OpenShift eine naheliegende Entscheidung.
Das ist nur am Rande mit dem Bereich Softwareverkauf verwandt, aber vor langer Zeit habe ich ein User-Interface-Update für ein schlecht designtes Spiel verkauft.
Ich setzte den Preis auf das Doppelte des Spiels selbst fest, und trotzdem kauften es die Leute. Weil es professionell gestaltet war.
Als professioneller Designer habe ich mir Zeit von meiner eigentlichen Arbeit genommen und etwas getan, was der Entwickler vermutlich nicht konnte.
Der deutlichste Kritikpunkt in den Kommentaren der digitalen Vertriebsplattform, auf der es damals verkauft wurde, war, dass das Update zu teuer sei, und die Leute kommentierten natürlich die Preispositionierung.
Aber eines war klar: Das Spiel selbst war zu billig.
Wenn Leute sich nur über den Preis beschweren und trotzdem weiter kaufen, heißt das, dass es sonst nichts gibt, worüber sie sich beschweren könnten.
Vögel wollen immer kostenloses Futter. Man sollte sich nicht nach den Vögeln richten.
Nebenbei: Das Update wurde auch illegal verbreitet und war unter Raubkopienutzern recht verbreitet. Da die meisten Kunden bezahlt haben, war ich eher froh darüber.
Außerdem war klar, dass ich ein Bündel gewünschter Funktionen abdeckte, das anderswo nicht angeboten wurde. Solche Probleme sind als Symptom dafür, dass man etwas gebaut hat, was Leute wollen, ziemlich gute Probleme.
Viele Open-Source-Projekte werden meiner Ansicht nach nicht aus freien Stücken, sondern aus Notwendigkeit Open Source
Manche Produkte müssen als Open Source entwickelt werden, damit sie überhaupt eine Chance auf Akzeptanz haben
Der Autor konzentriert sich auf einige wenige elitäre Open-Source-Projekte, und diese repräsentieren nicht die große Mehrheit der Open-Source-Projekte
Manche Unternehmen verfügen über die richtigen Kontakte in Wirtschaft und Regierung und können Produktlizenzen daher leicht teuer verkaufen, aber solche Fälle sind selten
Die meisten Menschen und kleinen Unternehmen haben kein solches Netzwerk. Ohne die passenden Geschäftsbeziehungen ist es schwierig, überhaupt etwas Geld zu verdienen
Es spielt keine Rolle, wie gut das Produkt ist oder wie stark es die Kosten von jemandem senken kann. Niemand vertraut ihm, niemand probiert es aus. Selbst wenn der langfristige Nutzen enorm sein könnte, ist die Hürde für die Einführung zu hoch
Ein Produkt Open Source zu machen, ist die einzige Möglichkeit, überhaupt einen Fuß in die Tür zu bekommen. Es gibt dem Produkt eine winzige Chance, wahrgenommen zu werden, und manchmal ist das alles