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

作者｜冬梅

結束 18 年熱愛，
Ghostty 逃離 GitHub

“有些告別，并不是因為不再熱愛，而是因為再也無法繼續(xù)留下?！?/p>

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

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

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

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

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

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

• Consul：服務發(fā)現(xiàn)與服務網(wǎng)格基礎組件

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

• Nomad：輕量級調(diào)度與編排系統(tǒng)

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

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

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

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

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

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

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

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

從那以后，我?guī)缀趺刻於紩蜷_ GitHub。每天，多次，持續(xù)了超過 18 年。這占據(jù)了我人生的一半以上。中間或許有極少數(shù)例外（我甚至很想看看數(shù)據(jù)），但我很難想象一年中有哪一周完全沒有打開過它?！?/p>

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

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

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

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

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

但這封“告別信”，在后半段急轉(zhuǎn)直下。

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

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

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

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

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

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

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

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

創(chuàng)始人的哭訴，引發(fā)社區(qū)共鳴

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

它更像是一種時代錯位。

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

有人在評論里扎心地寫道：“我們不是在討論 GitHub 好不好用，而是在討論，我們曾經(jīng)相信的那個地方，還在不在?！?/p>

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

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

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

在最初幾年，這個承諾基本兌現(xiàn)了。

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

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

但此后情況發(fā)生了改變。

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

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

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

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

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

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

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

但與此同時，另一條曲線開始浮現(xiàn)。

開發(fā)者社區(qū)的反饋逐漸出現(xiàn)分化，尤其集中在基礎設施層面——最典型的，就是 GitHub Actions。

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

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

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

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

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

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

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

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

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

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

這導致了一種頗具“黑色幽默”的現(xiàn)實：GitHub 正全力推動 AI 編程，鼓勵開發(fā)者更高效地產(chǎn)出代碼，但 AI 生成代碼所帶來的海量工作流，卻在反向?qū)ζ脚_自身的基礎設施構成持續(xù)的壓力放大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 整理，不代表平臺觀點，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

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

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

誠摯邀請你登臺分享實戰(zhàn)經(jīng)驗。AICon 2026，期待與你同行。