GitHub 是否正在沉沒？AI Slop 的興起與去中心化 的必要性

GitHub 是否正在沉沒？AI Slop 的興起與去中心化的必要性

十多年來，GitHub 一直是開源宇宙中無庸置疑的核心。它改變了我們協作的方式，將 Git 從一個技術工具轉變為開發者的社交網絡。然而，越來越多工程師警告說，該平台正在「沉沒」，理由是可靠性下降、AI 生成的「slop」大量湧入，以及其母公司 Microsoft 的窒息式影響。

曾經是一個精簡的代碼託管工具，現在卻越來越被視為一個臃腫的負擔。隨著穩定性動搖，且平台充斥著低質量的 AI 生成提交，開發者們開始提出一個根本性的問題：現在是離開的時候了嗎？

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 億次提交，到每年大約 140 億次的節奏。
  • CI/CD Load: GitHub Actions 從 2023 年每週 5 億分鐘，增長到最近每週超過 21 億分鐘。

這種激增主要是由 AI agents 和自動化工具驅動的，它們提交代碼的數量是人類無法比擬的。其結果是「slop 墳場」——大量低質量的 repositories 和 commits，這不僅使基礎設施承壓，也稀釋了平台發現機制的價值。正如一位評論者所言，該平台實際上是在「用 slop 對自己進行 DDoS 攻擊」。

Git is Not GitHub

Git 不等於 GitHub

現代軟體工程中最危險的誤解之一就是將 Git 與 GitHub 混淆。Git 是一種分佈式版本控制系統；它不需要中央伺服器即可運作。GitHub 僅僅是一個在 Git 之上添加了社交和協作層的託管服務。

目前對 GitHub 的挫折感正提醒著我們，「網絡效應」——即你必須留在一個平台，因為其他人都那裡——可能會變成一個陷阱。當一個平台變成「昂貴的負擔」時，留在該平台的成本最終可能會超過網絡的收益。

Evaluating the Lifeboats: Alternatives to GitHub

評估救生艇：GitHub 的替代方案

對於那些尋求遷移的用戶，選項從其他中心化 forge 到完全的自託管解決方案。

Centralized Alternatives

中心化替代方案

  • Codeberg: 一個非營利、社區驅動的 Forgejo 實例。對於想要避免企業所有權的人來說，它被廣泛認為是最安全、最可持續的替代方案。

  • GitLab: 「企業級」選擇。雖然功能強大且功能豐富，但它常被批評為臃腫且複雜，儘管它仍然是大型企業團隊的穩定選擇。

  • Bitbucket: 一個企業級替代方案，儘管通常被視為只是將一個企業環境換成另一個企業環境。

Self-Hosting and Decentralization

自託管與去中心化

對於追求完全控制權的人來說，自託管一個 Git forge 是終極的退出策略。Forgejo (a fork of Gitea) 經常被推薦，因為其輕量級的特性以及處理 actions 和 releases 的能力。

一些開發者甚至在倡導回歸「舊方法」——通過 SSH 和電子郵件列表來管理項目。正如原批評文章的作者所指點出的：

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

"如果 Linux 可以通過向電子郵件列表發送 patch，那麼『無法在大規模應用中運作』的論點就是技術能力問題。"

Conclusion: The Need for an Exit Plan

結論：需要一個退出計劃

無論 GitHub 是否真的在「沉沒」，或者只是在努力應對 AI 革命帶來的規模擴展，目前的氣候突顯了極端中心化帶來的風險。當全球開源代碼的主要基礎設施被單一實體控制時，任何質量或穩定性的下降都成為整個行業的系統性風險。

無論你在哪裡託管你的代碼，教訓是明確的：始終準備好一個退出計劃。無論是將你的 repositories 鏡像到第二個服務，或是維護一個自託管的備份，確保你的代碼不被鎖定在單一的「沉沒的船隻」上，是長期項目健康發展的先決條件。

Sources