Transparenz für die Community

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!