Essay: Why I Quit Mozilla

Overview
Jamie Zawinski’s 1999 essay “Why I Quit Mozilla” is a candid postmortem of his departure from Netscape and the mozilla.org project he helped found. He recounts how the open-sourcing of Netscape’s browser, announced with fanfare in 1998, devolved into a prolonged rewrite that failed to ship a usable product, drained morale, and squandered the project’s early momentum. The piece mixes first-hand chronology with a sharp critique of management, development strategy, and overblown expectations about open source, all framed by one principle: shipping is a feature.

From open source promise to endless rewrite
After releasing the massive Communicator 4 codebase under the Mozilla tree, the team discovered it was too tangled to evolve quickly. Management and senior engineers opted to throw it away and start over around a new rendering engine (NGLayout/Gecko) and a cross-platform UI toolkit (XPFE/XUL). Zawinski argues this decision doomed the schedule. Rather than iterating and shipping incremental improvements, Mozilla embarked on building a “platform” first and an application later. Months went by with infrastructure work, component systems, resource models, toolkit abstractions, while no browser appeared that ordinary users could run.

Why the bazaar needs a cathedral
Zawinski pushes back on contemporary “bazaar” hype. Open source thrives when there is a running program that people use and can patch; volunteers coalesce around working code and their own immediate needs. Starting from scratch gave contributors nothing to touch, test, or depend on, so the community never gelled. He says consumer desktop software is rarely “itch-scratching” for volunteers; it needs product direction, deadlines, and ruthless triage. Without users and releases, bug reports and patches dry up, and the virtuous cycle never begins. Open source, he insists, is not a magic schedule accelerator and cannot substitute for product management.

Leadership vacuum and platformitis
He describes mozilla.org as chronically underpowered: responsible for coordination but lacking authority to make hard cuts. The project tried to be everything to everyone, cross-platform, standards-complete, endlessly extensible, rather than a focused, shippable browser. Decisions were deferred or revisited; arguments over toolkits, component models, and licenses soaked up energy; nobody owned the product. Meanwhile, Microsoft’s Internet Explorer shipped relentlessly, widening the gap.

Netscape’s business drift
Inside Netscape, the revenue model had shifted from selling software to chasing “portal” page views on Netcenter, and later to surviving an AOL merger. Zawinski depicts a culture where the browser became a delivery vehicle for corporate deals and branding rather than a product to delight users. Engineers were pulled toward integrating services and ads while the core act of browsing, speed, stability, compatibility, was starved of attention. He saw the AOL acquisition as a final sign that Netscape’s priorities would never realign with shipping a great browser.

Principles and parting
Zawinski’s core tenets are stark. Shipping sooner with fewer features beats grand rewrites that never land. If you must rewrite, you must also simplify and deliver a minimal, usable product quickly. Community grows around releases, not promises. Governance must be empowered to say no, to kill distractions, and to protect schedules. He did not doubt his colleagues’ talent; he doubted the plan. Watching months of work produce frameworks rather than software people could run, he chose to leave rather than continue a death march.

Aftermath and resonance
He closes with guarded hope that Gecko might one day enable a good browser, but not under the prevailing approach or timeline. History eventually delivered Mozilla 1.0 and Firefox, but only after years that validated his fear about the rewrite’s cost. The essay endures because it articulates a product truth that transcends its era: users cannot run your intentions, only your releases.