What will it take to merge LibreOffice and OpenOffice?

Off the Beat: Bruce Byfield's Blog

Mar 25, 2015 GMT
Bruce Byfield

Ordinarily, I'm all for diversity in free software projects. However, I make an exception in the case of LibreOffice and OpenOffice. The sooner they become a single project, the better.

In other cases, I'm slow to accept arguments against duplication of projects. Combining projects does not automatically make for greater efficiency or quicker development; especially in the beginning, personalities can sabotage or even reverse any gains.

Besides, having more than one project encourages innovation, both from increased competition and from the fact that more perspectives find their way into development. I would never, for example, urge that Calligra Suite merge with LibreOffice, because their approaches to the office suite are very different, and a merge would likely lose features from both.

But LibreOffice and OpenOffice? Not only do they share megabyte upon megabyte of the same code, but five years of separation have brought so few visible changes that even an expert has trouble telling them apart without glancing at the title bar. Users might notice an efficiency here or an improvement there, but the major differences are at the code level and out of sight.

Moreover, as Jonathan Corbett points out in a subscriber-only article at LWN, OpenOffice suffers from a serious shortage of contributors. According to Corbett, OpenOffice has sixteen developers total, who made two releases in the last year. By contrast, LibreOffice has 268 developers, and has made fifteen releases in the last year.  

Yet despite this advantage, for all that LibreOffice has done to clean up the code and improve the interface, so much remains to be done that it seems clear that even 268 developers are not enough to finish such improvements any time soon -- let alone to develop much needed improvements such as table and chart styles.

Under these circumstances, what practical value could maintaining two such similar projects possibly have? Granted, OpenOffice began with a code audit, and, having made less radical changes than LibreOffice, seems somewhat stabler, but what is the value of having it struggle through releases, when even LibreOffice's numerical superiority is apparently inadequate to the task?

Obstacles to Unity
A merge would probably involve time-consuming comparisons of the two code bases. However, the obstacles to unity seem far more political than practical. As Corbett notes, IBM accounts for at least 60% of the contributions by changeset to OpenOffice, while Red Hat and Collabora Multimedia about 68% of the contributions to LibreOffice. Although Corbett makes no conclusions about these figures, the obvious inference is that the division might be partly due to corporations jockeying for position -- although for what reason is obscure.

Just as importantly, the division seems to reflect personal animosities on both sides. The animosity may be partly due to the fact that LibreOffice forked from OpenOffice.org after Oracle acquired the code from Sun Microsystems.

However, the division runs deeper than that. LibreOffice was started partly by members of Go-oo, a group of SUSE-centered developers who developed a semi-official fork that began releasing its own versions of OpenOffice.org in 2007. Go-oo's main reasons for existing were dis-satisfaction over the rate of improvement in OpenOffice.org's code, and the control which Sun Microsystems maintained over OpenOffice.org. The group's innovations were so popular that what many distributions branded as OpenOffice.org was actually its releases.

When LibreOffice forked, GO-oo members tended to go with it, while OpenOffice.org loyalists stayed with OpenOffice. At this point, the chances of outsiders comprehending the issues are slim, but what matters is that some of the personal divisions could be eight or nine years old, and that many have taken on a life of their own.

What these personal and possibly corporate feuds mean is that, for unification to succeed, it must allow everybody involved to save face.

Even the question of what the new project might be called is full of potential for disrespect. Would the combined project be called OpenOffice, taking advantage of the brand recognition built up in the fifteen years since the OpenOffice.org source code was released, but ignoring LibreOffice's wealth of contributions? Or would it be called LibreOffice, and disregard the history of OpenOffice and OpenOffice.org before it? Or if a new name is chosen with less history, what could it possibly be?

Maybe the two names could stand for different stages in the release process, just as Sid is always the code name for Debian's Unstable repository. But which would be the staging repository, known mostly to contributors, and which would be the official release by which the unified project would become known to the public? I have no inside information, but just recognizing the situation immediately brings the potential issues to mind. Discussions about Anglican-Catholic unity seem more likely to succeed.

And that's just the name. Imagine the same need for face-saving with each chunk of code.
Still, every now and then, a hopeful sign emerges. Originally, for instance, LibreOffice used the GNU Lesser GPL license. Since the Lesser GPL is compatible with OpenOffice's Apache 2 license, but the Apache 2 license is incompatible with the Lesser GPL, that meant that LibreOffice could use OpenOffice's code, but that OpenOffice couldn't use LibreOffice's code.

However, for the last few years, new LibreOffice code has been licensed under the Mozilla Public License, which is compatible with the Apache 2 license. Could some LibreOffice officials be quietly leaving the door open for a merger?

We can only hope. Relations between the two projects seem overdue for some common sense.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More