Mozilla at One: A Look Back and Ahead

Now that mozilla.org and the open-source Mozilla project are a year old, it's an appropriate time to look back at the experience thus far: what has been accomplished, what has not yet been done, what might have been done differently, what lessons have been learned, and what issues lie ahead. Below you'll find my personal opinions concerning these topics.

Highlights

• Netscape and mozilla.org released a large body of code into the open-source "pool," including
  • source code for Mozilla itself, consisting of most of the code-in-progress for Netscape Communicator 5.0
  • source code for related software, including the Directory SDKs for C and Java, PerLDAP, the Communicator Client Customization Kit, and a JavaScript reference implementation
  • several development tools useful for open-source projects, including the Bugzilla bug tracking system (now also used by Red Hat Software, among others), the Bonsai system for monitoring CVS trees, and the Tinderbox build system
  • source code for "orphaned" technology no longer under active development by Netscape, including the Electrical Fire Java Virtual Machine (JVM) implementation and the Java-based Grendel mail/news client (thus ensuring that others might benefit from the code already created)
• Netscape and mozilla.org created the Netscape Public License (NPL) and the Mozilla Public License (MPL) for licensing the Mozilla source release and other code released by Netscape. The licenses were created through a relatively public process in which draft licenses were published and comments solicited; partly as a result, the final NPL and MPL 1.0 were accepted by the bulk of open-source developers as reasonable licenses balancing the interests of Netscape and the larger community of developers and users. The NPL and MPL have also influenced new licenses created for other open-source projects. Note also that the NPL and MPL have recently been revised to address concerns about their patent clauses; see the revised licenses for more information. (The revised licenses also allow for the possibility of licensing code under both the NPL/MPL and an alternate license such as the GPL; mozilla.org will use this to release the JavaScript reference implementation under dual licenses so it can be used by more projects. There are no plans to release Mozilla code this way.)
• Early "developer preview" releases of Mozilla binaries (including the recently-released "M3 version") have provided a "plausible promise" of a fast, cross-platform, standards-compliant web browser (as well as a mail/news client and HTML editor) with relatively small memory and disk footprints, that can be embedded in other applications and cleanly extended to incorporate new modules, modified user interfaces, third-party Java implementations, and new local and network data sources.
• The project has begun to attract major pieces of useful functionality developed by outside contributors, such as the expat XML parser (from James Clark) and the Mozilla ActiveX control (from Adam Lock).
• The first non-Netscape commercial product built on the Mozilla code base has been announced: DocZilla, a tool for accessing SGML documents (and XML and HTML documents as well).
• Netscape and mozilla.org have to a large degree opened up not just the Mozilla code itself but also previously internal-only design discussions about how to move it forward -- an important achievement in terms of proving the workability of the open-source development model at commercial software companies that have previously developed only proprietary software. Those who don't have time to read all the newsgroup discussions can also keep track of happenings in the Mozilla project by reading mozillaZine, an independent news site created by Chris Nelson to provide information on all things Mozilla-related, as well as the Mozilla newsbot, which highlights significant threads in the Mozilla newsgroups; there are also many third-party web sites that have sprung up around the Mozilla project.
• mozilla.org has been able to move Mozilla to being based more on other open-source code, as opposed to depending on proprietary technology for key functions. In particular the Mozilla project was able to leverage the work of the GTK+ project to provide underlying technology for the new Mozilla cross-platform front-end interface.
• Several independent efforts have started to port Mozilla to other platforms, with some of them now well along (for example, the OS/2 port created by John Fairhurst, Henry Sobotka, and others).

Lowlights and Debatable Decisions

• Netscape and mozilla.org could have proceeded on the original plan to release "Mozilla Classic," i.e., a version of Mozilla using the original Communicator 5.0 source code, instead of rewriting Mozilla using the new NGLayout HTML layout engine (a major component of the new Gecko technology). This might have produced an official 5.0 release sooner and (as a side effect) resulted in having much earlier a relatively stable code base buildable by more developers; however this would have been at the cost of having a level of standards compliance not much above that of the Communicator 4.x releases. Many web developers, including those associated with the Web Standards Project, expressed the strong opinion that Netscape should not release a 5.0 product without complete compliance with as many web standards as possible, including at a minimum HTML 4.0 and CSS1. Netscape and mozilla.org therefore decided to drop the existing layout code and instead use NGLayout, even though at the time NGLayout was quite a ways from final release, and thus the overall Communicator 5.0 schedule would slip at least a few months (especially given that many other parts of Mozilla would have to be rewritten to use the new NGLayout APIs).

  Would it have been possible to first do a Mozilla Classic-based Communicator 5.0 release and then develop a Gecko-based follow-on release (5.x or 6.0) in the same overall time it will end up taking to do a Gecko-based Communicator 5.0? It's impossible to know for sure; however such a plan would have arguably created real and significant risks in terms of the length of the development schedule and the complexity of the development process, especially if the two releases were developed in parallel or nearly so.

• Netscape could have skipped development work on the Communicator 4.5 release (created using the traditional internal-only development process, with proprietary source code) and gone straight for 5.0; this would have freed up many of the developers (especially mail/news developers) who were working on 4.5 and allowed them to contribute much earlier to the Mozilla/5.0 effort. This problem was an unfortunate consequence of the fact that the 5.0 release was not complete and working at the time it was originally made available through mozilla.org, so that the Mozilla project was initially dependent on the activities of Netscape developers to produce a complete release. This led to a situation where there was a possible conflict between Netscape's business priorities as a commercial software company and mozilla.org's priorities as coordinator of an open-source project. However, putting aside for a moment Netscape's market needs for a 4.5 release, would it have helped the Mozilla schedule that much to have the 4.5 developers working on Mozilla and 5.0 instead? Or were there other items (like NGLayout) gating the Mozilla/5.0 schedule? Space and time don't permit discussing here all of the complexities of this issue.

• There was, at least initially, a very steep learning curve for developers wishing to do serious Mozilla hacking. There is a lot of code in terms of number of lines and number of source files, the code is very complex, being a mix of C and C++ with additional things like JavaScript thrown in for good measure, and there was not very much introductory documentation to orient new developers, at least at the start. The situation with regards to introductory documentation is somewhat better now; in particular the tutorial on extending Mozilla by Johnny Stenbäck and Heikki Toivonen provides a good introduction to the complete novice.
• For much of the project's life Mozilla has been very hard to build from scratch, especially for new developers with no previous build experience at Netscape. The build system has often been in flux, was not well-documented, and is pretty complex. On the plus side, the new autoconf-based build system (contributed by Christopher Seawood) brings the Mozilla project much more in line with current practice for open-source projects developing on Linux, and it is now significantly easier for new developers to get working builds on the Linux/Unix, Microsoft Windows, and Apple Macintosh PowerPC platforms.
• The Mozilla code base has been in continual flux and as a result builds on any given day have had wildly varying levels of stability. Because many of the technologies used in the current Mozilla architecture (for example, XPCOM and XPToolkit) are still in active development and because of the difficulty of doing truly portable cross-platform code, there have been relatively few stable points thus far at which Mozilla both builds and runs on all the major platforms of interest (Win32, Linux, and Mac). Like ease of building, stability is also improving slowly but surely as newer "milestone" releases appear, like the most recent "M3" release.
• For a while there was little (and in some cases no) documentation for the underlying Mozilla architecture and implementation details, and much of the documentation that did exist was either obsolete or badly out of date. This situation is improving, as most if not all of the major Mozilla areas now have at least some internal documentation; however the documentation will not be able to stabilize until the underlying implementations stabilize.
• Netscape did not make the Mozilla code available under the GNU General Public License, and based on the terms of the GPL code licensed under the NPL or MPL could not be incorporated into a GPLed program. (The reverse was and is true as well: GPLed code cannot be incorporated into Mozilla.) As a result Mozilla code could not be used in free software projects like GNOME that were incorporating browser functionality but were using the GPL for all their code. These inconsistencies between the NPL/MPL and the GPL have yet to be fully resolved.
• Many people have the perception that Mozilla is still a "Netscape project" and that therefore "outside" support is not needed nor even wanted. This is an incorrect perception, but it's understandable why people might have become confused about this: First, Netscape and now AOL do have a significant business interest in having the Mozilla project be successful, in order to provide a sound technology base from which to develop the branded Netscape Communicator product as well as to leverage for other possible AOL software and services; thus Netscape has funded and AOL will continue to fund a large number of Mozilla developers by providing them full-time employment. Mozilla developers outside Netscape who are volunteers do not have the luxury of being able to work on Mozilla full-time, and therefore until more companies are funding Mozilla development it's possible that significant Mozilla development will continue to be done mostly by Netscape developers. Unfortunately the issue of Netscape "dominating" Mozilla will likely remain to some extent a "no-win" situation as far as AOL and Netscape are concerned. If AOL puts even more funding and people into Mozilla development then it is open to the charge that it is trying to dominate the project and direct it solely to commercial ends; on the other hand if it were to back away from direct support of Mozilla and rely much more on outside developers then people would think that AOL had abandoned Mozilla or was guilty of exploiting the work of volunteers for its own purposes without giving anything back to the project. This problem is not unique to AOL and Netscape, of course; similar tensions will be present as other commercial companies move more into support, development, and use of open-source software.

  Also, there has been a learning curve for Netscape developers themselves, in terms of becoming comfortable and then competent at the task of doing development "in the fishbowl," i.e., with all design discussions, code checkins, and debugging conducted in the open; some of their actions during this learning period (for example, not posting design proposals for comment, or conducting discussions on Netscape-internal forums as opposed to using public newsgroups and mailing lists) have contributed to the perception that Mozilla is still a Netscape-only project. Fortunately Netscape developers have for the most part learned their open-source lessons and are now doing a better job of working within a public project.

Lessons Learned

• There's a lot more to a project than writing code. People tend to focus on the number of people contributing code to Mozilla or having access to the CVS tree; however the complete list of people helping mozilla.org includes not just module owners and other contributors of code but also people testing early builds and submitting bug reports, as well as people critiquing design decisions relating to proposed feature sets, user interfaces, internal implementations, and public APIs. Not all of those people are necessarily going to be programmers, and of those who are programmers not all are going to be contributing code. For example, several developers have been testing the Mozilla code for use as an HTML layout engine embedded in their application. They are not changing or contributing to that code, but their advice and bug reports help improve the code.
• Quality is better than quantity. Rather than having a mass of relatively unskilled volunteers, it is better to have the help of a few people who really know what they're doing in a particular area. Judged against this criterion, the mozilla.org effort has been very successful in attracting the support of several very talented non-Netscape people, both as programmers and as informal consultants. To take one major example, many of the world's leading experts on Web standards (HTML 4.0, CSS, XML, etc.) have contributed valuable advice and feedback on the implementation of those standards in Mozilla; their help is a key reason why even in its current immature state the Mozilla code is more standards-compliant than any other browser available today.
• To quote a hoary proverb, "An ounce of prevention is worth a pound of cure." Traditionally Netscape did design internally, produced internal alpha builds, and then released a public beta, at which point the public was finally able to critique the product and suggest improvements. Unfortunately, in many cases it was too late at that point to make widely requested improvements, because the developers had already committed to a particular implementation design and the product marketing folks were bound and determined to prevent them from going back and starting over; otherwise the product would have never shipped anywhere close to its projected release dates. Working in an open-source mode has allowed Netscape to get useful feedback right up front, in many cases before any code has been written, and change plans according; such feedback has not only helped Netscape make smarter decisions, it also (and even more important) has kept us from making dumb ones. (A good example here was the decision to rearchitect the product rather then try to struggle on using the old code base.)
• There is no "royal road" to open source for commercial software companies. To quote Jamie Zawinski, you can't "sprinkle [a project] with the magic pixie dust of 'open source,' and have everything magically work." To elaborate, a company cannot simply release source code, put a few newsgroups up, and expect distributed development to magically self-organize; it will need to make a sustained effort requiring various people's time and attention in order to get a distributed open-source development effort to the point where it can produce results. In Netscape's case this effort did not end with the release of the source code on 31 March 1998; on the contrary, it has been a continuing project to get people used to "working in the fishbowl:" reading and participating in the Mozilla newsgroups, not using Netscape-internal lists for discussions that aren't in fact confidential, writing and publishing documentation and proposals for the benefit of those not in their immediate groups, and so on. I'm not talking just about developers either; the effects of open-source development are spreading (or will spread) outward in the corporation to also include quality assurance, technical support, product marketing, and related functions.
• In relation to the previous point, it takes time to get a project ramped up to full activity, especially with regard to attracting large numbers of participants outside the original group. For much of the past year the Mozilla developers and mozilla.org have been working to address the core design and implementation issues around the Mozilla code itself, as well as the mechanics of converting an internal proprietary development project into a public open-source project. Now that that groundwork has been laid more attention can be paid to other areas where work is needed, like Mozilla testing by end users, more polished releases in terms of installation and initial configuration, and so on.

Issues Going Forward

• Mozilla on small devices. There is much excitement in the press and elsewhere over the prospects for non-PC devices. Is the Mozilla architecture as currently implemented capable of being scaled down for truly small devices (e.g., PDAs, settop devices, cell phones, and similar "information appliances")? Are there possible design changes we should be looking at now in order to help make this easier? Or are outside developers going to be okay if they simply proceed using the current code base? (There's a new Mozilla newsgroup netscape.public.mozilla.small-devices for discussing these issues.)
• Recruiting more developers. What further steps need to be taken to make it as pain-free as possible for developers to hack Mozilla? The existing build instructions, project documentation, and Mozilla tutorial are good steps in this direction; do they need further supplementing? If so, what are the most important documents to create or improve? (A suggested forum is netscape.public.mozilla.documentation.) What about providing more stable releases and buildable versions: will the current milestone plan address this problem? (A suggested forum is netscape.public.mozilla.general.)
• Security and cryptographic code. As is well-known, the Mozilla security and crypto code was removed prior to release because of U.S. export control regulations. Unfortunately both U.S. export control regulations and the presence of third-party technology continue to prevent AOL/Netscape from releasing a complete SSL and S/MIME implementation for Mozilla. It would in theory be possible for AOL to release a limited set of security source code, but this code could only be used by developers in the U.S. and Canada, and would also require additional work and time to add implementations of all the cryptographic algorithms required, some of which are still subject to U.S. patents. Given these limitations, it's unclear that doing such a limited security source release would serve any useful purpose with regard to either AOL or the broader Mozilla project; however as time goes on this may change. (A suggested forum is netscape.public.mozilla.crypto.)
• Increasing corporate involvement in Mozilla development. Usually people think of Mozilla developers as being either Netscape employees or volunteers on the net. However as noted previously one commercial company has already announced a product based on Mozilla code, and several others are now involved in Mozilla development to one degree or another. The core mission of mozilla.org will continue to be to coordinate public Mozilla development and be the steward of the public source tree; however that mission will include not just working with net developers but also working with commercial companies that wish to contribute code to the project and use Mozilla technologies in their own products and services. Are there any things that mozilla.org could do to work better with commercial companies while pursuing the core goals of the Mozilla project? Are there things that mozilla.org could do to help net developers who want to do paid Mozilla development work (e.g., as independent consultants or as employees of other companies)? (A suggested forum is netscape.public.mozilla.general.)

The Mozilla project goes beyond just AOL and Netscape though; as many people have commented, "the code is out there" now and in a sense belongs to everyone. As such its prospects can be improved not just by the work of AOL and Netscape, but by the help of anyone who sees its value and wants to get involved. We look forward to working with all of you.