LibreOffice and OpenOffice.org: Missing the Big Picture

For once I will forego a principle of mine and comment on a subject that I'm not immediately involved with: namely the conflict between the communities of OpenOffice.org and LibreOffice.

For readers that don't normally read Planet KDE, I think you will forgive me if I make some references to KDE organizations and applications. Readers that are not interested in OpenOffice or LibreOffice but only in topics related to KDE can stop reading here.

Background

As most of you know by now, Oracle has donated the code of OpenOffice.org (OOo) to the Apache Software Foundation (ASF). Previously it was owned by Sun and later Oracle and released under both a proprietary and an (L)GPL license. Now it will become licensed under the Apache Software License (ASL) only.

LibreOffice (LO) was forked from the LGPL'ed version of OpenOffice.org some 8 months ago, while also creating a new organization for this: the Document Foundation (TDF). During this time the LibreOffice community has worked on cleaning up the source code, integrating features from another fork, (Go-oo, which was used in most Linux distributions), merging features from subsequent versions of OpenOffice.org and also creating new features themselves. They have a healthy community going with a number of core developers (mostly employed) and a large number of volunteers. There is also work on creating a real foundation much like the KDE e.V in Germany, and they received substantial donations to this goal.

To put it mildly, the LO community is not happy about the move of Oracle. Here are some points that are being made:

• the donation to ASF is only made to further the agenda of IBM, since IBM is basing their application Symphony on the code of OOo.
• the move to donate to the ASF is done to weaken the LO community now that it is starting to see some success.
• the code should have been donated to TDF instead since they have all of the community behind them.

I personally don't think many of these points are valid. They have been debunked by clarifications on the Apache mailing lists in ways that at least I think are valid:

• The donation was made to ASF instead of TDF because of two main reasons: TDF is incorporated in Germany while ASF is American. Since Oracle is an American company and since the laws are what they are, Oracle would only be able to get the substantial tax deduction that they will if the donation is made to an american foundation, and the TDF uses a license that Oracle didn't want to use (more about this below).
• I think that LO indeed has a very healthy community, and it is growing week by week. However, it is self-selected from those that prefer the (L)GPL before other, more permissive, licenses. This means that LO only has the part of the community that is visible, not the actual whole community.
• I believe that Oracle doesn't really take TDF seriously. TDF and LO is really big in the Linux community, but most of the OOo users are actually on Windows. I seem to remember that less than 10% of OOo users are on Linux, but I would be grateful for corrections here. I also believe that Oracle doesn't take the Linux desktop community seriously, or at least that they think it is irrelevant to their goals. This means that I don't think that Oracle cares whether they interrupt the LO community or not.

Even though much of the fight has been about the communities, what it really boils down to is a license issue: The ASL is a so called permissive license which lets anybody do almost anything with the code, including incorporating it into a proprietary program or rerelease it altogether under a proprietary license. The GPL, on the other hand, demands that changes are either released with source code and under the same license as the rest of the application, or that they stay inhouse and are never released.

Interestingly enough, the permissive nature of the ASL lets developers of GPL code take code from a project under ASL and relicense and incorporate them into the GPL code. So the developers of LO can take all the changes that are made in OOo and put them in LO, but not the other way around.

Many community members of LibreOffice take this as proof that they are far ahead and that they will always stay far ahead. All the fixes in OOo can be merged with the LO code, but the other way around is not possible. Instead the LO fixes will have to be reimplemented from scratch unless a contributor could be persuaded to contribute to both the projects.

However, all of these considerations are missing the big picture.

The Big Picture

The big picture is that we are all together in a much bigger fight: the one between the Open Document Format (ODF) and the proprietary formats of Microsoft Office. It is petty to say that "we are ahead in this battle, and will always be" when at the same time the whole war is lost.

So here are the facts of the current situation:

1. Oracle has already made the donation, so there is no chance that they will change their mind and instead donate to TDF. The vote within the ASF to allow the donation into a so called 'podling' is well under way and it looks as if it will be a big YES. There are also over 100 people saying that they will contribute to OOo under the ASF. So it looks like OOo will indeed have a future inside Apache.
2. Many of the people listed as future contributors to OOo regard the ASL as the best license, precisely because it allows proprietary extensions or even relicensing of the project itself. Among these seem to be IBM who want to use the code as the base for Symphony. These people will not put their weight behind LO which is a GPL project.
   
3. The people behind LibreOffice will also not change their minds. For them the GPL is an important way to protect the future freedom of the code. Some of the founders have gone so far as to say that they discourage the contributors of LO to also contribute to OOo under Apache terms. While I am personally very much in favour of the GPL, I think this is a clear case of missing the big picture.

So, here we are: the community is divided into two parts, each with their own agenda but both with a very common interest and common code base (even if in different stage of refinement).

And I maintain that most of the people are missing the big picture. We need to cooperate in some way to win the war. So let's analyse where we can actually cooperate while at the same time keep our priorities in mind.

Common Ground

The most important feature that all office applications have is compatibility. It makes little sense if I produce a document that the recipient cannot load or that loses data when saved back. It is much less important if there is a common feature set in our editors or even if it renders completely the same (this is not true for all applications, of course, but for most).

I would especially stress that data loss is unacceptable.

So the most important thing is that LO and OOo can load and save the same files using the same definition: the ODF specification. As long as this is true, it doesn't matter if one or the other has more fancy features. It is, of course, necessary that they also remain compatible with the Calligra suite and other office applications that use ODF as their native format.

It is therefore important, considering the big picture, that if one of the two suites fixes a bug that introduces an incompatibility, that this fix is also implemented in the other. And not just because LO and OOo should remain compatible, but also in relation to the other ODF suites.

So I will suggest the following...

Compromise

In the Calligra Suite, we have a good separation between the so called Office Engine and the user interface. This engine has the responsibility to load, store, and save the contents of the document. It also renders the document on a canvas that can then be shown in an application for viewing or editing. The separation between the load/store/save parts and the rendering parts are not very strong, but it can nevertheless be seen.

Calligra has had great success with this separation. I think the thinking behind it can be applied to the current situation.

I think it would be of great value if TDF and ASF can agree to let OOo maintain the lower level (the Engine if you like) and then build both applications on top of this engine.

Here is my reasoning:

• The war that we are fighting is more important than the license issues. I understand that the people behind LO has little sympathy for the too permissive nature of the ASL and are firmly behind the GPL. However, this should be overshadowed by the importance of furthering the cause of ODF over the proprietary formats that the current monopoly is pushing.
• It is very important that different implementations of ODF suites remain compatible with each other. This is greatly helped if they are in fact based on the same code base. It should be more acceptable to have a smaller part of the whole appear under a license that you are not very fond of than the whole application. I think the willingness to do this could be greatly influenced by the current LO leaders, i.e. the people that form the steering board of TDF.
• It will save work if we can agree to at least have some common codebase instead of two totally different ones.

I am not familiar enough with the codebase of LO/OOo to give a suggestion of exactly which parts should be shared in this Engine and which shouldn't. But I am confident that if just the will exists to cooperate, then this should be an easy problem to solve.