Ja, OpenSource hat seine eigenen Gesetze. Das wissen wir wohl spätestens seit The cathedral and the bazaar. Mein grml-Projekt läuft jetzt seit über einem Jahr und für mich ist es seither mindestens ein Halbtagsjob. In dieser Zeitspanne gab es viele Höhepunkte, aber – wie bei jedem Projekt und wie das Leben so spielt[tm] – auch einige Tiefschläge. Was aber hat mich diese Zeit gelehrt?
Projektanfang
“Hallo, ich bin foo und möchte bar machen. Bar soll das Beste Teil werden!!11! Wer macht mit?” Ein oft gemachter Fehler: an die Öffentlichkeit gehen bevor Code existiert. Merke: es werden sich weitere Entwickler nur dann finden, wenn es bereits Code gibt. Setze dich hin, überlege dir das Design, schreibe ein wenig Dokumentation *für* *dich* *selbst* und erst wenn du was Lauffähiges/Vorzeigbares hast, mache dich auf die Suche nach Contributoren.
Für Leseratten: einschlägige Literatur lesen. Gute Startpunkte sind z.B. das bereits erwähnte The Cathedral and the Bazaar von Eric Steven Raymond und “Die Software Rebellen” von Glyn Moody [ISBN: 3478387302].
Zielgruppe
Das typische OpenSource-Projekt ensteht aus der Motivation, dass ein Problem gelöst werden will. Lösungen alla WFM (Works For Me) sind schnell gebastelt, der Weg bis zu einer öffentlichen Release ist aber weit. Wirklich. Ja, definitiv. WFM ist das, was man als $HOME/bin/* kennt. Um Software auch anderen Leuten zugänglich zu machen, muss aber nicht nur die technische Implementierung stimmen. Man muss sich auch um Sachen wie Dokumentation und Support kümmern (mehr zu diesen Themen noch später). Um den WFM-Status erfolgreich(!) zu verlassen muss man sich klar machen, wer denn eigentlich die Zielgruppe ist. Man kann prinzipbedingt einfach nicht alle głücklich machen. Man kann (in den meisten Fällen) einen Experten und einen Anfänger nicht gleichermaßen bedienen. Deswegen sollte man sich die Zielgruppe ganz klar definieren. Die Software/das Projekt muss auch dementsprechend ausgelegt sein.
Lerne mit Kritik umzugehen
Geschmäcker sind verschieden. Ebenso die Kommunikationsfähigkeiten. Es gibt Leute die schon in der ersten Mail an dich einen harrschen Tonfall verwenden. Flamer gibt es ebenso wie freundliche Menschen. Lerne mit ihnen umzugehen. Unterscheide zwischen konstruktiver und destruktiver Kritik und versuche die Aussage hinter dem Text zu finden.
Feedback?
Feedback gibt es vorwiegend bei Problemen. Ein Medienexperte hat mir gelehrt, dass man ca. 10-mal so viel negatives wie positives Feedback bekommt. Das ist also normal. Reagiere aber auf jede Art von Feedback, lasse den Anderen nicht im Ungewissen hängen. Egal ob der Fehler in deinem Produkt oder beim Benutzer (PEBCAK) liegt.
Bugreports
Bugreports kommen von Leuten die sich für dein Produkt interessieren. Wenn sich jemand für dein Produkt nicht interessiert, wird er dich auch gar nicht erst wissen lassen was wo happert. Stelle deinen Benutzern also ein Bug Tracking System (BTS) zur Verfügung. So erhält man Transparenz nach aussen. Bugreports sind dann nicht nur dem Maintainer in dessen Mailbox zugänglich, sondern auch andere Leute dürfen wissen, was Sache ist. Wichtig: das BTS muss *einfach* und *schnell* zugänglich sein. Mache nicht den Fehler, den besonders große, kommerzielle Firmen gerne machen: geschlosse BTS. Das BTS muss öffentlich sein. Verlange auch keinen Account für das BTS. Wer sich erst registieren muss (siehe Bugzilla@Novell) oder einen Account via Mail braucht (siehe bugs.kde.org) hat schon eine Hürde aufgebaut, die viele User gar nicht überqueren können oder wollen. Wer regelmäßig Bugs meldet, wird auch gegen einen Account nichts haben. Aber Leute denen etwas auffällt und die das den Entwicklern mitteilen wollen, möchten nicht erst minutenlang Webfrontents durchklicken. Ein gutes Beispiel, wie man ein BTS sinnvollerweise betreibt ist IMO jenes von Debian. Wer sich ein BTS mangels Ressourcen nicht leisten kann, sollte zumindest einen editierbaren Bereich schaffen. Ein Wiki ist dafür sehr brauchbar. Und für Leute die weder mit dem BTS noch mit einem Wiki umgehen können/wollen empfiehlt es sich, auch ein Webformular zu schaffen. Die darüber versandten Mails kann man immer noch in ein BTS oder das Wiki einpflegen. Natürlich skaliert das nicht beliebig, aber wenn man eine gewisse Projektgröße hat, stellt sich auch die Ressourcenfrage nicht mehr so… Das Webformular hat auch den großen Vorteil, dass der Bugreporter dafür kein funktionierendes Mailsetup braucht. Bei einer Live-CD wie grml übrigens sehr praktisch: mehrere verschiedene Browser sind vorhanden und wer Netzwerk hat kann einen Bugreport ganz schnell und einfach direkt nach dem Start machen.
Produkvermarktung
Screenshots! Für Neulinge deines Produktes zählt der erste Eindruck. In vielen Fällen ist der Aufwand, um “ein Produkt zu aktivieren” hoch. Sei es, dass erst einige (hundert) MB runtergeladen werden wollen, dass die Software erst durch die autoconf/automake-Hölle muss, oder dass man bestimmte Hardware braucht um sie zu nutzen. Bis dein Produkt beim Benutzer läuft, ist der Weg unter Umständen ein langer. Biete dem User also möglichst viele Möglichkeiten, dein Produkt schon im Vorfeld zu begutachten. Screenshots sind leicht und einfach zu erstellen und der User kann schon vorab sehen was ihn erwartet. Wenn ihm das Gezeigte zusagt, hast du vielleicht einen glücklichen Benutzer mehr. Umgekehrt bewahren Screenshots deine Benutzer vor falschen Erwartungen.
Produktverbreitung
Wie verbreite ich meine Software/mein Produkt erfolgreich? Wenn es Software ist, dann soll diese vermutlich nicht nur in deiner Distribution laufen, sondern auch auf Redhat, SuSE, $whatever zu finden sein. Mach es den Paketbetreuern also möglichst einfach, deine Software zu paketieren. Inkludiere eine Lizenzinfromation. Schreibe unbedingt Changelogs! Mach’ deine Software von möglichst wenigen Bibliotheken und weiterer Software abhängig. Sorge dafür, dass dein Produkt schnell zugänglich ist. Besorge Mirror für hohe Verfügbarkeit und schnelle Downloads. Versuche nach Möglichkeit stabile Links sowohl für deine Homepage als auch die Downloads selbst zur Verfügung zu stellen. Für Leute ohne Breitbandzugang sollte es auch einen Weg geben, um an dein Produkt auf anderen Wegen zu gelangen. Opensource-Shops kommen da oft von selbst angetrabt und kosten dich nichts. Und für Interessenten soll es die Möglichkeit geben, um Informationen bezüglich neuer Releases/Versionen zu bekommen, z.B. via Mailingliste oder RSS-Feed.
Werbung
Mundpropaganda. Nichts verbreitet sich schneller und effektiver, als wenn Leidensgenossen miteinander über gleiche Interessen reden. Sorge also dafür, dass deine Zielgruppe dein Produkt kennt. Sobald dein Produkt besser als die existierenden Alternativen ist, erledigt sich das fast von alleine. Das gilt nicht zwingend für alle User (AKA Mainstream), denn dort verbreitet sich in der Regel nicht immer das technisch beste Produkt, aber für deine Zielgruppe gilt das mit ziemlicher Sicherheit. Sei präsent! Schau dir die Referer auf deiner Projekt-Webseite an und melde dich in den Blogs, Artikeln, Foren,… zu Worte, wenn es was zu sagen gibt.
Teamarbeit
Arbeite mit deinen Leuten zusammen und nicht gegeneinander! Versuche zu erkennen, welche Leute für welche Aufgaben geeignet sind. Die meisten Sachen regeln sich von alleine, aber achte darauf, dass sich Leute mit einem Punkt auf der Todo-Liste nicht überfordert fühlen. Eine Zusage alla “ich mache $feature bis…” ist schnell gemacht, die Realisierung aber eine andere Sache. Unterschätze deine Mitstreiter aber auch nicht. Stille Wasser sind oft tief! :-)
Releasezyklen
Ein kritischer Punkt bei OpenSource ist der potenzielle Zeitmangel für das eigene Projekt. Dahinter stecken meist auch finanzielle Aspekte. Damit andere Leute den Status aber einschätzen können, muss die Website aktuell sein. Die letzte Release sollte nicht 3 Jahre zurückliegen. Zeige deinen Benutzern, dass du dich um sie kümmerst und informiere sie regelmäßig über den Entwicklungsstatus. “Release early and often.” Lass dich aber nicht von einem Releasedatum stressen. Kommerzielle Anbieter haben diesen Termindruck und du als freier OpenSource-Entwickler hast einen Riesenvorteil, den du auf keinen Fall ungenutzt lassen solltest. Die Release geht nicht dann raus, wenn es das Marketing will, sondern wenn du als Entwickler die Software als releasereif ansiehst. Wenn die Release deiner Meinung nach steht, dann steht sie, und keine Sekunde früher. Wenn es Deadlines einzuhalten gibt (CD-Druck, Fachartikel,…) , dann setze dir deine eigene Deadline noch wesentlich vor dem Stichtag. Es gibt Faktoren die du nicht kontrollieren kannst. Bugs bemerkt man laut Murphy immer im falschen Moment. Stecke dir aber auf jeden Fall Ziele für Releases. Nur wer ein Ziel vor Augen hat kommt zu einem Ergebnis. Ich verweise in Entwicklergesprächen gerne auf Gets Things Done. “Ach, ich mach die Release, wann es halt passt…” ist der erste Schritt zu Yet-Another-Dead-SourceForge-Project++.
Userfriendly
Schreibe fehlertolerante Software. Entwickler interagieren mit ihrer Software anders als die Benutzer. Deine Benutzer kommen auf Ideen, auf die du nie im Leben kommen würdest. Ja, wirklich. Mach’ Usability-Untersuchungen. Am Besten mit Leuten, die deine Software noch nicht kennen. Im Laufe der Zeit entwickelt sich einfach eine Betriebsblindheit. Was für den Einen selbstverständlich sein mag, ist für einen Anderen noch Neuland.
Kompatibel
Schreibe deine Software so weit es geht rück- und vorwärtskompatibel. Deine Benutzer werden dich vermutlich hintern den Mond wünschen, wenn sie bei jedem Down- oder Upgrade Konfigurationsdateien nachziehen und eine schwarze Katze opfern müssen, nur damit deine Software laufen will. Auf immer und ewig Altlasten mit zu schleppen ist aber auch nicht besonders elegant. Den Kompriss zwischen “wird sind vollkommen auf- und abwärtskompatibel” und “wir schmeissen Altlasten von Bord” zu finden ist die Kunst.
Finanzierung
Software-Entwicklung kostet Zeit und Geld. Nicht jeder OpenSource-Entwickler hat das Glück und kann Software im Zuge einer Anstellung programmieren. Was aber können Benutzer zurückgeben? Man muß dafür nicht programmieren können. Erzähle z.B. anderen Leuten wie gut dir die Software gefällt, das schmeichelt den Entwicklern. Gute Software zeichnet aus, dass sich mehr Sachen mit ihr realisieren lassen, als auf den ersten Blick scheint. Schreibe deshalb Dokumentation – Anleitungen, Artikel, Tipps und Tricks. Und vielleicht gibt es ja auch eine Wunschliste oder Möglichkeit zum Spenden? Mit dem Geld kann der Entwickeler noch mehr machen (vielleicht bekommst du ja endlich *das* langersehnte Feature implementiert?), neue Hardware und Literatur besorgen, oder auch einfach Sachen wie Hostingkosten für das Projekt bezahlen. Gib zurück was du bekommst!
Weiterführende Literatur
Wer an dieser Stelle noch Literatur zu dem Thema sucht, dem kann ich “Producing Open Source Software – How to Run a Successful Free Software Project” von Karl Fogel schwer ans Herz legen. Das Buch steht unter der Creative Commons Attribution-ShareAlike Lizenz und die 184 Seiten sind wirklich angenehm zu lesen. Vieles davon ist den Meisten vermutlich eh schon bekannt, aber es wird noch einmal ins Bewusstsein gerufen und es sind nette Anekdoten zu finden. :)
Bei der Linuxnacht auf den Chemnitzer Linuxtagen wurde unter anderem die Applikation 
