A "Fork" of OpenOffice.org? What the hell?

As Miguel rightly notes,

For years we have been shipping a patched version of OpenOffice because the release schedule of OpenOffice did not match our release schedule. In the very same way that Linux distributions have to ship patches against vanilla packages because the release schedule of those packages does not necessarily match the release schedule of a distribution.

It's quite normal for a distribution to include patches against upstream sources, for all kinds of reasons. As long as these patches are intended to be eventually merged upstream, there's no room to talk of a fork. Even a patch which is carried by a distro after being rejected by upstream does not create a fork. To have a fork you must create a situation where a 3rd party that writes a new, unrelated patch (with a new feature or whatever) has to write different code for the two versions (the upstream vanilla version and the patched distro version). If both versions are popular, some people will write for one and some for the other, and the two will grow farther apart, creating a fork. Even that's a borderline situation, since most of the code is still developed at a single location.

Adding support for a new file format doesn't create a fork. I think what PJ means is not a technological fork but a kind of mindshare-fork, where people who use Novell-OO.o get a (wrong) perception that it is special and distinct from the vanilla OO.o present in other distros, even though it isn't. The same plugin, if it successful, will be available in most other distros too, perhaps in a package separate from OO.o. But people will perceive Novell-OO.o as special, just like Novell and MS hope they'll perceive Novell's Linux as special, even though the actual free software in it is much the same as that in any other GNU/Linux distro.

Well, making people think your generic product is special is a standard part of selling it. At the far end it may shade into FUD, which is an unethical PR tool. But Groklaw's coverage here also smacks of FUD, because it is worded in an unclear and deceptive fashion. PJ should have explained just what her usage of "forking" (quotes in original) means. Because if it means ordinary forking of code, it's completely wrong. Many people have raised this issue, both in blogs and in comments on the linked Slashdot story, and I very much hope PJ will post a response, because this story has considerably tarnished Groklaw's reputation in my eyes.

Anyway, leaving the matter of forking aside for the moment, what does PJ see as the actual harm resulting from Novell developing this plugin? There's a thread on Groklaw starting here where people say things like:

It says they are working on translators! And the press release title says that they will support Open XML - what on earth is wrong with that?

And:

Doesn't this actually hurt Microsoft, by making it easier for businesses to move to ODF?

Since the responses aren't front-page, I wanted to expand on them here. Microsoft could easily produce their own OO.o plugin for OpenXML if that benefited them somehow. So the existence of the plugin isn't at issue here. Its inclusion and marketing by Novell - a major Linux distro and support provider, all the new-found antipathy towards it notwithstanding - could be a problem. It could divert people who try to migrate away from Windows to the newly formed MS-supported-not-quite-free-Linux camp.

In other words this is the exact same problem as Novell joining forces with Microsoft to begin with, not something new at all. PJ's use of "forking" confused and angered a lot of people, including me, and as a result I didn't grasp her meaning right away.

What else is interesting about this plugin? Well, PJ proposes that the conversion won't be quite perfect, because Microsoft won't publish (or let people use freely) all the information necessary to make a full OpenXML reader/writer. That's quite likely. Is it a problem? Yes, just like the fact that OO.o's current binary MS Office format support is far from perfect: it makes it hard or impossible for heavy MS Office users (as in, organizations with huge MS Office-format archives) to move to OO.o. It's especially hard to use a mixed OO.o / MSO environment, and to exchange documents between different companies or persons who use the two programs - data is constantly lost on conversion.

But would it be better if there was no OO.o OpenXML plugin, preventing people from moving away from MSOffice 2007 installations at all? Especially with a free, non-perfect OpenDoc plugin for MSOffice already available? I don't think that's possible. This plugin is too easy to write, with the OpenXML specs more or less available to the public. People want to migrate from MSOffice to OO.o, so if this plugin wasn't written by Novell or whoever else is working on it, someone else would certainly have published their own by now. Every corporate MSOffice user benefits from its existence, even if they don't actually use it, as a sort of safety net in case they have to stop using MSOffice in a hurry or exchange docs with a partner who uses OO.o. The same thing applies in the other direction - the odf-converter project is an (apparently) bidirectional filter.

Yes, the plugin can and will be used to imperfectly process MSOffice-generated documents. Microsoft will want to use this to give OO.o a permanent second-rate citizen position in a Microsoft-based network in order to reduce the risk of that network moving entirely to Linux. They want to be seen as making a concession, joining forces with Novell and supporting Linux and OO.o a bit more, while their real goal is to keep OO.o - MSOffice compatibility at a not-quite-perfect level. Perfect compatibility makes it too easy to migrate away from MSOffice, while zero compatibility makes the need to migrate too obvious, gives MS a bad image in the eyes of the likes of the EU, and is an unstable situation anyway - someone else is sure to write such a plugin. This way Microsoft and Novell at least keep some control over its development and quality.

So to sum up, a perfectly working converter outside the influence of Microsoft would obviously be better. But since we can't have that, and we can't avoid having some plugin in the long run, this one will have to suffice. Whatever marketing Novell and MS may bring to bear, it can't be as bad as a hypothetical world where no OpenXML - OpenDocument converter exists at all.