Microsoft, on the other hand, is ensuring that not only it won’t work on application-level interoperability regarding ODF, but also according to reports from their “ODF workshop” they held in Redmond last week, they are botching an ODF implementation to ensure everyone touching it will have a miserable life. Two examples : 1) they remove formulas from spreadsheets. I wonder how good is a spreadsheet without its formulas. 2) they add many dialog boxes to warn or ask the user, making reading/writing ODF extremely painful for users.

This is all written on the wall already.

I should have added to earlier comment that I think a lot of ODF proponents are (and have been) working with goals similar to what was described above. [Obviously, Novell is not one of these, as they insist on trying to legitimize OOXML and other technologies that put the ball in Monopolysoft’s court. It’s their time and Monopolysoft’s dollar, so I guess that’s their business.]

It’s unfortunate that Novell signed this deal in the first place. It supports OOXML because it has to. It’s a binding contract. In essence, Microsoft bought OOXML obedience from Novell.

An important situation with ODF extensions is how do you allow the positives of extensions while defending against the abuses of extensions? Some of the larger corp backers of ODF have leaned towards being lenient. This reminds me of ISO. It’s a bit informal among friends and everything mostly works until Monopolysoft shows up and exploits everything possible to game the system. Will we wait to toughen ODF until after Monopolysoft has done its number on it? Surely, they can and will extend ODF. This will create “ODF” files in large numbers that only work with MSO and those apps that license MSO libraries. These numbers can be overwhelming and hence become the de facto ODF. All may work out, nevertheless, if the case is successfully made to antitrust authorities that the extension mechanisms are being leveraged illegally by Monopolysoft.

We’ll see, but if ODF is not carefully worded ahead of time, we’ll hear the old “good for goose .. gander” song. It might be enough, however, to point out that Monopolysoft is neither a goose nor a gander but a monopolist. We’ll see.

[In addition to the patent issue described in this article/post above..] We know the technical mess and reinvention of the wheel that is OOXML, but as concerns patents, real patent traps will lie with MS-OOXML, and since this will not be unextended correct OOXML (currently, “correct” is meaningless), you will have no patent protections if you actually reverse engineer MS-OOXML in order to interoperate. Of course, attempting to interoperate with MSO is an interminable rat race that starts you and keeps you permanently in the tail position of that race. [OOXML will give way to XOXOML (TM) and then to something else, etc, each of which will be based on the closed patented extensions from earlier generations.]

The way forward should be to continue to grow an ecosystem of interoperable ODF (and other good standards) products. Good interesting products in large numbers that interoperate with each other NEED NOT interoperate specifically with MSO or other Monopolyware. If these products truly are good (many will be FOSS), consumers will see the value of moving over to these products. At some point they will know not to use MSO or will revert to older versions that can be understood mostly by Openoffice filters. Meanwhile antitrust authorities should force Monopolysoft to meet the ODF spec as much as possible. Us, rather than to go run Monopolysoft’s rat race, should instead complain to authorities about their brokenness.

I think this is the smartest path forward. Recap: ignore OOXML and MSOOXML in order to save LOTS of time to be spent instead on ODF (in practice, Sun probably won’t do this, but it’s their business how they spend their bucks). Work aggressively to grow ODF apps and documents that interoperate. Sell ODF and the apps to people.

Oh, and one more thing. OASIS should have an *official* path to determine if docs meet ODF requirements without the use of extensions. This way buyers can demand this. Otherwise, there will be confusion because today almost anything will qualify as an ODF conforming document (see ODF 1.1). You can’t separate the wheat from the chaff if you don’t have a trustworthy way to identify these parts.

Good luck.