Since its inception more than two years ago, the Mozilla project has been highly praised and much discussed as an example of the collaborative possibilities of the open source software movement. Thousands of programmers, would-be programmers, and interested technical types discuss the Mozilla project and the philosophy surrounding it. But the process for actually contributing source code appears complex and intimidating to those not involved in the project, and non-Netscape developers contributing their work to Mozilla remain a minority.
The amount of attention being paid to the project in the form of discussions, suggested changes, and private adaptations of the source suggests that the paucity of contributions has more to do with a lack of familiarity with the project and the tools than with a lack of interest. In this article, we attempt to provide a brief overview of the process for getting one's work into Mozilla, and we follow the travails of one company that has successfully done so. Most of the information in this article was presented at the "Contributing to Mozilla" discussion at the Second Mozilla Developer Meeting, moderated by Daniel "Leaf" Nunes. The enthusiasm that attendees had for this particular session was one of our primary motivations for doing this article.
It's true to some degree that the process is not an easy one, and there are a great many things to learn, to pay attention to, and to do with care. But the results can be extremely rewarding -- both for you and for the Mozilla open source community. The next section lists the resources you can use to get your work contributed, and it begins Alphanumerica's own Mozilla story.
A lot has happened since Alphanumerica started their Mozilla development. They have worked on Aphrodite and the Theme Builder, have coordinated the first two Mozilla Developer Meetings, and have been acquired by CollabNet. It all started with Total Recall, though. Total Recall and all of Alphanumerica's other projects, plus the projects of others in the community, can now be found on mozdev.org, a site that offers project hosting for Mozilla applications. |
Chris Blizzard, a key Mozilla member, talks about this in an interview he had with Linuxpower: "...because the Mozilla project was started by Netscape, it came with a lot of procedures and a very large nomenclature that most people were unaware of. Non-Netscape contributors have had to learn the ropes, too." |
I'm too far behind to catch up now.
Unlike a new open source project, Mozilla has evolved out of years of Netscape's internal development efforts and procedures. Developers who are new to this have had to come up to speed with a much longer project history than Mozilla's two years would suggest existed. These misperceptions will be easy enough to dispel by providing clear information about what these pre-existing guidelines and procedures are.
The Mozilla folks don't want me to come in.
Many Mozilla developers assume that everyone in the community has access to and understanding of the same information that they are familiar with. For example, when an outside developer asks a question about protocol, the first response is often "What, you mean you don't have access to the tree?," or something you don't understand like, "Why don't you make a patch of that and attach it to shaver's layout bug?" Don't let these sorts of esoteric responses dissuade you. The Mozilla community is used to working very close to the code and to one another. Once you take the time to learn about your area, about the other people involved there, and about the protocols for communicating and contributing, you'll find the Mozilla community an extremely capable and efficient one.
Mozilla has all the code it needs already.
From the point of view of outside developers, there is a misconception
that the core Mozilla developers aren't interested in new features that
derive from outside. At first, after Alphanumerica posted Total Recall to
the newsgroups and on their web site, they didn't know what else they could do and assumed that if anyone from Mozilla wanted the code, they would come and ask them for it.
The success of the Total Recall project -- the request for a crash recovery feature, the help Alphanumerica got from the Mozilla community, and the enthusiasm with which their work was integrated into the browser -- have proven their initial reservations wrong.
|
The steps you take to get your work contributed to Mozilla will undoubtedly vary according to your project, but most or all of the following categories of involvement are absolutely essential in order to be adequately informed and involved in the Mozilla community:
Newsgroups, IRC, web site, helping out | |
The Bugzilla database is where most of the information specifically about the Mozilla code base and its products is exchanged. Go to bugzilla.mozilla.org and use the Query tool to find the information most relevant to your own project. | |
Licensing, commenting, documentation | |
CVS, Tinderbox, Bonsai, build tools, building | |
The Mozilla community incorporates your work into the nightly builds. |
|
Pete Collins, Alphanumerica engineer: |
"At Alphanumerica we started our Mozilla development work about a year ago. For our first project, we wanted to come up with a way to recover your browsing session after either the operating system or the browser crashed. "This project turned out to be much harder than we had thought, and it took us about seven months to get it working. In that time we had worked on a number of other projects, including the Aphrodite browser and the Sullivan skin. "When Total Recall, the name of our crash recovery project, was finished and ready to go, we had no idea what to do with it. Even though by the time it was finished we had done a number of other Mozilla projects and were very familiar with Mozilla development, we didn't know how to get Total Recall checked into the Mozilla code.
"We put Total Recall on our site and asked a lot of questions and eventually figured it out. Since Mozilla is becoming a project with more and more outside developers, we felt that what we had learned would be good information for other developers who have patches and projects they want to add to the Mozilla code base. "One of the main things we learned was that everyone at Mozilla is very helpful, but they don't know that you need help unless you ask. When we did finally ask about checking Total Recall into the tree, we were told that they just assumed that we knew what to do with the code but that we just didn't want to check it in." |
In general, you begin the process of getting your work included in the Mozilla project by making yourself known as a trustworthy and capable member of the Mozilla community. The process for making yourself a part of the Mozilla community remains an informal one by design, so the contacts you make and the help you give to other members are very important in establishing your position as one of the Mozilla developers. In fact, it's unlikely you'll be initiated into the Mozilla community without having first exhibited your skills by helping others figure things out.
It's easy to feel that when you get your code working, you are nearly done. Perhaps you have already pulled the Mozilla source and gotten your own project integrated locally. But if you want to contribute to the Mozilla code base itself, your work begins when you get your own project settled and begin looking for a home in the Mozilla project.
Mozilla comprises a huge number of projects already. Some of them are separate projects that have little to do with the browser; others, like the project described in this article, are additions to the browser itself, new extensions or components that will add to the already huge value of the Mozilla browser.
The Mozilla web site is the first place you should go to acquaint yourself with the goals and projects in the Mozilla organization. As an open source community, however, mozilla.org is unlikely to welcome you very far in if your familiarity stops with reading and understanding the documents on this web site. Use the links below to start using, building, and learning from Mozilla, and then proceed to the following sections, where your interaction with the Mozilla community begins.
The Projects List is a long and somewhat dated list of the various projects that make up Mozilla. Be aware: Without any better indication of the scope or status of the various projects, this page can quickly lead you down some moribund and ill-conceived byways.
Module Owners offers more specific information about the owners of core modules in Mozilla. You can use the list of module owners to get an idea about how the Mozilla product itself is divided up (and see this division reflected in Bugzilla, where the bugs are assigned to module owners unless someone else is specified), and you can find out who to begin asking questions of in your area.
Build Documentation is a list of current build documentation for different platforms. It's a good idea to set up a build machine, pull the source code using anonymous CVS, and build Mozilla for yourself.
Mozilla Developer Documentation is a long list of documentation available at the mozilla.org web site.
|
Once you've become acquainted with mozilla.org by studying the web site, you can begin to take a more active role in the project.
Newsgroups
If the mozilla.org web site is the front door of the Mozilla project, then the netscape.public.mozilla.* newsgroups are the foyer. Reading and taking part in the discussions going on in such active newsgroups as netscape.public.mozilla.xpfe, netscape.public.mozilla.builds, and netscape.public.mozilla.seamonkey, you can very quickly get acquainted with many of the day-to-day challenges in Mozilla development and in your area of focus. You can also see which contributors are busiest in which areas and begin to take a role yourself as a helpful advocate, tester, teacher, or engineer.
There are dozens of newsgroups available in netscape.public.mozilla.*, and you will find that Mozilla developers are more likely to respond to questions and discussions in newsgroups than by e-mail, since the newsgroups give developers an opportunity to confer, to share, and to verify the information that is being disseminated.
The Mozilla IRC channels
Even more specific and fast-paced than the newsgroups are the two or three IRC channels that Mozilla developers use to communicate with one another about development matters. You'll see the that IRC channels #mozilla, #mozillazine, and #qa are busy with just the vexing and technical issues you'll be faced with when you edit, contribute to, and build the source code.
To access the IRC channels on Mozilla's IRC server, you can use one of the many shareware IRC clients, such as mIRC, or you can use Mozilla's own Chatzilla, which is available on the mozilla.org web site and can be accessed from the Tasks menu of the Mozilla browser once it is installed.
Taking part in Mozilla discussions, you will very often see references to bugs and bug numbers. These bugs are stored in a massive database called Bugzilla, which was a tool developed by Mozilla and which many developers have appropriated for use in their own development and project management environments. Very often in the newsgroups or in IRC, you will see problems identified with or answered simply by numbers, as in the following example:
Moz1: Hey, why doesn't the profile window pop up in today's build?
Moz2: I think that's 52445.
Alphanumerica's foray into the world of bugs began with a bug that someone wrote about needing to have a way to recover data on crashes. This bug, bug number 36810, formalized the need for a feature of the kind that Alphanumerica was already working on. If you haven't already, look at the bug and see what kinds of information are exchanged in the bug database; you will notice that the tone of the bug comments is broad and informal, and that the comments identify all kinds of things happening with that particular feature or bug. The QA contact, the responsible engineer(s), the steps to reproduce a bug, related bugs, status, priority, and many other pieces of information are associated with a bug.
Before bug number 36810 was written, Alphanumerica was having a difficult time finding a way into the code base. In a sense, a bug provides a forum for discussion and development; it can legitimize the wishes of users and the ambitions of developers.
This section describes some of the ways in which your work must be validated and prepared before it can be submitted to Mozilla for inclusion in the source.
Give yourself some credit: licensing your work
Before you are ready to submit anything to Mozilla, you will first need to
give yourself some credit for the work that you have done. You can do
this by prepending the Mozilla Public License to each of the individual files in your code. This basically states that you are granting the Mozilla organization rights to use your code in their project. Without this, it would be illegal for anyone to take your code and reuse it in Mozilla.
The MPL is fairly straightforward to use. On the mozilla.org site, there are copies of the license that have blanks in the areas that you need to fill out. These blanks are mainly for putting your name as the copyright holder of the code and for identifying the contributors who helped with the project.
For Total Recall, the license simply states that Alphanumerica created this function and that Pete Collins, Joshua Lerner and David Boswell worked on it.
Commenting and documenting your work
Good documentation is always important, but in an environment as collaborative and open as Mozilla's, it's essential. Whether it's better for you to comment your code in clear detail or create separate documentation such as "getting started" documents, READMEs, or installation instructions, you must provide documents that explain what your project is about and what your code does.
The Mozilla community uses a couple of different tools for commenting source code. The main tool is LXR, which is described below. You don't need to do anything special to your code so that it generates the HTML pages of the source code that LXR displays, but it always helps if you explain what each element, function, or module in your code does.
Mozilla also encourages developers to use JavaDoc-style comments in their code (see example below), from which other developers can generate reference documentation by using a tool like Doxygen.
JavaDoc style comments: /** * ... text ... */
See the Doxygen site's Documenting the code for more information about commenting code for use with documentation systems such as Doxygen and JavaDoc.
|
The best way to view the source code is to use LXR, which provides a web-based view of the structure of the source tree and of the source code itself. LXR gives you timely and easy-to-read views into the source code, its structure, and all of its files.
The resource that actually contains the source code is a massive CVS repository (actually, a series of repositories) that can be accessed with various tools provided by Mozilla. At some point, you will be using the CVS tool itself to check in your work, which is described on the Mozilla web site. But before that, you'll have to get used to monitoring the source tree so that you'll know what others are checking in, what state the automated builds are in, and what the source tree actually looks like.
Bonsai and Tinderbox: views into the source
Bonsai is a tool that lets you query the CVS repository for information about what's being checked in. You can run queries by date, engineer, file, branch, location, or by combinations of these and other parameters. Bonsai is indispensable for tracking changes to the source tree, and you must be aware of changes to your area in the source if your project is to be integrated smoothly. Using Bonsai and paying attention to the discussions about the source tree and the builds going on in the #mozilla channel on IRC and such newsgroups as netscape.public.mozilla.builds, you can monitor the area of your project to foresee changes that will affect you.
While Bonsai focuses upon the source code, Tinderbox looks at the builds that come from that source code. Tinderbox is a web-based tool that allows you to watch the progress of builds being done constantly from the source tree. Tinderbox broadcasts information about its relative success on different platforms, writes detailed information to log files, and links to Bonsai's check-in information to give you a great starting place for watching the overall progress of the source and the builds.
 |
Web-based Tinderbox Tool |
Checking in
Having said all that we have about getting acquainted with the Mozilla community, helping others, and finding your way around, we have omitted one of the most important requirements for getting your work contributed into the Mozilla code base. You must apply for and receive a CVS account that will allow you to write into the source code repository as well as check out from it.
All of the source code in the Mozilla project is available for download via anonymous ftp. This means that you do not need any special permissions to download the source code to your local machine and build Mozilla. If you have become a good member of the Mozilla community and have exhibited your talents and your willingness to help others, then filling out a CVS contributor form ought to get you the ability to check code in as well as out.
 |
LXR view of extensions area. |
First time contributions to the Mozilla project are always checked into the extensions area of the source base. Using LXR (shown above), you can see the projects already checked into and maintained in this area.
|
Daniel "Leaf" Nunes, Mozilla's build and release guru, describes the process for having your work simply present in this extensions area, and having it turned on in the nightly builds, so that users who grab the compiled versions of the source code can see your work: "The problem is that there isn't a strict, documentable pathway from having CVS access to contributing code that everybody uses. "There are a few common heuristics ("write an extension that everyone will find useful," "write good code," and "don't write something that works only on Windows, with a particular toolset", etc.), but there is no voting process to include something in the nightly builds. "Basically, if you write an extension (chatzilla is a good example) that works cross-platform, doesn't hork the builds when it's enabled, and is of some use to some large set of developers (primarily) and users (secondarily), I'll turn it on in the nightly builds, or someone will turn it on in the default build configuration. Obviously, if it becomes a nuisance, by breaking frequently, or taking too much build time/space, it's going to be removed again." |
Once you have apprised the Mozilla community of your project, prepared it properly, been given a CVS account, and checked your work in under the extensions directory, it will appear here in the Mozilla source code for all to see and compile.
The last and perhaps least scientific stage in getting your work incorporated into the project is to have it made part of the nightly Mozilla builds. There are dozens of projects at Mozilla that are in the source code and accessible by anyone compiling their own builds but are not a part of Mozilla's binaries. If you have proven the worth of your project and been a good member of the Mozilla community, then this last step--which needs to be handled by someone in the mozilla.org community itself -- is the final validation of your efforts.
Ian Oeschger is a Senior Principal Writer at Netscape Communications.
David Boswell has been involved in the Mozilla community for more than six years. He is also a coauthor of Creating Applications with Mozilla and helped launch mozdev.org.
Discuss this article in the O'Reilly Network Browsers Forum.
Return to the Mozilla DevCenter.
Copyright © 2007 O'Reilly Media, Inc.