O'Reilly logo

Open Sources by Chris DiBona, Sam Ockman

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 14. Freeing the Source: The Story of Mozilla

Jim Hamerly and Tom Paquin with Susan Walton

On January 23, 1998, Netscape made two announcements. The first, as reported by C|Net: "In an unprecedented move, Netscape Communications will give away its Navigator browser, confirming rumors over the last several weeks."

The second: "It also will give away the source code for the next generation of its Communicator suite."

The decision to give away the browser came as no surprise, but the release of the source code stunned the industry. It hit the pages of newspapers around the world, and even the Open Source community was surprised at the move. Never before had a major software company opened up its proprietary code. What was Netscape up to now?

We had decided to change the playing field, and not for the first time. Always known for thinking outside the box, this time Netscape was taking the commitment to building a better Internet to a new level. When Netscape initiated unrestricted distribution of early versions of its browser over the Internet in 1994, people said "That's crazy!" When Netscape said "Free Source Code" they said the same thing.

The discussion period leading up to the Open Source announcement moved like a runaway train. After months of deliberation about whether or not to release the binary for free, critical mass was reached in the decision to free the source in an unbelievable twenty-four hours.

As fast and surprising as the announcement seemed to both insiders and outsiders, it reflected several converging tracks of thought. Netscape executives were discussing a whitepaper by Frank Hecker that expressed a view coming to the forefront. In it he advocated that Netscape free its source. Frank had done his homework, citing Eric Raymond's paper, "The Cathedral and the Bazaar," and talking to people in departments throughout the organization—from engineering to marketing to management. In a twenty-page opus that was widely circulated, he pled the case that was gaining momentum:

When Netscape first made Navigator available for unrestricted download over the Internet, many saw this as flying in the face of conventional wisdom for the commercial software business, and questioned how we could possibly make money "giving our software away". Now of course this strategy is seen in retrospect as a successful innovation that was a key factor in Netscape's rapid growth, and rare is the software company today that does not emulate our strategy in one way or another. Among other things, this provokes the following question: What if we were to repeat this scenario, only this time with source code?

In the engineering pit there was a similar view. Many Netscape employees had experience working with Open Source. And since Communicator's code was so tightly integrated with Java and HTML, most recognized an emerging truth: It wasn't such a huge jump to make. The nature of Java invites a more open view of source distribution. Because it is cross-platform and can be compiled down to class files that are machine-independent executables, each binary is like a virtual machine. One effect of this is that programmers can decompile the executable and turn it back into source code. And the browser "view source" command made HTML a common vernacular. Rather than trying to block this, many believed Netscape should facilitate it, encourage it, and if possible, benefit from it.

The various grassroots schools of thoughts merged with unexpected suddenness. In meetings, reaction to the suggestion went from stunned shock to nods in minutes. Most of the discussions passed quickly from "should we?" to "when?" Most of the key people believed that we had to move fast, set a firm date, and make it happen. In January, Netscape made a promise to the Net: Communicator source will be released in the first calendar quarter of 1998. Netscape took this promise with deadly seriousness, and Project Source 331 came into being. This was the name for Netscape's all-out effort to have the source code out by March 31, 1998.

Then the reality set in.

Making It Happen

The body of Communicator source code at Netscape was called "Mozilla." Mozilla was a term initially created by Jamie Zawinsky and company during the development of Navigator. The team was working at a similarly frantic pace to create a beast vastly more powerful than Mosaic, and the word became the official code name for Navigator. Later the big green dinosaur became an inside joke, then a company mascot, and finally a public symbol. Now the name came into use as the generic term referring to the open-source web browsers derived from the source code of Netscape Navigator. The move was on to "Free the Lizard."

There was an amazing amount to be done to make the code ready for prime time. As issues surfaced, they separated themselves into categories and were claimed. The next three months were devoted to resolving issues at the fanatical pace that Netscapers knew well.

One of the largest issues was the disposition of the third-party modules included in the browser. Communicator contained over seventy-five third-party modules in its source, and all of the code owners needed to be approached. Teams of engineers and evangelists were organized to visit and sell each company on the concept of joining Netscape on the road to Open Source. All of them had heard Netscape's Open Source announcement, and now each company had a choice to make: their code could be removed or replaced, shipped as binary (kept in its compiled state), or shipped as source code along with Communicator. To complicate matters, many of the third-party contracts were unique and ran for different lengths of time. No one scenario would be appropriate as a solution for all situations.

Making the deadline for Project Source 331 was considered essential. And that required tough choices. This was surely the case when it came to the participation of the third-party developers. The rule was either you're in by February 24th, or your element will have to be scrubbed from the source. Those kinds of deadlines are not hard to set early on, but they became brutal when we hit the wall. When the time came, some code had to be removed.

Java was a proprietary language, so it had to be removed. Three engineers were assigned to perform a "Java-ectomy." The browser had to build, compile, and run—without Java. Since the overall code was so tightly integrated with Java, this was no small feat. The goal was to have the source code ready by March 15th so that the final two weeks could be devoted to testing. Engineers had to disentangle all Java code from the browser in an inconceivably short time.

Cleansing the code was a huge project. Early on, many felt it just couldn't be done in time for the deadline. But as steam gathered at meetings, strategies formed. The wheels began to turn. The Product Team dropped their entire workload (most were developing the next generation of the browser) and everyone got down to the business of surgery. Not only did the inclusion (or excision) of each third-party participant have to be resolved, all comments had to be edited from the code. Responsibility for each module was assigned to a team and they went in to scrub.

One of the great innovations that happened early on was the decision to use the Intranet bug-reporting system as a task manager. "Bugsplat" was the name for Scopus, a bug-reporting program fronted with an HTML interface. It was ideal as a workflow management system. New jobs were reported to the system as they came up, input in a simple HTML form. Just as with a bug that has been reported to the system, priorities were set, relevant participants were determined, and mailing lists grew up around each task. When the task (or bug) was resolved, all of the mailing lists and prioritization collapsed and disappeared from view. Engineers were able to track the progress of their modules and watch the project unfold by logging on to the Intranet.

The removal of the cryptographic modules was another tremendous task for the engineering team. Not only did the government insist that all cryptographic support had to be removed, but every hook that called it had to be redacted. One team's sole job was to keep in constant contact with the NSA and manage compliance issues.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required