Anzeige
Anzeige
Software & Entwicklung
Artikel merken

Welche Ansätze wann funktionieren (und welche nicht): Geschäftsmodelle für Open-Source-Unternehmer

Immer mehr Open-Source-Entwickler versuchen, mit ihrer Software Geld zu verdienen. Zeit für eine Analyse, wie vielversprechend die verschiedenen Konzepte zur Einnahmenerzielung mit Open Source sind. Dabei soll es nicht nur um ein paar hundert oder tausend Euro pro Monat gehen. Vielmehr ist die Frage, ob sich von den Einnahmen ein Unternehmen mit einem mehrköpfigen Entwicklerteam finanzieren lässt.

8 Min. Lesezeit
Anzeige
Anzeige

Zu Beginn die Idee, die am naheliegendsten und für einen Entwickler oder Anbieter von Open-Source-Software am einfachsten umzusetzen ist: Beratung und Schulung.

Beratung und Schulung

Anzeige
Anzeige

Beratung zu Software ist ein weites Feld. Es kann beispielsweise um die Bewertung gehen, ob eine Software für einen bestimmten Einsatz geeignet ist. Dazu gehören außerdem Empfehlungen für die passende IT-Infrastruktur, innerhalb derer die Software eingesetzt werden sollte. Nicht zuletzt sind Tipps zur optimalen Installation und Konfiguration der Software sowie zur Schulung für den operativen Betrieb eine Möglichkeit.

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?

Anzeige
Anzeige

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, Geld in professionelle Beratung und Schulung zu investieren. Ein Privatanwender, der nur ein Tool zum Editieren seiner Videos sucht, wird dagegen kaum bereit sein, Geld zu zahlen.

Anzeige
Anzeige

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.

Der Autor ist 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.

Anzeige
Anzeige

Service und Support

Wie bei Beratung und Schulung, 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.

Anzeige
Anzeige

Allerdings liegen inzwischen Erfahrungswerte vor, die nahelegen, 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.

Der Autor weiß aus eigener Erfahrung, dass Unternehmen oft zunächst versuchen, Installations-, Konfigurations- oder Betriebsprobleme selbst zu lösen. Dies gilt sogar für Konzerne, die sich externen Support direkt vom Entwickler oder Anbieter problemlos leisten könnten.

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 [1] 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 [2] 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.

Anzeige
Anzeige

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

Hosting und Administration

Eine vielversprechende Einnahmequelle für Entwickler und Anbieter von
Open-Source-Software ist das Hosting und die Administration der
Software für die Nutzer. „Software as a Service“ (SaaS), wie die Kombination aus Hosting und Administration gern genannt wird, ist deshalb interessant, weil hier ein Bündel von Services mit einer großen Wertschöpfung und einem hohen Komfortfaktor geschnürt wird. Eine attraktive Preisgestaltung 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 meist aus diesen Leistungen zusammen:

Anzeige
Anzeige
  • 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
  • das Einspielen von Security-Fixes, Bug-Fixes, Updates und Upgrades
  • die Aktualisierung des zugrundliegenden Software-Stacks
  • der Austausch von defekten Hardware-Komponenten
  • das Anlegen von Datensicherungen
  • die Analyse der Log-Dateien auf Auffälligkeiten

Doch Vorsicht: Die Kompetenzen, die man als SaaS-Anbieter benötigt, sind andere als die, die für die Entwicklung von Software erforderlich sind. Wer noch keine Erfahrungen mit dem Hosting und der Administration einer größeren Anzahl von Servern gesammelt hat, muss sich dieses Know-how entweder erst intern aufbauen oder einen erfahrenen, externen Partner finden, mit dem er auf diesem Gebiet zusammenarbeitet, um akzeptable Werte für Verfügbarkeit, Durchsatz und Latenz des SaaS-Angebotes zu erzielen.

Wichtig ist für einen SaaS-Anbieter außerdem eine extreme Kostenkontrolle, damit die Preisgestaltung wirtschaftlich ist. So muss man Themen wie Load-Balancing, Server-Virtualisierung, Plattform-Konsolidierung, automatisierte Überwachungs- und Eskalationsprozesse sowie Energieverbrauch voll im Griff haben, um ein kostengünstiges Angebot zusammenstellen zu können – womit wir wieder bei den Kompetenzen wären.

Anpassung und Entwicklung

Für den Nutzer einer Software hat sie 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, sie an seine Bedürfnisse anpassen oder die fehlende Funktionalität selbst hinzufügen.

Anzeige
Anzeige

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 Know-how, 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 Projekt 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. Zudem muss der Auftraggeber, wie es bei Entwicklungsaufträgen üblich ist, nur im Erfolgsfall zahlen. Er geht also kein finanzielles Risiko ein. Außerdem kann ein Auftragnehmer, der schon mehrere vergleichbare Projekte durchgeführt hat, oft wertvolle Ideen und Erfahrungen in ein solches 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.

Anzeige
Anzeige

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. Das ist ein gewichtiges Argument für das Outsourcing der Anpassungs- und Entwicklungsarbeiten an den Hüter der Mainline.

Upgrade auf kommerzielle Version

Mit dieser Einnahmequelle verlässt man die „reine Open-Source-Lehre“. Eine ganze Reihe von Open-Source-Unternehmen verfolgt mittlerweile das Geschäftsmodell, die Basisversion einer Software als Open Source 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 den Nutzern der Open-Source-Version eine kostenpflichtige Closed-Source-Variante angeboten, die attraktive Zusatz-Features bietet, damit der ein oder andere Anwender 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 sollte 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 und ohne zusätzlichen und teuren Konvertierungsaufwand weiternutzen lassen.

Weitere Konzepte

Abschließend fünf weitere interessante Ansätze für Einnahmequellen, die in der Praxis eingesetzt werden. Diese Konzepte sind nicht kommentiert, weil die Erfolgsaussichten stark abhängig von Typ und Komplexität der jeweiligen Software sind:

  1. Der Entwickler einer Open-Source-Software konzentriert sich bei seinen Dienstleistungen zu Service und Support auf (wenige) Multiplikatoren wie Internet-Provider und -Hoster, Systemhäuser und -integratoren sowie Agenturen und bietet diesen einen Second-Level-Support an, während die Partner für ihre Kunden den First-Level-Support leisten.
  2. Bugfixes für bestimmte Versionen werden vom Entwickler einer Open-Source-Software nur die ersten drei, sechs oder zwölf Monate oder bis zur Verfügbarkeit des nächsten Releases kostenlos angeboten. Wer ein bestimmtes Release länger nutzen und nicht ständig updaten möchte, muss also 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 Verwaltung großer Installationen einer Software bietet der 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 würde), kann er vom Rechteinhaber eine alternative Lizenz mit Nutzungs- und Verwertungsrechten für den kommerziellen Einsatz erwerben.

Generell ist zu sagen, dass man sich nicht auf ein einziges Geschäftsmodell verlassen sollte, denn in der Regel werden von drei Konzepten ein bis zwei nicht funktionieren. Vielmehr sollte auf mehrere Standbeine gesetzt werden, um eine stabile Basis für regelmäßige und auskömmliche Einnahmen zu schaffen.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige