You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

our mission

Netscape Communications made two important announcements on January 23rd, 1998:

  • First, that the Netscape Communicator product would be available free of charge;
  • Second, that the source code for Communicator would also be free.

On March 31st, the first developer release of the source code to Communicator was made available.

But what now? For the product to grow and mature and continue to be useful and innovative, the various changes made by disparate developers across the web must be collated, organized, and brought together as a cohesive whole.


Mozilla was the original code name for the product that came to be known as Netscape Navigator, and later, Netscape Communicator.

Later, it came to be the name of Netscape Communications Corporation's dinosaur-like mascot.

Netscape Communications Corporation holds trademarks on the names Netscape, Navigator, and Communicator; it has not yet been decided what, if any, restrictions Netscape will place on the use of those names.

Now, we use the name "Mozilla" as the principal trademark representing the Foundation and the official releases of internet client software developed through our open source project. is a group chartered to act as the virtual meeting place for the Mozilla code. That group is overseen by the Mozilla Foundation. We will provide a central point of contact and community for those interested in using or improving the source code:

  • We will provide technical and architectural direction for the project.
  • We will collect changes, help authors synchronize their work, and periodically make new source releases which incorporate the best work of the net as a whole.
  • We will operate discussion forums (mailing lists, newsgroups, or whatever seems most appropriate.)
  • We will coordinate bug lists, keep track of and publicize works in progress, and generally attempt to provide "roadmaps" to the code, and to projects based on the code.
  • And we will, above all, be flexible and responsive. We realize that if we are not perceived as providing a useful service, we will become irrelevant, and someone else will take our place.
  • We are not the primary coders. Most of the code that goes into the distribution will be written elsewhere, both within the Netscape Client Engineering group, and, increasingly, out there on the net, at other companies and other development organizations.

    We are code integrators. And, through our forums, we will try to help people reach consensus, and thereby provide direction and coordination for future improvements.

It can be observed that all successful open-source software projects follow this model of distributed development and centralized integration. One of the fears that open-source software software neophytes often express is that open availability of the source will lead to balkanization, that there will eventually be thousands of different descendants of the original software, and confusion and chaos will result. But, in reality that doesn't happen; organizations like tend to appear. Eric Raymond tries to explain why in his excellent paper, The Cathedral and the Bazaar. We hope to operate in the "Bazaar" style, and be to the public Netscape source code as Linus Torvalds is to Linux.

How we operate

As explained earlier, those of us here at are not the primary coders of the Mozilla web browser. We function as a switchboard, facilitating the cooperation of the thousands of participants out on the net. And we assemble the fruit of that labor in one place.

The real work gets done by people like you.


How can you participate? Simply by doing so! We believe in deeds, not words. We operate as a meritocracy, so the more good code you contribute, the more you will be allowed to contribute: that is, the better a developer you prove yourself to be through your actions, the more responsibility you will be given. This is not a Consortium. There is no such thing as membership. If you contribute code, then you're a member. It's as simple as that.

Now, in our role as integrators of the work being done by the countless others out on the net, we do have to have some rules. If we just blindly accept any patch thrown at us, pretty soon we'll have total chaos, and a source tree that doesn't work, and that's no good for anybody.

Module Owners

The basic model we intend to operate under is that each major module will have an owner designated by That person will be someone who knows the code well; is actually involved in developing the code, works well in the open source environment, and who feels that they are up to the task of being the arbiter of what should go in to that module, and what shouldn't. This person will also be the primary coder, but this is not a requirement. The module owner accepts improvements and bug fixes from others on the net.

Changes to a module are made by that module's owner, and then sent to for inclusion in our source distributions. If the owner of a module is new to the job, then we're probably going to work pretty closely with them to make sure that we're actually helping each other out: that they're giving us what we need to meet our desired level of quality, and that we're giving them the information and assistance they need. There are no hard and fast rules here, but one thing that is definitely true is that module owners will come to be judged, both by us and by the public, based on what they've accomplished.

Benevolent Dictator

In this way, it's a self-regulating system: if a module owner is viewed by the public as not doing a good job (perhaps their releases tend to be buggy, or non-portable; or perhaps they aren't responsive to bug fixes or suggestions) then what will happen is, someone out on the net will say to themselves (and to us), hey, I can do a better job than that. And we will say to them, go right ahead.

If the usurper and the old module owner can't work out their differences, then by default, the final decision becomes that of us here at we will be in a situation where there are two people asking us to take their version of some particular module, and we're going to pick the better one to include in our source releases.

Now, hopefully it will almost never come to that. In most cases, we won't have to make those kinds of hard decisions, because people will tend to work it out themselves, and cooperate, and accept help when it is offered. There exists years of evidence in the open-source software community that such things tend to work themselves out without a big fuss.

But, we here at decide what we put in the source distributions that we make. So that gives us final say on what goes into our distributions.

Of course, anyone anywhere in the world can make their own source distributions: we aren't unique in that respect. And that's another way that the system is self-regulating: if the public believes that we are making bad decisions about what to include and what not to include, about whose work to use and whose not to, or anything of that nature, then the public will vote with their collective feet: they will get their source distributions from someone other than, and we will have become irrelevant.

This is the way nearly all successful open-source software projects work, and that's why we're emulating it. We call this the Benevolent Dictator model. Dictator because there is one person (or organization) who eventually gets final say in the case of disputes; and Benevolent because the dictator always tries to do the right thing. Because if the dictator stops doing the right thing, the dictator becomes ignored, and ceases to be a dictator at all.

For those more democratically-minded, another way of looking at it is that the final arbiter really is something of an elected official: the voting process consists of whether anyone listens to them.

What Now?

So you want to help? Great!

Read our Getting Involved document if you want to know what work needs to be done. Read the Hacking Mozilla document to find what to do to submit code.