Geoffrey Huntley proposes closing open source pull requests in favor of Nix-overlay remixes

The proposal

Developer Geoffrey Huntley has published an essay on his site ghuntley.com arguing that open source needs a new operating model: repositories that are closed to pull requests but open to "remix". Under his plan, maintainers would publish their source code and their intent under an as-is license, switch off GitHub's pull request feature, keep discussions open, and document how users can adapt the software themselves. Huntley writes that he will follow this practice for everything he releases on GitHub from now on.

The essay reached the front page of Hacker News on October 14 and has reignited a long-running argument about how open source projects should be governed — this time with AI coding agents as the accelerant.

From bazaar to bottleneck

Huntley frames his argument against Eric Raymond's classic "The Cathedral and the Bazaar". The cathedral, in Raymond's metaphor, is a small private group shipping polished, infrequent releases; the bazaar is decentralized, open development, which GitHub later turned into a workflow anyone could join by filing a pull request. Huntley has no interest in returning to the cathedral, but he argues the bazaar was already straining before AI arrived, because it fostered a consumer mentality in which anyone could expect an unpaid maintainer to review, merge and support their contribution.

AI, in his view, turns that trickle into a flood. If pull requests can be mass-produced by machines, reviewing them becomes busywork; what a maintainer actually wants is the idea behind a change, which they may adopt upstream if it is good — with no obligation to do so.

How the remix model works

Huntley's proposal, which he calls the remix model, has five moving parts:

• Structure: decentralized and compositional. Adaptations spread as independent overlays rather than converging on a single repository and a single maintainer.
• Workflow: a user expresses a desired change once as a small Nix overlay, then reuses that derivation across devenv shells, Docker images, NixOS systems, tests, CI and agent sandboxes — without forking or maintaining a divergent copy.
• Core principle, "ideas over patches": the valuable unit is a change in behavior or architecture. Maintainers may incorporate it, reimplement it or ignore it, and owe the author no review or ongoing maintenance.
• Social contract: the license already permits adaptation without claiming anyone's future time. Credit and visibility can still exist; upstream incorporation is optional and deliberate.
• Discovery: useful adaptations appear as a proliferation of overlays in the wild. Maintainers can sample from that spread, and Huntley suggests agents could analyze GitHub's network graph to summarize remixes and feed promising ideas back upstream.

His worked example: a user who wants Git to refuse force pushes writes an overlay that patches Git once, and that behavior then appears consistently in developer environments, container images and system tests — with no pull request filed against Git itself. He has published a demonstration repository, ghuntley/nix-demo, showing the pattern in action.

The Nix wrinkle

The model's dependence on Nix is notable because Huntley is not a fan of the tool. He says he has considered Nix a terrible programming language for almost 13 years and describes its learning curve as brutal. His bet is that AI agents close that knowledge gap: overlay-based customization was always technically possible, but machines can now write the overlays for users who never learned how.

His stated hope is that removing the cognitive burden of running a project would lead more people to release software, and that the result would be highly customizable code that is still easy to consume.

Why it matters

The pull request is the load-bearing institution of modern open source governance: it defines who reviews, who merges and who gets credit. If machine-generated contributions keep scaling while human review capacity does not, that institution starts to fail. Huntley's essay offers a concrete, testable alternative — one maintainer, one toolchain, one personal commitment — rather than pure commentary. It also raises fair objections: it shifts the cost of customization onto every downstream consumer, depends on an ecosystem whose difficulty its own author concedes, and still requires someone upstream to judge which ideas are worth adopting. Whether or not the remix model spreads, the question it poses is now unavoidable: when patches are nearly free to produce but review is not, what should contribution mean?