© Andriy Popov, 123RF

Ist Cloud Computing der Tod von Open Source, weil ein einst erfolgreiches Geschäftsmodell nicht mehr funktioniert, wenn große Provider freie Software als As-a-Service-Angebote vermarkten, mit denen kein Mittelständler und erst recht kein Open-Source-Projekt mehr konkurrieren kann?

Kommerzielle Open-Source-Unternehmen folgten in der Vergangenheit vor allem einem Geschäftsmodell, auf das sich auch die Geldgeber für die Finanzierung von Open-Source-Projekten verließen und das zur Tragfähigkeit von Open Source im Ganzen beigetragen hat. Gemeint ist das Modell des Einzelanbieters (single vendor) einer Software unter einer freien Lizenz. Doch gerade dieses Geschäftsmodell sieht sich heute Herausforderungen gegenüber, die es zu zerstören drohen.

Verschiedene Geschäftsmodelle

Ein Businessmodell beschreibt im Allgemeinen, wie eine Firma operiert und wie sie es versucht, ihre Ziele zu erreichen. Open Source an sich ist kein Geschäftsmodell, es kann aber eine hilfreiche Strategie darstellen. Wer sich auf die Open-Source-Geschäftsmodelle konzentriert, der kann nach der Art der Wertschöpfung und dem Verhältnis zum geistigen Eigentum drei grundlegende Typen unterscheiden:

1. Open-Source-Service- und Supportfirmen

2. Open-Source-Distributoren

3. Einzelanbieter von Open-Source-Produkten

Reine Service- und Supportfirmen besitzen in aller Regel nicht das geistige Eigentum an den durch sie unterstützten Open-Source-Produkten, stattdessen bieten sie einer Community, die sich um diese Produkte gebildet hat, Supportdienstleistungen an.

Distributoren wiederum vermarkten eine komplexe Zusammenstellung von bestimmten Open-Source-Komponenten als neues Produkt. In der Regel haben auch sie allerdings keine Urheberrechte an den gebündelten Komponenten.

Anders die Einzelanbieter von Open-Source-Produkten – ihnen gehören im Normalfall die Urheberrechte an der Software, die sie vertreiben. Typischerweise entwickeln sie die Software selbst (Abbildung 1).

Abbildung 1: Einzelanbieter von Open-Source-Software programmieren in der Regel die Applikationen selbst, die sie dann lizenzieren und verkaufen. © scyther5, 123RF

Einzelanbieter und Lizenzmodelle

Bei der Ausgestaltung ihres Geschäftsmodells haben solche Firmen etliche Optionen. Zwei lassen sich vor allem unterscheiden: Dual Licensing und das Open-Core-Modell.

• Dual Licensing: Hier vertreibt der Hersteller seine Software unter einer Open-Source-Lizenz und zusätzlich unter einer proprietären Lizenz. Im letzteren Fall zusammen mit weiteren Dienstleistungen und Garantien, an denen seine Kunden interessiert sind. Nicht selten lehnen die Kunden auch die Open-Source-Lizenz ab und werden deshalb zu zahlenden Kunden der kommerziell lizenzierten Version.
• Open Core: Manchmal hält der Hersteller in der Open-Source-Version auch bestimmte Features zurück, die er nur zusammen mit der Bezahlversion anbietet. Meist heißt die freie Variante dann Community Edition und die zu bezahlende Version ist die Enterprise Edition.

Es lassen sich mindestens drei Generationen von Firmen unterscheiden, die das Einzelanbieter-Geschäftsmodell genutzt haben oder nutzen:

1. Die Pioniere. Die Idee von Open-Source-Software, die ein einzelner Anbieter erschafft, besitzt und vermarktet, kam schon in den 90er Jahren auf. Vertreter dieser Pioniergeneration sind etwa MySQL AB, Sleepycat Software Inc. oder Trolltech.

2. Die zweite Welle. In den frühen 2000er Jahren erkannten Unternehmer und Geldgeber, dass Open Source eine effektive Strategie sein kann, um existierende Softwaremärkte zu sprengen. So prägte bereits im Jahr 2004 die neu gegründete Open-Source-Firma Sugar CRM Inc. den Begriff “Commercial Open Source”, der manche Vorbehalte gegenüber Open Source abschwächen sollte. Andere Beispiele aus dieser Zeit sind Jaspersoft und Mulesoft, die beide später von größeren Unternehmen gekauft wurden und so ihren Investoren einen Gewinn einbringen konnten.

3. Die heutigen Mitspieler. Auch in der Gegenwart ist das Einzelanbieter-Modell populär. Aktuelle Beispiele sind etwa Mongo DB Inc., Redis Labs und Neo4j Inc. Sie haben von ihren Vorgängern gelernt. Fortschritte in der Technologie führen sie nun aber an eine Wegkreuzung, an der essenzielle Entscheidungen zu treffen sind.

Eine Analyse des Venture-Capital-Unternehmens OSS Capital ergab, dass die 40 bestbewerteten Open-Source-Firmen Anfang 2019 zusammen einen Marktwert von ungefähr 150 Milliarden US-Dollar hatten. Ein guter Teil dieser Gelder – die zum größten Teil mit Hilfe des Einzelanbieter-Modells erwirtschaftet wurden – ist bereits wieder an Investoren zurückgeflossen oder wird das noch tun. In dieser Hinsicht übertrifft das Einzelanbieter-Modell alle anderen Open-Source-Geschäftsmodelle.

Die Vielfalt der Geldflüsse und Erlösquellen

Investorengelder fließen immer dann, wenn ein Unternehmen seinen Geldgebern einen entsprechenden Gewinn – den Return of Investment (ROI) – glaubhaft machen kann. Beim Einzelanbieter-Modell kommen dabei dieselben Erlösquellen in Frage wie bei kommerzieller Software auch, das sind beispielsweise:

• Lizenzeinnahmen
• Gebühren für den frühen und bevorzugten Zugang zu neuen Features und Bugfixes
• Einnahmen aus Supportleistungen etwa via Hotline oder Vor-Ort-Consulting
• Finanzielle Gegenleistungen für Garantie oder Zertifizierungen
• Einnahmen aus Hosting
• Gebühren für Schulungen und Dokumentation
• Kostenpflichtige Selbsthilfe, etwa in Anwenderforen oder via Chatbots

Diese Einnahmequellen sind für den Praktiker nicht überraschend – kommen sie doch genau so auch bei klassischen Softwareherstellern vor. Open-Source-Einzelanbieter unterscheiden sich von traditionellen Softwareherstellern dadurch, dass sie oft auf Lizenzeinnahmen verzichten und gleich eine Art von Wartungsgebühren (Maintenance Fee) erheben. Das nennt man dann häufig das Subskriptionsmodell (Abbildung 2). Es kann, muss aber nicht mit Hosting verbunden sein.

Abbildung 2: Red Hat ist eines der größten Open-Source-Unternehmen weltweit und operiert mit verschiedenen Geschäftsmodellen sowohl als Supportfima wie auch als Software-Anbieter. © zimmytws, 123RF

Die entscheidende Herausforderung für den Einzelanbieter, der nach diesem Modell verfährt, besteht darin, nicht zahlende in zahlende Kunden zu verwandeln. Jede der Einnahmequellen ist dabei ein Anreiz für den Anwender, entsprechende Zahlungen zu leisten – etwa weil er nicht unter einer Open-Source-Lizenz arbeiten will oder weil er 24-Stunden-Support braucht und so weiter.

Alle Geschäftsbereiche profitieren

Wer die Ähnlichkeit des Einzelanbietermodells mit einem traditionellen Geschäftsmodell betrachtet, mag sich fragen, warum die Software dann überhaupt unter einer freien Lizenz veröffentlicht wurde. Hat das nicht nur Nachteile – etwa weil für einige Kunden die kostenlose Version ausreicht und ihnen Support als nicht so wichtig erscheint?

Der Grund dafür, einige oder alle Produkte unter einer Open-Source-Lizenz zu veröffentlichen, ist aber, dass dies alle Geschäftsbereiche verbessern und der Konkurrenz überlegen machen kann. Marketing, Verkauf, Produktmanagement, Technik – alle diese Geschäftsfelder können von Open Source profitieren. Und die Quelle dieser Vorteile ist wiederum die Community der nicht zahlenden Anwender, die sich im Geschäftsinteresse des Anbieters ausnutzen lässt. Der Preis, der dafür zu zahlen ist, besteht im nötigen Management der Community.

Marketing. Hochwertige Software kostenlos – das ist ein großartiges Angebot. Die daraus resultierende Mundpropaganda ist für Einzelanbieter besonders effektiv. Zufriedene Kunden reden gern über das Produkt, das ihnen das Leben erleichtert – das ergibt eine gute Referenz. Es trägt dazu bei, eine große, nicht zahlende Benutzerbasis aufzubauen, aus der der Vertrieb versorgt wird und die ein effizienteres und effektiveres Produktmanagement ermöglicht sowie Entwicklung und Support unterstützt.

Verkauf. Indem der Einzelanbieter alle oder einige seiner Produkte unter eine Open-Source-Lizenz stellt, erlaubt er es potenziellen Anwendern, sie problemlos zu benutzen. Im Unterschied zu Testversionen ermöglicht die Open-Source-Lizenz den Gebrauch auf unbestimmte Zeit und zu jedem Zweck. In der Folge werden die Anwender die Software auch so lange einsetzen, wie sie ihre Bedürfnisse erfüllt.

Aus dem Blickwinkel der Verkaufsabteilung ist eine große Verbreitung der Software unter nicht zahlenden Anwendern kein Problem, sondern eine Gelegenheit. Das Unternehmen verfolgt oft mit, wer sich seine Produkte herunterlädt, und sammelt E-Mail-Adressen. Die Firmen-E-Mail-Adressen darunter sind ein gutes Indiz für Kunden, die sich anzusprechen lohnt. Stammen dann noch mehrere dieser Adressen von ein und derselben Firma, ist das ein klarer Hinweis darauf, dass ein Anruf durch das Verkaufspersonal dort erfolgreich sein kann. Auf diese Weise gestattet es die Open-Source-Strategie der Verkaufsabteilung, ihre Anstrengungen zu priorisieren.

Der gesamte Verkaufsprozess wird so effektiver. Zu den ersten Usern der freien Version gehören oft Geschäftsanwender, besonders bei gehosteter Software, die mit der Kreditkarte bezahlbar ist. Gibt es mehrere solche Geschäftsanwender in einem Unternehmen, ist dessen IT-Abteilung unter Umständen bestrebt, die Software lieber zu kaufen und selber an zentraler Stelle anzubieten.

Der Open-Source-Einzelanbieter hat dann einen klaren Wettbewerbsvorteil gegenüber Konkurrenten: Sein Produkt ist bereits im Einsatz und hat Fürsprecher in der Belegschaft. Und was würde man wohl lieber kaufen: Ein Produkt, das man erst noch evaluieren muss, oder ein Produkt, das bereits genutzt wird und mit dem die Anwender schon gute Erfahrungen gesammelt haben?

Produktmanagement. Eine große Nutzerbasis – selbst wenn sie auch nicht zahlende Anwender einschließt – ist eine darüber hinaus große Hilfe für das Produktmanagement, wenn es darum geht, neue Features zu entwickeln. Der Open-Source-Einzelanbieter hat durch die kostenlose Freigabe seiner Software automatisch viele Anwender, von denen er dann für die Weiterentwicklung seines Produkts lernen kann.

Dazu bieten sich beispielsweise Foren an, in denen sich Anwender über Probleme und Anforderungen austauschen. Der Anbieter kann zudem leicht eine Möglichkeit öffentlich anbieten, Probleme und Fehler zu melden. Auch kann er Umfragen starten, um die Prioritäten für neue Features zu ermitteln. Dank der großen Nutzerbasis wird das oft in einem Umfang möglich sein, den traditionelle Hersteller nicht erreichen.

Entwicklung. Eine große Nutzergemeinschaft deckt Probleme schneller auf. Manche Anwender werden nicht nur einen Fehlerreport abschicken, sondern gleich auch ein Patch einreichen, um das Problem zu beheben. Eine solche Mitarbeit kann man vielleicht nicht erwarten, wird sie aber auch nicht zurückweisen. Der Einreicher des Patch tritt in der Regel seine Urheberrechte an dem Code ab. Zugleich ist das gelegentliche Einreichen von Code ein hervorragender Indikator für das Können und das Interesse des Einreichers und sein potenzielles Interesse an einer Mitarbeit im Unternehmen. Dadurch wird die Community Edition zugleich zu einem effektiven Recruiting-Instrument.

Support. Zumeist ist es für nicht zahlende Anwender selbstverständlich, dass die kostenlose Version kein Recht auf Support umfasst. Ganz im Sinne des Open-Source-Gedankens helfen sie sich deshalb untereinander. Wenn der Einzelanbieter geeignete Werkzeuge wie Foren oder Wikis bereitstellt, werden die Nutzer unter Umständen selber aktiv und schaffen Dokumentationen und Selbsthilfedokumente. Von der Kenntnis der dort aufgeworfenen Probleme und der dafür gefundenen Lösungen kann wiederum der Produktsupport profitieren.

Community Management. Wie beschrieben erwachsen die meisten Open-Source-Vorteile aus der großen Community nicht zahlender Nutzer. Das allerdings hat seinen Preis: Eine solche Community will verwaltet werden, was Arbeit macht. Community Manager müssen sich auf die Anwender einlassen und ihnen beispielsweise einen Webauftritt, Foren, Wikis oder eine Plattform für die kollaborative Software-Entwicklung bereitstellen.

Die meisten dieser Kosten sind variable Kosten, die mit der Größe der Community wachsen. Das Community Management muss also einerseits daran interessiert sein, dass sich die Nutzerbasis so schnell wie möglich vergrößert, und andererseits darauf achten, dass der Aufwand dafür so klein wie möglich bleibt.

Geistiges Eigentum schützen

Für den Einzelanbieter verbindet sich die Freigabe seiner Software unter einer Open-Source-Lizenz hauptsächlich mit zwei Problemen:

1. Wie bringt man nicht zahlende Anwender dazu, zu zahlenden Nutzern zu werden?

Das gelingt durch das Befolgen einiger Best Practices. An erster Stelle steht dabei der Aufbau einer Community, die sich selbst hilft und die Ressourcen des Anbieters möglichst nur im Notfall beansprucht. Stellt beispielsweise ein nicht zahlender Anwender in einem Forum eine Frage, so wird der Community Manager niemals direkt antworten. Er wird darauf warten, dass ein anderer Nutzer antwortet. Wenn nichts passiert, wird er versuchen jemanden anzustoßen, damit er antwortet. Und nur wenn auch das zu nichts führt, mag er in Erwägung ziehen, selber zu antworten.

2. Was tun, wenn ein Mitbewerber mit demselben Produkt konkurriert?

Beide Probleme adressiert dieselbe Strategie, die man auch den Imperativ des Urheberrechtsschutzes für Einzelanbieter nennen könnte: Handeln Sie stets so, dass Sie und nur Sie das Recht besitzen, ihr Open-Source-Projekt unter einer Lizenz ihrer Wahl zu veröffentlichen!

Indem er der einzige Besitzer des geistigen Eigentums bleibt, erhält sich der Einzalanbieter die Möglichkeit, sein Produkt verschiedenen Zielgruppen unter verschiedenen Lizenzen anzubieten. Gewöhnlich werden das zwei Lizenzen sein: Eine Open-Source-Lizenz, um eine möglichst große Community nicht zahlender Anwender entstehen zu lassen, und eine kommerzielle Lizenz für zahlende Kunden.

Um der einzige Eigentümer der Urheberrechte zu bleiben, muss die Software dem Einzelanbieter – ungeachtet der von der Gemeinschaft entwickelten Erweiterungen – zu 100 Prozent gehören. Beiträge aus der Community sind nur akzeptabel, wenn der Beitragende seine Rechte dem Einzelanbieter überschreibt oder ihm das Recht zur Relizenzierung überlässt.

Fast immer wird die Open-Source-Lizenz die gegenwärtig weitreichendste Lizenz sein, die AGPLv3.

Ein Ziel der AGPLv3 ist es, dass so viele Anwendungsfälle wie möglich die Copyleft-Klausel der Lizenz auslösen. Vereinfacht bedeutet dass, das bei Weitergabe der Software (eine Distribution) der gesamte betroffene Code offenzulegen ist. Mitbewerber können unter dieser Lizenz kein modifiziertes Produkt vertreiben, das ihr alleiniges geistiges Eigentum wäre, was wiederum ihre Wettbewerbsposition schwächt.

Ein weiteres Ziel der Lizenz ist es, dazu beizutragen, dass Softwarepatente durch eine Vergeltungsklausel verschwinden. Besagte Vergeltungsklausel widerruft dabei das Nutzungsrecht an der Software, zum Beispiel im Falle einer vom Nutzer gegen eine andere Person erhobenen Patentrechtsklage.

Sowohl kommerzielle Nutzer als auch potenzielle Wettbewerber mögen einen so lizenzierten Code im Allgemeinen nicht besonders. Daher motiviert die Wahl dieser Lizenz zum einen nicht zahlende Nutzer, zu zahlenden Kunden zu werden, und zum zweiten hält sie auch potenzielle Wettbewerber davon ab, das Produkt zu verwenden, um mit dem Open-Source-Einzelanbieter direkt zu konkurrieren.

Wie die Risikokapitalrenditen zeigen, funktionierte die beschriebene Strategie des geistigen Eigentums bisher relativ gut, und ein Einzelanbieter-Unternehmen stand daher auch nur selten in einem ernsthaften Wettbewerb mit jemandem, der das Produkt der eigenen Firma gegen sie verwendete. Doch das Aufkommen großer Public-Cloud-Infrastrukturen, darunter vielleicht an erster Stelle des Amazon Web Services (AWS), hat die Situation verändert und dieses Modell und die damit verbundenen Unternehmen nun an einen Scheideweg geführt.

Anbieter stehen am Scheideweg

Zunehmend wird Software als Service in Public Clouds verkauft. Zu den Firmen, die dies tun, gehören auch Mongo DB, Redis Labs und Confluent, jeweils mit einem Marktwert von über einer Milliarde Dollar. Anwendungsentwickler, die die Open-Source-Versionen dieser Produkte verwenden, sehen sich mit der unbequemen AGPLv3-Lizenz konfrontiert. Um deren Konsequenzen zu vermeiden, wollen sie ins Lager der zahlenden Anwender wechseln. So weit, so gut.

Anders als die Entwickler sind aber etliche Hosting-Provider zu dem Schluss gekommen, dass die Bestimmungen der AGPLv3 sie nicht tangieren. Es gibt keine formelle rechtliche Entscheidung, ob dies wahr ist, aber das Verhalten sowohl der Cloud-Computing-Anbieter als auch der betroffenen Einzelanbieterfirmen deutet darauf hin, dass die Anwälte zustimmen. In der Folge zahlen die Cloudbetreiber den Open-Source-Einzelanbietern nicht nur nichts, wenn sie deren Produkte in ihrer Cloud offerieren, sie haben sich darüber hinaus in einem ganz entscheidenden Anwendungsfall in deren mächtige Konkurrenten verwandelt.

Als Antwort darauf haben etliche Open-Source-Einzelanbieter ihre Lizenzen geändert, sodass diese jetzt Klauseln enthalten, die die kommerzielle Nutzung ihrer Produkte durch fremde Cloud-Computing-Anbieter verbieten. Das verstößt allerdings gegen das Diskriminierungsverbot in Kriterium 6 der Open-Source-Definition, weshalb die Software danach keine freie Software mehr ist.

Dies hat nun wieder den Zorn der Open-Source-Community auf sich gezogen, weil die meint, dass diese Einzelanbieter aus dem Begriff “Open Source” Kapital zu schlagen versuchen, obwohl sie gar keine freie Software mehr anbieten. Auch potenzielle Kunden sind vorsichtiger geworden, da das Versprechen, sie von einem erpresserischen Vendor Lock-in zu befreien, schwindet.

Die Herausforderung für die Firmen von Open-Source-Einzelanbietern besteht darin, wegen der oben erwähnten Vorteile große Anwendergemeinschaften aufzubauen, obwohl ihre Lizenzen keine Open-Source-Lizenzen mehr sind. Als Reaktion darauf versuchen sie die Bedeutung von Open Source neu zu definieren, damit sie weiter davon profitieren.

Ob diese Strategie aufgehen wird, ist nicht absehbar. Wenn sie sich damit nicht durchsetzen können, werden sie zu traditionellen Softwareherstellern. Wenn sie aber Erfolg haben, wird das die Open-Source-Gemeinschaft spalten und die kommerzielle Nutzung von Open Source in Frage stellen. Alternative Lösungsmöglichkeiten sind derzeit noch nicht bekannt.(jcb)