Updated (22-Sep-2005, 23:50 PDT): It's official as of yesterday. The Enterprise Technical Reference Model V3.5 is now published. FAQ is here. Official comments are here. This post has been kindly referenced from LinuxToday, NewsForge, and Bob Sutor (IBM) on his blog. I've no idea from where it's been unkindly referenced.
Updated (19-Sep-2005, 15:00 PDT): Started collecting blogs and news at the end in a further links section, starting with Nicolas Carr's post.
The discussion is certainly heating up around the Commonwealth of Massachusetts' decision to move to the Open Document Format standard. Simon Phipps (Sun) has an excellent blog entry on the framing that has begun. Bob Sutor (IBM) also provides excellent insight into the vendor positioning from his point of view. In the past week, the official vendor comments (Sun, IBM, Corel, Adobe, Microsoft) have been flowing into the Commonwealth.
The Microsoft response is a study in exactly this sort of framing game. While the others are a page or two supporting the decision, the Microsoft response is a fine example of norm entrepreneurial rhetoric at 14 pages.
So let's shape that frame a little. My experience here comes from more than 15 years as a developer of standards, a user of standards, and an implementer of standards, as both consumer and vendor, and across multiple products. My viewpoint is not constrained to narrow legal concerns with how standards impact my IP portfolio, but rather the broad market economics of standardization.
First, let's start with the market.
Christensen observed that when a technology space is immature, and the technology isn't "good enough", the vendor that controls the entire delivery process (i.e. tightly integrated innovation) wins. Once the vendor starts to over deliver on customer needs, indeed customers can't absorb (and so don't want to pay for) new innovation, then there is a call for standardization in the market place. At this point, the component players can get involved, and tightly integrated innovation no longer wins the day.
You might imagine that the call for standards is a market signal that the competitors love as well. They get a wedge to drive into the incumbents business to those over-served customers. Customers believe the standards are good (often sight unseen) because there appears growing choice in the market which at the very least puts price pressure on the incumbent. Innovating faster along the original trajectory doesn't help the incumbent because customers are looking for solutions, not even more innovation that they can't absorb and don't want to pay for. (Remember -- innovation is a supply side action. The demand side is about solving a problem.)
Geoff Moore also talks about standards from a technology point of view. He observed that when a gorilla is forming in a market there is a call for "open systems". He's right. But the timing is important here. If you call for standards before the customer is over served, the incumbent still delivers a better experience and wins. (To be clear: I like Christensen and Moore models a lot because they reflect how I've seen businesses and customers behave as both technology provider and consumer.)
This also means the vendor that is being "standardized" is going to "fight" that standards effort with a vengeance. (More on that in a moment.) So everyone is behaving economically rationally. Microsoft hates what's happening and IBM, Sun, et al love it.
Let's look at standards for a moment. Standards exist to encourage multiple implementations. That is their economic purpose. It is a specification of how something works at an interface such that multiple providers can provide the functionality. I wrote the following in a soon to be published O'Reilly essay:
*****
All standards live within a context of development and use. Many formal standards are developed by national bodies or international organizations such as ISO. These standards often define procurement policy for government organizations and large enterprises alike. Industry and trade associations develop standards relevant to their expert and specialized constituencies. In the information technology space for example, the IEEE has a standards arm, and historically CBEMA (now NCITS) and Ecma International acted as standards development organizations in the USA and Europe respectively for IT standards. Each of these three organizations was accredited within their national and regional geographies to produce standards that could be later adopted by the relevant nationally or internationally sponsored standards organization to prevent overlapping efforts, and to build on the relevant expertise within different industry groups.
Narrowing the focus even further, consortia of vendors [e.g. W3C and OASIS] often arise within a specific area of technology within an industry to develop standards and specifications. The consortia often try to build specifications more quickly to expand a particular market, feeling that the more traditional organizations are too slow to deliver standards
....
Another categorization attempts to discuss the difference between de jure standards developed in a consensus-based process and de facto standards. A more accurate statement might be de facto technology that describes a market dominant product, rather than a specification for interoperability open to all implementers. [One can argue that Christensen's model talks about when the market pressure turns de facto technologies into de jure specifications.]
*****
Proprietary specifications of de facto technologies are NOT standards. They don't exist to encourage multiple implementations of the technology for the consumer, but rather to encourage multiple complements to the technology, therefore increasing the value proposition of the de facto technology for the vendor. They serve a very different economic purpose. All of Microsoft's claims about being "the standard" are the antithesis of the standardization efforts the Commonwealth want to support.
If a company is not drowning in their own brand or innovation Kool-Aid™, then they will play the standards game well. They can't arguable stop the standards process, so it is better to get involved and manage the process.
This is certainly what Digital Equipment Corp. did through the 1980s and into the 1990s. The POSIX and UNIX standards efforts weren't about UNIX per se. DEC ruled the minicomputer market. VAX/VMS was an incredible engineering friendly platform for rich application development. Nothing wasn't documented for the platform so as to enable one to best develop new VMS applications. But, they were innovating faster than customers could absorb the innovation, and trying to drive customers up the product curve. They were also getting protectionist -- you couldn't add less expensive third party disks or memory to your VAX clusters without voiding your warranty. Customers wanted off the upgrade carousel. Applications (and ultimately data) are what's sticky for the customer. So if we could standardize on a portable application migration path, then even if portability wasn't perfect, it would have to be better than being locked onto the DEC platform. (Sound familiar?)
DEC led the POSIX standards efforts. In my opinion, they brilliantly applied Brooks' Law to the process. If a little standardization is good, then a lot must be better! Soon there were 350 people attending quarterly week long meetings, and a couple of dozen projects spread across a dozen working groups. There were co-ordination committees, and liaison points to countless other standards organizations and consortia around the world. You don't even have to be that deliberate. The best companies at the standards game simply invite/involve people with the right attributes. There are certainly other games to be played as well. The POSIX efforts went on for over a decade. Microsoft should have perhaps played the OASIS standards effort differently.
In the end, as customers, we chose the standards path. We were incredibly happy with the VMS platform, but not DEC's lock on us. We chose inferior technology (UNIX products were pretty raw in the late 1980s) and rewrote new applications for it, and began migrating existing applications. We could get UNIX systems from a wide variety of vendors, and we certainly beat DEC down in pricing discussions in the mean time. UNIX systems matured over time to be as robust and innovative as VMS was in its day. We were a commercial organization. We were following the lead of the U.S. government in its procurement policy. The customer that was front and center in the POSIX standardization efforts was the U.S. National Institute of Standards and Technology. (This was back before the head of NIST became a presidential appointment, and the NIST agenda became political. In those days, NIST dealt with boring tedious initiatives like how to the government should best procure technology to protect the long term investment of tax dollars.)
The cost of migration is always painful the first time. But then the pain is eaten and you're done. For a period of time, in Microsoft's "Get the Facts" campaign they had a collection of public case studies demonstrating that the Total Cost of Ownership was cheaper for Windows, but these case studies invariably ignored the cost of migration to Windows in the numbers (even when they mentioned them in the executive summary.) Amazing how the migration costs got ignored when the shoe was on the other foot.
While Microsoft would love us to believe that this is an "unproven" standard, document format standards are actually amazingly mature at this point in history. You have to set the optic right. We have lots of experience with document formatting standards, all the way back to SGML (somewhat before its time), to HTML for the web, to XML. Even the early SGML work was based on proprietary mark-up and type setting languages from IBM and DEC, and early UNIX systems. We even have the experience collectively in the industry to deal with the differences between page layout (PostScript) and the structure of the information. Like networking protocols, document formats either work or they don't and it's very direct evidence. With the first standard in place, the space will mature to accomodate new document objects, and the product space will mature as well.
So in the end, Microsoft's commentary and framing reflect their vendor-centric, market-position threatened point of view. And Sun's and IBM's positions are certainly to be expected. But then so is the Commonwealth's. The Commonwealth is making a tough choice, but ultimately the right choice for its constituents. The rest is just framing.
Additional Links:
- Nicolas Carr hits the nail on the head in this blog post (19-Sep-2005). (Thanks to Stephen O'Grady for the pointer.) To speak to Mr. Carr's concern about reading state documents, I would suggest that's why the Commonwealth is also supporting the ubiquitous PDF (which is an ISO standard and freely licensed and widely implemented by multiple sources). One can use ODF as the internal working format, and PDF as the external publishing format.
- Boston Globe article (14-Sep-2005) "Microsoft fights bid to drop Office Software". This is the article that provoked this response.
- My original roll-up post is here.
Postscript: For an excellent discussion on norm entrepreneurial rhetoric, I would encourage you to read David McGowan's "SCO What: Rhetoric, Law, and the Future of F/OSS Production". While the paper is a little long and free and open source software centric, the discussion is directly relevant. [It gets a little legalistic in the middle, but read the rest of it aloud to appreciate the use of language.]
Comments