The impact of OOXML

(I mentioned some of the following ideas in a presentation I held on Thursday at KTH, and thought I would share them. As a side-note, there may be another FFII-style lecture here later this year, covering a wider range of topics but also some OOXML material again.)

OOXML, to me, is not a standard; I do not recognize the value of it as an Ecma publication, or indirectly in "de facto" terms, simply because the main problem is still there: nobody but Microsoft knows how the format really works, and so not all consumers are yet able to escape the lock-in that is Microsoft Office.

When OOXML was preliminarily voted down on 2 September, not much has actually become clear about its future; most votes have a chance of being changed, especially since we do not yet know what the final proposal will look like. Microsoft's manipulations will certainly continue until February, and thus the usual techniques for prediction may not apply. (Without the interventions of the company, I would say OOXML would be gone already - maybe not even voted upon.)

While one can expect that the standard proposal will require a significant amount of changes to be approved, such fixes could still be of trivial nature, relatively speaking. There are some rather tough suggestions around, though. One of them was submitted by France (J1N8726-03.doc) and others, suggesting that OOXML first be split into two parts; a "core" and "extensions", where the former is something ODF-like, and the latter is an add-on to address properties of the old file formats.

So, in theory, anything could happen; some imaginable scenarios being that:

• ISO rejects OOXML. While this in itself would not exclude a new submission, that would get much attention with a new fast-track, or require much time without it; the proposal would likely be out of the picture in these cases.
• ISO decides to split the proposal, and approve the "core" and "extensions" parts as "technical specifications". An "ISO standard" labeling is delayed further, awaiting e.g. merging of the "core" part with ODF.
• ISO approves OOXML "as-is" (few, or no fundamental problems are solved). This would most likely affect the reputation of ISO itself (due to the scale of the abuse of the process), perhaps to such an extent that the approval would have little weight eventually.

In some sense, OOXML (as published by ECMA) consequently is less of a worry now - regardless of the voting results. However, an "as-is" approval could (through governmental policies etc.) raise a lot of "short-term" problems and further setback in useful development, and it would also have an impact on ISO. It's not just about OOXML, though: XPS is also knocking on the door, and it carries lock-in threats with it as well through software patents. Maybe there is more to come, still.

So, while the harm that could come of OOXML and the end result is probably limited at this point, it is important to fix ISO's - and its members' - working procedures (e.g. for the fast-track, voting rules, etc.) and patent policies, in particular. Right now, ISO allows for licensing terms that are incompatible with free software / open source, and XPS could invite significant trouble in this context. Also, the discussion of ODF vs. OOXML still has important lessons for reaching a new and improved single standard. The patching continues...