How MAPI Beat VIM (an historical footnote)

In a post on ZDNet today, David Berlind points out that Microsoft’s grip on the desktop market is due not only to the Office Suite but also to MAPI.  MAPI? You ask if you’re not a messaging nerd.  Yup, MAPI – Messaging Application Program Interface. David is kind enough to ask “Tom Evslin where are you?” when he first mentions MAPI (and then even kind enough to point to this blog in answer to his question).

So I thought I’d also answer another question for history buffs: how Microsoft fought back a coalition of Lotus, Apple, Borland, IBM, MCI, Novell, Oracle and WordPerfect who were pushing VIM (Vendor Independent Messaging), won the messaging API war, and, partly because of this victory, overtook Lotus, which offered Notes at the high end and cc:Mail at the low end, to become the world leader in messaging.

I was running the Microsoft Mail group when we developed MAPI and defeated VIM. So you can blame me (partly) if you hate your Exchange Server or your Outlook client.

Just as a refresher, APIs are the interfaces by which one program tells another one what to do.  A good set of APIs turn a product into a PLATFORM.  Other developers write and MARKET their own products which use the platform.  Platforms (like Microsoft Exchange Server or Windows itself) can achieve long-lasting dominant market positions. I wrote more on APIs here. 

David says that MAPI was better than its competitors because  it combined mail and calendaring instead of just addressing strictly messaging issues.  He’s right but that isn’t why MAPI won.  MAPI also was more complete than VIM.  It not only allowed other clients to access the server functions of Microsoft messaging, calendaring, and directory products; it also allowed other server products to be accessed by Microsoft clients (technically, it included SPIs or Service Provider Interfaces). But SPIs, which VIM didn’t support, weren’t why MAPI won, either.

As a matter of fact, we almost lost.  Our PR position was terrible.  All the other important vendors had agreed on a common “Vendor Independent” API.  We were stubbornly holding out for our own proprietary API. Our power customers – MIS managers from big corporate clients – were beating us up for being the holdout and denying the user community the indubitable benefit of a single API supported by all vendors and proprietary to none. Somehow, even though there were only about 10,000 people at Microsoft then, we were perceived as the bully even against giant IBM and the rest of the industry.

I was booed when I tried to explain the technical virtues of MAPI to a subcommittee of the EMA (Electronic Messaging Association – used to be the Electronic Mail Association but that was judged too sexist).  And I had been popular there before I joined Microsoft.  My fellow members– many of whom were customers – demanded that we give in. Yikes!

The next meeting of the EMA was coming up – in Houston, I think, although I could be wrong. It looked like we would really get a lot of heat. Giving in wasn’t really an option.  APIs are important!  MAPI was part of the foundation of Microsoft Mail and the upcoming Exchange product. Of course, it was also better than VIM and VIM really hadn’t been implemented anywhere but in cc:Mail. But, in the days when Notes was the 800 pound gorilla, we were losing the perception war and in real danger of a user revolt. Did I mention that giving in wasn’t an option?

Without authorization from Redmond – better to beg forgiveness than waste time asking permission, I used my keynote to make an offer. We would submit MAPI to XAPIA, a committee chaired by Lotus employee Ed Owens, as a candidate for the next generation messaging API. We committed ourselves to implementing whatever XAPIA decided (although we didn’t say that we would stop implementing MAPI. After all, we had to support the developers who were already using it.) We invited the VIM consortium to do the same with their standard.

VIM refused to take the pledge!  We were the good guys, again (for a little while). Eventually VIM was submitted begrudgingly but the war was over. XAPIA later published a subset interface called CMP (Common Mail Protocol) based mainly on MAPI. But, by then, the developer community had invested in MAPI and further battles didn’t matter.

There were two key pieces of information we had when we made that proposal to EMA:

• Ed Owens is a very fair minded guy who, if anything, would have to lean over backwards not to support his employer’s API; and
• the VIM Consortium (whose members didn’t trust each other much more than they trusted us) had to be unanimous in order to take action.

Our gamble was that VIM wouldn’t be able to respond to our offer because that many bureaucracies wouldn’t be able to coordinate at the executive level during the remaining day of the meeting.  They weren’t; so they attacked the idea of submitting to an unimpeachable standards body and pissed off the customers.

I’ll let Dave Berlind finish the story: “Today, Microsoft's Exchange email and calendaring server remains one of the important reasons that organizations remain committed to other Microsoft technologies such as its operating systems (Exchange Server only runs on Windows) and Active Directory.” APIs do matter.

But, if you read his whole post, you’ll find that the real point is that there are challenges abrewing.

Comments

[Don Price]

Having invested myself in several EMA funcations and leadership roles during this time the whole API issue was hard to avoid. In a long interview with Gartner, I believe it was Steve Weiss, I discussed with him the importance of API. The struggle I had experienced in my own efforts as well as other users at the time in working email systems that were either so closed you could not do anything, or had API's that took you through hoops in order to get anything done. At the time I felt users were important to the API decision but more importantly when investing into a messaging decision, the developer community was the critical issue. In order to gurantee a robust set of solutoins around the Mail Enable Applications vision, I needed a good set of developers out there creating new solutions for my company to chose. Having been very furstrated in ever increasing user demands from a company that had gotten the email religion, and only being able to source a solution from the single company which authored the messaging system.

In that discusion I refered to the API situations as the "API Wars".

Later that week I received a follow up call from Steve where he said his briefing was going out and wanted permission to use the phrase "API Wars"; not quoting me of course. To my surprise the brief did go out refering to the MAPI vs VIM situation as the "API Wars". Well I thought this would really bring light to the situation and everything good should come up it.

We'll looking back I am not sure it was all that good. As Tom stated, XAPI was alternative proposal made to forum an inclusive initiative. It was confusing to most; those informed knew the VIM API which no one was really forth coming on content expected we users would get some richness of ideas. Across all email systems would be great; my company at the time had 11 different email systems and putting up an application was all but a guranteed impossibilty.

In the end none of the initiatives ever brought the API robustness we needed and therefore I was faced with the very difficult task trying to decide on one systems for all! Details which are another story.

[Daniel Burgin]

I am nowhere near the expert Tom is on MAPI and other productivity protocols, but I am certainly a victim of the dominance of Exchange Server. If you happen to be an individual, and you don't want to (or can't) use Exchange, you must suffer through hack after hack to wirelessly sync email, calendar, and contacts.