This is the story of how a commercial software product became an open source software product. It’s a story about what’s required to run a successful open source project, how to spin an open source project out of a commercial software project, and how to harness the power of customers as contributors, guides, and promoters. This is also the story of how to design a well-governed open source community--one that is highly productive and produces high-quality software. And, it’s the story of how to harness an open source marketing community.

The community of developers that took stewardship over Netscape’s browser software eventually succeeded in their mission: to produce a state-of-the art Web browser that could compete head-to-head with Microsoft’s.

Transitioning Commercial Software to Open Source Software

Netscape handed over its then-popular Netscape Communicator to the open source community in January 1998. You may recall that by that time, Netscape offered its Communicator (browser and email client) for free on the desktop and sold complementary server-side software to businesses. But Microsoft had engaged and was already winning the browser wars, essentially driving Netscape out of business, by requiring that every PC that was sold with Microsoft Windows included Microsoft’s browser--Internet Explorer. Since both products were “free”--e.g., made available at no cost to the end user, the real battle was over who had control of the customers’ experiences as they surfed the Web.

As a way to gain more traction, Netscape offered a version of the source code for Netscape Communicator, including the Navigator browser, to the open source community, ceding control of the software to the community of developers who cared about keeping it alive. “Netscape’s goal was to seed a broad-based development effort within the software development community to produce future browser products as a shared resource,”[1] explained Mitchell Baker, who has been the “Chief Lizard Wrangler” of the Mozilla project from its inception.

She summarized the mechanics of the transfer from proprietary to open: “The source code was prepared for public release by removing all code that Netscape didn’t have the right to license under an open source license, and then replacing those pieces necessary for the code to compile and run. At the same time, a new open source license--the Mozilla Public License--was written, reviewed and accepted by the open source community, including the Open Source Initiative.”[2]

Netscape helped the group set up Mozilla.org, which eventually became the Mozilla Foundation. Throughout the Mozilla project, Netscape provided support, as did AOL when Netscape was acquired by AOL in 1999. The core development team was originally made up of Netscape employees who remained on Netscape’s (and then AOL’s) payroll, although today the mozilla.org staff does not have any Netscape/AOL employees.

Shifting to an Open Source Development Process

According to Mitchell Baker, one of the biggest shifts for the Netscape/AOL developers who were involved with Mozilla.org was to make all of their communications about the software and its direction open and public. Since many of the original Netscape folks still worked together, it was often easier for them to discuss a technical problem at the water cooler than it was to post their thoughts to the public discussion forums. The other habit they had to learn was to post all of their work in process in a shared code repository so that outsiders could see it, comment on it, and if they were permitted, make changes to it.[3]

Providing a Structured Process for Open Contributions

The Mozilla project is one of the largest and longest-running open source development projects. Most of its innovations in governance, policy-setting, and organizational structure were big departures from the commercial software development processes that Netscape (and most other commercial software development firms) had used. The Mozilla.org open development process had a few notable characteristics, many of which are now common practice for open source development. Open source development is not, as many might think, a chaotic, frenzied activity. It’s a unique combination of highly-structured development processes, visibility, and the ability to harness the goodwill of hundreds of contributors to identify bugs, test code, and offer improvements. As it moved from commercial to open source development, the former Netscape team put a number of important processes into practice.

Public Bug and Issue-Tracking System. The Mozilla.org team built an open source bug tracking system (Bugzilla). This became the heart of the open community process. All bugs and issues are reported publicly (except for security-related bugs which are held close to the vest, so as not to alert malicious hackers). Anyone can both monitor progress and jump in to work on an issue or bug to which they have a solution or a better idea.

Automated Build and Cross-Platform Testing. The team also developed an automated and highly-visible build and testing process. “This means that we have an automated process that builds and rebuilds the software continuously and tests it on multiple platforms to see if and when a new piece of code causes the software not to build,” Mitchell Baker explained.[4] Again, that visibility means that everyone can quickly see whose code caused a problem in a build or on a specific operating system.

Two Levels of Code Review. The Mozilla.org “staff” decided from the beginning that just because you were an employee of Netscape or an expert coder, you wouldn’t be able to submit code unless it had gone through a formal code review. In fact, as the programs became more complex, the team added a second layer of review, or “super-review” designed to catch architectural or design issues that would impact the overall quality of the final integrated product. Both reviewers and super-reviewers of the code were the most respected developers and the most knowledgeable people in their subject matter.

Earning the Right to “Touch the Tree.” In a company in which developers are employed to write code, they are often permitted to “write” or commit their code to the final build, simply because they are the employees. In an open source project, such as Mozilla, you earn the right to commit code based on the acknowledged value of your contributions.

Quality Assurance. One of the critical issues in software quality is the thoroughness of the testing process. QA is one of the functions that may be best suited to a customer-led community. Starting in 1999, Christine Beagle led the effort to encourage community members to volunteer for testing and QA, to take more authority over the QA process, and to make it a more organized activity. One of the stars who emerged from that volunteer QA community was Asa Dotzler, who was then hired to lead Mozilla’s QA efforts. “With Asa’s coordination we began to see a set of people doing more organized testing of our products. This provided enormous value,”[5] Mitchell Baker explained.

Setting up an Independent Entity

For the first five years, Mozilla.org was still closely tied to its “parent,” Netscape/AOL. AOL still needed to be able to count on and roll out updated versions of its browser that were based on the open source product. After Netscape 6.0 was released, Mozilla.org gained full control over the release schedule--in other words, what functionality would be in each release and when the product would be released. By the time Mozilla 1.0 was released in June, 2002, the “full-time” developers in the Mozilla.org community began seriously thinking about life as a completely separate entity from AOL. By 2003, the stars had aligned, and the completely independent Mozilla Foundation was launched on July 14, 2003. The original team included 10 paid employees, and a large and growing group of dedicated volunteers--by then, numbering in the tens of thousands.

Rewrote Most of the Code from Scratch--Focused on Browser and E-Mail

Between 1998 and 2004, members of the Mozilla.org community completely rewrote the original Netscape Communicator product, redesigning its core architecture and dividing the application functionality up into separate modules--browser, email, calendar, etc. By the time the Mozilla Foundation was formed, the team had made the decision to focus its energy on rewriting, yet again, the two most important cornerstones of the Mozilla integrated suite of applications: the browser (soon to be called Firefox) and the email (Thunderbird). Mitchell Baker explained: “The integrated Mozilla Application Suite (Seamonkey) is a fine product that many love. But the integration caused difficulties, and we knew we wanted updated, standalone browsing and mail applications. Given our limited resources, we had to place a bet, and we did.”[6] The Mozilla Foundation hired the lead volunteer developers for each of the two projects: Ben Goodger for Firefox and Scott McGregor for Thunderbird.

The Charter and Governance for Firefox Development

Blake Ross, Asa Dotzler, and Ben Goodger set the charter to create a new browser that would be much more consumer friendly--a browser that “their moms” could use. They wanted to have fun and accelerate the development process by not worrying about backward compatibility, design-by-committee, unnecessary features, marketing requirements, and so on. They also had some design principles[7] they wanted to demonstrate to the rest of the Mozilla community--in particular, how to modularize the code.

Typical Tightly-Controlled Open Source Development Project. The three lead developers made it clear that they would drive the Firefox development process and decisions. They would invite others into the development team as needed, “based on reputation and meritorious hacks.”[8] Like so many open source software projects, the process was driven by a small team of developers who maintained authority over the design and implementation of the code. Thousands of volunteers monitored the progress, and offered contributions and suggestions, but the evolution of the code was carefully controlled by the team of three.

By early 2004, when Firefox was in its 0.6 release, a buzz began to build in the Mozilla developer community. “There were still millions of contented users of the Mozilla Application Suite, but the momentum had clearly begun shifting to Firefox,” Mitchell Baker reported. “We saw significant adoption of Firefox 0.9 through the summer and fall of 2004--almost eight million people came to get a product that hadn’t reached its 1.0 status yet,”[9] Baker recalled.

Marketing of Firefox by Customer Community

I switched to the Mozilla Firefox browser in late 2004. What made me switch? Two things. First, colleagues were telling me how much better Firefox was than Microsoft’s Internet Explorer. Second...

***ENDNOTES***
1) Baker, Mitchell 2006, “The Mozilla Project: Past and Future,” “Open Sources 2.0: A Continuing Evolution.” Edited by Chris DiBona, Danese Cooper, and Mark Stone. O’Reilly.

2) Ibid.

3) Ibid.

4) Ibid.

5) Ibid, p.12

6) Ibid.

7) “Others of us are simply using this as a prototype to demonstrate possible optimizations to the trunk, such as stripping overlays or separating the application into separate processes instead of running one monolithic suite.” From FAQs, http://www.blakeross.com/firefox/README-1.25.html

8) “Principles, Strategy, Tactics, and Concrete Design Decisions.” Extract from the document that launched the Firefox development,
http://www.blakeross.com/firefox/README-1.25.html

9) Ibid, p. 14

10) Krishnamurthy, Sandeep 2005, “The Launching of Mozilla Firefox: A Case Study in Community-Led Marketing,” University of Washington, Bothell, Version 1.0, January 27.

11) Ibid.
***ENDNOTES***