Last time I wrote that the threats presented by Novell's OpenXML support plugin for OO.o don't outweigh the benefits of having such support. Even broken and partial support is still better than nothing because it enables companies to do a one-off conversion, with a manual pass if need be, to migrate away from MS Office. And it lets individuals, and companies which aren't ready yet for that migration, read evil OpenXML documents sent by other companies (or your government, in some cases).
Of course OpenXML support in OO.o can also encourage people
not to move away from MS Office, because if the metaphorical neighbours' kid who insists on using free software can read the documents your MS Word produces, he won't refuse to fix your computer. (A lucky few even have a government that wants to use open formats.) And it can also make people see OO.o as an inferior MS Office clone, because it can work with MS Office files but not as well as MS Office does itself, and it loses a bit of formatting data every time it opens them.
But by that measure we should also condemn projects like Samba and Wine. They too deliver inferior and late implementations of proprietary Microsoft technologies. I haven't heard any cries out of Groklaw that Samba betrays the free software community. (And don't talk to me about pure-Samba no-Windows networks. You could have all the same features on top of NFS or whatever if a tenth of Samba's development effort had gone that way instead. Samba's purpose is Windows compatibility, period.)
And what about the existing partial and inferior support for the MS Office .doc .xls etc. formats in OO.o and every other free office suite in existence? What about the FAT and NTFS filesystem support in Linux? I seem to remember PJ being proud of the community for such massive effort and dedication to often thankless projects of reverse engineering.
Well, yesterday Groklaw ran a new piece about the threat presented by OpenXML support, written by Georg C. F. Greve of the FSFE (FSF Europe). It relies on this post by Bob Sutor of IBM. So what do they tell us?
First they explain why free software, and in fact anyone other than Microsoft, will never be able to fully or correctly implement OpenXML. The spec is just too damn long and complex and looks like a dump of MS Office internal state. (Basically just like the old binary Office formats, but with XML tags instead of ASN.1 or whatever meta-format they have there now.) No argument from me so far.
Then Bob says:
[O]ther products and software, in practice, will NOT be able to understand arbitrary Open XML that might be thrown at them. [...] Therefore they will only create a bit that they need and send that off [to] the only software that might understand it, namely Microsoft Office.
[...] Open XML will be nearly fully read and written by Microsoft products, but only written in subset form by other software. This means that data in Open XML form will be largely sucked into the Microsoft ecosystem but very little will escape for full and practical use elsewhere.
Samba and Wine are bad comparisons here, because they deal with services, not data. So let's look at the example of reverse-engineered support for binary MS Office formats, or ".doc" for short. Does it create a situation where data only moves to MS Office and not from it?
In my experience, precisely the opposite thing takes place. Because the support is imperfect, people don't export data to MS Office unless they can't help it. If they want to send a read-only file, they use PDF or HTML. If they have to send an editable file, they still try to use RTF or some other least-common-denominator. If they have to keep up a high-volume traffic in editable "word processor" files... well, they're in trouble. There's no really good solution, which is why ODF was developed to begin with.
But my point is that the far more frequent use of .doc support in OO.o is for reading MSWord files, not writing them. (Especially since MSOffice users often have a bad, offensive habit of emailing Word files which aren't intended to be edited and could be replaced perfectly well with, say, PDFs.) Besides, read support came first and generally stayed better than write support (though this may not be the case with OpenXML support, since the converter is based on more or less bi-directional XSLT transforms).
For this to change with OpenXML, it would first have to be very successful in the Microsoft ecosystem, largely replacing .doc. This means a complete upgrade cycle to MS Office 12 (aka Office 2007), since we can expect that the OpenXML plugins released by Microsoft for older Office versions will provide only partial support. This is what Microsoft always does with Office format changes, to force everyone to undergo a 'generational' upgrade since Office 11 (aka 2003) will not be able to edit non-trivial Office 12 files without breaking the formatting a bit every time.
Once OpenXML establishes itself in the Microsoft sector, convincing free software authors and users to regularly export OpenXML (as opposed to importing OpenXML) will still be a difficult task. Particularly with Microsoft doing the talking.
Besides, as I pointed out above, it's natural for information flow to be lopsided. Some or most of the data that moves to a badly proprietary format like OpenXML never escapes. The same goes for data that's created in that format to begin with. That's what proprietary means. We can't change that equation. We can encourage people to move to open formats, but we can't do that by supporting proprietary formats perfectly (support can't be implemented). And we can't do it by not supporting them at all (people who need to migrate WILL write imperfect translators, and we can't stop them and shouldn't try).
So in short, my position here is that most of the evils forseen by Bob are an inescapable part of the coexistence and struggle between open and proprietary formats, between OpenDoc and OpenXML. We can't prevent the converter from existing because people really do want it. We can't prevent it from being included in at least some major Linux distros as a separate package, for the same reason. (Update: if you disagree, try to keep Mono out of distros first!) We can prevent it from being included in the OO.o upstream - at least, the OO.o developers can make that decision - but that only means someone else will have to develop and support it. By all means, don't include it in OO.o. We'll see if the market demand creates a supply of support for the converter project. Maybe we'll see free word processors other than OO.o Writer include support for it, too. (Is there an app-neutral standard for format support plugins of this kind yet?)
Back at Groklaw, Georg adds this:
With OpenXML, it appears as if there will be interoperability on paper only, but in reality people will experience numerous difficulties unless they use Microsoft Office. Because most users rightly fear and loathe incompatibilities, out of a sense of false security and lack of technological background, they will often choose the dominant product, effectively punishing the competitor for the behaviour of the dominant player.
And this is different from the existing situation how? Why do you think most home users don't switch to GNU/Linux today? Essential Windows apps or games don't run on Linux; websites are IE-only; proprietary data (not just from MS Office but from Windows apps in general) can't be converted without loss; DRM-protected media isn't available; the company's Windows Domain won't let you access services with Integrated Windows Authentication. It's all about compatibility, it always has been. People make a lot of noise about the training necessary to use a new OS and apps, but that's just a distraction, a surface reason. Think of all the training necessary to switch from XP to Vista and from Office 11 to 12. The fundamental situation is that training is something you only do once, but incompatibility is something you're stuck with forever.
Georg's final argument is that governments may be confused by OpenXML's false pretensions to the status of a free and open standard, and use it instead of the truly open and standard OpenDocument. I can't argue about that; as president of the FSFE he undoubtedly knows a lot more than I do about the political situation and how it will be affected by this. But I posit that partial support of OpenXML in free software is inevitable and that we should make the best of it... as we always have.
Owner login