一

2013 年 5 月，中国深圳一家叫“开源中国社区”（OSChina）的小公司发布了一个新产品——Gitee。它是一个仿 GitHub 的代码托管平台。当时中国开发者多数仍然用 GitHub；Gitee 是个相对小众的本土替代。

11 年后的 2024 年，Gitee 已经成为中国开发者生态的重要组成。它声称突破 1000 万开发者用户，托管多个国家级开源项目——包括 openEuler、OpenHarmony 的主仓1。

但 Gitee 跟 GitHub 之间的关系不是简单的“中国版 GitHub”。它的实际地位更复杂：

  • 官方主仓：openEuler、OpenHarmony 等关键中国项目的主代码仓库在 Gitee
  • mirror 用途：很多中国公司在 Gitee 维护其 GitHub 项目的镜像作为备份
  • 国内协作：当跨国协作不方便时，国内团队倾向用 Gitee 做内部协作
  • 公开 PR / issue：但全球公开协作主仓仍然在 GitHub

到 2026 年初，绝大多数中国开发者仍然把 GitHub 作为主要协作平台。Gitee 是补充，不是替代。但 Gitee 的存在本身改变了博弈——如果哪一天 GitHub 不可用，中国生态有一个不完美但可用的备援2。

二

Gitee 的具体功能跟 GitHub 大同小异：repo 托管、issue tracker、Pull Request、wiki、CI、organization 管理。但有几个关键差异：

审查机制：Gitee 比 GitHub 有更明显的内容审查。某些政治敏感内容会被自动隐藏或要求 take down。这种审查不是 Gitee 单独的事——它是中国 ICP 备案制度的延伸。任何中国注册的互联网平台都必须执行类似审查。

实名制：Gitee 要求中国大陆用户实名注册——身份证 + 手机号绑定。这跟 GitHub 完全匿名注册不同。实名制让“用户身份可追溯”成为默认。

国际化弱：Gitee 的 UI 主要是中文（虽然有英文版）。它的功能更新通常先服务中国市场，英文社区滞后。这造成了一种自我强化——非中文开发者很少用 Gitee，所以 Gitee 没有动力做强国际化。

法律合规：Gitee 作为中国公司，必须遵守中国法律——包括《网络安全法》、《数据安全法》、《个人信息保护法》。这跟 GitHub 受美国 OFAC 约束在结构上对称，但具体规则不同3。

读懂这些差异，能理解 Gitee 的真实定位：它是“在中国法律框架下运作的代码托管”——既不是“中国版 GitHub”，也不是 GitHub 的简单替代。它的用户基础是接受中国合规框架的开发者。

三

俄罗斯的 forge 故事不同。

俄罗斯没有像 Gitee 那样有规模的本土代码托管。它有几个项目：

GitFlic：俄罗斯本土 forge，2018 年起步。它的功能跟 GitHub 类似但规模小得多。2022 年俄乌战争后用户开始显著增长，但绝对数字仍然有限（估计在数十万级别）4。

自托管 GitLab：俄罗斯大企业大量使用自托管 GitLab。GitLab 公司本身（在美国）没有像 GitHub 那样对俄罗斯实体大规模封锁，主要原因是 GitLab 的开源版本可以被自托管——俄罗斯企业即使被 GitLab.com 封了也可以继续用自己服务器上的 GitLab 实例。

Yandex 内部：Yandex 维护自己的内部 git 基础设施。这跟 GitFlic / GitLab 不同——它不对外公开，只服务 Yandex 内部和合作伙伴。

俄罗斯的 forge 状况反映了俄罗斯科技生态的一个特点：它较为集中。少数几个大公司（Yandex、VK、Sber）主导，没有像中国那样的丰富中型科技公司生态。这让俄罗斯本土 forge 没法形成像 Gitee 那样的规模——因为活跃用户基础有限。

但 2022 年俄乌战争之后，俄罗斯政府推动“数字主权”政策。Decree 166 要求关键基础设施迁移到本土软件——这间接推动 GitFlic 等本土 forge 的应用5。到 2026 年，俄罗斯主要政府部门已经基本完成代码托管的本土化——不一定到 GitFlic，但至少不在被制裁可影响的境外平台。

四

欧洲 forge 生态走了完全不同的路径。

欧洲不像中国那样有“国家强制”驱动的本土 forge——欧盟没有“欧产 GitHub”政策。相反，欧洲的 forge 替代品多数是社区驱动的、强调数据主权与隐私的项目。

Codeberg 是这个生态的代表。Codeberg 是德国非营利组织 Codeberg e.V. 运营的代码托管服务。它基于开源的 Forgejo 软件运行6。

Codeberg 的定位：

  • 数据存储在德国，受 GDPR 保护
  • 没有 AI 训练数据采集（明确反对 GitHub Copilot 那种用户代码用于训练 AI）
  • 完全开源（用 Forgejo）
  • 非营利运营（不追求商业增长）

到 2024 年，Codeberg 用户在 10 万级别——相对 GitHub 的数千万小很多，但增长稳定。它的用户多数是隐私敏感的欧洲开发者、不愿被 AI 训练的项目、需要 GDPR 合规的小型公司。

Forgejo 是 Codeberg 背后的软件——一个 Gitea 的 fork。Gitea 是 2016 年起源的开源 GitHub 替代软件。2022 年 10 月，Gitea 的商标和域名被转给一个新成立的营利公司 Gitea Limited，没有事先咨询社区。这个商业化决定让大部分 Gitea 贡献者不满。他们 fork 了项目，成立 Forgejo——回归社区治理7。

Forgejo 由 Codeberg e.V. 维护，强调“无商业实体”原则。这跟 Gitea Ltd 的“开源 + 商业”模式形成对比。

Radicle 是另一种欧洲尝试。Radicle 是 peer-to-peer 的、不需要中心服务器的代码协作平台。每个用户在自己机器上运行 Radicle，repo 复制到多个 peer。这是“完全去中心化”的极端尝试——没有任何公司或基金会能“关闭”Radicle8。

Radicle 的实际使用规模很小——多数开发者发现完全 P2P 模型对日常协作不实用。但它代表了一种思想：如果你不想被任何 forge 管辖，去中心化是出路。

五

把 Gitee、GitFlic、Codeberg、Radicle 放在一起，能看到几种不同的“主权策略”：

Forge主权模式治理用户规模
Gitee中国国家合规商业公司（开源中国 + 华为/阿里影响）~1000 万
GitFlic俄罗斯国家驱动商业公司~数十万
Codeberg欧洲社区数据主权非营利 e.V.~10 万
Forgejo完全开源、社区驱动非营利自托管，规模未知
Radicle完全去中心化协议（不是公司）极小

每种策略对应不同的“威胁模型”：

  • Gitee 防御：美国制裁、本土合规
  • GitFlic 防御：西方制裁、本土合规
  • Codeberg 防御：商业化数据采集、AI 训练污染
  • Forgejo 防御：商业化背离社区
  • Radicle 防御：任何中心化失败

读懂这点，能理解 forge 平行化不是“反 GitHub”——是针对不同威胁的不同应对。

GitHub 仍然是全球最大的代码托管——估计 1 亿+ 开发者注册9。它服务的“威胁模型”是“绝大多数开发者大部分时间在做正常工作”。这种威胁模型对全球协作是高效的。但对那些有特定主权风险的开发者，GitHub 不够。

六

中国镜像生态是 forge 平行化的另一种形式。

中国主要大学和云服务商维护着丰富的开源软件镜像：

  • 中国科学技术大学（USTC）开源软件镜像站
  • 清华大学开源软件镜像站
  • 阿里云开源镜像站
  • 华为云开源镜像
  • 北京邮电大学镜像
  • 上海交通大学镜像
  • 网易镜像
  • 腾讯镜像10

这些镜像同步 GitHub、PyPI、npm、Docker Hub、Maven、Ubuntu、Debian、CentOS 等几乎所有主要开源生态。一个中国开发者可以从这些镜像下载几乎所有开源软件——不需要直接访问国际原始仓库。

这个镜像基础设施的意义：它是“假如 GitHub 不可访问”的备援。

实际中，多数中国开发者仍然能访问 GitHub（虽然有时候慢，需要 VPN 等）。但镜像基础设施意味着即使 GitHub 完全断开，已经发布的开源软件仍然可以在中国境内获得。这不解决“实时协作”问题（issue、PR、social 仍然在 GitHub 上），但解决“软件可用”问题。

俄罗斯也有类似但规模小得多的镜像基础设施。Yandex 维护一些镜像；Mail.ru 维护一些。但俄罗斯的镜像覆盖比中国窄——主要是 Linux 发行版和最常用的工具，不像中国镜像覆盖几乎所有 PyPI、npm 等11。

七

“假如 GitHub 不可用”——这个 thought experiment 在 2022 年俄罗斯被部分测试。

2022 年俄乌战争后，俄罗斯部分企业失去了 GitHub 访问。这不是 GitHub 完全断开俄罗斯——而是 GitHub 对部分被制裁的俄罗斯实体封锁。具体说：

  • 普通俄罗斯个人开发者基本不受影响（仍然能用 GitHub）
  • 被制裁的俄罗斯公司（Sberbank、Gazprom、部分国防工业）的企业账号被关闭
  • 这些公司的员工失去通过公司账号的协作能力

这种“部分断开”已经造成了显著的迁移：

  • 被影响的俄罗斯企业普遍转向自托管 GitLab
  • GitFlic 用户增长
  • 俄罗斯政府推动 Decree 166 加速本土迁移12

但完整的“GitHub 不可用”仍然没有被测试。即使 2022 年俄乌战争后，GitHub 也没有对整个俄罗斯封锁——只针对被制裁实体。整个俄罗斯生态仍然能用 GitHub 做大部分工作。

如果哪一天 GitHub 对整个俄罗斯断开——比如美国制裁升级到“地区级”——会发生什么？

俄罗斯的回应大概率是：

  • 镜像基础设施紧急升级（从有限覆盖到全面覆盖）
  • 国内 forge（GitFlic）紧急扩容
  • 政府强制企业迁移到本土
  • 现有 GitHub repo 通过各种方式（git clone、bundle、torrent）保存到俄罗斯境内

技术上是可行的——但社交层面会损失。issue tracker 上的讨论历史、PR 上的 review 记录、组织页面、profile 关系——这些不容易被简单“镜像”。一个项目从 GitHub 切到 GitFlic，技术资产可以迁移，但社交资产部分丢失。

八

中国的“预演”更系统。

中国主要科技公司在 2018-2024 年间做了大量“假设 GitHub 不可用”的备援工作：

  • 北邮、清华、华为等的内部基础设施已经“假设 GitHub 不可用”做了备援
  • 主要项目在 Gitee 维护镜像
  • 自动同步脚本（每天 / 每小时同步关键 repo）
  • 内部 fork 机制（如果上游消失，能继续基于内部 fork 工作）13

这种备援不是“反美”——是常规风险管理。任何主要中国科技公司都需要回答：“如果哪天 GitHub 不可用，我们能继续工作多久？”——答案应该是“至少几个月，可能几年”，而不是“立即崩溃”。

到 2026 年，中国科技公司的实际答案大致是：

  • 已发布的开源软件：能继续使用几乎无限期（通过镜像）
  • 已有的项目继续维护：可以（迁移到 Gitee 或自托管）
  • 全球协作密度：会大幅降低（issue 讨论、PR review 等无法直接迁移）
  • 新项目国际化：会困难（吸引非中国贡献者需要全球可见性）

这种“技术上可行但协作受损”的状态是 forge 平行化的真实代价。它不是“中国会失去开源”——是“中国会失去开源的全球性”。这是个微妙但重要的差异。

九

读到这里，一个自然的问题是：真的有“假设 GitHub 不可用”的可能吗？

短期内（1-2 年）：不太可能。GitHub 作为 Microsoft 的关键资产，整体关停某个大国会引起巨大商业损失。Microsoft 不会主动做这种决定，除非被美国政府强制。

中期（3-5 年）：可能性增加。如果美中关系恶化到某种临界点，美国政府可能强制 Microsoft 对中国关停 GitHub。具体触发条件难以预测，但理论可能性存在。

长期（5-10 年）：不可避免地需要考虑。即使 GitHub 不被关停，它的“美国合规约束”会越来越紧。最近的趋势——从国家级（2019 伊朗）到实体级（2022 俄罗斯）到 maintainer 级（2024 Linux 11 人）——是不断精细化。继续这个轨迹，下一步可能是“某些类型的中国 contributor 不能 maintain 某些项目”14。

每个国家都在为“长期可能”做准备——中国 OpenAtom、欧洲 STF、俄罗斯 Decree 166。这些不是为了“明天 GitHub 关停”，是为了“长期保持选择权”。

如果一个国家完全依赖 GitHub，它在跟美国的任何谈判中都有一个隐藏的脆弱性。如果一个国家有 viable 备援，它的谈判位置更稳。这就是平行 forge 生态的真正意义——不是替代，是保险。

十

最后看一个具体场景。

假设你是一个 2026 年的开源 maintainer。你的项目托管在 GitHub。你的 contributor 来自全球——美国、欧洲、中国、俄罗斯、印度、伊朗、巴西。你想保护项目的全球协作能力——避免在某个地缘事件中被穿透。

你的选择：

1. 保持 GitHub 主仓 + 多镜像

  • 主仓在 GitHub
  • 自动镜像到 Codeberg、Gitee、GitFlic
  • 如果哪个 forge 不可用，其他镜像仍可用
  • 缺点：协作主要在 GitHub，其他镜像主要是只读

2. 迁到中立基金会

  • 把项目放到 Linux Foundation、Apache、Eclipse 等大型基金会
  • 让基金会承担合规复杂度
  • 缺点：基金会注册地仍然是某个国家（多数美国）

3. 完全去中心化

  • 用 Radicle 或类似 P2P 工具
  • 每个 contributor 在本地有完整 repo
  • 缺点：协作效率大幅降低，UX 远不如 GitHub

4. 接受单一 forge 的风险

  • 仍然只用 GitHub
  • 接受可能某天被某种合规问题影响
  • 优点：UX 最好，社区最完整

到 2026 年，绝大多数项目仍然选 4 或 1——接受 GitHub 主仓的风险，最多加个镜像。选 2 的项目主要是大型企业项目。选 3 的极少15。

这反映了开源生态的现状：虽然有 forge 平行化的备援，但全球协作密度仍然集中在 GitHub。这是因为 GitHub 的网络效应——它有最多的开发者、最完整的工具链、最成熟的 CI 集成。任何替代都要付出“远离主流”的代价。

但 forge 平行化的存在本身改变了博弈。它给了开源运动一个“如果一切糟糕，我们至少有备援”的位置。这种位置——即使从未真正切换——也影响开发者、政府、监管者的行为。GitHub 知道有替代品，所以不会任意制裁；政府知道开发者有替代，所以制裁威力有限；维护者知道有备援，所以面对压力时有更多 leverage。

十一

CHAOSS 是另一个值得提的项目。

CHAOSS（Community Health Analytics for Open Source Software）是 Linux Foundation 旗下的项目，2017 年成立。它的目标是开发开源社区健康度量——能客观衡量一个开源项目的活跃度、多样性、可持续性16。

CHAOSS 的具体指标包括：

  • contributor 数量（绝对值和按时间变化）
  • contributor 地理分布
  • bus factor（如果某个 maintainer 离开，项目能否继续）
  • issue response time
  • code review coverage
  • 漏洞修复时间

这些指标本身不直接关系到地缘政治。但 CHAOSS 让一件事变得可能：追踪开源项目的“contributor 地理分布”如何变化。

如果哪一天 Linux 内核失去所有俄籍 contributor——不只是 11 个被删除的 maintainer，而是所有 .ru contributor 都因压力撤离——CHAOSS 能定量呈现这个变化。如果 PyTorch 在 2027 年突然中国 contributor 比例下降 50%，CHAOSS 能追踪到。

这种“contributor 地理分布”在 2014 年之前几乎没人关注——开源运动的姿态是“代码无国界”，所以贡献者来自哪里不是重要数据。2024 年之后这个数据变得至关重要——它能客观呈现“主权穿透”的实际效果17。

OpenSauced 和 Sourcegraph 是另外两个做类似工作的项目。它们提供更细粒度的 contributor 追踪和分析。Sourcegraph 2023 年发布的 “State of Open Source” 报告就显示，中国 contributor 数量在 2018-2023 年增长 47%——这是开源运动地缘格局变化的具体数据点18。

十二

最后回到 Gitee。

Gitee 在 2024-2026 年继续增长——它声称用户突破 1000 万，托管的项目越来越多。但它也有挑战：

  • 在国际化方面进展有限——非中文开发者很少在 Gitee 主动找项目
  • 它的实名制让“开源参与门槛”提高（任何贡献者都需要中国实名）
  • 政治敏感内容审查让它对某些用例不友好（如海外华人维护的项目可能避免在 Gitee 托管）
  • 它的商业模式仍然不清晰（是开源中国公司业务，但具体盈利方式不透明）

这些限制不阻止 Gitee 在中国生态的功能性——它仍然是 openEuler 这种关键项目的主仓。但它们限制 Gitee 成为“全球性 GitHub 替代”。它的实际角色是“中国生态的中心 + 全球生态的补充”19。

读懂这个，能理解 forge 平行化的真实形态：它不是建立“中国的全球开源平台”，是建立“中国生态的本土备援”。同样的逻辑适用于俄罗斯 GitFlic、欧洲 Codeberg——它们都是各自生态的本土备援，不是替代 GitHub 的全球野心。

这种“区域化备援”的格局，可能就是开源未来 10-20 年的实际状态。不是统一的全球生态，也不是完全断裂的多个生态——是一个由 GitHub 主导但有多个区域备援的格局。每个区域有自己的合规框架、用户基础、维护激励。GitHub 仍然是全球协作的中心，但越来越多的“主权敏感”工作通过区域 forge 完成。

下一章我们要看的是开源最新的一层——AI 模型权重。它带来了一个全新维度：不是源代码、不是 forge、不是 maintainer——而是数十亿个数字。这层的国家化已经开始，而它的逻辑跟传统开源很不一样。

References

  1. Gitee 官方页面 (https://gitee.com)。2024 年公开统计宣称 1000 万开发者。

  2. 关于中国开发者实际 GitHub vs Gitee 使用模式的多份社区调查。

  3. 《中华人民共和国网络安全法》、《数据安全法》、《个人信息保护法》对中国境内互联网平台的要求。

  4. GitFlic 官方页面与 2022-2024 用户增长报道。

  5. 俄罗斯 Decree 166（2022-03-30）描述。包括关键信息基础设施迁移本土软件要求。

  6. Codeberg.org 官方页面。德国 Codeberg e.V. 非营利。基于 Forgejo。

  7. Refine: GitHub Alternatives Worth Trying in 2026. 包括 Forgejo 从 Gitea fork 的描述。Link →

  8. Radicle.xyz 官方页面。P2P 代码协作描述。

  9. GitHub 用户规模公开统计。

  10. 中国主要镜像站：USTC mirror (mirrors.ustc.edu.cn)、Tsinghua mirror (mirrors.tuna.tsinghua.edu.cn)、阿里云镜像 (mirrors.aliyun.com)、华为云镜像 (mirrors.huaweicloud.com) 等。

  11. 俄罗斯主要镜像基础设施：Yandex、Mail.ru 等服务。

  12. 2022-2024 俄罗斯企业迁移到自托管 GitLab / GitFlic 的多家媒体报道。

  13. 多家中国大公司（华为、阿里、腾讯）的内部基础设施备援报道。

  14. 对未来 GitHub 制裁可能扩展方向的 OpenSSF、CSIS 等智库分析。

  15. 开发者实际选择数据：2024 GitHub Octoverse 报告等。

  16. CHAOSS Community Health Analytics for Open Source Software project. Link →

  17. 多份 contributor geographic distribution 研究：Sourcegraph、OpenSauced、CHAOSS 等。

  18. Sourcegraph 2023 “State of Open Source” 报告。中国 contributor 增长 47% 数据。

  19. Gitee 商业模式与挑战的多份行业分析。

  20. European GitHub Alternatives: Code Hosting with Privacy, Control, and Data Sovereignty. Link →

  21. Forgejo project page 与 Codeberg.org 维护信息。

  22. HowToGeek: “These 4 GitHub alternatives are just as good—or better”. 综合 GitHub 替代品评估。

  23. Best Open Source GitHub Alternatives 2026 — OSSAlt Guides. Link →

  24. OpenSauced.pizza 开源贡献追踪平台。

  25. 关于 forge 平行化对全球协作影响的多份学术研究与行业分析。