Setting the record straight


Index


Aren’t the “Browser Wars” over? Will Mozilla affect the Internet?

The Internet, the earth’s digital commons, is of increasing importance in our lives. The key to its vitality is interoperabilityopen development, open standards and open source software are what led to the birth of the Internet in the first place, as well as to other important universal systems such as global e-mail addressing and delivery.

Continuing in this spirit of openness, the Mozilla 1.0 code and development tools provide developers with the resources they need freely to create and view the presentation of the their content and data on the web.

The goal of the Mozilla project is to innovate and enable the creation of standards-compliant client technology to keep content on the web open. As more and more programmers and companies embrace Mozilla as a strategic technology, Mozilla 1.0 will assist further dissemination and adoption of open-source, standards-based software across the Internet, in turn contributing to its vitality.

Why did Mozilla 1.0 take so long to complete?

First, the scope of the project changed dramatically. The initial project was an incremental upgrade from the Netscape Communicator 4.x product line to a proposed 5.x product line. After the project was launched, however, it became clear that many of its goals could not be met using the existing codebase.

So a decision was made to reset the Mozilla project and to create a new generation of code. This decision expanded the scope of the project dramatically.

Secondly, not all the design changes for the new codebase were made at once. The development process turned out to be a lot like remodeling a house: Ideally, one plans in absolute, precise detail before beginning . . . in reality, however, this is seldom possible.

Finally, while this is our 1.0 release, it won’t be judged by the standards generally applied to the first release of products. Instead, Mozilla 1.0 will be compared against the latest generations of commercial browsers. So we spent the time necessary to make sure this release would indeed be “ready for prime time.”

When is the user experience going to get really innovative?

The emphasis for Mozilla 1.0, both in terms of functionality and of user interface, was to allow Netscape to create a reliable replacement for the Netscape Communicator 4.x series. However, there were profound changes under the hood that specifically relate to the future evolution of the user experience and that set Mozilla up for an exciting and rapidly evolving future:

Consider, for example, the tabbed browsing feature. H. J. van Rantwijk used this feature in another browser. Last year, he and some friends used XUL to create Multizilla. David Hyatt saw that work and quickly created a new XUL widget that natively implemented the basic features. Basic tabbed browsing features are now a standard part of Mozilla’s feature set, and work on the more sophisticated Multizilla project continues.

The Mozilla project and the development community around it work in tandem to create an ever-improving product, and we anticipate that user-interface experimentation and production implementation will accelerate once we ship Mozilla 1.0.

I’ve heard that the ”bug count” keeps climbing. Is that true?

A “bug report” can be made in Bugzilla for any issue relating to the Mozilla project that is important enough to involve multiple people and to track publicly. Our bug reporting and tracking system includes all reports made since the inception of the Mozilla project, so the number inevitably increases, since resolved bugs remain in the database.

There is no accurate way to relate the number of bug reports to the overall quality of the product:

  1. Some reports relate to project operations, not code.
  2. A significant number of bugs related to code are either duplicates of other bugs or bad bug reports; some are expressions of opinion or requests for particular enhancements.
  3. Requests for new features (RFEs or “requests for enhancements”) are tracked as bug reports.
  4. We have a series of “meta-bugs,” which are used for project management. For example, there is a meta-bug for each milestone release in which we track issues important to that release.
  5. The number of bug reports being filed is affected by the number of participants in the project: the more participants there are, the more bug reports that will find their way into Bugzilla.
  6. The existence of a bug report says little if anything about that bug’s effect on users. A single bug report may cover an enormous problem that affects all users consistently, or it may cover a highly specific issue that most users will rarely if ever encounter. As bug reports deal with ever more unusual issues, it is quite possible for the number of reports to go up simultaneously with an overall increase in quality.

While bug report counts do not help track “bugginess,” we do track other measures of bugginess, in particular Mean Time Between Failures (MTBF), a standard manufacturing concept (see, for example, this analysis of a recent build).

What is the relationship between mozilla.org and sponsoring corporations such as Netscape and AOL?

Mozilla.org exists to make Mozilla a successful open source project. It supports the entire Mozilla community and provides a central point of contact and community for those interested in using or improving the Mozilla codebase.

Mozilla.org maintains absolute independence in decison making. Decisions are made for the long-term health of the codebase and the entire Mozilla community. Mozilla.org receives corporate sponsorship of staff positions and resources (servers, etc.), accepts the best contributions available from the community, and communicates closely with distributors.

Some members of mozilla.org staff are volunteers, including its Chief Lizard Wrangler. Other staff members are sponsored by employers. In all cases a dedication to the project itself, rather than any particular product resulting from the project, is required. Mozilla.org has a longstanding commitment to full transparency.

Doesn’t Netscape do most of the work (writing code and documentation, testing, etc.)?

Netscape is the largest single contributor to the Mozilla project and has strengthened the community by employing a number of former volunteers, thereby allowing many of them to work full time on the project.

Netscape employees have been intimately involved in most aspects of the codebase, usually in tandem with a few key volunteers and an increasing number of employees of other companies who are using Mozilla code. To date, approximately 300 people unrelated to Netscape have made code contributions to the project.

The number of people participating in other aspects of the project is even larger. In particular, the number of those involved in product testing and bug reporting is enormous. Recent mozilla.org releases have been downloaded by between 300,000 and 400,000 people each, giving the project an excellent and timely set of testing data.

There are also hundreds of people participating in testing activites that assist those developers who are writing code. This allows the developers to be more efficient and effective.

Similarly, much of the documentation being generated, including various tutorials, come from the volunteer community.

Will AOL use Mozilla?

Mozilla.org can’t speak for future AOL actions; only AOL can. CompuServe, a 100%-owned subsidiary of AOL, is currently shipping the Mozilla technology known as “Gecko” as part of the CompuServe 7.0 client. AOL is currently testing a beta version of the AOL 7.0 client that also uses Gecko, but it’s premature to comment on any future plans.

What licensing terms govern the Mozilla codebase?

The Mozilla codebase is developed and licensed as open source/free software. This means that the recipient of the source code is guaranteed basic rights.

The bulk of the Mozilla codebase is governed by the Mozilla Public License and the Netscape Public License. Files with compatible open source/free software licenses (such as the BSD and MIT licenses) may also be included.

This means the Mozilla codebase can be the codebase can be legally:

by any person or corporation for any purpose.

More information on open source and free software can be found at http://opensource.org and http://www.fsf.org respectively.

The codebase is currently being relicensed to make it easier to combine Mozilla code legally with code from other projects that are also free but have incompatible licenses (the GNU GPL and LGPL). The holdup is a handful of “missing” contributors

What other technology is there? Who might find it useful?

The Mozilla codebase includes a wide variety of relatively modular, standards-based functionality. Developers, especially OEMs, will find that the codebase is an attractive free “plug and play-ground” source of high-quality software for creating or extending portable, standards-compliant, web- and ’Net-related software.

While much of the functionality is used in Mozilla 1.0, some is not.

There are, for instance, developer tools such as Bugzilla, which is an example of Mozilla technology that has been successful far outside the purview of the Mozilla project. There are now thousands of Bugzilla installations used world-wide to track information for other open and proprietary projects that have nothing to do with Mozilla.

In addition, there are miscellaneous other projects such as Rhino, an implementation of Javascript in Java (which enables those deploying Java solutions to provide scripting capabilities to their end users).

What goes on at mozilla.org?

Whatever it is, it is notably open. It is notable that the first design principle in the first “roadmap” document (October 1998) touched on this very issue (the other principles were about technical issues).

The web site itself is generally written by and for developers. It generally ignores, and is ignored by, other audiences such as the press and end users. If you have sufficient technical savvy, you get impressive tools such as web-site editing and archival features and a deceptively simple-looking graphical display of the real-time status of builds of various products on various platforms (e.g., this display of the latest status for one of the Mozilla product branches).

Mozilla development follows paths defined in a periodically updated “roadmap” document. Priorities and goals are defined in “manifesto” documents such as the mozilla 1.0 manifesto.