Shebanation

Way back in October, Bob Sutor, IBM’s open standards guru, wrote a piece on his blog where he described the Office Open XML standard as a one way standard, because the format is so complex and so geared towards compatibility with legacy Office compatibility that it could never be implemented as a fully functional file format by any competing personal productivity applications (PPAs) like WordPerfect and OpenOffice. I agree with a lot of his points but didn’t feel compelled to write about it since the issue had been covered pretty comprehensively in the blogosphere.

Today, though, a couple of interesting things happened that made me want to write about this. The first is that ECMA approved the Office XML standard over IBM’s objections. That got me thinking about Bob’s piece again. The other is that Rick Schaut of Microsoft’s Mac BU wrote an article explaining very eloquently why the Mac version of Office won’t support the Open XML file format until sometime next year. What struck me when I read the latter piece is that Rick absolutely, positively proves Bob Sutor’s point when he explains what it would take to create a file converter from scratch for Mac Word:

[…] a team of 5 developers will implement 25 handlers a week, which means that we’d have all the XML handlers written in 44 weeks. […] Nevertheless, we’ve taken a little less than a year to get the converters reading the new file format. We still aren’t writing the new file format, we have the RTF side of things to worry about, which is actually more complex than the XML side, and I’ve completely left out all of the design and coding for the intermediate representation of the file. The intermediate representation, itself, is at least 6 to 8 months worth of work.

Got that? It would take 5 developers a year to do a quarter of the work. That means the whole job is roughly 20 man-years of development time. That doesn’t include testing, documentation, or localization. That would probably double the number of man-years, at least. But it gets worse:

This is just for Word. We need additional teams for Excel and PowerPoint.

Back of the envelope, we’re now talking about 120 man-years. For Mac Office, Microsoft decided such an investment wasn’t practical, so instead they waited for Win32 Office to go final and are now porting the Win32 code to the Mac:

Lastly, can we port the Win Word converter? Well, actually, in a way, porting the Win Word converter is exactly what we have been doing, but we’re still faced with having to wait until Win Word ships before we have the final source code to merge into what we’ve already ported. Once that merge is done, then we still have to go through several months’ worth of testing and bug fixing before they’re ready for public use.

But it gets even worse! There is a lot of commonality between the in-memory data model for Win32 Office and Mac Office, since they share a lot of the same code, but doing converters for a competitive product that has a different in-memory data model would require more development time and more compatibility testing time.

Breaking out my envelope again, we’re now looking at 150 man years to do the job for a competitive PPA. How can competitors afford to make that level of investment? Novell says they will support import and export for Open XML with financial and technical help from Microsoft. Corel says they’ll do it too. Guess we’ll need to wait and see how successful they’ll be at maintaining fidelity and compatibility, though given what Rick has to say, I’m not super confident.