Freie Software ist fertig, wenn sie fertig ist, oder doch nicht? Ausgerechnet ein Ex-Debian-Chef behauptet nun, dass Programmieren im Rhythmus eines festen Terminplans besser für Anwender und Entwickler sei.
Es ist nur wenige Jahre her, da konnte man auf den Webseiten des Debian-Projekts folgendes lesen: “Wie üblich werden die Release-Ziele und das Release-Datum nicht im Vorhinein bestimmt. Um es einfach zu sagen, Debian veröffentlicht, wenn die Zeit gekommen ist.”
Im Jahr 2007 ist diese flapsige Bemerkung kein guter Wahlspruch mehr für qualitätsbewusste Softwareprojekte. Das ist zumindest die These der Dissertation von Martin Michlmayr, ehemals Debian Project Leader, und nun Doktorand an der Universität Cambridge. In seiner Forschung zur Qualitätsverbesserung in freien Softwareprojekten hat er sich auf den Einfluss des Release Management spezialisiert.
Für seine rund 200-seitige Arbeit, die als PDF zum Download bereitsteht, hat Michlmayr Mailinglisten gelesen, Bug- und Commit-Statistiken ausgewertet und Interviews mit Mitarbeitern zahlreicher Open-Source-Projekte geführt. Sein Fazit: Release-Pläne, die sich an Programm-Features orientieren (Feature-based Releases) sorgen für Frust bei Entwicklern und Anwendern, Zeitgesteuerte (time-based) Release-Planung dagegen bekommt allen Beteiligten besser.
Freeze-Panik
Als Beispiel zitiert er unter anderem die Geschichte von Debian 3.1., Codename Sarge: Hier führte das Motto “release when it’s ready” dazu, dass sich die ursprünglich für Ende 2003 erwartete Veröffentlichung sich bis Juni 2005 verzögerte. Das sorgte für frustrierte Entwickler, die Ihre Pakete nicht in absehbarer Zeit an den Mann brachten und für verärgerte Benutzer, die bei Lieferung bereits veraltete Software erhielten.
Was war passiert? Michlmayr verweist unter anderem auf ein Phänomen, dass auch schon Kernel-Größe Theodore T’so als “Stampede der Patches” beschrieben hat: Verkündet der Release-Manager plötztlich und unerwartet einen Freeze, versuchen alle Entwickler, schnell noch ihre Änderungen in den Code einzubringen. Die Entwicklung friert nicht ein, sondern explodiert geradezu. Das geschah auch bei Debian Sarge. In Folge dauert es lange, bis die neu eingereichten Änderungen getestet sind, die Eile sorgt zudem für schlechteren Code. Daher tauchen immer wieder unerwartete Bugs auf, die die Release blockieren. So kam es, dass sich Debian Sarge über ein Jahr lang im Freeze-Stadium befand.
Das Gnome-Projekt machte bei der Vorbereitung zu Version 2.0 der Desktop-Umgebung in den Jahren 2001 und 2002 ähnliche Erfahrungen. Der Gnome-Entwickler Murray Cumming beschrieb die Situation gegenüber Martin Michlmayr: “Die Freezes kamen plötzlich, und — wie bei Debian — wurde erst ein Freeze versprochen, dann kam sechs Monate lang doch keiner. Man arbeitet also ein halbes Jahr lang richtig hart für einen Termin, der sich ständig weiter in die Zukunft entfernt”.
Ein Terminplan muss her
Gnome musst handeln. Nach der Frustration bei 2.0 waren die Entwickler auch bereit, neue Wege zu gehen. Man entschied sich für einen etwa halbjährlichen Veröffentlichungsrhythmus. Das überschaubare Gnome-Kernteam beschließt dazu einen rigiden Zeitplan. Dazu wurde eine Maßnahme namens Reverting eingeführt: Ist ein Feature zur rechten Zeit nicht fertig, kommt dessen Vorversion in das Release.
Seither hat Gnome seinen Plan eiungehalten, wenn auch anfangs mit geringen Abweichungen. Distributoren schätzen die Termintreue, und Ubuntu hat sich gar dem Rhythmus angeschlossen. Allerdings handelt es sich bei den erfolgreichen Releases um inkrementelle Änderungen der Desktop-Umgebung. Ob sich auf diese Weise auch ein radikaler Versionssprung wie etwa ein Gnome 3.0 realisieren ließe, lässt sich nicht vorhersagen.
Bahnbrechende Neuerungen in einer Release beschreibt Michlmayr in seiner Arbeit aber ohnehin als Domäne kommerzieller Software: Deren Hersteller müssen genügend Neues bieten, um ihre Kunden zum Upgrade zu überreden. Zudem ist der Vertrieb als Box-Produkt aufwändiger als ein Update von Download-Mirrors. Freie Software kann sich dagegen an das “Release early, release often”, von Eric S. Raymond halten.
Das hat auch Open Office gemerkt. Bis vor kurzem machte die freie Bürosuite den langen Release-Zyklus ihrer kommerziellen Schwester Star Office von 18 Monaten mit. Die vielen Änderungen während der langen Entwicklungszeit von Open Office 2.0 und Änderungen selbst noch in der Betaphase (sonst hätte man ja nochmals eineinhalb Jahre auf das Feature warten müssen) führten zu großer Verspätung. Einige Linux-Distributionen hatten das freie Büropaket jedoch schon eingeplant und packten eine Beta in ihre Pakete, die sie selbst notdürftig flickten.
Danach wechselte des Projekt zu einem Rhythmus von drei Monaten und hält ihn seither in der Regel ein. Derzeit ist allerdings ein Umstieg auf einen Zyklus von sechs Monaten in der Diskussion, um mehr Zeit für Qualitätssicherung zu haben. Zudem sind nicht alle Anwender erfreut über derart häufige Updates.
Auch wenn die Wahl der richtigen Frist nicht einfach sein mag: Releases nach regelmäßigem Zeitplan bringen hauptsächlich großen und verteilten Softwareprojekten entscheidene Vorteile: Die Regelmäßigkeit und Vorhersehbarkeit von Freezes und Releases hilft den Entwicklern, Vertrautheit mit Release-Prozess zu entwickeln. Durch regelmäßige Übung spielen sich die Beteiligten aufeinander ein (siehe auch das folgende Gespräch mit Martin Michlmayr). Ist für das Testen von vorneherein ausreichend Zeit eingeplant, steigt zudem die Qualität des Produkts. Schließlich profitiert laut Martin Michlmayr auch die Motivation eines Entwicklers, wenn er weiß, dass seine Arbeit bald Anwender findet und er rasch Feedback erhält.
Interview mit Martin Michlmayr
Martin Michlmayr stammt aus Innsbruck und war 2003 bis 2005 Debian Project Leader. Der 27jährige Tiroler hat in seiner Heimatstadt und in Cambridge studiert und darf ab Juli den Titel Ph.D. führen. Er ist immer noch bei dem freien Projekt aktiv, er betreut beispielsweise den Debian-Kernel von NSLU2-Linux, einem Image für ein NAS-Gerät von Linksys. Daneben arbeitet er in der Debian-Qualitätssicherung: Er testet neue GCC-Versionen, indem er mit ihnen regelmäßig das komplette Debian-Archiv auf möglichst vielen Architekturen baut. So findet er sowohl Bugs in GCC als auch in der Software, die Debian mitliefert. Das Linux-Magazin unterhielt sich mit Martin am Rande des Linuxtags 2007.
Linux-Magazin: Wo findet man einen Doktorvater für eine Arbeit über freie Software?
Martin Michlmayr: Es gibt mittlerweile einige Unis, die sich mit dem Thema beschäftigen. Es berührt zahlreiche Gebiete: Softwareentwicklung, Ökonomie, Soziologie, teilweise auch Psychologie. In Irland und Spanien gibt es da gute Forschung. In Cambridge gibt es zwar viele Leute die freie Software entwickeln, beispielsweise viele Debianer, aber meine Arbeit ist eher eine Ausnahme.
Linux-Magazin: Wie kamst Du auf Dein Thema?
Martin Michlmayr: Mich hat immer schon Qualität interessiert. Ich bin ein relativ kritischer Mensch: Wo andere sagen, es funktioniert alles super, sehe ich eher die Seiten, die man noch verbessern kann.
Auch bei Debian habe ich viel für Qualitätssicherung gemach., Das ist eben das Thema, das mich interessiert. Es ist allerdings schwierig, Qualität zu messen, auch wenn es dazu interesante Projekte gibt wie FLOSSMetrics und QualOSS.
Ich wollte aber nicht den technischen Weg gehen, sondern ich wollte herausfinden, wie man ein Projekt mit tausend Freiwilligen in aller Welt organisiert. Das ist eine Frage, die bisher keine Arbeit so gestellt hat. Ich habe meine Erfahrung mit Debian eingebracht, wo man ständig auf Probleme mit der Koordination stößt.
Die meiste Literatur gibt es über große, erfolgreiche Projekte wie den Linux-Kernel, Apache, Samba. Zu Problemen mit der freien Software gibt es kaum Studien. Daher habe ich ein paar Interviews gemacht, um diese Probleme aufzuspüren, und da hat sich Release Management herauskristallisiert. Danach habe ich eine Vorstudie zu diesem Aspekt gemacht, die zeigte, dass Koordination in großen Projekten ein Problem ist. Kleine Projekte haben andere Sorgen, etwa zu wenig Mitarbeiter.
Ich habe mir dann einige große Projekte angesehen, und das Time-based Release-Management bei Gnome fand ich wirklich ein interessantes Beispiel. Man würde annehmen, bei so einem großen Projekt sei Release Management ein große Aufgabe. Aber die sagten, ,,Nein, wir tun da relativ wenig — wir publizieren die Schedule, irgendwann macht man die Tarballs und das Announcement. Das funktioniert wie eine Maschine.“ Sie haben diesen Prozess sehr gut implementiert.
Ich habe untersucht wie und warum Time-based Release Management funktioniert und wie man es umsetzen kann: Es reicht nicht zu sagen, wir machen nun jedes halbe Jahr ein Release. Man muss viele Strukturen ändern, einen Plan machen und Termine setzen.
Linux-Magazin: Ist Ubuntu ein Debian plus Time-based Releases?
Martin Michlmayr: Ubuntu hat viele andere Eigenschaften. Der Vorteil dieses neuen Projekts ist, dass sie aus dem lernen konnten, was bei Debian gut oder schlecht funktioniert hat. Ubuntu konnte seine Strukturen von Grund auf neu gestalten. Debian ist ein altes Projekt, das sich mit Veränderungen viel schwerer tut. Man wird aber auch sehen, wie das bei Ubuntu in fünf oder zehn Jahren aussieht.
Linux-Magazin: Hättest Du Deine Erkenntnisse schon als DPL gekannt, was hättest Du anders gemacht?
Martin Michlmayr: Naja, Debian geht ja auch in Richtung Time-based Releases mit einem Intervall von 18 Monaten. Das ist auf jeden Fall die richtige Richtung. Allerdings ist das eher die Sache der Release Manager, der DPL kann das nur unterstützen. Das Release-Problem hatten wir schon zu meiner Zeit, und mir war kalr dass man strukturierte Prozesse braucht.
Ich weiß nicht, ob ich etwas anders gemacht hätte. Aber jetzt gibt es immerhin die Dissertation, die auch praktische Aspekte behandelt, darum ist sie für Release Manager auf jeden Fall lesenswert.
Ich glaube auch, dass viele Erkenntnisse meiner Arbeit auch für Firmen interessant sind. Auf einer Vortragstour neulich haben mich viele Mitarbeiter von Softwarefirmen angesprochen, die ähnliche Probleme haben. Manche machen sogar intern so eine Art Time-based Releases alle vier Wochen.
