Open Core

Open Core (deutsch: Open-Core-Modell) ist ein Geschäftsmodell für Software, bei dem ein funktionaler Kern als Open Source veröffentlicht wird, während bestimmte zusätzliche Funktionen, Editionen oder Dienste proprietär bleiben und kostenpflichtig angeboten werden. Der offene Kern schafft Reichweite, Vertrauen und Community. Die kommerzielle Schicht finanziert das Unternehmen dahinter.

Den Begriff prägte 2008 der Analyst Andrew Lampitt, um eine Strategie zu beschreiben, die damals bei mehreren Open-Source-Unternehmen zu beobachten war. Seitdem hat sich das Modell zum verbreitetsten Weg entwickelt, mit Open-Source-Software Umsatz zu machen. Für Unternehmen, die solche Software einsetzen, ist es aus einem praktischen Grund wichtig: Wer „Open Source“ mit „komplett kostenlos und komplett frei“ gleichsetzt, kann bei der Kalkulation danebenliegen.

Wie das Open-Core-Modell aufgebaut ist

Ein Open-Core-Produkt besteht aus zwei Schichten. Die Community Edition enthält den Kern und steht unter einer anerkannten Open-Source-Lizenz wie MIT, Apache 2.0 oder GPL. Jeder darf sie herunterladen, nutzen, verändern und weitergeben. Die Enterprise Edition baut darauf auf und ergänzt Funktionen, die vor allem größere Organisationen brauchen. Diese Erweiterungen stehen unter einer kommerziellen Lizenz, ihr Quelltext ist entweder geschlossen oder einsehbar, aber nicht frei nutzbar.

Welche Funktionen in die kostenpflichtige Ebene wandern, folgt selten dem Zufall. Typische Kandidaten sind Merkmale, die vor allem bei wachsender Organisationsgröße zum Problem werden und für die Unternehmen erfahrungsgemäß zahlungsbereit sind:

• Zentrale Anmeldung und Verzeichnisanbindung, etwa Single Sign-On
• Feingranulare Rechteverwaltung, zum Beispiel rollenbasierte Zugriffssteuerung (RBAC)
• Audit-Logs und Compliance-Berichte
• Hochverfügbarkeit, Clustering und Skalierungsfunktionen
• Professioneller Support mit garantierten Reaktionszeiten
• Verwaltete Cloud-Angebote (Managed Hosting)

Die Logik dahinter ist einfach: Ein einzelner Entwickler oder ein kleines Team kommt mit dem Kern zurecht. Ein Konzern mit Compliance-Vorgaben braucht Rollen, Anmeldung und Nachweise, und für diese Anforderungen gibt es ein Budget.

Abgrenzung zu verwandten Modellen

Die Grenzen sind fließend, und viele Anbieter kombinieren mehrere Modelle. Wichtig ist die Unterscheidung von Open Source im engeren Sinn: Nach der Definition der Open Source Initiative (OSI) muss eine Lizenz unter anderem die freie Weitergabe und die uneingeschränkte Nutzung für jeden Zweck erlauben. Source-available-Lizenzen wie die Business Source License erfüllen das nicht, auch wenn der Quelltext lesbar ist.

Warum Open Core für Unternehmen relevant ist

Für Anbieter ist das Modell attraktiv, weil es Reichweite und Umsatz verbindet. Entwickler probieren die offene Version ohne Einkaufsprozess aus, empfehlen sie weiter und bauen Wissen und Erweiterungen im Ökosystem auf. Wächst ein Projekt in eine Organisation hinein, entsteht der natürliche Übergang zur kostenpflichtigen Edition.

Für Anwender liegt der Nutzen in Transparenz und Kontrolle. Der Quelltext des Kerns ist prüfbar, das Produkt lässt sich selbst betreiben, und ein Herstellerwechsel ist leichter als bei rein proprietärer Software. Das Risiko liegt an der Grenze: Was heute im Kern steckt, kann morgen in die kostenpflichtige Ebene wandern, oder eine Lizenz kann für künftige Versionen geändert werden. Für Entscheider ergeben sich daraus drei konkrete Prüffragen.

1. Welche Funktionen brauchen wir wirklich? Steht im Lastenheft eine Funktion, die typischerweise hinter der Bezahlschranke liegt, etwa Rechteverwaltung oder Firmenanmeldung, gehört die Enterprise-Lizenz von Anfang an in die Kostenrechnung.
2. Wie ist die Lizenz formuliert? Eine MIT-Lizenz für den Kern und eine separate Lizenzdatei für Enterprise-Bestandteile sind ein anderes Risikoprofil als eine Lizenz, die die Nutzung als Dienst einschränkt.
3. Wie tragfähig ist die Roadmap? Wandern erfahrungsgemäß Funktionen aus dem Kern in die kommerzielle Ebene? Ein Blick in Release Notes und Issue-Historie liefert Hinweise.

Beispiele aus der Praxis

GitLab ist eines der bekanntesten Open-Core-Produkte. Die Community Edition steht unter MIT-Lizenz, die Enterprise Edition ergänzt Funktionen unter kommerzieller Lizenz. GitLab beschreibt seine Strategie öffentlich als „buyer-based open core“: Funktionen werden danach eingeordnet, welche Käuferrolle sie primär betreffen, und entsprechend auf Editionsstufen verteilt.

Elastic veränderte 2021 die Lizenz von Elasticsearch und Kibana von Apache 2.0 auf eine doppelte Lizenzierung aus Server Side Public License (SSPL) und Elastic License. Als Reaktion veröffentlichte Amazon Web Services einen Fork unter dem Namen OpenSearch. Der Fall gilt als Lehrstück dafür, wie Konflikte zwischen offener Kernsoftware und Cloud-Anbietern entstehen können. Elastic ergänzte 2024 mit der AGPL wieder eine anerkannte Open-Source-Option.

HashiCorp stellte im August 2023 seine Produkte, darunter Terraform, von MPL 2.0 auf die Business Source License um. Die Community reagierte mit dem Fork OpenTofu, der unter dem Dach der Linux Foundation weitergeführt wird. Auch hier war der Auslöser das Verhältnis zu Anbietern, die die Software kommerziell weiterverwerten.

Die Fälle zeigen, dass Lizenzänderungen ein reales Szenario sind und nicht nur ein theoretisches. Sie zeigen aber auch, dass der Rechtsstand für bereits veröffentlichte Versionen erhalten bleibt und Forks möglich sind, wenn die Community das Vertrauen verliert.

Ein Beispiel aus dem Commerce-Umfeld

Auch im E-Commerce gibt es Open-Core-Konstellationen. Das Framework MedusaJS steht überwiegend unter MIT-Lizenz, hat aber laut der ENTERPRISE-LICENSE.md im Repository seit August 2026 einzelne Bausteine als Enterprise Materials ausgenommen. Betroffen sind nach den Angaben der Lizenz unter anderem RBAC und die OIDC-Anbindung für Single Sign-On. Generische Authentifizierung und die normale Nutzer- und Einladungsverwaltung bleiben MIT. Die Änderung gilt nach vorn und entzieht keine Rechte an bereits veröffentlichten Versionen. Den Zusammenhang für Kalkulation und Betrieb beschreibt der Beitrag zu MedusaJS.

Das Beispiel ist typisch für den Zuschnitt: Was Konzerne brauchen, liegt hinter der Lizenzgrenze, was Entwickler zum Einstieg brauchen, bleibt frei. Ob man das als fair oder als Bruch mit der Open-Source-Idee empfindet, ist eine Wertungsfrage. Für die Projektplanung ist relevant, dass die Grenze existiert und dass sie sich verschieben kann.

Lizenztechnik hinter dem Modell

Damit ein Unternehmen Teile seiner Software offen und andere proprietär anbieten kann, muss es die Rechte an beidem besitzen oder von Beitragenden einholen. Deshalb verlangen viele Open-Core-Projekte von externen Mitwirkenden ein Contributor License Agreement (CLA) oder eine vergleichbare Abtretung. Das erlaubt dem Rechteinhaber, den Code später unter anderen Bedingungen zu vertreiben. Für Beitragende ist das ein Punkt, den sie kennen sollten, bevor sie Arbeit investieren.

Die Wahl der Kernlizenz beeinflusst das Modell stark. Permissive Lizenzen wie MIT oder Apache 2.0 erlauben die weitgehend freie Weiterverwendung, auch in proprietären Produkten. Copyleft-Lizenzen wie die GPL oder AGPL verlangen, dass abgeleitete Werke unter denselben Bedingungen veröffentlicht werden. Die AGPL erweitert diese Pflicht auf Software, die über ein Netzwerk als Dienst angeboten wird, und ist deshalb für Cloud-Szenarien relevant. Anbieter wählen je nach Ziel: Eine permissive Lizenz maximiert Verbreitung, eine Copyleft-Lizenz erschwert es Wettbewerbern, den Code in geschlossene Dienste zu überführen.

Praktisch hilft Anwendern ein einfacher Prüfschritt. Im Repository liegt in der Regel eine Datei LICENSE und bei Open-Core-Projekten häufig eine zweite Datei für die kommerziellen Bestandteile. Sie listet auf, welche Verzeichnisse oder Module unter welcher Lizenz stehen. Diese beiden Dateien vor der Entscheidung zu lesen, dauert eine halbe Stunde und erspart spätere Überraschungen bei Kalkulation und Vertragsverhandlung.

Vor- und Nachteile im Überblick

Für den Einsatz eines Open-Core-Produkts sprechen die niedrige Einstiegshürde, der prüfbare Quelltext, die Möglichkeit zum Self-Hosting und ein Ökosystem, das Erweiterungen und Wissen bereitstellt. Bei Bedarf lässt sich später auf die kommerzielle Ebene wechseln, ohne die Plattform zu tauschen.

Dagegen sprechen die Unsicherheit über künftige Lizenzgrenzen, die Gefahr versteckter Folgekosten, wenn Enterprise-Funktionen spät auffallen, und eine mögliche Abhängigkeit vom Hersteller für sicherheitskritische Bausteine. Wer das Produkt tief anpasst, riskiert außerdem, dass Erweiterungen mit den proprietären Teilen kollidieren oder bei Lizenzänderungen neu bewertet werden müssen. Der Gegenpol zu diesem Risiko ist eine bewusste Strategie gegen Vendor Lock-in: klare Schnittstellen, dokumentierte Exportwege und regelmäßige Neubewertung.

Häufige Missverständnisse

„Open Source heißt kostenlos.“ Die Lizenz des Kerns kostet nichts, der Betrieb, die Entwicklung und gegebenenfalls Enterprise-Funktionen aber schon. Der Blick auf die Gesamtkosten gehört zu jeder ehrlichen Kalkulation, vergleichbar mit dem Total Cost of Ownership.

„Open Core ist dasselbe wie Freemium.“ Bei Freemium ist das Produkt selbst proprietär und wird in einer eingeschränkten Gratisversion angeboten. Bei Open Core ist der Kern quelloffen und frei veränderbar. Der Unterschied betrifft Freiheiten, nicht nur den Preis.

„Source-available ist Open Source.“ Nach der OSI-Definition nicht. Lizenzen mit Nutzungsbeschränkungen sind eigene Kategorien, auch wenn sie im Alltag oft unter dem Sammelbegriff Open Source auftauchen.

„Eine MIT-Lizenz garantiert die Zukunft.“ Sie garantiert, dass veröffentlichte Versionen frei nutzbar bleiben. Zukünftige Versionen kann der Rechteinhaber unter anderen Bedingungen veröffentlichen.

Ausblick

Die Spannung zwischen offenem Kern und wirtschaftlichem Erfolg bleibt bestehen. Cloud-Anbieter bieten offene Software als Dienst an und verdienen daran, ohne die Entwicklung zu finanzieren. Hersteller reagieren mit restriktiveren Lizenzen, Editionsgrenzen oder Cloud-Exklusivität. Die Gegenbewegung besteht aus Forks und Stiftungsmodellen, die Projekte in neutrale Trägerschaft überführen. Für Anwender ergibt sich daraus eine nüchterne Empfehlung: Lizenz, Roadmap und Governance eines Projekts sind ebenso Auswahlkriterien wie Funktionsumfang und Code-Qualität.

Wer Software auf fünf Jahre einplant, sollte die Frage nach der Lizenzgrenze deshalb wie ein Architekturthema behandeln: früh klären, dokumentieren und in Abständen neu bewerten.

Häufige Fragen zu Open Core

Was bedeutet Open Core?

Open Core bezeichnet ein Geschäftsmodell, bei dem ein Kernprodukt als Open Source veröffentlicht wird und zusätzliche Funktionen oder Dienste kostenpflichtig sind.

Ist Open Core dasselbe wie Open Source?

Nein. Der Kern ist Open Source, das Gesamtprodukt aber nicht vollständig. Die kommerziellen Erweiterungen stehen unter proprietärer Lizenz.

Welche Funktionen liegen typischerweise hinter der Bezahlschranke?

Häufig sind es Funktionen für größere Organisationen: Single Sign-On, Rollen und Rechte, Audit-Logs, Hochverfügbarkeit und Support-Verträge.

Ist Open Core für den Mittelstand geeignet?

Ja, sofern die benötigten Funktionen und ihre Lizenzierung früh geprüft werden. Für viele Anforderungen reicht der freie Kern, bei Compliance-Themen wird oft die kommerzielle Ebene relevant.

Was passiert, wenn der Hersteller die Lizenz ändert?

Für bereits veröffentlichte Versionen bleibt die damalige Lizenz gültig. Für künftige Versionen gelten die neuen Bedingungen. Die Community kann den letzten freien Stand forken, wie die Beispiele OpenSearch und OpenTofu zeigen.

Weiterführende Quellen

Die maßgebliche Definition von Open Source liefert die Open Source Initiative. Einen Überblick über das Modell bietet der Wikipedia-Artikel zum Open-Core-Modell. Die Lizenzbedingungen des Frameworks MedusaJS sind in der ENTERPRISE-LICENSE.md im Repository einsehbar.