Later, Microsoft sort of confirmed the authenticity in its own style ("Although Microsoft has not attempted to perform a line-for-line review of the posted documents, they do appear to be confidential Microsoft documents with annotation, sent internally to select staff and management on Aug. 11, 1998").

We need wonder no more. Vinod Valloppillil's paper, "Open Source Software: A (New?) Development Methodology, v. 1.00" has appeared as an exhibit [PDF] in Comes v. Microsoft. I'd say that authenticates it once and for all.

By the way, if you are by any chance trying to figure out Microsoft's policy toward standards, particularly in the context of ODF-EOXML, that same Microsoft page is revelatory, Microsoft's answer to what the memo meant when it said that Microsoft could extend standard protocols so as to deny Linux "entry into the market":

Q: The first document talked about extending standard protocols as a way to "deny OSS projects entry into the market." What does this mean?

A: To better serve customers, Microsoft needs to innovate above standard protocols. By innovating above the base protocol, we are able to deliver advanced functionality to users. An example of this is adding transactional support for DTC over HTTP. This would be a value-add and would in no way break the standard or undermine the concept of standards, of which Microsoft is a significant supporter. Yet it would allow us to solve a class of problems in value chain integration for our Web-based customers that are not solved by any public standard today. Microsoft recognizes that customers are not served by implementations that are different without adding value; we therefore support standards as the foundation on which further innovation can be based.

Um, what? They "need" to do it? Surely there is no technical need, unless you wish your own customers to have a superior experience and shut out all others, which is fine, but not in a standard. Standards are supposed to be for everyone.

Microsoft's "value add" to HTML resulted in browsers like Opera having difficulty displaying web sites, something I've written about before. Here's a snip from the Valloppillil memo, including some suggestions on how to beat Linux:

Open Source Software (OSS) is a development process which promotes rapid creation and deployment of incremental features and bug fixes in an existing code / knowledge base. In recent years, corresponding to the growth of Internet, OSS projects have acquired the depth & complexity traditionally associated with commercial projects such as Operating Systems and mission critical servers.

Consequently, OSS poses a direct, short-term revenue and platform threat to Microsoft -- particularly in server space. Additionally, the intrinsic parallelism and free idea exchange in OSS has benefits that are not replicable with our current licensing model and therefore present a long term developer mindshare threat. ...

OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market....

* Fold extended functionality into commodity protocols / services and create new protocols

Linux's homebase is currently commodity network and server infrastructure. By folding extended functionality (e.g. Storage+ in file systems, DAV/POD for networking) into today's commodity services, we raise the bar & change the rules of the game.

Now think about Ecma 376 and proprietary extensions, please. Remember Bob Sutor's warning?

...by standardizing its formats in ECMA, Microsoft should be giving up the right to include proprietary extensions of the spec when it creates its implementations. Repeat after me: NO PROPRIETARY EXTENSIONS

What might "value add" features written "above the standard" do to a standard? Is it still a "standard" if only Microsoft can fully implement it? This time, it's actually worse than writing above the standard. Microsoft is offering a competing "standard" instead of just writing above the standard ODF. Is that going to increase interoperability? Or will it shut people out? Yet the whole point of XML is interoperability, is it not? -- and isn't the goal of Massachusetts and others to ensure that everyone can access documents with full fidelity, not just certain customers of a certain vendor? How can proprietary extensions in a competing standard *not* clash with such a goal, unless someone insists at a minimum on guaranteed 100% full fidelity interoperability in both directions? And frankly, if you can guarantee that, what, pray tell, is the point of having two standards?

If that doesn't convince you, here's another exhibit from Comes v. Microsoft, Exhibit PX01413.pdf, a 1992 memo from bradsi to cameronm, jonl, mikemap and paulma:

we can doc the api's we know the apps group (and other isv's) use. this is a good practice. though it's not as straightforward as it appears, since some of the calls depend on context and an understanding of the source....

the biggest advantage our apps group has is access to the operating systems source. as long as this continues, the issue will never go away.

And here's another, Exhibit PX01614 [PDF], a memo from 1992, Dennis Adler to bradsi and davidcol:

You never address the issues Schulman raised in his mail. You continue to say, "There was no advantage to MS in using these APIs." Get real. You mean to tell me that the Word & Excel teams put in a bunch of API calls that they do not think would help them in a particular area? I hope not!

There is even one case (QCWin) where the "documented" use for the API SetMessageQueue enables QCWin to wait until the app it is debugging has a msg queue in place before sending it messages; this is clearly advantageous....

Stop trying to pretend that we did not do this to gain a competitive advantage, however slight. If that is not why these programmers used the undoc'd APIs in there [sic] code, then give me a plausable explanation for why they did.... truthful would be nice too.

More than a decade later, APIs are still the issue.

As I mentioned, I've written earlier about HTML and what Microsoft's value add did to the Internet, in an article "Reactions to MS's "Glimmer of Openness" & a Little Water Under that Bridge", but I'd like to repeat part of it here, the water-under-the-bridge part, so Groklaw's many new readers who are here specifically to read about ODF-EOXML can read it too in this context. After all, Microsoft defended the Halloween Memo I as being merely a hypothetical suggested strategy, not Microsoft's actual position or strategy. But what does the history show? Remember that this article is from 2005, so some things are included as history. For example, if you try to validate the HTML on the Microsoft page cited in the artilce today, by clicking on the link, there are now 32 HTML errors listed, not 68, and Ray Ozzie's page has 93, not 98. Why can't Microsoft just apply the standards so there aren't any HTML errors? As I asked in 2005, is it because they don't know how to write HTML according to the standard? Here you go, so you can make up your own mind about Microsoft's history with standards and whether it bears on the current discussion about ODF/EOXML:

********************************

Microsoft must be puzzled. Why is it almost no one trusts them, even when they do something that on its face looks good? Here they've announced a patent covenant for their XML, and we're all out here with our magnifying glasses looking for gotchas. But let's face it. There's a lot of water under this bridge. The burnt child dreads the fire and all that. We remember Netscape and Java and everything, all those tricky Microsoft gotchas. It's hardly irrational to look for more. *Not* looking for them would be irrational, given the history. In fact, let's review a little Microsoft history.

We remember when Microsoft joined the World Wide Web Consortium (W3C), an international consortium which develops Web standards and guidelines, to build consensus around Web technologies such as for HTML. Despite being a member, Microsoft developed their own proprietary HTML extensions anyway, their own little tweaks and twists, on the specification, which degrades the display of a good deal of the web by other browsers, simply because Microsoft won't follow the standard themselves, or maybe worse. They hold a dominant position in terms of numbers of users. You know, that old monopoly thing. So it's a meaningful negative effect. So just joining a standards group doesn't necessarily mean Microsoft will play fair. Remember this little incident in 2001?

Last week, people who tried to visit MSN.com with a non-Microsoft browser found themselves locked out. Although Microsoft's own Internet Explorer easily accessed the popular site, other browsers--such as Opera, Mozilla, Amaya and some versions of Netscape--received error messages and recommended that people "upgrade" to Internet Explorer.

The purpose of standards is so that everyone can speak the same "language," so to speak. Remember when that airplane crashed, because the air traffic controller and the pilot didn't speak the same language? The Web is international. It's just a lot of computers all over the world trying to interact. Without an agreement on how to meaningfully and seamlessly do that, the value of it goes down, which means that by doing what it did with HTML, Microsoft devalued the Web for everyone else, while enhancing its own market position. Just a few little extensions, and gotcha.

Think that's ancient history? W3C has a validation service, where you can go this very day and check your HTML for errors. Here's the W3C's validation report on msdn.microsoft.com: "Failed validation, 68 errors....This page is not valid HTML 4.0 Transitional". There are more than 68 errors, but some are duplicative. Is it because Microsoft doesn't know how to write HTML? They joined W3C. They know how. They don't care.

Here's another example, the report on another Microsoft page, one from their XML Development Center ("The language of information interchange"), with Ray Ozzie's name on it, on their RSS specification "Simple Sharing Extensions for RSS and OPML," at http://msdn.microsoft.com/xml/rss/sse/: "Failed validation, 97 errors. . . . This page is not valid HTML 4.0 Transitional." Well, W3C should know.

By the way Microsoft's copyrights in this specification were licensed with fanfare under a liberal Creative Commons license, which drew praise from some, but skepticism from others.

So, ironically enough, Microsoft presents information on its RSS "sharing extensions" using HTML that can't pass W3C's HTML validation. That worries some people, as do the "extensions" to RSS.

Why does it matter? What happens if your HTML doesn't validate properly? I'll let W3C explain:

What is Markup Validation?

Most pages on the World Wide Web are written in computer languages (such as HTML) that allow Web authors to structure text, add multimedia content, and specify what appearance, or style, the result should have.

As for every language, these have their own grammar, vocabulary and syntax, and every document written with these computer languages are supposed to follow these rules. The (X)HTML languages, for all versions up to XHTML 1.1, are using machine-readable grammars called DTDs, a mechanism inherited from SGML.

However, just as texts in a natural language can include spelling or grammar errors, documents using Markup languages may (for various reasons) not be following these rules. The process of verifying whether a document actually follows the rules for the language(s) it uses is called validation, and the tool used for that is a validator. A document that passes this process with success is called valid.

With these concepts in mind, we can define "markup validation" as the process of checking a Web document against the grammar (generally a DTD) it claims to be using....

Is validity the same thing as conformance?

No, they are different concepts.

Markup languages are defined in technical specifications, which generally include a formal grammar. A document is valid when it is correctly written in accordance to the formal grammar, whereas conformance relates to the specification itself. The two might be equivalent, but in most cases, some conformance requirements can not be expressed in the grammar, making validity only a part of the conformance....

Why should I validate my HTML pages?

One of the important maxims of computer programming is: Be conservative in what you produce; be liberal in what you accept.

Browsers follow the second half of this maxim by accepting Web pages and trying to display them even if they're not legal HTML. Usually this means that the browser will try to make educated guesses about what you probably meant. The problem is that different browsers (or even different versions of the same browser) will make different guesses about the same illegal construct; worse, if your HTML is really pathological, the browser could get hopelessly confused and produce a mangled mess, or even crash.

That is, of course, what happens to browsers that compete with Microsoft when they try to display pages written in Microsoft's proprietarily-twisted HTML. Users who don't know that it is Microsoft's HTML causing the problem are likely to think it's their browswer's fault, and switch to IE, imagining it's "better". You think it is deliberate?

Or remember what happened to WordPerfect? You can read about it in the current Novell v. Microsoft antitrust litigation. Here's Novell's complaint, and here's just a small part of what they are alleging:

55. A top Microsoft executive wrote that Microsoft should "smile" at Novell, falsely signifying Microsoft's willingness to help the two companies' common customers integrate their various products, while actuaIly "pulling the trigger" and killing Novell. Indeed, Microsoft's Chairman and CEO, Bill Gates, instructed his executives to develop plans to retaliate against Novell for its cooperation with the government authorities investigating Microsoft. As explained below, Microsoft fulfilled these instructions by withholding technical information about the ever-changing functions of Windows, including the integrated browsing functions in Windows 95, and by excluding Novell's office productivity applications from the major channels of distribution and other potential platforms....

71. During the development of Windows 95, Microsoft's executives schemed to integrate the browsing functions into Windows 95 in a manner designed to cause the maximum possible damage to competitors. ... For instance, Microsoft intentionally made the use of any browsing technology other than Microsoft's browser a "jolting experience" for its own Windows customers, solely to create the false impression that other browsers were not effective. ...

72. As a result of Microsoft's integration of the browsing functions into Windows, ISVs needed documentation of the browsing extensions to design their applications to perform the most basic file management functions. Microsoft initially documented the browsing extensions in the beta releases of Windows 95 and otherwise appeared to cooperate with ISVs in developing applications for release with Windows 95....

73. Microsoft "evangelized" the benefits of using the browsing extensions. In the early stages of developing WordPerfect for Windows 95, Novell thus devoted significant resources to ensuring compatibility with and otherwise exploiting the benefits of Windows' integrated browsing functions. Further, as encouraged by Microsoft, Novell expended additional resources to expand upon the extensions, providing still greater functionality for its own customers and potentially for other ISVs and their customers. ....

74. In an e-mail dated October 3, 1994, however, Bill Gates ordered his top executives to retract the documentation of the browsing extensions, but only until Microsoft's own developers of the Office suite of applications had sufficient time to work with the hidden extensions to build an insurmountable advantage over competitors such as WordPerfect. Gates further explained that without this advantage, Office could not compete with the major ISVs.

75. In public test versions of Windows 95 released a few months before the final product shipped to consumers, ripped out these programming interfaces without warning to Novell. After Microsoft withdrew the documentation of the browsing extensions, Novell was suddenly unable to provide basic file management functions in WordPerfect; in many instances, a user literally could not open a document he previously created and saved. Indeed, WordPerfect could no longer use the functions that Novell had innovated atop the extensions, while Microsoft Word could still take advantage of such innovations.

76. When Novell asked Microsoft why it removed the Explorer interfaces and browsing extensions, Microsoft claimed that it did not have the time and resources to complete their development. But in fact, the Explorer interfaces and browsing extensions had been complete and functional before Microsoft removed them. ...

77. Thereafter, when Microsoft released Windows 95 and Office 95, at virtually the same time, Microsoft suddenly reversed course and documented the programming interfaces. Doing so voided the alternatives that Microsoft previously forced Novell to expend an entire year developing and, at the precise moment when WordPerfect needed to enter the market, forced Novell to spend additional time designing basic functions of WordPerfect all over again. . . .

83. In addition to withholding technical information, Microsoft created and controlled new "industry" standards and established unjustified certification requirements to delay the release of Novell's applications and to impair their performance for Novell's customers.

84. First, as discussed above, Microsoft excluded from the markets the "OpenDoc" technology for sharing information among applications, by using its monopoly power to force a different standard upon the industry. . . .

85. Microsoft responded to this competitive threat by preventing CIL from making OpenDoc compatible with Windows 95. For example, Microsoft routinely required all ISVs to execute nondisclosure agreements as a condition of receiving the information they needed to develop their applications. These agreements, however, contained terms that uniquely targeted ISVs who were members of CIL, by preventing their employees who worked on OpenDoc from receiving Windows 95 betas or specifications, which effectively prevented CIL from initially developing OpenDoc for Windows 95. In addition, Microsoft required ISVs working with a Windows 95 beta to agree that they would not work on OpenDoc for two years. While Microsoft eventually dropped this requirement, its impact had immediate anticompetitive effects on OpenDoc's development.

86. Further, Microsoft unilaterally announced that OLE would be incorporated directly into Windows, instead of existing independently of the operating system as a technology to be adopted or rejected by ISVs, depending on their assessments of its technical merit. Microsoft then required OLE-compatibility as a condition of Microsoft's certification of an application's compatibility with Windows 95. This certification requirement was a significant barrier to entry into the applications markets, because Microsoft represented to the industry that any application lacking the certification could not be trusted to run on Windows 95. By exploiting this barrier to entry, Microsoft forced ISVs to make their applications OLE-compatible. Furthermore, Microsoft ensured that only applications using its tools, and not those of its competitors, would reach customers. This anticompetitive behavior by Microsoft is similar to the behavior described in the Government Suit with respect to Microsoft's efforts to force ISVs to use Microsoft's implementation of Java. "Specifically, in the First Wave agreements that it signed with dozens of ISVs in 1997 and 1998, Microsoft conditioned early Windows 98 and Windows NT betas, other technical information, and the right to use certain Microsoft seals of approval on the agreement of those ISVs to use Microsoft's version of the Windows [Java virtual machines] as the 'default.'" Findings of Fact ¶401.

87. There was no valid technical or business reason for requiring OLE- compatibility as a condition of the Windows 95 certification; OpenDoc was even more capable of providing the same linking and embedding functions, and in the absence of the certification requirement and other anticompetitive acts, OpenDoc and OLE would have continued to compete on their technical merits. Indeed, Microsoft initially announced that applications using OpenDoc would be deemed OLE-compatible, and would receive Microsoft's certification for Windows 95, because OpenDoc was a "superset" of OLE, meaning it provided every function of OLE, and more. Later, after Novell, other ISVs and CIL were far advanced in their efforts to develop and use OpenDoc, Microsoft announced that applications using OpenDoc would not receive automatic certification, and might not receive certification at all.

88. Seeing that Microsoft's anticompetitive acts would ensure the demise of OpenDoc, ISVs were left with no choice but to adopt Microsoft's proprietary OLE protocol as the de facto industry standard for linking and embedding. Even after making OLE the industry standard, however, Microsoft still withheld specifications and final, debugged versions of OLE until after Microsoft released its competing applications. Microsoft's anticompetitive acts concerning OLE further increased the "time-to-market" lead that Microsoft's office productivity applications unlawfully achieved over Novell's applications.

89. Second, Microsoft required office productivity applications seeking Windows 95 certification to be compatible with the very different Windows NT, which is an operating system for larger and more powerful computers that are used as "servers" to link numerous PCs (and peripherals) across an organization into a network. There was no justification for this requirement. Further, Windows 95 and Windows NT were so dissimilar that an application running on one system could not run on the other without substantial modification. Novell expended significant development resources to make its applications compatible with Windows NT, resulting in further delay in the release of Novell's applications for Windows 95.

90. Third, Microsoft unilaterally made the proprietary Rich Text Format ("RTF") of Microsoft Word the standard file format for text-based documents in applications developed for Windows. Upon capturing the standard, Microsoft strategically withheld the specification to injure competitors, including Novell.

So, as you can see, any announcement from Microsoft about standards comes in a context. Do you see why some are saying that there must be no proprietary extensions in Microsoft's XML?

Or let's go back in time a bit and read the Caldera Statement of Facts in the DR DOS case, the section called FUD Drip Feed. That case settled prior to a court ruling, so keep that in mind as you read, but it was settled with money from Microsoft going to Caldera. A lot of money. You can read in the document numerous allegations of tricks Microsoft employed to make sure its competition was always a dollar short and a day late, such as by not providing them betas to work with in a timely manner. And here's one of my favorite paragraphs:

32. The "death spiral" is somewhat of a term of art at Microsoft. On October 18, 1991, Mike Maples enquired of several executives: "I would like to ask you to invest half a day with me following Comdex. What I would like to brainstorm is how to push Excel over the top and Lotus out of business." To which Silverberg replied: "I'd be glad to help tilt lotus into the death spiral. I could do it friday afternoon but not saturday."... At a management conference in June 1992, one of the "6 Core Strategies to build share" included "Drive competitors into a death spiral," complete with objectives and tactics. ... Ironically, other discussion there focused on "Our Image" and how to overcome the industry perception of "Microslop," "Microshaft," and "Microsleaze."

Microsoft is not known for peaceful coexistence. So, you will have to forgive us if some of us are allergic to Microsoft promises of cooperation and openness. There is some history here.

Let's end with Tim Bray, who asks the obvious question ("Why Should There Be Two?") and has a very sensible suggestion:

The ideal outcome would be a common shared office-XML dialect for the basics -- and it should be ODF (or a subset), since that’s been designed and debugged -- then another extended vocabulary to support Microsoft features, whether they’re cool new whizzy features or mouldy old legacy features (XML Namespaces are designed to support exactly this kind of thing). That way, if you stayed with the basic stuff you’d never need to worry about software lock-in; the difference between portable and proprietary would be crystal-clear. And, for the basic stuff that everybody uses, there’d be only one set of tags.

This outcome is technically feasible. Who could possibly be against it?