Der 20-Punkte-Plan für Open Source

Wer mit dem Gedanken spielt, seine Software oder einen Teil davon als Open-Source-Software zu veröffentlichen, darf den Aufwand hierfür nicht unterschätzen. Martin Aschoff, Autor des nachfolgenden Artikels, ist Gründer und Vorstand der AGNITAS AG, die unter anderem die populäre Open-Source-Applikation OpenEMM betreut und weiterentwickelt. Außerdem ist er Vorstandsmitglied und Open Source Coach der Open Source Business Foundation (OSBF).
Er hat hier eine Liste der 20 wichtigsten Punkten (ohne allgemeingültige Weisheiten zum Thema Projektmanagement) für ein »Going Open Source« aufgeführt, die direkt aus der Praxis entstanden ist.
Richard Seibt

Vor der Entscheidung zu Open Source

1. Analysieren Sie Wettbewerber, 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. Sammeln Sie Informationen über Unternehmen, die bereits erfolgreich Open Source gegangen sind, und werten Sie diese aus. Suchen Sie beispielsweise im Enterprise Open Source Directory von Optaros, analysieren Sie die Projektstatistiken auf SourceForge (Rankings, Downloads, Bugtracker-Aktivitäten, etc.) und besuchen Sie deren Projekt-Websites.

3. Identifizieren Sie plausible Geschäftsmodelle rund um Ihr eigenes Open-Source-Produkt. Wichtig: Open Source ist kein Geschäftsmodell an sich, sondern nur ein Entwicklungs-, Vertriebs- und Marketing-Modell. Dieser Schritt ist der wichtigste von allen, um Erfolg zu haben. Gehen Sie auch davon aus, dass mindestens die Hälfte der Geschäftsmodelle in der Praxis nicht wie gewünscht funktionieren wird.

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

Anlaufstelle für alle, die Open Source unterstützen oder entsprechende Produkte entwickeln und anbieten wollen: die Open Source Business Foundation.

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

6. Entwickeln Sie eine Argumentation für Bestandskunden, warum das Open-Source-Produkt auch für sie als Nutzer der kostenpflichtigen Software-Variante Vorteile hat, um Umsatzschwund zu minimieren. Gegebenenfalls müssen Sie Ihre potenziellen Geschäftsmodelle daraufhin überarbeiten.

7. Legen Sie den initialen Funktions- und Leistungsumfang der Open-Source-Software fest – gegebenenfalls in Abgrenzung zu der Software-Variante, die weiterhin kostenpflichtig bleibt. Specken Sie das Produkt nicht zu weit ab, denn es muss attraktiv genug sein, damit sich der Aufwand für Download, Test, Installation und Konfiguration lohnt.

8. Stellen Sie einen Strategie- und Finanzplan auf, um Investoren und Gesellschafter/Aufsichtsrat vom Going Open Source zu überzeugen.

Auf Seite 2: Nach der Entscheidung

Nach der Entscheidung zu Open Source

9. Wählen Sie einen Projektnamen und ein Logo aus, die das Potenzial für einen weltweiten Markennamen haben, registrieren Sie die zugehörigen Domain-Namen und reservieren Sie den Projektnamen bei SourceForge.

10. Legen Sie den Detailgrad für die Entwickler-, Administrations- und Anwender-Dokumentation fest. Dieser Punkt hat erfahrungsgemäß neben dem Refactoring (siehe Punk 13) den größten Einfluss auf die Zeitplanung.

11. Vergleichen Sie die verschiedenen Open-Source-Lizenzvarianten und wählen Sie die für das eigene Projekt passende aus. Entscheiden Sie sich für eine OSI-zertifizierte Lizenz (www.opensource.org/licenses/category) wie Apache, BSD, CPAL, Eclipse, GPL, LGPL oder MPL.

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

13. Führen Sie ein Refactoring des Quellcodes durch, d.h. schließen Sie Sicherheitslücken, aktualisieren Sie Bibliotheken und Frameworks, strukturieren und dokumentieren Sie den Code, stellen Sie alle Bezeichner und Kommentare auf englische Sprache um, fügen Sie die Lizenz-Header ein, etc.

14. Verfassen Sie eine englischsprachige Dokumentation für Entwickler (Dateistruktur, Datenbank-Schema, etc.), Administratoren (Installation + Konfiguration) und Anwender (Handbuch + Online-Hilfe) bzw. überarbeiten Sie die vorhandene Dokumentation. Lassen Sie die Anwender-Dokumentation nicht von den Entwicklern schreiben.

15. Starten Sie eine englischsprachige Projekt-Website (unter Projekt-Domainnamen und org-TLD). Die wichtigsten Inhalte sind Community-Elemente wie FAQs, Foren, Wiki, Bugtracker und Roadmap sowie Nutzenargumentation, News-Rubrik, Lizenzvereinbarung und (dezente) Links auf Ihre kommerziellen Angebote.

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

17. Verfassen Sie Ankündigungstexte für die News-Rubrik auf Ihrer Projekt- und Unternehmens-Website sowie für SourceForge, Freshmeat und Presseinfos. Beauftragen Sie gegebenenfalls eine PR-Agentur für Presseinfos, White Paper, Pressegespräche, Redaktionsbesuche, etc.

18. Stellen Sie den Programmcode und Quellcode Ihrer Software auf SourceForge ein (alle anderen Plattformen sind aufgrund des weitaus geringeren Vermarktungs-Effektes ungeeignet) und kündigen Sie die Verfügbarkeit über alle Kanäle an.

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

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

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.

Bitte seien Sie sich auch 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 unter Umständen optimiert werden, die Foren- und Wiki-Einträge sind zu kontrollieren und moderieren, FAQs müssen formuliert werden, E-Mails von Nutzern, die koste
nlosen 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 …
(Martin Aschoff/mt)

Weblinks
OpenEMM
Agnitas
Open Source Business Foundation

Zum Expertenbeirat von eWEEK europe zählen neben Martin Aschoff unter anderem auch IDC-Geschäftsführer Wafa Moussavi-Amin, der Internet-Guru Ossi Urchs und Ex-IBM-Chef Richard Seibt.