MS, DOJ are making the right concessions

COMMENTARY--The nine states that rejected the Microsoft settlement modified their proposed sanctions on Monday. Most ofthe 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 ofthe operating system, the company should be requiredto offer a modular version that will allow equipmentmanufacturers and others to make their own decisionson adding middleware products that consumers want suchas browsers or media players. Microsoft thereforewould not be required to provide numerous versions ofthe operating system."

This is an important concession, and revealing of theproblems the states are having as they attempt toreconcile their proposed sanctions with antitrust'sintended goal of promoting consumer well being. Ithints that the non-settling states are beginning tounderstand the standardization benefits consumersderive from Microsoft's desktop operating system. Unfortunately, this alteration does not yet go farenough, as it still leaves ample room for developmentplatform fragmentation.

This alteration ignores the API differences whichexist between middleware products such as the NetscapeWeb browser and Internet Explorer or Real Audio's"Real Player" and Microsoft's "Media Player." Just asuser interfaces vary between the aforementionedsoftware programs, the API through which programsreuse aspects of functionality vary.

An API describes the semantics used by a particularoperation exposed for reuse by other pieces ofsoftware. For instance, a mail program might have anoperation named "sendEmail" which, as the namesuggests, sends e-mail. That operation might requirecertain types of information as "arguments." In thecase of the "sendEmail" operation, it might require alist of e-mail addresses and the text of the message tobe sent. In return, the operation might pass back tothe calling software some value that the program canuse to determine whether or not the message wassuccessfully sent.

The standardization issue comes into play becausethere are multiple ways to expose an operation whichsends e-mail. One mail client might call its operation"NSSendEmail", and take as arguments the message to besent, a list of addresses, AND a value which indicateswhether the program should encrypt the message beforesending it. A similar operation on another mailclient might expose the same functionality using anentirely different set of semantics. To add even moreconfusion, some mail software may not expose ANY APIto send e-mail. The software in question might only bedesigned for use via its user interface, not fromother pieces of software.

The inclusion of new features into Windows creates abaseline API definition. For instance, the presenceof Internet Explorer as an integral part of Windowsallows developers who target a particular version toknow that an HTML renderer exists on a client'scomputer which conforms to a certain well-known API. This boosts the inclusion of such advanced featuresinto software programs, as vendors can write softwaresafe in the knowledge that the required features willalways exist on their clients' computers.

Consumers benefit from such a vendor-created standard,which goes a long way towards explaining whyconsumers, through their buying choices, repeatedlyconstruct large, dominant software companies. BeforeMicrosoft, IBM set standards for the industry across abroad range of hardware and software categories. Today, Microsoft's control is mostly isolated todesktop computing, yet it is the standardization whichresults from that control which has benefitedconsumers. These benefits include price reductions inthe PC platform due to Windows-compatible hardwarecompetition, a proliferation of software options dueto the attraction of the standard platform, and aresultant reduction in price due to softwarecompetition atop the standard Windows base and theeconomics of scale which derive from a larger marketfor Windows hardware and software.

The intent of the opposing states' changes was to makeit possible for alternative middleware providers tocompete with Microsoft middleware while countering thecharge that they are harming consumers through theerosion of the Windows standard. That attempt fallsshort due to the problem of middleware APIcompatibility. The proposed settlement had the samegoal, however, and managed a solution which betterfulfills the opposing states' intent. As the proposedsettlement states in Section III.D:

"Starting at the earlier of the release of ServicePack 1 for Windows XP or 12 months after thesubmission of this Final Judgment to the Court,Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs,and OEMs, for the sole purpose of interoperating witha Windows Operating System Product, via the MicrosoftDeveloper Network ("MSDN") or similar mechanisms, theAPIs and related Documentation that are used byMicrosoft Middleware to interoperate with a WindowsOperating System Product."

Furthermore, in Section III.H.2, the settlement statesthat Microsoft must:

"Allow end users (via a mechanism readily availablefrom the desktop or Start menu), OEMs (via standardOEM preinstallation kits), and Non-MicrosoftMiddleware Products (via a mechanism which may, atMicrosoft's option, require confirmation from the enduser) to designate a Non-Microsoft Middleware Productto be invoked in place of that Microsoft MiddlewareProduct (or vice versa) in any case where the WindowsOperating System Product would otherwise launch theMicrosoft Middleware Product in a separate Top-LevelWindow and display either (i) all of the userinterface elements or (ii) the Trademark of theMicrosoft Middleware Product."

In other words, Microsoft must document allinteractions between the operating system and aparticular middleware product, such as InternetExplorer, as well as enable alternatives to be invokedin place of the Microsoft default. This helps thirdparties, such as Opera, to ensure that their softwarehonors the "contract" described by those documentedinteractions. Opera could be used in every situationthat Internet Explorer is used, allowing it to competefrom an efficiency, speed, and even a featurestandpoint while ensuring that developers and theconsumers they serve can expect a standard Windowsdevelopment base.

It is important, however, that the Microsoft-supplieddefault remain present on the system. If someoneremoves Opera or Netscape from their computer,Internet Explorer must exist to uphold the APIbaseline expected by applications which run onWindows. For this reason, though the proposedsettlement in Section III.H.1 ensures that OEMs canhide the icons for Microsoft middleware, it does notrequire the removal of code normally invoked by thaticon.

The settlement makes possible all the scenarios theopposing states wish to encourage through a "modular"OS. AOL could opt to release an "AOL-branded" PC,providing Netscape, Netscape Mail, the AIM InstantMessaging client and Real Player as replacements forthe Microsoft-supplied defaults. Third-party softwarewouldn't know the difference, however, because thoseAOL-branded products would adhere to the sameinterfaces as the Microsoft middleware. This woulderase the application barrier to entry, at leastinsofar as it applies to middleware, boosting featurecompetition in Windows.

The settlement proposes a superior solution to theissue of middleware competition, one that strives topreserve the benefits consumers derive from theWindows standard while mitigating Microsoft's marketpower. Given the changes proposed by the opposingstates, they are closer than ever to this model. Let's hope the thought process that led to this changecontinues, and that future revisions bring theopposing states closer to the lines drawn by theproposed 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.