David Crawshaw's argument in Devtools must be open source arrives with a prompt attached. Nightly: fetch the upstream project, replay your local changes on top of it, verify the software still works as intended, replace the running version. That is the entire maintenance procedure for a private fork, and it fits in a cron entry. The objection to forking a tool you depend on was always a labor problem: someone had to carry the patches forward at every release, and that someone was expensive and eventually left.
That labor is what kept forking off the menu for most teams. When a vendor's tool almost fit, the real options were living with the gap, filing a feature request and waiting two quarters, or switching to a competitor with a different set of gaps. Forking was available the way writing your own database was available: technically permitted, practically a decision to hire a person.
The line between building and buying has moved every decade I have been working, and it moves because the economics underneath it move. In the mid-1990s, companies built because there was very little to buy, and what existed shipped on a schedule measured in years. Packaged software and then SaaS pushed the line hard toward buy, and the pitch was explicitly about carry cost: somebody else would amortize maintenance across every customer, and you would stop paying a person to babysit a system that gave you no advantage. The frame that survived all of it is plain. Build what differentiates you, buy the undifferentiated heavy lifting, and re-run the calculation whenever the price of either side moves.
What moved this month is the price of carrying a private change against someone else's codebase. Simon Willison, amplifying Crawshaw's post, put the consequence directly: source access stops being an ideological preference and starts being leverage. The diff is now maintained by something that does not get bored, does not get promoted, and does not have a backlog.
The procurement consequence is the interesting part. "Can we see and change the source" has sat on vendor questionnaires for twenty years, and for most buyers it was decoration, because nobody in the building was going to exercise it. It now has a number attached. The value of source access is the cost of the workflow gap it lets a team close, minus a nightly agent run. For a tool that blocks something the team does forty times a week, that number is not small, and it changes which product wins a bake-off between two options that are otherwise even.
The math has a boundary, and the boundary matters more than the enthusiasm does. You cannot fork what you do not operate. Platformer's interview with Granola CEO Chris Pedregal is about a company whose product is a hosted service and whose differentiator is a posture on who gets to see the transcripts. No amount of source access changes that relationship. The leverage there is vendor selection and contract language, and it always was. Fork economics apply to tools running on machines the team already controls.
Open also does not mean cheap. Cloudflare's account of serving Kimi and GLM in production is a useful corrective: public weights are the start of the work rather than the end of it, and the company spent real engineering making those models small enough, fast enough, and safe enough to put in front of customers. Availability of source grants permission to change something. Keeping it running is a separate, ongoing job.
Which brings the cost to the one clause in Crawshaw's prompt that no agent can supply. The rebase, replaying local changes on top of the vendor's newest version, is mechanical, and agents are good at mechanical. "Verify the software still works as intended" asks what the software is supposed to do for this particular team, and that answer does not live in the repository. It lives in somebody's head, or in a test suite, or nowhere.
A fork with a vague verification step is worse than no fork, and it fails in a specific way. The rebase succeeds and the tests pass while the behavior drifts, quietly, toward whatever upstream decided to change, and the team finds out during an incident. That is the same failure that made unmaintained internal forks radioactive in the first place, and the nightly cadence makes it arrive considerably faster than the quarterly one did.
The durable asset is the verification spec: cheap patches, expensive intent. The patch is now cheap enough that its authorship barely matters. A written statement of what "as intended" means for a given workflow is expensive to produce, useful in a dozen other places, and the only thing standing between a self-maintaining fork and a self-corrupting one. It is also, conveniently, the artifact that makes the vendor question answerable in the first place.
Crawshaw published the rebase loop and gave it away, which was the easy half. The clause about intent is the half he cannot write for anyone else, and it does not require an agent, a fork, or a budget line. It requires one person on the team to sit down and write what the tool is supposed to do. Whoever writes that owns a fork. Everyone else owns a cron job that succeeds every night and proves nothing.