Seite 2: Allianzen, Endanwender

Inhaltsverzeichnis

Neue Allianzen

Nachdem sich die Apachen aus dem Java Community Process im Streit um die Herausgabe des Test Compatibility Kits (TCK) für die Open-Source-Entwickler durch Oracle zurückgezogen haben, stellt sich die Frage nach neuen Allianzen im Java-Bereich.

Als allgemeiner Trend kommt die Apache-Lizenz bei zunehmend mehr Open-Source-Projekten, nicht nur im Java-Bereich, zum Einsatz. Ein prominentes Beispiel hierfür sind die Projekte aus dem Umfeld des Spring Framework. In letzter Zeit hat nun auch in der JBoss-Community ein Umdenken stattgefunden. Wo es sinnvoll ist, verwendet sie nicht nur Apache-Projekte, sondern kooperiert sie inzwischen direkt mit Apache-Projekten, etwa Aries, Kalumet, CXF, DeltaSpike, Qpid, Blaze und Stonehenge. Ein bedeutender Schritt war sicherlich, die CDI-Referenzimplementierung Weld nicht wie bei Red Hat üblich unter die LGPL, sondern unter die Apache-Lizenz zu stellen. Das Framework und der auf Standards setzende CDI-Ansatz sind inzwischen so populär geworden, dass mit DeltaSpike an Erweiterungen gearbeitet wird. Ebenso soll Red Hats PaaS OpenShift unter der für Cloud-Anwendungen immer beliebteren Apache-Lizenz veröffentlicht werden.

Unterwegs zu den Endanwendern

Einer der großen Schwachpunkte der Apache-Projekte ist oft deren Dokumentation. Waren die Nutzer der Apache-Software in der Vergangenheit oft Entwickler oder Systemadministratoren, reichten rudimentäre und veraltete englische HTML-Dokumentensammlungen aus. Wichtige aktuelle Informationen zu finden ist bei einigen Apache-Produkten nicht einfach, da man dazu die Webseite, E-Mail-Liste oder das Projekt-Wiki absuchen muss. Wer es genau wissen will, kann ja immer noch im Sourcecode oder Issue-Tracker nachforschen.

Das Erstellen einer professionellen, mehrsprachigen Dokumentation und darüber hinaus gehende Support- oder Beratungsangebote waren damit Drittanbietern vorbehalten. Mit Produkten wie OpenOffice oder Flex wird die Kommunikation mit den (End-)Benutzern jedoch zunehmend wichtiger. Dadurch dass OpenOffice, anders als viele Apache-Produkte, bereits mehrsprachig verfügbar war, stellt sich auch für die ASF die Frage, wie sie jenseits der Committer die Endbenutzer bei der Übersetzung einbeziehen möchte. Dazu wurde als erster Schritt mit dem Apache Translate Pootle Service einen Übersetzungsdienst mit 70 Sprachen für alle Apache-Projekte zur Verfügung gestellt. Neben OpenOffice sind dort JMeter und Subversion als Übersetzungsprojekte registriert.

Als Ergänzung zu den englischsprachigen wurde für OpenOffice erstmals eine deutschsprachige (ooo-users-de@incubator.apache.org) und eine italienischen Mailingliste (ooo-utenti-it@incubator.apache.org) eingerichtet. Das OpenOffice.org-Forum betreibt die Open-Source-Organisation weiter, um den Dialog mit dem Endbenutzer jenseits der Mailinglisten aufrechtzuerhalten.

Ausblick

Für die eher lahmenden Initiativen wie Apache Extras oder Apache Labs ist bisher leider noch keine Besserung in Sicht. Für den Incubator bleibt es weiter eine wichtige Aufgabe, nachhaltig zukunfts- und überlebensfähige Projekte hervorzubringen. Damit auch zukünftig neue Projekte zu den Apachen hinzustoßen können, ist es nötig, hier die richtige Mischung zu finden und die Projektkultur, die vor allem auf Vertrauen und Kommunikation basiert, weiter auszubauen.

Angesagte Themen wie NoSQL, Cloud und Mobile sind bei den Apachen angekommen. Gerade Endbenutzer stellen neue Anforderungen an Apache-Produkte, wie Mehrsprachigkeit, Handbücher für unterschiedliche Nutzergruppen, einfache Installations- und Konfigurationsverfahren und eine direkte Kommunikationsmöglichkeit über Foren, Blogs oder Wikis. Die bisher eingeleiteten Maßnahmen für OpenOffice scheinen ein Schritt in die richtige Richtung zu sein. Wie die Maßnahmen ankommen, wird sich mit den nächsten OpenOffice-Versionen zeigen.
Frank Pientka
ist Senior Software Architect bei der Materna GmbH in Dortmund und Autor des Geronimo-Buchs im dpunkt Verlag. (ane)