

our mission

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






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


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 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.


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.