On infrastructure...

Much digital ink has been spilled about the ongoing saga between Matt Mullenweg and WP Engine, but what has been most interesting to me, personally, is the details that have been rapidly shared with the broader community. I have thoughts on the overall saga, but digging into the details feels more productive.

Today's topic? Infrastructure.

In interviews and on WordPress.org, Matt has noted [sic]:

WP Engine wants to control your WordPress experience, they need to run their own user login system, update servers, plugin directory, theme directory, pattern directory, block directory, translations, photo directory, job board, meetups, conferences, bug tracker, forums, Slack, Ping-o-matic, and showcase. Their servers can no longer access our servers for free.

Setting aside the saga itself, I find it an interesting premise that any independent company should host this infrastructure and support it. It's accurate to say a lot of companies host their own update servers for proprietary plugins, manage their own bug trackers, host their own conferences, meetups, and job boards, manage translations for their plugins outside of WordPress.org and, yes, some even host their own public copy of the plugin directory, for better or for worse.

But, fundamentally, there are two issues with a person or company wanting to replace core WordPress.org services (built-in to every version of the CMS for over a decade) with their own.

Hardcoded WordPress.org services

Over the weekend, a contributor filed a ticket against the WordPress product outlining the first issue: WordPress hardcodes the WordPress.org API, without a supported path for swapping the API with a custom one. I have to imagine that this is intentional, as fundamentally WordPress does not want the API replaced with (e.g.) a malicious API. While a comment in the ticket now notes a workaround, I have to imagine this is not something that should be supported by WordPress itself.

But yes, there's a workaround, which a company (in this case, WP Engine) could utilize on their global installations through a "must use" plugin (mu-plugin). That brings us to the second issue.

Closed source API

While the code powering the plugin and theme directories, including their APIs, is public, the code powering the update API is not public. On Monday morning, a contributor asked about this in the #meta channel on the WordPress Slack (direct link; requires WordPress.org login).

As of this writing, there has been no response or guidance. I have to imagine that's because the code powering these APIs is private, because it certainly used to be.

Edit: It was confirmed in-channel that this API is not open source at present. (Source)

This makes it considerably harder to replace the core API. The premise of WordPress, and much of Mullenweg's preaching, is a fundamental belief in the GPL and open source. In the recent live stream he did with Theo (t3.gg), Mullenweg noted he was a "zealot" on this front.

Philosophy of WordPress

While those two issues are likely to be difficult to overcome, they are solvable problems, with enough resources and desire. The bigger question, to me, is this: What is the philosophy of WordPress on this front?

Historically, WordPress has always "promised" that WordPress.org services would exist for every version of WordPress, with automatic updates added as part of WordPress 3.7 in 2013, a version of WordPress unofficially supported until just two years ago. In fact, the plugin guidelines, which every plugin developer must follow to include their plugin in WordPress.org's directory, call out the following:

8. Plugins may not send executable code via third-party systems.

Externally loading code from documented services is permitted, however all communication must be made as securely as possible. Executing outside code within a plugin when not acting as a service is not allowed, for example:

• Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s

Fundamentally, WordPress has treated the WordPress.org APIs—updates, plugins, and themes—as "sacred", in a way, doing everything in the project's control to keep users up-to-date and secure. Requesting (or mandating) that a large WordPress host setup and manage their own services replacing WordPress.org's seems counter to the promise WordPress has made to its users. More to the point, given that WordPress.org is Mullenweg's website (per the aforementioned live stream with Theo), should legal threats against Automattic—or even against him (in his capacity as owner of WordPress.org)—break that promise?