• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

An Antic Disposition

  • Home
  • About
  • Archives
  • Writings
  • Links
You are here: Home / Archives for Standards

Standards

Microsoft on Standards

2007/01/29 By Rob 11 Comments

There are many delicious morsels in the many exhibits in the Iowa Comes v. Microsoft case. Maybe that is why the official website containing the exhibits was taken down within hours of the case being settled? Luckily websites like Slated Antitrust filled the void and host backup copies of these candid insights into Microsoft’s internal strategies.

Let’s take a look inside.

First, here is the opening “Evangelism is War” section of a report called Effective Evangelism.

Our mission is to establish Microsoft’s platforms as the de facto standards throughout the computer industry. Our enemies are the vendors of platforms that compete with ours: Netscape, Sun, IBM, Oracle, Lotus, etc. The field of battle is the software industry. Success is measured in shipping applications. Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG [Developer Relations Group], is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: ‘A computer on every desk and in every home, running Microsoft software.’

Then we have this email from Bill Gates:

One thing we have got to change is our strategy — allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company.

We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities.

Anything else is suicide for our platform. This is a case where Office has to avoid doing something to destroy Windows.

And here is a excerpt from an email from then Microsoft GM Aaron Contorer to Bill Gates:

Switching Costs

In economics there is a well-understood concept called switching costs – how much it costs for a trading partner to change partners. Our philosophy on switching costs is very clear: we want low swiching costs for customers who want to start using our platform, and we want to provide so much unique value that there are in effect high costs of deciding to move to a different platform. There is a name for this: it is called Embrace and Extend.

Embrace means we are compatible with what’s out there, so you can switch to our platform without a lot of obstacles and rework. You can switch from someone else’s Java compiler to ours; from someone else’s web server to ours; etc. Customers love when we do this (as long as we don’t spend our energy embracing extra standards no one really cares about); our competitors are not sure they like it because they prefer us to screw up.

Extend means we provide tremendous value that nobody else does, so (A) you really want to switch to our software, and (B) once you try our software you would never want to go back to some inferior junk from our competitors. Customers usually like when we do this, since by definition it’s only an extension if it adds value. Competitors hate when we do this, because by adding new value we make our products much harder to clone – this is the difference between innovation and being just a commodity like corn where suppliers compete on price alone. Nobody builds or sustains a business as successful as Microsoft by producing trivial products that are easy to clone – that would be a strategy for failure.

If we fail to embrace, we can lose because there are big barriers to buying our products. But if we fail to extend, or do only humble work that is easy to clone or to surpass, we automatically lose because our competitors will spend literally billions of dollars to clone our work and replace us.

Patrick Ferell, at the time head of MSN tools and applications, worried about the internet’s open standards and protocols:

Looking out from the inside the current MSN strategy some things that concern me about the Internet and the Web are:

1) The Internet is about as open as it gets. This means that an ISV can go and buy a C compiler and a server, rent a wire and create a new service or create an extension to an existing one. The tools are still a little crude but there are very few bottlenecks in this process.

2) The Internet defines formats and architectures that MS has no control over and very little say in. MIME and the WWW helper architectures are crude but quite extensible.

Are there any other good Microsoft quotes out there regarding formats or standards? Post as a comment and I’ll add the best ones to the main post.


Change Log:

02/11/2007 — added Embrace & Extend quote sent in from reader
02/14/2007 — note on the links to the exhibits being broken
02/03/2008 — added MSN strategy quote

Filed Under: Microsoft, Standards

Adobe to Standardize PDF

2007/01/29 By Rob 3 Comments

According to the press release, it sounds like Adobe will submit their PDF 1.7 specification to AIIM, where it will be reviewed and refined before submission to ISO, likely to TC 171 . AIIM, if the name isn’t familiar to you, is the Association for Information and Image Management. They have been around since 1943, and they have a thriving ANSI-accredited standards program.

Note that this is not PDF’s first trip to ISO. Subsets of PDF have been standardized for particular problem domains, such as:

  • PDF/A for archiving as ISO 19005-1:2005
  • PDF/X for digital prepress exchange as ISO 15930
  • PDF/E for engineering workflows, currently under review ISO DIS 24517

But now we’ll be getting the full PDF functionality as an International Standard. This is good news. I’m pleased to see Adobe’s continuing leadership in this area. For more information on this topic, now and in the future, I recommend adding Adobe’s Duane Nickull to your regular cycle of blog reading.

Filed Under: Standards

Linus’s Law Applied to Standards Review

2007/01/23 By Rob 1 Comment

Eric Raymond’s famous formulation in the Cathedral and the Bazaar was “given enough eyeballs, all bugs are shallow”. Since Code is text and Spec is text, so it is reasonable to ask if this same law might apply to reviewing a specification as well.

This proposition was put to the test this last weekend at GrokLaw, where a team of volunteers attempted to review the 6,000 page Ecma Office Open XML specification. Since the specification is already two-weeks into a 30-day review in ISO/IEC JTC1, a parallel approach was the indicated solution. The alternative, for each individual to review the specification in its entirety, would have required them to read at the rate of 200-pages/day for a month.

The team of around 20 contributors logged nearly 1,000 edits on the wiki they set up for their collaboration. The wiki received a further 4,000 page reads. This was done over a few days, but the bulk of the work was done just this weekend.

What they found is amazing. As you know, I have been reading the OOXML specification, on and off, for a few months now, noting in this blog the problems I’ve seen. I thought I had a good grasp of the problems. But I was wrong. I was just scratching the surface. The Microsoft guys think I have been complaining too much. But it now looks like I wasn’t complaining enough.

Take a look at the report. I’ll need a few days to read through the details and research some of the items. You can be sure I’ll follow up with some new posts to explain, in plain English, the significance of the new issues.

Also, GrokLaw has put out a call for concerned individuals to write to their nation’s JTC1 representatives, to give informed thoughts on whether OOXML should continue the process toward an ISO standard, or whether it should be taken off its current “Fast Track” because it contradicts existing standards. If you are a regular reader of this blog, you know what is at stake and you know what to do.

One final note. I’m so impressed with the results of this collaborative approach to standards review, that I’m going to investigate whether we can do the same thing at OASIS. We’ve been using a wiki internally for drafting new parts of the ODF 1.2 specification, and that has worked well. But I’d love it if the next time we had a public review period for ODF we could have the public also participate in editing content in the wiki and organize the process that way. It is a much better method than the non-interactive, linear pattern of a mailing list.

Filed Under: OOXML, Standards

The Parable of the Solipsistic Standard

2007/01/22 By Rob 3 Comments

Winter is finally here. It is dark and dreary, the ground hard, unyielding. I’m getting over a cold. My feet are never as warm as I’d like them to be. But still, I look forward to spring. The seed catalogs have arrived. I’m starting to review possibilities for the garden next year. It is Winter, but this is only a temporary affliction. Current misery coupled with the knowledge of eventual satisfaction — there doesn’t seem to be a single English word which captures this thought. So, I’ll coin a word, “Sperandomiseria”.

Og mil ten fit ghust lech fer ti nostu, pertents? Sperandomiseria, cuic cuic danto do quant fer nos protoblian, sed nuic, volte torma. Zherantilli, fer muc opsice inito brandu s’deko prot affti? Nek worchi fer ubir! Sperandomiseria, gher-kloj ven ter moido, ven ter zer-moidi, eggen ven ter moidisti miki-moiki.

Do you agree? I think this is a good argument and I see no practical downside. Something must be done soon, lest we experience a repeat next time.

Sorry, What is that? You have no idea what I am talking about? Oh. So you don’t speak Weirish? We’ll need to do something about that then. That’s what I’m speaking now, Ecma Weirish. See, I used to use English, but I found that the English language was missing words for some things I wanted to express, so I made up some new words for these ideas, to ensure that everyone would perfectly understand what I was saying, with no ambiguities.

Ini hag danto do abergi nec palmu, ven fec tolibissi, pert rami fer cuic cuic affti.

Pardon, you are still having problems? You want to know about the words in the English language that were already well-known, useful and descriptive, and why I didn’t just use those, and supplement them with new words as needed? Good question. Once I started making up new words, I found that none of existing words in English perfectly matched my usage of them. In fact I really couldn’t translate my thoughts perfectly into any existing language. My thoughts are so unique that no other language works well for them . A totally new language is a much more accurate way to notate my thoughts. I wonder why everyone doesn’t do it? If you use this language, you will understand me perfectly.

Og mil ven ter moidisti… What? You again? Why can’t you just speak Weirish? When you use English you just slow down my mental processing. Ah, so you want to know how to speak Weirish. Great. I’ll give you a starter word list:

  • Pertentare (v) — to walk like Rob walks.
  • Protoblia (n) — a nice person [Note: This cannot be fully defined within this word list. It is best defined by how Weir thought a nice person was back 15 years ago.]
  • Zherantillo (n) — where Rob keeps his keys, sometimes upstairs near the bedroom, sometimes by the front door, sometimes in a hidden place.

Rhodantillu, muc muc dilinorpthu, ac…

I’m a patient man. What else do you want to know? Why should Weirish be an International Standard? Because it matches my thoughts so perfectly. Everyone wants to know what I think, so it is good that they learn Weirish for that task. If you look closely, you see that there are hundreds of languages already out there. I should have one too.

How do you say, “Firefox” in Weirish? Umm… uhhh… well, you don’t. I only use Internet Explorer, so there is no word for “Firefox”. Just say “Internet Explorer 4.0” instead. That’s close enough, right? Ditto for “Linux”, “OpenOffice”, “KOffice”, “WordPerfect” or “MySQL”. Here’s a 6,000 page document on Weirish I dictated in my sleep last week. Don’t leave! Hey! I’ve given you everything you’ve asked for. A perfect language, a dictionary for understanding it, a very very long manuscript on it, everything. Please, don’t go! Amitambo n’itorno!


Change log

1/28/07 — Fixed broken link, put Weirish text in italics, fixed grammatical error in one of the Weirish passages.

Filed Under: OOXML, Standards

A notable achievement

2006/12/09 By Rob 8 Comments

I believe congratulations are in order to Microsoft and Ecma’s TC45 for what appears to be a new world record for creating a standard. Their recently-approved Office Open XML (OOXML) standard weighed in at 6,456 pages yet took only 357 days to be reviewed, edited and approved, making it not only the largest markup specification, but possibly also the fastest to complete its standardization cycle.

To put the magnitude of this accomplishment into perspective, I looked at a variety of other successful standards from various standards bodies, such as:

  • OASIS OpenDocument Format (ODF)
  • OASIS Darwin Information Typing Architecture (DITA)
  • W3C Extensible Stylesheet Language (XSL)
  • W3C XHTML
  • W3C Scalable Vector Language (SVG)
  • W3C Simple Object Access Protocol (SOAP)
  • IETF MIME
  • Ecma C#
  • Ecma C++/CLI

In all cases I looked at how long the specification took to be standardized, from when the initial draft was made available (whether developed within the technical committee, or submitted by a vendor at committee formation) to the time when the standard was approved. So we’re looking at the complete editing/review/approval time, not including the time to author the initial draft. I also looked at the length of the resulting standard.

(Click on the above chart for a larger view)

As you can see, there is a noticeable trend with previous standards, where longer specifications took longer to edit, review and approve than shorter ones. This was the received wisdom, that standardization was a slow process, and this deliberate pace was necessary not only to achieve technical excellence, but also to socialize the specification and build industry consensus.

Also, previous specifications seemed to top out at around 1,000 pages. Larger than that and they tended to be broken into individual sub-standards which were reviewed and approved individually.

The general practice, as shown in this data, has been for standards to take from 0.1 – 1.2 pages per day, for a complete review/edit/approval cycle. Even other Microsoft specifications in Ecma have fit within these parameters, such as C# (1.2 pages/day) and C++/CLI (0.7 pages/day).

Thus the remarkable achievement of Microsoft and Ecma TC45, who not only managed to create a standard an order of magnitude larger than any other markup standard I’ve seen, but at the same time managed to complete the review/edit/approve cycle faster than any other markup standard I’ve seen. They have achieved an unprecedented review/edit/approval rate of 18.3 pages/day, 20-times faster than industry practice, a record which will likely stand unchallenged for the ages.

I think we would all like to know how they did it. High-altitude training? Performance enhancing drugs? Time travel? A pact with the Devil? I believe you will all share with me an earnest plea for them to share the secret of their productivity and efficiency with the world and especially with ISO, who will surely need similar performance enhancements in order for them to review this behemoth of a standard within their “Fast Track” process.

I am optimistic, that once the secret of OOXML’s achievement gets out, the way we make standards will never be the same again.


Change Log

1/26/07 — corrected two typographical errors pointed out by a reader

Filed Under: OOXML, Standards

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 6
  • Page 7
  • Page 8
  • Page 9
  • Go to Next Page »

Primary Sidebar

Copyright © 2006-2026 Rob Weir · Site Policies