Business

Im EOS Directory, das die Open Source Business Foundation (deren Vorstandsmitglied ich bin) in Kürze neu aufsetzen wird, geht es nicht um Open Source Software, sondern um Enterprise Open Source Software (Enterprise OSS). Das ist zwar im Namen nur ein kleiner, in Wirklichkeit aber ein sehr großer Unterschied! Der Namenszusatz "Enterprise" bedeutet, dass die Software für den professionellen Einsatz in geschäftskritischen Bereichen eines Unternehmens geeignet sein muss. Und die aus diesem Einsatzbereich resultierenden zusätzlichen Anforderungen sind signifikant, wie die Praxis zeigt.

So beinhaltet der Einsatz einer Open Source Software in Unternehmen auf der einen Seite funktionale Anforderungen wie

• Schnittstellen für die Integration in eine existierende IT-Infrastruktur


• Berücksichtigung von Zeitzonen


• Mandantenfähigkeit (sofern erforderlich)


• eine mehrsprachige Benutzeroberfläche (sofern eine GUI vorhanden ist) mit Unterstützung verschiedener Zeichensätze


• die Unterstützung älterer Browser-Versionen wie Internet Explorer 6 (für Web-Applikationen)

Auf der anderen Seite kommen nicht-funktionale Anforderungen hinzu, wie zum Beispiel

• ein stabiler und nicht zu exotischer Software-Stack, der zum Betrieb der Enterprise OSS erforderlich ist (Application Server, DBMS, ESB, o.ä.)


• die einfache Skalierbarkeit der Software (z.B. durch Caching, Verteilung auf mehrere Server, etc.)


• die Sicherheit der Daten vor Hack-Angriffen (nicht nur von außen, sondern auch von innen


• eine gute Usability, die die Bedienung der Enterprise OSS auch Gelegenheitsnutzern erlaubt (oft ein Schwachpunkt bei OSS)

Über die bloßen funktionalen und nicht-funktionalen Anforderungen hinaus haben Unternehmen oft Bedarf an zusätzlichen Dienstleistungen rund um eine Enterprise OSS, und zwar umso dringender, je geschäftskritischer die eingesetzte Software ist. So erwarten Unternehmen auf folgenden Gebieten Service-Leistungen durch externe Anbieter:

• Schulung: Dokumentation, Trainingskurse, Experten-Hotline, etc.


• Consulting: Workshops von der Spezifikation bis zur Implementierung, Unterstützung bei der Installation und Konfiguration der Software


• Service&Support: Sicherstellung des Betriebs der Software und Beseitigung von Problemen im laufenden Betrieb


• Wartung: Anpassung, Pflege und Aktualisierung der Software


• Entwicklung: Umsetzung von Änderungs- und Erweiterungswünschen (und zwar so, dass diese ein Software-Update überleben und nicht neu programmiert werden müssen)


• Infrastruktur-Tools: bedienungsfreundliche und zeitsparende Monitoring- und Administrations-Tools (die im Gegensatz zum Kernprodukt oft nicht Open Source sind)

Sicher ist diese Aufzählung noch nicht vollständig. Doch es ist bereits jetzt eine umfangreiche Aufstellung, die demonstriert, wie hoch die Anforderungen an eine Enterprise OSS im Vergleich zu normaler Open Source Software sind. Und meine persönliche Erfahrung zeigt, dass eine Software, die die oben genannten Punkte nicht oder nur unvollständig erfüllt, für den Einsatz in Unternehmen wenig geeignet ist.

Als Abschluss meiner Serie Richtig Geld verdienen mit Open-Source habe ich fünf weitere interessante Ansätze für Einnahmequellen zusammengestellt, die bereits von dem ein oder anderen Unternehmen in der Praxis eingesetzt werden. Ich werde diese Konzepte jedoch nicht weiter kommentieren, weil ich der Meinung bin, dass die Erfolgsaussichten der verschiedenen Ideen stark abhängig von Typ und Komplexität der jeweiligen Open-Source-Software sind:

1. Der Entwickler einer Open-Source-Software konzentriert sich bei seinen Dienstleistungen zu Service&Support auf (wenige) Multiplikatoren wie z.B. Internet-Provider und -Hoster, Systemhäuser und -integratoren sowie Agenturen und bietet diesen einen 2nd-Level-Support an, während die Partner für ihre (vielen) Kunden den 1st-Level-Support leisten.


2. Bugfixes für bestimmte Versionen werden vom Entwickler einer Open-Source-Software nur die ersten 3, 6 oder 12 Monate oder bis zur Verfügbarkeit des nächsten Releases kostenlos angeboten. D.h. wer ein bestimmtes Release länger nutzen und nicht ständig updaten möchte, muss einen Wartungsvertrag abschließen, um weiterhin Bugfixes für sein Release zu erhalten.


3. Der Entwickler einer Open-Source-Software bietet Binärversionen des Source Codes ausschließlich gegen Gebühr im Abonnement an. Die Binärversionen werden für verschiedene (Betriebssystem-)Plattformen angeboten und der Entwickler garantiert jeweils deren Lauf- und Funktionsfähigkeit.


4. Zur komfortablen Verwaltung von großen Installationen einer Open-Source-Software bietet deren Entwickler bedienungsfreundliche und zeitsparende Monitoring- und Administrations-Tools an, die im Gegensatz zum Kernprodukt kostenpflichtig sind.


5. Dual Licensing: Steht eine Open-Source-Software unter der GPL und der Nutzer möchte sie mit kommerzieller Software kombinieren (die durch den viralen Charakter der GPL dann ebenfalls zu Open Source werden würde), kann er vom Inhaber der entsprechenden Rechte (in der Regel der Entwickler als Urheber) eine alternative Lizenz mit Nutzungs- und Verwertungsrechten für den kommerziellen Einsatz erwerben.

Abschließend ist zu sagen, dass Sie sich bei der Wahl der Geschäftsmodelle nicht auf ein einziges verlassen sollten, denn in der Regel werden von drei Konzepten ein bis zwei nicht funktionieren. Vielmehr müssen Sie von Anfang an auf mehrere Standbeine setzen, um eine stabile Basis für regelmäßige und auskömmliche Einnahmen zu schaffen.

Mit der Einnahmequelle "Upgrade auf kommerzielle Version" verlassen wir erstmals die reine Open-Source-Lehre. Eine ganze Reihe von Open-Source-Unternehmen (die vornehmlich durch Venture Capital finanziert sind) verfolgt mittlerweile das Geschäftsmodell, die Basisversion einer Software als Open-Source-Version kostenlos zu verbreiten, um schnell und ohne große Marketing- und Vertriebskosten eine hohe Reichweite und breite Nutzerbasis aufbauen zu können.

Im zweiten Schritt wird dann den Nutzern der Open-Source-Version eine kostenpflichtige Closed-Source-Variante der Software angeboten, die attraktive Zusatz-Features bietet, damit der ein oder andere Anwender, der die Open-Source-Software schätzen gelernt hat und konkreten Nutzen daraus zieht, für den Umstieg auf die kommerzielle Version zahlt.

Die Migration der Nutzer einer Open-Source-Software auf die kommerzielle Version kann jedoch nur gelingen, wenn folgende drei Bedingungen erfüllt sind:

1. Die kommerzielle Software muss Zusatznutzen bieten, die zumindest für intensive Nutzer der Open-Source-Version so attraktiv sind, dass sie den Wechsel auf ein kostenpflichtiges Produkt in Betracht ziehen.


2. Die Bedienung der kommerziellen Version muss - soweit möglich - identisch zur Open-Source-Version sein, damit der Nutzer nicht umlernen muss und kein Einarbeitungsaufwand anfällt.


3. Die kommerzielle Software muss das gleiche Datenmodell verwenden, damit sich die Bestandsdaten aus der Open-Source-Version problemlos, d.h. ohne zusätzlichen (und teuren) Konvertierungsaufwand, weiternutzen lassen

Bei AGNITAS verfolgen wir mit dem OpenEMM als Basisversion des kommerziellen E-Marketing Manager (EMM) ebenfalls die beschriebene Upgrade-Strategie. Der OpenEMM ist eine ausgereifte Open-Source-Software, die alle wichtigen Funktionen für E-Mail-Marketing und Transaktionsmails abdeckt und weltweit von tausenden Nutzern regelmäßig eingesetzt wird.

Doch der EMM bietet gegenüber dem OpenEMM noch zusätzliche Premium-Features wie z.B. Mandantenfähigkeit, Auto-Optimierungen und Website-Tracking sowie den Zusatznutzen, dass er auf mehrere Server verteilt werden kann und damit bezüglich Verandgeschwindigkeit und Link-Tracking-Kapazität beliebig skalierbar ist. Damit bietet der EMM einige attraktive Vorteile, die schon manchen OpenEMM-Poweruser zum Umstieg bewegt haben. Aus eigener Erfahrung kann ich daher sagen, dass das Upgrade-Geschäftsmodell - zumindest in unserem Fall - funktioniert.

Gestern vor zwei Jahren haben wir bei AGNITAS den ersten Release Candidate unserer E-Mail-Marketing-Applikation OpenEMM auf SourceForge als Open-Source-Software veröffentlicht.

Damit ist es wieder Zeit für ein kleines Zwischenfazit: Was haben wir seitdem erreicht?

• eine funktionsreiche, bedienungsfreundliche und stabile Software-Version für Linux und Windows


• in Summe bislang über 60.000 Downloads* (zum Vergleich: vor einem Jahr waren es erst 16.000 Downloads)


• weltweit über 1.200 aktive Nutzer (gemessen über unseren Online-Update-Check) mit einem derzeitigen Wachstum von 10 bis 20 pro Woche


• eine wachsende, internationale Community, die uns aktiv unterstützt (Ideen für neue Features, Bugreports und Bugfixes, Dokumentation, Übersetzungen, Foren-Support, etc.)


• Code Contributions aus der Community (Typo3-Extension zur Integration des OpenEMM mit Typo3 und SugarCRM-Plugin** zur Anbindung des OpenEMM an SugarCRM)


• regelmäßige (und wachsende) internationale Umsätze durch kommerzielle Services wie Support, Hosting und Entwicklung

Während bei der Weiterentwicklung des OpenEMM sowie bei dessen Verbreitung und beim Aufbau der Community alles in etwa nach Plan verlaufen ist, muss ich leider feststellen, dass für die Entwicklung der Einnahmen gegenüber der ursprünglichen Planung etwa die doppelte Zeit erforderlich ist. Das heißt wir sind jetzt nach 2 Jahren bei der Höhe der Einnahmen dort, wo wir eigentlich schon nach einem Jahr sein wollten. Hauptgrund dafür sind die deutlich unter Plan liegenden Einnahmen aus Service & Support (siehe auch hier), die nur zum Teil durch über Plan liegende Erlöse aus Anpassung und Entwicklung ausgeglichen werden konnten.

Da wir ein schnell wachsendes (und profitables) Stammgeschäft mit unserem kommerziellen E-Marketing Manager EMM betreiben, konnten wir die Einnahmenlücke locker überbrücken. Wenn wir dagegen ausschließlich von Open-Source-Einnahmen abhängig gewesen wären, hätte uns die verzögerte Entwicklung der Einnahmen sicherlich die ein oder andere schlaflose Nacht bereitet.

So aber kann ich wie vor einem Jahr als Fazit sagen: Der Schritt, open source zu gehen, hat sich für uns gelohnt und wir würden ihn jederzeit wieder tun!


* Leider funktioniert die offizielle SourceForge-Statistik wegen des Rechenzentrum-Umzugs von San Francisco nach Chicago derzeit nicht. Erst ab Anfang August sollen die Werte (inkl. der fehlenden Daten seit Mitte Juni) wieder abrufbar sein.

**Entwicklung noch nicht abgeschlossen

Für den Nutzer einer Software hat diese nur selten exakt die Funktionalität, die er sich wünscht. Dies gilt natürlich auch für Open-Source-Software. Daher muss ein Nutzer entweder mit den Limitierungen der Software leben, oder er passt die Software an seine Bedürfnisse an bzw. entwickelt die fehlende Funktionalität hinzu.

In letzterem Fall stellt sich dem Nutzer die grundsätzliche Frage, ob er dies intern selbst umsetzen sollte (sofern geeignetes Personal vorhanden ist), oder ob er den Auftrag extern vergibt - vorzugsweise an den Entwickler oder Anbieter der Software. Die Inhouse-Anpassung und -Entwicklung hat für den Nutzer den Vorteil, dass sie in der Regel preisgünstiger ist - vorausgesetzt, der Nutzer beschäftigt Personal mit dem erforderlichen Knowhow, um das Projekt erfolgreich abzuschließen. Auch Change Requests lassen sich bei einer Inhouse-Entwicklung schnell und unbürokratisch umsetzen.

Demgegenüber hat das Outsourcing von Anpassung und Entwicklung den Vorteil, dass das Proiekt schneller abgeschlossen werden kann (sofern die internen Kapazitäten des Nutzers ausgelastet sind), weil der Auftragnehmer in der Regel viel tiefer im Thema steckt, größere personelle Ressourcen bereitstellen kann und an einer zügigen Umsetzung (und Bezahlung) interessiert ist. Zum anderen muss der Auftraggeber, wie es bei Entwicklungsaufträgen üblich ist, nur im Erfolgsfall zahlen, d.h. er geht kein finanzielles Risiko ein. Außerdem kann ein Auftragnehmer, der schon mehrere vergleichbare Projekte durchgeführt hat, in der Regel wertvolle Ideen und Erfahrungen in solch ein Projekt einbringen.

Es gibt jedoch noch ein Killerargument, das generell gegen eine Inhouse-Lösung und für die Beauftragung des Entwicklers der Open-Source-Software spricht: die Aufnahme des neuen Codes in die Mainline.

Die Mainline einer Software ist die Hauptentwicklungslinie, auf deren Basis neue Versionen der Software entstehen. Ist ein bestimmtes Feature oder eine Erweiterung nicht Bestandteil der Mainline, so ist diese Komponente entsprechend nicht automatisch in jedem neuen Release enthalten und deren Entwickler muss sie selbst in jede neue Version integrieren, was für jedes Release Mehraufwand bedeutet.

Wird ein Anpassungs- oder Entwicklungsauftrag für ein neues Feature oder eine Erweiterung dagegen an den Mainline-Entwickler vergeben, kann der Code (natürlich nur mit Zustimmung des Auftraggebers) in die Mainline aufgenommen und bei allen weiteren Updates automatisch berücksichtigt werden.

Gelingt es Ihnen als Entwickler oder Anbieter einer Open-Source-Software, deren Nutzer mit den oben genannten Argumenten vom Outsourcing der Anpassungs- und Entwicklungsarbeiten an Sie zu überzeugen, so erschließen Sie sich damit eine sehr interessante Einnahmequelle, denn Entwicklungsleistungen werden in der Regel bereitwilliger und deutlich besser vergütet als Support- oder Administrationsleistungen.

Eine vielversprechende Einnahmequelle für Entwickler und Anbieter von Open-Source-Software, die derzeit voll im Trend liegt, ist das Hosting und die Administration der Software für die Nutzer. Diese Leistung ist eigentlich ein alter Hut und wurde bereits vor einem Jahrzehnt als ASP (Application Service Providing) vermarktet. Heute sprechen die Marketingabteilungen von SaaS (Software as a Service) oder SoD (Software on Demand), was aus meiner Sicht die Sache wesentlich besser beschreibt.

Saas, wie ich die Kombination aus Hosting und Administration im folgenden kurz nennen möchte, ist deshalb eine vielversprechende Einnahmequelle, weil hier ein Bündel von Services mit einer großen Wertschöpfung und einem hohen Komfortfaktor geschnürt wird. Ein attraktives Pricing vorausgesetzt, sind daher erfahrungsgemäß auch sparsame Nutzer bereit, für dieses Leistungspaket eine monatliche (oder jährliche) Gebühr an den Anbieter zu zahlen.

SaaS setzt sich in der Regel aus folgenden Leistungen zusammen:

• die Bereitstellung der vorinstallierten und vorkonfigurierten Software auf einem (oder mehreren) Server(n)


• die Bereitstellung der erforderlichen Internet-Bandbreite für den Zugriff durch den Nutzer


• die Überwachung der Software auf Verfügbarkeit, Funktionsfähigkeit und Performance


• die Überwachung der Hardware auf Auslastung der Ressourcen (CPU, RAM, Festplatten)


• das Einspielen von Security-Fixes, Bug-Fixes, Updates und Upgrades


• die Aktualisierung des zugrundliegenden Software-Stacks (Betriebssystem, Application Server, DBMS, etc.)


• der Austausch von defekten Hardware-Komponenten


• das Anlegen von Datensicherungen


• die Analyse der Log-Dateien auf Auffälligkeiten (Hackerangriffe, etc.)

Doch Vorsicht: Die Kompetenzen, die man als SaaS-Anbieter benötigt, sind andere als die, die für die Entwicklung von Software erforderlich sind. Wenn Sie noch keine Erfahrungen mit dem Hosting und der Administration einer größeren Anzahl von Servern gesammelt haben, müssen Sie dieses Knowhow entweder erst intern aufbauen oder einen erfahrenen, externen Partner finden, mit dem Sie auf diesem Gebiet zusammenarbeiten, um akzeptable Werte für Verfügbarkeit, Durchsatz und Latenz Ihres SaaS-Angebotes zu erzielen.

Wichtig ist für Sie als SaaS-Anbieter auch eine extreme Kostenkontrolle, damit Sie das oben erwähnte attraktive Pricing wirtschaftlich darstellen können. So müssen Sie Themen wie Load-Balancing, Server-Virtualisierung, Plattform-Konsolidierung, automatisierte Überwachungs- und Eskalationsprozesse sowie - ganz aktuell - Energieverbrauch voll im Griff haben, um ein kostengünstiges Angebot zusammenstellen zu können - womit wir wieder bei den Kompetenzen wären.

Ein praktisches und wirtschaftlich erfolgreiches Beispiel, wie Sie auf Basis Ihrer Open-Source-Software ein SaaS-Angebot aufbauen können, ist der eMM-Xpress, bei dem es sich um die SaaS-Lösung unseres OpenEMM handelt.

Wie bei der bereits behandelten Einnahmequelle Beratung, so gilt auch für Einnahmen aus Service und Support, dass das Geschäftspotenzial stark von der Art der Open-Source-Software und der Zielgruppe für diese Software abhängt. Grundsätzlich lassen sich nur für ein ausreichend komplexes Produkt, das eine hohe Bedeutung für das Geschäft des Nutzers hat, kostenpflichtige Service- und Support-Leistungen verkaufen.

Denn für komplexe Open-Source-Software gilt: Hat der Nutzer diese installiert und zum Laufen gebracht, fangen oft erst die Schwierigkeiten an. Es gibt Fragen zur Bedienung und zum Betrieb, zur Optimierung der Konfiguration und unter Umständen treten bei speziellen Einsatzszenarien Probleme oder gar Bugs auf. Um dem Nutzer bei seinen Fragen und Problemen zu helfen, bieten viele Entwickler und Anbieter von Open-Source-Software Wartungsverträge für Service und Support an.

Diese Dienstleistungen, die in der Regel als Laufzeitverträge ausgelegt sind, galten bislang als sichere und langlebige Einnahmequelle. Allerdings liegen inzwischen Erfahrungswerte vor, die nahe legen, dass man sich nicht dauerhaft und ausschließlich auf diese Einnahmequelle verlassen sollte. So berichten Open-Source-Entwickler und -Anbieter zunehmend, dass Kunden die Wartungsverträge nach ein oder zwei Jahren Laufzeit kündigen, weil sie mittlerweile genügend Erfahrungen gesammelt haben, um die Open-Source-Software selbst zu pflegen und zu verwalten.

Aus eigener Erfahrung weiß ich, dass Unternehmen oft erst einmal - teilweise mit hohem Zeitaufwand - versuchen, Installations-, Konfigurations- oder Betriebsprobleme selbst zu lösen. Dies gilt sogar für Konzerne, die sich externen Support direkt vom Entwickler oder Anbieter locker leisten könnten. Entweder sind die IT-Abteilungen dieser Unternehmen nicht mit wichtigen Projekten ausgelastet, oder es wird bei der Kalkulation der internen Kosten keine Vollkostenrechnung aufgestellt (von Opportunitätskosten ganz zu schweigen).

Darüber hinaus gibt es immer mehr Wettbewerb durch dritte Anbieter von Service und Support für Open-Source-Software. Beispielsweise bietet das Unternehmen SourceLabs unter dem Slogan "We are IT people, we don't call support" eine E-Selfservice-Lösung für Open-Source-Support an und Service Provider wie OpenLogic sind darauf spezialisiert, Wartung und Support für verschiedene Open-Source-Projekte anzubieten, mit dem Vorteil, dass man hier (eventuell) alles aus einer Hand erhält.

Übrigens befinden Sie sich als Entwickler oder Anbieter einer Open-Source-Software ständig in einer schizophrenen Lage: Je mehr Aufwand Sie in die Usability und Dokumentation Ihrer Software stecken, desto mehr Aufwand haben Sie bei der Weiterentwicklung, und desto geringer ist der Service-Bedarf der Nutzer. Bieten Sie allerdings wenig Bedienungsfreundlichkeit und kaum Dokumentation, werden sich Interessenten erst gar nicht intensiv mit Ihrer Software beschäftigen, geschweige denn diese für den produktiven Betrieb einsetzen.

Zusammenfassend lässt sich sagen, dass Service- und Support-Dienstleistungen auch für grundsätzlich geeignete Open-Source-Projekte (siehe erster Absatz) nicht mehr das Allheilmittel für die Generierung signifikanter Umsätze sind. Um einen Wartungsvertrag abzuschließen zu können, müssen Sie zum einen Ihren potenziellen Kunden nachweisen, dass Sie die kostengünstigere Lösung gegenüber deren Inhouse-Support sind, und zum anderen müssen Sie deutlich mehr Kompetenz als der Wettbewerb bieten - am besten belegbar durch konkrete Projekterfahrungen und Referenzen.

Den ersten Beitrag zu meiner losen Serie Richtig Geld verdienen mit Open-Source starte ich mit der Idee, die am naheliegendsten und für einen Entwickler oder Anbieter von Open-Source-Software am einfachsten umzusetzen ist - Beratung und Schulung!

Beratung zu Software ist ein weites Feld: Sie kann bei der Bewertung, ob eine Software für einen bestimmten Einsatz geeignet ist, beginnen, über Empfehlungen für die passende IT-Infrastruktur (Hardware, Betriebssystem, Software-Stack, etc.), in der die Software eingesetzt werden sollte, führen, und bei Tipps zur optimalen Installation und Konfiguration der Software sowie Schulung für den operativen Betrieb enden.

Der potenzielle Umfang der Beratung (und einhergehend damit der erzielbare Umsatz) ist abhängig von der Art der Open-Source-Software: Handelt es sich um ein komplexes System wie eine Linux-Distribution, eine ESB-Middleware oder eine ERP-Applikation? Oder geht es "nur" um ein Utility wie ein Backup-Skript oder eine kleine Applikation wie eine Adressverwaltung?

Ob ein potenzieller Nutzer bereit ist, Geld für Beratung auszugeben, hängt auch davon ab, wie wichtig die Software für ihn ist. Eine Bank, die einen Open-Source-Application-Server für Ihre Online-Banking-Website sucht, ist sicherlich bereit, ein paar (kostenpflichtige) Manntage für professionelle Beratung und Schulung zu investieren. Ein Privatanwender, der nur ein Tool zum Editieren seiner Privatvideos sucht, wird dagegen kaum bereit sein, Geld zu zahlen.

Sie sehen also schon, dass das Geschäftspotenzial für Beratung zu Software stark abhängig von der Art der Open-Source-Software und der Zielgruppe für diese Software ist.

Zu beachten ist auch, dass Beratung und Schulung oft ein einmaliges Geschäft pro Kunde ist, weil der Kunde nach einer initialen Lernphase keinen weiteren Bedarf mehr daran hat. Wenn aber wiederkehrende Einnahmen fehlen, ist man als Entwickler oder Anbieter gezwungen, ständig neue Kunden zu gewinnen, was ein hartes Geschäft ist und entsprechend hohe Marketing- und Vertriebsausgaben erfordert!

Ich persönlich bin aufgrund eigener Erfahrungen skeptisch, ob sich mit Beratung und Schulung - abgesehen von komplexen Installationen in Großkonzernen - nennenswert Geld verdienen lässt. Die Kunden sind es oft von proprietärer Software gewohnt, dass diese Leistungen eine kostenlose Beigabe sind. Während die Anbieter proprietärer Software diesen Aufwand jedoch über den Verkauf der Lizenzen finanzieren können, steht der Open-Source-Entwickler oder -Anbieter erst einmal mit leeren Taschen da.

Daher ist bei den meisten Anwendern bezüglich der Finanzierung von Open-Source-Software noch ein Lernprozess erforderlich, im Sinne von Open Source ist frei, aber nicht kostenlos. In diesem Zusammenhang ist aber auch wichtig, dass sich die Open-Source-Softwareindustrie nicht weiter als Wohltäter der IT-Welt darstellt, sondern offen zugibt, dass sie lediglich ein alternatives Entwicklungs-, Vertriebs- und Finanzierungskonzept verfolgt, und dass Entwicklung und Vertrieb ohne Finanzierung (in welcher Form auch immer) auf Dauer nicht aufrecht zu erhalten sind!

In meinem Beitrag Geld verdienen mit Open Source vom August des letzten Jahres habe ich eine Liste von Vorschlägen zusammengestellt, wie sich mit Open-Source-Software Geld verdienen lässt. Diese Liste habe ich übrigens immer dann, wenn ich auf einen neuen Weg, aufmerksam geworden bin, ergänzt, so dass es sich für Leser der Urversion vielleicht lohnt, den Beitrag nochmal durchzugehen.

Ich habe seitdem unter dem Titel Kostenlose Open-Source-Software funktioniert nicht geschrieben, welche Probleme es bei der Umsetzung geben kann, mit Control Points ein Beispiel für Gegenmaßnahmen genannt, die man ergreifen kann und hier auf weitere Anregungen von Kevin Kelly, Mitbegründer des US-Kultmagazins Wired, verwiesen.

Nun ist es an der Zeit, einmal zu analysieren, wie vielversprechend die verschiedenen Konzepte zur Einnahmenerzielung mit Open Source sind, um nicht nur ein paar hundert oder tausend Euro pro Monat, sondern richtig Geld damit zu verdienen, so dass sich von den Einnahmen ein Unternehmen mit einem mehrköpfigen Entwicklerteam finanzieren lässt.

Daher werde ich in den nächsten Wochen und Monaten in loser Folge einzelne potenzielle Einnahmequellen meiner Liste aufgreifen und - auf Basis meiner Erfahrungen mit dem OpenEMM, bei ADAMATIS und in verschiedenen Open-Source-Beratungsprojekten - meine persönliche Meinung zu deren Erfolgsaussichten beschreiben. Dabei werde ich natürlich auch die Art der Software, um die es im Open-Source-Projekt geht (d.h. Betriebssystem, Middleware, Tool oder Applikation) berücksichtigen. Und vielleicht ist dann der ein oder andere Leser sogar bereit, seine Meinung oder Erfahrungen in Form eines Kommentars beizusteuern!

Kürzlich hatte ich eine Diskussion über Open-Source-Geschäfts- und Lizenzmodelle mit einem bekannten Open-Source-Unternehmen, das schon etliche Jahre Erfahrung auf diesem Gebiet hat. Dabei wurde mir gegenüber die strategische Bedeutung der Control Points betont - ein Begriff, der mir zuvor in Zusammenhang mit Open Source noch nie begegnet war.

Ein Control Point ist ein Kontrollpunkt, über den Sie die von Ihnen entwickelte Software trotz Open-Source-Lizenz weiterhin "im Griff" behalten, so dass ein anderes Unternehmen nicht einfach Ihre Software forken und mit minimalem Aufwand als Wettbewerber zu Ihnen auftreten kann.

Ein Control Point kann natürlich nicht den Software-Code selbst betreffen, den Sie unter einer Open-Source-Lizenz zur Verfügung stellen, denn hier haben Sie - abgesehen vom Urheberrecht - bereits alle wichtigen Rechte an die Nutzer abgetreten. Vielmehr muss ein Control Point das Umfeld dieses Software-Codes betreffen, also zum Beispiel die Kontrolle über

• eine wichtige Erweiterung (die nicht unter einer Open-Source-Lizenz steht)


• eine aufwändig gestaltete Benutzeroberfläche (die nicht unter einer Open-Source-Lizenz steht)


• eine attraktives Zusatzleistung (automatisierte Online-Updates, Gewährleistungen, etc.)


• ein exklusives Netzwerk von Partnern (für Vor-Ort-Services und -Support)

Die Herausforderung ist es, Control Points zu finden, die auf der einen Seite die Verbreitung eines Open-Source-Projektes nicht behindern. Auf der anderen Seite müssen die Control Points jedoch sicherstellen, dass das Unternehmen, dass die Entwicklung der Open-Source-Software finanziert, eine faire Möglichkeit erhält, davon auch geschäftlich zu profitieren.