The Open Source Business Model

Zusammenfassung

Richard Stallman gab Software frei und wollte damit Freiheit schaffen, keine Industrie. Doch aus seiner GPL entstand ein Ökosystem, das Milliarden wert ist. Die Geschichte des Open-Source-Business-Modells ist die Geschichte einer Frage, die bis heute keine befriedigende Antwort hat: Wie baut man ein Unternehmen auf etwas, das man kostenlos verschenkt?

Richard Stallman und die Geburt des Copyleft

1983 war Software zunehmend proprietär. Hersteller lieferten nur Binärdateien. Quelltexte waren Geschäftsgeheimnisse. Wer einen Bug fand, konnte ihn nicht selbst beheben — er musste warten, dass der Hersteller reagierte. Oder er musste zahlen.

Richard Stallman, damals Programmierer am MIT AI Lab, erlebte diesen Wandel als moralischen Verfall. Er hatte eine Welt gekannt, in der Programmierer Code selbstverständlich teilten, gemeinsam verbesserten, weitergaben. Diese Welt verschwand. Stallmans Reaktion war nicht Resignation — sie war Radikalität.

Im September 1983 kündigte er das GNU-Projekt an: ein vollständiges freies Unix-kompatibles Betriebssystem. 1989 folgte das Werkzeug, das seinen Ansatz rechtlich absichern sollte: die GNU General Public License (GPL).

Die GPL war ein juristischer Kunstgriff. Sie nutzte das Urheberrecht — das Instrument zur Kontrolle von Software — um genau das Gegenteil zu erzwingen: Freiheit. Wer GPL-Software vertrieb, musste den Quelltext mitliefern. Wer GPL-Software veränderte und weitergab, musste das modifizierte Werk ebenfalls unter der GPL veröffentlichen. Das Copyleft-Prinzip: Freiheit pflanzt sich fort wie ein Virus — deshalb nennen Kritiker es “virales Lizenzmodell”, deshalb nennen Befürworter es Geniestreich.

Stallmans Vision war explizit antikommerziell. Software sollte frei sein wie Redefreiheit — nicht wie Freibier, aber in der Praxis oft beides.

Linux: Das kollaborative Wunder

1991 schrieb Linus Torvalds, Student in Helsinki, eine E-Mail an die Newsgroup comp.os.minix:

“Ich schreibe ein (freies) Betriebssystem (nur ein Hobby, wird nicht groß und professionell wie GNU)…”

Er hatte unrecht.

Der Linux-Kernel wurde zum erfolgreichsten kollaborativen Software-Projekt der Geschichte. Was als Hobbyprojekt eines finnischen Studenten begann, läuft heute auf rund 96 % der eine Million meistbesuchten Web-Server, auf 100% der Top-500-Supercomputer, auf Milliarden Android-Geräten, in den Datenzentren von Amazon, Google und Microsoft.

Torvalds wählte ursprünglich eine eigene Lizenz, wechselte 1992 zur GPL. Die Entscheidung war bedeutsam: Sie verhinderte, dass Unternehmen Linux nehmen, verbessern und geschlossene Derivate daraus machen konnten. Jede Verbesserung musste zurückfließen.

Der Entwicklungsprozess war anarchisch und funktionierte trotzdem: Tausende Entwickler weltweit, koordiniert über E-Mail-Listen, ohne zentrale Organisation, ohne bezahltes Management. Patches wurden diskutiert, abgelehnt, verfeinert, akzeptiert. Die Qualität war hoch. Die Geschwindigkeit überraschte jeden.

Was niemand vorhergesehen hatte: Unternehmen begannen zu zahlen, um zu Linux beizutragen. Heute werden über 15% aller Linux-Kernel-Commits von Red-Hat-Ingenieuren geschrieben. Weitere 10% von Intel. Dann IBM, Google, Samsung. Die Firmen zahlen nicht für den Code — sie zahlen für den Einfluss auf die Richtung, für Early Access auf neue Features, für die Fähigkeit, ihre Hardware optimal zu unterstützen.

Red Hat: Das erste Milliarden-Dollar-Open-Source-Unternehmen

Die Frage “Wie verdient man Geld mit freier Software?” beantwortete Red Hat pragmatisch: nicht mit Software, sondern mit Service, Support und Zertifizierung.

Bob Young und Marc Ewing gründeten Red Hat 1993. Ihr Produkt war keine proprietäre Software — es war eine validierte, stabile, enterprise-taugliche Distribution von Linux, kombiniert mit Abonnements für Support, Patches, Sicherheitsupdates und Zertifizierungen. Unternehmen zahlten nicht für Red Hat Enterprise Linux selbst (der Quelltext war frei verfügbar), sie zahlten für die Garantie: dass jemand antwortet, wenn der Kernel um 3 Uhr morgens abstürzt.

Der Beweis, dass das Modell funktioniert, kam 2019. IBM kaufte Red Hat für 34 Milliarden Dollar — die größte Software-Akquisition der Geschichte bis dahin. Ein Unternehmen, das nie ein Byte proprietären Codes verkauft hatte, war 34 Milliarden wert.

Das Red-Hat-Modell hatte eine elegante Logik: Der Quelltext ist frei, das Know-how ist teuer. Wer Support braucht, zahlt. Wer keinen Support braucht, lädt sich CentOS herunter — Rhat-kompatibel, kostenlos, community-gepflegt — und ist trotzdem im Linux-Ökosystem.

Info

Die drei Lizenzfamilien im Überblick:

Permissive Lizenzen (MIT, Apache 2.0, BSD): “Tu was du willst.” Quelltext darf verwendet, modifiziert und in proprietäre Produkte integriert werden, ohne dass Ableitungen ebenfalls offen sein müssen. Einzige Pflicht: Urheberrechtshinweis beibehalten. Der gesamte macOS- und iOS-Kernel basiert auf BSD-lizenziertem Code. React (MIT), Android (Apache 2.0), Kubernetes (Apache 2.0).

Copyleft-Lizenzen (GPL, LGPL, AGPL): “Abgeleitetes bleibt offen.” Wer GPL-Software modifiziert und weitergibt, muss den Quelltext unter der GPL veröffentlichen. Die AGPL verschärft das: Auch wer GPL-Software über ein Netzwerk anbietet (also ein SaaS-Produkt baut), muss den Quelltext offenlegen. Linux-Kernel: GPL v2. WordPress: GPL v2.

Business Source License (BSL / BUSL): “Offen, aber nicht für Konkurrenten.” Code ist einsehbar und modifizierbar, darf aber nicht in kommerziellen Konkurrenzprodukten verwendet werden — typisch für vier Jahre, danach automatischer Wechsel zu einer permissiven Lizenz. Entwickelt von MariaDB (2016), übernommen u. a. von CockroachDB (2019) und HashiCorp (2023). (Elasticsearch wechselte 2021 dagegen zur SSPL, nicht zur BSL.)

Dual Licensing: MySQL und die Kommerzialisierung der GPL

MySQL fand einen anderen Weg. Die Datenbank war GPL-lizenziert — kostenlos für jeden, der selbst Open-Source-Software baute. Aber wer MySQL in proprietäre Software einbetten wollte, brauchte eine kommerzielle Lizenz.

Das Dual-Licensing-Modell war ein Hebel: Die GPL zwang proprietäre Nutzer, entweder ihren Code zu öffnen oder zu zahlen. Wer zahlen wollte, kaufte eine kommerzielle Lizenz von MySQL AB. So floss Geld zurück — von denjenigen, die am meisten von der Software profitierten, ohne zur Community beitragen zu wollen.

Sun Microsystems kaufte MySQL 2008 für eine Milliarde Dollar. Oracle übernahm Sun 2010 — und damit MySQL. Die Community reagierte nervös: Oracle war der direkte Konkurrent im Datenbankmarkt. Würde Oracle MySQL strangulieren?

Michael “Monty” Widenius, MySQL-Gründer, hatte vorgesorgt: Er hatte MySQL unter der GPL behalten. Das bedeutete, er konnte das Projekt forken. MariaDB entstand — kompatibel, unabhängig, community-kontrolliert. MySQL lebt bis heute unter Oracle, MariaDB lebt als Gegenentwurf. Der Fork funktionierte, weil die GPL das erlaubt.

Qt, das GUI-Framework von Nokia (später The Qt Company), folgte demselben Dual-Licensing-Prinzip: LGPL für Open-Source-Projekte, kommerzielle Lizenz für proprietäre Anwendungen.

Die Cloud-Krise: Als Amazon die Rechnung präsentierte

Das Dual-Licensing-Modell hatte eine implizite Annahme: Wer die Software kommerziell nutzt, zahlt. Diese Annahme überlebte die Cloud nicht.

AWS, Google Cloud und Azure begannen, populäre Open-Source-Datenbanken als verwaltete Services anzubieten: Amazon ElastiCache (Redis), Amazon Elasticsearch Service (Elasticsearch), Amazon DocumentDB (MongoDB-kompatibel). Die Cloud-Provider zahlten nichts an die ursprünglichen Entwickler. Sie mussten nicht: permissive und GPL-Lizenzen verlangten es nicht.

Elastic, das Unternehmen hinter Elasticsearch und Kibana, verlor Millionen potenzielle Kunden an Amazon — an ein Produkt, das Amazons eigene Ingenieure mit Elasticsearch-Quelltext gebaut hatten. 2021 handelte Elastic: Es wechselte Elasticsearch und Kibana von der Apache-2.0-Lizenz zur Server Side Public License (SSPL) — einer AGPL-Variante, die explizit Cloud-Provider trifft: Wer Elasticsearch als Service anbietet, muss den gesamten Quelltext seiner Infrastruktur offenlegen. Praktisch unmöglich für AWS.

AWS antwortete: Es forkte Elasticsearch unter dem letzten Apache-2.0-Stand und startete OpenSearch — community-gepflegt, permissiv lizenziert, direkt bei AWS gehostet. Elastic hatte Amazon nicht gestoppt. Es hatte Amazon einen Grund gegeben, einen eigenen Fork zu pflegen.

HashiCorp (Terraform, Vault, Consul) wiederholte das Muster 2023: Wechsel von Mozilla Public License zu Business Source License. Die Community reagierte mit einem Fork — OpenTofu, übernommen von der Linux Foundation. Innerhalb von Monaten hatte OpenTofu mehrere große Cloud-Provider hinter sich.

Das Muster war immer dasselbe: Lizenzschwenk → Community-Empörung → Fork → zwei parallele Projekte.

Dead End: Open Core

Warnung

Das Versprechen des Open-Core-Modells — und warum es strukturell bricht

Open Core sollte die perfekte Synthese sein: Der Kern ist offen, Enterprise-Features sind proprietär. Nutzer bekommen kostenlosen Einstieg, Unternehmen zahlen für erweiterte Funktionalität. Alle gewinnen.

In der Praxis erzeugt Open Core eine dauerhafte Spannung. Die Community will Features im Open-Source-Kern. Das Unternehmen will Features im proprietären Tier halten. Jede Feature-Entscheidung ist gleichzeitig eine kommerzielle Entscheidung. Entwickler merken das.

GitLab kämpfte jahrelang damit, die Grenze zwischen CE (Community Edition) und EE (Enterprise Edition) zu begründen. Features wanderten zwischen den Tiers — manchmal in beide Richtungen, nach Community-Druck. Das Vertrauen litt.

Confluent (Apache Kafka kommerziell) musste zusehen, wie AWS Amazon MSK (Managed Streaming for Apache Kafka) als direkten Konkurrenten aufbaute — mit denselben Open-Source-Komponenten, ohne Confluent einen Cent zu zahlen.

Das strukturelle Problem: Open Core funktioniert, solange kein Cloud-Provider die offene Seite selbst als Service anbietet. Sobald das passiert, verliert das Unternehmen seinen Hauptvertriebskanal an einen Konkurrenten mit unbegrenzten Infrastrukturressourcen. Die Alternative — mehr Features proprietär machen — untergräbt die Community-Adoption, die das Differenzierungsmerkmal gegenüber reiner proprietärer Software war.

Open Core ist kein totes Modell. Aber es ist ein fragiles Gleichgewicht, das ständige Neukalibrierung erfordert und keine dauerhaft stabile Lösung bietet.

Vermächtnis

Stallman wollte Freiheit. Torvalds wollte ein gutes Betriebssystem. Red Hat wollte ein Unternehmen bauen. Amazon wollte Services verkaufen. Alle bekamen, was sie wollten — und schufen dabei gemeinsam ein Ökosystem, das die gesamte digitale Infrastruktur der Welt trägt.

Die GPL ließ sich nicht verhindern, dass kommerzielle Akteure Free Software nutzen. Sie erzwang nur, dass Verbesserungen zurückfließen mussten — zumindest in Theorie. In der Cloud-Ära, wo Code nicht “verteilt”, sondern als Service angeboten wird, griff selbst die AGPL nicht mehr zuverlässig.

Was bleibt: Open Source hat gewonnen — als Entwicklungsmodell, als Qualitätsgarantie, als Community-Koordinationsmechanismus. Als Geschäftsmodell bleibt es ein Experiment in permanentem Ungleichgewicht: Wer trägt die Kosten, wenn alle vom Gemeingut profitieren?

Die Antwort, die sich abzeichnet, ist keine Lizenz. Es ist eine Frage der Macht: Welche Akteure haben die Ressourcen, einen Fork zu pflegen? Welche haben die Infrastruktur, ihn zu hosten? Welche haben die Marktmacht, Nutzer dorthin zu ziehen? In dieser Frage steckt die eigentliche Spannung, die Open Source im 21. Jahrhundert definiert.