好的，我要开一个历史课，因为自从这篇论文以来已经有几代软件工程师，我得假设并不是每个人都知道什么是大教堂。每个人都知道什么是集市，因为他们在日常中使用它，像是 GitHub。《大教堂与集市》 - 维基百科 维基媒体基金会，Inc. 维基媒体项目的贡献者 GitHub 采用了集市的理念——一个去中心化的、开放的、自组织的开源项目，并提供了一种工作流程，让任何人都可以通过拉取请求来检查或贡献源代码。我一直在思考，软件开发模型需要变革。我们不会回到那个小型、私密、排他性的小组构建源代码的教堂，发布的版本重度计划、频率低且经过精心打磨。但显然，现在 AI 到来了，我们需要一些新的东西。即使在 AI 之前，GitHub 的集市模型也已经显示出它的裂缝，因为它创造了基于消费者的权利，导致每个人都在催促维护者合并某些东西。它创造了非常奇怪的社会结构预期：发布代码的人有责任维护它，而这项工作却得不到任何报酬。但现在 AI 已到来，水坝真的已经决堤。因为阅读一份由代码生成的拉取请求有什么意义？我想要的只是阅读并理解核心理念。如果这是一个好主意，我可能会将其重新整合回去，但不应该有任何期望我会这样做。你看，开源软件按照定义就是开源，因为许可证规定它是现成的，而这种现成允许你对软件进行混合。但是问题是，人们一直认为混合软件太困难，但其实并没有。这只是一个知识差距的问题，而这个问题在 AI 到来后已不再存在。Nix 存在了很长时间。如果你还没有看到我几天前发布的关于 Nix 覆盖的文章，你应该去读一读。这个世界尚未明白你可以通过 Nix 覆盖字面修复一切。我们的行业目前有很多不确定的东西，但我可以肯定的一件事是，Nix 是一种糟糕的编程语言。记得我第一次学习它时，感觉就像是在推一堆屎上坡。学习的悬崖 Geoffrey Huntley Geoffrey Huntley 所以，我要提出一些建议，希望能帮助其他开源维护者。这是我现在在发布开放源代码许可证软件时时间的思考方式。混合模型结构：去中心化和组合化。思想通过独立的覆盖进行传播，而不是集中在单一的代码库和维护者上。工作流程：在现成许可证下发布源代码和意图。其他人通过编写一个小的 Nix 覆盖，表达所需的更改一次，然后在开发环境、Docker 镜像、NixOS 系统、测试、CI 和代理沙箱中重用该衍生物——无须分叉或维护不同的工件。核心原则：理念重于补丁。有价值的单位是行为或架构的变化。维护者决定是否整合、重新实现或忽略它。原作者没有评审、整合或维护更改的义务。社会契约：许可证已经允许混合，而不对任何人的未来时间提出要求。信用和可见性仍然存在；没有持续的维护责任。上游整合仍然是可选和故意的。发现：有用的适配在野外的覆盖中出现。维护者可以选择从这个传播中采样；其他人只需通过更新自己的覆盖文件即可轻松抓取和组合理念。示例：一个项目的使用者希望禁用 Git 在该项目中强制推送的能力。使用者不是向上游项目提出拉取请求，而是制作一个覆盖，修复 Git 拒绝强制推送；这一次性定义，然后在开发者环境、容器镜像和系统测试中一致出现——而无需向上游项目发起拉取请求。在实践中，从此以后，我将在 GitHub 上发布的所有代码将禁用拉取请求，保持讨论开放，并发布 + 维护指导，告诉你如何混合我的软件。0:00 / 0:59 无限可定制且易于使用的软件。这就是我希望成为标准实践的东西。如果你消除了发布开源和运行大项目的认知负担，我们将看到更多人发布软件。如果他们以正确的方式这样做，我们将看到世界上有更多软件。GitHub 网络图提供了一个探索生态系统中混合的绝佳方式。嘿，你甚至可以在其上运行代理，总结人们正在做的事情。你也可以在代理循环中使用它来探索混合思想，并将其反馈给上游的主要项目。GitHub - ghuntley/nix