Abbildung 1: Statt der eigenen Roadmap zu folgen, verkündete das Joomla-Projekt Release 1.0.13.
Wie fährt man ein Open-Source-Projekt möglichst gekonnt an die Wand? Man missachtet Grundregeln und legt sich selbst Steine in den Weg. Wie das in der Praxis funktioniert, zeigt das Joomla-Projekt.
|
Inhalt |
|---|
|
110 | Sun Studio unter Linux Die Netbeans-basierte IDE bringt eigene Compiler mit, die sich im Test gegen GCC bewähren müssen. 116 | Perl-Snapshot Ein Skript mailt täglich frische Tipps und Vokabeln an lernwillige User. |
Schon die Geburt des Joomla-CMS geschah 2005 unter heftigen Wehen: Nach Differenzen mit dem Markeninhaber des Mambo-CMS verließen die meisten Entwickler das bis dato erfolgreiche Projekt. Im Handgepäck nahmen sie dessen GPL-Quellcode mit. Darin änderten sie flugs den Namen auf “Joomla”, korrigierten ein paar Fehler und präsentierten das Ergebnis unter lautem Korkenknallen. In Rekordzeit wurde Joomla zu einem der beliebtesten Contentmanagement-Systeme – und ließ Mambo zurück.
Kurze Zeit später präsentierten die Entwickler eine respektable Roadmap. Demnach sollte bereits Anfang 2006 Version 1.1 erscheinen mit Verbesserungen bei Übersetzungen und der Textkodierung. Im dritten Quartal wollten sie eine ausgefeilte Benutzerverwaltung implementieren und erste Änderungen am Framework in Angriff nehmen. Für 2007 war Version 1.3 angekündigt, bevor noch im gleichen Jahr mit der Fassung 2.0 ein von Grund auf neu entwickelter Nachfolger die Nutzer erfreuen sollte.
Der ehrgeizige Plan geriet durcheinander, als die Entwickler anfingen, an Joomlas Fundamenten zu schrauben. So stellten sie immer mehr Teile des CMS auf Model-View-Controller um. Das sollte eine Investition in die Zukunft sein. Die Änderungen waren mittlerweile so umfangreich, dass man sich entschloss gleich mehrere Zwischenstufen zu überspringen. Schon war Joomla 1.5 gezeugt, der Geburtstermin der ersten Beta verschob sich jedoch immer weiter.
Die Anwender waren verunsichert: Sollten sie noch die veraltete Version einsetzen oder auf die bevorstehende Beta warten? Deren Veröffentlichungstermine platzten immer wieder. Hinzu kamen Gerüchte über einen Streit im Team, der die Einstellung des Projekts zur Folge hätte. Erst im Oktober 2006 erschien die erste Betaversion. Doch zu früh gefreut: Sie entpuppte sich bestenfalls als frühe Alpha. Einige Funktionen fehlten, waren unerwartet verändert oder voller Fehler. Dennoch versprach die Entwicklermannschaft schon vier Wochen später die Beta 2 zu präsentieren.
Schwere Altlasten
Ein Teil der Joomla-Entwickler war noch damit beschäftigt, Sicherheitslöcher der Vorversion zu stopfen. Erst als Joomla 1.0.12 fertiggestellt war, begannen alle das bis dahin dreiköpfige Joomla-1.5-Team zu unterstützen. Das Tempo stieg dennoch nur unmerklich. So kam es vor, dass schon korrigierte Fehler plötzlich wieder auftauchten – konsequente Qualitätssicherung sieht anders aus. Die Beta 2 verzögerte sich schließlich bis ins Jahr 2007 und war dennoch nur auf dem Stand einer fortgeschrittenen Alpha.
Im Frühjahr 2007 beschloss das Team dann, das Versionskontrollsystem auszutauschen, das unter anderem den Quellcode verwaltet. Jetzt schlug Murphys Law zu und ließ das ganze System zusammenbrechen. Das kostete die Entwickler weitere zwei Wochen.
Als am 22. Juli 2007 endlich der Release Candidate 1 erschien, gaben ihm die Entwickler das Etikett “Für den produktiven Einsatz”. Dies trifft jedoch bestenfalls auf das API des neuen Framework zu, das sich bis zur finalen Version nicht mehr ändern soll. Die Software selbst ist noch nicht ausreichend reif.
Abbildung 1: Statt der eigenen Roadmap zu folgen, verkündete das Joomla-Projekt Release 1.0.13.
Prinzipienfrage
Die Joomla-Entwickler haben ein wesentliches Open-Source-Prinzip missachtet: “Veröffentliche früh und häufig.” Statt kleine Schritte zu gehen, stellten sie eine ehrgeizige Roadmap auf und krempelten auf einen Schlag den gesamten Unterbau um. Immer mehr der geplanten Ziele zogen sie vor und machten damit die alte Roadmap überflüssig. Der Release Candidate der Version 1.5 kann dennoch kaum mehr als die ursprünglich geplante Version 1.1.
Tödlich war der unnötige Tausch des Forge-Servers. Wie jeder Informatik-Student weiß, sollte man in der Schlussphase eines Projekts von einem Tausch der Werkzeuge absehen. (ofr/fjl)
