Ein Build sagt mehr als tausend Worte

Wo kommt heute die Innovation her? Sind es tatsächlich die großen und feierlichen Standardisierungsgremien, die als Treiber für Erneuerung und Verbesserung auftreten? Läuft der Innovationsmotor des JCP, die OMG, von Oasis oder des W3C immer noch rund und sauber?

Es war einmal, da haben die großen Industriegremien etwas beschlossen, das dann über die Jahre in die Praxis gebracht wurde. Man beriet darüber, ob man eine Spezifikation entwickeln soll. Dann wurde diese ausgearbeitet und erst hinterher wurde die Technologie auch tatsächlich implementiert. Während dieses Prozesses gingen nicht selten Jahre ins Land.

Beispiele sind hierfür viele der wichtigen Java-Technologien, wie etwa Servlets, EJB, JSF, JCA und viele andere mehr. Auch wurden Referenzimplementierungen gebaut, die sauber wie ein Physikbaukasten für Zwölfjährige funktionierten, die in der Praxis allerdings eher Schrott waren. Einen Einschnitt stellte in dieser Hinsicht das Jahr 1999 dar, als die Aufgabe, Referenzimplementierungen für Servlets und JSPs zu bauen, an die Apache Foundation ging. Der Tomcat war die erste Referenzimplementierung, die auch für die Praxis taugte.

Eine echte Zeitenwende deutete sich um das Jahr 2005 an: JDO, von vielen geliebt, von manchen missachtet, wurde in ein neues Persistenz-API überführt, in dem ganz viel Hibernate steckte, sehr viel TopLink und ein kleines bisschen JDO-Spezifikation. Eine neue Ära war geboren, in der laufender, funktionsfähiger Code durchsetzungsfähiger werden würde als grauer in PDF geschriebener Text.

Auch der kometenhafte Aufstieg des Spring Framework hat bewiesen, dass Innovationsschübe von nun an nicht mehr von den Spezifikationspolitikern, sondern von den echten Entwicklern ausgehen sollten.

Auch die OMG bekommt diesen Trend zu spüren, wenn es um die Softwaremodellierung geht. Wo werden die wichtigsten Weichenstellungen getroffen, wenn es um die Modeling-Techniken geht – in dem Industriekonsortium oder in den entsprechenden Eclipse-Projekten. In unserem Eclipse-Interview (Eclipse Magazin 2.09) mit Ed Merks, langjähriger Modeling-Vordenker bei Eclipse, sagt dieser:

"Open Source entwickelt eine große Kraft und die Personen, die Open Source vorantreiben, werden mehr Einfluss haben als erwartet. Referenzimplementierungen sagen mehr als Worte. Sie sind übrigens auch „grüner“, d.h. sie fällen viel weniger Bäume, weil niemand in Versuchung gerät, sie auf Papier zu drucken. Standardisierte Apparate tappen nur allzu leicht in die Falle, sich zu sehr mit politischen Bemühungen von Komitees, die voller Kompromisse sind, auseinanderzusetzen und letztendlich nur Kompromisslösungen zu produzieren. Schlimmstenfalls können Standards zur Waffe gegen Innovationen werden, indem die kleinen, agilen Mitspieler ausgeschlossen werden und Mittelmäßigkeit produziert wird. Standards sollten darauf konzentriert sein, Best Practices festzulegen. Meiner Meinung nach ist Open Source das Werkzeug, innovative Best Practices zu etablieren und die Zuverlässigkeit und Effizienz der entwickelten Standards zu demonstrieren."

Nicht zu vergessen das OpenJDK-Projekt. Wer es für einen Tummelplatz kleinerer Java-Entwickler hält, die nichts Bedeutendes abliefern und allenfalls einen Pool darstellen, bei dem sich die offiziellen JDK-Implementierer nach Belieben bedienen können, der unterschätzt das Projekt gewaltig. Die Open- Source-Community, die sich rund um OpenJDK entwickelt, wird bei der zukünftigen Richtung, die bei Java eingeschlagen wird, mit Gewissheit ein gehöriges Wort mitreden (siehe auch unsere regelmäßige Kolumne "Viva Java Libre" von Dalibor Topic)

Diese Beispiele sollen nicht die Behauptung in die Welt setzen, dass Spezifikationen auf dem Müllhaufen der Geschichte landen sollten, sondern vielmehr zeigen, dass sich etwas auf dem Markt verändert hat. In sehr vielen Fällen wird zuerst Code produziert, dieser wird diskutiert und bewährt sich irgendwo. Wenn genügend wegweisende Ideen darin enthalten sind, wird womöglich nachträglich eine Spezifikation geschrieben. Code sagt eben mehr als trockene Spezifikationen. Oder: Ein Build sagt mehr als tausend Worte.

In diesem Sinne – viel Spaß bei der Lektüre!

Sebastian Meyen,
Chefredakteur