Mit einer Übernahme von Sun durch Oracle würde sich wohl auch für die freie Office-Suite OpenOffice.org einiges ändern - zumindest wenn man den Worten von Oracle-Boss Larry Ellison glauben darf. Dieser hatte vor kurzem mit einem Statement für Aufsehen gesorgt, in dem er sich für einen Rewrite von zentralen Teilen des freien Office auf JavaFX-Basis ausspricht.
Verblüffung
Eine Aussage, die schon damals für so manches ungläubige Staunen gesorgt hat, ist ein solcher Schritt doch nicht unbedingt ein triviales Unterfangen. Recht unmissverständliche Worte für diese Ankündigung findet nun auch Novell-Entwickler Michael Meeks: "Solche Ankündigungen sollte man nicht all zu ernst nehmen", so der langjährige OpenOffice.org-Entwickler im Gespräch mit dem WebStandard am Rande des Gran Canaria Desktop Summit.
Einschätzung
Ellisons Ansage sei primär als Unterstützung für JavaFX zu verstehen, in der Realität sei eine Neuentwicklung alleine schon vom Aufwand her praktisch undenkbar. So schätzt Meeks, dass ein Rewrite mit der aktuellen Anzahl an aktiven EntwicklerInnen gut fünf Jahre benötigen würde, schließlich sei die Code-Basis von OpenOffice.org geradezu riesig. Fünf Jahre, in denen weder die Wartungsarbeiten für bestehende KundInnen noch neue Feature-Arbeit eingerechnet sind, wie der Novell-Entwickler betont.
Kritik
JavaFX sei sicherlich eine interessante Technologie, allerdings sei sie wohl besser für ein Web-Office mit beschränktem Feature-Set als für eine vollständige Desktop-Suite geeignet. Zusätzlich merkt Meeks kritisch an, dass die Sun-Technologie derzeit alles andere als offen sei. So sei zwar anfänglich einiges an JavaFX-Code freigegeben worden, mittlerweile ist dieser aber offenbar gröber umgeschrieben worden, ohne dass die Öffentlichkeit etwas davon gesehen habe. Prinzipiell will der mittlerweile bei Novell auch den Linux-Desktop-Bereich übersehende Entwickler die Oracle-Übernahme aber nicht grundsätzlich negativ bewerten, man sollte zunächst einmal abwarten, wie sich das Ganze entwickle.
Speed
Auf die Frage, wie sich die Entwicklungsgeschwindigkeit von OpenOffice.org im vergangenen Jahr entwickelt habe, muss Meeks hingegen passen: Derzeit bereite das Projekt einen Wechsel des Code-Verwaltungs-Systems vor, statt CVS will man zunächst auf Subversion umsteigen um dann später ein verteiltes System zum Einsatz zu bringen - aller Voraussicht nach Mercurial. Dies sei zwar prinzipiell zu begrüßen - auch wenn er selbst einen direkten Wechsel auf Git bevorzugt hätte - leider habe dies aber auch negative Auswirkungen. Denn teilweise werde schon jetzt einiges extern entwickelt und sei somit zunächst einmal im OpenOffice.org-Repository unsichtbar. Außerdem würde dadurch so manche Detail-Information verloren gehen, so dass einzelne Änderungen kaum mehr zuverlässig zugeordnet werden können.
Renaissance
In das "Projekt Renaissance", das sich dem Umbau des User Interfaces verschrieben hat, seien die bei Novell beschäftigen EntwicklerInnen derzeit nicht involviert, bekennt Meeks. Derzeit sei es aber ohnehin noch zu früh dessen Fortgang irgendwie zu beurteilen, schließlich befinde man sich erst in der Design-Phase. Erst wenn das Coden beginne, würden sich die wirklich kritischen Herausforderungen stellen, immerhin seien auch in diesem Bereich Änderungen an OpenOffice.org mit einem erheblichen Aufwand verbunden. Entsprechend sei es kein Wunder, dass sich viele einst ambitioniert anvisierte Projekte noch heute in der Konzept-Phase befinden.
Fokus
Für sein eigenes OpenOffice.org-Team stehe hingegen in den nächsten Monaten weiterhin die Verbesserung der Interoperabilität mit Microsoft Office im Vordergrund. Dazu zählt der Ausbau des VBA-Supports, so sollen künftig auch Word-Makros unterstützt werden. Bisher hatte man sich in diesem Bereich auf Excel konzentriert. Aber auch der Support für das OOXML-Dateiformat wird weiter ausgebaut, etwa das laut Meeks derzeit mit einigem Aufwand betrieben werde. Und das durchaus mit Erfolg: In aktuellen Builds des Go-OO-Projekts wird mittlerweile bereits der Export von OOXML-Dateien unterstützt. Außerdem will man den Build besser aufteilen, um vor allem neuen EntwicklerInnen den Einstieg leichter machen und an kleineren Verbesserungen an der Tabellenkalkulation arbeiten. (Andreas Proschofsky [@suka_hiroaki auf Twitter] aus Las Palmas / Gran Canaria, derStandard.at, 08.07.2009)