Over the past few weeks we’ve seen a considerable flurry of activity – from a variety of perspectives – concerning the State of Massachusetts’ intention to mandate the OASIS Open Document Format standard as the default file format for its internal office productivity work. This entry is not intended to be yet another commentary on that decision, but rather a discussion of a related but distinct issue of its own. Astute readers might have noticed that most of my arguments vis a vis the Massachusetts matter (see here or here) are predicated on the idea that the Open Document Format is a critically important development for customers of office productivity software the world over, not to mention ISVs (Microsoft included [1]).
The main issue that critics of this position are likely to cite is adoption; the format is next to irrelevant, or so the argument goes, because it’s but a speck marketshare-wise next to the dominant file format of the past few decades – the Microsoft Office binary formats. While this is a legitimate assertion presently (and just as applicable to the forthcoming Microsoft Office Open XML formats, incidentally), given that the ODF is but newly minted and thus early on in its lifecycle, I take exception to this argument as a limitation of the ODF generally.
With the advent of the Open Document Format as well as its Microsoft Office Open XML counterpart, we’re at a critical juncture in the development of office productivity software – the proverbial fork in the road, if you will. The common element to either path is XML, because whatever route is chosen XML is going to be the basis for office productivity going forward. Nor is the critical factor openness, because although some parties external to Microsoft might (strenuously) disagree with me, I currently believe that both the ODF and the Office Open XML formats are open enough to work with. [2] The critical distinction, in my view, lies in the control of the format itself. On the one hand, we have the OASIS standard which is participated in by the likes of Adobe, IBM, and Sun, and on the other we have a format owned and controlled by Microsoft. It is my belief that over the longer term, a format owned by none and controlled by many is likely to be a better bet for interoperability and customer choice than a format controlled by a single commercial entity. Arguments against this position that focus on the adoption today seem unnecessarily fatalistic, in my view.
The point here is not to debate the relative merits and limitations of the formats themselves, nor to claim that Microsoft should abandon its Office Open XML formats which are undoubtedly required for backwards compatability reasons alone. It is instead to establish context. With some exceptions, when considering the storage medium for office productivity content longer term, my general recommendation for enterprises and governments alike is to proceed with the option likely to give them the most choices in the future, which I believe to be the ODF.
The argument really is not all that complicated:
- If it’s true that choice and interoperability are good for customers,
- And it’s also true that the Open Document Format is likely to provide more options with respect to choice (this is the point of contention for most ODF critics),
- Then logically it follows that the Open Document Format is crucially important for said customers.
If one accepts that – and there are many Microsoft employees or advocates who will not, despite the fact that the ODF is as Bob Sutor has noted absolutely not an anti-Microsoft format – then the OpenOffice.org (OO.o) organization gains a new importance. It’s not that the ODF is tied to any particular organization or product – quite the opposite, in fact – but rather that it’s imperative that the ODF has a strong, freely available reference implementation behind it. This is particularly true given the questions currently being raised about adoption and whether or not it’s actually a “standard” because “no one’s actually using it.”
To date the most visible of the projects behind the Open Document Format has been OpenOffice.org’s office productivity suite. Having used the OO.o suite as my primary authoring environment full time for better than a year and a half, even for externally received Microsoft Office spreadsheets, text documents and presentations, I can say that OO.o is a very capable product. It is not, in my opinion, the equal of Microsoft’s product, but for the majority of users it will more than suffice and it does offer features that Microsoft does not – PDF export, for one. The ODF, however, needs OO.o and other implementations to do more than meet the needs of users, however: they must exceed them, and provide customers with features they’ve never had before.
With all due respect to the engineers that have done excellent work on the OO.o and Star Office products, however, that is a challenge that no single organization can credibly meet. It is, instead, a challenge requiring a broad based, community oriented effort. An ecosystem. That basic assumption, in turn, is leading me to recommend that Sun seriously consider both the creation of an independent OpenOffice.org foundation and the donation of the OO.o codebase to said foundation.
To be clear, I’m far from the first to issue such a recommendation. The agument’s been making the rounds within the OO.o community for better than two years, from what I’m told. So why do I feel the need to make the argument now? Because I perceive three relatively pressing issues that are lending the issue a sense of urgency.
- First is the aforementioned Office Open XML format. Currently not publically available, with a public beta months away, now is the time to demonstrate the independence of OO.o from a single commercial entity, and give the ODF the credible reference platform is requires. While the ODF is compelling on its own, as demonstrated by the Massachusetts decision, it’s also true that a stronger, independent OO.o could only strengthen the case for the format itself. The status quo, however, favors Microsoft and once organizations begin to head down the Office Open XML path it will be difficult to convince them to backtrack to the ODF.
- Second, the potential for a fork in the OO.o codebase is a concern. We’ve already seen one in the variation of the codebase that IBM employs in its Workplace product, and while any and all such forks would undoubtedly preserve their support of the ODF, they represent an unnecessary fragmentation and duplication of effort. Far better for all the parties to contribute to a common base and differentiate with addons, plugins, service/support and the like. I’m also told that some of the downstream minor derivations of the OO.o codebase, such as Novell’s, are maintained within the actual OO.o CVS system – making the overhead associated with a fork minimal indeed.
- Lastly, we’ve heard a couple of minor grumblings recently that potentially significant new features requested by community members have gotten lost in the shuffle with the push towards Open Office 2.0. While there are many reasons for such decisions, and doubtless some of the requests were not realistic, it has given the impression to some that OO.o is less than responsive to the needs of its supporting community. Whether it’s fair or not, this impression acts to dampen the interest from various community members (driving them to competitive projects in the process), and also limits the infusion of fresh blood and direction into the OO.o roadmap. As Microsoft begins to drive features like VOIP into their office suite, it will be necessary for OO.o to respond in an agile fashion. It’s my belief that an independent OO.o would be more conducive to fostering external participation than the organization as currently constituted.
The next major question is: if Sun was willing to consider such potentially pushing OO.o to a foundation, what form should the resulting foundation take? What’s an example that can be used as a template to work from? While it’s perhaps not the one they would have picked, given the history, I personally believe that the Eclipse foundation is a model well worth examining. The similarities in terms of positioning are there, and I even think the technical plugin framework that Eclipse has established might be worth emulating. Just as OO.o is closely held by Sun, so too was the codebase at the core of Eclipse held by IBM. By pushing Eclipse towards greater levels of independence the foundation has fostered perhaps the most compelling ecosystem of third party projects this side of the Linux kernel. If anyone has other examples they feel would be instructive, I’d be happy to be sure that they get in front of the right people.
But as much as it might make sense to the Open Document Format and the OO.o community for Sun to make such a transition, it has to be in Sun’s best interests as well. So what are the incentives for Sun? Well, I think the Eclipse example could be instructive in this regard, as IBM seems happy with the decision, but more specifically:
- Ubiquity: Sun’s Simon Phipps is fond of saying that the commercial opportunity in open source lies in monetizing ubiquity, a point that I for the most part agree with. In my view, OO.o has a far greater shot at ubiquity as an independent entity contributed to but not controlled by Sun. We’ve been told on a few occasions by potential Star Office customers that the package is a difficult sell to C-level executives, because they feel – rightly or wrongly – that it’s a matter of Sun trying to compete on equal footing with Microsoft. Should OO.o become a foundation, this objection changes dramatically, as it’s at least possible, perhaps even likely, that we’d see additional contributors come online quickly. And how much more compelling is Eclipse now versus when it was just a codebase maintained by IBM?
- Distribution of Costs: While it’s certainly true that the creation of an independent foundation is not without its own set of significant upfront costs, these costs likely pale when compared to the long term ongoing resource investments required to singlehandedly develop, maintain, market, and distribute the codebase against a dominant incumbent like Microsoft. A foundation would potentially allow Sun to ammortize some of the costs for these efforts across a number of commercial participants. There are folks out there that have done a tremendous amount of work refactoring and componentizing the OO.o code base, and while the transition of OO.o to a foundation certainly wouldn’t guarantee that those changes would or could be submitted back, it certainly would remove one potential barrier.
- Control: Conventional wisdom would have one believe that by pushing OO.o to an independent foundation they’d be relinquishing control over the projects to competitors, and while that’s partially true I believe that obscures two important issues. First, that Sun would still be employing the majority of the resources (with one possible exception) intimately familiar with the codebase, and thus would still be sitting in driver’s seat to some extent – much as IBM was (and, some would argue, still is) with Eclipse. Second, by relinquishing control, Sun would immediately decrease the possibility of a potentially damaging fork. If we agree that some control over a centrally important project is better than total control of one in a series of forked projects, that’s a good thing.
To put all of this in simple terms, I think that the transitioning of OO.o to an independent foundation is not only necessary, but as much a win for Sun as it is for the OO.o community, the ODF, and the customers of all of the above. I believe Sun should be commended for their efforts that have provided the free and open source communities with a credible office productivity suite, but I think that just as Eclipse needed outside help to take the next step, so too will OO.o. That this is of critical importance to the ODF itself cannot be debated, and I think the available evidence indicates that it would be a net benefit to Sun as well. Sun has, in my opinion, earned the right to call on others to help carry the load and give the ODF the strong reference platform it requires. I for one hope they’ll ask for that help. But what do you all think?
[Standard disclaimer]: Of the entities mentioned, Adobe, Eclipse, IBM, Microsoft and Sun are RedMonk clients, while Novell is not.
[1] Microsoft would likely have an even larger market opportunity than they do currently were they to support the ODF; outside of Massachusetts, the EU and geographies further abroad have expressed strong interest in – and in some cases, a commitment to – the ODF. Supporting the format, I’ve argued before, would give them the ability to compete in accounts like MA that have mandated the ODF; something I believe they could do quite effectively. In addition, they could position themselves far more convincingly as pro-open standards and competition, something that likely would not hurt their chances in court with the EU.
[2] It would seem that Jon Udell agrees, with his piece here, but I’m hearing chatter that indicates that the transformation from ODF to MSXML and back may not be quite as seamless as we all expect. Will have more on that when I know more.
