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 核心使用的服務端編程語言 ↩︎
發表回覆