Community

Open Source bedeutet naturgemäß, dass der Quellcode eines Open-Source-Projektes offen gelegt werden muss. Aber in welcher Form muss der Quellcode veröffentlicht werden, d.h. wie einfach müssen Sie es für Dritte machen, Ihren Quellcode zu verstehen und daraus selbst die ausführbare Software zu erzeugen?

In der Open-Source-Definition der OSI wird lediglich gefordert (Hervorhebung von mir):

The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed.

Auch viele OSI-Lizenzen konkretisieren den Umfang und Dokumentation des Quellcodes nicht. Am weitesten geht meines Erachtens die GPL, die hier wieder mal ihrem Ruf als "härteste" Open-Source-Lizenz gerecht wird. Die GPL2 definiert:

"Source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable".

Und die GPL3 fordert:

"all the source code needed to generate [and] install [...] the work, including scripts to control those activities".

Allerdings wird meines Wissens in keiner Lizenz formuliert, wie viel (oder wenig) Aufwand angemessen ist, um aus dem Projekt-Quellcode die ausführbare Software zu erzeugen. Das bedeutet, dass diese Entscheidung dem Projekt-Verantwortlichen überlassen bleibt.

Wenn es sich um ein kleines Projekt mit wenigen Dateien handelt, ist dieses Thema nicht weiter wichtig, denn ein Nutzer, der sich für den Quellcode interessiert, bringt in der Regel ausreichende Kenntnisse mit, um aus den Quellcode-Dateien auch ohne zusätzliche Anleitung in kurzer Zeit die ausführbare Software zu erzeugen. Bei einem Enterprise-Software-Projekt, wie z.B. unserem OpenEMM, ist eine ergänzende Meta-Dokumentation dagegen wichtig, denn das ganze Projekt besteht aus weit über 1.000 Dateien. Würden wir die Dateien einfach in ein Verzeichnis kopieren und dieses als Zip-Datei oder Tarball auf SourceForge bereitstellen, könnte vermutlich niemand etwas damit anfangen.

Folgende Maßnahmen lassen sich ergreifen, um Nutzern das Generieren des Programmcodes aus dem Quellcode zu erleichtern:

• alle Dateien in einer übersichtlichen Verzeichnisstruktur anordnen


• die Verzeichnisstruktur und den Zweck der einzelnen Dateien in einer eigenen Datei dokumentieren


• die verwendeten Bibliotheken und Frameworks Dritter mit deren Abhängigkeiten und Verwendungszweck auflisten (und bereitstellen)


• das Datenbankschema und die Bedeutung aller Tabellen und Felder kommentieren


• ein Skript (z.B. für Ant) zum automatischen Generieren des Programmcodes zur Verfügung stellen (wie es die GPL fordert)


• die Parameter im Quellcode kommentieren, die Plattform-spezifisch gesetzt werden müssen (sofern erforderlich)

Doch wie einfach möchte man wirklich den Umgang mit dem Quellcode für Dritte gestalten? Auf der einen Seite wünscht man sich natürlich Entwickler in der Community, die bei der Weiterentwicklung der Software helfen. Für diese sollte es so einfach wie möglich sein, den Quellcode zu verstehen und damit zu arbeiten. Auf der anderen Seite will man es den kommerziellen Wettbewerbern nicht zu einfach machen, den Quellcode zu analysieren. Gehen Sie immer davon aus, dass Ihre Wettbewerber die ersten sind, die sich mit Ihrem Quellcode beschäftigen. Entweder, um geeignete Code-Fragmente in die eigene Software zu übernehmen (was bei Closed-Source-Software nicht nachweisbar ist), oder um Sicherheitslücken und Designschwächen zu finden und diese in der vertrieblichen Argumentation gegen Sie verwenden zu können!

Wir haben diesen Zielkonflikt so gelöst, dass wir eine Basis-Quellcode-Dokumentation öffentlich bereitstellen und gleichzeitig interessierten Entwicklern anbieten, sich bei uns zu melden, um weitere, ergänzende Dokumente zu erhalten, die nicht zwingend erforderlich sind, aber das Einarbeiten in das Projekt wesentlich erleichtern. Dadurch bekommen wir zum einen direkten Kontakt mit den Entwicklern, die sich intensiv mit unserem Quellcode beschäftigen und zum anderen haben wir für Wettbewerber eine (gewisse) Hürde aufgebaut.

Neben der in meinem vorigen Beitrag erwähnten Transparenz sind auch die Freundlichkeit und Hilfsbereitschaft einer Community für deren Erfolg entscheidend. Diese wird von dem Kernteam definiert, dem im Idealfall ein eigens für die Betreuung der Community abgestellter Community Manager angehört.

Allgemein gilt für die Kommunikation mit bzw. in der Community: "Wie man in den Wald hineinruft, so schallt es heraus." Seien Sie als Entwickler oder Anbieter daher sensibel bei der Wahl Ihrer Worte und glauben Sie immer an das Gute im Menschen! Gehen Sie beispielsweise bei Fragen von Nutzern, die bereits im FAQ oder Handbuch beantwortet werden, nicht davon aus, dass die Fragesteller nur zu faul zum Suchen sind. Gehen Sie stattdessen davon aus, dass die entsprechenden FAQ-Einträge oder Abschnitte im Handbuch schwer verständlich sind oder nicht gefunden wurden (vielleicht können Sie deren Übersicht und Struktur noch optimieren?) oder dass die Hilfesuchenden nicht so fit in der Sprache sind, die Ihre Dokumentation verwendet.

Ein Bugreport ist kein Angriff auf Ihr Projekt, sondern eine konstruktive Kritik, die Ihnen hilft, Ihr Produkt zu verbessern. Ein Hinweis auf Rechtschreibfehler in der Dokumentation ist keine kleinliche Kritik, sondern hier hat sich jemand die Mühe gemacht, Sie auf Fehler hinzuweisen, die den professionellen Eindruck Ihres Projektes beeinträchtigen. Und die Beanstandung eines umständlich zu bedienenden Features ist keine böswillige Nörgelei, sondern eine zielgerichtete Anregung, die Usability Ihrer Software zu optimieren.

Den meisten Nutzern ist durchaus bewusst, dass sie eine Open-Source-Software kostenlos bekommen haben und daher keinen Rechtsanspruch auf Service und Support geltend machen können. Dementsprechend positiv und dankbar reagiert die Mehrheit, wenn trotzdem auf Ihr Feedback reagiert und bei Problemen geholfen wird. Und sollte ein Nutzer doch einmal fordernd oder gar unverschämt auftreten, so hilft der freundliche Hinweis, dass er herzlich dazu eingeladen ist, als Contributor an der Beseitigung des kritisierten Missstands mitzuhelfen, oft Wunder.

Wie ich bereits mehrfach geschrieben habe, ist eine Community sehr wichtig für den Erfolg eines Open-Source-Projektes. Doch wie lässt sich eine große Community aufbauen (-> Quantität)? Und wie können deren Mitglieder motiviert werden, die Software, deren Dokumentation und das Angebot an E-Selfservices nicht nur passiv zu nutzen, sondern sich aktiv an dem Projekt zu beteiligen (-> Qualität)? (Dabei muss es nicht gleich Programmierung sein, eine Beteiligung kann beispielsweise auch durch das Verfassen und Verbessern der Dokumentation, Übersetzungen der Benutzeroberfläche und Handbücher, Supporteinträge in Foren und Maillisten oder Bugreports und Bugfixes erfolgen.)

Ein entscheidender Faktor für die Größe einer Community ist natürlich die Art der Software. Ein praktisches Backup-Tool für jedermann wird immer ein größeres Potenzial haben, als beispielsweise eine komplexe ERP-Software für eine ganz spezielle Branche. Doch davon abgesehen ist meiner Meinung die Transparenz eines Open-Source-Projektes ein ganz entscheidender Punkt für die Motivation, bei diesem Projekt mitzumachen:

• Transparenz beim Quellcode durch dessen Offenlegung und Dokumentation


• Transparenz beim Programmcode durch ein ausführliches Handbuch zu Installation, Konfiguration und Betrieb


• Transparenz bei den Fehlern durch einen öffentlichen Bugtracker


• Transparenz bei der Planung durch eine öffentliche Roadmap


• Transparenz beim Feedback der Community durch öffentliche Foren und/oder Maillisten ohne Zensur kritischer Beiträge

Transparenz in einem Open-Source-Projekt führt dazu, dass auch diejenigen Community-Mitglieder, die nicht zum inneren Kreis der Entwickler (die sogenannten Committer) zählen, wissen, was für das Projekt bereits getan wurde, was gerade getan wird, was noch getan werden muss und was eigentlich getan werden sollte. Dadurch sind die Community-Mitglieder außerhalb des Committer-Kreises in der Lage, zu erkennen, wo bei dem Projekt Hilfe und Unterstützung erforderlich sind. Für ein Community-Mitglied, das zu dem Projekt beitragen möchte (der sogenannte Contributor) steigt damit die Chance, dass sein Beitrag zum Projekt auch tatsächlich gewünscht ist und von den Committern verwendet werden wird.

Nun ist Transparenz für Software-Entwickler nicht unbedingt etwas Selbstverständliches, sondern exakt das Gegenteil von dem, was bei Close-Source-Software üblich ist. Bei Closed-Source-Software

• ist der Quellcode für die Nutzer nicht verfügbar


• die Dokumentation zum Produkt gibt es erst nach dem Kauf


• Fehler der Software werden möglichst geheim gehalten


• die Planung wird aus Angst vor der Konkurrenz nur eingeschränkt offen gelegt


• kritisches Feedback in Foren und Maillisten (sofern diese überhaupt vorhanden sind) wird gelöscht

Für Entwickler, die zuvor nur Closed-Source-Software angeboten haben, ist also ein Umdenkungsprozess erforderlich. Wenn die Transparenz-Erkenntnis sich jedoch erst einmal durchgesetzt und die Denkweise entsprechend geändert hat (ich spreche wieder aus eigener Erfahrung), kommt die Community von ganz allein in Gang: Es finden sich erste Anwender, die mithelfen, in den Supportforen Fragen anderer Nutzer zu beantworten, erste Dokumentations-Einträge im Wiki werden veröffentlicht, Bugreports inklusive Vorschläge für das Fixing werden eingereicht, Übersetzungen für die Benutzeroberfläche gehen ein, etc.

Glauben Sie mir: Ihre Anstrengungen, für Ihr Open-Source-Projekt Transparenz zu schaffen, werden - ggf. mit etwas Verzögerung - durch den Einsatz der Community für das Projekt reich belohnt!

Eine große, aktive Community ist ein Aktivposten für jedes Open-Source-Projekt und ein wichtiger Wettbewerbsvorteil gegenüber Closed-Source-Software - aber auch gegenüber Open-Source-Wettbewerbern (ja, sowas gibt es mittlerweile auch!), die noch nicht soweit sind.

Eine funktionierende Community bietet für das Open-Source-Projekt eine ganze Reihe von Vorteilen:

• kostenlose Werbung (Blog-Einträge, Foren-Beiträge, etc.)


• Ideen für die Roadmap (neue Features)


• Feedback zu Quellcode und Architektur (Vorschläge für Optimierungen, Hinweise auf Sicherheitsschwachstellen, etc.)


• Verbesserung der bestehenden Dokumentation


• Verfassen von Erweiterungen der Dokumentation (Installationsanleitungen, Tutorials, etc.)


• Übersetzungen für Benutzeroberfläche und Dokumentation


• Support für andere Nutzer (via Foren oder Maillisten)


• Tests von Beta-Versionen und Release Candidates


• Bug-Reports und Bug-Fixes (hohe Verbreitung sorgt für viele Tester und letztendlich weniger Fehler)


• Portierungen auf andere Betriebssysteme und Distributionen


• Refactoring von bestehendem Quellcode


• Erweiterung des Quellcode um funktionale Erweiterungen

Und sicher habe ich noch den ein oder anderen Punkt vergessen.

Wie Sie sehen, muss der Hauptnutzen einer Community nicht unbedingt sein, dass diese die Software kostenlos weiterentwickelt, wie es beispielsweise bei den Projekten der Apache Software Foundation der Fall ist. Bei bekannten Open-Source-Projekten wie MySQL, JasperSoft, SugarCRM oder Compiere wird die Entwicklung sogar primär von Entwicklern betrieben, die bei den jeweiligen Unternehmen, die hinter den Open-Source-Projekten stehen, fest angestellt sind. (Bei AGNITAS ist es übrigens nicht anders.)

Als Auslöser für die Bildung einer Community sehe ich die Philosophie der Open-Source-Entwicklung, die sich grundlegend vom Closed-Source-Entwicklungsmodell entscheidet. Während Closed-Source-Projekte von einem kleinen Kreis von Insidern entwickelt werden, der nicht nur den Quellcode, sondern oft auch dessen Bugs und manchmal sogar die Roadmap geheimhält, herrscht bei Open Source volle Transparenz: offener Quellcode, offen verfügbarer Bugtracker, offengelegte Roadmap, offenes (kritisch-konstruktives) Feedback via Foren und Maillisten!

Diese Offenheit führt letztendlich zu einer Gemeinschaft von Unterstützern, die die Community rund um das Projekt bilden - das hat mit dessen kostenloser Verfügbarkeit erst einmal gar nichts zu tun! Umgekehrt bedeutet dies, dass Closed-Source-Software keine Community aufbauen kann (allenfalls eine vom Hersteller gesponserte User Group) und dementsprechend auch nicht von den zahlreichen Vorteilen solch einer Gemeinschaft profitieren wird.

Ich bin übrigens überzeugt, dass auf lange Sicht eine gute Community der Grund sein kann, warum ein Nutzer eine Open-Source-Software einem Closed-Source-Projekt vorzieht. Und gegen diesen Wettbewerbsvorteil wird Closed Soure wenig ausrichten können.