Bild nicht mehr verfügbar.
WebStandard: Wann wird OpenOffice.org 2.0 fertig sein?
Michael Meeks: Das liegt in den Händen der Community, insofern ist das schwierig vorauszusagen. Aber für uns als Novell ist es natürlich auch möglich bereits früher einen Entwicklungszweig anzulegen, diesen zu stabilisieren und eine eigene Release zu machen, wenn wir denken, dass der Code bereits gut genug ist. Und ich denke 2.0 weist schon eine ganze Zeit lang eine ziemlich hohe Qualität auf, darum haben wir auch bereits eine Pre-Release mit SUSE Linux 9.3 ausgeliefert - und werden das mit 10.0 wieder machen, was durchaus als Qualitätssiegel zu verstehen ist.
WebStandard: Aber die offizielle Version hätte schon seit langem veröffentlicht werden sollen, oder?
Michael Meeks: Nun, ich denke ein Release-Zyklus von 18-24 Monate, wie wir ihn derzeit haben, ist für freie Software kaum zu rechtfertigen, also wollen wir schauen, wie wir das in Zukunft beschleunigen können. Sechsmonatige Release-Zyklen [wie bei zahlreichen anderen Open Source-Projekten, Anm.] haben sich als wirklich hilfreich herausgestellt, um Fahrt in ein Projekt zu bringen.
WebStandard: Ist der Entwicklungsprozess von OpenOffice.org transparent genug, oder wird zu viel von SUN hinter verschlossenen Türen beschlossen? So ist es ja zum Beispiel recht schwierig herauszufinden, wann denn nun eine Release tatsächlich stattfinden wird.
Michael Meeks: Da steckt sicherlich ein Körnchen Wahrheit dahinter. Aber: SUN versucht wirklich das Richtige zu tun. In Hinblick auf die Lizenz und die Rückgabe des Codes an die Community, haben sie großartige Arbeit geleistet. Die Basis ist also bereits da, aber nicht immer leicht zugänglich. Es ist nicht einfach sich in das Projekt einzubringen oder mit zu bekommen, was gerade vor sich geht. Wir (Novell) versuchen hier mit dem Planet OpenOffice.org und einem simpleren Bug-Interface etwas Abhilfe zu leisten, damit Interessierte einen leichteren Zugang bekommen.
WebStandard: Aber es gibt keine öffentliche Roadmap?
Michael Meeks: Ja, das ist zweifelsohne ein Problem. Ich denke das rührt daher, dass - wenn man in einer "Wir-veröffentlichen-wann-es-für-uns- am-günstigsten-ist"-Mentalität steckt - dies auch einiges über die interne Roadmap von SUN aussagen würde. Wenn man aber stattdessen einen fixen sechsmonatigen Zyklus wählt, ist es nicht mehr so wichtig, wann man genau in diesem Zeitraum eine eigene Release tätigt. Es gibt auch schlicht zu viel Bürokratie in der OpenOffice.org-Community, ein Beispiel: Wenn man eine Änderung vornehmen will, reicht es nicht aus, diese in den Entwicklungszweig einzuspeisen, zuvor muss eine eigene Spezifikation verfasst werden. Diese muss wiederum von fünf SUN-EntwicklerInnen - die schwierig zu kontaktieren sind, da sie natürlich auch jede Menge andere Sachen zu tun haben - genehmigt werden. Dadurch dauert der Prozess ein neues Feature unterzubringen beinahe ewig, was auch wieder dazu führen kann, dass nicht ausreichend getestet wird. Daraus entstand auch die Überlegung für ooo-build, als eine Art Testfeld für neue Patches bevor sie "upstream" in den offiziellen Code einfließen. Ich denke, dieser ganze Prozess muss sich verändern, damit die EntwicklerInnen leichter feststellen können, wann eine Release sein wird.
WebStandard: Ist es schwierig für neue EntwicklerInnen sich an OpenOffice.org zu beteiligen?
Michael Meeks: Ja, ich denke es ist schwierig herauszufinden, wo man beginnen soll. Es gibt einige Probleme, die wir in dieser Hinsicht zu lösen versuchen - wie mit dem eigenen Bugzilla-Interface - aber ich denke die OpenOffice.org-Konferenz in Slowenien steht vor der Tür und das sollte die richtige Zeit sein, um sich mal zusammen zu setzen, diese Dinge persönlich zu besprechen und Lösungen auszuarbeiten.
WebStandard: Vor kurzem wurde die Lizenz für OpenOffice.org geändert, was für Vorteile bringt das?
Michael Meeks: Bisher standen zwei Lizenzen zur Auswahl, die Sun Industry Standards Source License (SISSL) und die GNU Lesser General Public License (LGPL). Die SISSL hat es unter gewissen Voraussetzungen erlaubt, modifizierten Code nicht an die Community zurück zu geben. Also gab es eine Reihe von Firmen und Leuten, die das ausgenutzt haben, was zu einer Fragmentierung der Community führen kann, und nicht allen nützt. Gerade in Hinblick auf den Umfang der Arbeit, die SUN vornimmt wäre es richtig - und besser für alle - wenn die eigenen Modifikationen rückfließen - so wie wir das ja auch handhaben. Auf der anderen Seite ist es aber auch für uanbhängige Softwareanbieter wichtig, dass die LGPL und nicht die die GPL zum Einsatz kommt. Diese ermöglicht es kommerziellen Anbietern, ihre Programme mit OpenOffice.org zu verlinken - wie es zum Beispiel auch Fabasoft aus Österreich macht - und diese in ihr umfangreiches Gesamtpaket zu integrieren.
WebStandard: OpenOffice.org braucht beinahe ewig zum kompilieren, recht lang zum Starten und verbraucht eine Menge an Speicher - ist die Software zu "aufgeblasen"?
Michael Meeks: Ja, ist sie, aber wir werden in dieser Hinsicht kontinuierlich besser [zeigt ein Dokument her, das die Verbesserungen bei der Startzeit herausstreicht, Anm.]. Es sollte auch möglich sein den Speicherverbrauch zu reduzieren. Die Schwierigkeit dabei ist vor allem, dass es einiges an EntwicklerInnenzeit braucht, um überhaupt mal solchen Problemen auf die Spur zu kommen. Und so etwas ist dann halt nicht umgehend als "Erfolg" sichtbar, trotzdem hat Novell einiges in die Entwicklung der dazu notwendigen Tools investiert. Unerfreulicherweise verbraucht OpenOffice.org 2.0 noch immer mehr Speicher als es 1.1 getan hat, aber wir werden das künftig noch optimieren.
WebStandard: Mit der ursprünglichen Ximian-Version für OpenOffice.org 1.x waren die Unterschiede zwischen der erweiterten und der "normalen" Version recht offensichtlich, mit 2.0 scheint diese Lücke kleiner geworden zu sein. Ist dies ein Zeichen dafür, dass neue Änderungen schneller als zuvor in die offizielle Codebasis einfließen?
Michael Meeks: Ja, hier hat sich mittlerweile einiges verbessert. Durch 1.1.x und den langen Release Zyklus mussten wir zahlreiche neue Dinge rückportieren, da SUN keine neuen Features akzeptiert hat. Für 2.0 bin ich optimistisch, dass wir ein wesentlich geringere Anzahl an Patches haben werden. Unser eigener Fokus hat sich dadurch ziemlich verändert, statt Sachen rückzuportieren, konzentriert sich Novells OpenOffice.org-Team nun vor allem auf die Entwicklung von neuen Features wie dem Cairo-Support, der Verbesserung der Visual Basic-Unterstützung und der Mono- und Evolution-Integration.
WebStandard: Wird OpenOffice.org 2.0 bei seinem Erscheinen auch auf 64-Bit-Systemen kompilierbar sein?
Michael Meeks: Nein, sicher noch nicht mit 2.0, dahinter [den Code 64-Bit-clean zu machen, Anm.] steckt ein recht umfangreiches und schwieriges Problem. Es gibt zwar einiges Interesse daran, und wir investieren auch Arbeit in diesem Bereich, aber ich würde sagen, dass es zumindest noch sechs weitere Monate braucht, bis diese vollendet ist.
WebStandard: Zahlreiche Projekte im Bereich der freien Software - wie GNOME oder Firefox - versuchen die Usability ihrer Produkte zu verbessern, in dem sie die User Interfaces und Einstellungsdialoge vereinfachen. Ist das ein Bereich in dem auch OpenOffice.org noch dazu lernen kann?
Michael Meeks: Ja, definitiv. Es gibt noch reichlich Raum für Verbesserungen, zum Beispiel bei der [recht unübersichtlichen, Anm.] Autokorrektur. Außerdem gibt es eine Unzahl an Einstellungsoptionen zwischen denen es oft schwierig ist die wirklich relevanten zu finden.
WebStandard: In der Vergangenheit gab es einige hitzige Diskussionen in der Community über den Umstand, dass OpenOffice.org mit der Version 2.0 immer stärker auf Java basiert, ein Kommentar dazu?
Michael Meeks: Zunächst: Java ist großartig und SUN verwendet es schlicht weil es ihnen ein Plattform-unanbhängiges Toolkit zur Verfügung stellt. Das kann aber natürlich unangenehm für Umgebungen sein, die rein auf freie Software setzen. Zum Beispiel: Wenn man Sound/Video abspielen will, braucht man dafür das Java Media Framework. Darum versuchen wir - und andere - offene Alternativen zur Verfügung zu stellen. Allgemein ist es recht einfach SUN zu sagen, dass sie besser etwas anderes als Java einsetzen sollen - schließlich haben sie ja auch keine EntwicklerInnenzeit zu verschenken, und es ist eben einfach die beste Lösung für sie.
WebStandard: Auf welche Verbesserungen für OpenOffice.org können wir uns nach 2.0 besonders freuen?
Michael Meeks: Ich würde sagen, dass die Visual Basic-Kompatibilität wirklich wichtig - weil für viele Leute von großem Nutzen - ist. Die weitere Verbesserung der Performance ist ebenso ein zentrales Thema - ein Bereich in den ich selbst momentan die meiste Zeit investiere. Und das macht auch einigen Spaß, schließlich lässt sich dieses Problem nicht alleine auf OpenOffice.org beschränken, da spielen auch die glibc, der Compiler und die gesamte Toolchain eine entscheidende Rolle.
WebStandard: Wird es von Novell auch eine erweiterte OpenOffice.org-Version für Windows geben?
Michael Meeks: Wir haben zwar eine solche Version für den internen Gebrauch, aber es gibt keine Pläne diese öffentlich zu machen. Aber der Source Code ist natürlich frei zugänglich, insofern steht es allen frei dies selbst zu tun.
WebStandard: Innerhalb von Novell arbeiten eine Reihe von EntwicklerInnen an Dingen wie Beagle, Hula oder F-Spot, die eher als "cool new stuff" angesehen. Wäre es nicht manchmal verlockend selbst an einem dieser Projekte zu arbeiten, wo es "leichtere" Gewinne zu erringen gibt?
Michael Meeks: Natürlich gibt es auch andere Dinge, an denen ich mir zu arbeiten vorstellen könnte, und die erwähnten Projekte sind tatsächlich sehr interessant. Aber das Nette an OpenOffice.org ist, dass es so groß und solche eine Herausforderung ist, da es so wenig Leute gibt, die sich mit dem Code auskennen, und dass es leicht ist mit einer kleinen Änderung sehr vielen Menschen weiterzuhelfen. Insofern ist die Arbeit daran äußerst befriedigend.
WebStandard: Danke für das Gespräch.