Working at Mozilla has been a very educational experience over the past eight years. I have had the chance to work side-by-side with many engineers at a large non-profit whose business and ethics are guided by a broad vision to protect the health of the web ecosystem. How did I go from being on the front of a computer screen in 1995 to being behind the workings of the web now? Below is my story of how my path wended from being a Netscape user to working at Mozilla, the heir to the Netscape legacy. It's amazing to think that a product I used 25 years ago ended up altering the course of my life so dramatically thereafter. But the world and the web was much different back then. And it was the course of thousands of people with similar stories, coming together for a cause they believed in.

The Winding Way West

Like many people my age, I followed the emergence of the World Wide Web in the 1990’s with great fascination. My father was an engineer at International Business Machines when the Personal Computer movement was just getting started. His advice to me during college was to focus on the things you don't know or understand rather than the wagon-wheel ruts of the well trodden path. He suggested I study many things, not just the things I felt most comfortable pursuing. He said, "You go to college so that you have interesting things to think about when you're waiting at the bus stop." He never made an effort to steer me in the direction of engineering. In 1989 he bought me a Macintosh personal computer and said, "Pay attention to this hypertext trend. Networked documents is becoming an important new innovation." This was long before the World Wide Web became popular in the societal zeitgeist. His advice was prophetic for me.

[...]

The Mozilla Project grew inside AOL for a long while beside the AOL browser and Netscape browsers. But at some point the executive team believed that this needed to be streamlined. Mitchell Baker, an AOL attorney, Brendan Eich, the inventor of JavaScript, and an influential venture capitalist named Mitch Kapoor came up with a suggestion that the Mozilla Project should be spun out of AOL. Doing this would allow all of the enterprises who had interest in working in open source versions of the project to foster the effort while Netscape/AOL product team could continue to rely on any code innovations for their own software within the corporation.

A Mozilla in the wild would need resources if it were to survive. First, it would need to have all the patents that were in the Netscape portfolio to avoid hostile legal challenges from outside. Second, there would need to be a cash injection to keep the lights on as Mozilla tried to come up with the basis for its business operations. Third, it would need protection from take-over bids that might come from AOL competitors. To achieve this, they decided Mozilla should be a non-profit foundation with the patent grants and trademark grants from AOL. Engineers who wanted to continue to foster AOL/Netscape vision of an open web browser specifically for the developer ecosystem could transfer to working for Mozilla.

Mozilla left Netscape's crowdsourced web index (called DMOZ or open directory) with AOL. DMOZ went on to be the seed for the PageRank index of Google when Google decided to split out from powering the Yahoo search engine and seek its own independent course. It's interesting to note that AOL played a major role in helping Google become an independent success as well, which is well documented in the book The Search by John Battelle.

Once the Mozilla Foundation was established (along with a $2 Million grant from AOL) they sought donations from other corporations who were to become dependent on the project. The team split out Netscape Communicator's email component as the Thunderbird email application as a stand-alone open source product and the Phoenix browser was released to the public as "Firefox" because of a trademark issue with another US company on usage of the term "Phoenix" in association with software.

Google had by this time broken off from its dependence on Yahoo as a source of web traffic for its nascent advertising business. They offered to pay Mozilla Foundation for search traffic that they could route to their search engine traffic to Google preferentially over Yahoo or the other search engines of the day. Taking "revenue share" from advertising was not something that the non-profit Mozilla Foundation was particularly well set up to do. So they needed to structure a corporation that could ingest these revenues and re-invest them into a conventional software business that could operate under the contractual structures of partnerships with other public companies. The Mozilla Corporation could function much like any typical California company with business partnerships without requiring its partners to structure their payments as grants to a non-profit.

[...]

Working in the open was part of the original strategy AOL had when they open sourced Netscape. If they could get other companies to build together with them, the collaborative work of contributors outside the AOL payroll could contribute to the direct benefit of the browser team inside AOL. Bugzilla was structured as a hierarchy of nodes, where a node owner could prioritize external contributions to the code base and commit them to be included in the derivative build which would be scheduled to be released as a new update package ever few months.

Module Owners, as they were called, would evaluate candidate fixes or new features against their own list of items to triage in terms of product feature requests or complaints from their own team. The main team that shipped each version was called Release Engineering. They cared less about the individual features being worked on than the overall function of the broader software package. So they would bundle up a version of the then-current software that they would call a Nightly build, as there were builds being assembled each day as new bugs were upleveled and committed to the software tree. Release engineering would watch for conflicts between software patches and annotate them in Bugzilla so that the various module owners could look for conflicts that their code commits were causing in other portions of the code base.