Open Core

Open Core, Open Source und Freemium sind drei verschiedene Trennlinien

Diese Begriffe werden austauschbar benutzt, obwohl sie entlang verschiedener Achsen schneiden. Genauigkeit lohnt sich, denn der Unterschied entscheidet, was mit Ihnen passiert, wenn der Anbieter es sich anders überlegt.

• Open Source ist eine Lizenztatsache über den Code: Die Lizenz räumt Ihnen das Recht ein, ihn auszuführen, zu untersuchen, zu verändern und weiterzugeben. Über die Frage, wer wofür zahlt, sagt sie nichts.
• Open Core ist eine Verpackungsentscheidung darüber hinaus: Ein Teil des Produkts trägt eine offene Lizenz, ein anderer Teil existiert öffentlich überhaupt nicht. Die proprietäre Hälfte ist üblicherweise der gehostete Dienst, Single Sign-on, Audit-Logs, Berechtigungen und alles, wonach die größten Kunden fragen.
• [Freemium](/glossary/freemium) ist eine Preisentscheidung innerhalb eines einzigen proprietären Produkts: eine kostenlose Stufe und bezahlte Stufen derselben geschlossenen Software. Nichts ist offen, und Selbst-Hosting steht nicht zur Debatte.
• [Nutzungsbasierte Abrechnung](/glossary/usage-based-pricing) steht quer zu allen dreien — sie beschreibt, wie die Rechnung berechnet wird, nicht, was Sie mit dem Code tun dürfen.

Ein brauchbarer Test: Bei Freemium heißt Anschlagen an die Decke, dass Sie das Paket wechseln. Bei Open Core heißt Anschlagen an die Decke, dass Sie entweder wechseln oder das fehlende Stück selbst bauen, weil Sie den Rest des Systems in der Hand haben. Diese zweite Option ist der gesamte Wert des Modells für die anwendende Seite, und sie ist häufiger real, als man annimmt.

Ein Repository lesen, um zu sehen, wo die Linie wirklich verläuft

Wir schreiben regelmäßig über quelloffene Wachstumswerkzeuge auf unseren /grow-Seiten, und nach mehr als sechzig davon ist das Muster gleichmäßig genug für eine Checkliste. Was das Abzeichen behauptet und wo die Bezahlschranke steht, sind zwei getrennte Tatsachen — und die zweite entscheidet, ob das Werkzeug Ihr Problem löst. Lesen Sie danach, bevor Sie irgendetwas einführen:

• Öffnen Sie die LICENSE-Datei, nicht das Abzeichen. GitHubs eigenes Lizenzfeld zeigt `NOASSERTION`, wenn es nicht einordnen kann, was es gefunden hat, und manche Repositorys mit Lizenzabzeichen enthalten überhaupt keinen Lizenztext. Für sich genommen ist das kein Beweis, aber es ist das eine Feld, bei dem Sie sich keine Vermutung leisten können.
• Suchen Sie die Fußnote, die cloud-only sagt. Die häufigste Form ist eine Funktionsliste im README, bei der ein oder zwei Einträge einen leisen Hinweis tragen, dass es sie im gehosteten Tarif gibt. Ist genau dieser Eintrag Ihr Grund für die Einführung, haben Sie die ganze Geschichte schon gelesen.
• Lesen Sie die Vergleichstabelle, die das Projekt über sich selbst veröffentlicht. Das ist Marketing, behandeln Sie die Wettbewerberspalten also mit Misstrauen — aber die Spalte über das eigene Produkt stimmt meistens und verrät, was die Maintainer glauben zu verkaufen.
• Schauen Sie, welche Plugins oder Module als Kern markiert sind. Ein Projekt, das manche Fähigkeiten als Kern und andere als optional kennzeichnet, hat seine Linie bereits öffentlich gezogen — das ist deutlich verlässlicher als eine Preisseite.
• Prüfen Sie den Rechteinhaber und die Contributor-Vereinbarung. Hält ein einzelnes Unternehmen das Copyright, kann es später umlizenzieren; eine Stiftung oder eine breite Beitragendenbasis macht das erheblich schwerer. Dieses Feld sagt voraus, was in drei Jahren passiert.

docmd, ein Dokumentations-Compiler, den wir am 3. September 2026 vorgestellt haben, ist ein sauberes kleines Beispiel für die Form in gut lesbarer Ausführung: Der Compiler und alle seine Build-Ausgaben stehen im Repository unter MIT, und das eine gehostete Stück — ein Relay, mit dem eine rein statische Website den KI-Assistenten ohne eigenes Backend betreiben kann — ist klar als optionaler Dienst gekennzeichnet. In einer Minute wissen Sie, was Sie selbst hosten und was Sie kaufen würden; das gilt nicht für jedes Projekt dieser Kategorie.

Was das bedeutet, wenn Sie es einführen — und wenn Sie es bauen

Aus der Sicht der einführenden Seite lautet die ehrliche Frage nicht, ob das Werkzeug offen ist, sondern was Ihr Ausstieg kostet. Selbst-Hosting ist lizenzrechtlich kostenlos und in Stunden nicht kostenlos: Jemand macht die Updates, die Backups und den Ausfall. Rechnen Sie das gegen den gehosteten Tarif in der Größe, die Sie in einem Jahr erwarten, nicht in der von heute. Was Sie mit diesen Stunden kaufen, ist allerdings echt: Ihre Daten bleiben in einer Datenbank, die Sie kontrollieren, und wenn sich die Roadmap des Anbieters von Ihnen wegdreht, steht am Ende ein laufendes System statt einer Migration.

Wer als Gründerin oder Gründer das Modell für das eigene Produkt erwägt, sollte nüchtern sehen: Open Core ist eine Vertriebsstrategie, bevor es eine Umsatzstrategie ist. Es kauft Reichweite, Glaubwürdigkeit bei Entwicklerinnen und Entwicklern und einen Strom an Beiträgen; Kunden bringt es nicht von allein, und danach schränkt es Sie ein, denn eine Funktion von der offenen auf die bezahlte Seite zu verschieben gehört zu den wenigen Entscheidungen, die ein Projekt verlässlich Wohlwollen kosten. Legen Sie die Linie fest, bevor das Repository öffentlich wird, und schreiben Sie sie dorthin, wo Nutzende sie lesen können.

Die Arbeit, gefunden zu werden, nimmt es Ihnen ebenfalls nicht ab. Ein offenes Repository ist ein Vertriebskanal mit demselben Problem wie jeder andere — jemand muss davon hören. Deshalb sind die Projekte, die mit diesem Modell gewinnen, meist jene, die neben der Technik die gewöhnliche Content- und Community-Arbeit machen, und nicht jene, die angenommen haben, die Lizenz erledige das Marketing.