Carmack: the engine licensing trap that gutted id after Quake

5 min read 1 source clear_take
├── "Engine licensing as a primary business line was id's original strategic mistake"
│  ├── John Carmack (X (@ID_AA_Carmack)) → read

Carmack identifies the decision to monetize the engine as middleware as the pivot that turned id from a game studio into a vendor, distorting the roadmap and inviting Epic's Unreal to eat the licensing market id had defined. He argues this is what capped id's trajectory precisely when it should have been pulling away from competitors.

│  └── @shadowtree (Hacker News, 528 pts) → view

By surfacing Carmack's thread to the front page with the framing 'mistakes around Quake that ruined id software,' shadowtree endorses the read that the post-Quake strategic choices — chiefly the licensing pivot — are what hollowed out the studio rather than any single personnel or culture issue.

├── "id's collapse was a compounding of locally rational decisions, not a single villain or toxic culture"
│  └── John Carmack (X (@ID_AA_Carmack)) → read

Carmack explicitly declines to blame Romero's departure, American McGee, Sandy Petersen, or the post-Romero culture. He frames each rewrite, licensing deal, and delay as individually defensible engineering and business decisions whose aggregate effect was a decade of lost ground — a systems-level failure rather than a people-level one.

└── "The 'moat-monetization trap' is a generalizable failure mode for technical companies"
  └── top10.dev editorial (top10.dev) → read below

The editorial generalizes Carmack's account into a recurring pattern: small teams with a defensible technical moat begin monetizing the moat itself (licensing, middleware, platform sales) and lose the ability to ship the product the moat was built to enable. It argues this isn't gaming nostalgia but one of the most reliable failure modes in modern technical companies.

What happened

John Carmack, in a long reply thread on X (@ID_AA_Carmack), revisited the decisions around and after Quake (1996) that, in his telling, capped id Software's trajectory at exactly the moment the company should have run away from the field. The post — currently sitting at 528 on Hacker News — is the most candid public accounting Carmack has offered of the period between Quake and Doom 3, and it largely confirms what ex-id engineers and Masters of Doom readers have inferred for two decades: the company's problems were strategic, not technical.

The specifics he names are familiar but rarely stated this plainly. Carmack identifies the decision to make engine licensing a primary business line as the original sin — it converted id from a studio that shipped games into a vendor that shipped middleware, with all the roadmap distortion that implies. The Quake III engine (id Tech 3) shipped late, the Trinity rewrite that became Doom 3 took roughly four years longer than planned, and during that window Epic's Unreal engine ate the licensing market id had defined. The team also fragmented — American McGee, Sandy Petersen, John Romero already gone, and Carmack himself increasingly siloed on the renderer while gameplay decisions drifted.

What's new in the thread is the framing: Carmack doesn't blame any one person or even the famously toxic post-Romero culture. He frames it as a series of locally rational engineering decisions that compounded into a strategic disaster. Each rewrite was technically justified. Each licensing deal paid the bills. Each delay was defensible. The aggregate was a decade of lost ground.

Why it matters

This isn't gaming history nostalgia. The pattern Carmack is describing — a small team with a defensible technical moat that monetizes the moat itself and then loses the ability to ship the thing the moat was built for — is one of the most reliable failure modes in technical companies, and it has only gotten more common since 1998.

The AI-tooling space is currently running the exact same play. Companies that built differentiated inference stacks, retrieval pipelines, or agent frameworks are now selling those as platforms to other companies, which means their roadmap is driven by enterprise integration requests rather than by the application they originally set out to build. The moment your customers are other engineering teams instead of end users, your product velocity is governed by their procurement cycles, not your ship cadence. id learned this with Raven, Ritual, and Activision's licensees demanding stability over innovation. Modern infra startups learn it when Fortune 500 design partners ask for SOC 2 instead of new features.

Carmack's specific technical regret — the Trinity rewrite — also lands harder in 2026 than it did in 2004. The instinct to throw out a working codebase and rebuild from first principles is what killed Netscape, what nearly killed Basecamp, what cost Digg its audience, and what is right now consuming a generation of engineering teams who are rewriting working systems in Rust or rebuilding their backends around LLM-native architectures because the old code "isn't AI-ready." Carmack's verdict on Trinity is worth quoting in spirit: the rewrite was technically beautiful and strategically catastrophic, because the four years it consumed were four years Valve spent shipping Half-Life, Counter-Strike, and Steam.

There's also a quieter point in the thread about founder bandwidth. Carmack acknowledges that he was the rendering engineer and the de facto CTO and a significant chunk of the public face of the company, and that this was unsustainable but went unaddressed because the company kept being profitable enough to mask the structural problem. Profitability is the most effective camouflage for organizational dysfunction ever invented. Anyone who has watched a 30-person startup with a single irreplaceable founder will recognize the shape of this.

The community response on HN is unusually substantive — the top comments are from people who were either at id, at competitors like Raven and 3D Realms, or who licensed id Tech 3 and lived through the support experience. The consensus isn't that Carmack is being too hard on himself; it's that he's being characteristically precise about a period most participants prefer to mythologize.

What this means for your stack

Three concrete takeaways for anyone running a technical organization right now.

First, audit what your roadmap is actually optimizing for. If your last three sprints have been driven by enterprise customer asks, integration partners, or platform stability work, you are no longer building the product — you are maintaining the platform underneath someone else's product. That's a legitimate business, but it's a different business than the one you probably pitched investors, and it has a different growth ceiling. id was a hit-driven studio that accidentally became a B2B middleware vendor and never reconciled the two.

Second, be ruthless about rewrites. The Trinity-class rewrite — "we'll throw out the engine and rebuild with everything we've learned" — is almost always wrong, and it is wrong in a specific way: it assumes your competitors will stand still during the rewrite window. They will not. If a rewrite cannot ship a shippable increment within one quarter, it is not a rewrite, it is a sabbatical for your senior engineers. The correct move is almost always incremental replacement behind feature flags, with the old system continuing to ship revenue-generating features the entire time.

Third, price founder dependency explicitly. If your company has a Carmack — one person who is the renderer, the architect, the recruiter, and the brand — that person is a single point of failure even when they are present, because their attention is the bottleneck. The fix is not to clone them; the fix is to formally cap the percentage of decisions that route through them and treat exceeding that cap as a P1 incident.

Looking ahead

The useful thing about Carmack publishing this in 2026 rather than 2006 is that the lessons now apply to a generation of companies that mostly weren't alive when Quake shipped. The AI platform wars, the dev-tools consolidation, and the infrastructure-startup graveyard of the last 18 months are all running variations of the id playbook. Read Carmack's thread as a postmortem from the future of any company currently considering whether to become a platform. The technical decisions are easy to defend in isolation. The aggregate is what kills you.

Hacker News 546 pts 268 comments

John Carmack on the mistakes around Quake that ruined id software

→ read on Hacker News
starkparker · Hacker News

"Sorry, Sandy"Sandy Petersen's side of it comes out in a few interviews, like https://medium.com/@unkndoomer/back-to-the-past-e3c421fb2e70 and https://www.youtube.com/watch?v=MUeu96TKQwU (especially 14:17 onward)

Waterluvian · Hacker News

I don’t believe the ends justify the means and I respect his perspective on these regrets. I wonder if he’s kind of looking back from a position of assumed success. Would Quake have succeeded on a Doom++ engine?I remember feeling that Quake was something remarkably different from Doom, mainly becaus

tejohnso · Hacker News

Quake III Arena was pretty entertaining. Doesn't seem like it came from a company that had been ruined for years.I definitely noticed something around the Doom 3 release many years after Quake III Arena. The new game just didn't seem to have the same industry pushing, genre changing energy

ChrisMarshallNY · Hacker News

> I pushed everyone too hard. I didn’t appreciate how maturing companies need more slack, and that running people at startup intensity constantly will wear them out.Sounds like wisdom many companies might consider...

rustyhancock · Hacker News

> So if my theorem is correct, and Quake gutted id Software, was it worth it? Well I'd say yes absolutely. Games are more important than game companies, and Quake is an iconic titan of the gaming world.Sandy's quote here buried unfortunately by X.

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.