Michael Meeks, der bei Novell angestellte OpenOffice.org- Entwickler findet deutliche Worte für Suns Community-Management

Foto: GUADEC

Michael Meeks ist einer der profiliertesten Hacker in der freien Software-Welt. Ursprünglich an der Entstehung einiger zentraler Komponenten des Linux-Desktop GNOME beteiligt, leitet er nun bereits seit einigen Jahren die OpenOffice.org-Entwicklung beim Softwarehersteller Novell.

Mit seiner über die Jahre stark angewachsenen Truppe hat er einige zentrale Verbesserungen an der freien Office-Suite vorgenommen, und hatte dabei doch stets mit den administrativen Hürden von SUN zu kämpfen. Des Unternehmens also, das die freie Office-Suite einst zu Open Source gemacht hat, sich nun aber zunehmend als Hindernis für ein wirklich offenes Projekt darstellt, wie Meeks im Interview mit Andreas Proschofsky beklagt. Das Gespräch wurde am Rande der GNOME Users and Developers Conference (GUADEC) in Istanbul geführt.

Das folgende Interview ist auch in der englischsprachigen Original-Version verfügbar.

derStandard.at: Immer mehr Anwendungen verlagern sich ins Web - ein Trend der gerade im Office-Bereich mit Angeboten wie Google Documents derzeit deutlich sichtbar ist. Verschwindet langsam die Notwendigkeit für eine vollständige Desktop-Office-Suite?

Michael Meeks: Das ist eine sehr gute Frage, aber auch eine, die sehr schwer zu beantworten ist. Nun ich denke es gibt eine Vielzahl von unterschiedlichen Klassen von Anwendern, eine Vielzahl von unterschiedlichen Aufgaben. Und die einfachen Aufgaben wandern ins Web, wo es ja auch einige Vorteile gibt. Vor allem die einfache Zusammenarbeit mit anderen ist ein Killer-Feature, das diese sonst recht funktionsfreien Office-Anwendungen nützlich machen. Aber das Problem ist natürlich: Wenn sich mehr und mehr Sachen in das Web verlagern, bleiben die nicht-trivialen Aufgaben übrig, und einiges davon braucht recht viel Rechenkraft. Sogar ein simples Diagramm in einer Präsentation kann hohe Anforderung stellen, wenn dahinter eine riesige Pivot-Tabelle ihre Arbeit verrichten muss.

OpenOffice.org ist außerdem jetzt noch nicht mal fertig und das alles in HTML und Javascript neu zu schreiben, wäre ziemlich schwierig, das Web ist einfach auch keine sonderlich nette Entwicklungsumgebung. Es ist hier ziemlich schwierig, etwas zu produzieren, das wirklich haargenau so aussieht, wie man es gern hätte. Und das ist durchaus so beabsichtigt, das Web ist nicht für fixes Layout ausgelegt, was auch an sich gut ist, aber wenn man Dokumente layoutieren will, braucht man einfach mehr Präzision.

derStandard.at: Das User Interface von OpenOffice.org orientiert sich noch immer recht stark an dem von Office 2003. Microsoft hat in diesem Bereich mit Office 2007 einen großen Schnitt vorgenommen, wird OpenOffice.org diesem Vorbild folgen?

Meeks: Wir müssen tatsächlich das User Interface grundlegend überarbeiten, und das ist auch bereits in Planung. Aber die wirklich Problematik mit unserem gegenwärtigen UI ist meiner Meinung nach nicht die Frage nach Ribbon oder Nicht-Ribbon. [Ribbon ist der Name für das User-Interface-Prinzip, das Office 2007 einsetzt, Anm. apo] Unser Problem ist,dass wir noch immer ein ziemlich unflexibles Toolkit namens VCL einsetzen, das eine Entwicklung aus der Mitte der Neunziger-Jahre und schlicht ein Desaster ist. Es wurde seit damals einfach nicht mehr verbessert. Also versuchen wir hier momentan Verbesserungen vorzunehmen, um vernünftige Layout-Möglichkeiten einzuführen. Und das ist eine Entwicklung, die wir antreiben, die von Novell finanziert wird.

derStandard.at: Soll VCL dabei verbessert oder ganz ersetzt werden?

Meeks: VCL gänzlich verschwinden zu lassen, wäre schwierig, da es nicht nur für das User Interface sondern auch innerhalb der Dokumente selbst zum Einsatz kommt. Also versuchen wir künftig für das UI ein anderes Toolkit zu verwenden, wir wollen GTK+ als alternatives Backend einsetzen.

derStandard.at: Wird sich diese Änderung auf die Linux-Version beschränken?

Meeks: Ja. Momentan verwendet VCL unter Linux GTK+ um den Style anzuzeigen, auch das Hauptfenster ist bereits ein "richtiges" GTK+-Fenster, vieles der benötigten Infrastruktur ist also bereits vorhanden.

Eines der Probleme ist - wenn man sich zum Beispiel den Firefox ansieht: Sie haben das UI verändert und das erzielte Ergebnis ist wirklich exzellent, aber sie haben eben auch wirklich nur wenige Interface-Elemente. Und bei OpenOffice.org gibt es solch eine riesige Menge an User Interface, also ist es schwierig Änderungen einzuführen. Das ist auch der Grund warum sich über die Jahre hier so wenig getan hat. Wir hoffen also, dass die Art und Weise wie wir die Layout-Fähigkeiten designet haben, dabei helfen werden, hier einfach und ohne viele Komplikationen Änderungen vornehmen zu können, um schnell zu etwas zu kommen, das besser ist und netter aussieht. Die ersten Ergebnisse davon sollten innerhalb der nächste sechs Monate in der Codebasis landen.

derStandard.at: Ist die Veröffentlichung der nächsten Release unter dem Namen OpenOffice.org 3.0 nicht primär ein Marketing-Schritt? Immerhin gibt es eigentlich nichts, was es von einer weiteren Release in der 2.x-Reihe abhebt.

Meeks: Ja, das ist es. Aber ich denke, das ist nichts, wofür wir uns zu schämen brauchen.

Mit der Umstellung auf einen regelmäßigen Veröffentlichungs-Zeitplan haben wir in letzter Zeit einen großen Schritt nach vorne gemacht, schon lange vorher ist nun ist klar, wann eine neue Release herauskommen soll. Und das hat auch großartige Verbesserungen bei der Stabilität zur Folge gehabt, da der Abstand zwischen dem Melden eines Fehlers und dessen Behebung erheblich verkürzt wurde, dadurch bekommen wir nun auch mehr Feedback. Außerdem werden nun keine neuen Features mehr in letzter Minute eingeführt, da ohnehin klar ist, dass die nächste Release schon in sechs Monaten folgt.

Insofern sollte man OpenOffice.org nicht dafür kritisieren, dass nicht alles vollständig neu ist mit 3.0, es ist einfach eine willkommene Marketing-Gelegenheit. Es ist auch einfacher zu sagen "das wurde in Version 2.0 gelöst, das in Version 3.0".

derStandard.at: Abseits der User-Interface-Arbeiten, worauf konzentrieren sich Ihre Bemühungen gerade?

Meeks: Momentan tut sich einiges, vor allem auch in Hinsicht auf die bessere Unterstützung von VBA [Microsofts Visual Basic for Applications, Anm. apo], daran arbeiten gerade einige Entwickler. Ich selbst bin vor allem an der Build-Umgebung und der Entwicklerseite interessiert. Eines unserer größten Versagen ist es bislang externe Entwickler bei OpenOffice.org einzubinden, und das zu ändern liegt mir wirklich am Herzen. Insofern werden wir den gesamten Build in mehrere Source-Pakete aufteilen, damit man künftig nicht mehr die gesamte Suite neu kompilieren muss, wenn man nur einen Bug in Calc bereinigen will. Aus Entwicklersicht ist das wirklich eine zentrale Verbesserung.

Was allerdings wirklich schade ist, ist dass derzeit eine Abnahme der Investitionen in OpenOffice.org zu bemerken ist. So kürzt etwa Sun die Anzahl der am Projekte beteiligten Entwickler, während sie auf der anderen Seite weiterhin uneingeschränkte Besitzansprüche auf den Code anmelden, eine Situation, die natürlich andere davon abhält mehr zu investieren.

derStandard.at: Schon in der Vergangenheit wurde ja immer wieder einmal spekuliert, dass sich Sun früher oder später aus der OpenOffice.org-Entwicklung zurückziehen könnte, da man ja nicht wirklich das große Geld damit macht. Was würde in so einem Fall passieren?

Meeks: Um ehrlich zu sein, bin ich mir nicht sicher, ob das wirklich etwas vollständig Negatives wäre. Es wäre natürlich furchtbar Sun und die Entwickler, die sie einbringen, zu verlieren, immerhin ist Sun - wenn auch auf einem reduzierten Niveau - noch immer ein wichtiger Faktor und macht einiges an gutes Arbeit. Es ist aber wirklich eine Schande, dass Sun diese großartige Entwicklerkultur hat, aber es wirklich übel wird, wenn es dann um das Management von Projekten geht.

Rein auf ihren Entwicklungsbeitrag bezogen: Ja, so weit ich weiß haben sie noch immer einige Entwickler, die an OpenOffice.org arbeiten, aber das sind weniger als früher, es ist offensichtlich, dass hier Leute intern auf andere Projekte verlagert werden. Und das ist auch durchaus in Ordnung so, Sun kann mit seinen Ressourcen machen, was es will. Das traurige ist allerdings, das man vollkommen dabei versagt hat eine Community aufzubauen, andere Leute zu involvieren. Und das hängt damit zusammen, dass OpenOffice.org noch immer Sun gehört. Es ist ein Sun-Projekt. Sie besitzen den Code, sie verlangen [von allen, die Code beitragen wollen verlangt Sun ein "Copyright Assignment", Anm. apo] eine Übertragung der Eigentumsrechte, und das wirkt einfach ziemlich abstoßend.

Insofern gibt es wohl derzeit auch wachsende Zweifel an Suns Motivation rund um OpenOffice.org.

derStandard.at: Trotzdem: Wenn Sun geht, sind auch zahlreiche Entwickler weg...

Meeks: Ich sage nicht, dass Sun sich vollständig zurückzieht, nur um das klar zu stellen. Aber sie reduzieren ihre Investitionen. Aber: Wenn Sun weg wäre gäbe es auch die Möglichkeit endlich lange vorhandene Probleme zu beseitigen, die Möglichkeit, die Community lebendiger zu gestalten und es einfacher und interessanter zu machen an der Entwicklung mitzuarbeiten.

derStandard.at: Das Copyright Assignment würde dann wohl auch wegfallen?

Meeks: Klar, aber ich bin nicht einmal prinzipiell gegen ein Copyright Assignment. Wenn sich eine Stiftung oder eine andere Art von unabhängiger Organisation darum kümmert, ist das ok für mich. Die Free Software Foundation verlangt das zu Beispiel, und deren Abmachung ist wesentlich strikter. Das Problem bei OpenOffice.org ist einfach, dass man Sun vertrauen muss um in das Projekt zu investieren. Und wie weit man Sun vertrauen kann, ist eher fraglich.

Dabei haben sie ja versucht Kompromisse einzugehen, sie haben diesen äußerst umständlichen Organisationsprozess eingeführt, sie haben ein Advisory Board gegründet. Und dann haben sie sich immer wieder zusammengesetzt, haben geredet und geredet und haben schließlich einen Plan entworfen, wie man Code in das OpenOffice.org-Repository einbringen darf. Also darf man nun zwar Code beisteuern, dies ist allerdings mit einer schier endlosen Liste von Einschränkungen verbunden, die praktisch unmöglich zu erfüllen sind. Allen dieses furchtbare System als ultimatives Angebot zur Öffnung vor zu setzen ist erbärmlich, es ist lächerlich.

Wir haben einfach auf mehr gehofft, und wenn wir sicher stellen könnten, dass unsere eigenen Verbesserungen direkt in OpenOffice.org einfließen, wären wir begeistert. Wenn OpenOffice.org sich stärker öffnet, wären wir glücklich, das würde unseren Streit mit Sun beenden. Und es ist ja wirklich quälend zu sehen, wie sie soweit gehen, so viel Energie investieren und dann doch nicht den letzten Schritt machen. Mit all diesen lächerlichen Beschränkungen, der unklaren rechtlichen Situation - nichts kann mit OpenOffice.org ausgeliefert werden, wenn es nicht Sun gehört. Und das ist einfach eine Schande. Wenn jemand ein offenes Projekt kontrolliert und absichtlich externe Beiträge verhindert - nur aus eigenen proprietären Interessen heraus - dann fragt man sich schon, wie offen OpenOffice.org eigentlich wirklich ist.

derStandard.at: Zurückkommend zur Frage des Copyright Assignments: Macht Novell so etwas nicht selbst auch, etwa beim Mono-Projekt?

Meeks: Das ist natürlich eine wirklich gute Frage. Wenn man sich Mono ansieht, dann stimmt es, dass Novell eine Firmepolitik hat, die ein Copyright Assignment für den Kern - den JIT - hat, der allerdings nur einen kleinen Teil des gesamten Codes darstellt, weniger als 15 Prozent. Mono ist dieses riesige Ding, es beinhaltet die Klassenbibliotheken, es beinhaltet ziemlich viel Infrastruktur, all diese Dinge können problemlos weiterverwendet werden. Es ist nur der Kern, der unter der LGPL steht und das aus kommerziellen Gründen, was wir aber auch sehr deutlich sagen. Wenn man also bei Mono mitarbeiten will, kann man das in 80+ Prozent des Projekts, ohne irgendwelche Rechte abtreteten zu müssen. Wir wären wirklich glücklich, wenn das bei OpenOffice.org der Fall wäre.

Sun versucht übrigens das Problem auf Plug-ins abzuschieben, wo man dann kein Copyright Assignment braucht. Also liefert man nun die Software ziemlich unfertig aus, um so manches Dokument zu öffnen, muss man zuerst online gehen und eine Erweiterung herunterladen. Dabei ist die OpenOffice.org User Experience eigentlich auch schon so schlecht genug, ohne dass jemand sagt: "Du musst das installieren, also geh zu dieser Webseite, schau dir unsere Werbung an und dann lad es herunter".

derStandard.at: Auf welche Teile beziehen Sie sich da konkret?

Meeks:Interessanterweise gibt es gleich mehrere Teile, die von Haus aus nicht installiert werden, um mehr Traffic auf die Plugins-Seite zu erzeugen. So gibt es etwa den "Report Builder", der wirklich ein zentraler Teil der Datenbank-Komponente ist. Und anstatt dass er einfach da ist, wo er sein sollte, bekommt man einen Hinweis auf die Plugins-Seite. Und das ist einfach eine furchtbare User Experience, und es gibt auch keinen vernünftigen Grund dafür.

derStandard.at: Durch die Unzufriedenheit mit Sun scheinen Sie auch die eigene OpenOffice.org-Version - Go-oo - immer stärker zu pushen, oder?

Meeks: Das ist richtig. Frustration ist dafür wohl der Hauptgrund, wir wollen eine gute User Experience liefern, wir wollen unseren Code an die User bringen, wir wollen ihn veröffentlicht haben - und wenn Sun das nicht tut, dann müssen wir das halt selbst tun. Also bieten wir nun eigene Versionen für Windows und auch generische Builds für Linux an, und fordern die Leute auf sie zu benutzen. Wir hätten wirklich gerne eine gemeinsame Release, aber momentan ist das mit Sun einfach nicht zu machen.

Der Schnellstarter im Systray ist dafür ein gutes Beispiel. Wir haben diesen massiv verbessert, wir haben ihn unter Windows und Linux getestet und unseren Patch upstream geschickt. Leider hat er unter Windows zu Problemen geführt, also hat Sun ihn selbst "repariert". Dies hatte aber zur Folge, dass der GTK+-build wieder nicht funktionierte, da sie das offenbar nicht einmal getestet haben. Also haben wir nun eine Situation, wo sich der neue Schnellstarter zwar im Source Code befindet, aber sich nicht aktivieren lässt, da ihn Sun beim Kompilieren weg lässt. Was wirklich eine Schande ist, immerhin ist er ein ziemlicher Performancegewinn.

Weitere Beispiele für Sachen, die Upstream noch nicht akzeptiert wurden, sind der gstreamer Audio/Video-Support, die Unterstützung von Microsoft Works-Dateien, die Mono-Integration, besseres Rendering von chinesischen Schriftzeichen und vieles mehr. Sie können sich die Liste unter go-oo.org/discover ansehen.

derStandard.at: Momentan hinken die Go-oo Releases noch ein ganzes Stück hinter den "offiziellen" von OpenOffice.org hinterher, will man das verbessern?

Meeks: Ja. Und wir haben das in letzter Zeit bereits deutlich verbessert. Wir versuchen die Veröffentlichungen gleichzeitig mit Sun vorzunehmen, die Leute wollen ja auch nicht ewig auf Bugfixes warten.

derStandard.at: Einen zentralen Teil ihrer eigenen Entwicklungsbemühungen hat in der Vergangenheit die Konzentration auf Performanceverbesserungen und die Reduktion des Speicherverbrauchs eingenommen. Gibt es da noch Chancen auf weitere substantielle Verbesserungen?

Meeks: Definitiv. Wir haben hier in Zusammenarbeit mit AMD, die für ihre eigenen Bestrebungen bei ultramobilen Geräten daran interessiert waren, einiges an Arbeit geleistet. Das hat dann auch dabei geholfen, dass OpenOffice.org unter Linux - und auch auf anderen Plattformen - besser läuft. So haben wir etwa die Startgeschwindigkeit - auf einem halbwegs aktuellen Rechner - auf weniger als fünf Sekunden reduziert. Der erste Start ist allerdings weiterhin ein Problembereich, da hier noch zu viel unnötiger Code geladen wird, was natürlich nicht sonderlich schlau ist.

Aber eigentlich finde ich die aktuelle Performance schon ziemlich beeindruckend, wenn man sich zum Vergleich den GIMP ansieht, starten wir bereits flotter. Beim Warmstart nähern wir uns langsam dem Firefox, wenn wir also noch die Kaltstart-Probleme lösen, sollten wir ziemlich gut sein.

derStandard.at: Ihre offizielle Aufgabe bei Novell ist nun "Desktop-Architekt", was beinhaltet das?

Meeks: [lacht] Berichte schreiben und mit Leuten reden. Versuchen andere zu einer verstärkten Zusammenarbeit zu bringen. Momentan haben wir da etwa einige interessante Dinge am Laufen, um GNOME und KDE näher zueinander zu bringen. Und ich muss sagen, dass ich relativ beeindruckt bin von den KDE-Entwicklern bei SUSE, die das voll angenommen haben. Die Desktops näher zusammenzubringen und mehr Code zu teilen, ist wirklich zentral. Für uns liegt das Interesse natürlich daran Wartungskosten zu reduzieren, immerhin heißt es das rund 85 Prozent der Softwareentwicklungskosten in die Wartung gehen. Zusätzlich arbeiten auf beiden Seiten äußerst schlaue Personen, also macht es für alle Sinn sie zu einer verstärkten Zusammenarbeit zu bringen - halt da wo es keine größeren philosophischen Unterschiede gibt. Wir wollen ja nicht, dass KDE nicht mehr KDE ist, GNOME nicht mehr GNOME, aber bei gewissen Dingen macht ein Wettbewerb einfach keinen Sinn.

derStandard.at: Das Ziel ist aber nicht die beiden Desktops zu vereinen?

Meeks: Nein, wir wollen keine Vereinheitlichung, wir wollen keinen einzelnen Desktop, beide zu haben ist großartig. Aber sie zur Zusammenarbeit zu bewegen ist sinnvoll. Und es gibt ja auch bereits recht viel versprechende Zeichen, es wird schon viel Code zwischen den Desktops geteilt. d-bus ist dafür ein großartiges Beispiel, nicht nur weil beide es verwenden, sondern auch weil es ein Multiplikator ist, weil es die Vermischung von GNOME und KDE-Technologien ermöglicht.

Zusammen haben wir einfach wesentlich mehr Kraft, um andere zu einer Mitarbeit zu bringen und die Fragmentierung für Anwendungen wie Mozilla oder OpenOffice.org zu reduzieren, indem wir eine wirklich gute geteilten Infrastruktur anbieten können, die noch dazu plattformübergreifend ist. Insofern ist das schlicht ein logischer Schritt, die Schwierigkeit liegt darin, all die Spaltungen, die Sprachbarrieren und solche Dinge zu überwinden.

(Andreas Proschofsky, derStandard.at, 27.07.2008)