How Microsoft Should Have Played the ODF Standards Game

I posted on Microsoft's standards strategy around their Office XML Schema versus the OASIS Open Document Format standard that is well implemented and already on its way to ISO. 

Let's look at the strategy Microsoft should have followed to win this particularly nasty attack on one of their core revenue streams. We will make the following worst case assumptions (from a Microsoft business perspective):

• The market does really believe that Microsoft is over-delivering in the Microsoft Office product suite, triggering a call for standardization. 
• Tightly integrated innovation may not work in this product space as well anymore, unless they can build new complement models around it (e.g. perhaps a play around Sharepoint).
• The OASIS Open Document Format standard has a sufficient head start and real implementations that it really does catch on with customers.

Here's how it should have been done:

• When the OASIS group began Microsoft should have immediately joined and joined in force.  Standards is a game of collaboration and influence and you can't influence if you don't participate. For a multi-billion dollar revenue stream they could afford a little participation.
  
• Dipping a toe in the water here would only let them know what their competitors were doing rather than giving them the ability to effect things.  Microsoft should have had experts (multiple) in the room as "the most knowledgeable people" on the broad subject of document formats for the predominant format in the world. 
• As well they should have been volunteering to host meetings, assume administrative positions, and involve as many liaison points as possible.  (The more external liaison points one can create the slower the process will move.  This is applying Brooks' Law to standards groups.)
• They could have expanded the charter in dire ways to continue the confusion.  Look how long it took to complete the C++ language standard once that working group tried to bite off the entire HP template library as part of the initial work.  I can imagine linking the ODF work to character set specifications in ISO as a way to drag out the format standard discussion for quite some time, especially if cross standards organizational liaison points were set-up.

From this point forward, they would have been able to throttle expectations and directly impact the development process to maintain a core relationship to the evolving specification.  They could have ensured their own format (asset) was protected, but with a clear relationship to the standard maintained.  It would have forced a nasty amount of implementation stress onto the OpenOffice world, and on Sun and IBM by forcing them into co-operation they weren't ready to assume. 

Then when a standard was finally released:

• Immediately claim to be developing a conforming implementation to be released at some appropriate time. The public relations game is very clean.  They have been seen to be contributing all the development cycle.  They sound reasonable in relation to the customer desire to see a standard.  They can continue to advance their own format and innovation, while claiming the check box of conformance.
• Immediately propose the next wave of format standardization to maintain the illusion that the standard isn't yet baked, and could be evolving for some time.

Indeed, even though Microsoft chose not to participate (thereby receiving a nasty surprise when ODF landed in their laps relatively quickly and with apparent customer support), the simplest way to have made the entire "mess" go away would have been to:

• Announce support for the standard in a service pack after Office 12 ships.  It's reasonable to not immediately leap to implement and interrupt the current delivery cycle and no customer would punish them for that delay. 
• It could be dressed in almost identical language about having the superior technology but listening to customers. 
• Indeed they could even position it with existing customers as an archive format rather than a "real" document format. 

While the analysis sounds very sinister, it is actually the way the market place works.  Companies compete.  Standards are a market tool to enable multiple implementations of some functionality allowing competition in the market which lowers prices.  Depending upon the unique needs of customers, they also want solutions to problems.  They're willing to pay a premium for that solution.  That solution often starts as a unique value proposition from a single vendor. There comes a point when the vendor is in a dominant position and the customer wants price competition. And the cycle begins again. 

Standards move the market forward but threaten an incumbent's position.  The incumbent has a responsibility to shareholders to be as profitable as possible delivering new value to customers, but the easiest way for this would be to extend the technology base already in place.  These are the normal stresses in the market system.

The interesting thing is to look back on the number of times a vendor with a single implementation tried to win playing an overlapping standards game.  Looking at the UNIX wars I remember three occasions off the top of my head where this was tried over a long period.

• "tar wars" over archiving formats.
• The GUI Wars where OSF/Motif and Sun's GUI toolkit battled it out.
• The sockets versus streams debate.

In each case, we ended up with two standards being forced upon us.  In each case, the dominant technology that won in the marketplace was the one with the most implementations, with the other withering on the vine. Even when both specifications became required for an implementation to claim conformance to the single standard that included them, customers in the market used the specification which was most widely implemented every time. 

Microsoft chose the wrong strategy here on multiple levels, betting against customers and the market in general. It may buy a bit of time, but will ultimately cost them more in the long run.