The Mozilla Project and

I'm often asked questions about how the Mozilla project operates. Since there are probably many people with similar questions, I've created an overview of and the Mozilla project. (A more detailed breakdown can be found in Mozilla Roles and Responsibilities.) In this discussion, I use "Mozilla" to mean the codebase itself, "Mozilla project" to mean the set of activities around the Mozilla code (development, testing, etc.) and "Mozilla community" to mean the set of contributors engaged in these activities. Staff staff members provide the overall guidance for the project.

Staff members focus on the Mozilla project as a whole, not on any particular Mozilla-based product. Some members of the staff are focused primarily on the code itself, in the development, review and quality arenas. Others focus on the tools uses. All of us focus on community building: learning what the Mozilla community needs and trying to provide it. Some staff members are paid to work full time on the Mozilla project, others are paid to work part time on it, and some are unpaid volunteers. We represent different perspectives, but we share a common focus on the success of the Mozilla project.

The bulk of the coding is not done by staff members; the project would progress very slowly if this were the case. We do some hacking in areas where staff members have particular expertise, or where problems need solving. But the Mozilla development community does the bulk of the development.

To promote distributed decision making by the development community, staff delegates decision making authority for particular sections of code (known as "modules") to individuals who are close to that code. These individuals are known as "module owners." Each module owner is authorized to make design and implementation decisions about that module, to approve code for inclusion in the source code repository, and to grant to others the right to add code to this repository. In this system, staff members do not review each change to the source tree before it is checked in. Doing so would be an enormous administrative drag on the project.

Instead, staff reserves to itself final decision making authority. This includes the right to designate and remove module owners, to resolve conflicts among contributors and to determine the direction of the project, the code included in the repository, and the process by which the project is run. staff exercises such rights only when necessary. This allows the project to proceed quickly while maintaining staff's ultimate authority.

In making decisions, staff uses the following guidelines:

  • Decisions ought be proposed and discussed in public forums, and the resolution communicated in those forums.
  • Consensus should be sought, but unanimity is not required; few important decisions will be unanimous.
  • Alternatives that avoid head-on confrontation between contributors ought to be explored very carefully and adopted where appropriate.
  • Goals limited to a particular contributor should be implemented in that particular contributor's world.
  • Decisions must be based on what we believe is best for the entire community, not based on the desires of any one contributor. (the Mozilla Organization) a virtual organization consisting of staff and its delegates. It is the entity that coordinates Mozilla development. The mission of is to foster a successful open-source project. This means our core functions are to guide the overall development of the Mozilla code itself, and to be the central meeting point of the Mozilla development community. Participation in the Mozilla project is entirely voluntary, and the Mozilla Organization strives to make participation both useful and desirable for potential contributors.

The Mozilla Organization provides a wide range of services to assist the Mozilla development community. We provide technical and architectural direction for the Mozilla project, working with contributors to make the Mozilla code useful in a wide variety of products, platforms and devices. We manage our source code repository with the same goals in mind. We develop and implement processes to enhance public discussion, distributed development, and peer review. We maintain the website and provide Mozilla-related ftp services, newsgroups and mailing lists. The Mozilla Organization also develops and maintains a range of tools for use in the project. A good example is Bugzilla, an open source bug tracking and management system developed by and administered by to coordinate the Mozilla project's development efforts.

Mozilla Public License

Occasionally the multiple roles played by a contributor cause confusion. For example, Netscape was a major contributor to the Mozilla code. At the same time, Netscape used the Mozilla code as the basis of its Netscape 6 product. This caused some people to mistakenly believe that the Mozilla code and Netscape 6 are the same thing. This is not correct. Anyone is free to use Mozilla code to create a product, and to combine Mozilla code with other code to create that product. Netscape did just this, starting with Mozilla code, adding a set of Netscape specific items and additional code, and creating Netscape 6. Anyone is also free to use a subset of the Mozilla code in a product. Many companies embed the Gecko layout engine, for example.

The Mozilla Public License (the "MPL") sets out the terms under which the Mozilla code may be used. The MPL has been approved by the Open Source Initiative as an Open Source license. The MPL provides access to the Mozilla code on equal terms to all. The MPL requires "Modifications" to MPL code, including new APIs, to be made available in source code form. It then allows combination of MPL code with other code governed by different, non-open source terms. For example, anyone is free to create a commercial product by using Mozilla code, adding an API, making that API available under the terms of the MPL, and then using that API to call a proprietary library. In such a case, the MPL will not affect the proprietary library, which may retain its own, different license.

Mozilla Community

The Mozilla community includes all those who contribute to Mozilla, doing any of the multitude of things that help make Mozilla useful and successful. These actions ultimately determine the direction of the Mozilla project, through the contributions made and through participation in the Mozilla forums where the day-to-day activity takes place. Some people participate as individual volunteers, some through their educational institution, and others work at commercial organizations.

Mozilla is already an extraordinarily active open source project. Excluding for the moment engineers employed by Netscape, the Mozilla community includes contributors who participate in a wide range of activities. Some play the quintessential role of developing and contributing new features and fixing bugs in the code. Examples include MathML, the IRC client Chatzilla, the XML parser, the Active X component, Linux plug-in support, plain-text processing, Java integration, bi-directional language support, and XML-RPC. Other contributors test the product, finding and documenting bugs, and creating test cases and other tools to assist developers.

Contributors create ports of Mozilla to additional platforms. Others localize Mozilla for particular languages and cultures. Some help implement standards. Others help with communication, maintaining the website, writing documentation, and educating new members of the community. Communication occurs through the website, the developer newsgroups, our bugtracking database "Bugzilla", and the Internet Relay Chat ("IRC") channel #mozilla on

The Mozilla project is attracting dedicated, diligent and phenomenally talented people, both as individual volunteer participants and as employees of commercial vendors like Netscape. Mozilla is a vibrant project today with enormous potential for the future. Come join us.

Mitchell Baker
Chief Lizard Wrangler