WP Engine 收购 WPackagist 后，开源社区四天拿出更好的替代品

3 月 12 日，WP Engine³ 宣布收购 WPackagist²——这个服务于 WordPress Composer⁴ 生态系统十余年的基础设施项目。收购后 WP Engine 立即在每位开发者的终端里显示了”WPackagist is now maintained by WP Engine”的提示。一个看似微小的改动，却清晰地揭示了企业控制权如何改变工具与用户的关系。

四天后，社区给出了回应：WP Packages¹ 正式上线。

WP Packages 是什么

WP Packages 是由 Roots 团队（Bedrock、Sage、Trellis 的维护者）的开发者 Ben Word 构建的开源 Composer 仓库。WordPress.org 目录中的所有免费插件和主题都可以通过它安装。对于不熟悉 Composer 的读者来说，它是 PHP⁷ 的依赖管理工具，专业 WordPress 开发者用它来安装和更新插件、主题——相当于 PHP 世界的 npm。

Ben Word 其实早在去年八月就开始构建 WPackagist 的替代品，远在收购成为新闻之前。当问题出现时，社区已经准备好了答案。

不只是替代品

WP Packages 在多个维度上超越了它的前身。

最直观的差别是速度。冷启动解析 10 个插件的依赖，WPackagist 需要 12.3 秒，WP Packages 只需要 0.7 秒——17 倍的差距。这得益于对 Composer v2 协议的完整支持：只获取项目实际需要的包元数据，而不是像 WPackagist 那样下载整个索引文件。

在工程细节上，WP Packages 使用 CDN⁶ 缓存并提供公共缓存头，服务不可变的、内容寻址的单包文件。包命名更简洁（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 的出现表明，社区有能力在关键基础设施被商业化时快速构建替代方案。整个项目是完全开源的——应用代码、文档甚至完整的 Ansible⁵ 部署配置都在 GitHub 上公开，任何人都可以 fork 并运行自己的 WordPress Composer 仓库。

Ben Word 还公开承诺 WP Packages 永远不会在 Composer info 字段推送广告或推销信息。当一个项目对社区负责而非对企业董事会负责时，这种约束更容易兑现。项目通过 GitHub Sponsors 资金支持，赞助商包括 WordPress.com、Kinsta 等。

这个故事的精髓在于：不需要收购案，不需要董事会的定价决策。开发者替开发者解决问题，然后把结果分享给所有人。这就是开源应有的样子。