Home > Standards Blog

Advanced Search 

Welcome to ConsortiumInfo.org
Thursday, June 30 2016 @ 10:51 AM CDT

Email Article To a Friend View Printable Version

OpenOffice: Always the Bridesmaid, Never the Bride

OpenDocument and OOXML

Poor OpenOffice. It’s been open source for so long, and yet its adoption and market importance has always lagged far behind that of peer software like Linux – despite the fact that it’s free and implements a standard (ODF) aggressively promoted by some of the most powerful technology countries in the world. Can this ever change?

If yesterday’s announcement by IBM is any indication, the answer is “not likely,” despite the fact that Big Blue’s latest commitment to OpenOffice, on its surface, sounds like good news. The reason? It’s too little, and too late. Here’s why.  

First, let’s start with the announcement. As reported in various venues (e.g., ComputerWorld, The Register and Heise Online), IBM will be donating the standalone source code for its ODF-compliant Lotus Symphony office suite to the Apache Foundation. As you’ll recall, Oracle became the owner of OpenOffice after acquiring Sun Microsystems. After issuing various mixed signals, Oracle officially decommitted to supporting OpenOffice, and contributed the code in early June (but not the trademark) to the Apache Foundation, where it can now be downloaded under version 2.0 of the permissive Apache License.

IBM, via it’s long-time ODF representative Rob Weir, pledged yesterday to be a more consistent and supportive champion of OpenOffice. That commitment can be found in a memo posted at LWN.net, which reads in part as follows:
 
[W]e at IBM have not been exemplary community members when it came to OpenOffice.org. This wasn't necessarily by design, but for various reasons, that was the effect. Yes, we participated in various community councils, and sponsored conferences and worked together on standards. But when it came down to the code, we maintained Symphony essentially as a fork, and although we occasionally contributed code back, we did not do this well, or often.
 
We'd like to make some changes in how we do things, and the fresh
start at Apache is a good opportunity for this.
 
IBM’s code contributions themselves seem to have real value, including more user-friendly interface features and improved accessibility support. And IBM certainly can afford to dedicate enough skilled programmers to the OpenOffice project to accelerate its further development.
 
So what’s not to like?
 
The problem is that before Oracle contributed OpenOffice to Apache, its dithering annoyed the community of independent OpenOffice developers to the point that they forked the code. The version they now support is called LibreOffice, and its now hosted by an independent organization they founded for that purpose called The Document Foundation.
 
To be fair, there have always been multiple open source office suites that implement ODF. But OpenOffice always had the most credibility, due to the resources that Sun could (and did) dedicate to its development, the similarity of its look and feel to Microsoft’s Office suite, and the very large number of copies (over 100 million downloads to date) in use.
 
Still, OpenOffice never really took off the way it might have, and the reason was corporate control - Sun never set up OpenOffice under an independent foundation. Instead, it exercised a degree of control that led other companies (like IBM) that otherwise had good reasons to provide strong support to offer tepid and erratic assistance to OpenOffice instead. It also limited the number of independent developers that became involved – why, in effect, work for Sun’s unique benefit, when there are so many truly open community projects to contribute to instead?
 
And there’s the rub. Yes, it’s better that OpenOffice is now at Apache, a well-respected and important cornerstone of the open source development infrastructure with many interesting and important projects under its umbrella. And yes, it’s true that there are other open source projects (like Linux) that combine the efforts of many dedicated corporate as well as independent developers. 
 
But it’s hard to think of an example of a truly robust open source program that has two versions, one of which is a corporate supported version and the other a community supported fork. Unless the two efforts are merged (which now seems unlikely, given that OpenOffice is under the Apache License and LibreOffice is available under the GPL v.2, among other reasons)[Correction: LibreOffice is made available under a dual LGPLv3(or later)/MPL license] that means that corporate adopters will favor OpenOffice, while independent developers will provide vocal, as well as hands-on, support for LibreOffice.  
 
Whether OpenOffice has better or worse chances to predominate over LibreOffice also remains to be seen.  Linux distributions Fedora, openSUSE and Ubuntu already default to LibreOffice. And even if IBM is inclined to heavily support OpenOffice development at Apache, it’s ability to do so will be somewhat constrained. Why? Because if IBM is seen to dominate OpenOffice development, other companies may be loath to commit their own resources to the project, just as was IBM when Sun’s developmental bear hug was seen to be too oppressive.
 
All in all, it’s a real shame – the story could all have played out so differently if Sun had spun OpenOffice out years ago, or even if Oracle had contributed the code to Apache before OpenOffice community members bolted to create the LibreOffice fork.  As I have frequently noted in the past (e.g., here), open source software can grow to be a robust and enduring tree, but only if its planted in fertile ground.  For many good reasons, fertile ground means neutral ground – an independent foundation where everyone can conclude that they have more to gain than to lose by lending their efforts to achieve a common good.
 
Sign up for a free subscription to Standards Today here

 

OpenOffice: Always the Bridesmaid, Never the Bride | 0 comments | Create New Account
The following comments are owned by whomever posted them. This site is not responsible for what they say.