COMMENTARY--The nine states that rejected the Microsoft settlement modified their proposed sanctions on Monday. Most of
the modifications were minor, with one critical exception. Tom Miller, Iowa's State Attorney General, describes it as: "As a result of discovery, we have concluded that,
in addition to Microsoft's fully-integrated version of
the operating system, the company should be required
to offer a modular version that will allow equipment
manufacturers and others to make their own decisions
on adding middleware products that consumers want such
as browsers or media players. Microsoft therefore
would not be required to provide numerous versions of
the operating system."
This is an important concession, and revealing of the problems the states are having as they attempt to reconcile their proposed sanctions with antitrust's intended goal of promoting consumer well being. It hints that the non-settling states are beginning to understand the standardization benefits consumers derive from Microsoft's desktop operating system. Unfortunately, this alteration does not yet go far enough, as it still leaves ample room for development platform fragmentation.
This alteration ignores the API differences which exist between middleware products such as the Netscape Web browser and Internet Explorer or Real Audio's "Real Player" and Microsoft's "Media Player." Just as user interfaces vary between the aforementioned software programs, the API through which programs reuse aspects of functionality vary.
An API describes the semantics used by a particular operation exposed for reuse by other pieces of software. For instance, a mail program might have an operation named "sendEmail" which, as the name suggests, sends e-mail. That operation might require certain types of information as "arguments." In the case of the "sendEmail" operation, it might require a list of e-mail addresses and the text of the message to be sent. In return, the operation might pass back to the calling software some value that the program can use to determine whether or not the message was successfully sent.
The standardization issue comes into play because there are multiple ways to expose an operation which sends e-mail. One mail client might call its operation "NSSendEmail", and take as arguments the message to be sent, a list of addresses, AND a value which indicates whether the program should encrypt the message before sending it. A similar operation on another mail client might expose the same functionality using an entirely different set of semantics. To add even more confusion, some mail software may not expose ANY API to send e-mail. The software in question might only be designed for use via its user interface, not from other pieces of software.
The inclusion of new features into Windows creates a baseline API definition. For instance, the presence of Internet Explorer as an integral part of Windows allows developers who target a particular version to know that an HTML renderer exists on a client's computer which conforms to a certain well-known API. This boosts the inclusion of such advanced features into software programs, as vendors can write software safe in the knowledge that the required features will always exist on their clients' computers.
Consumers benefit from such a vendor-created standard, which goes a long way towards explaining why consumers, through their buying choices, repeatedly construct large, dominant software companies. Before Microsoft, IBM set standards for the industry across a broad range of hardware and software categories. Today, Microsoft's control is mostly isolated to desktop computing, yet it is the standardization which results from that control which has benefited consumers. These benefits include price reductions in the PC platform due to Windows-compatible hardware competition, a proliferation of software options due to the attraction of the standard platform, and a resultant reduction in price due to software competition atop the standard Windows base and the economics of scale which derive from a larger market for Windows hardware and software.
The intent of the opposing states' changes was to make it possible for alternative middleware providers to compete with Microsoft middleware while countering the charge that they are harming consumers through the erosion of the Windows standard. That attempt falls short due to the problem of middleware API compatibility. The proposed settlement had the same goal, however, and managed a solution which better fulfills the opposing states' intent. As the proposed settlement states in Section 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."
Furthermore, in Section III.H.2, the settlement states that Microsoft must:
"Allow end users (via a mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) in any case where the Windows Operating System Product would otherwise launch the Microsoft Middleware Product in a separate Top-Level Window and display either (i) all of the user interface elements or (ii) the Trademark of the Microsoft Middleware Product."
In other words, Microsoft must document all interactions between the operating system and a particular middleware product, such as Internet Explorer, as well as enable alternatives to be invoked in place of the Microsoft default. This helps third parties, such as Opera, to ensure that their software honors the "contract" described by those documented interactions. Opera could be used in every situation that Internet Explorer is used, allowing it to compete from an efficiency, speed, and even a feature standpoint while ensuring that developers and the consumers they serve can expect a standard Windows development base.
It is important, however, that the Microsoft-supplied default remain present on the system. If someone removes Opera or Netscape from their computer, Internet Explorer must exist to uphold the API baseline expected by applications which run on Windows. For this reason, though the proposed settlement in Section III.H.1 ensures that OEMs can hide the icons for Microsoft middleware, it does not require the removal of code normally invoked by that icon.
The settlement makes possible all the scenarios the opposing states wish to encourage through a "modular" OS. AOL could opt to release an "AOL-branded" PC, providing Netscape, Netscape Mail, the AIM Instant Messaging client and Real Player as replacements for the Microsoft-supplied defaults. Third-party software wouldn't know the difference, however, because those AOL-branded products would adhere to the same interfaces as the Microsoft middleware. This would erase the application barrier to entry, at least insofar as it applies to middleware, boosting feature competition in Windows.
The settlement proposes a superior solution to the issue of middleware competition, one that strives to preserve the benefits consumers derive from the Windows standard while mitigating Microsoft's market power. Given the changes proposed by the opposing states, they are closer than ever to this model. Let's hope the thought process that led to this change continues, and that future revisions bring the opposing states closer to the lines drawn by the proposed settlement.
John Carroll is a software engineer who lives in Switzerland. He specializes in the design and development of distributed systems using Java and .NET. He has also provided commentary about the Tunney Act comments.
