In reviewing the facts, I've developed a proposed settlement for the Microsoft antitrust case which better addresses the issues at hand. Instead of debating a business answer to Microsoft's possible monopoly position, my settlement encourages competition to "put up or shut up" by forcing Microsoft to open up some of their technical monopoly on file formats and device drivers.
In my proposed settlement, Microsoft will be required to release full documentation of, and public domain source code to read all file formats handled by the MS Office Suite starting with Office97 and all device driver formats starting with Windows 2000; they will provide a plug-in registry service, similar to Windows Media codec discovery, which allows third parties to register import handlers for converting their document formats into a formats readable and writable by Office applications; lastly, they wil be required to release public domain source code for the Internet Explorer HTML renderer, including the DOM, JavaScript, XML/CSS handling, etc.
The goal of a settlement is to open up the unfair barriers to competition, without unjustly harming Microsoft in the process. Splitting Microsoft into several separate business units is always at the top of any settlement discussion. However, this would drastically affect the structure of their business (for better or worse). This puts too much risk on an already struggling economy. Another more radical option is to turn Microsoft Windows operating systems into a regulated monopoly. However, there is no precedent for regulating the price of software, and this kind of government intervention would have fast and unknown consequences on Microsoft's process for developing software.
However, a critical eye will notice that many of Microsoft's unfair monopolistic barriers come from technical challenges which can be easily overcome. I've proposed two simple efforts which I believe will have minimal immediate impact on Microsoft's business, while slowly opening up room for competition by alternative vendors.
1. Open up File Formats
It is simply better for everyone to be able to read and write the same file formats. If we had several operating system vendors in pure competition, and everyone had a different word processor file format, emailing documents would be chaos. The scenerio we want is one where there is competition for operating systems and word processors, but where documents are reasonably interoperable. Requiring Microsoft to document and release office file formats would make this kind of interoperability possible.
Fortunatly, Microsoft is already making inroads in this direction. New versions of Office come with XML file save options [Word 11, XML]. They might choose to meet this requirement simply by changing future Office versions to use a compressed XML representation as their only save format. However, releasing documentation to the binary Office97 format is still critical. Many companies have expended effort to read and write these formats with some success. Having access to proper documentation would make it easier for them to achieve a satisfactory level of compatibility with Office file formats.
However, it is just as critical for Microsoft to make it possible for Office applications to read (and write) other third party formats. This would achieve unheard of interoperability between office-like applications. Internet users would be able to email each other documents in virtually any file format and be able to expect some level of compatiblity. Those that wanted true interoperability would trend towards either Office or those Office competitors which had done the best job of implementing the Office standards.
A similar situation exists with device drivers. Every year, thousands of device drivers are written to bring Windows support to third party devices. Every one of these devices is a living breathing technological barrier to entry for any other operating system vendor. If third party operating systems could read and use most Windows device drivers to support devices, it would make the operating system playing field much more open. Intel has already attempted to create such a project under the moniker Uniform Driver Interface (UDI). Requiring Microsoft to make Windows device drivers available to the efforts would make this project viable. In the future, we might require device drivers to be based on Microsoft's excellent MSIL technology (something they might already be thinking about doing themselves) to make dependencies simpler and allow them to be used by non x86 architectures.
After Microsoft takes these steps, we can make a single registry for handlers of many types of standardized fileformats (ala AmigaOS datatypes or BeOS Translation Kit), specified either in JVM or MSIL bytecodes. This registry would be available on the internet for all applications to register and download from. Handlers for the Office fileformats would lead the charge to use this registry, ultimately leading towards a future where file formats truly are interoperable -- not because of paper standards, but because of standardized implementations.
2. Release Internet Explorer source to the public domain
Microsoft faught to popularize Internet Explorer as the best Internet browser, even when the browser itself generates no revenue. There are many standards to assist in making webpages and browser interoperate. However, in the real world, no implementation is perfect and web pages are written to work on the most popular browsers. Now that Internet Explorer has more than 90% of the browser marketshare, it essentially is the standard for the web. In order for other systems to compete, they try and try to build a browser which does not just follow the standards, but operates exactly as Internet Explorer does. In order to make the Internet equally accessable on all desktop systems, Microsoft should be required to release the necessary source code for Internet Explorer.
Microsoft will argue that Internet Explorer is too tightly tied to their operating system. Certainly there are complications. For example, the HTML renderer is no doubt tied to details of Win32 such as the GDI drawing system and Win32 message queue event system. Other details related to its modularity are also likely to create roadblocks. However, surely a development organization as capable as Microsoft can find the right way to package and deliver the source code. As a simple litmus test, we can require them to port the source code and deliver a working application on their free-UNIX of choice. This would likely be FreeBSD if their shared source CLI initiatives are any indication.
Conclusion
This proposal calls for some large tasks to be taken on by Microsoft which will surely alter their business by easing barriers to entry in some of their markets. However, its success is more because of what it does not do. It does not: (a) split Microsoft into multiple bussiness units, (b) regulate the price of any Microsoft product, (c) require constant scrutany of Microsoft business practices, (d) require openness at the Win32 or application level, (e) encourage any drastic change to Microsoft's business.
The changes which happen as a result of this proposal will be gradual, they will encourage slightly increased competition in several areas of the industry, and they will leave Microsoft, the government, and the Industry time to understand and react to these changes.
Are you with me? Can you say Federal Referendum?
Posted by jeske at February 20, 2003 10:24 AM