- Published on
开发者离开 GitHub 转向 Codeberg 的原因 — 以及离开时真正失去的东西
- Authors
- Name
- Youngju Kim
- @fjvbn20031
开篇 — "离开 GitHub"的文章多了起来
最近在 GeekNews 和 Hacker News 上，HowToGeek 那篇《开发者正在抛弃 GitHub，转向 Codeberg 和自托管替代方案》的文章正被广泛传播。确实有几个知名项目离开了，个人开发者"我为什么离开"的回顾也接连不断地涌现。
先把话说平衡。GitHub 并没有在下沉。单看同一篇文章里的数字，GitHub 至今仍以大约每秒一名的速度新增用户，仓库数量已超过 6 亿，2025 年一年的提交量逼近 10 亿次。"大逃亡"这个词显然是夸张。尽管如此，仍有认真看待这股潮流的理由 — 人们给出的理由不是模糊的情绪，而是具体的，而且大多是 2025~2026 年新出现的。本文不是声讨 GitHub，而是想诚实地分辨什么是真的、又实际拿什么去交换。
真正在推动人们的是什么
第一是 可靠性。据第三方故障追踪(IncidentHub)统计，从 2025 年 5 月起约一年间，主要(major)故障有 48 起，总停机时间约 112 小时，其中 Actions 是最常崩溃的服务。这种故障疲劳，推动了终端模拟器 Ghostty(2026 年 4 月)和 Zig 语言(2025 年 11 月)的出走。Jonas Hietala 还进一步指出了 Actions runner 的忙等待(busy-wait)循环之类的代码质量问题。
第二是 所有权。2025 年 8 月，GitHub 被并入微软的 CoreAI 组织，独立 CEO 的职位随之消失。已卸任的 Thomas Dohmke 在 2025 年曾以"要么接受 AI，要么离开这一行"的意思发言。转向 Forgejo 的 Jorijn Schrijvershof 点出的核心也不是故障，而是这一点 — 归根结底，我并不拥有这个平台。
第三个、也是 2026 年最具体的导火索，是 AI 训练默认值的反转。据 Jorijn 所说，2026 年 4 月 24 日，GitHub 对 Copilot Free、Pro、Pro+ 用户，把代码用于 AI 训练改成了 opt-out(默认允许)，而且没有仓库级别的开关。也就是说，只要贡献者开着 Copilot 工作，维护者就没有办法阻止自己的代码流入训练数据。Gentoo 在 2026 年 2 月 16 日落脚 Codeberg 时，把"不断被推动在仓库里使用 Copilot"列为理由，也是同样的脉络。
在此之上又叠加了管辖权的担忧。就算把数据放在欧盟，在 FISA 第 702 条和 CLOUD Act 之下，美国法律的手依然够得着。HowToGeek 也提到了过去与 ICE 的合同(2019 年遭批评)以及 GNU 阵营的旧有许可证异议，但这些与其说是 2026 年的导火索，不如说更接近早已埋下的政治积怨。
Codeberg 与 Forgejo 实际能带来什么
Codeberg 由在德国注册的非营利组织 Codeberg e.V. 运营。会员选举理事会，预算对外公开(2025 年预算以 88-0-1 获得通过)，其托管实例上已经承载了超过 30 万个仓库。在其背后运行的软件就是 Forgejo。
Forgejo 用 Go 编写，2024 年 8 月重新以 GPLv3+ 授权。正如从 Gitea 分叉中得到的教训，这是为了防止代码库再次被商业收编而做的有意选择。而且这个软件可以自托管。出走的开发者们异口同声的第一印象，就是"快"。
不过自托管不是免费的。Jorijn 的配置是个好例子 — 一台 Intel NUC 配 64GB 内存，在 Docker 上跑 Forgejo v15 LTS 和 PostgreSQL 17，还有 Traefik。到这里都还算简朴。麻烦的是 CI。运行别人代码的自托管 runner 需要认真的隔离，于是他堆起了五层——KVM 虚拟机、默认运行时 gVisor、每周的破坏性重建、nftables 出站(egress)过滤、作用域受限的令牌。这才是"离开 GitHub"的真实账单。
但这并不是一个边缘的选择。荷兰政府在 2026 年 4 月上线了基于自托管 Forgejo 的 code.overheid.nl。其逻辑相同 — 自己拥有政府的代码基础设施，使用没有厂商把关的完全开源方案。在个人层面，Jonas Hietala 采取了折中方案 — 自托管 Forgejo 作为主界面，同时镜像到 Codeberg 作为对外公开的门面。
离开时真正失去的东西
失去最多的是 网络效应与可发现性。6 亿个仓库形成的引力，是替代方案模仿不来的。Hacker News 上得票最高的评论很冷静 — 把区区几个有意义的仓库和数十万个并排放在一起，能叫"趋势"吗。贡献者依然期待 github.com，而离开的一方则得依赖重定向和已归档的指针。
CI 的经济账 也很沉重。GitHub 撒向开源的免费 Actions 分钟数(minutes)，实际上扮演着"就留下别走"的补贴角色。自托管能换来更快的 CI(有人说 40 分钟缩短到了 10 分钟)和无限的 runner 分钟，但运维就全数落到自己头上。何况正如 Jorijn 所说，Forgejo Actions"追求的是熟悉感，而不是兼容性"。
# Forgejo Actions: 熟悉但并不兼容(Jorijn 的记录)
permissions: 块 → 被悄悄忽略
actions/checkout@v6 → 带认证的检出会坏，需固定到 v5
actions/upload-artifact@v4 → 需要单独的 Forgejo 分叉版本
OIDC 工作流语法 → 与 GitHub 不同
Dependabot → 没有，用 Renovate 代替
Codespaces / Apps 市场 / Advanced Security / 24-7 厂商支持 → 没有
替代方案自身的扩张阵痛也不容忽视。Codeberg 曾有过因持续的 DDoS 而性能变差的时期(Jonas)，也有报告称防抓取的机制(Anubis/iocaine)会因误判把正常用户一并挡在门外(HN)。非营利组织的容量是有限的。所以连 Jorijn 都诚实地划了条线 — 如果没有余力运维基础设施、深度依赖 GitHub 独有的功能、比起所有权更看重贡献者的发现，或者没把握安全地运营 runner，那么自托管就不是答案。Hacker News 大致的结论也落在相近的地方 — 眼下的出走，与其说是更优的替代方案逼着谁迁移，不如说更接近原则与理念。
结语
所以真正的问题不是"GitHub 会不会下沉" — 因为它不会。真正的问题是"我的基础设施由谁拥有，以及事后才意识到自己并不拥有它，这个代价有多大"。这条轴归根结底是触达范围对所有权。Codeberg 与 Forgejo 让你交出触达范围与便利，换回的是所有权、治理，以及速度。
对于重视独立、并且真的能自己把基础设施运维起来的个人或项目而言，这种迁移正变得越来越现实。反过来，对于活在贡献者发现和 Actions 生态之上的项目来说，同样的迁移会变成一张相当昂贵的账单。诚实的态度是这样的 — 认真倾听人们给出的理由，但不要夸大趋势，并亲手衡量自己到底有多依赖 GitHub。