3 月 12 日，WP Engine3 宣佈收購 WPackagist2——這個服務於 WordPress Composer4 生態系統十餘年的基礎設施專案。收購後 WP Engine 立即在每位開發者的終端裡顯示了”WPackagist is now maintained by WP Engine”的提示。一個看似微小的改動，卻清晰地揭示了企業控制權如何改變工具與使用者的關係。
四天後，社群給出了回應：WP Packages1 正式上線。
WP Packages 是什麼
WP Packages 是由 Roots 團隊（Bedrock、Sage、Trellis 的維護者）的開發者 Ben Word 構建的開源 Composer 倉庫。WordPress.org 目錄中的所有免費外掛和主題都可以透過它安裝。對於不熟悉 Composer 的讀者來說，它是 PHP7 的依賴管理工具，專業 WordPress 開發者用它來安裝和更新外掛、主題——相當於 PHP 世界的 npm。
Ben Word 其實早在去年八月就開始構建 WPackagist 的替代品，遠在收購成為新聞之前。當問題出現時，社群已經準備好了答案。
不只是替代品
WP Packages 在多個維度上超越了它的前身。
最直觀的差別是速度。冷啟動解析 10 個外掛的依賴，WPackagist 需要 12.3 秒，WP Packages 只需要 0.7 秒——17 倍的差距。這得益於對 Composer v2 協議的完整支援：只獲取專案實際需要的包後設資料，而不是像 WPackagist 那樣下載整個索引檔案。
在工程細節上，WP Packages 使用 CDN6 快取並提供公共快取頭，服務不可變的、內容定址的單包檔案。包命名更簡潔（wp-plugin/ 和 wp-theme/ 替代了 wpackagist-plugin/ 和 wpackagist-theme/），後設資料包含了作者、描述和主頁連結這些 WPackagist 缺失多年的資訊，同步頻率也從 WPackagist 的大約 90 分鐘縮短到了 5 分鐘。
遷移很簡單
從 WPackagist 切換到 WP Packages 只需幾條命令。先移除舊包，再切換倉庫地址，最後用新的命名重新安裝。整個過程不需要改動專案程式碼。Roots 還提供了一鍵遷移指令碼自動更新 composer.json。使用 Bedrock 的專案則已經預設配置好了 WP Packages，無需任何額外操作。
composer remove wpackagist-theme/twentytwentyfive
composer config --unset repositories.wpackagist
composer config repositories.wp-composer composer https://repo.wp-packages.org
composer require wp-theme/twentytwentyfive
為什麼這件事值得關注
WordPress 生態的基礎設施被企業收購不是第一次了。WP Packages 的出現表明，社群有能力在關鍵基礎設施被商業化時快速構建替代方案。整個專案是完全開源的——應用程式碼、檔案甚至完整的 Ansible5 部署配置都在 GitHub 上公開，任何人都可以 fork 並執行自己的 WordPress Composer 倉庫。
Ben Word 還公開承諾 WP Packages 永遠不會在 Composer info 欄位推送廣告或推銷資訊。當一個專案對社群負責而非對企業董事會負責時，這種約束更容易兌現。專案透過 GitHub Sponsors 資金支援，贊助商包括 WordPress.com、Kinsta 等。
這個故事的精髓在於：不需要收購案，不需要董事會的定價決策。開發者替開發者解決問題，然後把結果分享給所有人。這就是開源應有的樣子。
名詞解釋
- WP Packages：WordPress 官方推出的包管理基礎設施 ↩︎
- WPackagist：WordPress 外掛和主題的 Composer 包倉庫 ↩︎
- WP Engine：主流 WordPress 託管服務商 ↩︎
- Composer：PHP 的依賴管理工具 ↩︎
- Ansible：開源的 IT 自動化運維工具 ↩︎
- CDN：內容分發網路，透過全球節點加速網頁載入 ↩︎
- PHP：WordPress 核心使用的服務端程式語言 ↩︎
發表回覆