Einträge von Martin Aschoff

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!

Nichts ist für einen Entwickler unangenehmer, als mit großem Tamtam eine neue Software-Version zu veröffentlichen, die noch einen dicken Bug enthält. Eine sehr beliebte Möglichkeit der Software-Branche, diese Peinlichkeit zu umgehen, ist die Veröffentlichung von Release Candidates (RC). Allerdings haben erfahrungsgemäß die meisten Nutzer kein Interesse daran, eine potenziell fehlerhafte Software zu installieren, zu konfigurieren und zu testen.

Anbieter von kommerzieller Software haben wenigstens die Möglichkeit, ihre Kundschaft zum Testen zu motivieren, indem sie die RC-Versionen kostenlos zur Verfügung stellen. Bei Open-Source-Software kann dies jedoch naturgemäß nicht funktionieren. Entsprechend gering ist oft die Zahl der Nutzer, die sich zum Testen einer RC-Version von Open-Source-Software entscheidet und entsprechend spärlich die Anzahl der Rückmeldungen.

Eine aus meiner Sicht akzeptable Alternative zur Veröffentlichung von Release Candidates ist eine Variante, die ich als Staged Release bezeichne. Staged ("abgestuft") bedeutet, dass die neue Version nicht sofort der ganzen Welt verkündet und zugänglich gemacht wird, sondern dass man versucht, das neue Release Schritt für Schritt einzuführen.

Bei der Version 5.5.0 unseres OpenEMM, die wir derzeit in einem Staged-Release-Prozess veröffentlichen, sehen die Schritte wie folgt aus (wobei die Schritte jeweils im Abstand von zwei bis drei Tagen erfolgen):

Der erste Schritt besteht darin, die neue Version heimlich, still und leise auf SourceForge einzustellen. Wenn Sie den Kreis der ersten Nutzer noch stärker reglementieren möchten, können Sie die Software alternativ nur ausgewählten Kunden und Interessenten über einen eigenen Download-Server anbieten. In beiden Fällen können Sie, wenn die Early Adaptors Probleme feststellen, das Release kurzfristig für den Download sperren, verbessern und ersetzen.

Im zweiten Schritt wird die neue Version für das Online-Update freigeschaltet (sofern Ihre Software über solch eine Funktionalität verfügt), damit ein bestehender Nutzer, der das neue Release auf SourceForge entdeckt, bequem per Online-Update upgraden kann.

Als nächsten Schritt kommunizieren Sie die Verfügbarkeit der neuen Version an die Nutzer Ihrer Software, und zwar (sofern technisch möglich) zuerst an Nutzer einer Uralt-Version, dann an die Nutzer von älteren Versionen und am Schluss an die Nutzer von neueren Versionen. Bei unserem OpenEMM ist das einfach möglich, weil bei jedem Aufruf der Software ein Online-Update-Check durchgeführt wird und sich die Update-Meldung abhängig von der Version der abfragenden Software variieren lässt.

Sind Ihre Kunden informiert, können Sie im anschließenden Schritt die Verfügbarkeit der neuen Version per Newsletter an Ihre Community kommunizieren. Um den Kreis noch mehr zu erweitern, folgt im vorletzten Schritt die Ankündigung der neuen Version auf Ihrer Projekt-Website sowie als Projekt-News auf SourceForge und abschließend im letzten Schritt via freshmeat.net, Xing und ggf. per Pressemeldung an den Rest der Welt.

Sollten Sie im Rahmen des Staged Release tatsächlich eine Bugfix-Version veröffentlichen müssen, so machen Sie bitte kein Silent Update, das die Nutzer verwirrt (weil es unterschiedliche Versionen mit gleicher Bezeichnung gibt), sondern hängen Sie zumindest einen Buchstaben an die verbesserte Version an, z.B. 5.5.0a.

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!

Für Verwunderung und teilweise sogar Empörung hat die Ankündigung gestern gesorgt, dass Microsoft der Open Source Business Foundation beitritt und sein Engagement zusätzlich dadurch unterstreicht, dass Andreas Hartl, Director Platform Strategy von Microsoft Deutschland, einen Sitz im OSBF-Vorstand übernimmt (dem ich auch angehöre).

Ich halte die (negativen) Reaktionen auf Microsofts OSBF-Beitritt für übertrieben. Microsoft hat in den letzten Monaten sehr viel unternommen, um sich mit Open Source anzufreunden. Einen Überblick zu Microsofts umfangreichen Open-Source-Aktivitäten inklusive der Open-Source-Blogging-Plattform Port 25 und der Open-Source-Hosting-Website Codeplex finden Sie hier. Nicht zuletzt hat Microsoft mit der Ms-PL und Ms-RL zwei eigene Open-Source-Lizenzen entwickelt und von der OSI offiziell zertifizieren lassen. Meiner Meinung nach ein deutliches Zeichen, dass es Microsoft mit der Entwicklung eigener und der Förderung fremder Open-Source-Software Ernst meint.

Natürlich klingen uns allen noch Steve Ballmers Stänkereien gegen Open Source im Ohr. Doch Microsoft ist größer und vor allem vielfältiger als Steve Ballmer. Es gibt durchaus Strömungen bei Microsoft, die Open Source nicht nur als Gefahr für Windows und MS Office, sondern auch als Chance für die weitere Entwicklung des Software-Marktes begreifen. Daher auch der Beitritt von Microsoft zur OSBF.

Übrigens hat Microsoft durch den OSBF-Beitritt auch die OSBF-Satzung akzeptiert, und in der steht unter Vereinszweck: "Der Zweck des Vereins ist es, die Software- und Dienstleistungsindustrie, die unter anderem auch nach dem Open Source-Entwicklungsverfahren arbeitet, zu stärken, d.h. insbesondere dazu beizutragen, Arbeitsplätze im Bereich Open Source Softwareentwicklung und -dienstleistung zu schaffen bzw. zu sichern."

Ich empfehle daher allen Skeptikern, Microsoft beim Wort zu nehmen und dem Unternehmen die Zeit zu geben, damit es uns allen durch Taten zeigen kann, wie es Open Source zukünftig in der Praxis unterstützen wird.

Wenn Sie mit Ihrem Open-Source-Projekt frisch starten, haben Sie zunächst 0 Downloads auf SourceForge und liegen dementsprechend in allen Rankings weit hinten. Hier ist mein Tipp, um die Verbreitung Ihrer Software schnell in Schwung zu bringen:

Eine moderne Software sollte keine Insel-Lösung sein, sondern mit anderen Applikationen und Tools kommunizieren und zusammenarbeiten können. Daher lässt sich die Verbreitung Ihrer Open-Source-Software erheblich beschleunigen, indem Sie für populäre "benachbarte" Open-Source-Projekte eine Integration in Form einer Extension oder eines Plugins anbieten. Wenn die "benachbarten" Open-Source-Projekte beispielsweise Download-Zahlen im 6-stelligen Bereich aufweisen und Sie über die neue Anbindungsmöglichkeit an Ihre Software nur ein bis zwei Prozent der vorhandenen Nutzer auch für Ihr Projekt interessieren können, ergeben sich damit automatisch einige tausend Downloads!

Ein praktisches Beispiel: Wir waren bei unserer E-Mail-Marketing-Software OpenEMM der Meinung, dass sowohl eine CMS- als auch eine CRM-Software von der OpenEMM-Funktionalität für professionelles E-Mail-Marketing profitieren würden. Daraufhin haben wir die am meisten verbreitete CMS- und CRM-Lösung im Open-Source-Bereich identifiziert (Typo3 bzw. SugarCRM). Im nächsten Schritt haben wir Entwickler gesucht, die mit dem Schreiben von Typo3-Extensions bzw. SugarCRM-Plugins bereits Erfahrungen gesammelt haben. Mit der Internet-Agentur Target-E aus München und dem Open-Source-Entwickler go-mobile aus Linz konnten wir zwei hervorragende Partner gewinnen, die ihre technische Kompetenz mit der Entwicklung von Typo3-Extensions bzw. SugarCRM-Plugins bereits unter Beweis gestellt haben und aktuell eine entsprechende Erweiterung für den OpenEMM entwickeln bzw. bereits fertiggestellt haben.

Unser Gedanken zur Verbreitung: OpenEMM hat bislang 45.000 Downloads, SugarCRM 330.000 und Typo3 sogar 3.2 Mio. - damit ist ganz klar, dass OpenEMM von einer Typo3-Extension bzw. einem SugarCRM-Plugin erheblich profitieren kann.

Eine Alternative zu der Anbindungsmöglichkeit an eine konkrete Software ist eine generische Webservice-Schnittstelle, über die andere Applikationen und Tools Ihr Projekt "fernsteuern" können. Interessanterweise war dies auch das Feature, das beim OpenEMM in den Foren am meisten nachgefragt wurde - und seit Fertigstellung der Schnittstelle auf Arten genutzt wird, die wir uns selbst gar nicht vorstellen konnten!

Doch gleichgültig, ob Sie sich für eine Software-spezifische Anbindung oder eine generische Webservice-Schnittstelle entscheiden, wichtig ist, dass Sie über Ihren Tellerrand hinausblicken und aktiv an Optionen zur Integration Ihres Projektes in bestehende Open-Source-Lösungen arbeiten.

Der Open-Source-Kongress OSCON des O'Reilly-Verlages (bekannt für seine exzellenten Fachbücher), über den ich letztes Jahr bereits hier berichtet habe, gilt als das Mekka der Open-Source-Szene und findet dieses Jahr vom 21. bis 25. Juli in Portland, Oregon statt. Ich freue mich, dass ich zum 10-jährigen Jubiläum dieser Veranstaltung als Sprecher dabei sein kann.

Das Thema meines Vortrages, der am 23. Juli um 10:45 Uhr Ortszeit startet, lautet "Going Open Source: The 20 Most Important Things To Do". Falls Ihnen das irgendwie bekannt vorkommt - es handelt sich dabei um eine 45-Minuten-Präsentation dieses Beitrags. Anscheinend ist das Thema auch in den USA - wo man angeblich immer schon viel weiter als in Europa ist - so interessant, dass ich von O'Reilly zur OSCON eingeladen wurde.

Meine aktive Teilnahme als Sprecher gibt mir natürlich auch die Gelegenheit, im Juli an dieser Stelle live von der OSCON zu berichten und auch einen Blick hinter die Kulissen werfen zu können. Ich bin gespannt darauf!