为何我要从 GitHub 迁移至 Forgejo

# 为什么我离开 GitHub 转向 Forgejo | Jorijn Schrijvershof 来源: https://jorijn.com/en/blog/leaving-github-for-forgejo/ 我将我的代码从 GitHub 迁移到了自托管的 Forgejo。并非因为服务中断，而是因为谁拥有运行在这些服务之上的东西。荷兰政府刚刚做出了同样的选择。 2026 年 4 月 27 日，荷兰内政部低调上线了 code.overheid.nl (https://www.nldigitalgovernment.nl/news/soft-launch-for-government-open-source-code-platform/)，这是一个用于荷兰政府源代码的自托管 Forgejo 实例。项目经理 Boris Van Hoytema 表示，该平台“源于该部门必须在法律上将其源代码发布在其拥有的地方的要求”，并且选择 Forgejo 而非 GitLab 是因为它完全开源，提供了数字自主权所需的所有自由 (https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/dutch-alternative-sharing-public-code)。 前一周，我悄然将自己的代码向同一方向迁移。我现在主要的 Git 托管地址是 code.jorijn.com (https://code.jorijn.com/)，在一台经过加固配置的 NUC 上运行着 Forgejo v15 LTS。我的一些代码库已经搬了过去；其余的正在排队等待迁移。长期计划是在迁移完成后归档我的公共 GitHub 代码库，并将每个归档指向新的主页。 大多数关于离开 GitHub 的文章都以服务中断为开头。中断是真实的。但这不是我离开的原因。服务中断、默认启用的 AI 以及 GitHub 不再拥有自己的 CEO，这些都是一个基本事实的症状：我不拥有这个平台。荷兰政府刚刚得出了相同的结论。因此，这是这种思考的长篇版本，以及当你决定做出这一改变时，实际情况是什么样的。 **简而言之** - GitHub 在 2025 年 5 月至 2026 年 4 月期间记录了 257 起事件，其中 48 起为重大事件。CTO 公开道歉并表示，为了跟上 AI 驱动的负载，容量需要扩大 30 倍。 - 2025 年 8 月，GitHub 不再拥有自己的 CEO。它现在是微软 CoreAI 部门的一个单元，该部门负责构建 Copilot 和更广泛的 AI 堆栈。 - 2026 年 4 月 24 日，GitHub 将 Copilot Free、Pro 和 Pro+ 的用户交互数据默认切换为用于 AI 训练的光选入（opt-in）模式。没有代码库级别的退出选项。 - 根据《外国情报监视法》（FISA）第 702 条和《云法案》（CLOUD Act）的美国司法管辖区风险尚未解决。微软自己的律师在法国参议院宣誓作证时称，他无法保证欧盟数据免受美国政府无声访问的影响。 - 荷兰政府在 2026 年 4 月因相同的原因选择了 Forgejo 用于 code.overheid.nl。我也对我的工作做出了同样的选择。 - code.jorijn.com 在一台 NUC 上运行 Forgejo v15 LTS，配有 KVM 隔离的、每周重建的 Actions runner。公共 GitHub 代码库将在迁移完成后进行归档，并指向新主页。 ## 为什么服务中断实际上并不是原因 2026 年 4 月的服务中断是那种会让工程师愤怒的类型。4 月 23 日，合并队列的 squash-merge 代码路径 (https://www.theregister.com/2026/04/29/github_says_sorry_and_says/) 在功能标志未完全回滚后，在 658 个代码库和 2,092 个拉取请求中静默回滚了先前已合并的提交。包括 Modal 和 Zipline 在内的公司进行了手动数据恢复。四天后，过载的 Elasticsearch 集群导致拉取请求、问题和软件包离线超过六个小时。 但是，随便选哪一个月，情况都同样糟糕。仅在 2026 年 2 月就记录了 37 起事件，包括一次导致 Actions、Copilot Coding Agent、Code Review、CodeQL、Dependabot 和 Pages 同时宕机长达 3 小时 40 分钟的中断。2025 年 10 月 1 日是一次长达十小时的 macOS 运行器中断。IncidentHub 的聚合统计显示，2025 年 5 月至 2026 年 4 月的总数为 257 起事件和 48 起重大中断 (https://blog.incidenthub.cloud/github-reliability-outage-history-2025-2026)，总停机时间约为 112 小时。 正确解读这份清单的方式不是“GitHub 不可靠”。大型系统会崩溃。正确的解读方式是 GitHub 自身对其设定的框架。CTO Vlad Fedorov 于 4 月 28 日道歉 (https://github.blog/news-insights/company-news/an-update-on-github-availability/) 并表示，容量必须增长 30 倍才能跟上负载。他将这种负载直接归因于自 2025 年 12 月以来的“代理式 AI 工作流增长”。可靠性故事是 AI 故事的下游产物。GitHub 并未减缓 AI 功能的步伐。它正在加倍投入。中断就是加倍投入在生产环境中的样子。 务实工程师（The Pragmatic Engineer）指出，GitLab、Bitbucket、Vercel、Linear 和 Sentry 并没有经历同样的一年 (https://newsletter.pragmaticengineer.com/p/the-pulse-ai-load-breaks-github-why)。它们在同样的整体需求压力下为开发者提供服务。GitHub 正在努力应对的问题对 GitHub 而言是特有的。 ## GitHub 不再拥有自己的 CEO 更大的事实比道歉更早出现，而且获得的媒体报道要少得多。2025 年 8 月 11 日，Thomas Dohmke 卸任 (https://github.blog/news-insights/company-news/goodbye-github/) GitHub CEO 一职。微软没有任命他的继任者。相反，GitHub 被并入微软的 CoreAI 部门 (https://www.geekwire.com/2025/github-will-join-microsofts-coreai-group-with-departure-of-ceo-thomas-dohmke/)，这是一个由 Satya Nadella 于 2025 年 1 月引入的团队 (https://blogs.microsoft.com/blog/2025/01/13/introducing-core-ai-platform-and-tools/)，其明确使命是构建*面向第一方和第三方客户的端到端 Copilot 和 AI 堆栈*。 GitHub 的收入、工程和支持现在向 Julia Liuson 领导的微软开发者部门汇报。GitHub 的首席产品官向微软 AI 平台副总裁汇报。品牌依然存在。独立的领导层不复存在。 这很重要，因为留在 GitHub 上的旧有论点是微软将其保持距离。从 2018 年到 2024 年，这在实质上是真实的。Dohmke 拥有真正的发言权。产品决策显然是 GitHub 的，而不是微软的。2025 年 8 月之后，这一论点不再成立。当你今天向 github.com 推送代码时，你实际上是将其推送到微软 AI 组织的一个单元。这是否让你困扰，取决于你有多少信任微软的 AI 组织会为你的代码库做出与旧版 GitHub 相同的决策。我不再信任，而这种不信任的原因将在下一部分中显现。 ## 训练数据默认值发生了翻转 2026 年 3 月 25 日，GitHub 宣布了一项隐私声明变更 (https://github.blog/changelog/2026-03-25-updates-to-our-privacy-statement-and-terms-of-service-how-we-use-your-data/)，自 4 月 24 日起生效。从该日期起，*Copilot Free、Pro 和 Pro+ 用户的交互数据，具体包括输入、输出、代码片段和相关上下文，将用于训练和改进我们的 AI 模型，除非用户选择退出*。 关于这一声明有三件事至关重要，按顺序排列。 第一：退出而非加入。默认值翻转了。任何使用 Copilot 免费、Pro 或 Pro+ 的人现在都在为模型训练做出贡献，除非他们前往 Copilot 设置页面并关闭该功能。 第二：没有代码库级别的开关。作为维护者，我不能告诉 GitHub *不要在我的代码库内的交互上进行训练*。退出选项是按用户账户进行的，因此每位贡献者都必须做出自己的选择。实际上，我的代码库在任何人使用 Copilot Free/Pro/Pro+ 触碰它时就会成为训练材料，无论我如何授权。 第三：私有代码库的例外情况比听起来更窄。GitHub 表示不使用私有代码库“静止”内容进行训练，但它确实收集在私有代码库中使用 Copilot *时*生成的“代码片段和交互上下文”。*静止的代码*与*编辑时生成的片段*之间的界限，善意地说，是模糊的。 Copilot Business 和 Copilot Enterprise 客户享有豁免权，因为他们受单独的数据保护协议管辖。划分很明确：支付足够的费用，你的交互就不是训练数据。否则，它们就是。 我在几周前写过关于代理式 GitHub Actions 的文章 (https://jorijn.com/en/blog/github-actions-agentic-workflows-natural-language-cicd/)，当时安全模型是头条新闻。训练数据的翻转是同一个故事的第二部分：GitHub 对你的交互数据的战略利益现在是结构性的，而非可选的。我对在别人的平台上争论该策略的优劣不感兴趣。我宁愿不在这个平台上。 ## 还有司法管辖区的问题 在所有这些之下，有一层东西不会随着隐私声明的改变而改变。GitHub Inc. 和 Microsoft Corp. 是美国公司。他们持有的任何内容都适用于美国法律，包括《外国情报监视法》（FISA）第 702 条 (https://www.congress.gov/crs-product/R48592) 和 2018 年的《云法案》（CLOUD Act）(https://natlawreview.com/article/beyond-server-location-why-new-fight-over-fisa-702-and-cloud-act-matters-corporate)。无论数据物理上位于何处，这两者都适用。 第 702 条于 2024 年 4 月重新授权两年，目前正运行在 45 天的延期上 (https://www.cnbc.com/2026/04/30/fisa-section-702-congress-extension.html)，该延期于 2026 年 4 月底签署，而国会正在争论更长的续期。它授权美国情报机构通过 domiciled 在美国的电子通信服务提供商针对非美国人员进行情报收集。《云法案》允许美国执法部门强制总部位于美国的公司提供存储在世界任何地方的数据。 GitHub 于 2024 年 10 月宣布为企业云提供欧盟数据驻留 (https://github.blog/changelog/2024-10-29-github-enterprise-cloud-data-residency-in-the-eu-is-generally-available/)。这解决了数据位置问题。但它没有解决司法管辖区问题。《云法案》的暴露取决于公司控制，而非地理位置。 对此最诚实的阐述并非来自监管机构，而是来自微软自己的律师，他在 2025 年 6 月的法国参议院听证会上宣誓作证称，他*无法保证存储在欧洲微软数据中心中的法国数据免受美国政府无声访问的影响* (https://techcrunch.com/2026/04/27/whats-behind-europes-efforts-to-ditch-u-s-software-in-favor-of-sovereign-tech/)。 我在 earlier piece on why "hosted in Frankfurt" doesn't mean GDPR-compliant (https://jorijn.com/en/blog/eu-data-sovereignty-hosted-in-frankfurt-not-gdpr-compliant/) 中涵盖了更广泛的法律图景，并在 my piece on NIS2 (https://jorijn.com/en/blog/nis2-directive-for-hosting-providers-and-their-clients/) 中讨论了托管提供商的操作影响，因此我将细节保留在那里。这里重要的是一个狭窄的点。只要你的代码存放在 github.com，你的代码就处于美国法律领土内。欧盟数据驻留是一种安慰，而非修复。 ## 荷兰政府的选择：code.overheid.nl 这就是荷兰政府的选择值得关注更多关注的地方。法律驱动力是荷兰自 2020 年以来实施的“Open, tenzij (https://fsfe.org/news/2020/news-20200424-01.en.html)”政策：除非安全或保密要求另有规定，否则使用公共资金开发的软件默认为开源。为了遵守规定，该部门需要一个真正受其控制的地方来发布代码。Code.overheid.nl 就是答案。 值得暂停思考的是*他们选择了哪个 forge*。欧盟委员会自 2022 年 9 月以来在自托管的 GitLab 上运行 code.europa.eu (https://interoperable-europe.ec.europa.eu/collection/open-source-observatory-osor/news/ecs-codeeuropaeu-launches)。德国的 openCode (https://opencode.de/en) 也是 GitLab。法国的 code.gouv.fr (https://code.gouv.fr/fr/) 是一个聚合器，索引托管在其他地方的代码库，本身并不是一个 forge。 荷兰政府选择 Forgejo 而非 GitLab 是故意的。正如 OSOR 文章所述，理由是 Forgejo 完全开源，没有核心开源分裂，提供了数字自主权所需的所有自由。Van Hoytema 补充说，Forgejo 的路径图“远远更 aligned”与他们相比的替代品。政府不仅仅想要一个主权 forge。他们想要一个不受商业供应商高级别限制的主权 forge。 因此，机构模式很重要：一个拥有严肃律师和长远记忆的国家政府查看了与我相同的图景，做出了相同的决定，并在前一周将其付诸实施。这并不能证明决定是正确的。这至少证明了该决定已不再边缘化。 ## 为什么选择 Forgejo，而不是 GitLab 我认真权衡了 GitLab。自托管的 GitLab CE 是一个已知量，拥有更大的商业生态系统，老实说，界面更精致。两件事影响了选择。 第一：许可证。GitLab 是核心开源。社区版采用 MIT 许可证，但我在生产中实际想要的许多功能都存在于企业层级下，受非自由许可证约束。Forgejo 走向了另一条路。截至 2024 年 8 月的 v9.0 (https://forgejo.org/2024-08-gpl/)，项目从 MIT 重新许可为 GPLv3+，明确目标是保持 copyleft 并抵制代码库未来的商业收购。2022 年 12 月从 Gitea 分叉 (https://blog.codeberg.org/codeberg-launches-forgejo.html) 的发生，正是因为 Gitea Ltd 以社区未同意的方式控制了商标和域名。吸取的教训体现在许可证中。 第二：治理。Forgejo 位于 Codeberg e.V. (https://docs.codeberg.org/getting-started/what-is-codeberg/) 之下，这是一个自 2018 年 9 月在柏林注册的非营利组织，拥有成员选举的董事会、公开预算和其托管实例上的 30 万个以上代码库。成员每年投票决定预算；2025 年计划以 88 票赞成、0 票反对、1 票弃权获得通过。这不是关于社区治理的市场营销声明。这是一个德国*Verein*在做*Vereine*做的事。 Forgejo v15.0 LTS 于 2026 年 4 月 16 日发布 (https://forgejo.org/2026-04-release-v15-0/)。它是该项目的第 100 个版本。长期支持将持续到 2027 年 7 月 15 日。Forgejo Actions 在 v15 中达到了我所需的成熟度（临时运行器、OpenID Connect、可重用工作流扩展）。自分叉以来的发布一直很稳定，并有活跃月度报告。 诚实的警告：商业 Forgejo 生态系统是真实的但单薄。目前最清晰的商业产品是 Codey by VSHN (https://www.codey.ch/)，这是一个瑞士托管的管理型 Forgejo，每月 19 瑞士法郎，于 2025 年 3 月在 Servala 推出。没有红帽风格的企业支持订阅。如果你需要 24/7 电话支持和一个可以指责的供应商，你需要自己构建，或者等待。我愿意等待，因为我更愿意拥有平台。 ## 我构建了什么，以及为什么它看起来是这样的 Code.jorijn.com 运行在我家庭办公室的一台配备 64 GB RAM 的 Intel NUC 上。Forgejo v15 LTS、Postgres 17 和 Traefik 生活在 Docker 中。一个由 Incus 管理的 KVM 虚拟机与它们并列，运行我的 Forgejo Actions runner。这就是整个平台。 架构概览：单台 NUC 在 Docker 中运行 Forgejo、Postgres 和 Traefik，另有一台 KVM 虚拟机托管 Actions runner。runner 通过路由器的 hairpin NAT 经由公共主机名到达 Forgejo，这使得路径与任何外部客户端相同。 有趣的决定不在于 Forgejo 的部署。Forgejo 加上 Postgres 加上反向代理并不有趣。花费最多思考的决定是 runner。 ### 危险实际上在哪里 如果你自托管一个 forge，forge 本身是容易的部分。困难的部分是运行 CI 作业的东西。我的 runner 必须在日常 Renovate 计划下执行 `npm install`、`composer install` 和 `pip install`，针对锁文件生成...