开源的新模式:不接受拉取请求,开放二次创作
A new model for open source: closed to pull requests, open to remix

原始链接: https://ghuntley.com/remix/

作者认为,AI 已经破坏了 GitHub 的集市模式:拉取请求和消费者期望给维护者带来了负担。与其回到大教堂式开发,他们提出一种建立在 Nix overlays 之上的新开源模式。代码以“现状”许可发布并表明意图,但没有审查、合并或维护贡献的义务。核心单元是想法而非补丁:如果一项变更有用,其他人可以在一个小型 overlay 中将其表达一次,并跨开发环境、容器、NixOS 测试、CI 和智能体沙箱复用,而无需分叉。是否并入上游仍然可选。发现通过 overlay 的增殖与组合发生,智能体可以帮助探索和总结。在实践中,作者将禁用拉取请求,保持讨论开放,并发布混搭指南。他们希望这能降低发布软件的负担,从而带来更多开源项目和可无限定制的软件。

Hacker News 帖子“开源的新模式:不接受拉取请求,对重混开放”提出了拒绝 PR 但允许重混的项目。在四条评论中,用户们就这一想法展开辩论。一人说,分叉一直就是这样运作的。另一位维护着许多叠加其上的补丁。
相关文章

原文

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

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

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.

  • 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.

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

a demo of this idea in action

ps. socials

联系我们 contact @ memedata.com