How "Ignorant of Standards" was Microsoft Really?
Thursday, June 26 2008 @ 09:20 AM CDT
Contributed by: Andy Updegrove
Regular readers will notice that I've been woefully silent the last few weeks, at first due to having too many irons in the fire, and for the last ten days due to being on a family vacation abroad, returning not till July 2. As a result, I've been not only behind on blogging, but also on keeping up with the news while limited primarily to Blackberry access since I left. But I thought that it might be useful to take a break and share the "Huh?!?" I experienced when I stumbled across this article by Andrew Donoghue at ZDNet while briefly enjoying an island of laptop connectivity in a hotel lobby in Florence. The article is titled, "Microsoft admits to standards ignorance pre-OOMXL" and is based on remarks by Microsoft national technology officer Stuart McKee. Even more incredibly, it bears the following subtitle:
Microsoft has admitted that, despite being one of the dominant names in IT for over 30 years, it had little or no experience or expertise around software standards until the company was mid-way through the process of getting Office Open XML approved by the International Organization for Standardization.
Why "Huh?" Because Microsoft has been playing the standards game, butting heads over prior technologies such as ActiveX, Java and much, much more with the best of them for decades as a member of hundreds of standards organizations. Moreover, it has held many board seats along the way, and has had a staff of attorneys for some time dedicated to standards matters. That staff includes the former General Counsel of the American National Standards Institute (ANSI).
Still, while McKee has over-spun the point by a few hundred RPMs, there is an important point to be made on the subject of Microsoft's standards-related capabilities, as I'll explain in greater detail below.
McKee's comments were made during a panel debate I regrettably declined to be part of, due to current travel, at a Red Hat conference in Boston last week entitled 'The OOXML battle: Who really won?' According to McKee,
We found ourselves so far down the path of the standardisation process with no knowledge. We don't have a standards office. We didn't have a standards department in the company. I think the one thing that we would acknowledge and that we were frustrated with is that, by the time we realised what was going on and the competitive environment that was underway, we were late and there was a lot of catch-up.
Given the history as I know it, you'll have to forgive me for coughing a bit into my hand over that one, although there is a grain of truth in McKee's statement.
That grain comes from the fact that Microsoft, in truth, does not have the kind of global standards infrastructure in place that IBM maintains. IBM's position is, I believe, unique among US multinational IT companies in this regard, with no other peer company having the first hand experience, presence and participation in standards bodies around the globe that IBM has created over the last fifty years.
IBM has enjoyed this position since Tom Watson, Sr., decided to split responsibility for the company between his two sons at the time that he stepped down from day to day control. When Tom Watson, Jr. took over as President in 1952, the consolation prize for his brother was assuming responsibility for IBM's foreign operations. The result was a decades-long degree of focus and autonomy that later caused some issues Lou Gerstner had to wring out in order to make IBM a leaner survivor in the mid-nineties, but also gave birth to a level of local autonomy for managers in many countries around the world that helped foster greater integration into local National Bodies.
As a result, it is certainly true that when IBM, and to a lesser extent companies such as Google and Oracle, decided to lay on the full court, global OOXML press, Microsoft was left to play catch up ball, and lacked the type of finesse that its more experienced rival could bring to the game in countless venues around the world. In consequence, much of its activity had to be undertaken not by standards professionals, but by a host of other staff from many disciplines. Perhaps this is part of the reason for the number of both publicized as well as alleged missteps that attended the OOXML process. In contrast, the ODF camp was able to make its case with very few accusations of heavy handedness being made against them.
According to the ZDNet article, McKee had no apologies for any of Microsoft's actions however:
Microsoft did not regret any of its actions during the voting process and claimed the company was merely trying to catch up with a process that it had very little experience of. "I think the thing is that Microsoft was really, really late to this game," he said. "It was very difficult to enter into conversations around the world where the debate had already been framed."
So if Microsoft is in fact an experienced player in the standards game, why did it allow itself to get so far behind in the standards race infrastructurally?
The answer is doubtless in part because most of the action in IT standards occurs in consortia, and not in the traditional standards infrastructure, made up of National Bodies, ISO, IEC and JTC 1. Putting boots on the ground in the "mirror committees" for a given technical committee in countries around the world is a significant undertaking, and a far smaller percentage of IT standards are either created in the first instance through that process, or approved after development through the Fast Track process (as OOXML was, through Ecma) or the PAS process, as ODF was (through OASIS). And few, if any, of the standards that do become so blessed by the traditional process have been as closely contested as was OOXML. More typically, a far smaller number of National Bodies take an active interest in any single standard, and are generally interested only in improving it, rather than opposing it. Hence, from a resources point of view, it's hard to make a case for the type of investment in standards professionals on a global basis that IBM maintains.
The result is that, notwithstanding all of the criticism that has been levied (including by me) at the traditional National Body/JTC 1 system, it does have one thing to be said for it: it's a huge job to try and steamroll (in this case) 86 National Bodies, compared to a single consortium or accredited body - a point that Rick Jelliffe has repeatedly made. That takes an enormous amount of time if there is serious opposition.
This time around, Microsoft was willing to make the effort, although with four appeals being processed and DIS 29500 OOXML implementation in Office now postponed until the next major release due to the number of changes to the OOXML draft along the way, the jury is still out on whether Microsoft can be said to have succeeded. Indeed, McKee was also quoted as saying at the same presentation that "ODF has clearly won," although I doubt that this statement is any more reflective of Microsoft's internal strategic decision making consensus than his portrayal of his employer's standards capabilities.
So what will Microsoft have learned from this long, hard process? Should it enter into a standards equivalent of the Cold War arms race, matching IBM standards professional for standards professional in virtual silos around the world, or become a more effective team player within the existing process?
Embarking on the first strategy would take not only millions of dollars but many years to bring to fruition. You can't simply send a green employee into a standards committee where the most influential members have often been working together for years and expect to get results. Thus it would seem that in open standards, as in open source, Microsoft will need to adopt a strategy that involves being a more savvy and collaboratively effective player in the overall ecosystem, rather than trying to maintain the hegemony of its historical, proprietary environment through efforts to promote defensive standards across the industry, at least in the face of determined opposition.
That would be good news for everyone - including Microsoft. Why? because it would be far easier for Microsoft to execute on such a strategy effectively, because it's not really ignorant about how to participate in this process at all. Indeed, after being a team player in many, many consortia over the years already, working shoulder to shoulder with its competitors to help create many standards of common interest, it has no catching up to do at all. Moreover, when competing in this manner, IBM and others should have no great advantage over Microsoft at all.
Or, as the old saying goes, "If you can't beat them, join them." You'd have to be truly ignorant about standards not to take that advice.
Updated: An anonymous reader below has provided a link to a blog entry by Microsoft's Jason Matusow in response to the ZDNet article. You can read much more of interest in that blog entry here, but I thought I would paste in here some of the details confirming my account of Microsoft's past and current standards activities:
More than eight years ago, a corporate standards organization was formed in the company to help product teams be better participants in standards orgs, to make more strategic decisions about what and where to contribute specifications, and how to deal with the legal issues surrounding standards bodies (there is an entire specialization in the legal field for this kind of work believe it or not).
Currently, the standards organization at Microsoft has more than 25 full-time employees in it and is focused not only on standards, but how the company thinks about interoperability and standards as a whole. What's more, because we are active in more than 150 standards orgs at any one time, and more than 400 overall - we have more than 600 product team and field employees who have been internally certified for standards work (and most of them are active in some committee or other). Our products have supported literally more than 10,000 standards and we have contributed specifications in the areas of development languages, runtimes, networking protocols, systems management, hardware, mobility, document formats, security,...the list goes on.
For further blog entries on here , click