Kritik an gängiger Software-Release-Politik

Freie Software ist fertig, wenn sie fertig ist. Oder nicht? Ausgerechnet ein Ex-Debian-Chef behauptet nun, dass Programmieren im Rhythmus eines festen Terminplans besser für Anwender und Entwickler sei.

Es ist nicht lange her, da konnte jeder 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-Managements spezialisiert.

Für seine rund 200-seitige Arbeit, die unter [1] 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 offenbar besser.

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 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.

Freeze-Panik

Was war passiert? Michlmayr verweist auf ein Phänomen, das auch schon Kernel-Größe Theodore T\’so als “Stampede der Patches” beschrieben hat: Verkündet der Release-Manager plötzlich einen unerwarteten Freeze, versuchen alle Entwickler schnell noch ihre Änderungen in den Code einzubringen. Die Entwicklung friert nicht ein, sondern macht einen panischen Sprung.

Das geschah auch bei Debian Sarge, wie Abbildung 1 veranschaulicht. Als 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.

F Abbildung 1: Wird ein Freeze-Termin (grüne Linie) plötzlich und unerwartet verkündet, steigt die Zahl der eingereichten Änderungen (rote Kurve) zunächst sprunghaft an. (Bild: © Martin Michlmayr)

Das Gnome-Projekt machte bei der Vorbereitung zu Version 2.0 der Desktop-Umgebung in den Jahren 2001 und 2002 ganz ähnliche Erfahrungen. Der Gnome-Entwickler Murray Cumming beschrieb die Situation gegenüber Martin Michlmayr: “Die Freezes kamen plötzlich, und wurde – wie bei Debian – 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 musste handeln. Nach der Frustration bei 2.0 waren die Entwickler auch bereit neue Wege zu gehen. Sie entschieden sich für einen etwa halbjährlichen Veröffentlichungsrhythmus. Das überschaubare Gnome-Kernteam beschließt dazu einen rigiden Zeitplan und führt eine Maßnahme namens Reverting ein: Ist ein Feature zur rechten Zeit nicht fertig, kommt dessen Vorversion in die geplante Release.

Seither hat Gnome seinen Plan eingehalten, 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 auf diese Weise auch ein radikaler Versionssprung wie etwa ein Gnome 3.0 realisierbar wäre, lässt sich nicht vorhersagen. Bahnbrechende Neuerungen in einer Release sieht Michlmayr ohnehin als Domäne kommerzieller Software an. Deren Hersteller müssen genügend Neues bieten, um ihre Kunden zu einem Upgrade zu überreden. Zudem ist der Vertrieb als Box-Produkt aufwändiger als ein Update von Download-Mirrors. Freie Software dagegen kann sich an das “Release early, release often” von Eric S. Raymond halten.

Diese Lektion hat auch Open Office gelernt. Zunächst machte die Bürosuite den mit 18 Monaten sehr langen Release-Zyklus ihrer kommerziellen Schwester Star Office mit. Die vielen Änderungen während der langen Entwicklungszeit von Open Office 2.0 und neue Features selbst noch in der Betaphase (sonst hätte man ja nochmals eineinhalb Jahre 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 einem regelmäßigem Zeitplan bringen großen und verteilten Softwareprojekten Vorteile. Nach Michlmayrs Untersuchungen helfen die Regelmäßigkeit und Vorhersehbarkeit von Freezes und Releases den Entwicklern Vertrautheit mit dem Release-Prozess zu gewinnen.

Durch regelmäßige Übung spielen sich die Beteiligten aufeinander ein (siehe auch den Kasten “Gespräch mit Martin Michlmayr”). Ist für das Testen von vornherein 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.

Diskutieren Sie mit!
Wie sind Ihre eigenen Erfahrungen mit Release-Management? Sind Sie anderer Ansicht als Martin Michlmayr? Diskutieren Sie mit anderen Anwendern und Entwicklern unter: [http://www.linux-community.de]

Gespräch mit Martin Michlmayr
Martin Michlmayr stammt aus Innsbruck und war 2003 bis 2005 Debian Project Leader (DPL). Der 27-jä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: Unter anderem testet er neue GCC-Versionen, indem er mit ihnen regelmäßig das komplette Debian-Archiv baut. So findet er Bugs sowohl in GCC als auch in der Software, die Debian ausliefert.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: Software-Entwicklung, Ökonomie, Soziologie, teilweise auch Psychologie. In Irland und Spanien gibt es dazu gute Forschung. In Cambridge findet man zwar viele Leute, die freie Software entwickeln, beispielsweise viele Debianer, aber meine Arbeit ist eher eine Ausnahme. Linux-Magazin: Wie kamst Du auf das Thema? Michlmayr: Mich hat immer schon Qualität interessiert, denn ich bin ein relativ kritischer Mensch. Ich wollte aber nicht die technische Qualität messen, sondern herausfinden, wie man ein Projekt mit tausend Freiwilligen in aller Welt organisiert. Das ist eine Frage, die bisher keine Arbeit so gestellt hat. Die meiste Literatur gibt es über große erfolgreiche Projekte wie den Linux-Kernel, Apache und Samba. Zu Problemen der freien Software gibt es kaum Studien. Ich habe daher ein paar Interviews geführt, um diese Probleme aufzuspüren, und da hat sich Release-Management herauskristallisiert. Danach habe ich eine Vorstudie angestellt, die zeigte, dass in großen Projekten die Koordination das Problem ist. Kleine Projekte haben andere Sorgen, etwa zu wenige Mitarbeiter. Ich habe mir dann einige große Projekte angesehen. Das Time-based Release-Management bei Gnome fand ich wirklich ein interessantes Beispiel. Man sollte annehmen, bei so einem großen Projekt sei Release-Management ein Riesenaufgabe. 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. Es reicht nicht zu sagen, wir machen nun jedes halbe Jahr eine Release. Man muss viele Strukturen ändern, einen Plan machen und Termine setzen. Linux-Magazin: Ist Ubuntu ein Debian plus Time-based Releases? Michlmayr: Ubuntu hat viele andere Eigenschaften. Der Vorteil dieses neuen Projekts ist, dass es aus dem lernen konnte, was bei Debian gut oder schlecht funktioniert hat. Linux-Magazin: Hättest Du über diese Erkenntnisse schon in Deiner Zeit als DPL verfügt, was hättest Du anders gemacht? Michlmayr: Debian geht ja auch in Richtung Time-based Releases mit einem Intervall von 18 Monaten. Das ist auf jeden Fall der richtige Weg. Das ist aber eher Sache der Release-Manager, der DPL kann das nur unterstützen. Das Release-Problem hatten wir schon zu meiner Zeit und mir war klar, dass wir strukturierte Prozesse brauchen. 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 lesenswert.

Gespräch mit Martin
Michlmayr

Martin Michlmayr stammt aus Innsbruck und war 2003 bis 2005 Debian Project Leader (DPL). Der 27-jä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: Unter anderem testet er neue GCC-Versionen, indem er mit ihnen regelmäßig das komplette Debian-Archiv baut. So findet er Bugs sowohl in GCC als auch in der Software, die Debian ausliefert.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: Software-Entwicklung, Ökonomie, Soziologie, teilweise auch Psychologie. In Irland und Spanien gibt es dazu gute Forschung. In Cambridge findet man zwar viele Leute, die freie Software entwickeln, beispielsweise viele Debianer, aber meine Arbeit ist eher eine Ausnahme.

Linux-Magazin: Wie kamst Du auf das Thema?

Michlmayr: Mich hat immer schon Qualität interessiert, denn ich bin ein relativ kritischer Mensch. Ich wollte aber nicht die technische Qualität messen, sondern herausfinden, wie man ein Projekt mit tausend Freiwilligen in aller Welt organisiert. Das ist eine Frage, die bisher keine Arbeit so gestellt hat.

Die meiste Literatur gibt es über große erfolgreiche Projekte wie den Linux-Kernel, Apache und Samba. Zu Problemen der freien Software gibt es kaum Studien. Ich habe daher ein paar Interviews geführt, um diese Probleme aufzuspüren, und da hat sich Release-Management herauskristallisiert. Danach habe ich eine Vorstudie angestellt, die zeigte, dass in großen Projekten die Koordination das Problem ist. Kleine Projekte haben andere Sorgen, etwa zu wenige Mitarbeiter.

Ich habe mir dann einige große Projekte angesehen. Das Time-based Release-Management bei Gnome fand ich wirklich ein interessantes Beispiel. Man sollte annehmen, bei so einem großen Projekt sei Release-Management ein Riesenaufgabe. 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. Es reicht nicht zu sagen, wir machen nun jedes halbe Jahr eine Release. Man muss viele Strukturen ändern, einen Plan machen und Termine setzen.

Linux-Magazin: Ist Ubuntu ein Debian plus Time-based Releases?

Michlmayr: Ubuntu hat viele andere Eigenschaften. Der Vorteil dieses neuen Projekts ist, dass es aus dem lernen konnte, was bei Debian gut oder schlecht funktioniert hat.

Linux-Magazin: Hättest Du über diese Erkenntnisse schon in Deiner Zeit als DPL verfügt, was hättest Du anders gemacht?

Michlmayr: Debian geht ja auch in Richtung Time-based Releases mit einem Intervall von 18 Monaten. Das ist auf jeden Fall der richtige Weg. Das ist aber eher Sache der Release-Manager, der DPL kann das nur unterstützen. Das Release-Problem hatten wir schon zu meiner Zeit und mir war klar, dass wir strukturierte Prozesse brauchen.

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 lesenswert.

Infos
[1] Martin Michlmayr, “Quality Improvement in Volunteer Software Projects”; Dissertation Cambridge 2007: [http://www.cyrius.com/publications/michlmayr-phd.pdf]]