Warum wir unseren Code verschenken – und was das mit guter Strategie zu tun hat

Bei fellowork begleiten wir Unternehmen bei der Transformation und entwickeln digitale Produkte. Ein zentraler Teil unserer Arbeit ist es, Wissen zu teilen und echte Einblicke in unsere Prozesse zu geben. Heute machen wir genau das: Wir nehmen euch mit auf die Reise einer Entscheidung, die wir für unser neuestes Projekt getroffen haben, unseren KI-Assistenten Ally.

Wir haben entschieden, Ally als Open-Source-Projekt zu veröffentlichen. Dieser Schritt war für uns kein Selbstzweck, sondern das Ergebnis einer langen strategischen Überlegung. Denn die Frage war nicht ob, sondern wie wir den Code freigeben. Die Wahl der richtigen Open-Source-Lizenz fühlte sich an wie eine Weggabelung mit drei sehr unterschiedlichen Pfaden. Jeder Pfad hätte Ally und unser Geschäftsmodell in eine völlig andere Zukunft geführt.

In diesem Artikel zeigen wir euch, welche Optionen wir abgewogen haben, welche Vor- und Nachteile jeder Weg mit sich bringt und für welche Lizenz wir uns am Ende entschieden haben, und warum.

Die Ausgangslage: Warum Ally Open Source machen?

Der Markt für KI-Anwendungen explodiert. Viele Unternehmen wollen KI nutzen, aber der Bau einer eigenen, zukunftsfähigen Anwendung von Grund auf ist komplex und teuer. Genau hier setzt Ally an: als fertige, anpassbare Basis für eine GenAI-App.

Ein entscheidendes Feature ist das integrierte Model Context Protocol (MCP). Es etabliert sich gerade als Industriestandard und funktioniert wie eine universelle Steckdose für KI-Anwendungen. Das macht Ally besonders zukunftsfähig und einfach erweiterbar.

Indem wir Ally mit dem MCP ausstatten und Open Source machen, senden wir ein klares Signal an den Markt: "Hier ist eine erstklassige Basis. Ihr könnt eure eigenen Tools und Services einfach andocken." Das schafft die perfekte Grundlage für unser Dienstleistungsgeschäft, denn viele Unternehmen werden unsere Hilfe benötigen, um ihre individuellen Werkzeuge fachgerecht an diese Steckdose anzuschließen.

Ally ist damit unsere beste Visitenkarte. Aber unter welchen Bedingungen geben wir sie aus der Hand?

Drei Wege, eine Entscheidung: Welche Lizenz ist die richtige?

Bei der Wahl der Lizenz standen wir vor drei grundlegend verschiedenen Strategien. Jeder Weg hatte seine eigenen Chancen und Risiken.

Weg A: Maximale Verbreitung (Permissive Lizenzen)

Dieser Weg bedeutet, jedem zu erlauben, fast alles mit unserem Code zu tun.

• Lizenzen: MIT-Lizenz, Apache 2.0
• Die Idee: Wir geben die Kontrolle komplett ab, um die größtmögliche Reichweite und Akzeptanz in der Community zu erzielen. Jeder darf Ally nehmen, verändern und auch für eigene kommerzielle, geschlossene Produkte nutzen.
• Vorteil: Gilt als "echtes" Open Source, genießt höchstes Vertrauen und hat den geringsten administrativen Aufwand.
• Nachteil: Ein Konkurrent könnte unsere gesamte Arbeit nehmen, ein Konkurrenzprodukt daraus bauen und damit Geld verdienen, ohne uns jemals zu beteiligen. Ein vollständiger Kontrollverlust.

Weg B: Offenheit mit kommerzieller Absicherung (Dual-Licensing)

Dieser Weg kombiniert eine offene Lizenz mit einem kommerziellen Modell.

• Lizenz: AGPLv3 + eine eigene kommerzielle Lizenz
• Die Idee: Wir nutzen eine starke "Copyleft"-Lizenz. Die AGPLv3 zwingt jeden, der eine modifizierte Version von Ally als Netzwerkdienst anbietet, den gesamten Quellcode ebenfalls zu veröffentlichen. Das ist für Unternehmen, die ihre Geschäftslogik schützen wollen, unattraktiv. Wer das nicht möchte, muss bei uns eine kommerzielle Lizenz kaufen, die ihn von dieser Pflicht befreit.
• Vorteil: Schafft eine direkte Einnahmequelle und schützt uns davor, dass andere unsere Arbeit als Basis für geschlossene Konkurrenzprodukte nutzen.
• Nachteil: Hoher administrativer Aufwand (u.a. durch ein Contributor License Agreement) und das Risiko, dass ein Konkurrent die AGPL-Version nutzt, um ein ebenfalls offenes Konkurrenzprodukt aufzubauen.

Weg C: Schutz vor kommerzieller Nutzung (Fair-code)

Dieser Weg macht den Code einsehbar, verbietet aber die kommerzielle Nutzung durch andere.

• Lizenzen: Business Source License (BSL), Elastic License 2.0
• Die Idee: Der Code ist offen, aber er ist kein "Open Source" im strengen Sinne. Wir behalten die volle Kontrolle darüber, wer mit unserer Arbeit Geld verdienen darf.
• Vorteil: Direkter Schutz vor kommerzieller Konkurrenz.
• Nachteil: Geringere Akzeptanz in der Entwickler-Community, da es nicht als "echtes" Open Source gilt.

‍

Unsere Entscheidung: Weg B mit der AGPL-3.0

Nach sorgfältiger Abwägung haben wir uns für Weg B entschieden: Dual-Licensing mit der AGPLv3 als öffentlicher Lizenz.

Warum? Weil dieser Weg unsere strategischen Ziele am besten ausbalanciert:

1. Wir bleiben Open Source: Wir wollen Teil der Community sein und von ihr profitieren. Die AGPL ist eine anerkannte Open-Source-Lizenz.
2. Wir schützen unsere Arbeit: Die "virale" Natur der AGPL verhindert, dass Unternehmen Ally einfach nehmen und in ein proprietäres Konkurrenzprodukt verwandeln. Kein Unternehmen will die Geschäftslogik seiner wertvollen, internen Tools offenlegen müssen.
3. Wir schaffen einen klaren Anreiz für unser Dienstleistungsgeschäft: Die AGPL erzeugt einen sanften Druck, entweder mit uns zusammenzuarbeiten (Dienstleistung) oder eine kommerzielle Lizenz zu erwerben, um die eigene Technologie zu schützen. Beides führt zurück zu uns.
4. Wir fördern unser Kerngeschäft: Unser Hauptziel ist nicht der Lizenzverkauf, sondern die Gewinnung von Kunden für individuelle Projekte. Ally ist das perfekte Werkzeug, um unsere KI-Kompetenz zu demonstrieren.

Was du für dein Projekt mitnehmen kannst

Die Wahl einer Open-Source-Lizenz ist keine rein juristische Formalität, sondern eine tiefgreifende strategische Entscheidung. Wenn du vor einer ähnlichen Frage stehst, stelle dir folgende Fragen:

• Was ist dein primäres Ziel? Maximale Verbreitung (Weg A), Monetarisierung und Schutz (Weg B) oder strikte Kontrolle (Weg C)?
• Wer ist deine Zielgruppe? Eine reine Entwickler-Community reagiert anders auf Lizenzen als Unternehmenskunden.
• Was ist dein Geschäftsmodell? Die Lizenz muss dein Geschäftsmodell unterstützen, nicht untergraben. Willst du Dienstleistungen, Lizenzen oder etwas ganz anderes verkaufen?
• Wie viel Kontrolle willst du abgeben? Sei ehrlich zu dir selbst, wie viel es dich stören würde, wenn ein anderer mit deiner Arbeit reich wird.

Für uns war der Weg klar, als wir diese Fragen beantwortet hatten.

‍