Business

Kevin Kelly, Mitbegründer des US-Kultmagazins Wired, hat in seinem Blog unter dem Titel "Better Than Free" einen ausgezeichneten Artikel verfasst, in dem er sich ausführlich Gedanken dazu macht, wie man in Zeiten des Internets mit digitalen Produkten noch Geld verdienen kann.

Während Kelly bei digitalen Produkten in erster Linie an redaktionelle Beiträge, Musikstücke und Filme zu denken scheint, sind seine Gedanken auch für Open Source sehr interessant. Kelly listet folgende acht nicht-kopierbare Eigenschaften auf, die er "Generatives" nennt, und aus denen sich Produkte und Services rund um digitale Produkte ableiten lassen:

1. Unmittelbare Verfügbarkeit (Immediacy)


2. Maßgeschneiderte Personalisierung (Personalization)


3. Auslegung und Auswertung (Interpretation)


4. Echtheit und Rechtsgültigkeit (Authenticity)


5. Zugänglichkeit (Accessibility)


6. Darstellung und Gestaltung (Embodiment)


7. Gönnerschaft und Unterstützung (Patronage)


8. Auffindbarkeit (Findability)

Beim Lesen dieser Liste (und den Erläuterungen in Kellys Artikel) lassen sich sofort Dienstleistungen wie automatische Updates, maßgeschneiderte Dokumentation, Gewährleistung, Hosting oder individualisierte Benutzeroberflächen ableiten. Und mit etwas mehr Nachdenken kann die Liste sicherlich noch zu weiteren Premium-Services inspirieren.

Kelly betont übrigens, dass er Werbung bewusst nicht auf diese Liste aufgenommen hat, weil er Werbung nicht als langfristige Lösung sieht, um digitale Produkte zu refinanzieren. Das sehe ich genauso, denn der Werbekuchen kann gar nicht so schnell wachsen wie die Services aus dem Boden sprießen, deren Finanzierungsmodell auf Werbung basiert.

Der (provozierende) Titel dieses Beitrags ist eigentlich ein Widerspruch in sich: Open-Source-Software ist in der Regel kostenlos erhältlich, und da es sie gibt (sogar immer mehr davon), muss das Konzept auch funktionieren.

Tut es aber nicht, denn Entwicklung und Vermarktung von Open-Source-Software kosten Geld. Dies gilt, wie ich bereits hier geschrieben habe, übrigens auch für Projekte, die nicht von einem kommerziellen Unternehmen getragen werden, wie z.B. der Linux-Kernel, der Apache-Webserver oder die Eclipse-IDE. In diesen Fällen übernehmen die Arbeitgeber der beteiligten Entwickler wie IBM, Novell oder Red Hat die Kosten für Gehälter und Vermarktung.

Leider sind nicht alle Nutzer bereit, die unumstößliche Tatsache, dass auch Open-Source-Software Geld kosten muss, zu akzeptieren. So habe ich in den letzten 1 1/2 Jahren zahlreiche Tricks kennen gelernt, mit denen Nutzer unserer freien OpenEMM-Software versuchen, auch Zusatzleistungen kostenlos zu erhalten. Hier ein paar Beispiele für die kreativen, oft aber auch frechen Tricks:

• Statt eine Setup- oder Support-Frage im kostenlosen Forum zu stellen, werden alle auf der OpenEMM-Website genannten E-Mail-Adressen mit dem gleichlautenden Text angeschrieben.


• Ein Support-Suchender, der bei unserer "normalen" Telefonnummer (=Vertrieb) nicht weiterkommt, probiert verschiedene Durchwahlen aus, bis er schließlich direkt in der Entwicklungsabteilung landet.


• Wenn wir noch das Feature XY entwickeln, so wird uns versprochen, soll sofort ein Wartungsvertrag abgeschlossen werden (das Feature ist aufwändig und in der kommerziellen EMM-Version enthalten).


• Bei einer E-Mail-Anfrage wird der Eindruck erweckt, dass es sich um ein größeres Projekt handelt und um Rückruf gebeten. Kaum ist dieser erfolgt, müssen "nur noch" einige technische Fragen geklärt werden - und von dem avisierten Projekt ist plötzlich keine Rede mehr.


• Bei einer sehr offiziell formulierten Anfrage über unser Kontaktformular wird eine bedeutende Firma als Absender genannt, die ein idealer strategischer Partner für uns wäre. Die angegebene Kontakt-E-Mail-Adresse ist jedoch ein Freemail-Account und das Problem ist so simpel, dass man sich fragt, warum die anfragende Weltfirma dieses nicht selbst lösen kann.

Wir haben als Konsequenz zusätzlich zu unserer Support-Hotline für 1,99 €/Minute (die leider nur aus Deutschland erreichbar ist) eine per Paypal zahlbare Support-Pauschale von 75,- € eingeführt, die der Nutzer nur im Erfolgsfall zahlen muss. Wer diese 75,- € nicht investieren will, um sein Problem mit unserer Unternehmens-Software zu lösen, der ist für uns als Kunde auch nicht interessant und wird demzufolge nicht bedient.

Das mag hart klingen, aber da wir keine Lizenzgebühren einnehmen, müssen wir eben auf andere Weise den finanziellen Aufwand decken, den die Entwicklung und Vermarktung des OpenEMM verursacht. Und ein individueller kostenloser Support wäre in diesem Zusammenhang extrem kontraproduktiv.

Letzten Freitag hat sich der LBCN (Linux Business Campus Nürnberg) in Open Source Business Foundation (OSBF) umbenannt. Hintergrund dieser Entscheidung ist die Entwicklung der Mitgliederstruktur, die eine Erweiterung des Vereins auf die gesamte Welt der Open-Source-Software und eine neue, europaweite Ausrichtung erforderte.

Während bei Gründung des Vereins die Mitglieder vornehmlich aus dem Linux-Umfeld kamen und in der Metropolregion Nürnberg beheimatet waren, hat das rasante Wachstum auf mittlerweile knapp 120 Mitglieder dazu geführt, dass nun alle Bereiche des Open-Source-Marktes abgedeckt werden und 3/4 der Mitglieder außerhalb der Ursprungsregion Nürnberg angesiedelt sind - 10% sogar außerhalb Deutschlands und einige in den USA.

Mit seinem starken Mitgliederwachstum und der neuen Ausrichtung hat die OSBF nun die Chance, zu einem internationalen Netzwerk der europäischen Open-Source-Branche zu reifen. (Da ich in den erweiterten Vorstand des Vereins gewählt wurde, sehen Sie mir meinen Enthusiasmus bitte nach.) Die vollständige Pressemeldung zur OSBF lesen Sie hier.

In den USA lässt sich beobachten, dass in denjenigen Segmenten des Software-Marktes, in denen mehrere Open-Source-Projekte vergleichbarer Ausrichtung existieren, diese zunehmend untereinander konkurrieren. Die Entwickler und Anbieter der Projekte versuchen sich gegenseitig zu übertrumpfen, indem sie öffentlich Technologien und Funktionsumfänge der Software sowie Kennzahlen wie die Anzahl der Downloads und das Alter (=Reife?) der Projekte miteinander vergleichen.

Dieses Vorgehen ist schon länger im Markt der Linux-Distributionen der Fall, in letzter Zeit aber auch bei Applikationen zu verfolgen - speziell in den Märkten für CMS-, CRM- und ERP-Software. Deren größte Vertreter werden zunehmend von Venture-Capital-Unternehmen finanziert und haben mit den frischen Finanzmitteln u.a. aggressive Vertriebsmannschaften aufgebaut, um die Vorteile der eigenen Software an potenzielle Kunden zu kommunizieren.

Auf der einen Seite kann ich dieses Verhalten nachvollziehen. So beobachten wir als Entwickler des OpenEMM natürlich auch aufmerksam die Aktivitäten von phpList (das ist die Open-Source-Software, die unserer am nächsten kommt) und vergleichen sämtliche Parameter, die wir für beide Projekte ermitteln können.

Auf der anderen Seite halte ich das öffentliche Vergleichen mit anderen Open-Source-Projekten für den völlig falschen Ansatz im Vertrieb, der nur vom echten Wettbewerb ablenkt. Natürlich ist es schön, wenn man der größte Open-Source-Anbieter in seinem jeweiligen Marktsegment ist, so dass die Venture-Capital-Geber schon vom nahenden IPO-Termin oder Trade Sale an IBM, Oracle oder SAP träumen dürfen.

Hauptwettbewerber einer Open-Source-Software sind jedoch nicht andere, ähnlich ausgerichtete Open-Source-Projekte, sondern die kommerziellen Closed-Source-Produkte (z.B. von IBM, Oracle und SAP), deren Lizenzen für viele tausend bis hunderttausend Euro angeboten werden, ohne dass der potenzielle Käufer - ganz im Gegensatz zu Open-Source-Software - vor dem Kauf feststellen kann, ob das gewählte Produkt in der Praxis tatsächlich seinen Anforderungen entspricht.

Der Fokus auf Open-Source-Wettbewerber schwächt den noch kleinen, zarten Open-Source-Markt und hat keinerlei Auswirkungen auf den großen, mächtigen Closed-Source-Markt. Letzerer ist jedoch derjenige Markt, auf den wir uns konzentrieren sollten und von dem wir uns alle ein dickes Stück abschneiden wollen - ein Stück, das um ein Vielfaches größer ist als derzeit der gesamte Open-Source-Markt!

Wenn man ein neues Open-Source-Projekt starten möchte, ist auch das Timing für dessen Erfolg entscheidend. Ich glaube nicht, dass es mittlerweile noch irgendein Segment im Softwaremarkt gibt, für das der Start eines Open-Source-Projektes jetzt noch zu früh wäre. Dagegen sind einige populäre Märkte wie Datenbanken, Content Management Systeme oder CRM-Software bereits heute so dicht besetzt, dass man als neuer Anbieter nur noch einer unter vielen wäre. Wessen Herz oder Knowhow an einem bestimmten Thema hängt, das bereits belegt ist, der sollte sich das populärste Projekt aus diesem Marktsegment heraussuchen und dafür Open-Source-Erweiterungen in Form von modularen Extensions oder Plugins entwickeln. Dies kann wesentlich aussichtsreicher sein, als das x-te Projekt zu einem bestimmten Thema zu starten.

Ist das favorisierte Marktsegment dagegen erst mit einem einzelnen Anbieter belegt oder sogar noch völlig unbesetzt, dann ist jetzt der richtige Zeitpunkt, um mit einem eigenen Open-Source-Projekt zu starten, denn günstiger werden die Zeiten nie mehr werden! Es ist aus meiner Sicht nur noch eine Frage der Zeit, bis auch die letzten weißen Flecken auf der Software-Landkarte mit Open-Source-Projekten abgedeckt sein werden, denn inzwischen stellt sich jeder strategisch denkende Entwickler von Closed-Source-Software täglich die Frage, wie er mit dem Thema Open Source umgeht. Wartet er, bis es die ersten Open-Source-Wettbewerber gibt und reagiert dann darauf (in welcher Form auch immer)? Oder agiert er offensiv und bietet deshalb selbst eine Open-Source-Variante seiner Software an, um den Markt möglichst früh (mit) zu besetzen und Erfahrungen zu sammeln?

Ich persönlich glaube, dass wir mit Open Source erst ganz am Anfang der Entwicklung stehen und in wenigen Jahren praktisch jeder Software-Entwickler Open-Source-Varianten seiner Produkte anbieten wird bzw. muss! Die qualitativen und Wettbewerbs-Vorteile von Open Source gegenüber Closed Source sind einfach zu überzeugend - das gilt langfristig selbst für diejenigen Anbieter, die heute (noch?) in ihrem jeweiligen Marktsegment führend sind.

Was allerdings nicht funktioniert, ist die Annahme, aus einer Phase der Schwäche heraus durch den Wechsel zum Open-Source-Entwicklungsmodell zu wirtschaftlicher Stärke zurückkehren zu können. Diese Erwartung ist leider falsch, denn zum einen ist Open Source erst einmal kein Geschäftsmodell, sondern ein Entwicklungsmodell, und zum anderen braucht man einen langem Atem, um ein Open-Source-Projekt zum Erfolg zu führen. Kurzfristig stellt sich dieser Erfolg in den seltesten Fällen ein, weil eine Open-Source-Variante den Anbieter in der Regel zuerst Umsatz mit Bestandskunden kostet (die zu der neuen Version wechseln) und es einige Zeit dauert, bevor mit der Software eine so große Verbreitung erzielt wird, dass der mit Neukunden erzielte Dienstleistungs-Umsatz den Umsatzverlust bei den Bestandskunden übersteigt.

Als Programmbeirat des Kongresses Open Source Meets Business 2008 soll (darf) ich mir sämtliche Präsentationsentwürfe für Vorträge auf der Konferenz anschauen, diese kommentieren und bewerten. Mein erster Eindruck: Da kommen sehr interessante Themen auf uns zu, so dass die Auswahl, welcher Vortrag einen Slot im Programm erhalten soll, nicht leicht fällt.

Um Ihnen etwas Appetit auf den Kongress zu machen: Zum einen sind Vorträge vorgeschlagen, die Ihnen Knowhow für den eigenen Betrieb vermitteln, wie z.B.:

• Überwachung der IT mit Open-Source-Software


• Desaster Recovery mit Open-Source-Software


• Vorstellung der Webservices-Alternative REST


• Vergleich von ERP-Systemen auf Open-Source-Basis

Zum anderen findet am ersten Tag des Kongresses der Investment Summit statt, der speziell die Entwickler, Anbieter und Vermarkter von Open-Source-Software anspricht mit Themen wie:

• Vermarktungsmodelle für Open-Source-Lösungen


• Erfahrungsbericht zur Akquisition von Kapital


• Wachsen ohne Venture Capital

Dies sind allerdings nur Vorschläge, die ich persönlich interessant finde und positiv bewertet habe. Sobald das Konferenzprogramm verabschiedet und öffentlich verfügbar ist, werde ich hier darüber berichten. Der Kongress selbst findet vom 22. bis 24. Januar 2008 in Nürnberg statt.

Wenn man einmal untersucht, warum ein bestimmtes Open-Source-Projekt erfolgreich ist (im Sinne von finanziell erfolgreich für dessen Entwickler und das begleitende Öko-System), dann kristallisieren sich aus meiner Sicht die folgenden drei Erfolgsfaktoren heraus:

1. Der Verbreitungsgrad der Software in der Zielgruppe (als Produkt aus den drei Einzelfaktoren Funktionsumfang, Bedienungsfreundlichkeit und Bekanntheitsgrad)


2. Die Größe und der Aktivitätsgrad der Projekt-Community (als Ergebnis des Community-Supports durch die Entwickler sowie der Offenheit und Zugänglichkeit des Projektes - dazu in einem späteren Beitrag mehr)


3. Die geografische Verbreitung und fachliche Qualität des Partner-Netzwerks (d.h. lokale Partnerunternehmen, die Implementierungen, Schulungen und Support vor Ort übernehmen)

Diese drei Erfolgsfaktoren formen zusammen das Image eines Open-Source-Projektes bei Nutzern, Interessenten und Partnern. Ein gutes Image kann zum Aufbau einer echten Marke (im Sinne von brand) führen, die dann für Wettbewerber (Closed Source wie Open Source) eine hohe Markteintrittsbarriere darstellt.

In folgenden Beiträgen werde ich noch ausführlicher darauf eingehen, ob bzw. mit welchen Maßnahmen sich die genannten drei Erfolgsfaktoren für Open Source beinflussen lassen.

In der Annahme, dass es später noch einmal nützlich sein könnte, habe ich alle Vorbereitungen, die wir 2005 und 2006 getroffen haben, um mit dem OpenEMM Open Source zu gehen, Tag für Tag dokumentiert. Kürzlich hatte ich einen Beratungstermin mit einem Unternehmen, das jetzt ebenfalls den Open-Source-Pfad einschlagen möchte. Aus diesem Anlass bin ich meine OpenEMM-Aufzeichnungen noch einmal durchgegangen und habe daraus eine Todo-Liste mit den meiner Meinung nach 20 wichtigsten Punkten zusammengestellt (ohne allgemeingültige Weisheiten zum Thema Projektmanagement):

Vor der Entscheidung zum Going Open Source:

1. Wettbewerber analysieren, die bereits Open Source gegangen sind (falls Sie in Ihrem Marktsegment nicht der erste wären und kein Wettbewerber eine dominierende Marktposition besitzt: Ist eine deutliche Abgrenzung voneinander möglich?)


2. Informationen über Unternehmen, die bereits erfolgreich Open Source gegangen sind, sammeln und auswerten (im Enterprise Open Source Directory von Optaros suchen, Projektstatistiken auf SourceForge SourceForge analysieren und Websites der Unternehmen besuchen)


3. Plausible Geschäftsmodelle rund um das eigene Open-Source-Produkt identifizieren (Wichtig: Open Source ist kein Geschäfsmodell per se!) und davon ausgehen, dass mindestens die Hälfte davon in der Praxis nicht wie gewünscht funktionieren wird


4. Prüfen, inwieweit ein Going Open Source den Umsatz mit Bestandskunden vermindern und den Umsatz mit neuen Kunden erhöhen könnte (Kernfrage: Lässt sich mit dem potenziellen Mehrumsatz der Umsatzverlust bei den Bestandskunden mehr als ausgleichen?)


5. Bei Investoren und Gesellschaftern/Aufsichtsrat vorfühlen, ob Open Source ein bekannter Begriff ist und die grundsätzliche Bereitschaft besteht, sich mit diesem Thema, das einen langfristigen Investitionshorizont voraussetzt, auseinanderzusetzen


6. Argumentation für Bestandskunden entwickeln, warum das Open-Source-Produkt auch für sie als Nutzer der kostenpflichtigen Software-Variante Vorteile hat, um Umsatzschwund zu minimieren (potenzielle Geschäftsmodelle ggf. überarbeiten)


7. Initialen Funktions- und Leistungsumfang der Open-Source-Software festlegen (ggf. in Abgrenzung zu der Software-Variante, die weiterhin kostenpflichtig bleibt)


8. Strategie- und Finanzplan aufstellen, um Investoren und Gesellschafter/Aufsichtsrat vom Going Open Source zu überzeugen

Nach der Entscheidung zum Going Open Source:

9. Projektnamen und -logo wählen, die das Potenzial für einen weltweiten Markennamen haben, zugehörige Domain-Namen registrieren und Projektnamen bei SourceForge reservieren


10. Detailgrad für Entwickler-, Administrations- und Anwender-Dokumentation festlegen (hat großen Einfluss auf die Zeitplanung)


11. Open-Source-Lizenzvarianten vergleichen und die für das eigene Projekt passende auswählen (die OSI-Website führt eine Liste aller OSI-zertifizierten Lizenzen)


12. Falls die Open-Source-Software auf Closed-Source-Komponenten oder -Bibliotheken aufsetzen würde, diese durch Open-Source-Alternativen ersetzen (z.B. Oracle Database durch MySQL)


13. Quellcode-Refactoring (Sicherheitslücken schließen, Bibliotheken und Frameworks aktualisieren, Code strukturieren und dokumentieren, alle Bezeichner und Kommentare in englischer Sprache, Lizenz-Header einfügen, etc.)


14. Englischsprachige Dokumentation für Entwickler (Dateistruktur, Datenbank-Schema, etc.), Administratoren (Installation + Konfiguration) und Anwender (Handbuch + Online-Hilfe) verfassen bzw. überarbeiten


15. Englischsprachige Projekt-Website (unter Projekt-Domainnamen und org-TLD) aufbauen - die wichtigsten Inhalte sind Community-Elemente wie FAQs, Foren, Wiki, Bugtracker und Roadmap sowie Nutzenargumentation, News-Rubrik, Lizenzvereinbarung und (dezente) Links auf kommerzielle Angebote


16. Kommerzielle Angebote und Services aus Gründen der Hygiene nicht auf der org-Website, sondern auf der bisherigen Unternehmens-Website listen


17. Ankündigungstexte für News-Rubrik auf Projekt- und Unternehmens-Website sowie für SourceForge, Freshmeat und Presseinfo verfassen (ggf. PR-Agentur für Presseinfos, White Paper, Pressegespräche, Redaktionsbesuche, etc. beauftragen)


18. Programmcode und Quellcode der Software auf SourceForge einstellen (alle andere Plattformen sind aufgrund des weitaus geringeren Vermarktungs-Effektes ungeeignet) und dessen Verfügbarkeit über alle Kanäle ankündigen


19. Für Web-basierte Open-Source-Software Demo-Server einrichten, der per Internet öffentlich zugänglich ist und den Interessenten Live-Tests erlaubt


20. Alles, was für das initiale Release der Open-Source-Software nicht fertig geworden ist, in die (öffentliche!) Roadmap aufnehmen

Diese Checkliste liefert natürlich nur eine stark komprimierte Zusammenfassung der erforderlichen Tätigkeiten und erhebt keinen Anspruch auf Vollständigkeit. Auch die Reihenfolge der Punkte ist nur als Vorschlag zu verstehen, zumal einige Themen ohnehin parallel bearbeitet werden sollten. Auf einzelne Punkte dieser Liste werde ich in späteren Beiträgen noch genauer eingehen.

Bitte seien Sie sich darüber im Klaren, dass für Sie nach der Veröffentlichung der ersten Open-Souce-Version die Arbeit erst richtig anfängt! So muss der Activity Index bei SourceForge (der in etwa dem Page Rank bei Google entspricht), aufmerksam verfolgt und ggf. optimiert werden, die Foren- und Wiki-Einträge sind zu kontrollieren und moderieren, FAQs müssen formuliert werden, E-Mails von Nutzern, die kostenlosen Support erwarten, sollten (in welcher Form auch immer) beantwortet werden, Erfolgskennzahlen wie Visits und Downloads wollen erhoben und interpretiert werden, und so weiter und so fort ... Going Open Source ist kein zeitlich befristeter Abenteuerurlaub, sondern wie ein Umzug in ein fremdes Land - dessen sollten Sie sich bewusst sein.

Abschließend noch ein Literaturtipp zu einem Buch, das für mich persönlich sehr hilfreich war und bestimmt auch Ihnen wertvolle Informationen liefern wird: "Producing Open Source Software", Karl Fogel, O'Reilly-Verlag. Nachtrag: Der Inhalt dieses Buches ist auch kostenlos online verfügbar!

Open-Source-Software ist zwar frei erhältlich, trotzdem kosten deren Entwicklung und Vermarktung Geld. Dies gilt natürlich auch für Projekte, die nicht von einem kommerziellen Unternehmen getragen werden, wie z.B. der Linux-Kernel, der Apache-Webserver oder die Eclipse-IDE. In diesen Fällen übernehmen die Arbeitgeber der beteiligten Entwickler wie IBM, Novell oder Red Hat die Kosten für Gehälter und Vermarktung.

Auf jeden Fall müssen die finanziellen Aufwendungen, die die Entwicklung und Vermarktung von Open-Souce-Software verursacht, auf andere Weise als durch die Zahlung von Lizenzgebühren erwirtschaftet werden. Ich habe dazu eine Liste von Vorschlägen zusammengestellt, wie man mit Open-Source-Software Geld verdienen kann:

Beratung:

• Evaluierung, welche Open-Source-Produkte für ein Projekt geeignet sind


• Seminare und Workshops zu einem Produkt für potenzielle Nutzer


• Beratung zu Implementierung und Betrieb


• Schulungen für Anwender


• Schulungen für Entwickler


• Kongresse für Interessenten, Nutzer und Entwickler

Support:

• Installation und Konfiguration


• Migration von Bestandsdaten


• Übersetzen der Benutzeroberfläche in andere Sprachen


• Verfassen von maßgeschneiderter Dokumentation (Handbücher, Online-Hilfe)


• Zugang zu Support-Foren, die direkt von Entwicklern betreut werden


• kostenpflichtige Support-Hotline (Telefon, E-Mail, Chat)


• Laufzeitverträge zur Übernahme von Gewährleistung und Haftung


• Wartungsverträge mit unterschiedlichen Service Levels


• Supportverträge für Altversionen über definierten Zeitraum


• 2nd-Level-Support für 1st-Level-Support-Partner (Consulting, Training, Entwicklung)

Betrieb:

• Bereitstellung des getesteten/zertifizierten Programmcodes (d.h. nur der Quellcode ist frei zugänglich)


• Automatisierte Online-Updates des Programmcodes


• Beobachtung und Überwachung des Produktivbetriebs


• Hosting der Software (inkl. passender Hardware) für Endkunden


• Zusatzservices wie Backup-Services, Firewall, Load-Balancing, etc.


• Hosting der Software für 1st-Level-Support-Partner

Entwicklung:

• Beseitigung von Bugs


• Erweiterung um kundenindividuelle Funktionalität


• Programmierung neuer Schnittstellen


• Integration mit anderer Software (Anpassung von/an Schnittstellen)


• Bundling mit anderen Software-Komponenten zu einem eigenen Produkt

Sonstiges:

• Lizenzierung von kommerziellen Zusatzmodulen


• Upgrade auf kommerzielles Premium-Produkt


• Verkauf von Appliances (Server mit installierter und vorkonfigurierter Software)


• Zertifizierung von 1st-Level-Support-Partnern (für Installation, Konfiguration, Monitoring, Administration)

Diese Liste erhebt natürlich keinerlei Anspruch auf Vollständigkeit, sondern soll Ihnen Anregungen geben und vor allem auch zeigen, dass es eine Vielzahl von Möglichkeiten gibt, um mit Open Source Geld zu verdienen.

In meinem letzten Beitrag unten habe ich bereits geschrieben, dass es für einen Anbieter von Software erstrebenswert ist, wenn möglichst alle Nutzer die gleiche (neueste) Version seiner Software benutzen.

Was kann man tun, um seine Nutzer zum Update zu bewegen? Die Erfahrung zeigt, dass selbst dann, wenn die aktuellere Version einer Software schon länger verfügbar ist und sich das Update sehr einfach durchführen lässt, das Beharrungsvermögen der Nutzer immens ist. So besteht z.B. bei unserem Projekt OpenEMM die Deinstallation aus nur sieben Kommdandos, und die Installation der neuen Version - inklusive einer ggf. erforderlichen Migration der Bestandsdaten - benötigt etwa ein Dutzend Kommandos. Alles wird ausführlich in der Installationsanleitung erklärt und ist in 15 bis maximal 30 Minuten erledigt.

Beispielsweise führt ein Update von OpenEMM 5.1 auf das ganz aktuelle Maintenance Release 5.1.1 dazu, dass drei kleinere neue Features hinzukommen und 16 bekannte Bugs beseitigt sind. Trotzdem ist in der Vergangenheit jeweils nur ein sehr kleiner Teil der installierten Basis auf solch eine neuere Version gewechselt.

Natürlich kann und sollte man von seinen Nutzern nicht erwarten, dass sie jedes Mini-Release mitmachen. Aber manchmal wundert man sich als Entwickler schon, mit welch veralteten Produkten "draußen" noch gearbeitet wird. Einerseits schade, weil die Nutzer nicht die beste Version benutzen, die Ihnen zur Verfügung steht - andererseits beruhigend, dass bereits eine veraltete Version "gut genug" zu sein scheint.

Wer sich mit dem Status Quo nicht zufrieden geben und seine Nutzer stärker zum Update motivieren möchte, dem bieten sich zwei Maßnahmen an:

• Die erste, relativ einfach umzusetzende Maßnahme ist die Einführung eines regelmäßigen Online-Versionschecks, z.B. beim Start der Software oder bei jedem Login des Nutzers. In diesem Fall prüft die Software über einen Internet-Aufruf auf dem Webserver des Open-Source-Projektes, ob es sich um die aktuellste Version handelt bzw. welche Vorteile die aktuellste Version bietet (im einfachsten Fall durch die Anzeige eines Links auf das Changelog). Dadurch wird der Nutzer automatisch darauf hingewiesen, dass eine neuere Version verfügbar ist und aus welchen Gründen er wechseln sollte. Das funktioniert sehr gut: Wir haben mit dem OpenEMM 5.1 dieses Feature eingeführt und seit Verfügbarkeit der Version 5.1.1 sind die Downloads auf SourceForge deutlich höher als für die früheren Maintenance Releases!


• Die zweite, allerdings wesentlich aufwändigere Maßnahme ist eine Online-Update-Funktion, die sich mit einem einzigen Klick durchführen lässt und möglichst keinen Restart des Computers erfordert (wer Firefox nutzt, hat dieses Verfahren gewiss schon zu schätzen gelernt). Über das Online-Update wird dem Nutzer das manuelle Sichern der Daten, das Deinstallieren der alten sowie Downloaden und Installieren der neuen Dateien sowie ggf. Ändern der Konfiguration abgenommen, so dass er sich mit der komplexen Technik hinter der Benutzeroberfläche nicht beschäftigen muss. Gerade Nutzer, die wenig Erfahrung mit der Kommandozeile haben, werden dieses Feasture sehr zu schätzen wissen und weniger Scheu vor einem Update haben.