On 25 January 2011 The Document Foundation (TDF) published LibreOffice 3.3, the first stable release of the OpenOffice.org fork announced on 28 September 2010. It is the first moment at which code maintained outside the official OpenOffice.org tree — the Go-oo patches and those accumulated by the Linux distributions — comes back into a single source that builds and ships as a finished product.

Context

Until then OpenOffice.org was the reference tree for the free office suite, developed under the control of Sun Microsystems and then of Oracle, after the acquisition closed in January 2010. A pragmatic fork had existed around that tree for years, Go-oo, maintained mainly by Novell since 2007: inside it were more complete import filters for Microsoft formats, stability fixes and features that upstream either rejected or integrated on unworkable timescales. In parallel, every Linux distribution applied its own set of patches to the OpenOffice.org build it packaged.

The result was de facto fragmentation: a Fedora user, an Ubuntu user and someone downloading the binary from openoffice.org started from different sources while reading the same version number. The 28 September 2010 fork turned that informal situation into a formal structure. TDF was born as an independent foundation based in Germany, invited Oracle to take part — an invitation that was declined — and brought along much of the team already working on Go-oo and on the distribution packages.

What 3.3 contains

LibreOffice 3.3 starts from OpenOffice.org 3.3 — at the time still in beta on Oracle’s side — and grafts on top the work that until then lived outside the tree. The features TDF flags in the release announcement are largely the ones that came in from those external branches:

  • SVG file import and editing in Draw;
  • title-page formatting and numbering in Writer;
  • import filters for Microsoft Works and Lotus Word Pro;
  • better sheet and cell handling in Calc;
  • a PDF import extension and the Impress presenter console shipped as standard;
  • a reworked report builder.

To these are added the new features coming from the OpenOffice.org 3.3 branch: handling of custom document properties, embedding of standard fonts in generated PDFs, up to one million rows per Calc sheet, extra CSV import options, hierarchical axis labels in charts, coloured sheet tabs.

The components remain the historical six: Writer (word processing), Calc (spreadsheets), Impress (presentations), Draw (vector drawing), Base (database frontend), Math (formulae). The native format is OpenDocument Format (ODF), standardised as ISO/IEC 26300; import/export of Microsoft formats (DOC/DOCX, XLS/XLSX, PPT/PPTX) inherits the filters that came in from Go-oo directly.

The critical point: a single build and inherited code

The most interesting aspect of 3.3 is not a visible feature but the fact that the tree is one again. Keeping three overlaid layers of patches — upstream, Go-oo, distribution — means porting and testing every fix against different combinations, and accepting that the same bug behaves differently depending on the build that hosts it. Reuniting the sources removes this cost that returns at every release and makes the same base verifiable by anyone, regardless of the package.

The operation also touched packaging: TDF reports having merged the various language versions into a single build, cutting the size of the Windows installer considerably compared with shipping per language. It is a distribution-logistics detail, but one that bears directly on the work of those who package and those who keep mirrors running.

On the legal side, the fork does not hold the copyright to the original OpenOffice.org code and so cannot relicense it at will: it must distribute the whole under the inherited terms. New contributions are accepted under the LGPLv3-or-later licence, a choice that fixes the terms within which the codebase can evolve without depending on the decisions of the original copyright holder.

Governance implications

The stated reason for the fork is procedural, not technical. In the months after the Sun acquisition the community observed some of Oracle’s decisions on other inherited open projects — among them the effective halt to OpenSolaris in August 2010 — and chose to set up an independent foundation before the same thing happened to the office suite. It is a precautionary fork: the TDF structure — a board elected by the community, membership open to individual contributors as well, its own infrastructure for repositories and bug tracking — is designed not to concentrate control in a single company.

For anyone weighing adoption, the fact that counts is that the centre of gravity of development has shifted. The Linux distributions that already packaged OpenOffice.org with their own patches now have an upstream that integrates that work by construction, instead of receiving it as an external change to reapply at each release. As of January 2011 Oracle’s position on the remaining OpenOffice.org branch is not yet publicly defined, and this opens a phase in which two trees born of the same code proceed in parallel.

Limits

A first release after a fork also inherits the defects of the starting code. 3.3 starts from an OpenOffice.org 3.3 beta, not the final Oracle version, and part of the legacy-code clean-up is still under way. The fidelity of the Microsoft filters, however improved over the official tree thanks to Go-oo, remains a matter of approximate compatibility: conversion of documents with complex formatting has to be checked case by case, not taken for granted. Finally, the continuity of the fork rests on a transition of developers and infrastructure carried out in a few months; its solidity will be measured on the maintenance releases that follow, not on this first publication.

Cover image: Horizontal flat-style “LibreOffice” wordmark logo on a transparent background — logo by Christoph Noack, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:LibreOffice_Logo_Flat.svg