"Es gibt noch reichlich Raum für Verbesserungen"

von Redaktion  |  14. November 2005, 15:38
  • Artikelbild

Michael Meeks von Novell spricht im Interview mit dem WebStandard über die OpenOffice.org- Entwicklung und notwendige Änderungen

Ursprünglich an grundlegenden Technologien des GNOME-Desktops arbeitend, widmet sich Michael Meeks nun als Leiter von Novells OpenOffice.org-Team voll und ganz der Verbesserung der freien Office-Suite. Dabei ist er auch federführend am ooo-build-Projekt beteiligt, das aus einer verbesserten Version der Software für den Ximian Desktop hervorgegangen ist, und mittlerweile die Basis der OpenOffice.org-Pakete in den meisten Linux-Distributionen bildet. Die Fragen stellte Andreas Proschofsky am Rande der Novell Hausmesse Brainshare in Barcelona.

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.

Das Interview im englischen Original finden Sie hier.

Links

Novell

ooo-build

OpenOffice.org

SUN

Planet OpenOffice.org

OpenOffice.org- Konferenz

Fabasoft

Cairo

Mono

Evolution

Beagle

Hula

F-Spot

Service

Das Interview im englischen Original

Nachlese

Zweite Beta von OpenOffice.org 2.0 veröffentlicht

druckenweitersagen:
posten
15 Postings
Francis Ford Fiesta
28.09.2005 11:39
Jesus Christus - was für ein Bart !!


Sollte eigentlich verboten werden ...

»Pythagoras1«  
21.10.2005 08:57
wtf?!

Buffy die Vampirjägerin 
27.09.2005 22:11
Auch von mir: "danke!"

BranVan 2000
27.09.2005 20:44
an den standard:

ihr redakteur auf diesem gebiet ist gold wert!

Captain Nem0
27.09.2005 20:01
Danke!

Erstens danke für das ausführliche und interessante Interview!
Zweitens danke an alle OpenOffice-EntwicklerInnen. Werd euch mal meine Diplomarbeit widmen ;-)

J. P.
27.09.2005 19:46
Leider ist die Datenbankkomponente noch ziemlich unausgereift

Für den Gelegenheits-Office-User ist das vielleicht nicht so relevant, aber um OpenOffice in Betrieben und im professionellen Bereich einzusetzen ist eine gescheite Datenbankkomponente ein Muss. Leider ist Base noch zum Haareraufen schlecht und im Vergleicht zu MS Access eine Katastrophe.

Manfred Huber
27.09.2005 23:53

access ist keine datenbank sondern ein kinderspielzeug.

Frodo Der Hobbit
28.09.2005 07:52

das ärgert die grösseren anbieter natürlich, dass man mit minimalem footprint und wartungsaufwand ein büro mit 100 leuten mit einer komplexen und superschnellen komplettlösung versorgen kann.

Manfred Huber
28.09.2005 13:45

ich finde das eh sehr toll wenn sie mit access komplexe projekte fuer 100 user mit minimalem wartungsaufwand umsetzen. wahrscheinlich haben wir eine unterschiedliche vorstellung davon was "komplex" ist.

haben sie mit ihrer anwendung auch schon ein paar access upgrades hinter sich?

Aquaticus
27.09.2005 23:03
na dann

muss Base ja wirklich extrem schlecht sein, wenn es sogar noch übler als Access ist;)
Scherz bei Seite: Welche vernünftige Firma setzt eine Desktop-Datenbank ein, wenn sie ein Serverseitiges DBMS haben kann? Das möchtegerne-kompetente mittlere Management (oder vergleichbare Lackafferl), das nach einem kleinen Kurserl ganz überrascht is, dass dasjenige was sie da vorher immer in Excel gebastelt haben, auf einmal ganz subadoll geht? Nun - wenns wirklich was wichtiges sein sollte, wirds von einer kompetenten Person am Server umgesetzt und wenns nur eine Beschäftigungstherapie für sich selbst und das Sekretariat is, ists auch vollkommen unwichtig.

nogga 
27.09.2005 23:46

Da gibts mehr als genug Beispiele:
warum soll ich z.B. für eine Abteilungsinterne Featureliste ein Serverseitiges DBMS machen?
Rechen mal den aufwand!!
Vor allem wenn eine excelsheet mit einen kleinen VBA scripts auch schon ausreicht oder man sich schnell mit Access eine kleine DB inklusive UserInterface zusammenbasteln kann!

Alle schimpfen immer über Access! So schnell wie mit dem Tool macht man selten DB Anwendungen. Das Problem ist halt, das die Leute oft den Zeitpunkt versäumen wenn sie auf eine "echte" DB umsteigen sollten weil es immer komplexer wird

Aquaticus
28.09.2005 20:29
eben

"DBMS machen" Ähm-das 'macht' doch soundso nicht irgendjemand, sondern hat in der Regel die dafür ausgebildete DB-Administration.
"aufwand!!" EBEN! 1 vernünftiges DBMS, das den MitarbeiterInnen geregelt zur Verfügung steht und verhindert, dass diese 100te unnötige Stunden damit verbringen Unsinnigkeiten in VBScript umzusetzen oder z.B.Dinge, die eigentlich relational gelöst werden müssten in einen rekursiven Wahnsinn quetschen, den dann soundso wieder Administrator/innen aufdröseln müssen.
Wenn Du die MitarbeiterInnen so schulen würdest, dass sie echt mal was vernünftiges scripten könnten, müsstest du dir auch die Schulungskosten leisten wollen und nicht alle in den 08/15 "Oh Microsoft Office" Kurs zur Gleichschaltung verfrachten.

nogga 
29.09.2005 10:11

Und was bring dir ein Ausgebilder tDB Administrator?
du vergisst leider das die DB bei den meisten Anwendungen der geringste aufwand ist. Du brauchst nämlich noch solch kleine Sachen wie ein Benutzer Interface, oder sollen die Anwender über SQL statements die Daten einklopfen?

d.h. du brauchst da schon mindestens 2 Leute und wenn wir davon ausgehen, das es fachspezifische Probleme sind, schon 3 Leute, weil jemand muss ja erklären was es tun soll!

Und vergiss die Schulungskosten! Ich kenne niemanden der auser vielleicht in der Schule eine Access Schulung erhalten hat, aber ich kenn mehr als ein dutzend leute die sich mit Access rumgespielt haben.
Da gehts nicht um Access oder ein grosses DBMS sondern um Access oder gar nix (händisch)

Threonin
28.09.2005 10:58
Sie haben völlig recht!

Plattenproduzent
27.09.2005 15:24

danke für das interview, sehr interessant!

Die Kommentare von User und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.

© derStandard.at GmbH 2010 - Impressum

Alle Rechte vorbehalten. Nutzung ausschließlich für den privaten Eigenbedarf.
Eine Weiterverwendung und Reproduktion über den persönlichen Gebrauch hinaus ist nicht gestattet.