Wie Open-Source-Unternehmen Geld verdienen

Von Brian Tr · Aktualisiert am 2. Oktober 2026

Ein Open-Source-Unternehmen verschenkt sein Kernprodukt und muss trotzdem Gehälter zahlen. Das klingt nach einem Widerspruch, und es ist die erste Frage, die jeder Gründer und Investor zu diesem Modell stellt. Die Antwort lautet: Der Code ist selten das, was verkauft wird. Kunden zahlen für alles rund um den Code: jemanden, der ihn betreibt, unterstützt, zertifiziert, erweitert oder die rechtliche Verantwortung dafür übernimmt.

Dieser Artikel erklärt, was „Open Source“ tatsächlich bedeutet, auf welchen Wegen Unternehmen daraus Umsatz machen und welcher Spannungsbogen mehrere bekannte Unternehmen zwischen 2021 und 2026 dazu brachte, ihre Lizenzen zu ändern. Er ist ein Nachschlagewerk zum Geschäftsmodell, keine Rechtsberatung, und er vergleicht keine aktuellen Anbieterpreise. Einen Überblick über weitere Wege, wie Startups Geld verdienen, finden Sie bei den SaaS-Preismodellen.

Was „Open Source“ tatsächlich bedeutet

„Open Source“ ist kein loses Synonym für „kostenlos“ oder „der Code ist öffentlich“. Die Open Source Initiative (OSI) pflegt die Open Source Definition, eine Liste von zehn Kriterien, die eine Lizenz erfüllen muss. Drei davon sind für Geschäftsmodelle am wichtigsten:

• Freie Weitergabe. Die Lizenz darf niemanden daran hindern, die Software zu verkaufen oder zu verschenken.
• Abgeleitete Werke. Die Lizenz muss Änderungen und abgeleitete Werke erlauben.
• Keine Diskriminierung von Einsatzbereichen. Die Lizenz darf niemanden daran hindern, das Programm in einem bestimmten Bereich zu nutzen, wozu in der Praxis auch der kommerzielle Betrieb gehört.

Genau beim letzten Kriterium kollidieren Geschäftsmodelle mit der Definition. Eine Lizenz, die sagt „jeder darf dies nutzen, außer um es als konkurrierenden gehosteten Service zu verkaufen“, schränkt einen Einsatzbereich ein. Das kann eine völlig vernünftige kommerzielle Entscheidung sein, doch nach Lesart der OSI ist es kein Open Source. Genau das sagte die OSI zur Server Side Public License (SSPL) in einer Stellungnahme vom Januar 2021 und nannte es Täuschung, solche Software als Open Source zu bezeichnen.

Es gibt also im Kern zwei Lager:

Der Rest dieses Artikels hält beide auseinander. Die Unterscheidung ist wichtig für Kunden (was dürfen sie tun?), für Mitwirkende (bleibt meine Arbeit offen?) und für Gründer (was kann ich versprechen?).

Das Paradox, den Kern zu verschenken

Wenn jeder das Produkt kostenlos herunterladen, verändern und betreiben kann, warum sollte dann jemand zahlen? Open-Source-Unternehmen antworten auf vier Arten:

1. Den Aufwand verringern. Software gut zu betreiben ist schwer. Kunden zahlen dafür, dass jemand anderes sie betreibt.
2. Das Risiko verringern. Große Organisationen wollen einen Anbieter, den sie anrufen können, ein Security-Response-Team und eine rechtliche Garantie.
3. Hinzufügen, was der kostenlosen Version fehlt. Funktionen, die vor allem großen Teams wichtig sind (Zugriffskontrollen, Audit-Logs, Single Sign-on), werden separat verkauft.
4. Das Recht zu verlangen schützen. Manche Unternehmen halten den Code zum Lesen offen, beschränken aber, wer ihn weiterverkaufen darf.

Das Verschenken des Kerns dient auch als Distribution. Entwickler übernehmen, was sie ohne Beschaffungsprozess ausprobieren können, und ein Unternehmen, das diese Akzeptanz gewinnt, hat einen eingehenden Vertriebskanal. Das ähnelt der Logik von Product-led Growth und Freemium-Geschäftsmodellen, mit einem Unterschied: Ein kostenloser Nutzer von Open-Source-Software kann den Code auch forken, selbst hosten und nie Kunde werden.

Die wichtigsten Monetarisierungsmodelle

1. Support und Abonnements (das Red-Hat-Modell)

Das älteste Modell verkauft Sicherheit rund um freie Software. Red Hat ist das Standardbeispiel. IBMs Ankündigung vom Oktober 2018 über die Vereinbarung, Red Hat für $190 je Aktie zu übernehmen, bei einem Unternehmenswert von rund $34 Milliarden, beschrieb das Zielunternehmen als führenden Anbieter von Open-Source-Software für Unternehmen, darunter Linux-, Hybrid-Cloud-, Container- und Kubernetes-Technologien.

Wofür zahlt ein Red-Hat-Kunde? Die eigene Abonnement-FAQ nennt Patches, Fehlerbehebungen, Updates und Upgrades, technischen Support mit 24/7-Verfügbarkeit sowie Zertifizierungen für Hardware, Software und Cloud-Anbieter. Sie hält auch fest, dass ein Kunde, der ein Abonnement auslaufen lässt, Sicherheits-Errata, Fehlerbehebungen und technischen Support verliert. Das Produkt ist also eine gewartete, zertifizierte, unterstützte Version und nicht der Quellcode selbst.

Wo es funktioniert: Infrastruktursoftware, die große Organisationen produktiv betreiben und deren Ausfall sie sich nicht leisten können. Wo es Mühe hat: Der Vertrieb ist langsam und aufwendig, und das Modell skaliert mit Menschen und Vertrauen, nicht mit Downloads.

2. Open Core

In einem Open-Core-Unternehmen ist das Basisprodukt Open Source, und ein Satz zusätzlicher Funktionen ist proprietär und kostenpflichtig. Die Extras sind meist das, wonach große Organisationen fragen: erweiterte Sicherheit, Governance, Werkzeuge für Skalierbarkeit, offizielle Integrationen und dedizierter Support.

Die strategische Frage ist, wo man die Grenze zieht. Steckt zu wenig in der kostenlosen Version, hat die Community keinen Grund, sie zu übernehmen. Steckt zu viel darin, hat niemand einen Grund zu zahlen. Gründer nutzen oft einen einfachen Test: Funktionen, die einem einzelnen Entwickler helfen, bleiben kostenlos, und Funktionen, die einer Organisation bei der Koordination helfen (Berechtigungen, Compliance, Administration), sind kostenpflichtig.

Das Risiko ist das Vertrauen. Wenn ein Unternehmen eine Funktion aus der kostenlosen in die kostenpflichtige Stufe verschiebt, kann die Community das als Verrat lesen, und ein Fork kann folgen.

3. Managed Cloud (gehosteter Service)

Der größte Teil der heutigen Open-Source-Erlöse stammt daraus, die Software für Kunden zu betreiben. Das Unternehmen hostet sie, übernimmt Upgrades, Backups und Skalierung und berechnet Nutzung oder Kapazität. Das ist das SaaS-Modell, angewandt auf ein Open-Source-Produkt, und die Preismechanik behandelt der Artikel zur nutzungsbasierten Preisgestaltung.

MongoDB zeigt, wie groß das werden kann. In seiner Ergebnismitteilung für das Geschäftsjahr 2026 (Geschäftsjahr zum 31. Januar 2026) meldete MongoDB einen Gesamtumsatz von $2,46 Milliarden, wovon der Cloud-Service Atlas rund $1,81 Milliarden ausmachte, etwa 73 %. Das ist die Zahl eines einzelnen Unternehmens für ein Geschäftsjahr, kein Branchenrichtwert, und MongoDBs Kerndatenbank ist Source-available und nicht Open Source (dazu unten mehr).

Wo es funktioniert: Produkte, die mühsam zu betreiben sind, sodass Bequemlichkeit etwas wert ist. Wo es Mühe hat: Jeder mit einem Cloud-Konto kann denselben Service anbieten, auch die größten Cloud-Anbieter. Das ist die Wurzel der unten beschriebenen Lizenzstreitigkeiten.

4. Dual Licensing

Beim Dual Licensing wird derselbe Code unter zwei Lizenzen angeboten. Die eine ist eine kostenlose, meist Copyleft-Lizenz, die jeden, der darauf aufbaut, verpflichtet, den eigenen Quellcode zu denselben Bedingungen weiterzugeben. Die andere ist eine kostenpflichtige kommerzielle Lizenz für Unternehmen, die die Software ohne diese Pflicht in ein geschlossenes Produkt einbetten wollen.

Es funktioniert am besten für Bibliotheken und Komponenten, die andere Unternehmen in ihre eigenen Produkte einbetten. Für Endanwender-Anwendungen funktioniert es schlecht, da dort niemand eine Ausnahme von den Copyleft-Bedingungen braucht. Außerdem muss das Unternehmen in der Regel die Rechte zur Neulizenzierung besitzen, und hier kommen Contributor-Vereinbarungen ins Spiel (siehe unten).

5. Source-available und Lizenzwechsel

Eine wachsende Gruppe von Unternehmen veröffentlicht heute Quellcode unter Lizenzen, die die kommerzielle Nutzung einschränken, meist um zu verhindern, dass Wettbewerber das Produkt als gehosteten Service weiterverkaufen. Gängige Beispiele sind die SSPL, die Business Source License und Lizenzen im Fair-Code-Stil. Diese Lizenzen erlauben Kunden, den Code zu lesen, auszuführen und zu verändern, und lassen dem Anbieter das ausschließliche Recht, ihn als Service zu verkaufen.

Einige dieser Lizenzen wandeln sich nach einer festen Frist in eine vollständig offene Lizenz um. So lässt sich versprechen, irgendwann offen zu sein, und zugleich ein Vorsprung für den Moment schützen.

6. Spenden, Sponsoring und Stiftungen

Nicht jedes Open-Source-Projekt ist ein Unternehmen. Viele werden von Freiwilligen gepflegt, von Sponsoren finanziert oder in Stiftungen angesiedelt. Die Apache Software Foundation etwa bittet bedeutende Mitwirkende, eine individuelle Contributor-Lizenzvereinbarung zu unterzeichnen, damit die Stiftung das Projekt verteidigen kann, falls ein Rechtsstreit über die Software entsteht. Stiftungen geben Projekten neutrale Governance und rechtlichen Schutz, aber sie bezahlen keine Gründer. Rund um Stiftungsprojekte wachsen oft kommerzielle Unternehmen, die Support oder Hosting verkaufen, was in die Modelle 1 bis 3 zurückfließt.

Die Modelle im Vergleich

Die meisten realen Unternehmen kombinieren mehrere. Ein typisches Produkt hat einen kostenlosen Open Core, eine gehostete Version, eine Enterprise-Stufe und eine Support-Option.

Das Hyperscaler-Problem und die Relizenzierungswelle von 2021 bis 2026

Managed Cloud ist das profitabelste Modell und zugleich das, das ein größerer Wettbewerber am leichtesten kopieren kann. Wenn die Lizenz es erlaubt, kann ein Cloud-Anbieter eine Open-Source-Datenbank oder ein Werkzeug hosten, dafür Geld verlangen und wenig zurückgeben. Open-Source-Anbieter nennen das „Strip-Mining“.

Mehrere Unternehmen reagierten mit Lizenzänderungen. Jede der folgenden Ankündigungen stammt vom Unternehmen selbst.

Beim gemeinsamen Lesen dieser Ankündigungen fallen einige Dinge auf.

Die Begründungen sind einheitlich. Elastic sagte, die Änderung solle verhindern, dass Anbieter seine Software als Service anbieten, ohne etwas zurückzugeben. HashiCorp argumentierte, manche Anbieter profitierten von Open-Source-Arbeit, ohne beizutragen. Redis sagte, der Großteil seiner kommerziellen Verkäufe laufe über die größten Cloud-Service-Anbieter.

Ehrlichkeit beim Label zählt. Redis erklärte offen, dass seine neuen Lizenzen die OSI-Definition nicht erfüllen und dass es die kostenlose Version „Community Edition“ statt Open Source nennen werde. Die OSI vertritt zur SSPL dieselbe Ansicht.

Rückzieher kommen vor. Elastic und Redis ergänzten beide später die OSI-anerkannte AGPL als Option. Redis sagte, die frühere Änderung habe das Verhältnis zur Community beschädigt, und Elastic sagte, der Schritt sei von Sorgen über Amazons Praktiken getrieben gewesen, die Lage habe sich aber inzwischen geändert. Für einen Gründer lautet die Lehre nicht, dass eine bestimmte Lizenz die richtige ist. Sie lautet, dass ein Lizenzwechsel eine Geschäftsentscheidung mit Kosten bei der Community ist, die über Jahre nachwirken können.

Manche Lizenzen enthalten eine Uhr. Directus sagt, jede Version seiner Software werde nach vier Jahren unter der GPLv3 vollständig Open Source, und nach seinen Schwellenwerten können Organisationen mit weniger als $5 Millionen Jahresumsatz und 50 Beschäftigten sie kostenlos nutzen. Eine zeitverzögerte Lizenz versucht, den Anbieter jetzt zu schützen und das Open-Source-Versprechen später einzulösen.

Community gegen Umsatz: die zentrale Spannung

Kommerzielle Open-Source-Unternehmen leben mit einem dauerhaften Konflikt. Die Community will stabile, kostenlose, freizügig lizenzierte Software. Investoren und Beschäftigte wollen wachsenden Umsatz. Jede Monetarisierungsentscheidung verschiebt das Gleichgewicht.

Einige praktische Druckpunkte:

• Feature-Gating. Eine bestehende Funktion hinter eine Paywall zu verschieben, bricht ein ungeschriebenes Versprechen gegenüber Nutzern und Mitwirkenden.
• Governance. Kontrolliert ein Unternehmen die Roadmap, wandern externe Mitwirkende womöglich ab. Eine Stiftung gibt neutrale Kontrolle, nimmt dem Unternehmen aber einen Teil davon.
• Forks. Verärgert ein Lizenzwechsel genug Teile der Community, kann ein Fork unter einer freizügigen Lizenz entstehen. Der Fork behält den alten Code und zieht womöglich genau die Cloud-Anbieter an, die das Unternehmen aussperren wollte.
• Marke. Selbst wenn der Code frei kopiert werden darf, gilt das für den Namen meist nicht. Redis etwa beschränkt inzwischen die Verwendung von „Redis“ in den Namen anderer Produkte nach seiner Markenrichtlinie.

Contributor-Lizenzvereinbarungen

Eine Contributor-Lizenzvereinbarung (Contributor License Agreement, CLA) ist ein Dokument, in dem ein Mitwirkender einem Projekt die Rechte einräumt, die es zur Nutzung seines Beitrags braucht. Stiftungen setzen sie für rechtliche Klarheit ein, wie die ICLA-Begründung der Apache Software Foundation zeigt.

Für ein Unternehmen hat eine CLA einen zweiten Zweck: Sie macht es möglich, die Lizenz später zu ändern oder den Code unter einer kommerziellen Lizenz zu verkaufen, weil das Unternehmen die nötigen Rechte hält. Redis etwa sagte, es verlange von Mitwirkenden die Annahme seiner CLA, bevor es deren Beiträge in Betracht ziehe.

Mitwirkende empfinden CLAs manchmal als Einbahnstraße. Ein Unternehmen, das das Wohlwollen der Community behalten will, sollte klar sagen, warum es eine verlangt und was es im Gegenzug verspricht.

Was das für ein Startup bedeutet

Wenn Sie ein Open-Source-Geschäftsmodell erwägen, lohnt es sich, einige Fragen früh durchzuarbeiten.

1. Wofür zahlen Kunden, wenn der Code kostenlos ist? Für Bequemlichkeit, Risikoreduktion, Funktionen oder Erlaubnis. Wenn Sie es nicht benennen können, haben Sie noch kein Geschäftsmodell.
2. Wer könnte Ihr Produkt weiterverkaufen? Lautet die Antwort „jeder Cloud-Anbieter“, wählen Sie Ihre Lizenz von Anfang an mit diesem Wissen, denn eine spätere Änderung ist teuer.
3. Wie gewinnen Sie das Vertrauen der Community? Entscheiden Sie, was Sie niemals hinter eine Paywall verschieben werden, und schreiben Sie es auf.
4. Verstehen Sie die Wirtschaftlichkeit? Kostenlose Nutzer kosten Geld in Betrieb und Support. Verfolgen Sie die Unit Economics für das zahlende Segment, nicht die Gesamtzahl der Downloads.
5. Gibt es einen Burggraben jenseits des Codes? Marke, Hosting-Expertise, Ökosystem und Daten können wichtiger sein als die Lizenz. Der Artikel zum Economic Moat behandelt diese Idee ausführlich, und Netzwerkeffekte können greifen, wenn eine große Entwickler-Community das Produkt wertvoller macht.

Gerade Teams in der Frühphase sollten dieses Modell mit anderen Optionen wie Plattform-Geschäftsmodellen vergleichen, bevor sie sich festlegen.

Die Praxis bei Lizenzierung und Contributor-Vereinbarungen unterscheidet sich je nach Land und Investor, daher sollten Gründer für ihre eigene Situation rechtlichen Rat einholen. Eine verlässliche vergleichende Quelle speziell zu Open-Source-Geschäftspraktiken in Südostasien haben wir nicht gefunden.

Wichtige Fakten

• Die Open Source Definition der OSI hat zehn Kriterien und wurde zuletzt 2007 geändert. Eines davon verbietet Einschränkungen von Einsatzbereichen.
• Die OSI stellte im Januar 2021 klar, dass die SSPL keine Open-Source-Lizenz ist.
• IBM kündigte im Oktober 2018 an, Red Hat für $190 je Aktie bei etwa $34 Milliarden Unternehmenswert zu übernehmen.
• Die Abonnement-FAQ von Red Hat nennt Patches, Updates, Support und Zertifizierungen als Leistungen eines Abonnements.
• MongoDBs Service Atlas erwirtschaftete im Geschäftsjahr 2026 etwa 73 % des Umsatzes von $2,46 Milliarden.
• Elastic wechselte im Januar 2021 zur SSPL und ergänzte im August 2024 die AGPL.
• HashiCorp übernahm die BSL 1.1 im August 2023.
• Redis wurde im März 2024 Source-available und ergänzte im Mai 2025 die AGPLv3.
• NocoDB und Directus wechselten 2026 beide zu Source-available-Lizenzen.
• Eine Source-available-Lizenz ist kein OSI-Open-Source, auch wenn der Code öffentlich ist.

Weiterführende Lektüre

• Freemium-Geschäftsmodelle
• Product-led Growth
• Economic Moat
• Geschäftsmodelle von Hardware-Startups
• SaaS-Preismodelle
• Plattform-Geschäftsmodell