FAIR package management for WordPress
The last year has been a rocky one for the WordPress community. Matt
Mullenweg—WordPress co-founder and
CEO of WordPress hosting company Automattic—started a messy public spat with
WP Engine in September and
has proceeded to use his control of the project's WordPress.org
infrastructure as weapons against the company, with the community
caught in the crossfire. It is not surprising, then, that on
June 6 a group of WordPress community participants announced the
Federated
and Independent Repositories Package Manager (FAIR.pm) project. It
is designed to be a decentralized alternative to WordPress.org with a
goal of building "public digital infrastructure that is both
resilient and fair
".
Background
Mullenweg used his keynote at last year's WordCamp US to complain that Automattic competitor WP Engine was not contributing enough to the WordPress ecosystem. In addition, he said that it violated WordPress trademarks by removing some of the content-management system's (CMS) revision features.
As a result, WP Engine traded cease-and-desist letters with Automattic, and then filed a 62-page complaint against the company and Mullenweg personally. Since then, Mullenweg has been using his control of the WordPress.org infrastructure as a weapon against WP Engine, as well as members of the WordPress community that have questioned his actions. He blocked WP Engine's access to WordPress.org, terminated a number of people's WordPress.org accounts, seized control of WP Engine's plugins hosted on WordPress.org, and more.
In October, a project called AspirePress
was launched to respond to the problem that "every WordPress
instance in the world has a single point of failure
" in the form
of WordPress.org. That project sought to provide a community-run
mirror for WordPress plugins and updates, and also helped lay the
groundwork for FAIR.pm.
WP Engine was granted a preliminary injunction, on December 10; the order forced Mullenweg to unblock WP Engine's access to WordPress.org, reactivate accounts, and restore its ownership of the Advanced Custom Fields (ACF) plugin on the site that had been hijacked by an Automattic-controlled fork of the plugin.
Shortly after the injunction, an anonymous group of WordPress
contributors published an open
letter asking Mullenweg to propose "community-minded
solutions
" to objections about the project's governance, lack of
transparency, and conflicts of interest. That did not happen. But
Mullenweg did deactivate the
WordPress.org accounts of Joost de Valk,
Karim Marucchi, Sé Reed, Heather Burns, and
Morten Rand-Hendriksen, after De Valk and
Marucchi
separately published their visions for WordPress without a benevolent
dictator for life (BDFL). Mullenweg said that he was doing so to
"give this project the push it needs to get off the
ground
". De Valk later wrote
that Mullenweg's post helped serve as a catalyst for FAIR.pm:
Several groups had been working on related problems, each bringing different perspectives, needs, and capabilities. Rather than announce a new umbrella, we focused on connecting the dots between these parallel efforts. We're not naming everyone in that alignment publicly yet, but it's safe to say: this is a group of groups, and that's its strength.
What followed were weeks of collaboration. We mapped out which parts of the ecosystem needed reinforcement. Some things were urgent: plugin update services, the plugin and theme directories, static assets like emojis and avatars, and the dashboard feeds. We began with mirrors and drop-in replacements, but the plan was always broader than that.
In January, Automattic also announced it was reallocating its resources away from WordPress development in response to the lawsuit. Since then, things have been relatively quiet, but the entire saga has undermined confidence in WordPress as the go-to, stable, and safe open-source CMS that individuals, businesses, and hosting companies could trust for long-term web projects.
WordPress.org is at the center of the project's development and distribution; it is hard-wired into the CMS as the source of plugins, themes, and updates for anyone running the CMS on their own infrastructure—or those providing hosting to others. One of the things driven home by the conflict between Automattic and WP Engine is how much control Mullenweg has as BDFL over the larger community via WordPress.org, and that he is willing to use it in a decidedly non-benevolent fashion. It is only surprising that the larger community has waited this long to collaborate on an alternative.
The project
The Linux Foundation's press release about FAIR.pm diplomatically avoids mentioning any of the messy backstory; it simply touts the advantages of a vendor-neutral package-management system for WordPress, and introduces the co-chairs of the project's technical steering committee (TSC). The co-chairs are Carrie Dils, Mika Epstein, and Ryan McCue. Dils is known for her WordPress advocacy work, Epstein is the former manager of the WordPress.org plugin repository, and McCue has been a contributor for more than 20 years, including being the developer behind the WordPress REST API. The full list of steering committee members includes more than 30 people from the larger WordPress community who have served as the initial organizers of the project.
The TSC, according to the technical charter, is responsible for all technical oversight of the FAIR project. The TSC has voting rights in the project, as well as the ability to modify or approve modifications to the project's source code, documents, and other artifacts. Contributors to the project may become organizers by a majority vote of the TSC.
What is not yet clear is who's footing the bill for FAIR.pm. The Linux Foundation's press release does not include any information about project sponsors. It merely says that announcements about governance and funding are forthcoming, and invites companies or organizations interested in participating to get in touch. This is somewhat unusual. Similar announcements, such as the announcement for Valkey, and for OpenTofu, have included at least some of the companies that were backing the new efforts. It is unclear whether this indicates that the FAIR.pm announcement was assembled hastily, that companies funding it want to avoid the spotlight for now, or both.
So far, the project has developed many of the pieces it will need to provide distributed package management for WordPress. This includes a protocol for its decentralized distribution system, a plugin to enable WordPress to use FAIR repositories, a Mini FAIR plugin for small-scale hosting and distribution of WordPress packages, as well as the server software used for the main FAIR.pm server to provide repository information and distribute packages to WordPress systems. Note that, in FAIR.pm parlance, themes, plugins, language packs, WordPress updates, and even WordPress "core" are all called packages. The protocol documentation is licensed under the Creative Commons Attribution 4.0 license, and all of the software is available under the GPLv2 (the same license used for WordPress itself).
How it works
Traditionally, WordPress extensions are identified by the directory name of the plugin, called a "slug". For example, when the ACF plugin is installed, its code is located in the wp-content/plugins/advanced-custom-fields directory; the slug for ACF is "advanced-custom-fields". The slug is the unique identifier used to search WordPress.org for plugins to install, to check for updates of installed plugins, and to report statistics.
WordPress users can install plugins that are not listed on WordPress.org—but any such plugins are essentially second-class citizens in that ecosystem. Firstly, they are not discoverable via the WordPress administrative interface, or on the WordPress.org directory. Secondly, if a plugin developer wishes to implement updates that do not require WordPress.org, they have to use a third-party tool for updating or implement their own upgrade handling method in the extension—or require users to upload new versions manually.
These are not obstacles if a developer has developed a custom extension for their personal site, but it serves as friction against adoption for plugins that are meant for widespread use. Since many plugins and themes are developed with commercial interests in mind, this is a significant hurdle for anyone who wishes to—as business folks like to say—monetize WordPress extensions.
Perhaps even more worrisome for the commercial providers is the
fact that WordPress installations, by default, phone home to WordPress.org
with information about installed plugins and other data. The FAIR
documentation notes that only a small amount of that data is
provided to plugin publishers. The full data is only available to
WordPress.org, "and there are no guarantees about
conflicts-of-interest in the usage of this data
".
The FAIR project, in contrast, says it will operate an open analytics system that will collect data to be made available (in anonymized, aggregated form) for everyone:
No single actor has special access to this data, and the analytics system is operated by the FAIR Web Foundation for the benefit of all. Strict rules govern the use of and access to this data.
This data can be used by plugin maintainers to check data about their own plugins, by discovery servers to find which plugins exist, and for any other purpose such as research.
To work with the FAIR protocol each plugin needs to have a W3C standard decentralized identifier (DID), instead of a slug, that is used to fetch a document that includes information about the plugin repository, license, authors, type of package, security contact information, cryptographic signing keys, and more. This does mean that themes and plugins will have to be modified to work with the FAIR plugin and infrastructure, but the documentation for doing so appears unfinished.
Another problem that has been made clear over the last year is one of moderation; currently, the WordPress.org server administrators choose which packages are published, which might be marked "insecure", and more. As demonstrated with the ACF plugin, the WordPress.org administrators can also take over a plugin completely. That might be a good thing, if a widely used plugin has been abandoned or has a security vulnerability that needs immediate response. But that power can be, and has been, abused.
The documentation
for the FAIR protocol indicates that the FAIR.pm server will offer a
moderation system to "protect the ecosystem
", but others can
implement additional moderation systems on top of the protocol:
Anyone can offer their own moderation service which users can opt in to. For example, users might choose to only install packages which have been manually approved by a trustworthy source, or they may pay a security company to help them block less-secure packages. Hosts might also offer a moderation service to their customers which blocks incompatible plugins.
Users can choose their moderation services, including disabling the built-in, FAIR-provided moderation service.
The FAIR plugin—which is not yet considered stable—is designed to federate a number of features that currently depend on WordPress.org: this includes CMS updates, several WordPress APIs, server health checks, as well as the event and news feeds displayed in the administrative dashboard.
The plugin will allow users to search discovery servers for new plugins. Currently the plugin is set up to use the AspirePress package mirror that launched last year, but it is expected that other FAIR providers will come online—and users can change the configuration to use whatever providers they would like. At least, they will be able to once more providers come online. Version 0.2.0 of the plugin was released on June 6.
What's next
The project page mentions a FAIR distribution of WordPress that would allow hosting providers and users to provision the CMS with FAIR.pm preinstalled from the start. To date, there is no repository for that work. Ironically, Automattic's slowdown in WordPress development should make it easier for the FAIR.pm project to maintain a fork of WordPress in the long-run.
Judging by the current state of the plugin and documentation, there is a fair amount of work ahead before the WordPress ecosystem can declare independence from WordPress.org. The project has three working groups at launch to do that work: the temporary technical independence working group responsible for initial bootstrapping of the protocol and plugins, a permanent group responsible for long-term development and operation of the FAIR package manager, as well as a community working group to support contributors.
It would appear that Mullenweg got his wish; De Valk and others went ahead with an independent WordPress project, and it seems to have quite a few people from around the community lending a hand. It will be interesting to see how it evolves and whether the larger community leaves WordPress.org behind.