Yahoo! - Full Coverage - Help

(Previous Page -- Findings Index -- Full Coverage)

I. The Success of Microsoft's Effort to Protect the Applications Barrier to Entry from the Threat Posed by Navigator

377. In late 1995 and early 1996, Navigator seemed well on its way to becoming the standard software for browsing the Web. Within three years, however, Microsoft had successfully denied Navigator that status, and had thereby forestalled a serious potential threat to the applications barrier to entry. Indeed, Microsoft's Kumar Mehta felt comfortable expressing to Brad Chase in February 1998 his "PERSONAL opinion" that "the browser battle is close to over." Mehta continued: "We set out on this mission 2 years ago to not let netscape dictate standards and control the browser api's [sic]. All evidence today says they don't."

378. The population of browser users is expanding so quickly that Navigator's installed base has grown even as its usage share has fallen. In fact, AOL credited an estimate stating that Navigator's installed base in the United States alone grew from fifteen million in 1996 to thirty-three million in December 1998. By all indications, Navigator's installed base will continue to grow. This does not mean, however, that Navigator is -- or will be -- an attractive enough platform for the development of network-centric applications to weaken the applications barrier to entry. As discussed above, the APIs that Navigator exposes could only attract enough developer attention to threaten the applications barrier to entry if Navigator became -- or appeared destined to become -- the standard software used to browse the Web. Navigator's installed base may continue to grow, but Internet Explorer's installed base is now larger and growing faster. Consequently, the APIs that Navigator exposes will not attract enough developer attention to spawn a body of cross-platform, network-centric applications large enough to dismantle the applications barrier to entry.

379. Not only did Microsoft prevent Navigator from undermining the applications barrier to entry, it inflicted considerable harm on Netscape's business in the process. By ensuring that the firms comprising the channels that lead most efficiently to browser usage distributed and promoted Internet Explorer to the virtual exclusion of Navigator, Microsoft relegated Netscape to more costly and less effective methods of distributing and promoting its browsing software. After Microsoft started licensing Internet Explorer at no charge, not only to OEMs and consumers, but also to IAPs, ISVs, ICPs, and even Apple, Netscape was forced to follow suit. Despite the fact that it did not charge for Internet Explorer, Microsoft could still defray the massive costs it was undertaking to maximize usage share with the vast profits earned licensing Windows. Because Netscape did not have that luxury, it could ill afford the dramatic drop in revenues from Navigator, much less to pay for the inefficient modes of distribution to which Microsoft had consigned it. The financial constraints also deterred Netscape from undertaking technical innovations that it might otherwise have implemented in Navigator. Microsoft was not altogether surprised, then, when it learned in November 1998 that Netscape had surrendered itself to acquisition by another company.

380. Were AOL ever to attempt to revive Navigator's usage share with the intention of building it into a significant platform for the development of network-centric applications, that effort would not make any headway before January 1, 2001, when AOL's obligation to distribute Internet Explorer on a preferential basis expires. In fact, there is presently no indication that AOL will try even after that date to raise Navigator's usage share substantially. First of all, as explained above, AOL need not revive Navigator's usage share in order to achieve an adequate return on its investment in Netscape. Secondly, while the due-diligence summary and board-of-directors presentation that preceded the Netscape acquisition discuss AOL's commitment to invest marketing resources in an effort to stem the slide in Navigator's share, neither report indicates any intention on AOL's part to invest in actually raising Navigator's share.

381. Also detracting from the notion that AOL is committed to reviving the middleware threat through Navigator is the fact that AOL included in the November 1998 agreement with Sun a provision making clear that the new partnership with Sun in no way obligated AOL to drop Internet Explorer from its client software in favor of Navigator. The provision states that "AOL has no present intention to make any such replacement or use and shall have no obligation to make any such replacement or use, and that it is AOL's present expectation that it . . . may seek to renew and/or extend and expand its present agreement with Microsoft Corporation to continue to distribute Internet Explorer."

382. Bill Gates himself, who is not one to underestimate threats to Microsoft's business, apparently concluded after reviewing the November 1998 transactions that AOL would not seek to develop a platform that would compete with Microsoft's network-centric interfaces. In December 1998, during a meeting convened to analyze the implications of the AOL/Netscape/Sun transactions, Gates declared to the assembled Microsoft executives, "AOL doesn't have it in their genes to attack us in the platform space."

383. Finally, if its coveted placement in the Online Services Folder fails to entice AOL into extending its agreement with Microsoft past January 2001, Microsoft assuredly has the wherewithal to offer AOL additional inducements in exchange for yet more commitments that will preclude a resurgence of Navigator's usage share. Even if, despite the absence of signs to that effect, AOL drops Internet Explorer and adopts Navigator with a mind to reviving Navigator's usage share after January 1, 2001, Navigator's transformation into a platform attractive enough to threaten the applications barrier would be a chimerical aspiration, especially considering Microsoft's increasing influence over network-centric standards. In any event, nothing that happens after January 1, 2001 will change the fact that Microsoft has succeeded in forestalling for several years Navigator's evolution in that direction.

384. Although the suspicion lingers, the evidence is insufficient to find that Microsoft's ambition is a future in which most or all of the content available on the Web would be accessible only through its own browsing software. The evidence does, however, reveal an intent to ensure that if and when full-featured, server-based applications begin appearing in large numbers on the Web, the number of them relying solely on middleware APIs (such as those exposed by Navigator) will be too few to attenuate the applications barrier to entry.

385. At least partly because of Navigator's substantial usage share, most developers continue to insist that their Web content be more-or-less as attractive when accessed with Navigator as it is when accessed with Internet Explorer. Navigator will retain an appreciable usage share through the end of 2000. After that point, AOL may be able and willing to prevent Internet Explorer's share from achieving such dominance that a critical mass of developers will cease to concern themselves with ensuring that their Web content at least be accessible through non-Microsoft browsing software. So, as matters stand at present, while Microsoft has succeeded in forestalling the development of enough full-featured, cross-platform, network-centric applications to render the applications barrier penetrable, it is not likely to drive non-Microsoft PC Web browsing software from the marketplace altogether.

VI. MICROSOFT'S RESPONSE TO THE THREAT POSED BY SUN'S IMPLEMENTATION OF JAVA

386. For Microsoft, a key to maintaining and reinforcing the applications barrier to entry has been preserving the difficulty of porting applications from Windows to other platforms, and vice versa. In 1996, senior executives at Microsoft became aware that the number of developers writing network-centric applications in the Java programming language had become significant, and that Java was likely to increase in popularity among developers. Microsoft therefore became interested in maximizing the difficulty with which applications written in Java could be ported from Windows to other platforms, and vice versa.

A. Creating a Java Implementation for Windows that Undermined Portability and Was Incompatible with Other Implementations

387. Although Sun intended Java technologies eventually to allow developers to write applications that would run on multiple operating systems without any porting, the Java class libraries have never exposed enough APIs to support full-featured applications. Java developers have thus always needed to rely on platform-specific APIs in order to write applications with advanced functionality. Recognizing this, Sun sponsored a process for the creation of a software method that would allow developers writing in Java to rely directly upon APIs exposed by a particular operating system in a way that would nevertheless allow them to port their applications with relative ease to JVMs running on different operating systems.

388. On March 12, 1996, Sun signed an agreement granting Microsoft the right to distribute and make certain modifications to Sun's Java technologies. Microsoft used this license to create its own Java development tools and its own Windows-compatible Java runtime environment. Because the motivation behind the Sun-sponsored effort ran counter to Microsoft's interest in preserving the difficulty of porting, Microsoft independently developed methods for enabling "calls" to "native" Windows code that made porting more difficult than the method that Sun was striving to make standard. Microsoft implemented these different methods in its developer tools and in its JVM. Microsoft also discouraged its business allies from aiding Sun's effort. For example, Gates told Intel's CEO in June 1996 that he did not want the Intel Architecture Labs cooperating with Sun to develop methods for calling upon multimedia interfaces in Windows.

389. Since they were custom-built for enabling native calls to Windows, and because they were developed by the firm with the most intimate knowledge of Windows, the native methods that Microsoft produced were slightly easier for developers to use than the method that derived from the Sun-sponsored effort, and Java applications using Microsoft's methods tended to run faster than ones calling upon Windows APIs with Sun's method. If a developer relied on Microsoft's methods rather than Sun's, however, his Java application would be much more difficult to port from the Windows-compatible JVM to JVMs designed to run on different operating systems.

390. Microsoft easily could have implemented Sun's native method along with its own in its developer tools and its JVM, thereby allowing Java developers to choose between speed and portability; however, it elected instead to implement only the Microsoft methods. The result was that if a Java developer used the Sun method for making native calls, his application would not run on Microsoft's version of the Windows JVM, and if he used Microsoft's native methods, his application would not run on any JVM other than Microsoft's version. Far from being the unintended consequence of an attempt to help Java developers more easily develop high-performing applications, incompatibility was the intended result of Microsoft's efforts. In fact, Microsoft would subsequently threaten to use the same tactic against Apple's QuickTime. Microsoft continued to refuse to implement Sun's native method until November 1998, when a court ordered it to do so. It then took Microsoft only a few weeks to implement Sun's native method in its developer tools and JVM.

391. Although the Java class libraries have yet to provide enough functionality to support full-featured applications, they have gradually expanded toward that goal. In 1997, Sun added a class library called Remote Method Invocation, or "RMI," which allowed Java applications written to call upon it to communicate with each other in certain useful ways. Microsoft was not willing to stand by and allow Java developers to rely on new Java class libraries unimpeded. The more that Java developers were able to satisfy their need for functionality by calling upon the Java class libraries, the more portable their applications would become. Microsoft had developed a set of Windows-specific interfaces to provide functionality analogous to the functionality RMI offered; it wanted Java developers to rely on this Windows-specific technology rather than Sun's cross-platform interface. Microsoft thus refused to include RMI as a standard component of the Java runtime environment for Windows that it shipped with Internet Explorer 4.0.

392. The license agreement it had signed with Sun the previous year obligated Microsoft to offer RMI, at a minimum, on its developer Web site. Microsoft did so, but with respect to the RMI beta release, it buried the link in an obscure location and neglected to include an entry for it in the site's index. Referring to RMI and any Java developers who might access Microsoft's site looking for it, a Microsoft employee wrote to his approving manager, "They'll have to stumble across it to know it's there. . . . I'd say it's pretty buried."

393. It is unclear whether Microsoft ultimately placed RMI in a more prominent place on its developer Web site. Even if it did, the fact that RMI was not shipped with Microsoft's Java runtime environment for Windows meant that Java developers could not rely on its being installed on consumers' PC systems. If developers wanted their Java applications to call upon communications interfaces guaranteed to be present on Windows users' systems, they had no choice but to rely on the Microsoft-specific interfaces instead of RMI. Microsoft undertook the effort to remove RMI from the rest of the Java class libraries, instead of simply leaving it in place and allowing developers to choose between it and Windows-specific interfaces, for the sole purpose of making it more difficult for Java developers to write easily portable applications.

394. In a further effort intended to increase the incompatibility between Java applications written for its Windows JVM and other Windows JVMs, and to increase the difficulty of porting Java applications from the Windows environment to other platforms, Microsoft designed its Java developer tools to encourage developers to write their Java applications using certain "keywords" and "compiler directives" that could only be executed properly by Microsoft's version of the Java runtime environment for Windows. Microsoft encouraged developers to use these extensions by shipping its developer tools with the extensions enabled by default and by failing to warn developers that their use would result in applications that might not run properly with any runtime environment other than Microsoft's and that would be difficult, and perhaps impossible, to port to JVMs running on other platforms. This action comported with the suggestion that Microsoft's Thomas Reardon made to his colleagues in November 1996: "[W]e should just quietly grow j++ [Microsoft's developer tools] share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps." Microsoft refused to alter its developer tools until November 1998, when a court ordered it to disable its keywords and compiler directives by default and to warn developers that using Microsoft's Java extensions would likely cause incompatibilities with non-Microsoft runtime environments.