Your Next Plugin System Is a Fork

David Crawshaw has earned the right to make big claims about developer infrastructure. He co-founded Tailscale, wrote some of the most-circulated essays on programming with LLMs, and now builds agent infrastructure at exe.dev. His latest post, "Devtools must be open source," hit the Hacker News front page this week with an argument that's sharper than its familiar title: plugin systems and config files are relics of an era when modifying software was expensive. Agents have made modification cheap. So the source code itself becomes the extension API — and closed-source devtools are quietly amputating their most valuable surface.

He's mostly right. But "mostly" is doing real work here, and the parts where he's wrong matter to anyone deciding what to build their workflow on.

The config file was always a workaround

Here's the insight worth keeping: extensibility systems exist because forking used to be ruinously expensive to maintain, not to create. Patching Vim or Postgres for yourself was always a weekend project. Carrying that patch across five years of upstream releases was the tax nobody wanted to pay, so vendors gave us escape valves — plugin APIs, hook systems, YAML sprawl — that let us change the 20% of behavior they'd predicted we'd want to change, and nothing else.

Crawshaw's claim is that agents attack the maintenance cost directly. An agent can apply your personal patch, then re-apply it against every upstream release, forever, while you sleep. His running example: meat.dev, a personal tool that uses LLMs to strip trivial noise out of diffs so reviewers can focus on structure. He integrated it into Shelley, exe.dev's open-source coding agent, with a single prompt — no plugin API involved, because when the agent has the source, everything is a plugin point.

None of this desire is new. It's the original Emacs pitch, the reason dotfiles repos exist, the whole "personalized development environment" subculture that grew up around Neovim. What's new is who pays the carrying cost. Free software advocates spent forty years arguing you should be able to modify your tools; the economics said you couldn't afford to. If agents flip that, source access stops being an ideological preference and becomes a capability gap.

Where the argument holds — and where it snaps

For single-player tools — your editor, your shell, your CLI utilities, your coding agent itself — I think Crawshaw is directionally correct. The blast radius of a broken personal fork is one annoyed developer, and the payoff of a tool shaped exactly to your workflow compounds daily.

The HN thread surfaced the failure modes, though, and they're not nitpicks. An agent-maintained fork is a nondeterministic build step you personally own; as one commenter put it, every nightly rebase carries a chance you "wake up and find your workflow broken." That's a flaky CI pipeline for your own brain, and unlike a plugin API, nobody upstream is contractually keeping your integration point stable. The economics also still ride on token prices — "just have the agent rebase it" is a sentence with a monthly invoice attached.

The bigger snap point is collaboration. Team tools derive much of their value from uniformity: shared CI, shared formatters, shared review tooling. Onboarding, support, and security audits all assume everyone runs roughly the same thing. A team where every engineer maintains a divergent agent-managed fork of the build system isn't personalization, it's entropy. Crawshaw extends the argument to CRMs and CMSs; I'd stop well short of that. The inner loop is ready for this. The shared layer isn't.

One more quibble that's actually a concession in Crawshaw's favor: the argument doesn't require open source in the OSI sense. It requires source access plus the right to modify for your own use — which source-available licenses like BSL and FSL generally permit. The tools genuinely locked out of this future aren't the fair-source crowd. They're the binary blobs.

The industry is walking the other way

Here's the collision that makes this more than a think piece. Just as agents make source access more valuable than it's ever been, the devtools industry spent 2023–2025 retreating from it: HashiCorp's BSL move begat the OpenTofu fork, Redis's relicensing begat Valkey (before Redis partially reversed course with AGPL). Those fights were framed as cloud-vendor economics. Crawshaw's argument adds a new cost column: every restriction on modification now forfeits agent-era personalization value too.

The agent vendors themselves split cleanly on this. OpenAI's Codex CLI and Google's Gemini CLI ship under Apache 2.0. Claude Code — the market leader, and Crawshaw's named example of the limitation — ships as minified JavaScript on npm. Then in late March 2026, multiple outlets reported that Anthropic accidentally published a release with its sourcemap intact, exposing the full TypeScript source, which was mirrored across GitHub within hours before Anthropic called it a packaging error. Whatever you make of the incident, it demonstrated both halves of Crawshaw's thesis at once: keeping devtool source closed is operationally fragile, and developer demand for that source is enormous.

Fair disclosure of the obvious: Crawshaw sells VMs for agents, and Shelley's open license is his differentiator against Claude Code. The post is an argument and an ad. That doesn't make it wrong — but it explains the "must."

What to do with this on Monday

The actionable version isn't "fork everything." It's a filter for the next tool decision you make: when two options are comparable, weight forkability heavily, because the gap between "configurable" and "modifiable" is about to widen. For coding agents specifically, the open field — Codex CLI, Gemini CLI, OpenCode, Aider — can be reshaped by the very tool you're evaluating; a closed one caps you at whatever hooks the vendor predicted.

If you try the personal-fork workflow, treat it like an engineering system, not magic. Keep patches small and few. Maintain them as an explicit queue on top of pinned upstream releases — not nightly HEAD. Make the agent write a test asserting each patch's behavior, so a botched rebase fails loudly instead of silently reverting your workflow. And review every post-sync diff like a PR from a fast, overconfident intern, because that's what it is. Where a five-line config change does the job, use the config — it's still cheaper than a fork when it exists.

"Must" overclaims, as manifestos do. But the durable insight survives the caveats: for the tools you run alone, source access is becoming the real extension API. Extension marketplaces will matter less. License checkboxes will matter more. And the devtools that ship as sealed binaries will be the first to learn what it costs when your most engaged users can no longer engage.