Nixpkgs 核心团队已解散
NixOS 社区正在应对 Nixpkgs 核心团队这一相对较新的团队突然解散，这反映出的更多是长期存在的治理问题和贡献者倦怠，而不是软件本身的技术失败。评论者描述了围绕审核、赞助和决策结构的多年政治与社会冲突升级，有人因此质疑项目的长期稳定性，也有人强调 nixpkgs 和 NixOS 仍在运行并持续更新。与此同时，用户分享了对 Nix 强大能力与复杂性的复杂体验，讨论其在可复现系统和大规模部署中的优势，是否足以抵消学习曲线和生态摩擦，尤其是在小团队或个人场景中。
nixpkgs 核心团队解散的影响
- 核心团队规模很小（最初约 4 人，最近为 2 人）且相对较新（大约成立一年），并不是 nixpkgs 的基础。
- 贡献者表示 nixpkgs 和 NixOS 会继续；这些人本人也并未停止他们自己的贡献。
- 有人将这视为回到核心团队成立前的既有状态；也有人认为这是治理压力和贡献者倦怠的又一迹象。
- 少数评论者声称“ NixOS 正在死去”；另一些人则强烈反驳这一点，指出包和操作系统更新仍在持续。
治理、审核与社区冲突
- 许多人认为根本问题在于治理：职责委派不清、指导委员会的“干预”或微观管理，以及对一个志愿者项目来说过于沉重的流程。
- 文章提到了多次此前危机：审核团队集体辞职、与指导委员会的争执，以及其他高调辞职事件。
- 有人将审核描绘为过度热心、政治化，并聚焦于意识形态斗争（例如围绕赞助商、“安全”、“法西斯”）；也有人把责任归咎于指导委员会，或归咎于赋予坏人作恶空间的“系统性”问题。
- 几篇帖子把动荡归因于更广泛的文化战争动态和“觉醒”政治；另一些人则批评这种框架过于简化且具有分裂性。
- 尽管原因存在争议，但人们普遍认为关键贡献者的倦怠是真实存在的。
对生态系统的信任
- 一些用户表示他们已经停止使用 NixOS，因为反复的风波让这个生态系统在关键工作负载上显得不稳定、缺乏可信度。
- 另一些人认为，开源中的治理风波很常见，而技术生态本身仍然“久经考验”，并被广泛使用。
技术与用户体验主题
- 正面体验：
- Nix/NixOS 因可复现配置、机队管理、机器人部署、快速且低成本的构建，以及按项目隔离的环境（通常通过 flakes + direnv）而受到称赞。
- 家庭实验室和公司部署报告称，原子化升级可靠，回滚也很容易。
- 负面体验：
- 学习曲线陡峭；nix 语言和 nixpkgs 被描述为晦涩难懂。
- 文档碎片化且不一致（flakes 与非 flakes、NixOS 与 macOS），还有许多失效链接；用户很依赖聊天工具或 LLM。
- 软件包维护质量参差不齐；有些包缺失、过时，或功能被削减，尤其是在 macOS 上。
- 一些人觉得 Nix 过于复杂，抽象层级不对，并没有完全解决跨平台构建的痛点。
Flakes 与“实验性”状态
- Flakes 在实践中被广泛采用；不少人认为它们必须被正式宣布为受支持，而不是“实验性”。
- 其他人指出了真实缺点（例如在
nix run .#...时会把大型本地数据复制到存储中）。
生态、资金与替代方案
- 有人提出：严重依赖 Nix 的公司是否应该为其开发提供资金；回应从“他们应该”——以减少倦怠——到“开源规范下这并非理所当然”不等。
- 一些用户转向或推荐替代方案：Guix、基于 Kubernetes 的方案、不可变 Fedora 变体（如 Bazzite/Silverblue），或 StageX 之类的新系统；也有人使用 NixOS 来承载 Kubernetes。
- 少数人认为 Nix 的模型非常有吸引力，以至于即使当前社区崩溃，别人也会接手这些想法。
元话题：社区文化与讨论质量
- 几位评论者指出，反复出现的 Nix 讨论经常演变成同样的模式：“我试过 Nix 然后放弃了”、文化战争争吵，以及对治理的抱怨，而不管原始话题是什么。
- 对社区文化的观察（动漫头像、兽迷、酷儿身份、军工行业用户）被随口提起，有时是调侃，有时是贬低。
- 一些贡献者明确表示会避开 Discourse/“社区”空间，因为那里戏很多，但仍会直接向 nixpkgs 提交 PR。