Open Sources 2.0

Chapter 1. The Mozilla Project: Past and Future

Mitchell Baker

The Mozilla project was launched on March 31, 1998. On this date, the source code for the Netscape Communicator product was made publicly available under an open source license, the “Mozilla Organization” was founded to guide the project, and development of the codebase began to move from a proprietary model into an open model coupled with commercial involvement and management practices.

Of these three elements, the release of the source code is discussed in Open Sources. In summary, 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 (http://www.opensource.org). The other two topics—the story of mozilla.org and the development of the Mozilla project—are the subject of this essay. The creation of the Mozilla Public License is generally an untold story, but it occurred during the time covered by the original Open Sources book and isn’t discussed in detail here.

Each of these three activities was a step into the unknown. Basic development principals of the open source model (“running code speaks,” peer review, leadership based on technical merit) were known. But the combination of open source techniques with an active, focused commercial management structure was uncharted territory. The shift of authority from a commercial management structure to a separate organization was new, and presented many management challenges. The development of project management techniques and tools that could be shared by multiple commercial development teams and a volunteer community was new. Development of a large, complex end-user application in the open source space was new.

Of course, the Mozilla project was not the first open source project with commercial involvement. Cygnus, many of the Linux distributors, and Sendmail were all companies involved with open source development, and the Apache project was developing experience in coordinating open source development where some of the contributors were paid by their employers. But none of these projects provided more than a rough set of guidelines for how the Mozilla project might operate. The Mozilla project was unusual, and at the time perhaps unique, in the way project leadership interacted closely with both commercial teams (project managers, people managers, and engineers) and individual contributors.

Not all open source projects are interested in commercial project management and people management issues, but for us it was always a given. Today other projects are thinking about these issues as the development and use of open source software increase. Given our history, size, and scope, the Mozilla project remains a trendsetter in this arena.

Founding of the Mozilla Organization: Obvious for Developers, a Bold Step for Management

The Mozilla project originally grew out of Netscape Communications Corporation and its Netscape Communicator product. In early 1998, the Netscape management team made the decision to continue development of Netscape’s flagship product, Netscape Communicator, through an open source development model. At the time, Netscape Communicator and Microsoft’s Internet Explorer browser were locked in a fierce competitive battle often referred to as the “browser wars.” 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.

At its inception, the Mozilla project faced some paradoxes. First, the only people familiar enough with the code to participate actively in its development were Netscape employees. Those employees were still expected to work within the management system and practices that Netscape had developed in its proprietary days. There was no volunteer community. And yet, even at that early time, it was clear that the long-term success of the project required a broad constituency of people and companies working jointly on the project. It was not enough to have open source code (code available under an open source license). The project needed an open development process, and this required authority over the code’s development to be based on technical merit and distributed outside Netscape. The question was how to get there from here.

One thing was clear: the success of the project depended on it being a real open source project. In other words, the project needed to have technical legitimacy and development decisions would need to be guided by technical considerations. This was intuitively clear to the group of Netscape employees who were familiar with open source, eager to help move the Mozilla code into the open source world and who ultimately became the founding members of the Mozilla Organization. This group made the need clear to Netscape management, which was receptive to trying to do the right thing.

When the Mozilla project was officially launched, Netscape executive management therefore took some bold steps. First, they officially anointed “mozilla.org” as the steward of the codebase and leader of the project. I say officially because it’s quite possible that a group like mozilla.org would have developed even if Netscape hadn’t officially helped to create one. But this step was important, as it allowed mozilla.org to focus on building the project rather than on proving the necessity of its role.

The creation of mozilla.org was a significant step that set the tenor of the project’s development. It meant that the development of the Mozilla codebase was to be guided by something other than Netscape’s own product and revenue plans, and also that Netscape management would need to give up control. This may seem like an obvious statement in an open source world, but it is one of the most difficult problems in moving from a proprietary to an open system. It is particularly difficult when the commercial vendor is actively trying to ship a product and the code has not yet reached a good, solid state that can serve as the basis of that product.

Some have said that the Mozilla project was not a true open source project during this time because Netscape employees contributed so much to the project and Netscape management was so involved for so long. It’s possible this is true. But I believe that Netscape management lived in an intensely uncomfortable setting as control of the project moved from their hands into those of mozilla.org. And since I personally was the fulcrum for stresses between the project leadership and the Netscape management team, I’ll warrant that Netscape management felt it was living in a real open source project. In 1999, Netscape Communications Corp. was acquired by America Online (AOL). This resulted in many changes, but the relationship between mozilla.org and the Netscape browser development group continued as before. For quite a while, we used the term Netscape/AOL to describe the Netscape browser development group after the AOL acquisition, and I’ll use that phrase for the rest of this chapter.

The members of the Mozilla Organization are known as “mozilla.org staff.” The original members of the 1998 launch were Netscape employees who had a vision for an open source Mozilla project and a determination to see it succeed. The most media-genic of these founders was Jamie Zawinski, who left the project after a year. But the most consistent and long-term contributor has been Brendan Eich, who was a founding member of mozilla.org and remains the technical and philosophical leader of the project to this day. Over time, the percentage of mozilla.org staff employed by Netscape decreased steadily. Today, the mozilla.org staff does not have any Netscape/AOL employees.

After the Mozilla project was launched, mozilla.org staff members began the process of changing development styles from a proprietary to an open source model. The early steps were logistical: establish public communications channels such as mailing lists and newsgroups; establish a public system for viewing and tracking bugs. A harder task was changing habits. For example, the existence of public communications channels was not enough. Old habits die hard, and there was a tendency for people to use the methods they had always used. This was complicated by the fact that Netscape as a company still had confidential data about itself and its business partners that couldn’t go into public forums. So, it was not possible to eliminate all private channels. Eventually we changed the names of any remaining private mailing lists to something long and awkward that required conscious thought to use. This gave Netscape/AOL employees a way to disseminate confidential data when necessary, but made public disclosure the easiest path.

Even as basic a step as public communications in an open source project can be difficult for some management teams to accept. In a system that is public by default, everyone needs to learn what information must remain confidential, and to remember this while working. At first it’s a big effort to work in public and some people see it as overhead. Then as the project progresses and the public interaction provides increasing value, the need to keep something private is seen as a burden. This is certainly the case for the Mozilla project today, where the only private development information we solicit are bugs which could have an impact on the security features of our products. We’ve set up a system for treating these bugs privately, and the system has overhead. We bear it in the security context because security is critical, but we avoid it in other contexts.

We also set up a public bug and issue-tracking system. This is commonplace today, but was innovative at the time. We made the bug-tracking system an open source project under the Mozilla umbrella, and today Bugzilla is a successful project in its own right (http://www.bugzilla.org). We also set up a continuous build system and web frontend (http://tinderbox.mozilla.org/showbuilds.cgi). This means that we have an automated process that builds and rebuilds the software continuously on multiple platforms to see if and when a new piece of code causes the software not to build. Then came a period of learning to “work in the fishbowl.” Some people adapt easily to having all their work visible, and others struggle. Many simply walk down the hallway to talk with a buddy, and then forget to tell everyone else. This period takes some time and effort.

Updating the Codebase

About six months into the project, it became clear that the codebase was in need of updating. By late 1998, the inherited code was several generations old, had been patched over and over, and actually hindered ongoing innovation. Old and fragile, it looked backward toward the beginning of the Web, rather than forward to the new technologies a modern browser would need to support. So, in late 1998, a painful decision was made to rewrite the layout engine, a critical and complex core component.

This decision changed the scope of the project dramatically. The initial project was an incremental upgrade from the Netscape Communicator 4.x product line to a proposed 5.x product line. Moving to the new layout engine (known as Gecko) meant that the incremental model was gone; the Mozilla project would need to develop a complex new layout engine and then build a new browser application on top of it. And things got harder from there. As the new layout engine began to mature, it became clear that other significant parts of the codebase would also need rewriting. The development process turned out to be a lot like a remodeling project where fixing one problem leads to another. Then came the long, slow grind to producing something useful (Mozilla 1.0 in June 2002) and finally something great (Mozilla Firefox in November 2004).

During this time, many proclaimed us dead, a failure. What those people didn’t see was the passion and commitment of the contributors to the project, including the Netscape employees. The contributors knew that they were developing good technology. They knew they had a shot at building a great browser and mail client. And they knew it mattered. The Web matters. Browsers matter. Much of the world decided that the days of browser innovation were over. Some mourned the loss of choice, and many didn’t realize the dangers of accessing the World Wide Web only through a single access point. But the contributors to the Mozilla project realized both the danger and the potential for something innovative. They persevered. The prominence of Netscape often obscured the efforts and dedication of the individuals themselves. Yes, many contributors were paid by Netscape. Of these, many contributed far beyond the requirements of a job, doing extra work to make the product “theirs” and to make sure they were proud of it. Meanwhile, the individual volunteers provided critical expertise and contributions across the codebase.

During this period, almost all the code in the Mozilla browser and email client was rewritten. The focus was a modern layout engine, and a set of technologies designed to make the promise of cross-platform development a reality for the Web. We created a cross-platform component model (XPCOM),a cross-platform XML-based UI language known as XUL (pronounced zool), a new toolkit using XUL, and a set of cross-platform applications themselves. Developing these was a long process, but we felt that it was important to have technology that would help us move forward. The power of these technologies has been demonstrated through our new products: Mozilla Firefox and Mozilla Thunderbird, in which we were able to build award-winning cross-platform applications quickly on top of mature, preexisting infrastructure.

A Disciplined Methodology

Along the way, the Mozilla projects developed a highly disciplined method of distributed software development. Many people think that open source development is necessarily chaotic. Or they wonder about the quality of the code because anyone can create a patch and offer it for inclusion in the source base. Open source need not be chaotic, and the Mozilla project is not. For every piece of code checked into the Mozilla products, we track:

• Who checked it in

• When it was checked in (to the minute)

• What problem it was trying to address

• The complete history of the issue (bug) the code was trying to address

• Who did the code review (often two levels of review)

• Whether the next build of the software was broken on any of our main platforms

• Whether the code affected our performance metrics, by platform

• Build and optional log comments

• A comparison with the previous version of the code.

This information is available at any time; it does not require an expert to find or assemble the data. It is available online, in real time, through a web interface; all one needs is a web browser (http://tinderbox.mozilla.org/showbuilds.cgi). We do this so that many contributors can work on the same codebase simultaneously and know what’s going on. We do this so that the source code “tree” stays healthy, and we address problems before more new code makes them worse. We also have policies determining who gets access to the CVS tree, what’s required before code can be checked in, what to do when the tree doesn’t compile and run, how authority is delegated to those with expertise, and so on.

Building an Open Source Project

The process of building software proceeded simultaneously with building a vibrant open source project. The creation of mozilla.org had gone hand in hand with the recognition that Netscape management would need to give up a great deal of control over the development process. Now it was time to figure out how to make the transfer. I describe in this section two of the most significant topics we addressed—control over the source code repository and control of the designated releases—in some detail, for I believe this shows how the Mozilla project came of age.

Implementing a transfer of control from Netscape management to mozilla.org caused a number of strains. Mozilla.org staff could have proceeded in opposition to Netscape. Indeed, we thought about it many times. However, Netscape was a large and valued contributor, whose involvement and work product remained very important for the project. So, we spent a great deal of energy figuring out techniques that addressed the concerns a commercial entity like Netscape brings to a project and simultaneously building a strong open source community.

Having control of the source code repository may seem like an obvious requirement for an open source project, but there were many sensitivities in our case. For example, the Mozilla project has processes to make sure that code is of good quality before it is checked in. This is often the case in open source projects, and many contributors understand that their code needs to meet project standards. However, this is not always the case in commercial settings. Often the employment decision is what matters. If someone is an employee, his code goes into the project he was hired to work on. Instituting code review for everyone, even people employed to contribute code, can be a surprise for new employees and for their managers. Suddenly the decision of what code goes into the source repository is not made by managers for a particular person through the employment process. Instead, the decision is made by engineers who review the code itself rather than the person’s credibility or employment status. And the code review is not optional or auxiliary; code cannot be checked into the tree until an appropriate reviewer has given formal approval.

We instituted code review as a prerequisite to check-in relatively early in the process without too much controversy. Sometime later we implemented a second layer of review which we ended up calling “super-review.” Super-review is an “integration review” or “plumbing review.” Does the code conform to coding guidelines? Does it use the somewhat tricky XPCOM in appropriate places and not elsewhere? Does it conform to the overall architectural goals? Does it avoid needlessly diminishing modularity?

We instituted the super-review requirement because we felt we had to. The Mozilla codebase is large and complex, and we were worried about overall code quality. We needed to increase our confidence that the code we were accepting into the tree would solve the immediate problem, and still leave us enough flexibility for future development. Implementing the super-review was very painful for everyone involved. It was painful for the identified super-reviewers. Being a super-reviewer is actually a lousy job—who wants to review yet more code instead of writing it oneself? And of course, the super-reviewers were well regarded and had plenty of work to do themselves. They took on the super-review job not because they wanted to, but because they believed it was important to making Mozilla the project we wanted it to be. Super-review was also painful for the contributing engineers. Adding another layer of review to the pre-check-in requirements was seen as “yet more bureaucracy” by some.

There were many requests for absolute, guaranteed turnaround times for super-review. Engineers and managers complained they could not schedule work accurately due to the unknown lags caused by waiting for super-review. And yet, the super-reviewers had to balance review of code with writing their own. And since they were well regarded, their code was acutely needed. I was unwilling to agree to rigid turnaround times for super-review, believing that doing so would put the work of key contributors at risk. We eventually agreed on a timeframe for an initial response from the super-reviewer, which would contain some estimated time for full review.

Another issue was determining who has “write-access” to the source code repository. This was extremely sensitive. In a commercial setting, it is often the case that when people are hired they are given access to the part of the source code repository to which they are expected to contribute. In open source settings, one typically earns access by making valuable contributions. Moving the open source standard of “earn the right to touch the tree” to employees who need to contribute code to do their job can be difficult. In particular, the rationale for why this is necessary can be hard to explain in a commercial setting when all the code an employee writes must be reviewed and super-reviewed before it can be checked in. The question comes up: assume Employee X is hired. She writes code, and it passes review and super-review. Why on earth can that employee not go through the mechanical task of actually checking the code in? I was never able to provide a complete answer to this question. I know that open source projects regularly vet people before allowing access to the source code repository. And I know it would be very odd for a management chain in a company to make the decision about CVS access. So it’s clear that this “is just not done.” But I was not able to explain clearly how someone could do damage by having CVS access if all of her code was reviewed and approved before check-in, even though the technical leadership of the project felt very strongly about this. The idea of automatic access for employees had an emotional response because open source projects rely on peer review and technical leadership, and I shared this. But the key engineers were adamant that the quality of the code would suffer through automatic access, even though our pre-check-in code review requirements are quite stringent.

It was an awkward setting to institute a policy for which I couldn’t give a crisp reply to the various management teams affected. (I’ve been responsible for policy for mozilla.org since 1999, so it was my job to write the policy, describe it to management, and address the concerns and complaints that might come up.) And the possibility existed that management groups would be surprised, distressed, or outraged that such a policy would be instituted without a clear answer as to why the code quality wasn’t adequately protected. Nevertheless, we instituted this policy in 2001.

A second area where shifting control to mozilla.org was highly sensitive concerned control of the milestone releases. By “owning the releases,” I mean several things: first, defining and implementing a planned milestone schedule; second, defining and implementing a process for getting a release into shipping condition; and finally, identifying and shipping the release.

When the Mozilla project was launched, the planning and release schedule was determined and implemented by Netscape employees contributing to the project, but not directly by mozilla.org staff. We worked on changing this for quite some time before we had proven ourselves trustworthy enough for Netscape to give up control. This may seem laughable—how can a so-called “open source” project not control its own releases? But it’s important to remember that Netscape was under enormous pressure to release a product, and giving up control of the process by which releases are made is extremely uncomfortable. Mozilla.org was new and unproven. And of course, managing a software project with hundreds of people working on it is not easy in any setting.

Control of these aspects moved formally from the Netscape management to the mozilla.org staff following the release of the Netscape 6 browser. This shift had been discussed for some time but still involved a leap of faith for those who had previously exercised decision-making power.

This was a tempestuous time; mozilla.org staff had influence, but not control. We thought many times about whether we needed to create a fork in order to affect such a shift in control. Each time, the mozilla.org staff decided that Netscape’s contributions were far too important to the project and outweighed the desire for open source purity or credibility. I suspect that the Netscape management team must have had similar discussions, weighing a fork and the ability to manage their releases as they felt best with the value gained from the open source project. In the end, we all hung in and mozilla.org staff became the official keeper of our releases after Netscape 6.

Owning our releases did not mean that we ignored Netscape. Netscape remained the largest single contributor, and its pool of talented and dedicated engineers was boggling. Netscape was also the largest single distributor of Mozilla-based products. Managing the project without taking Netscape’s needs into account would have been stupid. By this time, Netscape didn’t exercise control as it once had, but its leadership role in the project was greater than some might have liked. Mozilla.org staff continued to hear from the community that we were Netscape stooges and there wasn’t a “real” open source project. However, to my mind, Netscape’s role was now determined by classic open source principles: leadership and influence through the quality of one’s contribution. Of course, this involves an acceptance of the role of a corporate entity in an open source project, which made some uncomfortable.

Mozilla.org was able to own our releases well, in part because we had developed an active, effective quality assurance (QA) community. Over the years, I’ve learned how few people intuitively grasp the importance of the QA effort (and I suspect, how important QA will be to other projects of similar scope). Both of our major efforts—web browsing and email—live in an extremely complex world. The Web is very diverse, and people use our software in a boggling array of environments and in wildly different ways. Hiring a QA team as full-time testers is part of a solution, but it is not the complete answer. I’m becoming more and more convinced that it may well be impossible to hire a QA team big enough and diverse enough to do thorough testing of a product like a web browser.

By 1999, it had become apparent that an active community of people was interested in contributing to our testing and QA effort. Christine Beagle joined us to lead an effort at mozilla.org to make this group cohesive, figure out ways to give the group some authority, and encourage them to step forward. The response to a bit of attention and appreciation directed at this nascent community was astounding. One mark of success is that shortly thereafter, we hired one of the more active and organized of these folks as our community QA lead. This person was Asa Dotzler, who has been a key figure in the project ever since, still coordinates QA activities, and is extremely active in managing our release process. With Asa’s coordination, we began to see a set of people doing more organized testing of our products. This provided enormous value. The testers also did things such as look at all the bugs assigned to a particular engineer, verify that the bugs were legitimate, check to see if the bug existed on all platforms, create test cases, and then verify fixes across our main platforms. These efforts saved enormous amounts of time for the engineers trying to write the code to fix the bugs. I’ve learned that this type of work often gets little respect, but we value it highly and find these contributors to be extremely important to our project. Many of these efforts were coordinated through mozillaZine, an independent webzine dedicated to the Mozilla project that was founded by Chris Nelson in September 1998 (http://www.mozillazine.org).

Massive community testing remains important today. We provide Release Candidates for our major product releases precisely so we can get 50,000-100,000 downloads from our key community and get a good reach on quality.

Young Adulthood—the Mozilla Foundation

The idea of an independent legal organization to guide the Mozilla project had been discussed when the project was first launched in 1998. However, it was decided that the time was not quite right. At the time, there were no models for setting up such an organization and figuring out how it would be governed, who would participate, and so on. There was enough unknown and far too much work in getting the code ready, the project launched, and a browser developed to take on things we didn’t absolutely have to do. Eventually we decided that the right time to create an independent Mozilla Foundation would be when a critical mass of people was interested in supporting a foundation. That critical mass would need to include a significant set of volunteers and a set of companies interested enough to fund browser developer and distribute Mozilla-based technology.

That critical mass began to develop with the release of Mozilla 1.0. Mozilla 1.0 showed that we could produce a good product, that the Mozilla releases where determined by Mozilla rather than by Netscape, and that the project had a positive future. At least one critical corporate participant came to us and told us that 1.0 proved our viability and that they were very interested in helping form and support an independent Mozilla Foundation.

Following the release of Mozilla 1.0, I spent a fair amount of time thinking about what an independent Mozilla Foundation would look like, how we might put it together, how many employees we would need, which companies would likely provide support, and how to finance employees in the early years. I had help from a set of mozilla.org staff members. In addition, I had the good fortune of hooking up with Mitch Kapor, who had recently joined the open source world with the launch of the Open Source Applications Foundation (http://www.osafoundation.org). Mitch was an immense help in thinking through various possible structures for the Mozilla Foundation and is an unsung hero in getting the Mozilla Foundation launched.

In the spring of 2003, the stars aligned. Mozilla.org staff was ready, the project had developed a critical mass, and we had some corporate support. In addtion, AOL decided it was ready to help spin out the Mozilla project. This was an important element for mozilla.org staff. Of course, we could have launched a project without AOL’s support—that’s the nature of open source—but the mozilla.org staff felt that AOL’s support was important to the launch of an independent Mozilla project. We hoped that the use of the Mozilla trademarks would be transferred to a new organization, along with a set of machines. We wanted to be able to hire a group of people, some of whom were current AOL employees, without bad feelings. We felt it was very important to the project’s stability to have a smooth transition from AOL to a successor. We also knew we needed to hire people to keep the project running well, and that it would take us time to find ongoing funding sources. So, the seed funding that AOL provided was another critical factor. Through July, I worked to reach agreement with AOL on how the Mozilla Foundation would be launched. Once again, Mitch Kapor provided invaluable assistance in helping to get the arrangements with AOL worked out.

On July 14, 2003, the Mozilla Foundation was launched as an independent non-profit organization. AOL contributed $2 million in seed funding for the Mozilla trademarks, the Mozilla Public License, the machines we were using to host the web site and other infrastructure, and the efforts of a transition team to help create a smooth handoff. We knew we had some additional funding from IBM and Sun, and Mitch Kapor donated $150,000 for each of the first two years. Based on this, Brendan Eich and I decided, with the help of Chris Hoffman and Mitch, to aim for an initial group of 10 employees.

The initial group was divided among (i) those focused on the projectwide resources (technical leadership, infrastructure, tools, web site management, builds, releases, QA), (ii) those focused on the codebase itself (Firefox, Thunderbird, Gecko, the DOM, and JavaScript) and (iii) a couple of people focused on all the other things the project and the Mozilla Foundation needed to be successful, including relationships with commercial contributors and other organizations, legal structure, trademarks, finances, and so on. Mitch Kapor offered to extend his organization for providing back-office services—payroll, benefits, accounting, donation processing, and human resources—to the Mozilla Foundation on very gracious terms, which has been a great boon. Securing high-quality services in these areas for the Mozilla Foundation had always been of concern to me and this has been a phenomenal solution for us.

This resulted in a group that was small for the scope of the project, but still big for a nonprofit open source project to support. We chose this route because we believed that the project was unlikely to reach its potential without a core group of at least this size. We felt this was the minimum size for critical mass for several reasons, including these:

The World Wide Web isn’t finished.

It’ changes all the time. New content types develop, new technologies develop, and new possibilities emerge. If the browser doesn’t continue to develop, the consumer’s ability to enjoy these enhancements stagnates.

Browsers and email clients aren’t done yet.

There’s a whole range of innovative ideas that interact with browsers and email clients. For example, RSS readers can be nicely integrated with both browsers and email. In addition, the underlying components on which the actual end-user applications are built require constant development.

Speed matters.

We need good Internet clients now. Having a core set of people able to devote full-time attention to this makes a big difference in accomplishing things quickly.

The size and scope of the project requires it.

Just keeping track of what’s going on in the Mozilla project takes time. About 80 people actively check into the CVS repository each month, and of course, many more active participants don’t have CVS access. We also have a high level of involvement with commercial entities and with Mozilla development teams at commercial entities. Providing the technical leadership and coordination for this large a group is a big job, even with a set of full-time employees. Doing so without a set of people available full time (or more than full time) would be beyond daunting.

The founding in July was followed by a hectic startup period through the fall. We assembled the team of employees. We found office space at an affordable rate, thanks again to friends of the Mozilla project who extended a helping hand. We moved our equipment from AOL to our co-location facility and our offices. We knew it was important that enterprises and other institutions got a good picture of the Mozilla Foundation and grew confident that we are not a naive, flaky group, so we spent a chunk of time talking with these groups.

We decided that a serious focus on the end user needed to be added to our traditional focus on developers. Product development continued at a fast clip through this period.

Firefox and Thunderbird

As if forming the Foundation, moving employees, and establishing and supporting ourselves wasn’t enough, we also began a determined transition from the application known as Mozilla or the Mozilla Application Suite, or by its codename, Seamonkey, to our new products: Mozilla Firefox and Mozilla Thunderbird.

We knew that our future lay with the new applications. The integrated Mozilla Application Suite is a fine product that many love. But the integration caused difficulties, the UI had been built by accretion and had been added to over the years, and we knew we wanted updated, standalone browsing and mail applications. Given our limited resources, we had to place a bet, and we did.

The Mozilla Foundation hired the lead Firefox and Thunderbird developers, Ben Goodger and Scott McGregor. We talked with Ben and Scott about providing assistance to the community of people working on the Mozilla Application Suite. We continued with our releases of the Mozilla Application Suite, including improvements to the core components, performance, stability, and security, and coordinating feature work done by our community. But we did not hire people focused on the Mozilla Application Suite.

Both Firefox and Thunderbird were in the early stages of development when we made this decision. Indeed, Thunderbird had not even seen its 0.1 release when the Foundation was launched. Despite this, we knew that the then-current state of Thunderbird could probably have supported an 0.1 or 0.2, or maybe even an 0.3 label. This was borne out when we were contacted over the summer by a Fortune 100 company wanting information about Thunderbird. The company had already done a significant amount of due diligence and had realized that Thunderbird was the best option. They wondered if the Foundation would be interested in speeding development of certain enterprise features if we had some additional funding to do so. As a result, Thunderbird has had a rich set of enterprise features from its early days. It lacks an integrated calendar, but the Mozilla calendar project was reinvigorated and an integrated calendar project launched in the fall of 2004.

Firefox was further along the development path, but still quite young. It wasn’t even called Firefox at that time; it was called Firebird, the second of two early names which we abandoned due to trademark issues. The application-eventually-known-as-Firefox was at the 0.5 stage, quite usable, but not a polished end-user application. The development goal had always been a strict focus on the end-user experience above all else. This continued, and Bart Decrem drove the end-user focus throughout all aspects of the Foundation’s operations. Firefox began to be noticed in 2004 with the 0.6 release. It quickly began to capture the interest of much of our developer community. There were still millions of contented users of the Mozilla Application Suite, but the momentum had clearly begun shifting to Firefox.

In February 2004, we found a public posting by a visual designer named Steve Garrity, describing what Firefox needed for its icons, logos, and visual identity in general. The content of the post was excellent. Better yet, Steve seemed to have both knowledge of and an interest in tackling these problems, instead of simply complaining or pointing out problems. We asked him if he’d like to take the lead for a bit and show us what could be done. He said yes, and the Visual Identity Team was created. Both Firefox and Thunderbird took a giant step toward becoming sophisticated, polished end-user applications. By the 0.8 release of Firefox in June 2004, the momentum for Firefox was growing dramatically. Firefox was already an impressive product, offering features new to most users.

In addition, the Internet experience had become extremely painful. Malicious actors were everywhere. The Web was infested with viruses and security exploits, seemingly uncontrollable pop-up windows appeared almost everywhere, and distracting, bandwidth-chewing ads appeared long before desired web content. The browser, a piece of software many had come to take for granted, suddenly mattered. The browser is the mechanism through which one’s computer—one’s hard drive with its critical and private data—connects to the wild, wild world of the Web. A modern, high-quality browser is necessary to keep this connection from being increasingly painful and even dangerous. The Mozilla Foundation had a great browser in Mozilla Firefox, and people began to notice. By mid-2004 we began to see that the types of people who were interested in Mozilla Firefox were expanding. We began getting messages from people who clearly were neither early adopters nor even particularly savvy. So, we knew we were making a difference. And we knew that the difference was important enough for more people than ever before to pay attention. People who tried Firefox loved it. Around the 0.9 timeframe (June 2004), a groundswell began building.

The summer of 2004 was an even more painful time on the Web. A series of viruses and security issues caused enormous inconvenience and concern. Internet Explorer was a vector for many attacks. These problems caused consumers to pay more attention to their browser. They helped people realize why an alternative browser is so important to the health of the Internet and one’s ability to interact comfortably with the Web. Security is a very difficult problem. A browser must be open to the content of the Web—that’s the whole point. At the same time, it can’t be too open. A browser needs to have a series of defenses to help filter out bad content. No browser can be perfect, and that includes Firefox. We know that we will be making security changes and improvements in our products on a continual basis, and we hope that others do as well.

We saw significant adoption of Firefox 0.9 through the summer and fall of 2004—almost 8 million people came to get a product that hadn’t reached its 1.0 status yet. Mozilla Thunderbird adoption was also proceeding well, though not at the same fantastic rates. On the marketing side, Spread Firefox was launched in September 2004. This was a community marketing effort, perhaps the first of its kind. We knew that the great strength of the Mozilla project is the community of people dedicated to making it successful. We also knew that we would not have a traditional “marketing” or “PR” effort, spending large amounts of money on media events. And the mail we were receiving made it clear that people were excited about Firefox and wanted to help their friends and family switch.

The result was http://www.spreadfirefox.com, the home of a fervent evangelism community focused on increasing Firefox adoption. The most famous Spread Firefox campaign to date has been the New York Times campaign, which was proposed and initiated by a community member. This started out as a 10-day campaign to get 2,500 people to contribute funds to buy a full page ad in the New York Times supporting Firefox. Ten days was the wrong timeframe—2,500 people signed up in the first two days. We kept the campaign open for 10 days anyway and ended up with 10,000 choosing to participate. We had promised that contributors’ names would be in the ad and would be legible, so we enlarged the ad and made it a full two-page ad. It ran on December 16, 2004. A while later I came to work to find two young men standing outside our door. The door is glass and we had taped the NYT ad to the door so that it was visible from the outside. The two young men looked lost, but one wore a Firefox T-shirt. So, as I reached the door to go in, I asked, “Can I help you find something?” The men were rather shy, looking at their feet and mumbling, “We just wanted to see the Mozilla Foundation. We’re only in town for a few days and had to see it.” Then one of them straightened up, looked me in the eye, jabbed his finger at the New York Times ad, and said proudly, “And there’s my name, right there!” Sometimes I think people believe I’m exaggerating when I describe how passionate consumers are after they’ve tried Firefox, but it’s actually hard to overstate the excitement that Firefox has generated.

Getting Firefox and Thunderbird to a 1.0 status and shipped was a very intense period. We knew we had great products in the works, but we had to finish them. We also had to get a set of related activities completed. These included revamping our web site, developing our communications plan, working with the Spread Firefox community, improving our localization process and working with the various localization communities, figuring out our search relationships, working with our affiliates—Mozilla Europe and Mozilla Japan—on the international aspects of the launch, and so on. The ferocious dedication of everyone involved was required. I cannot stress enough the commitment of the Mozilla community. On Sunday, November 7, I logged onto IRC at about 8:00 A.M.., which is early for me and for most of the Mountain View-based staff. I was bombarded with questions from our localization communities in Europe and Asia. Some were up early, many were up very, very late, and all were trying to figure out how to manage their schedules over the next 48 hours to be available whenever needed to get their localized versions finished, approved and shipped as part of the 1.0 release.

Mozilla Firefox 1.0 and Mozilla Thunderbird 1.0 were released on November 9, 2004. To say they have been well received is an understatement. Firefox 1.0 was downloaded from our mirror site about 2 million times in the first two days alone, and has plunged on at an average rate of almost 250,000 downloads per day since then. As of mid-April 2005, the number of downloads that we can track is very close to 50 million. On the usage side, Firefox has gained worldwide market share at a rate of nearly 1% per month from November to April. As of April 2005, surveys are beginning to show Mozilla browsers at or above 10% market share. Among technically focused sites, the market share of Mozilla products ranges up to much higher numbers.

It’s extremely difficult to gain this sort of market share on the desktop in the face of a competitive product that people get when they buy a computer. The fact that Mozilla Firefox has done so is a reflection of a great product, a huge need, a fervent community, and the power of the Internet.

Many people have wondered whether open source development can produce great end-user applications. One school of thought says that open source developers can produce infrastructure and products that other developers like, but not applications aimed at the general end user. Mozilla Firefox and Thunderbird demonstrate that open source software can indeed produce great end-user products. I believe that we are only at the beginning, and we will see a range of innovative end-user products come from the open source world in the coming years.

The Future

The mission of the Mozilla project is to promote choice and innovation on the Web by creating great end-user offerings. We focus on innovation because the Web is still young—we’ve seen only the beginnings of its potential. That potential can be stifled if we don’t have innovative work done on the client side.

We focus on choice because this allows people to have greater control over their Internet experience. This control over our life on the Web increases in importance each year, as more and more critical functions such as banking, health care, insurance, and commerce are done over the Web. A monoculture is rarely a healthy ecology. A single effective choice in browsers and email clients is dangerous, both to consumers and to the health of the Web itself.

Firefox in particular has shown that consumers will pay attention to a product that provides an alternative, and that the Mozilla project can create such a product. We have a number of challenges ahead of us. We need to continue to release products that people love. We have a set of responsibilities that come with the user base, adoption rate, and increased visibility of the project. Conditions will change, and we will need to adapt. These are challenges, but certainly no greater than those we have faced to date. These are the challenges that result from the project’s achievements. We have great talent, a powerful and creative community, a well-earned place in the Internet ecosystem, a growing user base, and, at long last, a legal home for the Mozilla project in the Mozilla Foundation.

As we go forward, there is no change in the mission of the project. Our basic approach of combining open source DNA with involvement by commercial entities will continue. The Mozilla Foundation has grown some and may grow some more, and we expect to continue working closely with a set of companies that are interested in developing and distributing Mozilla technology. The increasing acceptance of open source software by the commercial world opens up greater possibilities for collaboration. The emergence of web-based services provided through the browser also encourages business models for the service provider other than charging for each copy of software provided. This allows more entities to contribute to our project. Our focus on distributed development, technical excellence, and welcoming new participants will continue. The need for a vibrant, creative community of people focused on the Web will not change.

I expect the Mozilla project will continue to be a trendsetter in a number of arenas: development of open source end-user products, combining volunteer and commercial activity in an open source project, maintaining a critical mass of people as employees of the Mozilla Foundation, and funding that set of employees plus community marketing and adoption programs. We aren’t the only ones doing these things, and we continue to learn and benefit enormously from the open source projects. We hope to contribute ever more in return.