Diese Woche wurde ich gefragt, ob wir im Rahmen der Professionalisierung der TYPO3 Association planen, eine Enterprise Edition, also eine nur gegen Vergütung (z. Bsp. verbandeltes Supportpaket) erhältliche, zusätzliche Version der frei verfügbaren TYPO3 Edition herauszubringen. Ich weiß, es ist verführerisch, das was bereits alle tunm auch machen zu wollen. Tatsächlich halte ich jedoch Enterprise Editions strategisch für ziemlichen Unsinn. Sie sind Old-Economy-Business-Modell-Denken, auch wenn es im Moment so aussieht, als wären sie der Goldstandard für OpenSource-Unternehmen Geld zu verdienen.
Lesedauer (4 Minuten)
Enterprise Editions erscheinen als logischen Schritt hin zu einem Revenue-Stream für OpenSource-basierende Produkte zu sein. Warum sollte man nicht auf dieses Modell setzen?
Herabwürdigung der Community
Damit man eine Enterprise Edition beim Kunden argumentieren kann, benötigt man Alleinstellungsmerkmale. Diese können z. Bsp. zusätzliche Funktionalität, zusätzliche Unterstützung, zusätzliche Schnittstellen, etc. beinhalten. Was auf den ersten Blick eine feine Sache für den Kunden ist, stellt aber in Tat und Wahrheit die frei verfügbare Community Edition erheblich schlechter.
Ich bin der Überzeugung, Open Source Unternehmen oder Organisationen wie die TYPO3 Association sollten die Community in den Mittelpunkt stellen und darum herum Revenue-Streams finden und aufbauen. Eine Enterprise Edition schafft da jedoch genau das Gegenteil. Sie lässt das Community Produkt niedriger erscheinen und logischerweise muss auch das Enterprise Projekt immer prioritär behandelt werden (z. Bsp. bei Bugfixes, etc.), will man es sich mit der zahlenden Kundschaft nicht verscherzen.
Was eigentlich der große Vorteil von OpenSource Projekten ist, nämlich eben diese Peer-Production wird so systematisch unterwandert. Man muss sich nicht wundern, erwachsen daraus auf diese Weise keine großen aktiven Communities. (Bitte Community nicht mit Usern im Forum verwechseln!)
Support nur für die Enterprise Edition
Viele OpenSource Unternehmen verbinden Ihre Support-Pakete ausschließlich mit den Enterprise Editions. Ich habe das, auch nach über 10 Jahren in dem Umfeld, nie wirklich verstanden. Es ist doch paradox: Man treibt Aufwand um ein Produkt, die Enterprise Edition, auf den Markt zu bringen, treibt Aufwand, um es aktiv zu verkaufen und limitiert dann einen vielversprechenden, komplementären Revenue-Stream auf diese anteilsmäßig kleine Installationsbasis.
Ein paar OpenSource Vendors werden jetzt entgegnen, dass das Risiko zu groß sei, Support auf die Community Edition zu geben. Ja, das kann wohl durchaus sein, aber eben darum, weil sie anstatt sich um die Community und organisierte und saubere Peer-Production zu kümmern, viel in die Enterprise Edition investiert haben und die Community Edition vernachlässigt haben. Und, es geht ja nicht darum Garantie zu geben, sondern darum, Support von offizieller Stelle zur Verfügung zu stellen. Das ist ein echtes Bedürfnis in fast jeder grösseren Firma. Gerade eben auch wenn Community-Editions genutzt werden.
Warum also nicht einfach die komplette installierte Basis nutzen, um da ein Support-Angebot zu basieren (idealerweise im 2nd und 3rd Level Bereich). Stattdessen versuchen die OpenSource Unternehmen die Kunden auf die Enterprise Edition zu ziehen, was vielfach nicht sehr einfach ist, weil die Anforderungen meist eben auch mit einer Community Edition schon sehr gut abzudecken sind.
Die Sache mit der Skalierbarkeit
Ich höre bereits ein paar Leute sagen: „Ja, aber Support skaliert nicht.“ Das ist in der Tat ein Argument. Um Support-Pakete anzubieten, wird grundsätzlich Manpower benötigt. Niemand, der ein Business-Modell entwickelt, mag das sonderlich. Das heißt aber überhaupt nicht, dass die Personalkosten linear zur Revenue-Kurve laufen würden. In der Praxis geht es eher darum Sockelleistungen zu garantieren und auf Spitzen reagieren zu können. Wer sich damit auseinandersetzt, erkennt schnell, dass strukturierter Support als Teil eines Business-Modells gar nicht so schlecht skaliert. Eine Voraussetzung dafür ist natürlich ein robustes Produkt.
Freemium vs Open Source
Viele Anbieter machen daher nicht OpenSource im eigentlichen Sinne, sondern Freemium mit OpenSource Komponente. Die Definition aus Wikipedia dazu:
Freemium ist ein Geschäftsmodell, bei dem das Basisprodukt gratis angeboten wird, während das Vollprodukt kostenpflichtig ist.
Sieht man bei den Vendors genauer hin, ist meist wo OpenSource draufsteht tatsächlich eigentlich Freemium drin. Das liest sich in Beschreibungen dann so: Community Edition: „Grundlegende CMS/eCommerce Funktionen“ und bei der Enterprise Edition eben: „Fortgeschrittene Features für Unternehmen“. Das finde ich nicht weiter schlimm, aber dafür den Spagat über dem OpenSource Thema zu machen, bringt diesen Unternehmen unter dem Strich wohl auch nicht sonderlich viel. Die Enterprise Edition bremst die Unternehmen mehr, als sie sich das vorstellen.
Freiwillig höhere Kosten im Development
Aus Anbietersicht kommt eine weitere Komponente hinzu, die ich nicht so recht verstehen will. Warum sollte ich zusätzlich zum Community-Produkt noch ein Team haben, welches die Enterprise Edition entwickelt (gut, ich weiß, das kann auch historisch bedingt sein z. Bsp. bei Start-Ups)? Die meisten Unternehmen laufen jedoch früher oder später in ein Szenario, in welchem sie zwei Versionen parallel unterhalten und weiterentwickeln müssen. Und meist wird dann logischerweise die Community Edition vernachlässigt.
Wer verdient schon wirklich Geld mit der Enterprise Edition?
Kuckt man sich um, sieht man, dass es eigentlich kein Unternehmen gibt, dass das Enterprise Edition Modell so wirklich leveragen konnte. Damit meine ich nicht, dass sie keine nennenswerten Umsätze generieren konnten/können. Viele der Firmen sind aber (noch) sehr klein (<100) und es braucht auch vergleichsweise wenige (wiederkehrende) Enterprise Subscriptions, um damit einen substantiellen Teil der Kosten zu decken. Bei den meisten, gerade bei den Shooting-Stars der letzten Jahre, hat es jedoch nie ganz gereicht. Denn wer sein Potenzial ausreizte, musste das Wachstum extern finanzieren, jene, die sich der Selbstfinanzierung verschrieben, blieben schlicht hinter ihrem Potential.
Wie denn?
Das ist genau die Frage, die ich mir schon recht lange stelle und ich glaube darauf mittlerweile eine simple Antwort zu haben: In dem man die Community ins Zentrum stellt.
Alle Aktivitäten, die man als kommerzielle Entität eines OpenSource Projekts vornimmt, sollten dazu da sein, der Community weiter zu helfen.
Bevor man also hingeht und einfach irgendwelche Einnahmequellen definiert, sollte man sich fragen, was kann unsere Einheit dazu beitragen, damit es der Community besser geht. Dabei gibt es direkte und indirekte Leistungen. Direkte Leistungen sind z. Bsp. Funding für Core Development und Product Management, Enablement cost und so weiter. Indirekte Leistungen wären etwa Marketing und Öffentlichkeitsarbeit .
Die kommerzielle Einheit muss dafür sorgen, dass Leistungen die aus irgendwelchen Gründen nicht auf freiwilliger Basis erbracht werden, trotzdem erledigt werden oder in viel höherer Kadenz erbracht werden können. Und sie hat diese Kosten selber zu tragen. Es ist sozusagen die Contribution der kommerziellen Einheit in die OpenSource Gemeinschaft.
Auf der anderen Seite sollte man genau analysieren, wo man als Brückenbauer in der Community Win-Win-Situationen schaffen kann. Wie kann man Leute zusammen bringen und Bedürfnisse erfüllen und Community Member gegenseitig davon profitieren? Entlang dieser Win-Win-Konstellationen kann man denn auch die Revenue-Streams installieren.
Ein Beispiel für eine solche Win-Win-Situtaion ist der Marketplace, den ich ja schon breiter vorgestellt habe resp. meine Vision davon: Durch das zentrale, entgeltliche zur Verfügung stellen von umfangreicher Zusatzfunktionalität profitieren alle. Die Agenturen die diese Extensions bis jetzt erstellt haben, aber aus kommerziellen Überlegungen nicht veröffentlichten, die Agenturen die solche Extensions für ihre Kundenprojekte verwenden, die Kunden, die so günstiger an gute, bestehende Funktionalität kommen und schlussendlich auch TYPO3 als Brand, da eben diese Funktionalität transparent verfügbar ist und z. Bsp. für Marketingzwecke verwendet werden kann.
An dieser Schnittstelle aus verschiedensten Interessen gilt es als kommerzielle Entität hinter dem OpenSource Projekt, eine Tantieme der erreichten Wertschöpfung zu nehmen. Das ist völlig legitim und für alle nachvollziehbar. So sieht der perfekte Revenue-Stream im OpenSource Umfeld aus: Alle gewinnen.
Win-Win-Pattern finden
Die Erarbeitung eines Business-Case für OpenSource Communities sollte daher nie aus Me-Too oder Best-Practice bestehen. Denn jede Community ist individuell.
Vielmehr geht es darum, zuerst diese Win-Win-Pattern zu identifizieren (auch wenn diese teilweise ungewöhnlich sind) und basierend darauf Produkte und Einnahmequellen zu bauen. Im Fall von TYPO3 heißt das zudem, dass sämtliches Geld ja wieder der Community zu Gute kommt, weil die TYPO3 Association der Community gehört. Das Erarbeitungsmodell der Win-Win-Pattern funktioniert aber auch bei kommerziell orientierten Unternehmen. Die Mechanik ist dieselbe.
Zugegebenermaßen ist es nicht ganz einfach von einem Enterprise-Edition-Modell in andere Modelle zu gehen. Ich habe gerade kein Beispiel, wo das geklappt hätte. Den meisten OpenSource Produkten fehlt es denn auch an einer genügend großen Community. Und das ist eben auch ein Huhn-Ei Problem: Um ein Plattform-basierendes Win-Win Modell zu fahren, benötigt man eine große Community, das Vorhandensein einer Enterprise Edition verhindert das jedoch eher.
So gesehen ist ein solcher Wechsel mit einem immensen wirtschaftlichen Risiko verbunden. Denn der Wechsel bedeutet zuerst einmal ein massives Investment in die Community und das beginnt damit, einfach mal den gesamten Code unter OpenSource zu veröffentlichen. Umso schwieriger wenn man Kunden, Mitarbeiter und Community jahrelang auf die Enterprise Edition eingeschworen hat.
Artikel auf Social Media teilen:
