GitHub 是否正在沉没？AI Slop 的兴起与去中心化的必要性

十多年来，GitHub 一直是开源宇宙中无可争议的中心。它改变了我们协作的方式，将 Git 从一个技术工具转变为开发者的社交网络。然而，越来越多的工程师开始警告，该平台正在“沉没”，理由是可靠性下降、AI 生成的“slop”（低质量内容）泛滥，以及其母公司 Microsoft 的窒息式影响。

曾经作为托管代码的精简工具，现在越来越多地被视为一种臃肿的负担。随着稳定性的动摇和平台被低质量、AI 生成的提交（commits）所淹没，开发者们开始问一个根本性的问题：是时候离开了吗？

The Stability Crisis: "Zero Nines" of Uptime

稳定性危机："Zero Nines" 的在线率

最近的观察表明，GitHub 的官方状态页面可能并未反映全貌。用户报告称，停机时间增加且性能下降，一些人指出自 Microsoft 收购以来，平均在线率呈下降趋势。体验不再是无缝的；相反，它表现为次级速率限制（secondary rate limits）和在关键部署窗口期间发生的意外停机。

这种不稳定性不仅仅是便利性的问题。对于依赖 GitHub Actions 进行 CI/CD 流水的团队来说，平台停机意味着生产环境的全面停滞。批评者认为，GitHub Actions 已成为“最薄弱的环节”，创造了一个中心化的单点故障，使得组织危险地依赖于单一供应商的在线率。

The "AI Slop" Problem

"AI Slop" 问题

虽然有些人将 GitHub 的困境归因于一般的企业管理不善，但其他人则指向了一个更具体的罪魁祸首：AI 生成代码的爆炸式增长。这种增长规模是惊人的。根据 GitHub 自身领导层引用的数据，平台活动量呈指数级激增：

• Commits: 从 2025 年的 10 亿次 commits 到每年约 140 亿次的节奏。
• CI/CD Load: GitHub Actions 从 2023 年每周 5 亿分钟增长到最近的每周超过 21 亿分钟。

这种激增很大程度上是由 AI agents 和自动化工具驱动的，它们提交代码的量级是人类无法企及的。其结果是形成了一个“slop graveyard”（低质量内容坟场）——大量低质量的仓库（repositories）和 commits 淹没平台，使基础设施承压，并稀释了平台发现机制的价值。正如一位评论者所言，该平台实际上是在“用 slop 进行自我 DDoS”。

Git is Not GitHub

Git 不等于 GitHub

现代软件工程中最危险的误解之一是将 Git 与 GitHub 混为一谈。Git 是一个分布式版本控制系统；它不需要中央服务器即可运行。GitHub 只是一个在 Git 之上增加了社交和协作层的托管服务。

目前对 GitHub 的挫败感提醒了人们，“网络效应”（network effect）——即因为其他人都在那里，所以你也必须留在该乎平台——可能会变成一个陷阱。当一个平台变成“昂贵的负担”时，留在该平台上的成本最终可能会超过网络带来的收益。

Evaluating the Lifeboats: Alternatives to GitHub

评估“救生艇”：GitHub 的替代方案

对于那些寻求迁移的开发者，选项从其他中心化平台到完全自托管解决方案都有。

Centralized Alternatives

中心化替代方案

• Codeberg: 一个非营利、社区驱动的 Forgejo 实例。对于想要避免企业所有权的人来说，它被广泛认为是安全、最可持续的替代方案。
• GitLab: “企业级”选择。虽然功能强大且功能丰富，但它经常因臃肿和复杂而受到批评，尽管它仍然是大型企业团队的稳定选择。
• Bitbucket: 一个企业级替代方案，尽管通常被视为只是将一个企业环境换成另一个。

Self-Hosting and Decentralization

自托管与去中心化

对于寻求完全控制权的人来说，自托管一个 Git forge 是终极的退出策略。Forgejo（Gitea 的一个 fork）经常因其轻量级特性以及处理 actions 和 releases 的能力而被推荐。

一些开发者甚至在倡导回归“旧方法”——通过 SSH 和 email mailing lists 管理项目。正如原批评文章的作者指出：

"If Linux can be maintained by sending patches to an email mailing list, 'doesn't work at scale' "doesn't work at scale' arguments are skill issues."

"如果 Linux 可以通过向 email mailing lists 发送补丁来维护，那么‘无法在大规模下工作’的论点不过是技术能力问题。"

Conclusion: The Need for An Exit Plan

结论：需要一个退出计划

无论 GitHub 是否真的在“沉没”，或者仅仅是在努力应对 AI 革命带来的规模扩张，当前的气候都凸显了极端中心化的风险。当全球开源代码的主要基础设施被单一实体控制时，任何质量或稳定性的下降都将成为整个行业的系统性风险。

无论你在哪里托管你的代码，教训是显出的的：始终准备一个退出计划。无论是将你的 repositories 镜像到第二个服务，或者维护一个自托管的备份，确保你的代码不会被锁定在单一的“沉没的船只”上，是项目长期健康发展的先决条件。