ODF vs OOXML: Being impartial, and having people work

I was recently confronted with the question of having my users open any kind of office files they would receive as attachments. It gave me an occasion to review the whole controversy on Office Open XML, the new Microsoft format. And I didn't get any further by reviewing it :-(
As matter of fact, rather than focusing on solutions like ODF, OOXML, or their implementations in MS Office or OpenOffice.org or others, I think the good way to take the question is to focus on the problems we have to address and define them better.

• Why did we need to change? What were the problems in the previous formats of Microsoft Office?
  

1. Vendor lock-in: because the format was not publicly documented, competitors could not implement it. They could not write competing software, resulting in a slow down of quality and support from Microsoft.
   
2. Bad support of previous versions: some files created with older versions of Microsoft Office cannot be opened with newer versions. This is especially true of Powerpoint slideshows. Even when a file can be opened, it is very common that the layout of elements doesn't look the same on different MS Office versions or different Windows versions.
   
3. Viruses: because the format was binary, and not publicly documented, it was easy to hide viruses in it, and hard to detect them. Lots of botnets have been created because of the funny powerpoints that are forwarded from employee to employee.
4. Heavy and limited format: the format inherited incoherences from its previous implementations, making it heavy to implement, and resulting in heavy files.

• What makes the best format?

1. Vendor lock-in: ODF suffers no limitations, the standard evolves, and can be implemented freely. Microsoft have said they will let competitors implement OOXML freely and they will publish modifications to the standard. Yet we have historical reasons to doubt this will be their policy.
2. Viruses: ODF is a complete XML format, which can easily be scanned against viruses. OOXML allows for binary parts in the documents, thus enabling viruses.
3. Weight of the format: Both are mostly text based and use a zip compression, obtaining comparable results for the size of files. ODF makes re-use of other standards such as HTML or SVG, allowing for cheaper implementation, whereas OOXML starts all from the ground up.
4. Implementations: Currently, OOXML is completely supported only in Microsoft Office 2007. ODF is completely supported in OpenOffice.org, StarOffice, Symphony, KOffice, Google Docs and others.

From a technical point of view, ODF is by far superior to OOXML.

• What do we face now?
  

1. Both ODF and OOXML have been promoted as ISO standards (26300:2006 for ODF and 29500:2008 for OOXML.)
2. Some companies have updated to Microsoft Office 2007, which saves by default as OOXML. Some companies have turned to OpenOffice.org which works natively with ODF.
3. So the result is that company users receive daily legacy binary .doc, .xls, .ppt and ODF documents and OOXML documents.
4. The most common Office suite is still Microsoft Office 2003, which works neither with ODF nor with OOXML.
5. Many companies don't have enough Microsoft licenses for all their workstations and implement OpenOffice.org where they don't have license.

• To the point: what do we need now?

1. Have both formats work with MS Office 2003, or pay and have them work with MS Office 2007. This seems to be possible with a "conversion environment" from Microsoft (to open OOXML) and a plugin from Sun (to open ODF).
   
2. Have both formats work with OpenOffice.org, where Microsoft licenses are not available. ODF is natively supported, and the implementation has started for OOXML. OOo should have working OOXML in short time.

As a conclusion, after spending quite a few hours on the question, I can tell that ODF is a technically far better solution, and that it should be possible to maintain people working through this cacophony with additional plugins for MS Office.
Of course, as usual, implementation will be the most important part. I will post about the implementation of plugins when I have results.