开源新范式：拒绝Pull Request，拥抱Remix
A new model for open source: closed to pull requests, open to remix
作为开源维护者，我决定关闭Pull Request，转而推行“Remix”模式。在AI时代，传统的GitHub集市模型已显疲态，维护者被无数琐碎的合并请求淹没。新的模式主张：发布源码和意图，由社区通过Nix overlay进行自由重组和定制，而非强制上游合并。这并非回归封闭，而是将“补丁”思维转变为“理念”思维。维护者只需关注核心架构，社区则利用AI代理轻松生成定制化环境。这种去中心化、可组合的协作方式，将大幅降低开源发布的认知负担，让软件生态更加繁荣。
开源软件之所以称为开源，是因为许可证明确声明其现状许可，并允许你自由地对其进行Remix。
HN 评论区
12- kvemkon
> 开源的新模式：拒绝 Pull Request
这就是 SQLite 几十年来一直采用的运作方式。这对他们来说或许很合适。这是一个非常特殊的项目，拥有数十亿个运行实例（与 curl 不同，它处理的是需要长期保存和修改的数据），但这并不适用于所有情况。
允许提交 Pull Request 并不等同于必须审查或接受它们。对于潜在贡献者来说，提前了解维护者在这项工作上能投入多少时间，通过免责声明说明这一点是非常有用的。
- wink
从大规模应用的角度来看，这听起来简直是一场噩梦。
一直以来，将修复补丁合并回上游（Upstreaming）都是一件很棒的事，这样你就不用再操心自己那个独一无二的“雪flake”分支了，尽管这需要时间、精力等等。
当然，那些完全押注 AI 的人会声称“别担心，我们只需让 AI 代理去 cherry-pick 上游的所有安全修复”，对此我只能祝他们好运。
至于我？每当我能 sunset 自己的个人项目，转而使用一个拥有（哪怕只是小小）社区的工具，并尝试去改进它，而不是从头开始一切时，我都会感到非常开心。（当然，相反的情况也发生过，只是比较少见）。也许对于那些喜欢创造新事物、建立社区、积累名声的人来说情况不同。我只是一个随机出现的家伙，和你合作几天、几周或几年，然后再次消失。
- soundworlds
这就是我目前做开源的方式。我喜欢将其视为一种强有力的间接协作形式 - https://johnoestmannmusic.com/indirect-collaboration/