You are currently viewing a snapshot of www.mozilla.org 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 www.mozilla.org, please file a bug.

The mozilla.org Advocacy Pulpit

In addition to being a kind of giant "switchboard" for
connecting together the developer community, we feel that
one of the most useful roles mozilla.org
can play is that of advocate. The number of people who want
to work on the Mozilla code can be huge, and so we will try
to use our pulpit here to build consensus on what we see as
the most important issues and thereby arrive at some kind
of coherence in the direction of development, at least for
major features and large changes. You could think of these
as the documents that describe the "core values" of the
project.

This essay exhorts you to keep in mind what we
perceive to be Mozilla's greatest strength that it uses
the same interface for the same task, regardless of how
the service is implemented on the other end. We believe
that consistency in the user interface is a big part of
what made Mozilla the success that it is today.

This document explains what Internationalization
and Localization (I18N and
L10N) are, and
why they should matter to you: why it's important
to write code that is localizable and works with
all languages, and how the existing
infrastructure in the source can help you do
this.

An essay by Mitchell Baker, written in 2003,
covering the big picture, Gecko, XUL, Camino and Safari,
and why web browsers still matter.

Essays that will be found here in the future will
include:

Cross-platform code

Why it's a good thing; an appeal to not fragment
the user base with gratuitously system-specific
improvements; why "it works for me" is not a long-term
plan for survival. (For technical details, check out
the C++ Portability
Guide.)

Modularity

An appeal to add infrastructure before adding
features; suggestions on how one can do both at the
same time; how to write a good API. (For technical
details, check out the Extending Mozilla
document.)

Backward compatibility

Why keeping old web pages (and code) working is of
utmost importance; how to create a new API without
breaking the old one, and why you should care; why mom
and pop need your help more than the developers of the
world.

No doubt many of you will see these as obvious and we will
be preaching to the choir; and that's great. The purpose of
these essays is to lay out those tenets we believe to be most
important to the goals of this particular open-source software
project: to produce code that is of the most utility to the
largest number of people.

Contributions of editorials are, of course, welcome. If you
would like to write one, let us
know.