Through the Looking Glass

If Musoft looked in the mirror and saw the events culminating in Microsoft’s trial, it would be jealous. Though Musoft always worked to maximize profits—true to its corporate nature—Microsoft, armed with identical products but stronger IP rights, had been able to foreclose so many competitive threats and become so much more profitable! So Musoft would need to examine the relationship among rights, incentives, and strategies that set its world apart from Microsoft’s.

Back in the applications market, our major concern seemed to be that underprotecting applications could deter innovation. There, Musoft launched Mundos 1.0 as middleware and treated it as an application. But here in the platform market, where maximal profits flow to whomever owns the largest network, the situation was a little different. Consider Musoft’s calculations as it contemplates launching Mundos 95, a true platform that will define a network. Musoft would like to own that network, but in Manifestoland, Congress doesn’t award any IP rights without source-code disclosure. And disclosed source code would turn Mundos into an open standard—no one would own it. So Musoft must consider keeping its source code secret, owning the network, but relinquishing control over object-code distribution—a choice similar to the one that record companies may soon face in a P2P world.

Musoft’s choice pits revealing its Mundos 95 source code, charging for each copy of its object code, and blocking competition for a few years, against keeping its source code secret and trying to make money in various aftermarkets. The first option runs right into the network­industry dilemma; the only way that Musoft could earn a decent return on software sales would be to eviscerate the value of its network by charging a high purchase price. The second option appears to be a risky attempt to build a huge Mundos network quickly.

Paradoxically, the business model implicit in secret platform source code looks a lot like an open-source business model. Then again, perhaps that similarity is not all that odd. After all, though source code and object code are different beasts from the perspective of software developers, there’s not much difference between them to users. While open develop­ment can help a company reduce its costs, open distribution just pushes companies toward aftermarket business models and away from direct- sales business models. In that sense, the only real difference between open-source code and unprotected object code is that the original devel­oper controls the customization opportunities in the latter. In other words, a platform developer who opted out of the IP system to keep its source code secret would incur higher development costs but retain greater customization opportunities than an open-source advocate.

Suppose that Musoft, understanding these calculations and tradeoffs, chose to keep its source code secret, effectively inverting the open-source ethos even while adopting its business model. Musoft’s calculations return us to the conclusion reached back in the open source bazaar: Service-oriented business models make more sense than product-oriented models in software-infrastructure settings.

In a related vein, for platforms, the dangers of overprotection dwarf any possible fear of underprotection. In our own world, when triple pro­tection combines with a network barrier to entry, extraordinarily pow­erful rights emerge to protect software and to enable lucrative after­market opportunities.

Musoft and Microsoft both must maintain at least four sets of relationships—though given the different rights and choices at their dis­posal, the nature of those relationships are likely to differ. But one way or another, they must each deal with: the OEMs who build and sell hard­ware; the ISVs whose software must run on some platform; competing platform developers or would-be entrants into the platform market; and consumers who use their platform networks. Their parallel paths through these relationships reveal the unspoken role that IP rights played in issues raised during Microsoft’s trial.

Let’s start with the OEMs. Before Microsoft emerged as the platform monopolist, it maintained a symbiotic relationship with OEMs. Most of the OEMs’ customers wanted to buy hardware already loaded with a software platform. OEMs wanted to offer their customers as many dif­ferent platforms as possible. Microsoft’s interest, like that of its platform competitors, lay in making its platform available to as many consumers as possible, regardless of their hardware choice. Platform developers and OEMs were in rough power parity. Neither side would have benefited from an exclusive agreement.

But network economics correctly predicted that the platform market would eventually tip to a standard. As it happened, a critical mass of consumers began demanding that OEMs provide them with turnkey systems running Windows. These demands gave Microsoft some serious negotiating power vis-a-vis the OEMs. At trial, the government was able to demonstrate that Microsoft:

charges different OEMs different prices for Windows, depending on the degree to which the individual OEMs comply with Microsoft’s wishes.

Microsoft bestowed favor upon some OEMs and spewed venom upon others. And of all the OEMs, it was IBM that proved to be the greatest target of Microsoft’s ire. Why? Remember OS/2? That wonderful graph­ical interface that would someday displace DOS? The one on which Microsoft had not only partnered with IBM, but invested such great development resources that it even let DR-DOS surpass MS-DOS as the finest DOS on the market? Well, IBM finished the project on its own after Microsoft quit to focus on Windows. OS/2 had the potential to compete with and to surpass Windows, and IBM wanted to offer con­sumers a choice. IBM was perfectly willing to sell consumers its hard­ware equipped with Windows. But it also wanted to offer an entirely-IBM system, from its hardware through its OS/2 platform, down to its applications. That choice might have made consumers happy, but it didn’t play too well in Redmond.

Microsoft tried to convince IBM to move its business away from products that themselves competed directly with Windows and Office. Microsoft leveraged the fact that [IBM’s] PC Company needed to license Windows at a competitive price and on a timely basis, and the fact that the company needed Microsoft’s support in many more subtle ways. When IBM refused to abate the promotion of those of its own products that competed with Windows and Office, Microsoft pun­ished the IBM PC Company with higher prices, a late license for Windows 95, and the withholding of technical and marketing support.⁸

Microsoft used its position as the platform monopolist to secure the OEM channel.

Over in Manifestoland, Musoft couldn’t control distribution. Mani­festoland OEMs purchased a single copy of Mundos 95 and distributed it freely with their hardware. That worked fine for Musoft, who’d already decided to sacrifice short-term revenues to focus on network growth. But it did leave Musoft with little of Microsoft’s asymmetric strength during negotiations covering the various “more subtle ways” that OEMs need platform developers.

Microsoft and Musoft both understood that their relationships with ISVs were trickier than their OEM relationships. Because the technical skills necessary to develop platforms and applications are quite similar, some ISV products that complement their platforms actually compete with their applications. These complicated relationships, in which poten­tial competitors are also potential customers, force every platform devel­oper (and every firm who controls the core product of a network industry, for that matter) to face the tension between access and control. Platform developers must find the appropriate balance between main­taining tight control, thereby forcing ISVs to work on competing plat­forms, and granting those independents access to the API and development tools they might need. Most commercially viable long-term strategies lie between the extremes of total access and total control.

Microsoft chose this middle ground, licensed its APIs but not its source code, and thereby defeated Apple. Musoft had no such luxury. Manifestoland’s constraints forced Musoft to pursue an access-oriented strategy as the price of secrecy. This choice, however, also posed a quandary in thinking about alliances with ISVs. How could Musoft share the Mundos APIs safely without protective IP rights? Corporations who share their trade secrets with potential competitors don’t rely on IP rights for protection. The laws of trade secrets, licenses, contracts, and busi­ness torts are both more powerful and more appropriate tools to protect these relationships.

Which leaves us with one burning question concerning the relation­ship between a platform monopolist and ISVs: What did Microsoft actu­ally do? Microsoft may, on occasion, give its own developers a tiny lead time on API changes hoping to gain a leg up in the relevant applications market, and it varies its APIs often enough to dissuade cloning, but by and large, Microsoft’s strategy leans strongly towards access. Microsoft wants ISVs to write programs that run on Windows. The last thing that Microsoft wants to see is a huge increase in Linux or Mac applica­tions. As a result, Microsoft works hard to ensure that developers get what they need to develop new Windows applications—for with each new application, the applications barrier to entry grows stronger, the Windows network becomes more valuable, and Microsoft’s monopoly becomes more secure.

There are, however, two exceptions worth noting. The first deals with Microsoft’s Office suite. For a while, competing application developers produced popular, powerful office programs, including some that ran on Windows; Lotus 1-2-3 and WordPerfect come immediately to mind. These programs retained strong market positions and large shares—at times, even larger than those of Microsoft’s own Excel and Word—well into the Windows era. And yet, Microsoft was able to reduce both to relatively small niche players. Much of this came from Microsoft’s ability to exert negotiating strength with OEMs—applying leverage that, as we noted, grew from the nature of its IP rights and would not have been available to Musoft. After all, many consumers purchase new hardware configured not only with a platform, but also with an office suite. But leveraging OEMs only could accomplish part of the goal. Microsoft likely also applied some of the same moving-target-API strategies to these competitors that it had with DR-DOS. But though such actions were likely, we can’t know with any degree of certainty precisely what Microsoft did in these markets. These stories didn’t unfold during the trial because applications were where the trial was not; we have less data about Microsoft’s behavior in applications markets than we might like.

The second exception is even more important—for it leads us into the relationships among direct platform competitors. The developers of pow­erful middleware applications threaten to dethrone platform monopo­lists through one of the two paths that network economics left open to them. They can develop new products that are so far superior to Windows that consumers would be willing to incur the switching costs; or they can develop new products that expand the market by so much that the new consumers using their products generate a network larger than the Windows network.

How can these circumstances arise? Computer science tells us that in platform software, these conditions arise only during transitions between successive generations. These periods represent the all-important junc­tures when the translation frontier evolves upward by integrating enough new middleware (or applications) to alter its entire look and feel, and thus to invite a whole new group of human users who’d never bothered to learn the specialized language of the old translation frontier into the wonderful world of computing. When that migration occurs, the winners of the middleware competition easily could gain ownership of the next­generation platform. We’ve already seen that migration happen once, when MS-DOS swallowed the Windows middleware application to become a true platform. At trial, Judge Jackson ruled that Microsoft had violated the antitrust laws by squelching nascent threats from IBM, Intel, Apple, and RealNetworks.⁹ But by far the most significant threat had come from the combination of Netscape’s Navigator and Sun’s Java—a direct middleware threat.

Now Musoft never learned to squelch these threats; they still exist in the competitive markets of Manifestoland. Through the looking glass, Musoft watched Microsoft’s exploits in the fabled browser wars.