The USA's justice system is adversarial, meaning that it pits two teams of lawyers—the prosecution and the defense—against each other in the search for truth. The prosecution emphasizes the truths that support a verdict of "guilty," while the defense emphasizes the truths that support a verdict of "not guilty." Neither team lies, but neither team tells the whole truth, either. Each side tells a version of the truth that is biased in its favor. The jury decides which version of the truth is the most compelling.

Standards battles between platform vendors work very much the same way. Each platform vendor fields a team of Technology Evangelists (TEs) who are pitted against each other in the search for truth. Each team of TEs emphasizes a version of the truth that favors its platform over all others. Each Complementary Goods Developer (CGD) listens to the debate and decides which version of the truth is the most compelling.

There are two important differences between the two systems, however.

• First, in legal trials, a judge ensures that neither team cheats. In standards battles, however, there are no judges. Independent analysts serve a similar function, but their weak business models make them susceptible to bribery by platform vendors.
• Second, lawyers are bound by a strict code of ethics. Any lawyer who violates that code can be disbarred, losing the right to practice law ever again. On the other hand, such a code of ethics also protects lawyers from pressure from clients or employers to perform unethical acts. In Technology Evangelism today, there is no code of ethics for TEs, nor any protection for TEs whose employers attempt to pressure them into performing unethical acts.

I don't know how to fix the analysts' business models to make them less bribe-able. However, professionalizing TE could raise its ethical standards considerably, and defend TEs from their employers' pressure.

Given the low esteem in which lawyers' ethics are held by the general population, Technology Evangelism could perhaps aim higher. However, the adversarial system has served the interests of justice reasonably well for centuries, and provides a good metaphor for Technology Evangelism.

[Added December 13 2008] I'm now reading the Dalai Lama's Ethics for the New Millennium, which I hope will provide me with a ethical framework for evangelism that's more satisfying that the one described in this posting. Is "having the ethics of lawyers" really the best that evangelism can aspire to? I hope not.

Many of the TE practices that I now consider to be unethical involve hidden influence. Exposing such influence would make them ethical. Biased, perhaps, but as long as this bias is transparent, it's ethical.

The purpose of Technology Evangelism, when applied to new technology platforms, is to make that platform the first to attain a critical mass of complementary goods. At that point, network effects kick in, and the value of the network effect attracts the majority of the market to the leading platform, thereby increasing its network value even further. This positive feedback loop drives the platform to industry domination, pushing all competing platforms into relatively tiny (and unprofitable) niches. Technology Evangelists (TEs) get the positive feedback loop started by organizing circumstances to make their platform the most appealing to Complementary Goods Developers (GCDs), and by making sure that CGDs know about their platform's appeal.  So far, so good.

However, a platform vendor's TEs are perceived to have a vested interest in the success of their platform—because, of course, they DO have such an interest—and therefore their claims about their platform's virtues tend not to be credible. To overcome this, TEs seek independent sources of credibility. Three such sources are independent consultants, independent analysts, and independent third-party CGDs (the latter being "just like me," from every other independent CGDs' perspective).

The support of independent consultants and analysts provides an argument by authority, while the support of CGDs provides social proof. Both of these are logical fallacies, but the human psyche is hard-wired to give them great weight, so they are very effective fallacies (see Cialdini, Influence: Science and Practice). Taking advantage of them is not, I believe, inherently unethical; it's just how human beings persuade each other. When the subject matter of a decision is very complex, individuals simply don't have the time to conduct a thorough investigation of the facts for themselves. Relying on social proof and authority is a practical short-cut to decision-making.

Where the ethical line is crossed, I submit, is when the support of these early adherents is gained by hidden inducements.

Hidden inducements to CGDs

Consider the case of a CGD that is offered the opportunity to participate in a platform's FirstWave program. Such programs generally give the participating CGD a combination of technical support and co-marketing support, which (respectively) lower the cost and increase the benefit of supporting the new platform. Given that supporting ANY new platform tends to be very expensive, such a program is a strong inducement to support a given platform. Furthermore, the CGD to which such a program is offered knows full well that if it does not accept the offer, its competitor probably will (such programs tend to include only one product from each category). To enter the program, the CGD must sign a Letter of Agreement (LoA) that described the benefits to be received from the platform vendor, and the actions to be taken by the CGD in order to get those benefits. The terms of the LoA are secret.

Without the hidden inducements of such a program, the value of supporting the platform may be less than that of supporting alternative platforms. Alternatively put, the hidden inducements can make an inferior platform more appealing than a superior one.

Later CGDs, seeing the inducement-receiving CGDs demonstrating their support for the new platform, but not knowing about the hidden inducements, are led to believe that the cost of supporting the platform is lower, and the benefits higher, than they really are (to one not receiving the hidden inducements). That's the crux of the problem.

The solution is simple: make the terms of the FirstWave LoA public at the time the participating CGDs' products are demonstrated. That way, non-participating CGDs could consider the benefits received by the program's participants when making their own platform-adoption decisions. The inducements would no longer be hidden.

A general solution

Exposing the inducements offered by TEs is, I believe, a solution to most of the ethical dilemmas of Technology Evangelism.

Consider a panel discussion at a conference, at which the merits of competing platforms are discussed for the benefit of the panel's attendees. In a "stacked panel" (see the General Evangelism Timeline, page 12), a TE secretly influences the choice of a panel discussion's moderator and panelists to favor the TE's platform. This is unethical, because the TE's incfluence is hidden.  If the TE's influence were exposed from the outset, then its attendees would understand that the panel was biased, and treat the information gleaned from it accordingly.

Likewise, if a report comparing and contrasting different platforms were known to come from an analyst on who was on Microsoft's payroll, then the report's readers could take this bias into account.

The ethical implications are clear:  a TE's influence should always be transparent.

In this January 2007 ComputerWorld article, Microsoft's disavowal of the Plamondon Files is presented as follows:

A Microsoft spokesman dismissed the comments today, saying they don't represent the company's philosophy and never did. "These were isolated, inappropriate comments made more than a decade ago and not a statement of Microsoft's policy at any time," said Jack Evans, a Microsoft spokesman.

Like all good disinformation, it contains a kernel of truth. "The comments" described in the article consisted of

1. Calling Independent Software Vendors (ISVs) "pawns in the struggle between platform vendors" (Comes v Microsoft, Exhibit 2456, page 1), and
2. Saying that it's OK for Microsoft to lie to ISVs in order to get them to support Microsoft's platforms (Comes v Microsoft, Exhibit 2456, page 2).

Comment #2: Is it OK to lie to ISVs?

Here's what I said:

You’re going out with a girl, what you really want to do is have a deep, close and intimate relationship, at least for one night. And, you know, you just can’t let her feel like that, because if you do, it ain’t going to happen, right. So you have to talk long term and white picket fence and all these other wonderful things, or else you’re never going to get what you’re really looking for. So you can’t let them feel like pawns, no matter how much they really are.

Anyone hearing me say this would reasonably infer that it was OK for TEs to mislead ISVs into thinking that the TE was offering a long-term relationship when in fact only a short-term relationship was being offered. In short, they would infer that it was OK to lie. That was not at all what I intended.

What I meant to say was that TEs were expected to move on to a new set of ISVs for each new technology, while leaving long-term relationships to Microsoft Developer Network (MSDN). This was a change in policy from when I joined Microsoft's Developer Relations Group (DRG) four years earlier (1992), because then MSDN had only recently started. Unfortunately, I got lost in my spur-of-the-moment metaphor, and said something that was neither true nor to the point.  This metaphor was misguided in and of itself, by implying that it was OK to lie to girls to get them into the sack.  "Locker-room talk," perhaps?  Maybe, but still wrong.

Earlier that day, in presentation called "Evangelism Strategy" (page 12), I had emphasized the importance of telling the truth:

The one-night-stand metaphor was just plain wrong.  I'm sorry that I used it. I did NOT use it in Microsoft's subsequent mandatory training seminars for DRG's newly-hired TEs. Hence, Microsoft's 2007 disavowal of this comment is correct.

Comment #1: Are ISVs pawns in the struggle between platform vendors?

Here's what I said:

ISVs—independent software vendors—are pawns in the struggle between platform vendors.

Well, that's pretty clear.

The central purpose of the official training program that arose from the DRG Summit was to emphasize to a TE's job was to ensure that Microsoft's technologies were the first to attain a critical mass of ISV support. Helping ISVs was a means to this end, not the end in itself. This concept is central to Platform Evangelism, and it's perfectly ethical and correct. In developing metaphors to make this concept clear to Microsoft's newly-hired TEs, I chose those metaphors which emphasized the TE's viewpoint, not the ISV's viewpoint, as was appropriate in a TE training seminar. Hence the pawns metaphor.

Yet even from the TE's viewpoint, the pawns metaphor was (and remains) flawed, which is why I had to patch it up by saying:

We cannot succeed without them [ISVs]. If you’ve ever tried to play chess with only the pieces in the back row, you’ve experienced losing, OK, because you’ve got to have those pawns. They’re essential. So you can’twin without them, and you have to take good care of them.

Furthermore, a pawn can't change sides in the middle of a game, but ISVs can switch sides at any time. If an ISV doesn't like the way it's being treated by a platform vendor, it can switch platforms. It could also be acquired by a competing platform, or even start offering its own competing platform. I made this point, too.

They are today’s allies; tomorrow, who knows? Tomorrow, you know, it could have been that Netscape was a little applications company that we thought was great and we worked with, and then suddenly they came up with this competing platform. The bastards! And you never know which way they’re going to go. They also could join up with, you know, IBM. We worked closely with Lotus for years. Lotus was one of our stronger supporters of OLE, and yet, then IBM bought them.

So I knew the pawns metaphor was flawed, but it was the best that I could come up with at the time.

As I recall, Dave Winer was the first to describe platform vendors as providing the infrastructure for a garden—soil, sun, and water—and then inviting gardeners to come plant crops there. That's a much more accurate metaphor. Every platform vendors is competing for independent gardeners by providing more nutritious soil, brighter sunlight, and purer water, plus an ever-expanding list of services that make gardening simpler, easier, and more profitable.

Nonetheless, the "ISVs are pawns in the struggle between platform vendors" metaphor continued to be used in Microsoft's subsequent mandatory training seminars for DRG's newly-hired TEs, and as such was Microsoft's "policy" towards ISVs at the time (at minimum, 1996-1998). Hence, Microsoft's 2007 disavowal of this comment as "not [being] a statement of Microsoft's policy at any time" is incorrect.

So, where's the disinformation?

The "one-night-stand" metaphor was a mistake, not repeated in DRG's subsequent mandatory TE training seminars. However, the "pawns" metaphor WAS used in these mandatory seminars, and as such embodied Microsoft's policy. For Microsoft's spokesman to disavow both in the same breath was disinformation.

But that's not the real problem.  The deeper issue is that these metaphors are trivial, compared to the unethical practices encouraged in the mandatory training sessions based on the Plamondon Files. Stacked panels, zombie consultants, suborned analysts, etc.—these are the real problem. By disavowing the "isolated, inappropriate comments" above as "not [being] a statement of Microsoft's policy at any time," Microsoft drew attention to these comments alone, thus distracting attention away from the deeper problems revealed by the Plamondon Files.

Exactly as I would have done, back in the day.

Microsoft has four options in responding to the publication of this blog's content.

Firstly, Microsoft could choose to do the right thing by supporting the call for the professionalizing Technology Evangelism (TE) via a single independent organization. This is probably Microsoft's best option, because it puts the "TE Ethics" issue firmly to rest. However, Microsoft is unlikely to pursue this course, for reasons discussed below.

Secondly, Microsoft could choose to support a second TE association, competing with whatever independent TE association springs up first. It would justify this on the grounds of providing competition among associations, freedom of choice, etc., but the purpose would actually be to maximize FUD and minimize the impact of TE professionalization on its freedom of action. As with all FUD, this is a delaying tactic.

Thirdly, Microsoft could resist the call to professionalizing TE by pursuing the Three D's of Disinformation: Deny, Disavow, and Discredit.

1. Deny that the practices described in the Plamondon Files
   • were ever used by anyone at Microsoft other than me ("lone wolf"), and
   • are still in use today ("ancient history")
2. Disavow the Plamondon Files' status as embodying Microsoft's official policy at the time ("loose cannon")
3. Discredit me, by impugning my intelligence, character, motivations, current ethics, etc. ("disgruntled ex-employee").

Fourthly, Microsoft could simply dismiss the issue and hope that it just goes away.

I expect that Microsoft will progress through this list in reverse order: Dismiss, Discredit/Disavow/Deny, Delay, and then finally, when all else fails, Do the Right Thing by supporting a single professional TE organization. That path through its options is the most ruthless. Its what I would have done, back in the day.

Microsoft has a strong incentive to follow this path: profit. Microsoft has lost (or been forced to settle) a number of lawsuits that involved its TE practices as embodied in the Plamondon Files, despite its disavowal thereof (a disavowal in which, I was embarrassed to say, I was complicit through silence). However, it has now been revealed that the practices embodied in those documents were official Microsoft policy (as manifested by the requirement that all newly-hired TEs participate in training based, in part, on those documents). This revelation weakens Microsoft's defense, potentially enabling more suits, with more success, and with higher damages and/or settlement costs. Microsoft has a duty to its shareholders to resist such pay-outs. This duty could be seen as compelling Microsoft to work its way backwards through the list of options above. 

If, on the other hand, Microsoft were to skip right to Doing the Right Thing, it would speak volumes about the extent to which it, too, has turned over a new leaf.

For eight years (1992-2000), I was the driving force behind Microsoft's effort to make its Technology Evangelism (TE) efforts more efficient, effective, and ruthless, by studying both the practice and the theory of TE. After leaving Microsoft in 2000, I spurned the inquiries of numerous Microsoft competitors to testify on their behalf. As recently as year, I fell on my sword on Microsoft's behalf.

So why come forward now?

Two reasons.

First, the global financial melt-down forced an epiphany. We at Microsoft always felt that we were on the side of free markets and unfettered capitalism—you know, the Good Guys. But so did the guys at Lehman Brothers, AIG, Fannie Mae, and all of the other failed financial institutions. Even Alan Greenspan, the High Priest of free markets, has had to concede that there's "a flaw" in free market economics—a flaw that led directly to the current financial collapse.

My belief that I was one of the Good Guys was similarly flawed. This is now inescapable. I was wrong. Many of the TE practices that I developed, taught, and espoused were wrong. Anyone who continues to practice them is wrong. As a first step towards making amends for my past wrongdoing, I must make this clear, and widely known.

Second, Microsoft—where these practices were developed, welcomed, and endorsed as official policy—is this week launching its first public volley in the Mother of All Standards Battles, to control the de facto standards of cloud computing. For Microsoft, this is a life-or-death struggle. When Microsoft's back is to the wall, can it reasonably be expected to refrain from using the TE tactics that it KNOWS will help it win, if its use of those tactics is unrestrained?

However, my concern is not just for Microsoft. These TE practices are very effective, and now that some of them have been documented in the public record, other platform vendors will be tempted to use them, too, when their backs are against the wall.

This problem can only be treated, I believe, by professionalizing TE, and thereby inoculating platform vendors against unethical TE practices.

That's why I felt compelled to come forward now. Only now have I realized how wrong I was, and by coming forward now, in the opening skirmishes of the Cloud Computing Wars, I can begin to make amends for my past wrong-doing.

In a standards battle, Technology Evangelists (TEs) represent platform vendors to Complementary Goods Developers (CGDs). CGDs rely on the information provided by TEs, among other sources, to decide which platform(s) to target. Making the right platform-targeting decisions can make or break a CGD. For example, being slow to target Microsoft Windows 3.0 (perhaps due to Microsoft's "head fake" towards OS/2) led to the decline of Lotus 1-2-3, WordPerfect, and other competitors to Microsoft's applications.

The stakes being so high, it is reasonable for CGDs to demand that platform vendors and their TEs follow a strict code of ethics.

However, CGDs are not the only ones at risk from unethical and anti-competitive TE practices. The people—as in, "we, the people"—have an interest in these TE practices, too. Microsoft has lost or been forced to settle several anti-trust lawsuits that involved TE practices, including United States v. Microsoft, Sun v. Microsoft, and Comes v. Microsoft. For example, a core finding of United States vs. Microsoft was that one of Microsoft's key TE tools, the FirstWave Program—the first version of which, for Windows 95, I helped create—was anti-competitive. Likewise, one of the key issues in Comes vs. Microsoft was Microsoft's use of unethical Technology Evangelism practices in erecting an "Application Barrier To Entry" (see page 30 here) to defend Windows from competitors. The erection of such barriers can be seen as the sole function of Platform Evangelism, which is a subset of Technology Evangelism. Hence, the ethics of TE is a matter of the public welfare.

Traditionally, the public need for ethical behavior from individuals whose has been met by professionalization—that is, by creating a new profession.

Well-known professions include accounting, nursing, law, teaching, etc. Recently-professionalized jobs include civil engineering, real estate sales, and public relations.

Professions are characterized by four things:

1. a standard body of skill and knowledge,
2. a code of ethics,
3. a certification examination, and
4. a professional association.

These things can be created for TE, too. With a new TE profession in place, platform vendors could prove their seriousness about TE ethics, and promote the public welfare, by publicly committing (a) to hire only those TEs whose skills and knowledge (including ethical knowledge) have been properly certified, and (b) to observe the TE code of ethics.

Such professional standards aren’t perfect, or lawyers would never be disbarred. However, professionalizing TE would remove the cloud hanging over Microsoft’s—and the industry’s—practice of Technology Evangelism. With cloud computing emerging as the Mother of All Standards Battles, now’s the time for TE professionalization.

It could be argued that Microsoft's unethical Technology Evangelism (TE) practices are "old news"—i.e., that Microsoft stopped using these questionable TE practices long ago.  This is very unlikely to be the case, for at least three reasons.

Firstly, there is a huge loophole in the Final Judgment of US vs. Microsoft which keeps the door open to these practices. Section D of that Judgment reads:

III.D. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network ("MSDN") or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D, the term APIs means the interfaces, including any associated callback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release [emphasis added] of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner [emphasis added].

What matters here is the timing with which Microsoft must share information about new platform services (Application Programming Interfaces, APIs) with Independent Software Vendors (ISVs; software being a complementary good to a platform API, such ISVs are Complementary Goods Developers [CGDs]). According to the Judgment above, Microsoft is not required to share information about its new APIs until the API's "last major beta test release"—that is, just before the final commercial version is released to the market. By this point, a well-run TE campaign would already be nearly over. The support of the API by Microsoft's own products (e.g., Office) and by the participants in the API's FirstWave program would have moved the new API very close to a critical mass of support.

One of the main goals of a FirstWave program (also known as an "Early Adopter Program") is to demonstrate, at the event that marks the release of a new API's first public beta, the exploitation of the relevant APIs by the FirstWave program's ISVs' applications. That is, by the time non-FirstWave ISVs get access to the new API, their FirstWave competitors would already have an enormous head start. Furthermore, the Final Judgment defines the last beta, not the first, as being the one for which widespread disclosure is required. The last major beta comes out just before the API's commercial release, which is time at which FirstWave program participants are expected to ship their API-exploiting applications. That is, the Final Judgment requires Microsoft to release information about a new API to non-FirstWave participants only a few weeks or months before the FirstWave participants' applications ship to paying customers. This time-to-market advantage, combined with the co-marketing that Microsoft gave to its FirstWave participants, made the invitation to participate in a FirstWave program "a carrot so big that it was a stick." When offering a given ISV the opportunity to get the benefits of joining a FirstWave program (carrot), the unspoken threat was that if that ISV didn't accept, the invitation would be extended to that firm's leading competitor (stick).

Microsoft's TEs believed that the benefits of participating in FirstWave programs were so pronounced that during Windows 95's FirstWave Program, many of Microsoft's TEs (including Doug Heinrich, the Director of Microsoft's Developer Relations Group [DRG], which was responsible all of Microsoft's TE efforts at the time) formed an investment pool that bought the stock of the FirstWave program's participants. I did not participate in this fund, as I thought that those who owned such ISVs shares might put those ISVs' interests ahead of Microsoft's, thus violating their fiduciary responsibility towards their employer. (I was nothing if not consistent in placing Microsoft's interests above all others.)

The point is that this Judgment, by affecting only TE activities after the last major beta test release, does almost nothing to limit Microsoft ability to perform TE unethically, and indeed increases its incentive to put the hammer down before the last major beta test release is issued.

Secondly, to the extent that the requirements imposed by Section III.D of the Judgment had any salutary effect on Microsoft's TE practices, those requirements are now irrelevant, as the term of that section of the Judgment expired in 2007 (although the requirements of other sections were extended). Microsoft is now free to practice TE any way it damn well pleases, without let or hindrance.

Thirdly, members of the Free and Open Source Software (FOSS) community have asserted that Microsoft has used these practices in its recent evangelism as recently as last year (2007).

This is not to say that Microsoft still practices TE in precisely the same way as it did in the 1990's. Clearly, it does not. Blogging, for example, has provided a new channel for Technology Evangelism. However, the ethics of Technology Evangelism is independent of the communication technologies it uses; one can stack a panel in a virtual conference as easily as in a physical conference. That's why the professionalization of Technology Evangelism, with a strong code of ethics, is needed.

The standards battle over cloud computing is do-or-die for Microsoft. In a fight for its survival, Microsoft has the incentive, the experience, and the legal freedom to use every trick in its TE book to win. It, and all other platform vendors, must be restrained from the worst of such excesses by increasing the professionalism of its TEs.

On January 16th, 1996, a group of Microsoft's Technology Evangelists (TEs) from its overseas subsidiaries gathered at its Redmond headquarters to receive training on the strategy and tactics of Technology Evangelism (TE) as practiced by Microsoft's top Redmond-based TEs. Microsoft had no TE formal training program at the time; everyone else just "learned by doing."

At this event, called the "DRG Summit," I gave three presentations, "Evangelism is WAR!," "Evangelism Strategy," and "Power Evangelism." Marshall Goldberg gave a presentation on "Relationship Evangelism." As I recall, the DRG Summit was organized by Avery Bishop, and Ken Fowles also gave a presentation, although I came in late and missed it, so I don't recall what it was about. The training presentations were videotaped, and I arranged to have my and Marshall's presentations transcribed. These presentations were also attended by some of Microsoft's Redmond-based TEs. Many of them stated afterwards that they wished that they had received similar training.

The Director of Microsoft's Developer Relations Group (DRG), Doug Heinrich, agreed that such training should be available to Microsoft's Redmond-based TEs. He (a) assigned me to develop materials for use in training Microsoft's newly-hired TEs, (b) required all newly-hired TEs to attend such seminars, and (c) encouraged all experienced TEs to both attend these seminars and to contribute to them. My performance in leading such training seminars became, thereafter, an objective on which I was formally reviewed for raises, bonuses, and stock options.

I augmented the above-mentioned training materials with two white papers, "Effective Evangelism" and the "Generalized Evangelism Timeline." I also wrote "Making the Most of the PDC" (Professional Developer's Conference), which was used as a preface to Microsoft's official PDC staff guide for at least three successive PDCs.

I continued leading such seminars once each six months until I left DRG in 1998 for a TE role in Microsoft Research's University Relations Group. I received excellent performance reviews during this period. In January 2000, Darryn Dieken, another Microsoft TE, received copies of these materials for use in training a new group of TEs. I recall sending copies of these documents to other TE groups during the 1998-2000 period, during which DRG's function was dispersed among Microsoft's product groups, but I can't prove it.

These training materials embodied Microsoft's policies, practices, and preferences with regard to Technology Evangelism. The Director-level declaration that attendance at these seminars was mandatory for newly-hired TEs makes them "policy" by definition.

The only substantial difference between the DRG Summit's transcripts and the later training seminar presentations was my use of a "one night stand" analogy at the DRG Summit (see the top of page 2 in this transcript). In this analogy, I stated that it was OK to lie to ISVs to get them to support Microsoft's technologies. This implication that "lying to ISVs (or to anyone else) was OK" was a mistake, for which I alone am responsible, and which I deeply regret. No similar analogy, statement, or implication was included, in any form, in DRG's mandatory seminars. This analogy was made only verbally, and did not appearing in the presentation's slides. Indeed, the presentation's slides clearly stated that TEs could stress those aspects of the truth that were advantageous, but should never, ever lie. This latter view was emphasized in DRG's mandatory training seminars.

The above documents have been entered into the public record in a series of anti-trust actions against Microsoft. They have become known, collectively, as "The Plamondon Files."

It has been expedient for Microsoft to deny that these documents accurately reflected Microsoft's practices at the time, to disavow any authority I might have had to define Microsoft's policy (neglecting to mention that the training materials were sanctioned by DRG's Director), and to discredit me in various ways. Yet the the public record contains (a) a description of me as "an uber-evangelist" (by Darryn Dieken), (a) a description of me as DRG's "theoretician" (Marshall Goldberg), and (c) the statement that "everything James says [in the DRG Summit presentations] is true" (also Marshall Goldberg). The record also shows that Marshall was also a very senior evangelist, meeting regularly with Bill Gates, so his comments cannot credibly be dismissed.

Does Microsoft still utilize the TE techniques described in the Plamondon Files? Many in the Free and Open Source Software (FOSS) community believe that Microsoft does.

[Yes, I recognize the irony in using Microsoft's free Live! Spaces service to make these documents, and these comments, available to the public.]

A new standards battle is emerging between vendors of cloud computing platforms. It could turn into the Mother of All Standards Battles, because the battle's participants (currently VMWare, Google, Amazon, and Microsoft)

• have all either learned from past standards battles, or hired people with such knowledge;
• are rich (or in VMWare's case, are likely to be purchased by someone rich), enabling them to throw vast quantities of money into the breach; and
• all know that, due to network effects and bandwagon effects, the first platform to hit critical mass will tend to make huge profits and to crush competing platforms unmercifully, providing ample motivation to throw their money into the breach rapidly.

This battle is not just about the profits to be derived from the platform itself—it's about the profits to be derived applications that the winning platform vendors builds on that platform. For example, Microsoft's establishment of Windows as the de facto standard platform for personal computer applications gave its Office applications a huge boost in the market, enabling them to crush their competitors (who were slow to port their applications to Windows). According to Microsoft's 2008 Annual Report, the revenues from Office ($11 billion) earns nearly as much profit as Windows ($13 billion). Whoever controls the cloud computing platform will have a huge advantage in winning subsequent battles among cloud computing's applications.  That's why cloud computing platform vendors can afford to spend a fortune developing their cloud computing platforms and yet give them away for free. They can afford to give away the razor to sell more blades. (For the economics of this, see Oz Shy's The Economics of Network Industries and/or W. Brian Arthur's Increasing Returns and Path Dependence in the Economy.)

Because the potential upside is potentially enormous, and the downside is potentially fatal, I would expect Google, Amazon, VMWare, and every other cloud computing platform service provider to syndicate its risk by joining together in an EBM (Everyone But Microsoft) Cloud Computing Alliance, backing a single platform that they'll all agree to develop, use, and promote jointly as an alternative to Microsoft's (as-yet unannounced) platform.

These EBM alliances rarely work, for a variety of reasons.

• Politically, such an Alliance can't be formed until each potential Alliance member gives up the belief that it can win alone—a belief fueled by its head-start over Microsoft's as-yet unannounced platform. This makes such Alliances slow when speed is essential.
• Economically, before the ink is even dry on such an Alliance agreement, the participants' interests inevitably shift to minimizing their Alliance-related costs while maximizing their Alliance-related benefits. This effect could be exacerbated by the current economic downturn; short-term losses could make the potential long-terms gains of Alliance membership look expendable.
• Socially, such alliances require a bridging of corporate cultures that is difficult under even ideal circumstances.
• Individually, if and when things start to go wrong, the individual human participants often have every personal incentive to run away to some other part of their company (where their contributions to their company's bottom line are more direct and tangible) rather than to fight for the alliance's victory (which may not benefit the individual in any tangible way). Again, the current financial crisis may exacerbate this issue.

However, Google has the cash, the experience, the chutzpah, the head start, and—most importantly—the credibility needed to give Microsoft a run for its money. It does not need to form an EBM Alliance to win.  All it needs to do is execute flawlessly with a huge budget, great people, a good architecture, skilled management, efficient evangelism, and a burning passion to be the first to assemble a critical mass of complementary products. That's a tall order, but one which Google, more than any other firm today (other than Microsoft) has the capacity to deliver.

Google's cloud computing platform need not commoditize Windows in order to crush Microsoft. All it needs to do is to become the focus of NEW application development. That would make Windows a legacy system—a change in status that would send Microsoft's revenues (from Office, as well as Windows) into a death spiral. On the other hand, if Microsoft manages to win the cloud computing standards battle, then it merely regains the status quo ante bellum—Google's profiable search and advertising business would be unaffected, all else being equal.

That's why I don't count Microsoft out of the cloud computing standards battle, despite its tardiness. Like a fox chasing a rabbit, Google is running for its dinner, but Microsoft is running for its life.

For example, I would not be at all surprised to see Microsoft opening up its wallet (and other assets) to Amazon, VMWare, and Everyone But Google, in an attempt to get them to commit to Microsoft's nascent platform ASAP. Even a tiny slice of Microsoft's multi-billion-dollar cash hoard could look exceedingly tempting to credit-crunched potential partners.

These factors suggest that the cloud computing war may be nasty, brutish, and short, with its competitors throwing everything they've got into the contest just as rapidly as they can.

What fun for the rest of us!  :-)

Whenever the status quo is challenged by a new technology, or whenever an entirely new service (for which there is no status quo) is offered by different platforms, the result is a standards battle. The backers of each platform battle to establish its service's interface as the de facto standard for future complementary goods. This battle may take place in the conference rooms of official standards organizations (e.g., IEEE, W3C, ECMA, etc.), in the back rooms of alliance-forming firms, or in the marketplace, but there's a standards battle in any case.  However, the term is usually used to describe only the latter case, in which the standards battle is waged in the marketplace. That's how I'll use it henceforth.

Every new industry faces a foundation standards battle in its earliest years. This battle eventually yields a dominant design, the emergence of which ends that industry's foundation standards battle (by definition; if it didn't end the foundation standards battle, it wouldn't be "dominant"). One example is the battle between Westinghouse and Edison in the earliest years of the electrical service industry, known as the War of Currents. Such a battle tends to form the core of an industry's foundation myth. (For more on "dominant designs," see Utterback's Mastering the Dynamics of Innovation.)

After a dominant design emerges in a given industry, new standards battles will tend to erupt only when previously-integrated features become modularized sufficiently to become services, thereby shifting the industry's locus of profitability (as per Christensen's Law of Conservation of Integration, discussed in his book Seeing What's Next).

The computer industry is different. This difference is driven by its rapid and relentless reduction in the cost of computing power, which can be seen as:

• making the emergence of a dominant design impossible, or
• making the dominance of any given design temporary, or
• accelerating the rate at which features are modularized into services.

Whichever of the above views one chooses to hold—I find them to be indistinguishable in their effects—the net result is that the computer industry is characterized by frequent standards battles. The industry's earliest standards battles were between integrated hardware/software/service platforms (IBM and the Seven Dwarfs), from which IBM's IBM System/360 (plus related software & services)emerged as the dominant design. Continued cost reductions created a new market for personal computers for consumers (whose needs were overshot by mainframe and minicomputers), sparking another standards battle, from which the Wintel platform (from Microsoft and Intel) emerges as the dominant design. Other notable standards battles included the Browser Wars, OLE vs. OpenDoc, the Java Wars, and a zillion other minor skirmishes. A major battle over cloud computing platforms is gearing up right now.

Although the big operating system platform vendors (and now, cloud computing platform vendors) get the most attention, lots of smaller companies produce platforms, too. Each vertical market has its own platforms. For example, the music technology industry has a plethora of domain-specific platforms such as Yamaha's OPT, Steinberg's VST, Gibson's MAGIC, Recordare’s MusicXML, etc.. Even MusicXML—a document interchange format for music notation software, which is presumably a tiny market—faced a host of competing technologies. Clearly, the need to efficiently win standards battles is shared by a large number of firms—not just a few huge software firms.

In the influential 2001 paper The Law of Accelerating Returns, Ray Kurzweil wrote

"The paradigm shift rate (i.e., the overall rate of technical progress) is currently doubling (approximately) every decade; that is, paradigm shift times are halving every decade (and the rate of acceleration is itself growing exponentially)."

If we stipulate that each paradigm shift requires a new platform, then the rate of emergence of new platforms is accelerating, too—not just in the computing industry, but in all industries. Look, for example, at the platforms used over the history of the recorded music industry (see table below).

The gap between a given platform's emergence and its successor's emergence is shortening rapidly. New virtual music data formats can be expected to gain temporary dominance, and then decline, at an ever-accelerating rate.

This suggests that ALL industries, not just computing, will have an ever-increasing need to establish new technology platforms, and that the ability to win standards battles efficiently—the core competency of the Platform Evangelist—will become increasingly valuable.

I am particularly interested in the art and science of establishing proprietary technology platforms as de facto standards in markets that are strongly dominated by network effects. In such markets, the winning platform tends to become locked in by the consumer's switching costs. Such platforms can produce enormous profits.

The characteristic that distinguishes platforms from other technologies is that a platform exposes at least one general-purpose service through a consistent interface. The interface modularizes the general-purpose service, which enables:

• complementary goods to be developed on one or both sides of the interface, and
• innovation to proceed at different rates (and with different business models) on either side of the interface.

The selection of a platform by market forces, in the presence of network effects, is path dependent. If most of the early decision-makers choose a given platform, then its network-effect-derived benefit can become insurmountable, leading all competing platforms to fail, hence limiting the platform choices available to later decision-makers.

The economics literature usually describes the very earliest platform-adoption decisions as being "random." Minimizing this randomness is the essence of Platform Evangelism. The Platform Evangelist's job is to arrange circumstances such that her platform is the obvious choice for early adopters—ideally, a choice so obvious that its early adopters do not even realize that they have made a "choice." The Platform Evangelist's goal is to have her platform be the first, among competing platforms, to assemble a critical mass of complementary goods. By definition, once this critical mass has been reached, the combination of network effects and bandwagon effects will drive the platform to market dominance.

To be profitable, the platform must not only dominate its market, but also be defended from cloning. Anti-cloning defenses include patents and rapid evolution. Maintaining the platform's anti-cloning defense must also be cheap, relative to the platform's revenue, else the cost of defense will consume the platform's potential profits.

Platforms comprise only a small subset of the technologies, so Platform Evangelism is a subset of Technology Evangelism. Not all Technology Evangelists (TEs) will evangelize platforms. However, I submit that the theory and practice of Platform Evangelism can usefully inform all Technology Evangelism.

Between 1992 and 2000, I was a Technology Evangelist (TE) with Microsoft, where I was widely considered to be its leading TE theorist  and practitioner. For example, in the late 1990's, I was the only Microsoft employee to design and lead TE training seminars that all of Microsoft's newly-hired TE's were required to attend.

Back in 2003, I started writing a book that focused on Microsoft's TE practices in the 1990's. However, such a book would not be relevant today. The theoretical underpinnings of TE are unchanged, but the Internet has dramatically changed TE practice. I now hope to correspond with TE's around the world to learn about today's best practices. I'll attempt to place those practices into their theoretical context, and post my work here.

Please do not hesitate to comment on, criticize, or offer corrections to what you read here. I appreciate your feedback.  :-)