2026 年 6 月 22 日，Guix 项目维护者 Ludovic Courtès 发了一篇博客，标题平淡无奇：「One year with Codeberg」。但内容的分量，远超标题的克制——这是目前自由软件社区规模最大、过程最透明的一次「逃离 GitHub」实验的完整复盘。
一年前，Guix 把全部代码仓库、Issue 跟踪和 Pull Request 流程从 GNU Savannah 和基于邮件的 Debbugs 系统搬到了 Codeberg——一个运行 Forgejo 的德国非营利托管平台。一个每年有 400 多人提交代码的项目，在经历了十多年的邮件补丁工作流之后，做了一个被很多人认为「激进」的选择。现在，数据来了。
邮件 vs 网页：一场不为外人道的分裂
Guix 的旧工作流放在今天看简直像考古现场：Bug 报告和补丁通过邮件发送，由 Perl 写的 Debbugs 系统跟踪。核心贡献者用 Emacs 和顶级邮件客户端在这个体系里如鱼得水——对他们来说，Debbugs 几百行 Perl 代码建立在邮件这个久经考验的联邦标准之上，而 Forgejo 这种 Web 锻造厂动辄成百上千个 Go 依赖，臃肿得不像话。
社区甚至围绕邮件工作流搭建了一套精密的辅助设施：mumi 给 Debbugs 套了一个漂亮的 Web 界面，QA 服务会自动把补丁系列打到 Git 分支里编译测试。迁移意味着这些工具全部作废。
但另一面的声音同样真实。2025 年 1 月，Steve George（Futurile）发布了 Guix 首次用户与贡献者调查结果，900 人参与。结论很直接：对于大量潜在贡献者来说，邮件工作流是「一个阻碍」。说白了，年轻一代的 hacker 可能根本没在邮件里提交过补丁——他们熟悉的是 GitHub 式的 PR 按钮。
这种分裂是自由软件运动的经典困局：老将们珍视的「极简、联邦化、标准合规」，在新人眼里就是「门槛高、响应慢、不知道我的补丁到底有没有人看」。
GCD 共识：没有独裁者的项目怎么做决定
Guix 面对两个层面的问题：工具选择，以及决策机制——项目没有「仁慈的独裁者」（BDFL）。2024 年 12 月，社区通过了 Guix 共识文档（GCD）流程：提案者必须与所有人协作达成共识，参与者不能简单「反对」，必须提出具体的需求和建议修改。最终可以表达「支持」「接受」或「不赞成」。
GCD 002 号提案就是迁移到 Codeberg。2025 年 2 月提交，讨论了整整两个月——这是流程允许的最长时限。三分之二的 Guix 团队成员参与了审议：72% 表示「支持」，28%「接受」，零人「不赞成」。2025 年 5 月初，提案正式生效。
这个结果很有意思。28% 的人只是「接受」而非「支持」，说明有相当比例的老贡献者并不喜欢这个方向，但没有强烈到要否决。Courtès 的博客透露：「讨论显示，许多长期贡献者对转向一个主要被感知为『Web 优先』、相比邮件工作流效率较低的方向感到不安。放弃多年来围绕邮件工作流精心构建的基础设施也让人不舍。」
但天平最终倾斜的原因也写得很清楚：「接触更广泛社区、改善多数人的开发体验的预期，可能是推动这一积极结果的关键动力。」
还有一个几乎没引起争议的因素：选择 Codeberg 不仅因为它是自由软件（Forgejo），还因为它由非营利组织 Codeberg e.V. 运营。这和 Guix 的价值观天然一致——没有商业公司的利益纠葛，不用担心某天醒来发现服务条款被修改。
切换现场：CI 断档是最大的坑
按照共识文档的规划，迁移是渐进式的。主仓库 2025 年 5 月 25 日迁移完成，原来的 Savannah 仓库保留为镜像。旧 Issue 和补丁追踪器一直运行到 2026 年 1 月 1 日才正式关闭。
切换过程本身没出大乱子。Courtès 评价 Codeberg e.V. 员工和志愿者的服务质量「非常好」，偶有 downtime 但「通常时间很短且有清晰沟通」。
最大的坑来自一个没被充分预见的问题：持续集成。
原来邮件时代的 QA 服务（qa.guix.gnu.org）会自动把补丁打到临时分支并编译测试。迁移到 Codeberg 之后，PR 的 CI 没有及时跟上。有好几个月，审查者只能靠人工判断 PR 会不会搞坏东西——在一个每年 500+ PR 的项目里，这根本不可持续。
直到 2025 年 9 月，项目才在 pulls.ci.guix.gnu.org 上部署了 Cuirass（Guix 自研的 CI 工具）来接 PR 构建。Courtès 坦诚这「最初被视为权宜之计」：目前只构建单一架构（x86），比不上原来 QA 的多架构覆盖。但一个意外的利好是反馈的「即时可见性」——Cuirass 以 guix-cuirass-bot 的身份直接在 PR 下回复构建成败，新人不再需要去邮件列表翻找测试结果。
对于那些离不开 Emacs 的开发者，好消息是 fj.el 和 Emacs-Forgejo 两个 Emacs 接口在这一年里快速成熟。AGit 工作流（通过 git push 直接创建 PR，无需先在 Web 上 fork 仓库）也赢得了不少用户。
数据说话：贡献者没少，但积压在涨
这是整篇博客最有价值的部分。Guix 团队做了扎实的数据统计。
先说结论：迁移并没有带来一些人期待的「Codeberg 效应」——贡献者数量的爆发式增长并没有发生。2025 年 6 月（迁移刚完成）确实出现了一个新贡献者和总贡献者数量的小高峰，但此后一年和迁移前一年的增长趋势大致相当。Guix 一直在稳定吸引新贡献者，Codeberg 没有加速这个进程，也没有让它减速。
但绝对数字依然可观：每月有超过 500 个 PR 被提交。合并速率略低于提交速率，导致积压持续增长。目前有 639 个开放 PR，占历史总 PR 数（6459 个）的 10%。作为对比，Nixpkgs 的开放 PR 占比只有 2.5%（1.2 万开放 / 47.3 万历史总量）。
Courtès 把积压归因于两个可能的因素：过高的提交摩擦或 CI 反馈不足。
最大的摩擦点是签名提交要求。Guix 要求每个 commit 必须由授权提交者签名——不像 Nixpkgs 等很多项目那样点一下「Merge」按钮就行。这意味着合入代码的人必须真正对改动负责，不能隐身。这是「软件供应链安全」和「开发者便利性」之间的权衡，Guix 选择了前者：「这是我们愿意做出的取舍，因为我们关心保障软件供应链的安全，但我们还需要看看这个成本能否以某种方式被缓解。」
Lobsters 上炸出的真问题
Lobsters 上这篇博客拿到了 90 分、38 条评论。抛开技术细节，社区讨论炸出了几个更深层的问题。
「不要把 GitHub 换成 Codeberg 垄断」。 用户 FedericoSchonborn 在「希望 Codeberg 成为新 GitHub」的评论下回复：「我宁愿看到许多独立的代码锻造厂通过 ForgeFed 互相通信，而不是把所有东西都搬到 Codeberg。我们不需要一个新的开源中心节点。」这指向了一个悖论：逃离集中式平台如果只是跳到另一个中心节点，等于什么都没改变。推动锻造厂之间的联邦互操作，才是更根本的出路。
工具链集成仍是软肋。 用户 colonelpanic 指出：「自从开始用 Codeberg，我发现几乎没有任何东西真正支持通用 Git 集成——几乎全是 GitHub / GitLab only。」这个问题在第三方 CI、静态托管、项目管理系统等场景中反复出现。根子是生态惯性——当所有 SaaS 的「Connect your repo」按钮背后都只写了 GitHub 和 GitLab 的 OAuth 流程时，选择其他平台就意味着被整个工具链抛弃。
稳定性仍有差距。 用户 ysun 写道：「从我的体验来看，Codeberg 比 GitHub 有更多奇怪的故障，比如 push 会随机失败。」另一位用户 srtcd424 补充：「我不认为 Forgejo 目前能接近 GitHub 的扩展能力。Codeberg 的人在尽力，但需要时间。」
这些都不致命。「替代方案」的真正成本，是此后每一天都要生活在一个生态支持弱一档、稳定性差一档、集成少一档的世界里——迁移那一天的工程量反而可以忽略。Guix 因为有足够的技术能力和自建基础设施的意愿，可以扛住这些成本——但大多数项目扛不住。
自由软件的代价，和它买来的东西
Guix 的这篇文章最值得被记住的，不是结论——它没有给出一个简单的「成功」或「失败」判断。而是过程的透明度。一个没有 BDFL 的自由软件项目，用自己设计的共识决策机制，完成了一次涉及 400+ 人的基础设施迁移，然后把数据、缺陷、争议全部公开。
Courtès 在结尾提到一条「突发新闻」：一个在 Guix 上部署 Forgejo 的 PR 刚刚被提交——「纯声明式配置、完全可复现的锻造厂部署，你能想象吗？」这指向了 Guix 式自由的最终形态：不仅要运行在自由软件的锻造厂上，还要让任何人都能用 Guix 声明式地部署自己的锻造厂。从逃离 GitHub 到自己成为替代方案的基础设施，Guix 走的是一条比「搬家」更远的路。
Guix 基金会在最近投票成为 Codeberg e.V. 的支持性（非投票）成员，作为表达感谢和支持的方式。这或许是另一个信号：逃离 GitHub 需要与替代平台建立持续投入资源的长期关系，一次搬家远远不够。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。