Microsoft Office and ODF: Best Practices

Sorry for yet another bookmark post, but knowing how often I hear about this kind of compatibility problem, I thought this article was rare enough to notice: Rob Weir details how to handle ODF (Google Docs, OpenOffice, LibreOffice...) in Microsoft Office, version by version, from Office 2000 to Office 2010.

Raw unrefined suggestion about firewall rules

Since now we see attacks from inside intranets, using zombie networks, I think it could be a good idea to turn on the firewalls on each machine in the network (including on Windows stations, which I know is sometimes a problem) and to set up a detailed set of rules for them.

My problem was: how to figure out which rules for such a complex problem, so many machines?
My suggestion: why not propose a standard for a single file giving the positive rules necessary for a software to operate?

One file per application, that would come shipped with the application, and would describe all the things that need be open, for the application to work. The file would not describe what set of rules to put on which firewall, but simply what needs to be open.

If we have a look at the TCP/IP layers

This picture from Wikipedia under the GFDL license.

we see that simple firewalls operate on the Internet and Transport layers. Modern firewalls and proxies also operate on the Application layer.
I guess a simple XML dialect could be created to describe which things need be let in and out, on which layer. If this gets standardized or at least RFC'ed, there is a good chance to see opensource software adopt it, both on the application and on the firewall sides. On which case, since opensource is biggest marketshare on infrastructure, others should follow.
(All that raw and unrefined.)

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.