The Netscape Rewrite
Netscape is the case everyone reaches for when they argue against a rewrite. The story is real. It also gets cited with far more confidence than the evidence supports.
What happened
Netscape Communicator 4 shipped in 1997 with a rendering engine that was hard to work in and increasingly out of step with emerging web standards. Netscape open-sourced the code as Mozilla in early 1998, and later that year the project decided against evolving the existing layout engine and started a new one, which became Gecko.
The gap that followed is the part everyone remembers. Netscape 4.x aged in the market with no competitive successor while the new engine was built. Netscape 6 arrived in November 2000 and was widely judged to have shipped before it was ready. Gecko did eventually become very good, shipping as Firefox in 2004, but by then Internet Explorer had taken the overwhelming majority of the market.
The rewrite was the most-cited factor in that outcome from the moment Joel Spolsky used it as the central example of his April 2000 essay, published while the outcome was still unfolding.
What the case demonstrates
Run the case through the framework in The Rewrite Trap and Netscape hits several failure modes at once:
- The Never-Ending Rewrite. A multi-year gap in which the organization could not ship a competitive product, while the old system aged in production. Every month the target moved.
- The Business-Alienated Rewrite. The market Netscape 6 entered in late 2000 was not the market the project was scoped for in 1998. Bundling and distribution had reshaped browser competition in the meantime.
- The rewrite blocked feature delivery. This is the cost that compounds fastest, and it has nothing to do with the quality of the new engine. Gecko was a serious piece of engineering that outlived the company. Nothing shipped while it was being built, in a market that was being decided during exactly that window.
The last point is the transferable lesson, and it is not really about browsers. The opportunity cost of a rewrite is measured in the value you do not deliver while it runs. Netscape's window happened to be the one in which the browser war was settled.
What it does not prove
Netscape is a single case, it is twenty-five years old, and it is overdetermined. Microsoft was bundling Internet Explorer with Windows and giving it away, the conduct at the center of United States v. Microsoft. AOL acquired Netscape in 1999, with the strategic disruption that implies. Reasonable people disagree about how much of the outcome the rewrite caused and how much it merely coincided with.
So treating it as proof that rewrites always fail is weak reasoning, and we would rather not lean on it even though the conclusion suits us. The argument against big-bang rewrites does not need Netscape. It rests on the structure of the bet: all delivery deferred to one irreversible cutover, with the business and its competitors moving throughout. That structure shows up just as clearly in cases where no antitrust suit or acquisition muddies the picture. Sonos in 2024 is the cleaner example, with roughly $100 million of revenue impact and a CEO gone within eight months, and no confounding market shock.
What Netscape could have done instead
Nobody sensible argues Netscape should have kept the 1997 engine forever. It plainly needed replacing, and standards support was a real forcing function, the kind that earns large work.
The question is whether it needed replacing all at once, with nothing shipping in the interim. The techniques that make incremental engine replacement tractable (routing a subset of traffic or content through a new implementation, running old and new in parallel and comparing output, shipping behind flags) were much less established in 1998, which is a fair defense of the decision at the time. They are established now, which removes that defense for anyone making the same call today.
So the Netscape story is not proof that rewrites fail. It is the clearest illustration of what it costs when the only path to a better system runs through a period where you cannot ship. If you are considering a replacement large enough to create that period, the period itself is the thing to design away.
