Die erste Frage ist natürlich, was sich durch Open Source überhaupt ändert, immerhin stehen die Sourcen ja zu einem großen Teil schon hier oder hier zum Download bereit. Dennoch ändert sich der juristische Status, was bedeutet, dass Java jetzt auch in Bereiche vorstoßen kann, die nie zuvor ein JDK betreten hat, also zum Beispiel einige Linux Distributionen oder auch Organisationen, die nur Open Source nutzen wollen. Gerade dies wird in Zukunft wichtiger werden, da zum Beispiel einige Länder signalisiert haben, dass sie in Zukunft nur Open Source nutzen wollen, um möglichst wenig von Technologie-Anbietern abzuhängen.
Ein mögliches Problem ist das Entstehen von Forks. Wenn man sich allerdings Open Source im Allgemeinen anschaut, so ist das generell kein so großes Problem. Das gilt z.B. für Linux, anders sieht es vielleicht bei BSD aus. Man muss eben einen Fork dauerhaft weiter pflegen, und diesen Aufwand dauerhaft zu betreiben, ist nicht so einfach. Außerdem ist man von den Bug-Fixes des eigentlichen Systems abgeschnitten. Und so ist trotz der sehr liberalen Apache Lizenz zum Beispiel bei Spring soetwas bisher nicht passiert und auch sehr unwahrscheinlich. Bei Java gibt es allerdings schon heute in gewisser Weise Forks, da es viele unterschiedliche JDK-Hersteller gibt, darunter Firmen wie BEA und IBM. Eine Rolle spielt sicher auch, dass Microsoft versucht hatte, eine inkompatible Version von Java auf den Markt zu bringen. Dieses Problem ist meiner Ansicht nach aber keines mehr, denn Microsoft hat mit .NET und J# mittlerweile eine andere Strategie zum Umgang mit Java.
Andere Lizenzen können Forks effizient verhindern - ein Beispiel ist sicher JBoss mit GPL und das Vorgehen gegen Apache Geronimo wegen dem Kopieren von Code (siehe dieser Brief). Denn durch die GPL muss man seine Änderungen veröffentlichen, so dass man nicht "im stillen Kämmerlein" eine eigene Version erstellen kann, deren Änderungen nie veröffentlicht werden, und man kann den Code auch nicht unter einen anderen Lizenz wieder veröffentlichen.
Ein anderer Vorteil von Open Source ist die Innovation. Jeder kann sich beteiligen: Wenn ich eine gute Idee für eine Linux-Erweiterung habe, kann ich sie vorschlagen oder sogar implementieren und einbauen. Allerdings gibt es hier bei Java ein Problem, denn Java wird im Rahmen des JCP-Prozess standardisiert. Wenn ich einen tollen neuen Garbage Collection Algorithmus habe, kann ich ihn einbauen, weil es nach außen keine Änderung ist. Wenn ich aber eine geniale Idee für eine Modifiaktion am JDK habe, die eine Ergänzung zum Standard darstellt oder ihn gar bricht, muss ich durch den JCP-Prozess. Und der kann langsam sein. Man kann es an Spring und EJB 3 festmachen. Spring ist ein nicht standardisiertes Open Source Projekt, EJB 3 ein Standard, die beide im Java Enterprise Bereich zu Hause sind. Am 30.6.2004, als die ersten öffentlichen Versionen von EJB 3 / JSR 220 erschien, war Spring in Version 1.0.2. Als JSR 220 am 11.5.2006 final war, gab es Version 2.0M4 von Spring und dazwischen waren 1.1 und 1.2 erschienen. Dafür gibt es zahlreiche, gute Gründe wie die Integration anderer Persistenz-Ideen in JSR 220, und es gibt sicher schneller JCPs. Aber es zeigt auf jeden Fall, dass man ohne Standard schlicht schnell neue Versionen bauen kann und dadurch auch schnell Feedback aus der Praxis bekommt, mit dem man dann das Produkt iterativ verbessern kann. Und agile Methoden lehren uns, dass schnelles Feedback sehr wichtig ist.
Also: Auch wenn Java Open Source wird, werden Innovationen wie die Unterstützung von dynamischen Sprachen auch weiterhin in einem JCP standardisiert und damit wird es - selbst wenn jetzt sofort jemand eine komplette und tolle Implementierung vorlegt - erst in Java SE 7 in 2008 kommen.
Fazit: Ich glaube, dass der Schritt letztendlich eine konsequente Fortsetzun der Strategie von Sun ist, Software-Assets in Open Source zu wandeln. Die Auswirkungen sind vor allem auf der politischen und juristischen Ebene zu suchen. Für uns als Techniker sollte sich nicht allzuviel ändern. ¶ 10:30
