Ruby 社群的分水嶺：一場企業控制與開源精神的戰爭
最近 Ruby 社群風風雨雨，由於我不太了解 Ruby 生態圈，於是就請 Claude 整理了一下背景知識和前因後果，生成了以下的故事。
在程式設計的世界裡，很少有故事能像 2025 年 9 月的 Ruby 社群事件一樣，如此鮮明地展現出企業利益與開源理想之間的深刻矛盾。對於不熟悉 Ruby 的工程師來說，這個故事其實可能發生在任何程式語言生態系統中——想像一下如果 npm、pip 或 Composer 的控制權突然被企業接管，會發生什麼事情。
序幕：繁榮背後的隱憂
Ruby 這個優雅的程式語言，自 1995 年由日本人松本行弘創造以來，一直以「讓程式設計師快樂」為核心理念。2004 年，一個名叫 David Heinemeier Hansson（DHH）的丹麥年輕人，用 Ruby 開發了一個革命性的網頁框架 Ruby on Rails，從此改變了整個網路開發的面貌。
Rails 的成功是驚人的。GitHub、Shopify、Airbnb、Square、Coinbase、Zendesk——這些今天我們熟知的網路巨頭，都建構在 Rails 之上。DHH 也因此成為了程式設計界的明星人物：他不僅是技術創新者，還是暢銷書作者、賽車手、創業家，甚至坐上了 Shopify 的董事會。
但 Ruby 世界的運作遠比表面看起來複雜。就像 JavaScript 開發者依賴 npm 來管理套件、Python 開發者使用 pip 一樣，Ruby 開發者的日常工作離不開一套精密的工具鏈。RubyGems 是 Ruby 的套件管理系統，每個可重複使用的程式碼包被稱為一個「gem」。Bundler 則是相依套件管理工具，就像 JavaScript 的 package.json 配合 npm install，用來管理專案中使用哪些 gems 的哪些版本。而 RubyGems.org 則是全球 Ruby 套件的中央倉庫網站，相當於 npmjs.com 或 PyPI.org，所有的 gems 都發布在這裡供人下載。
這套看似簡單的基礎設施，每天處理著數億次的套件下載，支撐著全球無數的 Ruby 應用程式。但在這個光鮮的表面之下，Ruby 世界的權力結構正在悄悄發生變化。
第一章：權力的集中
DHH 的影響力遠超過一般的開源專案創始人。他不僅持有 Rails 的商標，還在 2022 年創立了 Rails Foundation 並擔任主席。更重要的是，他與 Shopify 的關係讓他擁有了巨大的企業影響力。在 12 名 Rails 核心開發成員中，接近一半直接受僱於 DHH 的公司 37signals 或者 Shopify。這種權力集中程度在開源世界是很罕見的，就如同一個人同時控制了技術標準、組織治理、企業資源和人事任命。
與此同時，Ruby 生態系統的基礎設施由一群默默無聞但極其重要的維護者們支撐著。其中最關鍵的人物是 André Arko，一個從 2010 年開始就投入了 15 年生命來維護 Bundler 的開發者。他見證了 Bundler 從早期的原型發展成今天 Ruby 開發者每天都要使用的工具。另一位重要人物是 Ellen Dash，這個從 13 歲就開始參與 Ruby 社群、維護 RubyGems 超過 10 年的女性工程師。
這些維護者們的工作是無償的，他們為了社群的理想而奉獻著自己的時間和精力。但是，營運這些服務需要資金。RubyGems.org 每天處理數億次下載，需要大量的伺服器、頻寬和人力維護。而這些資金主要來自企業贊助，這就為後來的衝突埋下了種子。
在開源世界裡，通常有一些非營利組織負責管理重要的基礎設施。在 Ruby 世界裡，這個組織叫做 Ruby Central，就像 Python Software Foundation 或 Node.js Foundation 一樣。Ruby Central 的主要工作包括舉辦 RubyConf、RailsConf 等重要會議，維護 RubyGems.org 的伺服器和基礎設施，以及支持 Ruby 社群發展。
但這裡有個關鍵的區別需要理解：營運服務和擁有程式碼是兩回事。Ruby Central 營運 RubyGems.org 這個網站，提供伺服器、頻寬、維護，但 RubyGems 和 Bundler 的原始程式碼是由社群維護者們開發和擁有的。就像某個公司可能營運一個 Git 伺服器，但託管在上面的開源專案程式碼仍然屬於原作者。這個概念上的區別，在後續的衝突中變得至關重要。
第二章：資金依賴的危險遊戲
2015 年，André Arko 意識到 Bundler 和 RubyGems 缺乏穩定的資金來源，於是創立了 Ruby Together，這是一個專門募資來支付維護者薪水的組織。就像是一個眾籌平台，但專門用來資助開源基礎設施。Ruby Together 從不要求任何形式的治理或控制權，維護者們在 RubyGems 和 Bundler 的 GitHub 組織中做他們的事，而 Ruby Together 的員工和董事會成員則在 rubytogether GitHub 組織中做他們的事。
2021 年，Ruby Together 與 Ruby Central 合併，目標是整合資源。雙方簽署了詳細的合併協議，其中明確規定新的 Ruby Central 必須「賦權專案用戶和維護者決定專案的最佳方向」、「給控制權給社群」、「對社群負責和透明」、「建立協作、正面的專案空間」。這份合併協議的核心精神很清楚：這一切都是為了 Ruby 社群。沒有社群，這項工作就沒有意義，也不可能完成。
與此同時，Shopify 這個建構在 Rails 上的電商巨頭，正在成為 Ruby 世界最大的企業用戶之一。他們雇用了許多 Ruby 和 Rails 開發者，為開源專案貢獻程式碼，也提供大量的資金支持。更微妙的是，DHH 坐在 Shopify 的董事會上，這創造了一個複雜的利益關係網。
這種企業參與本來是好事。開源基礎設施需要錢，企業受益於開源軟體，回饋社群是理所當然的。但當這種資金支持變成單一依賴時，問題就開始出現了。
第三章：風暴前夕的政治暗流
2025 年上半年，DHH 開始在他的個人部落格上發表一系列爭議性言論。他抱怨倫敦不再是三分之一「本土英國人」的城市，暗示非白人不是真正的英國人。他讚揚 Tommy Robinson，一個有著多項暴力犯罪前科的極右翼煽動者。他發表反跨性別、反移民言論，描述大尺碼黑人女性廣告為「怪誕」，並讚美取而代之的「金髮嬰兒」廣告。
對於許多不關心政治的工程師來說，可能會覺得這些言論與技術無關。但在開源世界裡，知名人物的公開言論會直接影響社群的包容性和資金來源。Ruby 社群一直以友善和包容著稱，DHH 的言論與這種文化價值觀產生了尖銳衝突。
英國開發者 Tekin Süleyman 公開表示「Ruby 社群有 DHH 問題」。作為一個非白人英國公民，他無法解釋聽到這種毒性修辭從 Ruby 社群最知名領袖口中說出時的痛苦。他回憶起自己在 1980、90 年代在倫敦成長時遭受的種族主義，那些質疑他存在權利的白人男性，那些因為種族出身而讓他感到不受歡迎或不安全的地方和空間。
更嚴重的是，這些爭議開始產生實際的經濟後果。當 Ruby Central 決定讓 DHH 在 2025 年 7 月的最後一屆 RailsConf 上發表演講時，Sidekiq 這個重要的 Ruby 工具開發商立即撤回了每年 25 萬美元的贊助。Sidekiq 的作者 Mike Perham 明確表示，他無法繼續支持一個為 DHH 提供平台的組織。
這個決定讓 Ruby Central 陷入了財務危機。失去了 Sidekiq 的 25 萬美元後，他們變得幾乎完全依賴 Shopify 的資金。而 Shopify，正是 DHH 擔任董事會成員的公司。這種依賴關係創造了一個危險的動力學：當你的生存依賴於單一資金來源時，你實際上已經失去了獨立性。
第四章：新挑戰者的出現
就在這個敏感時刻，André Arko 在 8 月底宣布了一個名為 rv 的新工具。在 Ruby 開發中，開發者通常需要同時管理多個複雜的工具：rvm、rbenv 或 chruby 來管理不同的 Ruby 版本，RubyGems 和 Bundler 來管理專案的相依套件，還要確保不同專案使用正確的 Ruby 版本和套件版本。這個過程複雜且容易出錯，就像 JavaScript 開發者需要管理 Node 版本、npm 套件、yarn.lock 檔案等。
rv 承諾要改變這一切。它不僅管理 gems，還管理 Ruby 版本，甚至提供預編譯的 Ruby 以減少編譯時間。André 在他的部落格文章中寫道：「過去十年左右維護 Bundler 的過程中，我一直有個想法：我想要一個更好的相依性管理工具。它不僅管理你的 gems，也管理你的 Ruby 版本。它不僅管理你的 Ruby 版本，還安裝預編譯的 Ruby，這樣你就不用每次都等待 Ruby 從原始碼編譯。更重要的是，它讓運行任何用 Ruby 寫的腳本或工具變得非常簡單，即使那個腳本或工具需要與你的應用程式不同的 Ruby 版本。」
rv 的 README 中甚至大膽宣告要「擺脫 rvm、rbenv、chruby、asdf、mise、ruby-build、ruby-install、bundler 和 rubygems」，提供一個統一的解決方案。
這個宣布在 Rails 核心團隊中引起了警覺。Shopify 的員工、Rails 核心成員 Rafael França 在 Bluesky 上公開表示不信任這些「正在開發競爭工具並為此募資的管理員」，甚至懷疑他們可能會「破壞 rubygems 或 bundler」。他引用了 rv 的 README，並加上評論：「我不太確定我信任他們不會破壞 RubyGems 或 Bundler。」
這種指控很嚴重，也很諷刺。André 已經無償維護 Bundler 十五年，突然被指控可能會破壞他自己一生心血投入的專案。更重要的是，與此同時 André 和其他維護者成立了一個名為 Spinel 的合作社。合作社是一種特殊的企業組織形式，由成員共同擁有和控制，不受外部投資者或董事會影響。這意味著 Spinel 提供的服務不會受到企業利益的控制，對於習慣了企業控制的人來說，一個完全獨立、不受企業影響的替代方案確實構成了威脅。
第五章：Rails World 的暗室交易
2025 年 8 月底，Rails World 會議在阿姆斯特丹舉行。這是 Rails 社群最重要的年度聚會，會場充滿了興奮的開發者們展示最新的技術創新。但在會議的光鮮表面之下，一場關乎 Ruby 未來的神秘會議正在進行。
參與這場閉門會議的包括 Ruby Central 代表、Rails Foundation 代表、Shopify 等主要企業代表，以及 Rails 和 Ruby 核心開發者。雖然具體議程沒有公開，但據知情人士透露，會議的核心議題是 Ruby Central 的財務困境和解決方案。有人向 Ruby Central 提出了長期資金支持的提案，但提案附帶了條件：必須移除某些 RubyGems 維護者。
這種條件式資助在開源世界是極其罕見和有爭議的。就像是有人對負責管理 Python 套件倉庫的組織說：「我們願意資助你們，但你必須移除某些 pip 維護者。」這種做法打破了開源社群的基本原則：技術決策應該基於技術考量，而不是企業利益。
會議的參與者包括 HSBT（Hiroshi Shibata）、DHH、Aaron Patterson、Amanda Perino、Shan Cureton、Marty Haught、Ufuk Kayserilioglu 和 Rafael França。這些人代表了 Ruby 世界的權力中心，他們在這個會議上做出的決定，將改變整個 Ruby 生態系統的未來。
據多個消息源透露，Shopify 在這個過程中施加了巨大的壓力。他們的訊息很清楚：要麼按照我們的要求做，我們會提供長期資金支持；要麼拒絕，你們將再也得不到企業資金。這是一個典型的「胡蘿蔔加大棒」策略，利用 Ruby Central 的財務困境來達成他們的目標。
第六章：九月的背叛
2025 年 9 月 9 日，一個看似平常的週一，Ruby 世界的秩序開始崩塌。
Hiroshi Shibata（HSBT），一個 Ruby 核心成員和 RubyGems 維護者，擁有 RubyGems GitHub 組織的最高權限。這一天，他做了幾件看似簡單但意義重大的事情：將 GitHub Enterprise 組織從「RubyGems」重新命名為「Ruby Central」，添加 Ruby Central 的開源總監 Marty Haught 作為新的 owner，並降級其他所有維護者的權限。
在現代開源專案管理中，GitHub 組織的名稱不只是一個標籤，它代表著身份認同和控制權。將「RubyGems」改名為「Ruby Central」等於在宣告：「這個專案現在屬於 Ruby Central，不再屬於 RubyGems 社群。」而擁有 admin 或 owner 權限意味著可以決定哪些程式碼變更被接受、可以發布新版本到套件倉庫、可以添加或移除其他開發者。失去這些權限意味著你無法再參與專案的管理，即使你貢獻了多年的時間和精力。
當其他維護者質疑這個突然的變化時，HSBT 拒絕撤銷變更，聲稱需要 Haught 的許可。這個回應讓整個維護者團隊感到震驚和困惑。他們無法理解為什麼一個外部人員突然擁有了他們多年來共同維護的專案的控制權。
六天後，在維護者們的強烈抗議下，一些變更被回復了。Haught 承認這是一個「錯誤」，但他仍然保持著 GitHub enterprise 的 owner 身份，即使其他維護者從未同意過他的任命。這種「錯誤」的說法很難令人信服，因為在 GitHub 上進行這些操作需要多個步驟的確認，不太可能是意外。
第七章：虛假的和解
9 月 17 日，一場關鍵的 Zoom 會議在 RubyGems 維護者和 Marty Haught 之間召開。Haught 試圖緩解緊張局勢，解釋他正在制定新的「營運協議」，所有 RubyGems.org 服務的營運者都需要簽署。他提到一個「風險」：有外部人員擁有「營運 RubyGems 服務所必需的倉庫」的所有權權限。
但維護者們很快澄清了一個關鍵區別。RubyGems 開源程式碼就像 Apache、Nginx 或 MySQL 的原始碼，任何人都可以下載、修改、運行。這些程式碼由社群開發者維護，屬於社群。而 RubyGems.org 服務則是 Ruby Central 營運的特定網站，使用 RubyGems 程式碼，但運行在 Ruby Central 的伺服器上。
這就像是 Mozilla 維護 Firefox 的開源程式碼，但如果你下載 Firefox 程式碼並建立自己的瀏覽器分支，Mozilla 無法阻止你。Ruby Central 有權控制他們營運的服務，但沒有權利控制開源程式碼本身。
據一位看過這次會議錄音的人士透露，Haught 完全理解這個區別。他知道 Ruby Central 可以控制他們營運的服務，但不能聲稱擁有社群開發的開源程式碼。然而，在表面上的理解和同意之下，一個更大的計劃正在進行。
會議結束時，維護者們以為他們已經澄清了誤解，以為 Ruby Central 會尊重開源專案的獨立性。他們沒有意識到，這場會議實際上是暴風雨前的短暫寧靜。
第八章：九月十八日的敵意接管
9 月 18 日，EuRuKo 會議正在歐洲舉行，許多可能發聲反對的歐洲 Ruby 開發者都在參加會議，無法及時回應突發事件。就在這個精心選擇的時刻，Marty Haught 執行了 Ruby Central 董事會的決定。
那一天，RubyGems 和 Bundler 的所有團隊管理員失去了他們的 GitHub 組織權限。他們的 rubygems.org 電子郵件帳號被禁用。他們對 bundler 和 rubygems-update gems 的發布權限被撤銷。更諷刺的是，André Arko 當時正在值班負責 RubyGems.org 服務的營運，但他對 GitHub 和 Fastly（提供 CDN 服務的公司）的存取權限在那一刻被撤銷了。
想像一下在有人值班維護 npm 服務時，突然撤銷他們的伺服器存取權限，這就是當時發生的情況。André 不僅失去了維護 Bundler 的能力，甚至失去了處理 RubyGems.org 服務問題的能力，儘管他正在值班。
Ellen Dash，這個從 13 歲就開始參與 Ruby 社群、維護 RubyGems 超過 10 年的工程師，立即意識到發生了什麼。她在第一時間發表了強烈聲明：「我要說清楚：這是一次敵意接管。我相信 Ruby Central 的行為對整個 Ruby 社群構成威脅。強制移除那些維護 RubyGems 和 Bundler 超過十年的人，本質上就是敵意行為。」
她立即辭去在 Ruby Central 的職位，並發布了一份詳細的 PDF 文件記錄了整個事件過程。在開源世界，失去這樣的維護者不只是失去一個員工，而是失去活的知識庫，失去了解系統每個細節、歷史決策原因、潛在技術債務的專家。
André Arko 也發表了告別聲明：「正如我的同事 Ellen 所指出的，RubyGems 團隊已經不復存在。我祝願每個人在維護套件管理功能並為整個 Ruby 社群做出貢獻這項巨大任務中好運。與此同時，我期待利用我新獲得的自由時間專注於一些真正令人興奮的專案。」
第九章：企業公關的煙霧彈
在 Ellen 公開爆料六小時後，Ruby Central 發布了名為《加強 RubyGems 和 Bundler 的管理》的官方回應。這篇文章充滿了企業公關語言，沒有任何 Ruby Central 成員願意署名負責。
文章大量使用「供應鏈安全」作為藉口。在軟體開發中，供應鏈攻擊確實是一個真實的威脅，攻擊者可能會通過 compromising 相依套件來攻擊使用這些套件的應用程式。近年來確實有一些高調的攻擊案例，但供應鏈安全通常指的是防止惡意套件被上傳、確保套件發布過程的完整性、實施多重驗證等安全措施，而不是突然移除長期貢獻者的存取權限。實際上，移除經驗豐富的維護者可能會降低安全性，因為失去了最了解系統的人。
DHH 在 Twitter 上支持這個決定：「Ruby Central 正在採取正確的行動，確保 Ruby 供應鏈在技術和組織上都無可指責。」這個立場充滿了諷刺意味，因為 DHH 平時經常批評企業對開源專案的不當控制。他曾經建立了一個網站專門批評蘋果對 App Store 的控制，在他的部落格中寫道：「我對自己的開源專案擁有權非常重視。」但現在，他支持了一個類似的企業接管行為。
Ruby Central 的董事會成員、Shopify 員工 Ufuk Kayserilioglu 開始在社交媒體上為這次行動辯護。他在 Bluesky 上寫道：「Ruby Central 多年來一直在營運 rubygems.org 系統，所以這很難被認為是供應鏈攻擊。相反，我們對系統所有用戶都有法律義務，要保持系統安全和穩定。」但他故意混淆了概念，將 RubyGems 開源程式碼與 RubyGems 服務混為一談。沒有人指控 Ruby Central 接管 RubyGems 服務，而且接管 RubyGems GitHub 組織和 gems 並不是滿足 Ruby Central 法律義務所必需的。
第十章：董事會的痛苦選擇
9 月 21 日，Ruby Central 董事會成員兼財務長 Freedom Dumlao 發表了一篇名為《RubyGems 爭議的董事會成員觀點》的文章，試圖從內部視角解釋事件的經過。
Dumlao 描述了董事會面臨的困境：「要麼 Ruby Central 實施控制措施來確保我們負責的基礎設施的安全和穩定，要麼失去我們用來維持這些服務在線運行的資金。在不到 24 小時的時間裡，我們仍在努力解決這個問題。據我所知，與一些維護者的對話仍在進行，但我們希望的合作並沒有出現。」
他承認了一個關鍵事實：這是一個財務脅迫的結果。「很明顯我們還沒有完全準備好，但最終我們沒有時間了。必須投票，這樣我們才能確保不會失去營運 RubyGems 所必需的資金。」
雖然 Dumlao 沒有明確提到 Shopify，但根據其他消息源，正是 Shopify 施加了這種「要麼接受我們的條件，要麼失去資金」的最後通牒。Dumlao 的描述揭示了一個典型的企業控制策略：利用資金依賴來強制執行企業意志。
Dumlao 寫道：「如果我投票反對，我覺得我就是在投票開始關閉 Ruby Central 的過程。」這種表述展現了董事會成員面臨的道德困境，但也暴露了治理結構的根本問題：當一個非營利組織過度依賴單一資金來源時，該企業實際上擁有了否決權。
第十一章：幕後黑手的真相
就在這時，Joel Drapper，一位前 Shopify 員工、現在的 Ruby 開發者，開始進行深入調查。他與十多位直接參與事件的人士交談，甚至看到了關鍵會議的錄音，逐漸拼湊出了事件的完整真相。
Drapper 的調查揭露了一個令人震驚的幕後故事。在 Sidekiq 撤資後，Ruby Central 確實面臨財務困境，但 Shopify 的反應不是單純的資助，而是帶有明確條件的交易。Shopify 要求 Ruby Central 完全控制 RubyGems GitHub 倉庫和相關 gems，並特別要求排除 André Arko，不允許他重新獲得專案存取權限。
更令人不安的是，為了確保接管的順利進行，Shopify 準備了新的 on-call 輪值團隊來替代被排除的維護者。他們的工程師在接管的同時開始提交程式碼，這是他們六年來第一次向 RubyGems 專案提交程式碼。這種準備程度表明這不是一個倉促的安全決定，而是一個精心策劃的接管行動。
接管的時機選擇也很可疑：選在 EuRuKo 會議期間，當許多可能發聲反對的歐洲 Rubyists 都在參加會議，無法及時回應。當 André 這個值班工程師失去存取權限時，Shopify 的團隊立即接手了營運責任，顯示出他們早就準備好了替代方案。
據 Drapper 的調查，Ruby Central 的董事會在 Marty Haught 向他們匯報時，已經被告知這次接管可能對社群造成的風險和傷害。Haught 甚至提到了其他選項，比如 forking 一些專案。但在 Shopify 的最後通牒壓力下，董事會仍然選擇了最激進的接管方案。
第十二章：概念混淆的宣傳戰
Ruby Central 在為自己的行為辯護時，不斷使用一種狡猾的策略：故意混淆「RubyGems 開源程式碼」與「RubyGems.org 服務」的概念。他們聲稱因為營運服務，所以也擁有程式碼，但這種邏輯在開源世界是站不住腳的。
這種論點就像是說因為 GitHub 託管了 Linux 核心的程式碼倉庫，所以 GitHub 擁有 Linux；因為某個公司運行了一個 WordPress 網站，所以他們擁有 WordPress；或者因為 Cloudflare 提供 CDN 服務給 npmjs.com，所以 Cloudflare 擁有 npm。在開源世界，託管服務和程式碼所有權是完全不同的概念。
9 月 23 日，Ruby Central 執行總監 Shan Cureton 發布了一個影片聲明，代表董事會和團隊發言。她聲稱 Bundler 和 RubyGems 通過與 Ruby Together 的合併來到 Ruby Central 的責任範圍內，但這是錯誤的：Ruby Together 從未擁有 Bundler 或 RubyGems。
Cureton 在影片中不斷混淆概念，聲稱「RubyGems.org 不只是程式碼，它是一個生產服務。它運行 Ruby 生態系統的關鍵基礎設施，處理數十億次下載，儲存敏感的後設資料，並被有合規要求的公司所依賴。因為它是一個服務，Ruby Central 承擔法律責任、財務風險和營運風險。」
但她故意混淆了 RubyGems.org 原始碼與 Ruby Central 營運的服務。聲稱因為營運使用原始碼的服務而擁有原始碼，就像聲稱你擁有 Rails 因為你有一個 Rails 應用程式並贊助了某個對專案貢獻 PR 的人。
第十三章：rv 工具背後的威脅論
要理解為什麼 rv 工具會引起如此強烈的反應，需要了解它所代表的更深層威脅。Ruby 開發者長期以來一直在忍受工具鏈的複雜性：需要使用 rvm、rbenv 或 chruby 來管理不同的 Ruby 版本，需要 RubyGems 和 Bundler 來管理專案的相依套件，還要確保不同專案使用正確的 Ruby 版本和套件版本。這個過程複雜且容易出錯，經常讓新手感到困惑。
André 的 rv 工具承諾要統一這個混亂的生態系統。它不僅管理 gems，還管理 Ruby 版本，甚至提供預編譯的 Ruby 以減少編譯時間。最重要的是，rv 讓運行任何用 Ruby 寫的腳本或工具變得簡單，即使那個腳本需要與你的應用程式不同的 Ruby 版本。
但 rv 的真正威脅不在於技術創新，而在於它所代表的獨立性。rv 由 Spinel 合作社開發，這是一個不受企業控制的組織。如果 rv 成功，它將證明社群驅動的替代方案是可行的，可能會減少對 Ruby Central 控制的傳統工具的依賴。
Rafael França 的擔憂反映了既得利益者的恐懼。他在 Bluesky 上質疑維護者的動機，暗示他們開發競爭工具是為了個人利益。但這種質疑忽略了一個關鍵事實：André 已經無償維護 Bundler 十五年，突然被懷疑會破壞他自己一生心血投入的專案。
第十四章：André 的反擊
面對這場敵意接管，André Arko 做出了一個戲劇性但合理的反應：註冊 Bundler 商標。9 月 25 日，他在部落格文章《Bundler 屬於 Ruby 社群》中詳細講述了這個決定背後的原因。
André 回顧了他與 Bundler 十五年的淵源，從 2010 年加入 Carl Lerche 和 Yehuda Katz 的團隊，到成為主要維護者，再到創立 Ruby Together 來資助開發工作。他特別提到了與 Ruby Central 的合併協議，其中明確規定要「賦權專案用戶和維護者決定專案的最佳方向」、「給控制權給社群」、「對社群負責和透明」。
「最近幾週，Ruby Central 突然聲稱他們獨自擁有 Bundler。這根本不是事實，」André 寫道。「為了保護那些為專案投入如此多時間和精力的維護者團隊的聲譽，我已經註冊了我在 Bundler 專案上的現有商標。」
但 André 明確表示，他註冊商標不是為了個人利益：「雖然商標註冊在我個人名下，但我不會為自己保留它，因為 Bundler 的理念屬於 Ruby 社群。一旦有一個對維護者負責、對社群負責、擁有公開民主選舉董事會成員的 Ruby 組織出現，我承諾將完全轉移我的商標。」
商標在法律上控制的是名稱的使用權，而不是程式碼本身。擁有 Bundler 商標意味著只有商標持有者可以決定什麼產品可以叫做「Bundler」，其他人可以 fork 程式碼，但不能使用「Bundler」這個名稱。這是一個防禦性策略，目的是防止 Ruby Central 或其他組織不當使用 Bundler 的名稱。
第十五章：社群的分裂與覺醒
這次事件在 Ruby 社群中造成了前所未有的分裂，但也喚醒了許多人對開源治理問題的關注。
支持維護者的聲音越來越強烈。Homebrew 專案的領導者 Mike McQuaid 表示願意調解，但最終失敗。他在 Bluesky 上寫道：「Ruby Central 處理這件事非常糟糕，包括錯誤地移除了 RubyGems 組織中字面上最活躍的成員，而他已經拒絕回歸。」他還批評 Ruby Central 引用供應鏈問題是「不必要的恐懼、不確定性和懷疑」。
一封名為「Plan Vert」的公開信開始在社群中流傳，要求 Rails 核心團隊與 Ruby 社群切斷與 DHH 的關係，理由是他的「種族主義和恐跨觀點」。這封信得到了越來越多知名開發者的支持，包括 Mastodon 的創造者 Eugen Rochko。Mastodon 是最受歡迎的基於 Rails 的開源應用程式，Rochko 的支持具有重要的象徵意義。
與此同時，DHH 和他的支持者開始反擊。DHH 發表了一篇題為《技術界覺醒島嶼的最後瘋子們正在絕望》的文章，聲稱對他的批評是「反社會行為和暴力幻想」的表現。他建立了一個名為「Stand With DHH」的網站來收集支持，並發表了更多爭議性言論。
Shopify 的 CEO Tobi Lütke 也加入了這場爭論，他轉推了一個極右翼媒體對 Plan Vert 公開信的攻擊，並評論道：「建設者們承受著分裂小丑騎進來並惡意噴出他們顯然自己都不理解的廢話術語的巨大精神負擔，這真是太可怕了。」
第十六章：技術替代方案的興起
面對這場危機，被排除的維護者們並沒有放棄。他們通過 Spinel 合作社繼續他們的工作，代表著一個不受企業控制的新方向。
Spinel 合作社的成立本身就是一個政治聲明。合作社模式確保所有成員都有平等的發言權，沒有外部投資者或董事會可以施加不當影響。André、Samuel Giddins、Kasper Timm Hansen 和 Sam Stephenson 組成了這個團隊，他們都是 Ruby 生態系統的資深貢獻者。
rv 工具的開發繼續進行，代表著一個技術上的革新。但在當前的政治背景下，rv 不僅僅是一個工具，它成為了社群獨立性的象徵。每一個選擇使用 rv 而不是傳統工具的開發者，都在投票支持一個不受企業控制的未來。
與此同時，一些開發者開始考慮 fork RubyGems 和 Bundler。雖然 Ruby Central 控制了 GitHub 組織，但他們無法控制開源軟體的本質：任何人都可以複製程式碼並繼續開發。如果社群真的決定創建 fork，Ruby Central 可能會發現自己控制的只是空殼。
第十七章：更大的教訓
這個故事的意義遠超過 Ruby 本身，它為整個開源世界提供了重要的教訓。
在 JavaScript 世界，npm 主要由 GitHub（現在是微軟）資助。在 Python 世界，PyPI 依賴企業贊助。在 PHP 世界，Packagist 需要企業支持。當開源基礎設施過度依賴單一企業資金時，類似的問題可能在任何生態系統中發生。
明確的治理結構可以防止權力濫用。需要明確區分服務營運權和程式碼所有權，建立民主決策機制，設置制衡權力的機制。多元化的資金來源可以防止單一企業的不當影響。
DHH 的情況展示了當個人擁有過多控制權時的風險。技術創新者不一定是好的社群領袖，個人觀點可能與社群價值衝突。需要機制來平衡個人權威和集體利益。
當企業利益與社群價值衝突時，透明的決策過程、多元化的資金來源和強而有力的社群聲音都是必要的。但最重要的是，社群必須有勇氣為自己的價值觀戰鬥。
尾聲：未竟的戰爭
截至 2025 年 9 月底，這場戰爭遠未結束。Ruby Central 仍然控制著 RubyGems 和 Bundler 的 GitHub 倉庫，但他們的權威已經受到嚴重質疑。被排除的維護者們通過 Spinel 繼續他們的工作，開發著可能改變整個生態系統的新工具。André 持有的 Bundler 商標成為了抗議的象徵，也是對未來民主治理的承諾。
DHH 繼續發表爭議性言論，社群仍在掙扎如何應對一個既創造了他們喜愛的工具、又表達他們反對的觀點的人。Plan Vert 公開信繼續收集簽名，Shopify 和其他企業面臨著越來越大的壓力要求他們表態。
這個故事提醒我們，技術從來不是中性的。我們使用的工具、平台和基礎設施都有其政治性和經濟性。在一個日益由少數大企業主導的科技世界裡，開源社群必須時刻警惕，保護那些讓開源世界獨特和有價值的原則：協作、透明、社群驅動的創新，以及對所有人開放的理念。
Ruby 社群的這場戰爭還在繼續，但它已經為整個開源世界留下了深刻的教訓。不管最終結果如何，2025 年 9 月將被記住為開源世界的一個轉捩點，一個關於我們究竟想要什麼樣的技術未來的時刻。在這個故事中，我們看到了人性的複雜、利益的衝突、理想的脆弱，以及普通開發者為了保護共同價值而展現的勇氣。
這場戰爭的結果將決定的不僅僅是 Ruby 的未來，而是開源精神在企業化時代能否生存的問題。無論你使用什麼程式語言，這個故事都值得你的關注，因為它可能預示著你所依賴的開源基礎設施的未來。
本著作由小克製作，以創用CC 姓名標示-相同方式分享 4.0 國際 授權條款釋出。