IBM's vice president of standards and open source Bob Sutor appears quite peeved by an article in eWeek:
In an eWeek article just published ("Microsoft to OpenDocument Alliance: Where's the Choice?"), Microsoft is accusing the supporters of the OpenDocument Format, a true open standard from the OASIS standards organization, of somehow limiting choice. They've tried this line before. It was ridiculous then, and it's ridiculous now. Give us a break.....
There's more. Sutor goes on to characterize a standard that's produced by OASIS as being far more open than one produced by Ecma. Based on an interview I did of Ecma Secretarie General Jan van den Beld, I'd have to agree. But not for every standard produced by OASIS. Just those that conform to the far more open of OASIS IP policies (the OpenDocument Format Standard is one of those). But back to the question "Where's the choice?"; it is a fair question. Today, almost a year later, there are all sorts of competitors to Office sprouting up (many of them Web/AJAX-based) that surprisingly don't support ODF. For some developers I've spoken too, it isn't a question of not wanting to support ODF in their products. The desire is there. It's the difficulty in doing so. ODF is a complicated specification for which no open source software development kit (SDK) exists. In other words, if you want to snap ODF support into that Web-based word processor or spreadsheet that you're developing, you have to do most of the heavy lifting yourself. If there was one oversight in the go-to-market strategy that was hatched by IBM, Sun and others, it was that the solid open source SDK that makes full-blown ODF support a cinch should have been co-developed by the two companies and made available some time last year.
Meanwhile, speaking of AJAX-based Office competitors, check out iNetOffice's iNetWord (Dan Farber showed it to me last night and I was pretty wowed). From what I can tell on its features page (no one answered the phones at iNetOffice's offices), it doesn't support ODF (also, its Save Document Dialog, shown left, indicates that HTML is the only choice). But, it's a very slick AJAX-based word processor that's also a Web page authoring system replete with some very respectable templates that can put the polish on any Web site. I haven't given it a good test run yet. The version that runs under Firefox is currently in beta and crashed my browser when I tried to create a new document (unfortunately, I was half-way through the first version of this blog (without having saved it) when the iNetWord took my Firefox down for the count. I had to start all over. Bummer. I got farther using IE. But, as can also be seen from the Save Document dialog to the left, there's no FTP capability. So, if you are creating Web pages, it's a bit more painful than it should be to get those Web pages onto your Web server (it's doable by saving the file locally to your hard drive first and then doing whatever you'd normally do to upload it to your Web server).
The reason it would be great if all these products supported some common formats is that it keeps people from getting trapped. The problem is that if you pick one of these new products and create a lot of documents with it, then you're stuck with that product if you need to continue accessing those documents over the long haul. And you should be able to switch to new better mousetraps without having to mothball your document archive or go through a painful conversion process. Sure, you could probably take iNetWord's HTML format and open it with other page editors, but HTML has some severe limitations when it comes to the more complicated Office documents that include features and functions (eg: revisions) that simply aren't found in HTML formatted documents.