Die Woche: +1 für schnelle Veröffentlichungen
Firefox zeigt seit zwei Jahren: Die Freigabe neuer Versionen in einem schnellen Rhythmus hat viele Vorteile und geht nicht zu Lasten der Qualität. Damit kann es als Vorlage für andere Projekte dienen – etwa KDE.
- Thorsten Leemhuis
Der Linux-Kernel, Chrome und Firefox zeigen seit einer Weile: In schneller Folge neue Versionen zu veröffentlichen funktioniert wunderbar. Anwender kommen so zügig an Fehlerkorrekturen und erhalten neue Funktionen nach und nach in kleinen Dosen, die auch Entwickler besser managen können. Das KDE-Projekt wäre daher meines Erachtens gut beraten, wie vorgeschlagen nicht mehr jedes halbe Jahr, sondern doppelt so schnell oder gar schneller neue Versionen zu veröffentlichen.
Größeren Einspruch gegen den bislang weitgehend konstruktiv diskutierten Vorschlag gab es von den Betreuern der KDE-Pakete von OpenSuse: Der schnellere Zyklus würde mehr Arbeit machen und die Qualität verschlechtern. Daran ist aber vor allem die Herangehensweise der OpenSuse-Entwickler schuld, denn das einer OpenSuse-Version beiliegende KDE bleibt auf seinem jeweiligen Stand und erhält nur kleinere Updates; neue Versionen mit größeren Überarbeitungen können Anwender über optionale Paketdepots erhalten. Das vor zehn Monaten freigegebene OpenSuse 12.2 setzt daher auch heute noch auf KDE 4.8; wechselwillige Anwender finden ein Add-on-Depot mit dem aktuellen KDE 4.10 beim OpenSuse Build Service.
Mit diesem Modell verkomplizieren sich die OpenSuse-Entwickler das Leben nicht nur selbst, sie machen es auch den KDE-Entwicklern und Anwendern schwerer. Das zeigt der Rückblick auf Firefox, denn da war es ähnlich, bis die Entwickler trotz viel Argwohn und Kritik vor zwei Jahren auf einen "Rapid Release Process" umgestiegen sind. Daher gibt es jetzt alle sechs Wochen eine frische Firefox-Ausführung: Entweder die der Haupt-Entwicklungslinie (derzeit Firefox 22), die Fehlerkorrekturen und neue Funktionen bringt, oder ein einmal im Jahr daraus hervorgehendes Extended Support Release (ESR) (derzeit Firefox 17.0.7esr), das ein Jahr gepflegt wird und sich daher kaum ändert, weil es nur Fehlerkorrekturen und kleinere Anpassungen erhält.
Distributionen wie Fedora, OpenSuse und Ubuntu setzen vornehmlich auf den Firefox der Hauptlinie, Unternehmensdistributionen wie Debian oder RHEL eher auf die ESR-Ausführung. Firefox-Entwickler erhalten daher nicht mehr direkt oder indirekt Fehlerberichte für zahlreiche, häufig hoffnungslos veraltete Versionsreihen, die Linux-Distributoren irgendwann beigelegt haben; stattdessen sind es vornehmlich Bug-Reports für die zwei Entwicklungslinien, die tatsächlich noch gewartet werden. Bei der Wartung und Fehlerbeseitigung können die Entwickler von Distributionen und Firefox daher jetzt besser zusammenarbeiten.
Auch die Entwickler von Firefox-naher Software haben sich nach Rumpeln im Gebälk auf den schnellen Release-Zyklus eingestellt: Gute Extension-Autoren wissen einfach, dass alle sechs Wochen eine neue Version erscheint und passen ihre Erweiterungen rechtzeitig an. Das klappt nicht immer, aber besser als früher, wo es selbst bei populären Erweiterungen immer mal wieder Wochen oder Monate dauerte, bis diese mit den ersten Ausgaben von Firefox 3.0, 3.5 oder 3.6 zusammenarbeiteten.
Die Firefox-Entwickler sind zudem viel näher an den Anwendern: Wenn sie einen Fehler korrigieren, landet die Fehlerkorrektur schon nach wenigen Wochen bei den betroffenen Anwendern – und nicht wie früher erst mit der nächsten Version einer Linux-Distribution, die Monate oder Jahre später ein neues Firefox-Release mitbringt. Neue Funktionen kommen zudem schneller und in kleinen Happen zu den Anwendern. Ein wichtiger Aspekt, um heute konkurrenzfähig zu bleiben und Anwendern zeitnah zu liefern, wonach sie verlangen. Über das Internet leicht nachreichbare Fehlerkorrekturen und Quellcodeverwaltungssysteme wie Git ermöglichen dabei ein Entwicklungsmodell, bei dem die Qualität nicht leidet – oft ist es sogar besser als bei einem klassischen Entwicklungsmodell aus den Zeiten, in denen Software vorwiegend in Schachteln verkauft wurde.
Mit KDE könnte das ähnlich gut laufen wie bei Firefox – eine Desktop-Umgebung ist zwar komplexer, doch Rolling-Release-Distributionen machen vor, dass solche Updates funktionieren. Auch bei Fedora sind umfangreichere KDE-Updates über die gewöhnlichen Aktualisierungen längst normal; das mit KDE 4.8 ausgelieferte Fedora 17 hat daher erst Version 4.9 und später 4.10 nachgereicht bekommen, ohne dass es größere Probleme gab.
Revolutionäre Änderungen, wie sie KDE 4.0 gebracht hat, sollten natürlich nicht von heute auf morgen als Update an die Anwender gehen – da ist ein klassischer Ansatz gefragt. Ähnlich wie bei Firefox sind die Unterschiede zwischen einem KDE 4.9 und dessen Nachfolger 4.10 aber normalerweise nicht so groß, dass ein durchschnittlicher Anwender nicht schnell damit klar käme; dasselbe gilt für Gnome und die meisten anderen Anwendungen. Anders als vor zehn oder fünfzehn Jahren müssen sich Computer-Nutzer ohnehin darauf einstellen, dass sich die Umgebungsbedingungen mit der Zeit ein klein wenig ändern. Anderswo ist das normal, auch bei Apps für Smartphones und Tablets hat man meist keine andere Wahl – und bei Webseiten so gut wie nie. (thl) (thl)
