Die Freiheit, die ich meine …

Am 28. September 2010 gaben einige Mitglieder des OpenOffice.org-Projekts die Gründung einer unabhängigen Stiftung namens The Document Foundation bekannt. Parallel dazu veröffentlichten sie mit LibreOffice ihre eigene Version der freien Office-Suite. Zwei bisher im OOo-Projekt aktive Vertreter berichten über die Hintergründe dieses Schritts.

In Pocket speichern vorlesen Druckansicht 11 Kommentare lesen
Lesezeit: 11 Min.
Von
  • Thorsten Behrens
  • Florian Effenberger
Inhaltsverzeichnis

Im Herbst 2010 rumorte es im Umfeld der freien Büro-Suite OpenOffice.org (OOo). Seit der Übernahme von Sun durch Oracle gab es aus der Community des Projekts immer wieder Beschwerden über Oracles Vorgehensweise. Das führte letztlich dazu, das führende Mitglieder der Projekt-Community die Gründung einer unabhängigen Stiftung namens „The Document Foundation“ (TDF) ankündigten. Zeitgleich veröffentlichten sie mit LibreOffice ihre eigene Version der freien Office-Suite.

Schon bei der Ankündigung des OpenOffice.org-Projekts im Jahr 2000 plante Sun Microsystems eine unabhängige Stiftung. Zehn Jahre später hatte sich das Community-basierte Entwicklungsmodell als Erfolg herausgestellt: Mehr als 20 % Marktanteil in zahlreichen Ländern, über 100 Millionen Downloads pro Jahr und eine der weltweit größten Open-Source-Communities sprechen für sich.

Trotzdem gab es auch kurz vor dem zehnten Geburtstag keine Bemühungen, die angekündigte Stiftung ins Leben zu rufen, und mit Übernahme von Sun durch Oracle Anfang 2010 geriet die Projektarbeit immer schwieriger. Herrschte bei Sun noch eine Kultur der offenen und konstruktiven Kommunikation, so gestaltete sich der Dialog mit Oracle schwieriger und die Unsicherheit über die Zukunft des Projekts bereitete zahlreichen Aktiven durchaus Sorgen.

Mehr Infos

Stellungnahme Oracle

Da Oracle an der Entwicklung, die zur Gründung von LibreOffice geführt hat, erheblichen Anteil besitzt, hat iX dem Softwarehersteller diesen Artikel vorab zur Verfügung gestellt und um eine Stellungnahme gebeten. Leider hat Oracle die Gelegenheit bis zum Redaktionsschluss ungenutzt verstreichen lassen.

Vieles konnte man angesichts der großen Übernahme zumindest vorübergehend noch verstehen. Beispielsweise ist die unklare Regelung zur Benutzung des neuen OpenOffice.org-Logos – eines der Themen, die die Community in den letzten Monaten stark beschäftigten. Selbst langjährige Aktive wussten nicht, unter welchen Bedingungen sie die Marke in ihrer täglichen Arbeit verwenden durften. Nachdem sich auch die Hoffnung nicht erfüllte, Oracle-Verantwortliche würden auf der OpenOffice.org-Konferenz in Budapest klar Stellung zur Zukunft des Projekts beziehen, unterstützten viele Aktive in der Community den Schritt, eine unabhängige Stiftung zu gründen.

Dabei darf dies keineswegs als Trennung vom Hauptsponsor verstanden werden, sondern als Mittel, die Errungenschaften der letzten Dekade zu bewahren und gleichzeitig sowohl die Community als auch das Produkt weiterzuentwickeln. So erhielt Oracle ganz bewusst eine Einladung, sich der Stiftung gleichberechtigt anzuschließen. Der Konzern gab jedoch kurz darauf bekannt, das OOo-Projekt wie gewohnt und unabhängig von der Document Foundation weiterzuführen, an der Stiftung sei man nicht interessiert. Wegen Oracles Namensrechten an OpenOffice.org geriet der ursprünglich als Platzhalter gedachte Name LibreOffice zum neuen Projektnamen.

Nachdem vor allem Oracle-Mitarbeiter einen Interessenkonflikt der TDF-Gründer in den Raum gestellt hatten, traten Letztere von ihren ehrenamtlichen Posten zurück, was schlussendlich unter anderem im geschlossenen Abgang nahezu der gesamten freiwilligen deutschsprachigen Community gipfelte – die Seite der Ansprechpartner stand bis zum Redaktionsschluss fast leer.

Heute haben die Aktiven im Projekt LibreOffice unter dem Dach der Document Foundation ein neues Zuhause gefunden. Im sogenannten „Next Decade Manifesto“, in Anspielung auf das zweite Jahrzehnt des Projekts, haben die Gründer ihre Pläne und Ideen für die Zukunft festgehalten. Eine unabhängige Stiftung spiegelt die Werte und Ideale der Community am besten wider. Im Vordergrund der meritokratisch aufgebauten Document Foundation stehen die Unabhängigkeit von einem einzelnen Sponsor, das Senken der Einstiegshürde für Helfer und Firmen sowie Transparenz und Offenheit in allen Prozessen.

Unterstützung erfährt das Projekt nicht nur von (ehemals) Aktiven des OpenOffice.org-Projekts und von zahlreichen Organisationen wie FSFE, Novell, Red Hat oder Google, sondern auch von Vereinen aus Deutschland, der Schweiz, Brasilien und Italien. Zudem haben die führenden Linux-Distributoren angekündigt, die voraussichtlich Ende Januar erscheinende finale LibreOffice-Version in ihre Distributionen aufzunehmen. Auch der CIO der Stadt München äußerte sich positiv zur Stiftungsidee.

Trotz all dieser Erfolge existiert die Document Foundation derzeit noch nicht als juristische Person. Momentan verwaltet der gemeinnützige Verein OpenOffice.org Deutschland e.V. die entsprechenden Rechtsgüter, sammelt Spenden und betreut die technische Infrastruktur. Die tatsächliche Gründung erfolgt bewusst erst jetzt, um allen Firmen und Sponsoren ausreichend Gelegenheit zu geben, sich zu beteiligen.

Derzeit gibt es ein Steering Committee, das aus acht Mitgliedern und deren Stellvertretern besteht. Es wickelt das Tagesgeschäft ab und kümmert sich auch um die Gründung der Stiftung. Danach wird es sich auflösen und die Geschäfte an die Organe der Stiftung übergeben. Wichtig ist den Gründern Transparenz, so finden beispielsweise alle Telefonkonferenzen öffentlich statt.

Ihren Sitz soll die Stiftung in Deutschland bekommen, ein erster Entwurf der Statuten existiert bereits. Das hiesige Stiftungsrecht genießt einen guten Ruf und bietet Sicherheit – einer der Gründe, warum ein Verein nicht ausreicht, denn dort ließe sich die Satzung relativ einfach ändern.

Bei allem ehrenamtlichen Engagement der letzten Wochen darf man aber nicht vergessen, dass zur Stiftungsgründung ein Kapitalstock von mindestens 50 000 bis 100 000 Euro empfohlen ist. Das ist eine Besonderheit des Stiftungsstandorts Deutschland, aber letzten Endes der gewünschten Sicherheit geschuldet. Nur so lässt sich sicherstellen, dass die Stiftung unabhängig von einzelnen Großsponsoren agieren kann und damit Kontinuität und Investitionsschutz erreichen. Die Arbeit der nächsten Wochen wird daher vor allem darin bestehen, Kontakt zu potenziellen Sponsoren und Unterstützern aufzunehmen.

Leider warten derzeit viele Firmen mit einer Beteiligung auf die Existenz der Stiftung, deren Gründung jedoch wie dargestellt schon einen großen finanziellen Aufwand bedeutet, den der Verein nicht allein stemmen kann. Hier gilt es, noch mehr Überzeugungsarbeit zu leisten. Das grundlegende Interesse von Wirtschaft und Verwaltung an der Foundation ist vorhanden, nun muss sich dies auch durch entsprechende Unterstützung ausdrücken.

Gleichzeitig will die Document Foundation auch eine seit vielen Jahren bekannte Unzulänglichkeit des Projekts angehen: den Programmierermangel. Während sich in allen anderen Bereichen – sei es Marketing, Dokumentation, Support, Qualitätssicherung, Lokalisierung und Webseite – unzählige Ehrenamtliche einbringen, trägt die Hauptlast der Entwicklung seit Jahren das übernommene StarDivision-Team in Hamburg.

Viele Prozesse, Tools und Kommunikationskanäle blieben daher auf Mitglieder des Hamburger Teams zugeschnitten und manchmal auf sie beschränkt. Ein Teufelskreis: Weil die meisten Entwickler ohnehin in Hamburg saßen, sah man wenig Grund, etwas daran zu ändern – und weil sich wenig änderte, blieb die Beteiligung unabhängiger Entwickler gering. Ein weiteres Hemmnis war die obligatorische Abgabe einer schriftlichen Copyright-Assignment-Erklärung, die selbst bei unbestritten wertvollen Codebeiträgen zu wochenlangen Verzögerungen bei der Aufnahme in den Hauptentwicklerzweig führten. Darüber hinaus begannen Entwickler und Drittfirmen die darin innewohnende Asymmetrie zunehmend kritisch zu hinterfragen. Insgesamt führte all dies dazu, dass sich das OOo-Projekt zehn Jahre lang schwertat, freiwillige Entwickler zu gewinnen und bei der Stange zu halten. Daher blieben viele für Attraktivität, Wartbarkeit und Verständlichkeit des Codes notwendige Änderungen aus.

Mehr Infos

Fahrer-Assistenz

Schon seit Jahren enthält die Codebasis Unittests, besonders im Bereich des Komponenten-Frameworks UNO sowie einiger neuerer Basisbibliotheken. Entwickler nutzten diese aber häufig nicht ihrem Potenzial entsprechend oder übersetzten sie sogar überhaupt nicht. Insbesondere ließ sich bislang der eigentliche Applikationscode, beispielsweise der Formelparser in Calc oder das Layout im Writer, in der Regel wegen weitgehender Wechselbeziehungen mit anderen Codeteilen nicht via Unittests absichern. Eine Gruppe von LibreOffice-Entwicklern ist derzeit dabei, diese fundamentale Beschränkung zu beheben – beispielsweise schreiben sie für Calc mittlerweile bei Änderungen am Formel-Parser in der Regel sofort einen Unittest, um Regressionen in diesem sensiblen Bereich zukünftig zu vermeiden. In beiden Projekten, sowohl in LibreOffice als auch in OpenOffice.org, lassen sich mittlerweile Unittests der Codebasis nutzen. Bei OpenOffice.org ist dies leider derzeit noch kompliziert: Einige Unit-Tests laufen beim eigentlichen Bauen durch, andere muss man via subsequenttests nach einem erfolgreichen Build ausführen. LibreOffice führt Unittests grundsätzlich beim Bauen aus, zusätzliche Tests kann man via make check starten.

Demgegenüber hat die Document Foundation das Ziel, eine aktive Entwicklergemeinschaft mit einer Mischung aus angestellten und ehrenamtlichen Entwicklern aufzubauen. Wichtig war es daher, die Einstiegshürden deutlich zu senken, und ein Klima zu schaffen, in dem sich Entwickler auch dauerhaft wohlfühlen. Dazu gehören:

  • Die Chance, gleich beim ersten Versuch einen lauffähigen Build zu erhalten, sowie ein einfacheres, an etablierten Standards anderer Open-Source-Projekte orientiertes Build-System.
  • Schnellere Turnaround-Zeiten: Keine Klimmzüge, um vom geänderten Code zum Binary zu kommen. Gerade Einsteiger stolperten oft darüber, dass ein OOo-Build ein Installationsarchiv liefert und man das Programm nicht direkt daraus starten konnte.
  • Bessere Code-Übersicht: Ohne detaillierte Kenntnisse des Codes können sich Einsteiger kaum zurechtfinden. Eine Liste gängiger Abkürzungen, Unterprojekte, eine generierte, detaillierte Dokumentation ausgewählter Subsysteme, Integration von zwei gängigen Sourcecode-Indexierungstools direkt in den Build-Prozess (GNU id-utils sowie ctags) sollen Quereinsteigern viel Frustration ersparen.
  • Aufräumen des Codes: Viele Details erschweren den Einstieg. Dazu gehören auch nach zehn Jahren noch deutsche Kommentare, mehrfach vorhandene Funktionen wie vier String-Klassen, Altlasten wie makrobasierte Containerklassen sowie große Mengen auskommentierten Codes. Hier steht viel Fleißarbeit an, die sich aber perfekt als Einstiegsaufgabe für Neuankömmlinge eignet – und etablierte Entwickler dürften es begrüßen.
  • Continuous Integration: Einzelne Entwickler bauen auf ihren Maschinen den jeweils aktuellen Code ständig durch, und schicken bei Fehlern den letzten Committern eine E-Mail – so ist trotz teilweise großer Änderungen auch der aktuelle Entwickler-Zweig (fast) immer baubar. Darüber hinaus sind ähnlich wie beim Mozilla-Projekt nächtliche Builds geplant.
  • Kein obligatorisches Copyright-Assignment: Stattdessen akzeptiert LibreOffice Code unter der Lesser GPL v3-Plus-Lizenz sowie der Mozilla Public License MPL 1.1. Zukünftig lässt sich der Code auch unter neueren Versionen obiger Lizenzen veröffentlichen.
  • Mehr Austausch: Ein Entwickler-IRC-Kanal sowie eine -Mailingliste, auf denen quasi zu jeder Tages- und Nachtzeit jemand mit Rat und Tat zur Seite steht, soll Neuankömmlingen das sonst sehr frustrierende Warten auf Hilfe ersparen.

Code nimmt LibreOffice – ähnlich wie beim Linux-Kernel und anderen Projekten – am liebsten in Form von Patches auf der Entwickler-Mailingliste entgegen und diskutiert ihn dort. Im Erfolgsfall erfolgt – oft innerhalb weniger Stunden – durch einen der Kernentwickler der Commit im Namen des Patch-Autors. Hat sich ein neuer Entwickler bewährt, kann er auf Wunsch gerne direkte Commitrechte auf die Git-Repositories erhalten.

Insgesamt konnte das Projekt mit diesen Maßnahmen seit Ende September rund 70 neue Kontributoren hinzugewinnen. Teilweise kehrten Entwickler, die OpenOffice.org vorher verlassen hatten, zum LibreOffice-Projekt zurück. Über alles gesehen haben seit Ende September bis dato etwa 160 Entwickler direkte Code- oder Übersetzungsbeiträge zu LibreOffice geleistet, eine Zahl, auf die das Projekt sehr stolz ist.

Die dem LibreOffice-Projekt zugrunde liegende Philosophie heißt Änderungen willkommen – sollte ein Patch einmal eine Regression verursachen, so wird diese entweder schnell behoben, oder die Änderung zurückgenommen – in jedem Fall aber legen die Kernentwickler viel Wert auf Agilität, und halten wenig davon, coole Features zurückzustellen, bis sie zu hundert Prozent fertig sind. Dahinter steht die Überzeugung, dass Software ohnehin nie wirklich fertig wird und eine schnelle Integration von Code die Motivation der Entwickler fördert – Herummäkeln und Zurückstellen bewirken dagegen eher das Gegenteil.

Damit hat sich das LibreOffice-Projekt ganz klar der Basar-Philosophie der Open-Source-Entwicklung verschrieben, im Gegensatz zur vormals doch eher einem Kathedralenbau ähnlichen Sichtweise. Die Beteiligten haben die Hoffnung, damit ähnlich Erfolg zu haben wie andere große Open-Source-Projekte, beispielsweise das Linux-Kernel-Projekt. Da ein Fork immer Anlass für Unstimmigkeiten ist, sollte er das letzte Mittel bleiben. Aber die Option, den Code unabhängig vom Originalautor weiterzuentwickeln, ist elementarer Bestandteil des Open-Source-Modells.

arbeitet als Open-Source-Programmierer für Novell und ist Gründungsmitglied sowie Mitglied des Steering Committee der Document Foundation.

engagiert sich seit vielen Jahren ehrenamtlich für freie Software und ist als ehemaliger Marketing Project Lead des OpenOffice.org-Projekts Gründungsmitglied sowie Mitglied des Steering Committee der Document Foundation.

Alle Links: www.ix.de/ix1102088

Mehr Infos

LibreOffice selber übersetzen – erste Schritte

Ein selbst übersetztes LibreOffice lässt sich am einfachsten unter Linux realisieren, da hier von der gesamten Build-Umgebung fertige Pakete existieren, die man gegebenenfalls nur nachinstallieren muss. Für einen Einstieg in die LibreOffice-Programmierung ist der eigene Build der empfohlene Weg. Zunächst einmal sind alle benötigten Tools und Bibliotheksprojekte einzuspielen:

sudo apt-get build-dep openoffice.org # Debian & Ubuntu
sudo zypper si -d OpenOffice_org-bootstrap # für OpenSUSE
sudo yum-builddep openoffice.org # für Fedora & derivatives

Danach gilt es, den Quellcode aus der Versionsverwaltung auszuchecken:

git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo 

Das Übersetzen erfolgt dann in drei Schritten:

cd libo ./autogen.sh (--with-num-cpus=num falls mehrere Cores zur Verfügung stehen) 
make
make dev-install

Nach erfolgreichem Durchlauf befindet sich nun eine lauffähige Installation von LibreOffice unterhalb des ./install-Verzeichnisses. Beispielsweise startet

cd install/program 
../ooenv
gdb --args ./soffice.bin -calc

LibreOffice Calc direkt im Debugger.

(avr)