Die Flinke Feder

Das Apache-Release: Verspätetes Geschenk

Bernd Fondermann

Manchmal schaut man sich das Treiben eines Open-Source-Projekts an, und alles scheint gut zu sein. Es wuselt und wieselt auf den Mailinglisten, Fragen werden gestellt und sogar hilfreich beantwortet. Es werden Bug-Reports aufgemacht, kommentiert und die zugehörigen Unzulänglichkeiten in den Sources gefixt. Ein steter Strom von Commits läuft ins Code-Repository. Hier und da wird ein Eckchen ausgebessert oder ein Featurechen angebaut. Es scheint alles zu passen.

Und doch, und doch fehlt dem Open-Source-Konsumenten etwas. Erst weiß man vielleicht gar nicht genau was es ist; man fühlt sich wie ein Kind, das ein ganzes Jahr mit großen Augen den Spielzeugkatalog durchblättert – und am Ende fällt Weihnachten aus. Es fehlt etwas, was einem übergeben wird, was man mit roten Wangen auspacken und dann, die übrige Welt vergessend, selber ausprobiert: Das Release! Jene gepackte Datei, je nach Wunschzettel als Zip oder Tar, mit dem kleinen README-Zettelchen mit den lieben Worten der Entwickler drin und allem, was neu und glänzend ist, in CHANGES.TXT. Mitunter endet die Leidenschaft schnell im Frust und die vermeintliche Kostbarkeit landet kaputt in der Ecke. Wenn sie überhaupt jemals ein Bit von sich gegeben hat. Aber ohne Release fehlt uns was.

Leider ist die Releasedisziplin vieler Apache-Projekte, sagen wir, undurchsichtig. Neidisch schiele ich dann rüber zu den Kollegen von Eclipse, Ubuntu und Debian, die feste Releasetermine haben, an denen alle Teilprojekte zu einem einzigen riesigen Produktrelease zusammengefasst werden, und das zudem noch einen beeindruckenden Namen hat: am besten einen Jupitermond oder eine lustige Alliteration wie „Frying Flamingo“.

Es ist nun mal wie es ist, das Apache-Ökosystem aus knapp hundert sehr unterschiedlichen und gegensätzlichen Projekten und noch viel mehr releasten Produkten lässt sich nicht in ein einheitliches Schema zwingen. Das liegt auch daran, dass die Projekte extrem autonom agieren. Es gibt kein zentrales Gremium, das solch ein Über-Release planen und koordinieren könnte. Der Overhead der Foundation ist winzig.

Die eigene Subkultur jedes Projekts findet auch in den Releases ihren Niederschlag, nämlich darin, wie viele Versionszweige parallel gepflegt werden. Auch, wie regelmäßig neue Software an die User gegeben wird, um schon frühzeitig Feedback zu bekommen, ist unterschiedlich. Manche Projekte veröffentlichen Milestone Releases, andere nur den Golden Code. Tomcat releast erstmal und erklärt dann im Nachhinein die neueste Version für stabil oder nicht. Was regelmäßig Fragezeichen erzeugt, ist die Ungewissheit, wann und ob das nächste Release überhaupt kommt. Und oftmals ist es genau das Projekt ganz oben auf dem eigenen Wunschzettel, das seit Monaten partout kein neues Päckchen schnüren will und weiter und weiter entwickelt, als ob es kein Morgen gäbe.

Doch nehmen wir an, die Entwickler würden sich tatsächlich dazu durchringen, eine neue Version in Angriff zu nehmen. Wie funktioniert das Releasen bei Apache eigentlich?

Das jeweilige Project Management Committee (PMC) eines Projekts ist für die Ratifizierung eines Release-Kandidaten verantwortlich – und das gilt Apache-weit. Erst durch eine Abstimmung, in der nur die Stimmen der PMC-Mitglieder zählen, wird der Sourcecode, zusammengefasst in einem Archiv-File oder gekennzeichnet durch eine Revisionsnummer in Subversion, auch zu einem offiziellen Release. Die Binärdistributionen, die oftmals mitkommen, sind nur die Zugabe – im Kern geht es um den Source-Code. Es wird gerne gesehen, wenn interessierte Nicht-PMC-Mitglieder ihre Stimme abgeben, diese werden als nicht bindend (non-binding) gekennzeichnet.

Was viele Nutzer von Apache Software gar nicht wissen und vielleicht auch nicht wissen wollen: Ein Apache-Release unterscheidet sich ganz wesentlich von Software, die auf Sourceforge oder Github veröffentlicht wurde:

  • Alle Source-Dateien müssen den Apache Header tragen
  • Code lässt sich auf seinen Urheber zurückverfolgen
  • Alle mitgelieferten Libraries sind kompatibel zur Apache Lizenz
  • Das Release enthält die Lizenz an prominenter Stelle sowie weitere Lizenzinfos

Kurz: Jedes Release ist durch einen Veröffentlichungsprozess mit einem Haufen Regeln gelaufen. Diese strengen Regeln [1] sollen zwei Gruppen rechtlichen Schutz geben: den Nutzern und den Entwicklern von Apache-Projekten. Dieser Schutz war letztendlich der eigentliche Grund, den rechtlichen Rahmen einer amerikanischen Foundation zu wählen. Er bedeutet für die Entwickler einen wesentlich höheren Aufwand als Software „einfach online zu stellen“. Doch es macht sich spätestens im Fall eines Rechtstreits bezahlt – selbst wenn es für Entwickler wirklich nervig ist, eine endlich fertiggestellte Software nochmals anzufassen und auf releasemäßig „rund“ zu machen. „Release“ sagt nichts über die Reife und Güte des Codes aus, sondern nur, dass die veröffentlichte Software durch diesen Prozess gelaufen ist. Auch veröffentlichte Betas und Milestones müssen so geprüft sein, für Nightly Builds oder beliebige Zustände im Source-Repository gilt das nicht. Damit wir auch beim nächsten Mal wieder ein neues Päckchen zum Auspacken und Ausprobieren haben.

Ausgewählte Releases aus dem Jahre 2010

Apache-Projekt Letztes Release Neuerungen
Tomcat 7.0 und neuer Servlet-3.0-konform, bessere Einbettbarkeit
Ant 1.8.0 und neuer Viele Bugfixes und Verbesserungen
Maven „3.0“ Neuer Unterbau
JAMES „3.0.0“ M1 Umbau der Architektur
MINA „2.0.0“ und neuer Refaktorisiertes API
CouchDB „1.0.0“ und neuer Erstes uneingeschränkt produktionsreifes Release
Geronimo 3.0M1 Java EE 6 Web Profile Support, OSGi Support
Commons Lang 3.0-beta Umstieg auf Java 5, neue Funktionen
Commons IO „2.0“ Umstieg auf Java 5, Erweiterungen des API
Lucene 3.0.0 und neuer Refaktorisiertes API, neue Funktionen
Tuscany SCA 2.0-M5.1 Neue SCA-Implementierungen
POI 3.7-beta3 Viele Bugfixes
Bernd Fondermann (bernd.fondermann[at]brainlounge.de) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt a. M. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop und Lucene und ist Member der Apache Software Foundation und Vice President Apache Labs.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.