5.2萬Star項目被迫出走GitHub，但開源世界只剩更差的選擇

作者｜冬梅

結束 18 年熱愛，
Ghostty 逃離 GitHub

“有些告別，并不是因為不再熱愛，而是因為再也無法繼續留下。”

這是 Ghostty 項目創始人 Mitchell Hashimoto 在宣布項目即將逃離 GitHub 時寫下的開頭。整篇長文沒有技術細節的鋪陳，反而像一封寫給過去 18 年的“告別信”，甚至，他在寫這封“告別信”時是哭著寫完的！

Mitchell Hashimoto 出生于 1990 年，是一位典型的“從開源社區成長起來”的工程師。

20 歲出頭時，他就因創建 Vagrant 而在開發者圈子中嶄露頭角。Vagrant 解決的是開發環境一致性的問題——在容器和云原生尚未普及的年代，它幾乎是團隊協作開發的“標配工具”。

這一項目不僅讓他一舉成名，也成為后來一整套基礎設施工具體系的起點。

2012 年，他與聯合創始人一起創立了 HashiCorp。這家公司后來成為 DevOps 工具鏈中不可忽視的一極，推出了一系列廣泛使用的基礎設施軟件，包括：

• Terraform：定義并管理云資源的事實標準之一

• Consul：服務發現與服務網格基礎組件

• Vault：安全密鑰與憑證管理

• Nomad：輕量級調度與編排系統

這些工具的共同特點是：將復雜的基礎設施操作抽象為可編程、可復用的工作流，本質上推動了“Infrastructure as Code（基礎設施即代碼）”這一范式的普及。

在商業層面，HashiCorp 也一路成長為一家上市公司，成為少數從純開源社區成功走向企業級商業化的軟件公司之一。

但相比“企業家”身份，Mitchell Hashimoto 更被開發者社區認可的，仍然是“工程師”和“開源作者”。

他長期活躍在開源一線，親自維護項目、參與社區討論，并保持極高的技術輸出頻率。在很多人眼中，他代表的是一類典型的技術人路徑：通過開源項目建立聲譽，通過工具改變行業，再通過公司將其規模化。

也正因為這種背景，他對 GitHub 的情感才顯得格外特殊——他不是簡單的“平臺用戶”，而是那一代真正在 GitHub 上完成自我實現的人：從發布項目、積累影響力，到建立公司、影響行業路徑，幾乎全部發生在這個平臺之上。

Mitchell 在這封與 Github 的告別信中寫道：

寫下這些讓我感到一種不理性的悲傷，但 Ghostty 將離開 GitHub。

我是 GitHub 用戶 1299，注冊于 2008 年 2 月。

從那以后，我幾乎每天都會打開 GitHub。每天，多次，持續了超過 18 年。這占據了我人生的一半以上。中間或許有極少數例外（我甚至很想看看數據），但我很難想象一年中有哪一周完全沒有打開過它。”

GitHub 是讓我最快樂的地方。我總會為它留出時間。經歷糟糕的分手時，我把自己丟進開源世界……在 GitHub。大學凌晨四點，所有人都睡著的時候，我再提交一次 commit。甚至在蜜月期間，當妻子還在睡覺時，我都在逛 GitHub。這是我一直以來最快樂、也最想待的地方。

有些人會無意義地刷新社交媒體，而我在這個“刷屏”出現之前，就已經在 GitHub 的 issue 里“刷屏”了。度假時，我會收藏一堆 GitHub 項目，去研究它們。不只是代碼，還有開源社區的運作方式、維護者如何處理棘手問題……說真的，我喜歡這些。

也許有人會覺得這不太正常，但我的愛好、工作和熱情恰好完全重合，而在我人生的大部分時間里，它們都存在于互聯網的同一個地方：GitHub。

我創建 Vagrant（我第一個成功的開源項目），很大程度上是因為我希望它能幫我拿到 GitHub 的工作機會。這個我從不避諱——我在 20 歲第一次公開演講時就開玩笑說：‘如果這個項目做得夠好，也許 GitHub 會雇我。’

GitHub 曾是我的夢中工作。我最終沒能在那里工作（這不是他們的錯）。但那是我最想去的地方。那里的工程師令人驚嘆，產品令人驚嘆，而它也是我每天呼吸、生活的一部分。18 年，一整個人從出生到成年所需的時間，我都在 GitHub 上度過。

但這封“告別信”，在后半段急轉直下。

最近，我一直在公開批評 GitHub。我說了很多難聽的話，我很憤怒，也傷害了一些人。我在發泄。因為 GitHub 每一天都在讓我失望，這對我來說是件非常私人的事情。也許這種情緒不理性，但我確實把 GitHub 愛得太深了，所以我對它生氣。我為傷害到那些仍在努力工作的人感到抱歉。

這種感覺已經持續很久了。過去一個月，我甚至開始做一件事：每天記錄一次——如果 GitHub 的故障影響了我的工作，我就在那一天畫一個 ‘X’。幾乎每天都有 ‘X’。

就在我寫這篇文章的今天，我已經有大約兩個小時無法進行 PR 審查，因為 GitHub Actions 出現了故障。這已經不再是一個可以認真工作的地方了——如果它每天都要讓你停擺幾個小時。

這里不再讓我感到快樂。我想留下，但它似乎不再需要我。我想完成工作，但它不讓我完成。我想發布軟件，但它不讓我發布。

我希望它變得更好。但我也想寫代碼。而現在，我無法在 GitHub 上寫代碼了。抱歉。18 年之后，我必須離開。

也許有一天我會回來。但前提必須是真正的改變與結果，而不是承諾。

至于 Ghostty 項目最終會遷移去哪里，Mitchell 沒有明確的回應，但他在一則 X 評論中提及，正在努力尋找一個統一的解決方案，但現在還來得及調整方向。

Mitchell 的其他獨立項目將繼續托管于 GitHub 平臺。本次轉移僅涉及 Ghostty 項目，該項目是近期服務中斷事件中受影響最嚴重的，不僅對 Mitchell 本人造成困擾，也給項目維護者及社區用戶帶來了不便。

創始人的哭訴，引發社區共鳴

然而，這些都還不是這場情緒的全部。

在 Hacker News 上，這位創始人隨后補充的一段評論，讓這次“逃離”顯得更加真實，也更加讓人動容：

我知道這聽起來很夸張，但這是事實：我寫這篇博客文章的時候，真的哭了。（眼淚都滴到鍵盤上了，說出來確實挺丟人的。）

他補充說道：“沒有人應該為一個 SaaS 產品而哭。但 GitHub 對我來說遠不止如此（這些我在文章里都寫了）。我對它有一種不太健康的情感依附。它給了我太多，我對此心懷感激。但它已經不再是從前的樣子了……我也說不清。

我們斷斷續續討論了幾個月，幾周前開始認真討論，幾天前才真正做出決定。當我把這些寫下來，按下‘發布’按鈕的時候，一切都變得真實了。我知道大家會覺得這很可笑。這確實很蠢。但我真的很喜歡 GitHub，也真心希望它能找到出路。”

Mitchell 這段“帶著眼淚的控訴”，迅速點燃了評論區。

一位同樣早期加入 GitHub、并且自稱現在仍然是 GitHub 員工的用戶這樣回應：

“我也是老用戶——22723 號。某種意義上，我們是同一代人（畢竟現在 GitHub 已經有將近 1.8 億用戶了）。但我對這件事的理解有點不同：只有那些真正關心 GitHub、愿意留下來把它變好的人留下，GitHub 才會變好。”

但他對 GitHub 的態度卻截然不同，他表示自己不會離開：

“正因為它對我來說太重要了，我反而無法離開。而且，我不是唯一有這種感覺的人。”

該用戶還表示這種轉變不能完全歸罪于 AI 或者微軟，而是技術基礎正在發生變化。

“過去幾年，GitHub 經歷了一次根本性的范式轉變（智能體編碼）以及爆發式增長。問題并不只是 AI，也不只是微軟。用奧卡姆剃刀來看，更簡單的解釋是：規模，以及我們腳下整個技術基礎正在發生變化。我希望我們還能做點什么，讓你有一天愿意回來。我希望還能重新點燃你曾經的那種快樂。對開發者來說，這些情緒一點都不愚蠢。”

還有很多 Hacker News 用戶表達了與 這位 GitHub 內部員工不同的觀點。

這部分開發者群體對 GitHub 現狀有一種幻滅感：當一個平臺變得“大而不能倒”時，用戶的熱愛與反饋往往會撞上一堵冰冷的制度高墻。

有用戶指出，“那句‘只有真正關心 GitHub 的人留下來，它才會變好’，其實是個極具誤導性的陷阱。這話對微軟內部的開發者可能成立，但對普通用戶來說完全是謊言。作為一個用戶，如果你只是像往常一樣繼續使用它，根本沒有任何途徑能讓它變得更好。”

另一位用戶同意上述觀點。他寫道：

“我深有同感。時間已經給出了答案：即使用戶們滿懷熱忱地留下來，試圖‘改進’這個平臺，結果看到的卻是 GitHub 體驗的一路劣化。這種劣化并沒有因為用戶的堅持而停止。”

更有用戶反饋，用戶的耐心換來的是長達數年的反饋石沉大海。

“確實如此。早在 2018 年，我就投入了大量精力向官方報告‘壓縮合并（squash &;n' merge）’中的元數據重寫錯誤，并持續推動修復。期間雖然有一兩個內部員工表現出興趣，但隨后便杳無音信。多年過去了，這個 Bug 依然在那。現在，我對 GitHub 修復基本功能的任何期望都已徹底崩塌，只剩下滿心的諷刺與失望。”

面對開發者群體對 Github 的失望情緒，這位 GitHub 員工在評論區繼續輸出，他認為：GitHub 不會被替代，GitHub 最有可能擁有光明的未來，而實現它的最佳途徑，是從內部改進它。他寫道：

就像 Mastodon 未能取代崩潰后的 Twitter 一樣，我并不認為 GitHub 的替代平臺會成為主流。盡管未來可能會出現更多類似 Codeberg 這樣的 GitHub 類平臺，或者部分項目會轉向 Tangled 和 Forgejo 這樣的新型代碼托管工具，但要說服數百萬 GitHub 用戶遷移到更為復雜的平臺，仍然令人難以置信——這就像‘20XX 年會是 Linux 桌面元年’一樣不現實。

我認為，GitHub 最有可能擁有光明的未來，而實現它的最佳途徑，恰恰是從內部改進它。我選擇加入這里，正是因為我希望從內部推動 GitHub 變得更好。因此，我才提到‘我希望我們的努力，能讓你們有一天愿意回來’。我深信這個可能，所以我選擇留下，為此付出努力。就像 Mitchell 曾堅守 GitHub 的理想那樣，我也珍視那份愿景。他已經決定離開，而我還沒有——這無關對錯，只是個人選擇的不同。

Mitchell 的文字在 Reddit 上同樣引發了強烈共鳴。

尤其是在 Reddit 等社區中，圍繞“Ghostty 是否應該逃離 GitHub”的討論迅速發酵，評論區幾乎變成了一場集體回憶錄：有人談起自己第一次提交 pull request 的緊張，有人回憶當年追著 issue 學習編程的日子，也有人開始質疑——那個曾經承載開源精神的 GitHub，是否正在變成一個“基礎設施優先”的商業平臺。

某種程度上，這并不只是一個項目遷移的決定。

對一代技術人而言，GitHub 曾經不僅是工具，更像是一種精神空間：代碼、協作、聲譽、學習路徑，甚至職業命運，都在這里交匯。

它既是“代碼托管平臺”，也是“技術烏托邦”的象征——一個你只需要寫好代碼，就能被世界看見的地方。

而如今，當一個從 2008 年就扎根其中的老用戶，用“18 年”“每天多次打開”“人生一半時間”來描述自己的關系，并最終選擇離開時，這種情緒很難被簡單歸類為“產品體驗不佳”。

它更像是一種時代錯位。

當平臺規模不斷擴大、功能不斷疊加、商業邏輯持續強化時，那種最初的、近乎純粹的開源體驗正在被稀釋。穩定性問題只是導火索，真正被觸動的，是開發者對“歸屬感”的失落。

有人在評論里扎心地寫道：“我們不是在討論 GitHub 好不好用，而是在討論，我們曾經相信的那個地方，還在不在。”

以人為中心的開發體驗，
還能被保留下來嗎？

2018 年，Microsoft 以 75 億美元收購了 GitHub。

當時給出的承諾很簡單：讓 GitHub 更好地服務開發者，而不是改變它。

在最初幾年，這個承諾基本兌現了。

2019 年，GitHub 正式推出了 GitHub Actions，將 CI/CD 能力直接嵌入代碼倉庫，開發者無需再依賴外部工具鏈。這一發布被普遍視為 GitHub 平臺能力的重要躍遷。

從產品演進來看，那是一個“工程效率優先”的階段：圍繞代碼托管本身不斷增強基礎設施能力，讓開發流程更順滑、更自動化。

但此后情況發生了改變。

2021 年，在以 ChatGPT 為代表的大語言模型爆發后，GitHub 與 OpenAI 合作推出了 GitHub Copilot。逐漸地，Copilot 從輔助工具發展到了微軟戰略核心位置上。

最初，Copilot 被定義為“AI 結對編程助手”，用于代碼補全與建議。但很快，它的定位發生了變化。

Copilot 不再只是一個功能，而成為微軟 AI 戰略的重要入口之一。圍繞它的商業模式也迅速成型：個人版每月 10 美元，團隊版 19 美元，企業版 39 美元——這是 GitHub 歷史上最清晰、最直接的訂閱收入來源之一。

隨后幾年，圍繞 Copilot 的產品演進明顯加速，并呈現出一個清晰方向：從“輔助寫代碼”走向“替你完成開發流程”。

2024 年，GitHub 發布了 Copilot Workspace，允許 AI 從 issue 出發，理解需求、生成代碼并直接創建 Pull Request。

到 2025 年，GitHub 進一步推出 Agent 模式（Copilot Agents），將這一能力推進到“端到端自動化開發”的階段：AI 可以從需求理解、代碼生成到提交 PR 完整執行一條鏈路。

從產品路徑來看，這是一條非常一致的技術路線：從代碼補全 → 任務理解 → 自動生成 → 自主執行，GitHub 正在從“代碼托管平臺”，轉向“AI 驅動的軟件生產系統”。

但與此同時，另一條曲線開始浮現。

開發者社區的反饋逐漸出現分化，尤其集中在基礎設施層面——最典型的，就是 GitHub Actions。

用戶開始對 GitHub Actions 的穩定性表示失望，失望的原因有很多，包括構建排隊時間顯著增加、Runner 隨機失敗、緩存命中率不穩定、日志丟失或加載緩慢等等。

GitHub 官方狀態頁面也在一定程度上反映了這種壓力：

盡管這些問題并不意味著系統“不可用”，但對于依賴 CI/CD 的團隊而言，穩定性波動本身就是生產力損耗。

而在 Ghostty 創始人的那篇長文中，這種“體感”第一次被具象化——通過“每天打一個 X”的方式，記錄 GitHub 故障對工作的實際影響。

如果把這兩條曲線疊加在一起，一個更值得討論的問題就出現了：GitHub 是否真的“變差了”？還是說，它只是把重心轉移了？

從企業資源配置的邏輯來看，答案傾向于后者。

Copilot 作為明確的收入來源，契合微軟以 AI 為核心的戰略，開發者工具正是其關鍵落地場景。相比之下，Actions 等基礎設施更偏向“成本中心”，其目標往往是“穩定可用”而非“追求突破”。當一個平臺將最優秀的工程資源和戰略優先級傾注于 AI 產品時，原有基礎設施滑向“足夠好”的狀態，幾乎是一種必然。這不是 GitHub 獨有的問題，而是許多平臺在戰略轉型期都會面臨的結構性張力。

更深層的變化在于，AI 正在重塑 GitHub 的底層負載模型。過去，平臺的系統負載是基于“人類開發節奏”設計的：人工寫代碼、提交 PR、觸發 CI 構建，這是一個相對穩定、可預測的流程。

但隨著 GitHub Copilot、Claude Code、Cursor 等 AI 編程工具的普及，開發行為發生了根本變化：單個開發者的代碼產出量和提交頻率大幅提升，自動化測試的觸發次數呈倍數增長。尤其在 AI Agent 模式下，一個簡單需求就可能引發多輪自動迭代，這使得 CI 負載不再與“開發者數量”線性相關，而是與“AI 迭代次數”掛鉤，形成了一種指數級增長的壓力模型。

而 GitHub 的基礎設施，最初并非為此類模式設計。

這導致了一種頗具“黑色幽默”的現實：GitHub 正全力推動 AI 編程，鼓勵開發者更高效地產出代碼，但 AI 生成代碼所帶來的海量工作流，卻在反向對平臺自身的基礎設施構成持續的壓力放大。

真正的問題或許不在于這種變化是對是錯，而在于：在這個被 AI 加速的世界里，曾經那種緩慢、穩定、以人為中心的開發體驗，還能否被保留下來。

GitHub 之外，開源只剩更差選擇

即便 GitHub 廣受爭議，但是當人們開始審視 GitHub 之外的選項時，很快會發現，每一種路徑都對應著一種妥協。

從產品能力看，GitLab 是最接近 GitHub 的平臺：完整 DevOps 生命周期、CI/CD、權限管理、企業級能力一應俱全。

但問題在于，它的兩種路徑都不理想：

SaaS：價格直接勸退：GitLab Premium 定價約 $29/ 用戶 / 月，明顯高于 GitHub Team。對于一個 10 人團隊，每月成本可達 $145–290，美式企業軟件定價邏輯非常明顯。

自托管：隱藏成本遠高于預期。理論上，GitLab CE（開源版）可以自托管，聽起來是“自由”的解決方案。但現實是：算上基礎設施、運維成本后，一個 20～50 人的團隊，總成本差不多要在 2000 美元 / 月，總結起來就一個字：貴。

因此有 Reddit 用戶吐槽說 GitLab 托管費高得離譜。

如果說 GitLab 是“企業級替代”，那么 Codeberg 更像是“理念驅動型替代”。

它的優勢明確：非營利組織運營、不做數據收集、不做 AI 訓練并且完全免費（靠捐贈）， 這也是為什么一些項目開始遷移。例如：Zig 語言已經從 GitHub 遷移到 Codeberg，理由包括性能問題和 CI 不穩定。

但 Codeberg 的問題同樣明顯：定位只服務開源。它重點強調 FOSS（自由開源軟件），商業閉源項目并不適配 。

Reddit 用戶總結得很直白：它的靈活性太低了。

此外，Codeberg 能力與生態不足：CI/CD 依賴外部工具（如 Woodpecker）、插件生態幾乎不存在、社區規模遠小于 GitHub。

另一類替代方案是：Gitea 和 Forgejo。特點很簡單：可以擁有完全控制權，但是必須承擔全部復雜度。包括：CI/CD 自建、權限系統維護、備份與災備以及安全更新等，這些工具本質不是平臺，而是“基礎組件”。

可以這樣說，開源世界并非沒有選擇，而是所有替代路徑都伴隨著清晰且不可回避的代價。

https://news.ycombinator.com/item?id=47939579

https://mitchellh.com/writing/ghostty-leaving-github

https://www.xda-developers.com/ghostty-ditching-github-over-chronic-reliability-failures/

https://www.reddit.com/r/programming/comments/1sye8fc/ghostty_is_leaving_github/

https://www.mymcpshelf.com/blog/best-github-alternatives/?utm_source=chatgpt.com

https://www.reddit.com/r/opensource/comments/1qmiv56/for_those_who_use_github_to_host_their_projects/?utm_source=chatgpt.com

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。