Aaron Fischer Ingenieur, Vater, Heimwerker, Problemlöser

23 Dezember, 2009

Tag 24: Ausblick, wie gehts weiter?

TL;DR:

Geschafft! Wir haben ein kleines Spiel von Anfang bis zum Ende begleitet. Wirklich bis zum Ende? Das ist jetzt die Frage. Gibt es ein Ende bei einem Open Source Projekt? Wann hört man auf mit Entwickeln? Was passiert, wenn der Hauptentwickler die Lust verliert? Haben wir etwas vergessen? Das werden wir jetzt klären.

Was passiert eigentlich, wenn wir ein Projekt für fertig erklären? Ein paar User laden sich die Software oder das Spiel herunter, benutzen es einige Zeit und wenn sie es für gut empfinden, empfehlen sie es weiter. Das Programm verbreitet sich. Und mit zunehmender Verbreitung steigt auch die Anzahl der Testkandidaten, die das Programm nutzen und testen. Jetzt liegt es in der Macht der User, ob das Projekt groß und berühmt wird oder nicht. Wenn es viele verwenden, tauchen zwangsläufig auch viele Fehler und Wüsche an das Programm auf. Fließen diese Fehler und Wünsche zurück an den/die Entwickler, können sie sich dem Problem annehmen und das Feature einbauen bzw. den Fehler fixen. Fließt kein Feedback zurück, bleibt die Software Fehlerbehaftet und schlecht getestet. Und ohne Feedback verliert auch der Programmierer die Lust daran.

Wie fängt man nun Fehler und Wünsche von den Benutzern ein? Die verbreitetste Lösung ist ein Bug- oder Issue-Tracker wie Mantis oder Bugzilla. Auch Github legt für jedes Projekt einen Issue-Tracker an. Hiermit lassen sich Fehler und Wünsche direkt über den Browser melden. Meist werden die Meldungen dankend angenommen, ein Paradebeispiel ist Ubuntu. Hier werden alle Fehlerberichte sehr ernst genommen und mit akribischer Genauigkeit bearbeitet, auch wenn die Bearbeitung etwas langsam ist.

Merken wir uns also: Wenn ein Open Source Projekt einen Fehler erzeugt, der so nicht vorkommen darf, dann freut sich der Autor sehr darüber, davon zu hören. Bug-Reports sind ein wichtiges Feature von Open Source das man nutzen sollte!

Was passiert aber jetzt, wenn das Projekt keine wirkliche Verbreitung erhält oder der Hauptentwickler aus irgend welchen Gründen aufhört an der Software zu arbeiten? Ist dies schlimm? Meistens leider ja, denn eine Software, die nicht in Bewegung ist, erhält meist auch keine wichtigen Bug Fixes mehr und stirbt somit. Es ist also wichtig, ein Open Source Projekt kontinuierlich zu betreuen und weiter zu entwickeln. Ist dies nicht der Fall, stirbt meist das Projekt.

Fühlt sich allerdings ein User so verbunden mit der Software, dass er beschließt das Projekt weiterzuführen, kann er dies natürlich tun. Man nennt dies auch forken. Man nimmt sich den letzten Stand der Software, überführt es in ein neues Repository und nennt es ein bisschen anders, meist wird ein -ng (Next Generation) hinten angehängt. Dies ist allerdings die letzte Rettung für ein Projekt. Besser ist es natürlich, wenn der Hauptentwickler die Leitung einer anderen Person überträgt, die dann das Projekt weiter trägt. Dies kommt glücklicherweise auch oft vor. Ziel ist es also, das Projekt in ständiger Bewegung zu halten, nie die Lust daran zu verlieren und auch Durststrecken durchzustehen.

Schwer ist dies natürlich dann, wenn jemand anders auf die gleiche Idee gekommen ist und eine ähnliche Software programmiert hat und schon weiter ist. Wenn zudem seine Software besser und verbreiteter ist, passiert es schnell, dass die eigene Software hierbei vom großen Riesen verschluckt wird. An solchen Stellen kann man sich die Frage stellen: Weitermachen oder aufhören? Eine dritte Option wäre auch, sein eigenes Wissen und vielleicht sogar Teile des Programmcodes in das andere Open Source Projekt zu übertragen und ein noch besseres Programm zu schaffen.

Allerdings ist hier auch wieder Vorsicht geboten: Zu viele Köche verderben den Brei. Jeder hat seine eigenen Vorstellungen, wie etwas umzusetzen ist und man muss innerhalb des Projekts eine gemeinsame Lösung finden. Leider passiert es häufig, dass dann beide Ziele verfolgt werden und am Ende eine Software mit 457 Einstellmöglichkeiten, 5 Oberflächen in 2 verschiedenen Programmiersprachen programmiert wird, mit der sich dann keiner mehr gerne beschäftigt. Sendmail ist (abgesehen von der sicherheitskritischen Architektur) ein gutes negativ Beispiel dafür.

Es gibt so viel zu beachten und man möchte es möglichst jedem Recht machen, doch leider ist dies nicht immer möglich. Im Endeffekt sollte man auf sich hören und das Umsetzen, was man selbst für richtig hält. Denn im Endeffekt ist die treibende Kraft die eigene Freude am Programmieren.

Damit möchte ich nun den Adventskalender und somit auch die Open Source Artikelreihe beenden. Doch aber nicht dieses Projekt, das zwischen den Artikeln entstanden ist. Wer also Lust hat, in den kommenden Feiertagen etwas zum Projekt beizutragen, kann dies gerne tun, ich würde mich sehr darüber freuen. Ein herzliches Dankeschön geht an Florian Eitel, der jede Nacht den Adventskalender neu gemalt hat und mit seiner Vorstellung der CLI-Tools eine perfekte Ergänzung zu meinen Beiträgen geliefert hat!

Am Ende würde mich jetzt eure Meinung interessieren. Wie fandet ihr die Reihe? Unter welchen Voraussetzungen würdet ihr mitmachen? Bitte, bitte nehmt an der Umfrage teil! Ich würde mich sehr über ein Feedback freuen.

Ich wünsche allen ein schönes Weihnachtsfest, ein paar erholsame Tage und viel Erfolg im neuen Jahr! Danke fürs Lesen!