Rob

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

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.

A Review of the Wikipedia Article on ODF

2007/01/27 By Rob 5 Comments

As I had done last week with the Wikipedia article on Office Open XML (OOXML), I have taken a read through the article on OpenDocument Format (ODF). My aim was to do some fact checking and make some suggestions on some additional references that might be included. In some case I’ve made additional usage or phrasing suggestions, but I have not endeavored to do a full edit of the article.

In accordance with Wikipedia’s Conflict of Interest guidelines, I will put a link to this blog entry on the ODF article’s Talk page. These points are for the consideration of the volunteers editing the article, to consider and do what they want with them. I’ll probably repeat this review on a quarterly basis.

Since the article is changing at a rather rapid rate, you should note that I looked at the revision of 27 January at 16:19 which you can retrieve here.

Opening paragraph. “…is a document file format used for exchanging electronic documents”. I’d say instead, “…for describing electronic documents”. Documents are exchanged via protocols like SMTP, WebDAV or HTTP, etc. ODF is only describing the documents.
Strictly speaking, ODF was developed by a technical committee (TC) working within the OASIS consortium. The point is OASIS as a whole approved ODF, but it was developed within a TC.
Last sentence of first paragraph is awkward. I’d keep the details and dates in the Standardization section and just state the current status here: “OpenDocument is an OASIS Standard as well as an International Standard published as ISO/IEC 26300:2006”
The next sentence is weak. I’d rephrase as something like “ODF meets the common definitions of an [Open Standard], meaning the specification is freely available and may be implemented freely”. Since Wikipedia already has nice article on open standards, why not just link to that?
The claim that ODF was “intended” to avoid vendor lock-in should be substantiated. That indeed may be one of its effects. But the charter of the TC did not mention that as an explicit goal. I think this is just loose language. Whenever you see a passive sentence, ask yourself, “Who or what did this”? Who intended ODF to be such and such? If you can provide a reference for that question, then you have something.
Next sentence is awkward. How about, “OpenDocument is the first widely adopted International Standard for editable office documents.” ?
Under Specifications, in addition to the listed compression advantage of using the approach with the ZIP archive, it also has the benefit of separating the content, styles , metadata and application settings into four separate XML files. This is a good example of the architectural principle of [Separation of Concerns].
I suggest we add here: “An important goal during the development of ODF was to reuse existing relevant standards where possible. Such standards used in ODF include [MathML], [Synchronized Multimedia Integration Language|SMIL], [SVG], and [XForms].” If needed a link to the ODF TC’s charter would server as an authoritative reference for the goal to reuse existing standards.
The Standardization section seems to be split off into a linked article which is a bit outdated. Is this necessary? This might make more sense to have this information brought back into the main article. Just my opinion.
First sentence is not quite correct. ODF was developed by a technical committee (TC) working within the OASIS consortium.
“OASIS Standard” should be capitalized as a proper noun.
This section gets a bit weighted down with jargon. Does the average reader, even a technical reader, understand was a “DIS” is, or a “default ballot”? We should either explain the significance of these terms, or summarize. I don’t think this needs to contain a day-by-day retelling of how a specification made its way through ISO.
OpenDocument Format 1.1 was approved as an Committee Specification in October. The ballot for approval as an OASIS Standard is occurring right now. (Would the average reader understand this distinction? Specifications are approved first by the ODF TC as Committee Specifications, then major versions are put forward for a vote by the entire OASIS membership as an OASIS Standard, and even more significant editions are then put forward for approval by ISO as an International Standard.)
On the ODF 1.2 work, the parenthentical remark on spreadsheet formulas seem out of place and redundent since there is a separate Criticism header that covers this. The obvious presumption is that anything added to ODF 1.2 is added because it is not already there. Do we believe that any reader would think otherwise?
Overall the 1.2 statement looks like it needs a rewrite. I’d suggest a simple statement like, “OpenDocument Format is currently being drafted by the ODF TC. It is planned to contain additional accessibility features, metadata enhancements, spreadsheet formula definition (based on [OpenFormula] and any errata submitted by the public.” (Discussion of various schedule predictions seems outdated since December has already come and gone. )
Section on Application support — “Since there are a number of independent implementations of the ODF standard..”. This might be better in an “Interoperability” sub-section. If you make such a sub-section, the Fellowships test suite, mentioned earlier in the article, could be moved there as well.
“Although Microsoft Office does not support OpenDocument…” should be, “Although Microsoft Office does not support OpenDocument natively…”
Again, never trust engineers to come up with a good prediction of schedules. December has come and gone and no Add-in is complete.
There should also be mention of Corel’s stated plans to add ODF support to WordPerfect Office. The press release you can reference is here.
There is mention here of a “MS Open XML translator”. This was Microsoft’s name for their intiative. But the web page linked to here consistently refers to itself as the “ODF Add-in for Microsoft Word”. This is confusing. Maybe start with a mention of the Microsoft announcement from July 2006 (this press release) then say that one such project supported by Microsoft is the ODF Add-in for Word, etc.
The ODMA mention is unrelated to ODF. It probably should be removed entirely.
Under the Accessibility sub-section, might want to mention that a group at the University of Illinois has written an OpenDocument Format Accessibility Evaluator to scan uploaded ODF documents for how well they follow best practices for accessibility. A link to the tool is project is here.
Under Promotion section, we should link to the ODF Adoption TC’s web page here and mention that they also manage the web site http://OpenDocument.xml.org
The promotion activities of OpenOffice.org should be included in the bullet list that follows, right? Not clear why it is not.
“…as well as other companies who may or may not be working inside…” is weird. Was someone attempting to say something here. The fact that the ODF Alliance is stated has having “more than 280 members” should make it obvious that not all are members of the OASIS ODF TC. Is anything added by having this statement?
ODF Alliance has 362 organizational members according to their latest newsletter here .
In Adoption section, there is repetition of information that was already covered in the Application support section, such as the Microsoft-funded translator work.
The Adoption section is incomplete, missing adoptions in Brazil, Argentina, Extremadura Spain, and India. The ODF Alliance newsletters have the details on these and others. This whitepaper is a good summary.
In Criticism section, the statements, “Some mathematicians do not think that the choice of the MathML W3C standard for use in OpenDocument is a good choice” and “monstrosity written purely by web designers” lack an authoritative citation. All that is given is a link to an unnamed commenter on a GrokLaw article, whose credentials as a mathematician or a spokesman for mathematicians are not obvious. Consider that one of the authors of the MathML 2.0 standard, and co-chair of the W3C’s Math Working Group, is Patrick Ion, editor of the American Mathematical Society’s Mathematical Reviews. So the credibility of MathML should not so easily be set aside by a single anonymous, unsubstantiated comment. I’d also note that the Wikipedia artcle for MathML does not note such criticism.
“The OpenDocument ISO specification does not contain a defined formula language” is more precise as “The OpenDocument ISO specification does not define a standard spreadsheet formula language.”
“This means that ISO conforming files do not have to be compatible.” This is a weak argument. Even if the spreadsheet language were defined, ISO conforming documents are not required to be compatible. For example, two implementations may implement different subsets of features. And even without a formula standard, implementations can still be compatible. For example, 1-2-3 , Quattro Pro and OpenOffice have been able to read Excel formulas for years, even though Microsoft had not specified this. Maybe what is meant here is “This means that spreadsheet implementations currently rely on application-level interoperability testing rather than referencing a normative specification of formula syntax and semantics.”
The criticism of the ability to embed Java applets is new to me. No reference is given for this criticism. The section number establishes the existence of the feature, but does not establish grounds for criticizing it. Is this original research? If so, it does not belong on Wikipedia.

Change Log
1/28/07 — corrected link to ODF’s Talk page

Crocodile Tears

2007/01/25 By Rob 21 Comments

By now everyone on the planet with an internet connection knows about Rick Jelliffe, the blogger Microsoft offered to pay to make the Office Open XML Wikipedia page “more objective”. (It is unclear what criteria Microsoft uses to determine which bloggers are given free laptops and which ones get offered cash.) In any case, I suspect that objectivity, like love, is something that is better free than purchased.

Microsoft’s Doug Mahugh disclosed a portion of the proposal he sent to Rick, in a comment on Slashdot:

Wikipedia has an entry on Open XML that has a lot of slanted language, and we’d like for them to make it more objective but we feel that it would be best if a non-Microsoft person were the source of any corrections… Would you have any interest or availability to do some of this kind of work? Your reputation as a leading voice in the XML community would carry a lot of credibility, so your name came up in a discussion of the Wikipedia situation today.

The national coverage of what was eventually called “Wiki-gate” brought the inevitable reaction from Microsoft — IBM made us do it:

[Microsoft] Spokeswoman Catherine Brooker said she believed the articles were heavily written by people at IBM, which is a big supporter of the open-source standard — in USA Today.

So the question in my mind is this: How bad was the OOXML Wikipedia page before all the fuss started? All this Wiki-gate news hit on the 23rd, with Rick’s blog post. So let’s go back to the Wikipedia page previous to that, which would be the version of 18 January. Take a read. You can also take a look at the Talk page where the prior version was last edited on 21 September. You can read it here.

Is this something that one would say has “a lot of slanted language” and was “heavily written by people at IBM Corp”? Is this something that warranted extraordinary means to address? I’d be interested in what parts they believed were “heavily written”. What does “heavily written” even mean? This is quite an allegation.

How’s this for heavy: I’ll make you an offer you can’t refuse. I’ll do a review and fact checking of the 18 January version of the OOXML Wikipedia entry, and I’ll link to the review from the Talk page, so others can consider it and make the changes if they agree. I won’t charge you a cent. If you find this at all useful, you can donate a few dollars to the Free Software Foundation. How’s that, Doug?

The first paragraph should say simply “Office Open XML”. It is a waste of time to argue about whether it is Microsoft Office Open XML, Ecma Office Open XML or ISO Office Open XML. At some point you may have one version in ISO while a revision is being worked on in Ecma. Just call it “Office Open XML” and it will cover all cases.
Next sentence should say, “The specification was developed by Microsoft and others…”. You shouldn’t need to list them all here, but do list them under Standardization.
Should say, “is the default format in Office 2007”, not just “is used”.
“Microsoft maintains that its primary goal…” needs a reference to cite. Perhaps page 1 of the whitepaper.
“The Microsoft Office Open XML format is Microsoft’s direct answer to the OpenDocument format” also needs a reference or should be removed.
Standardization section would be better if written chronologically, start from the beginning and end at the end.
Should say, “A liaison from the ISO/IEC JTC1/SC34 was appointed to help during…”
Licensing — “There has been a lot of argument about…”. If there has been a lot, maybe someone should cite an example?
Brian Jones is an expert in some things, but I am not aware of his legal credentials. So citing his legal analysis does not seem to be authoritative and I doubt he intended it to be taken that way. This citation should be removed.
Overall, the Licensing section seems like it is missing what I’d consider the two most important links: Microsoft’s Open Specification Promise, and to the Baker & McKenzie analysis.
I would move the packaging and relations text into its own article called “Open Packaging Conventions” or OPC. The basic structure here will be used in other Microsoft formats like XPS so it makes sense to centralize it in one place and reference it from here.
Under Document Markup Languages, I’d drop the discussion of the 2003 formats. Move that to a different article if needed. Ditto for DataDiagrammingML.
Under Criticism, there needs to be some references cited. There is no shortage of criticism and no shortage of references for that. If you want primary source material, I’d suggest GrokLaw list as the most comprehensive. It cannot simply be denied or ignored that there is a large amount of criticism out there. It will look silly for Wikipedia if OOXML is defeated in ISO and the day prior there was not even a mention of criticism on its Wikipedia page.
Market Adoption — This section seems to be talking more about application support than adoption. I suggest it be renamed “Application Support” and “Adoption” be reserved for notable adoptions of the standard at the state or national level if/when they occur. OpenOffice’s support of WordProcessing 2003 doesn’t belong here, but Novell’s announcement that they will add OOXML should be here.
A note throughout — this article could use some copy editing. As expected with any text written by several people over time, not all native English speakers, there are differences in levels of formality and a good number of language errors.

That’s about it. I didn’t see anything all that unusual or extreme here. If anything I found it odd that there are no links in this article to anything critical of OOXML, even though Microsoft’s stated reason for contracting with Jelliffe was to correct bias in the article. What am I missing? Where is this horrible slant? If anything, this article is living in some dream world where OOXML is not being heavily criticized for being too large, too rushed and too poorly written. If an article with no links to criticism is considered “heavily written by IBM”, I’d hate to see what Microsoft thinks an objective article reads like.

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.