作者因担忧平台所有权问题，将代码从GitHub迁移至自托管的Forgejo。荷兰政府也基于同样考虑，选择Forgejo作为开源代码托管平台，因其完全开源且功能完善。

从GitHub迁移至Forgejo：一次关于代码主权的实践

核心动因

荷兰开发者Jorijn Schrijvershof于2026年5月公开其代码迁移计划，将全部项目从GitHub转移至自托管的Forgejo实例。这一决定与荷兰政府同期启动的code.overheid.nl平台形成呼应，二者均基于对平台控制权、数据主权和AI伦理的深度考量。

关键转折点

1. GitHub的战略转型

   • 2025年8月GitHub被并入微软CoreAI部门，失去独立CEO职位
   • 2026年4月Copilot默认启用用户交互数据训练AI模型（仅账户级可关闭）
   • 2025年5月至2026年4月共发生257次服务中断，48次重大故障，AI负载被指为主要原因

2. 司法管辖风险

   • 美国《CLOUD法案》和《FISA 702条款》使欧盟数据驻留方案形同虚设
   • 微软律师在法国议会作证时承认无法保证欧盟数据免受美国政府访问

荷兰政府的示范效应

荷兰内政部选择Forgejo而非GitLab构建政府代码平台，因其： - 完全开源（无开放核心商业陷阱） - 符合数字自主权要求 - 发展路线与政府需求高度契合

技术实施方案

基础设施架构： - 单台Intel NUC（64GB内存）运行Forgejo v15 LTS - 通过KVM虚拟机隔离CI运行环境 - 五层安全防护： 1. KVM虚拟化隔离 2. gVisor容器运行时 3. 每周销毁重建机制 4. nftables出口过滤 5. 范围限定的运行器令牌

迁移成本： - 失去GitHub社交图谱和发现机制（通过仓库存档+重定向缓解） - 需替代Dependabot（使用自托管Renovate） - GitHub Actions生态兼容性摩擦

决策评估框架

不建议迁移的情况包括： - 严重依赖GitHub特有功能（如Codespaces） - 缺乏基础设施运维能力 - 以开发者社区可见性为优先考量

深层启示

该案例揭示了开源协作生态正在发生的结构性变化：从商业平台依赖转向主权控制，其中Forgejo作为Gitea分支的代表，通过GPLv3+许可和Codeberg非营利治理，提供了另一种可能性。正如作者强调的，这不是关于可靠性的选择，而是关于"谁拥有运行在底层系统之上的内容"的根本命题。

（注：本文在编辑过程中保留了原作的论证逻辑与技术细节，删减了重复的故障数据列举、导航菜单等非核心内容，对技术术语进行了中文语境适配。）

以下是评论内容的总结：

1. 对GitHub的批评与替代方案

• 观点：GitHub的集中化违背了Git的去中心化精神，且存在AI扫描、微软控制等问题。

  • 引用："Git was always meant to be decentralized... GitHub is just another place you can host your code" (评论1)
  • 引用："I don’t really trust GitHub to keep things private anymore" (评论16)

• 替代方案：

  • Forgejo/Gitea：自托管方案，易用且受推荐。
    • 引用："I have been self-hosting Forgejo... impressively easy to maintain" (评论2)
    • 引用："I’m really impressed with Forgejo" (评论17)
  • Tangled：基于AT协议的去中心化平台。
    • 引用："I’m making my jump over to Tangled... finding it lovely" (评论15)
  • Fossil：单文件存储的版本控制工具。
    • 引用："Consider Fossil... packages the entire repository state into a single file" (评论27)

2. 自托管的优势与挑战

• 优势：隐私控制、避免AI抓取、脱离大公司依赖。

  • 引用："No https, registrations disabled and repos are not public" (评论6)
  • 引用："I don’t want to provide AI scrapers with content" (评论12)

• 挑战：CI/CD功能缺失、多平台支持困难。

  • 引用："How do you guys using Forgejo... get a similar matrix [of runners]?" (评论23)
  • 引用："I wish it offered a windows binary" (评论26)

3. 对去中心化的反思

• 质疑：去中心化可能只是寻求新中心化的借口。

  • 引用："Perhaps when people ask for decentralization, they are actually seeking a new center" (评论7)

• 现实需求：用户仍依赖集中化工具的便利性。

  • 引用："some of my identity is built around github... releases, packages, actions... very convenient" (评论20)

4. 商业与政治因素

• 企业行为批评：GitHub等平台滥用开源成果。

  • 引用："companies that benefited from open source have poisoned the industry" (评论12)

• 地缘政治考量：欧洲主权解决方案受关注。

  • 引用："Dutch government’s choice of Forgejo, not GitLab, was deliberate" (评论14)
  • 引用："EU-sovereign CI/CD with Git included" (评论9)

5. 用户粘性与迁移障碍

• 迁移阻力：品牌依赖、社交图谱、功能习惯。

  • 引用："The hardest parts of switching... adapting to not having the same GitHub v3 API" (评论16)

• 成本问题：低价基础托管服务缺失。

  • 引用："Who offers low feature git hosting for a small price?" (评论19)

总结呈现了从技术、政治到用户体验的多维度讨论，既包含对GitHub的批评，也涵盖了替代方案的实践与局限，同时反映了去中心化理想与现实集中化需求之间的矛盾。