A new model for open source: closed to pull requests, open to remix

# a new model for open source: closed to pull requests, open to remix. Source: [https://ghuntley.com/remix/](https://ghuntley.com/remix/) All right, I'm going to open up a history lesson because it's been a couple of generations of software engineers since this essay, and I have to assume not everyone knows what a cathedral is\. Everyone knows what a bazaar is because they're using it day to day with GitHub\. [The Cathedral and the Bazaar \- Wikipedia Contributors to Wikimedia projects ](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar?ref=ghuntley.com)GitHub took the bazaar's ideas—a decentralized, open, self\-organizing open\-source project—and provided a workflow that lets anyone inspect or contribute source code via a pull request\. I've been thinking that there needs to be a new software development model\. We're not going back to the cathedral, where a small, private, exclusive group builds the source code, with releases that are heavily planned, infrequent, and polished\. But it's clear we need something else now that AI is here\. The GitHub bazaar model, even before AI, was already showing its cracks because it created consumer\-based entitlements where everyone was nagging maintainers to merge something\. It created really weird social\-structure expectations: that someone who releases code has an obligation to maintain it and get paid nothing for the work\. But now that AI is here, the dams have well and truly burst\. For what's the point of reading a pull request that's been generated by code? All I want is to read and understand the core idea\. If it's a good idea, I might incorporate it back upstream, but there should be no expectation that I will\. You see, open source software is open source by definition because the license says that it's as is, and that as is permits you to remix software\. But the problem has been that it's been perceived as too hard to remix software, but it hasn't been\. It's just a knowledge gap issue that no longer exists now that agents are here\. Nix has existed for a long time\. If you haven't seen the article that I posted a couple of days ago about Nix overlays, you should read it\. [the world hasn’t figured out yet that you can literally just fix everything with a Nix overlay There are many things that are uncertain in our industry right now, but one thing I am certain about, and have been for almost 13 years, is that Nix is a terrible programming language\. I remember when I first learned it, it felt like pushing shit uphill\. The learning cliff Geoffrey HuntleyGeoffrey Huntley ](https://ghuntley.com/nix/)So, I'm going to propose something that I hope helps other open source maintainers\. This is how I'm thinking about my software now that I release it under open\-source licenses\. ## The Remix Model - **Structure**: Decentralized and compositional\. Ideas spread through independent overlays rather than converging on a single repository and a single maintainer\. - **Workflow**: Publish source and intent under an as\-is license\. Others remix by writing a small Nix overlay that expresses the desired change once, then reuses that derivation across devenv shells, Docker images, NixOS systems and tests, CI, and agent sandboxes—without forking or maintaining a divergent artifact\. - **Core Principle**: Ideas over patches\. The valuable unit is a change in behavior or architecture\. Maintainers decide whether to incorporate it, reimplement it, or ignore it\. The original author has no standing obligation to review, integrate, or maintain the change\. - **Social Contract**: The license already permits remixing without creating a claim on anyone’s future time\. Credit and visibility can still exist; there is no ongoing maintenance duty\. Upstream incorporation remains optional and deliberate\. - **Discovery**: Useful adaptations appear as a proliferation of overlays in the wild\. Maintainers can sample from that spread if they choose; everyone else can grab and compose ideas simply by updating their own overlays via an agent\. > **Example**: A consumer of a project wants to disable Git's ability to force push in that project\. Instead of raising a pull request to the upstream project, the consumer makes an overlay that patches Git to refuse force pushes; this is defined once and then appears consistently in developer environments, container images, and system tests—without a pull request against the upstream project\. In practice, from this point forward, for any code I release on GitHub, I will disable pull requests, keep discussions open, and publish \+ maintain guidance on how you can remix my software\. 0:00 /0:59 Infinitely customizable software that's easy to consume\. That's what I hope becomes a standard practice\. If you remove the cognitive burden for releasing open source and running a big project, then we're going to see more people releasing software\. And if they do it in the right way, then we're going to see so much more software in the world\. The GitHub network graph provides a fantastic way to explore the remixes in the ecosystem\. Heck, you can even run agents over it to summarize what people are doing\. You can also use it in an agent loop to explore remix ideas and feed them back upstream into the main project\. [GitHub \- ghuntley/nix\-demo at ghuntley\.com Patch git once with a Nix overlay; use it in devenv, a NixOS VM test and a Docker image \- ghuntley/nix\-demo GitHub ](https://github.com/ghuntley/nix-demo?ref=ghuntley.com)a demo of this idea in action ps\. socials > 🗞️ a new model for open source: closed to pull requests, open to remix\.[https://t\.co/kJAllc39mc](https://t.co/kJAllc39mc?ref=ghuntley.com)[pic\.twitter\.com/DILnyNns42](https://t.co/DILnyNns42?ref=ghuntley.com) — geoff \(@GeoffreyHuntley\)[October 14, 2026](https://x.com/GeoffreyHuntley/status/2110515103778881661?ref_src=twsrc%5Etfw&ref=ghuntley.com)