Video.js被棄16年后，創始人用1個決定讓5個對手集體"掀

一個支撐了萬億次視頻播放的開源項目，在被東家拋棄后，創始人回來做了一件事：讓5個競爭對手自愿刪掉自己的代碼，從頭一起寫。

這聽起來像開源世界的童話。但數據是冷的——Video.js v10比v8小了88%，不是壓縮算法的功勞，是5個項目真的把架構撕碎重來了。

從"被裁員"到"被拋棄"：一個16歲項目的瀕死時刻

Video.js的年齡足夠讓一代工程師從入行用到帶團隊。2009年發布，它解決了當時最頭疼的問題：如何讓視頻在不同瀏覽器里正常播放。Flash正在死去，HTML5視頻標簽剛剛誕生，各瀏覽器實現得像方言一樣互不兼容。

Steve Heffernan寫了這個播放器，然后交給了Brightcove維護。后者是一家視頻技術公司，用商業收入養著開源項目，這種模式持續了十幾年。

2024年，Brightcove被收購。收購方的算盤里沒給Video.js留位置——維護團隊被裁，項目技術上進入"被遺棄"狀態。

Steve在16年后重新接手。這時候他本可以做最安全的選擇：恢復更新頻率，修修bug，保證現有用戶不流失。開源項目的"僵尸復活"劇本通常到此為止。

但他選了最難的路。

5個"敵人"坐在同一張桌子前

Steve開始接觸另外4個開源視頻播放器項目的核心維護者：Media Chrome、Plyr、Vidstack、Mux Player。這些不是無名小卒——Plyr在GitHub有2萬多星，Vidstack是新一代開發者的心頭好，Mux Player背后站著視頻基礎設施公司Mux。

他的提案直白到近乎冒犯：你們各自的代碼庫，放棄掉。我們一起寫一個新的。

開源世界的正常劇本是什么？Fork（分叉），競爭，互相挖用戶，直到某個項目因為維護者 burnout（精力耗盡）或金主變心而沉寂。Video.js自己差點就走完這個劇本。

但5個項目的工程師同意了。

「我們都厭倦了重復造輪子，」Vidstack創始人Matt McClure后來在技術社區寫道，「每次有人問我'該用哪個播放器'，我都很想反問'你真的很在乎這個區別嗎'。」

這種"在乎"的代價是真實的。5個代碼庫意味著5套bug修復、5份文檔維護、5群用戶在Discord里問同樣的問題。更隱蔽的成本是架構債務——每個項目都為了兼容自己的歷史決策而越來越臃腫。

88%的瘦身：不是優化，是推翻

v10的體積數據容易讓人誤解。88%減小不是前端工程師熟悉的"啟用Brotli壓縮"或"路由懶加載"那種漸進式優化。

舊版Video.js的問題在于標準本身。它把UI、播放邏輯、流媒體支持全捆在一起。你只需要一個背景靜音視頻？打包體積約9KB。你要用流媒體？膨脹到150KB。沒有中間態，無法按需裁剪。

v10的解法是徹底分離。UI不是播放器，播放不是播放器，流媒體支持直到你配置才加載。這種架構在舊代碼庫里無法實現——不是技術不可能，是"不破壞現有API"的政治不可能。

React版本的實現細節能說明這種徹底性。他們沒有用Web Components（網頁組件）套殼做React風格的API，而是直接用Hooks（鉤子）和Render Props（渲染屬性）。Vue版本的Composable（組合式函數）版本也承諾保持同樣原則。

皮膚系統直接借鑒了shadcn的設計理念：復制粘貼，歸你所有。沒有"主題API"的學習成本，沒有"自定義但別改太多"的隱性約束。

這些選擇都有一個共同前提：放棄向后兼容的承諾。

這是5個項目合并才能換來的奢侈。單個項目不敢做，用戶會跑；5個項目一起做，用戶……還是會抱怨，但至少知道該往哪跑。

開源的"不可能三角"被打破了？

這件事的反常程度需要放在開源經濟學的框架里理解。

開源項目通常面臨一個不可能三角：可持續維護、技術激進創新、社區廣泛采納。你只能選兩個。Linux選了后兩個，代價是Linus Torvalds的絕對權威和企業的間接供養。React選了前兩個，代價是Meta的完全控制。舊Video.js試圖選第一和第三，結果在技術債里越陷越深，直到被金主拋棄。

Steve的解法是在三角之外找第四個點：讓競爭對手變成合作者，把"社區"的定義從單個項目的用戶群，擴展到整個視頻播放器品類。

這個模型的脆弱性顯而易見。5個工程師都有本職工作，Mux Player的維護者Rik Heijmann要兼顧公司產品線，Plyr的Sam Potts有全職工作，Vidstack剛完成融資。Beta版2026年3月發布，GA（正式發布）預計年中——時間表由志愿者的業余時間決定。

但模型的韌性也同樣明顯。沒有單一金主能再次"賣掉"這個項目，因為所有權已經分散。沒有單一維護者 burnout 能拖垮進度，因為有5個人在互相備份。

「我們不是在維護一個播放器，」Steve在技術播客里說，「是在維護一個共識：視頻播放的基礎設施不應該有5種不兼容的實現。」

這種表述有理想主義色彩，但執行層面很務實。v10的代碼倉庫里，每個核心模塊都有來自至少兩個原項目的提交記錄。Code review（代碼審查）的規則是：任何涉及架構的改動，需要兩個以上"原項目代表"的批準。

這不是合并，是聯邦制。

一個尚未回答的問題

2026年3月的Beta版已經可用。GA時間表是"年中"，具體日期取決于5個兼職工程師的進度。

更不確定的是長期治理。當v10穩定后，5個項目會完全合并成一個品牌，還是保持各自的前端包裝？Plyr以其極簡API著稱，Vidstack以類型安全為賣點，這些差異化在統一架構下如何保留？

Steve的回應是暫時不回應。「我們先證明這個架構能跑起來，」他在GitHub討論區寫道，「品牌問題值得爭論，但不是現在。」

這種延遲決策的姿態，和v10的技術選擇一脈相承：分離關注點，推遲綁定。

開源世界見過太多"合并宣言"變成" fork 戰爭"的前奏。但Video.js v10的奇怪之處在于，5個項目的代碼庫真的在萎縮——不是被拋棄，是被主動縮減。Plyr的GitHub倉庫已經標注"遷移至Video.js v10"，Vidstack的新功能開發暫停，資源轉向聯合架構。

這不是勝利者通吃，是參與者集體退出競爭。

一個用戶在新版文檔的評論區問：「如果我想從舊版Video.js遷移，但依賴了某個特定插件，怎么辦？」

維護者的回復被點贊到置頂：「先確認那個功能在v10里是否真的需要插件。我們刪掉的代碼比保留的多，可能你依賴的只是個歷史包袱。」

這種對話每天都在發生。16年前Steve寫Video.js是為了解決瀏覽器兼容問題，現在他回來，是為了解決開源項目本身的兼容問題——不是技術層面的，是組織層面的。

v10能成功嗎？Beta版的下載量在增長，但"成功"的定義本身在模糊。如果5個項目最終真的合并成一個維護團隊，這是開源治理的特例還是模板？如果某個原項目后來退出，聯邦制會不會退化為寡頭制？

這些問題沒有寫在路線圖里。路線圖只有三行：Beta 2026年3月，GA 2026年中，五個工程師，都有其他工作。

最后一個已知事實是：Steve在重新接手后的第一次社區會議上，展示了5個項目的logo拼成的六邊形。他說這是"暫時的視覺方案"，但那個文件至今還在倉庫里，沒人提議替換。