JFK’s line after the Bay of Pigs that Victory has a thousand fathers, but defeat is an orphan has a less adversarial and more useful popular version Success has a thousand fathers, failure is an orphan, and that is what came to my mind when thinking about the Microsoft announcements on first-class support for ODF, direct involvement in the OASIS process, and extending the OSP license to ODF.
It is a great opportunity for hatchets to be buried, and I endorse everything that Patrick Durusau has written this week on it: “Not With A Bang, But With A Whimper” Ending the document format war that never was. Microsoft adopts OpenDocument Format. (and also see Dr Durusau’s “Divorce, Trust and Microsoft” Immediate steps towards building trust with Microsoft in the OpenDocument community.) Alex Brown also has an item Microsoft Moves to Support ODF Standard that I concur with too. (For background, Dr Durusau’s comments hearkens back to Dr Brown’s OpenXML vs ODF in SC34: The Phoney War.)
A year ago, I wrote a blog called Fantasy Press Releases which I called for MS to support standards out-of-the-box, as many people did. It looks like we will get this before another year is out. Excellent, excellent. I don’t know why they don’t do the PDF support earlier though: surely if it is just a matter of packaging up the existing plug-ins there should be no problems? I cannot see any convincing reason not to support IS29500 Compatibility in the Service Pack 2 either. It would be good for everyone if they put out an early version of SP2 ASAP with the PDF support in it, under some kind of beta scheme. (One thing that I have learned about MS is that it does take about three years to go from plan to execution: this was of course a reason why support for ODF in Office 12 was unreasonable, it was at the wrong stage in their development cycle. [A report has said they are skipping from Office 12 to Office 14: pfah] )
Almost a year ago, in Remembering George the Animal Steele! Why the Open Source community should support an ISO Office Open XML standard (or, at least, not oppose it!) I wrote:
In my view, the drivers for ODF will continue unabated even after/if Open XML becomes a standard.
So, in my jaded view, ODF will not make Office go away, ISO ODF will not make Ecma Open XML go away, and ISO Open XML will not make ISO ODF go away. So I see no downside in Open XML becoming an ISO standard: it ropes Microsoft into a more open development process, it forces them to document their formats to a degree they have not been accustomed to (indeed, the most satisfactory aspect of the process at ISO has been the amount of attention and review that Open XML has been given), and it gives us in the standards movement the thing that we have been calling for for decades (see my blog last week that compared what Slashdotters were calling for in 2004 with the path that MS has taken).
I think this is what we are seeing. The people who saw OOXML as being some kind of defense against ODF (whether they were on the anti-MS side or the MS side) were wrong. The thing that makes MS support ODF is market demand: significant users saying “We want to use ODF”. It is this positive demand, not emotional anti-IS29500 rhetoric, that is prevailing.
To try to put it again, there is a supply for standards and a demand for standards: adding IS29500 to the standards that can be supplied does not alter the dynamics and drivers for the demand of ODF. In fact, in the long run it increases the demand, because the file format information is out in the open, relatively unencumbered, and there will be many governments who will take the line “We know that ODF 1.0 was not not complete enough, and we know that ODF 1.1 is better, and that ODF 1.2 is looking very good: it is reasonable for us to anticipate that ODF 1.2 will be generally adequate for our requirements with the extra IS29500 input, and that we can start working towards ODF 1.2 by encouraging ODF 1.1 use.”
(On the issue of why MS will support ODF 1.1 not ISO ODF 1.0, the people to ask are the OASIS ODF TC: why didn’t they do their correct maintenance and submit ODF 1.1 to ISO? It would be paradoxical if MS participation energizes the ODF TC to treat ISO as something more than a rubber stamp!)
Goodbye to all that
The decision to broaden the OSP license to ODF (which is no surprise, this is something that participation in the OASIS group would require) does bring up an interesting point. During the OOXML discussions, there was frequent FUD that ODF was preferable to OOXML because OOXML may have IP problems: one problem I had with that was that surely if there were patents applying to techniques of implement office applications held by MS, these would apply just as much to ODF implementations as OOXML implementations? In fact, more so, because the OSP applied to the OOXML. The same issue is true vice versa: Sun’s equivalent to the OSP for its IP in OpenOffice applies to ODF but AFAIK not to OOXML implementations. (When you get to particular media formats that are outside the scope of the standards, there is a different argument, of course: the two shouldn’t be conflated.)
Finally there is the issue of MS joining the OASIS ODF TC. I have argued fairly consistently about the benefits of having MS at the table, and I think we owe Patrick Durusau a really good amount of honour here, for demonstrating that it is possible for self-motivated technical experts, who are above the marketing fray and who open themselves to criticism by refusing to budge from their vision despite partisan attack, to have moved the OASIS ODF TC to a point where MS thinks there is some point in participating in it.
However, frankly, I have my doubts. While I welcome the move, my regular readers will know I that I think partisan participation in standards bodies (i.e. where one mob actively blocks the technical requirements of another mob on the grounds “I don’t want to advantage my competitors”) is untenable for a standards body. That there is a significant danger that this attitude will prevail can be seen from the response of (my fanboys) the ODF Alliance Marino Marcich with its talk of “governments will continue to adopt a ‘buyer beware’ attitude” and so on. It will be a challenge for companies who have made “open” a codeword for “anti-Microsoft” to figure out a new marketing position: but where you get “open” people running public conferences on openness under Chatham House secrecy rule and sending emails threatening legal consequences to committee experts if they dare not follow the corporate line, I don’t have high expectations. The word “openness” has become like the “war on terror”: don’t look at the details or what is actually being done too closely!
Will leopards who have made their livelihood pouncing on MS every time it admits or reveals a problem over the last year change their spots: will they learn to have a pragmatic and cooperative attitude where the outcome of a good standard is more important than scoring marketing points along the way? We shall see. I have my hopes and doubts.
What about the dangly bits?
My other reservation about MS’s announcement does have a resonant spike with something else in Marcich’s reported comment ODF Alliance managing director Marino Marcich said the proof of Microsoft’s commitment to openness would be whether ODF support is on a par with Open XML.
We know that ODF 1.1 does not do everything that OOXML can support. So when it is the default format, what happens to the extras? There are a couple of possibilities. Office could just throw them away. That will frustrate users, who expect documents to open the same as when they close, and you would expect that users will be savvy enough to save in whichever format round-trips adequately. Office could embed foreign elements into the ODF: this is of course what ODF allows, but it then it will freak out people who apply the “embrace and extend” hammer to every issue. Or it could add OOXML files into the ODF ZIP file, with dual formatting, along the lines I raised in Can a file be ODF and OOOXML at the same time?.
Lets take a concrete example. As far as I know, ODF has no equivalent to OOXML’s Smart Art feature. Smart Art is one of the those features which makes old-time SGML-ers say “At last, after 20 years, this is the kind of thing we have been talking about” and represents IMHO the most radical innovation in structured GUI design in the last 20 years (given that there have been no real advances in structured editors since 1988’s SoftQuad Author/Editor.) What Smart Art does is allow a list to be edited structurally in a simple nesting list editor, then styled into scores of different diagram types: Venn diagrams, circular lists, all sorts of things. In the old SGML days, this is the kind of thing we would do by transforming from an SGML structure into a troff
pic script, for example, but with much slicker graphics.
I have found Smart Art really is a great advance for productivity, and maintainability (not having to keep the graphics files in a separate format for the drawing application), and it is something that I wish there were Open Source equivalents. Now if it is so good, why isn’t it on the ODF radar (and I trust readers will correct me if I have missed it!)? When saving out to a format that does not support SmartArt, Office currently converts it to a graphic, but tries to incorporate metadata or extra information to allow “rehydration” (which is MS’ buzzword for when you roundtrip data through a less-capable format with embedded extras which allow reconstruction of the original format.)
SmartArt is addictive. If it is lost by going through a different application or format that does not support it, or maintained as a graphic, you are liable to replace the graphic with another SmartArt graphic when you re-open the file, with steely annoyance.
One thing about the DIS29500 debates that observers have found perplexing has been the idea that a 6000 page standard has too much information. I don’t know that many people realized that in some cases (and I am not saying this is the only issue) it was a code for “Our product cannot match your feature list” which itself has several sub-issues (”We don’t want for our products to march to MS’ drum”, “We can only get interoperability by limiting features to a common subset”, “Our development procedures are too chaotic to have any goalposts other than adding one level of features to what we already have”, and so on.) SmartArt is definitely in this category.
So I would see Smart Art (under whatever guise) as a touchstone issue for seeing how well MS’ participation in the OASIS ODF TC takes them towards real convergence. I certainly expect that there are many issues such as the formula issue Dr Durusau raised earlier that will benefit quite fast. In fact, just as having IS29500 is helping ODF, I think MS participation in OASIS ODF will also help improve IS29500.
As I said, Smart Art is a really important advance in (QUASIWYG) editing of structured information and it shifts the text/graphic barrier in a really interesting and useful way: AFAIK it is not on the list for ODF 1.2, and it will be interesting to see whether the ODF process can handle innovations that come from the MS side. I think the deafening chorus from users especially governments throughout the DIS29500 discussions that IS29500 was acceptable only because it could help towards convergence is something that the ODF old blood may need to take stock of: Microsoft seems to be taking it seriously, yikes!
Do the right thing
Developers/standarizers on both sides need to be whacked on their heady heads with a mackeral that Not Invented Here is not acceptable. I think people accept that until now there have been reasonable excuses: that Office could not implement ODF before it existed, that Office could not use ODF as its default format until ODF had even minimal features and completeness, that OpenFormula could be syntactically incompatible with everyone else’s spreadsheet syntax, that ODF’s graphics could cherry pick SVG without really providing actual SVG compatibility (SVG Tiny please?), and so on. (Actually, I don’t mean NIH in the sense that there absolutely cannot be multiple syntaxes or technologies for the same thing if there is some historical reason or feature difference, I am primarily talking about rejecting features merely because of their provenance.) The state of the schemas for DIS 29500 mark 1 and ODF 1.0 just reveal their level of maturity and production-level adoption, and there is nothing wrong with being an adolescent. ODF and OOXML will grow up, and they need the partisan spirit and the NIH attitude to be kept under control to do so.
But it remains to be seen whether the OASIS ODF TC can sustain MS participation. I have written before that where there is direct participation in a standards body by rivals who take an uncooperative stance, it is difficult for the work to go ahead without it becoming a ganging-up exercise. (See Is our idea of open standards good enough? for more on this.) If MS proposes things to support Office better in ODF, and Sun and IBM don’t want to have to support those things, what happens: if it were the W3C, with direct member voting, you could expect MS to be rollled and eventually go away out of frustration/pique. The ISO model is one of direct membership for technical work, but indirect membership for final votes (i.e. it is the National Bodies which vote, not corporations or other stakeholders), and that creates a different dynamic that can produce a fairer result.
With all that said, Happy Father’s Day to the many people who have gotten us this far: I think it is positive news!