Software
Doktorarbeit untersucht Release-Management von freier Software
Martin Michlmayr, Debian-Projektleiter 2003 und 2004, untersucht in seiner Doktorarbeit Wege, um mit besserem Release-Management die Qualität freier Software zu verbessern.
Der Österreicher Michlmayr, der an der englischen Universität Cambridge promoviert, ist nach eigenen Angaben dabei, seine Doktorarbeit abzuschließen. Sein Thema sollte die Qualitätsverbesserung von freier Software sein. Da seine anfänglichen Recherchen ergaben, dass das Release-Management ein sehr problematischer Bereich bei vielen Projekten ist, entschied er sich, dafür, sich auf dieses Thema zu konzentrieren.
In der Doktorarbeit untersuchte Michlmayr große und komplexe freie Softwareprojekte, an denen hunderte von Freiwilligen mitarbeiten. Er konzentrierte sich auf Projekte, die ihre Veröffentlichungen anhand eines Zeitplans vornehmen. Daher wird beispielsweise ein Projekt wie KDE in der Arbeit nicht berücksichtigt. KDE folgt immer noch dem Prinzip, eine neue Version zu veröffentlichen, wenn alle geplanten Features implementiert sind.
Im ersten Teil einer Folge von Veröffentlichungen stellt Michlmayr die sieben näher untersuchten Projekte vor: Debian, GCC, GNOME, den Linux-Kernel, OpenOffice.org, Plone und X.org. Er beschreibt die Veröffentlichungspraxis der Projekte und wie sie sich im Laufe der Zeit verändert hat, die Maßnahmen, die getroffen wurden, um Termine einzuhalten, und eventuelle Probleme. In weiteren Artikeln will er weitere Ergebnisse seiner Arbeit vorstellen.
Auffallend ist eine Gemeinsamkeit aller untersuchten Projekte: Alle begannen entweder mit sehr langen oder völlig ungeplanten Release-Zyklen. Dies führte zu Veröffentlichungen, die auf einen Schlag viele neue Features und Änderungen brachten und wenig getestet waren. Die Entwickler und die Anwender waren nicht zufrieden, da neue Features erst nach langer Zeit in offiziellen Versionen erschienen. Die Entwickler bauten kurz vor der Veröffentlichung noch neue Features ein, um nicht einen weiteren Zyklus abwarten zu müssen. Wer auf die Software aufbauen wollte, stand immer vor der Frage, ob er die aktuelle, aber schon leicht veraltete Version oder eine wenig getestete Betaversion einsetzen sollte oder gar auf die nächste offizielle Version warten sollte.
Alle diese Probleme werden mit kürzeren Release-Zyklen umgangen. Hierfür haben die Projekte unterschiedliche Ansätze entwickelt, doch auch hier gibt es Gemeinsamkeiten. So manches Projekt hat aber noch Schwierigkeiten, die Terminpläne einzuhalten. OpenOffice.org hat sich mit einem dreimonatigen Release-Zyklus gar etwas zuviel vorgenommen und diskutiert jetzt, diesen auf sechs Monate zu verlängern.
Am meisten kämpft sicherlich Debian mit dem Terminplan. Obwohl einige Maßnahmen getroffen wurden, konnte der Termin für Debian 4.0 nicht gehalten werden. Als Grund sieht Michlmayr die mangelnde Motivation einiger Entwickler, ihre Aufgaben rechtzeitig zu erledigen. Mit Verzögerungen kämpft auch GCC, was hauptsächlich dem Zeitmangel des Release-Managers zugeschrieben wird. GNOME hingegen hat das Problem mustergültig gelöst, es wird jedoch die Frage aufgeworfen, ob innovative und ambitionierte Änderungen mit einem Release-Zyklus von sechs Monaten vereinbar sind. Kein Problem scheint dies für den Linux-Kernel zu sein, dessen neue Versionen etwa alle drei Monate erscheinen, wobei größere Änderungen oft lange Zeit außerhalb der offiziellen Version entwickelt werden oder in kleinen Happen integriert werden. Die hohe Rate der Innovation kollidiert jedoch mit Stabilitätsforderungen und führt zu einer zu hohen Fehlerzahl in offiziellen Versionen.
Alle Projekte haben augenscheinlich davon profitiert, dass sie die Release-Zyklen planbar machten, dass sich Release-Manager intensiv um die Fertigstellung kümmern und die Projekte geeignet strukturiert und modularisiert wurden.
