Mimicking Microsoft's Middleware Strategy
May 29, 2002
So, does providing middleware confer a strategic advantage? Certainly, DOS and Windows have been good for Microsoft (Nasdaq: MSFT) . Microsoft did not just provide these platforms; it also sold development tools for them.
Better yet, the company wrote applications that ran only on DOS and Windows (except for a small side business focused on Macintosh applications). By narrowing its focus, Microsoft was able to concentrate on making better applications rather than worrying about cross-platform development.
Also, DOS and Windows were compelling enough to application writers and users that Microsoft was able to charge money for them. This is very unusual for middleware.
Usually, a middleware layer must be given away to encourage users to install it.
Otherwise, you get a vicious circle in which users don't want to pay for middleware, which means application writers can't assume users have it on their systems, which means fewer applications will target the middleware layer, which makes it even less likely that users will pay for it, and so on.
However Microsoft managed to avoid such an outcome -- either through a gift horse received from IBM (NYSE: IBM) , aggressive platform evangelism or strong-arming OEMs. It was an impressive feat to turn this normally negative cycle into the virtuous one that now drives Windows sales. Remember that the cross-platform support offered by middleware directly benefits programmers, not users.
Most users run just one operating system and don't care if their applications run on a different one. Developers, on the other hand, benefit directly from easy portability because it greatly reduces their development costs. It's very hard to convince users to pay for a middleware layer that benefits them only indirectly.
So, how does Microsoft's approach to DOS and Windows compare with what Sun, Netscape/AOL and Real (as well as Microsoft) are trying to do with their middleware?
First, consider old-style middleware, which exports an API (application programming interface) that applications target. The two best-known current examples are Sun's Java and Netscape's plug-in architecture (for its browser). Although both companies made noise about replacing Windows in the hearts and minds of programmers, in neither case did they actually follow Microsoft's model.
Neither Sun nor Netscape was attempting to build a business by selling applications that targeted the APIs their middleware exported. Both companies had to give away their middleware to encourage widespread adoption. They did not attempt to overcome the "feature lag" issue by working closely with hardware vendors. Instead, they targeted a well-defined subset of the functionality that Windows offered.
Unfortunately, this was a hopeless business model. Both companies generated a lot of positive buzz, but there was no way to translate that buzz into money. Targeting a subset of Windows that covered perhaps 80 percent of applications might have seemed reasonable -- but consider that the key to Windows' success over DOS was that it covered more than 100 percent of what DOS did.
Java and Web browsers are simply not enough of an advance over Windows to justify charging money for them. Gaining cross-platform support but being saddled with feature lag is a tradeoff that makes no sense when more than 95 percent of PCs run Windows.
The second type of middleware, and the one of most concern to the nine holdout states in the Microsoft antitrust trial, encompasses applications that do not expose an API but, instead, are platforms for data: media players, instant messengers and the page-viewing components of Web browsers.
It is not actually clear why such applications are labeled middleware. How is an instant messenger different from an e-mail client? How is a media player different from a word processor? Exposing APIs, if these applications do so at all, is a minor part of their overall purpose.
This confusion makes it even less likely that controlling this "nouveau middleware" will provide any strategic advantage (or income) to its owners. As with Java and browsers, the middleware itself is given away. The "applications" -- media streams, messages and Web pages -- are fairly trivial to "port," if that term even makes sense. Content can be easily encoded in a different format, Web pages viewed in a different browser.
Companies misunderstand Microsoft's success. They think that because controlling the API in Windows has been a huge advantage for Microsoft's applications, controlling a media player format also must pay off.
But Microsoft succeeded because it was able to make Windows widely available while still charging money for it, and it was able to reap benefits by focusing its application development efforts on a single platform. In contrast, Apple (Nasdaq: AAPL) controls its API and has not translated that control into application dollars.
So, you might ask, why is Microsoft risking a judicial mandate of fully modular Windows just to protect its right to include something that turns out to be not that important?
That's a good question. Next time you see Bill Gates, you can ask him.
Adam Barr worked at Microsoft for more than 10 years before leaving in April 2000. His book about his time there, Proudly Serving My Corporate Masters, was published in December 2000. He lives in Redmond, Washington. Adam can be reached at firstname.lastname@example.org.