Ein How-to für Unternehmen mit Mut Warum sich Open Source lohnt!

Open Source-basierte Software macht die Cloud zum sichersten Ort für sensible und schützenswerte Daten. Unternehmen sehen in Open Source-Projekten heute deshalb auch längst keine Notlösung mehr, sondern erkennen zunehmend die Vorteile dieses unternehmens­strategischen Ansatzes. In diesem Artikel zeigen wir, worauf beim Open-Source-Einsatz zu achten ist und welche Lizenzierung zu welchem Geschäftsmodell passen könnte.

Open Source als Notlösung? Das ist längst vorbei. Heutzutage werden Unternehmen mit dem Ziel gegründet, genau das aufzubauen. Genauso entscheiden sich bestehende Unternehmen, wie MongoDB oder HashiCorp, Produkte als Open Source freizugeben. Auch Newcomer, wie n8n oder Builder.io, betreten den Markt mit der strategischen Entscheidung, mit Open Source wirtschaftlich erfolgreich zu sein. Denn inzwischen gibt es interessante Monetarisierungs­optionen, insbesondere der Verkauf von Supportleistungen, von SaaS (Software-as-a-Service) oder von kommerziellen Lizenzen für Premium­funktionen sind attraktive Geschäftsmodelle.

Wer sich für Open Source entscheidet, kann auf seine Community zählen.

Abgesehen von den wirtschaftlichen Aspekten, hat Open Source eine große Strahlkraft. Dadurch, dass der Quellcode offen ist und ihn jede Person lesen und verändern kann, entsteht bei Entwicklern und Entwicklerinnen das Gefühl, Teil einer Community zu sein. Entsprechend sind sie bereit zur Verbesserung der Software beizutragen und sich gegenseitig bei Problemen zu helfen. Das färbt natürlich auch positiv auf das Image des Unternehmens ab, dieses wird meistens als freundlich, progressiv und offen wahrgenommen. Außerdem ist die Einstiegshürde niedrig. Entwickler und Entwicklerinnen arbeiten sehr gerne mit Open-Source-Software, wenn sie nach einer Lösung suchen, die sie sofort nutzen können.

Trotz aller Vorteile: Das sollte man beachten.

Natürlich gibt es trotzdem ein paar Aspekte zu bedenken, bevor man sich für Open Source entscheidet. Mein Co-Founder und ich haben uns große Gedanken um die Gefahr des Free Ridings gemacht. Damit ist gemeint, dass die Open-Source-Version so gut ist, dass niemand die Premium­funktionen kaufen möchte. Es kommt also darauf an, die freie Version so gut wie möglich zu machen, aber auch Spielraum für kostenpflichtige Features zu lassen, die den Entwicklern und Entwicklerinnen die Arbeit noch leichter machen. Ein bisschen so wie im Flugzeug: In der Economy Class kommt man sicher und gut umsorgt ans Ziel, aber in der Business Class sogar erholt, weil alles bequemer und großzügiger ist. Außerdem empfehle ich, vor der Entscheidung für ein Open-Source-Geschäftsmodell eine ausführliche Konkurrenzanalyse durchzuführen. Denn andere Unternehmen könnten mit aufspringen und ihre kommerziellen Produkte rund um das eigene Open-Source-Projekt anbieten. Ein dritter Aspekt, den man beachten sollte, ist der Wertverlust, der durch die Herausgabe des geistigen Eigentums entsteht. Das kann sich negativ auf die Unternehmensbewertung auswirken und war in der Vergangenheit wohl häufig ein Hauptgrund für den schlechten Ruf von Open Source als strategische Geschäftsentscheidung.

Auf die Wahl der Lizenz kommt es an.

Leider gibt es keine Möglichkeit alle genannten Vorteile ohne die Nachteile auszuschöpfen, deshalb geht es darum klug abzuwägen. Die Wahl der Lizenzierung ist hier ausschlaggebend. Entscheidet man sich für eine lockere Lizenz, die es jeder Person erlaubt, alles mit dem Code zu machen, profitiert man voll von den Vorteilen, ist aber auch allen genannten Nachteilen schutzlos ausgeliefert. Eine strengere Lizenz verschafft einem über die Risiken mehr Kontrolle, aber der Community-Aspekt und die positiven Abstrahleffekte auf das Image des Unternehmens werden kleiner sein.

Die wichtigsten Lizenztypen im Überblick.

Um die Optionen besser voneinander abgrenzen zu können, skizziere ich die wichtigsten Lizenztypen im Überblick:

• Lockere Lizenzen: Hier ist für Nutzende alles möglich, das heißt, der Quellcode kann beliebig verändert und weiterentwickelt werden. Beliebte Beispiele für diesen Lizenztyp sind MIT, BSD und Apache.

• Copyleft-Lizenzen: Ermöglicht den Nutzenden ähnlich viel Freiheit wie die lockere Lizenz, kommt aber mit einer Bedingung. Weiterentwickelte Versionen müssen unter die Lizenz der ursprünglichen Open-Source-Software gestellt werden und ebenfalls frei bleiben. Das bedeutet, dass verhindert wird, dass jemand eine erweiterte oder veränderte Version der Software für sich beansprucht und als Closed Source möglicherweise monetarisiert. Beliebte Beispiele für diesen Typ sind GPL, AGPL, MPL, wobei MPL als die lockerste Copyleft-Lizenz gilt.

• Eingeschränkte Lizenzen: In diesem Fall behalten sich die Herausgeber bestimmte Rechte vor, die von Fall zu Fall unterschiedlich sind. Die meisten Einschränkungen zielen darauf ab, anderen das Anbieten von SaaS zu untersagen. Bekannte Beispiele für diesen Lizenztyp sind BSL, Elastic License und SSPL. Wichtig ist noch zu wissen, dass eingeschränkte Lizenzen nicht als “echtes” Open-Source-Projekt gelten. Ich empfehle daher, in der Kommunikation den korrekten Begriff “source available” zu nutzen, um Missverständnisse zu vermeiden.

Die Lizenz und das Monetarisierungs­modell müssen ein Match sein.

Schaut man sich auf dem Markt um, kann man deutlich erkennen, dass die erfolgreichen Unternehmen ihre Lizenz passgenau zum jeweiligen Monetarisierungs­ansatz gewählt haben. SaaS-Unternehmen mit Fokus auf einer technisch versierten Kundschaft, wie n8n, Gitpod oder Confluent können stark vom Vertrauen und guten Image von Open Source profitieren, ohne zu große Nachteile zu haben. Ihr Produkt wird am besten als SaaS genutzt und entsprechend haben wenige Menschen ein Interesse die Software selbst zu verwalten. Um sich vor SaaS-Konkurrenz zu schützen, hat sich beispielsweise Gitpod für eine Copyleft-Lizenzierung entschieden. Mögliche Wettbewerber sind dadurch gezwungen, ihre Angebote ebenfalls als Open Source freizugeben.

Anders sieht es aus, wenn die Zielgruppe eines SaaS-Unternehmens nicht technisch versiert ist. Dann macht eine eingeschränkte Lizenzierung Sinn. So wie das beispielsweise bei Personio oder HubSpot der Fall ist. Diese Unternehmen hätten durch einen offeneren Umgang mit ihrem Code kaum etwas zu gewinnen, aber viel zu verlieren. Den Kunden ist es egal, aber die Konkurrenz wäre sicher hoch erfreut. In diesem Fall also lieber kein “echtes” Open Source.

Dann gibt es noch den Fall von Infrastruktursoftware, die von Experten und Expertinnen selbst verwaltet wird und sich über Supportleistungen monetarisieren lässt. Hier entscheiden sich viele Unternehmen in den früheren Phasen der Entwicklung für Copyleft- oder lockere Lizenzen. Unternehmen, die damit erfolgreich fahren, sind beispielsweise Kong oder Puppet. Werden solche Unternehmen größer und müssen beispielsweise als börsennotierte Unternehmen verstärkt wachsen und monetarisieren, so wechseln diese häufig wieder zurück zu einer eingeschränkten Lizenz wie der BSL. Dies war zum Beispiel bei bekannten Firmen wie MongoDB und Elastic und erst kürzlich bei HashiCorp zu beobachten. In solchen Fällen kommt es meistens kurzfristig zu einem Aufschrei in der Community. Da die Software aber in der Regel bereits eine “kritische Masse” an Nutzern hat, schadet der Lizenzwechseln den Firmen häufig nicht langfristig.

Ist der Markt groß genug?

Schließlich ist es wichtig, vor der finalen Entscheidung auch die Marktstruktur zu beachten: Open Source funktioniert gut, wenn es genügend potentielle Kunden gibt, also neben den vielen “Free Ridern" auch eine attraktive Anzahl an zahlenden Kunden realistisch ist. Befindet man sich als Unternehmen hingegen in einem Markt, in dem es potentiell nur eine Handvoll großer Kunden gibt, würde ich dringend von Open Source abraten. Open Source ist gut, sogar besser als manche denken, aber eben nicht gut für alle.

Über den Autor

Felix Schuster ist CEO und Mitgründer des Confidential Computing Anbieters Edgeless Systems.

(ID:49822345)