Almost a year ago, we broke down one of the tech industry’s less covered (but no less impactful) beefs, looking at all the parties involved, their lawsuits, and most importantly, how it was impacting the larger ecosystem and community.

(Quick plug: you can check that out here)

Since then, the lawsuits have only continued and the community is showing signs of finding new, alternate, directions. Today’s piece is a look at what’s happened since our original piece and how the ecosystem has adapted.

First, let’s set some quick context on this entire scenario. In September of last year, Matt Mullenweg (first of his name, current CEO of Automattic, original WordPress developer, launcher of law suits, etc) spoke at a conference about how there were parties out there taking advantage of the open source ecosystem with subtle digs at those parties. He expanded in a blog post shortly after, and dropped all pretense: he specifically accused WP Engine of exploiting the WordPress ecosystem while contributing minimal developer hours compared to their revenue (uh also, along the way, he called them 'a cancer to WordPress' that needed to be stopped.)

This post kicked off a series of events and (legal) actions between a lot of different entities that can be best understood as:

• WP Engine: a managed WordPress hosting provider that has grown to become one of the larger commercial entities in the WordPress ecosystem. They were founded in 2010, acquired by a PE firm in 2018, and subtweeted by Matt in 2024

• Matt Mullenweg: the original WordPress founder, who also happens to be the head of the non-profit WordPress Foundation, CEO of the for-profit company Automattic, and the owner and operator of the WordPress.org site and domain as an individual. Busy guy. The fact that he was all these things uh was not always so well known (take from that what you will)

• WordPress (Open Source Project): outside of all these formal organizations and legal entities, there is a global community of WordPress developers, maintainers, and users who have built one of the most rich and robust open source technologies that the world has ever seen

Our original piece described the back and forth between the organizations mentioned above (lot of legalese and cease and desist vibes), and put out some thoughts on how this would affect the wider community:

• This might continue the web’s splintering era. If this chaos continues for much longer, you could see a huge rise in forks, clones, and derivatives that come to the market to compete with WordPress and fill the newly discovered gap in the world of open platforms. WordPress’s very origins came from forking an earlier project, so this would be an ironic twist.

• It’s increasingly looking like people will need to price in the governance risk from recent events, impacting procurement and security. A dangerous red flag in this whole scenario has been components and plugins being blocked from updating, leading to huge vulnerabilities.

We predicted ecosystem fragmentation and governance risk pricing. Both happened.

• 150 employees left Automattic (Mullenweg offered buyouts to any employees who disagreed with his actions)

• WP Engine had access to critical WordPress infrastructure revoked by Mullenweg, leading many people to uh learn that it could even be revoked in that manner by that person

• CEOs of WordPress agencies like Karim Marucchi felt the governance risk, noting that they “received phone calls from the chief legal counsels of some of our clients—these are large corporations—saying, ‘this is a supply chain security issue,’”

  • Uh since we’re on the topic, here’s some fun reading about supply chains and digital goods (https://sitebolts.com/the-visible-hand-when-digital-supply-chains-meet-geopolitical-reality/, https://sitebolts.com/when-digital-supply-chains-meet-geopolitical-reality-part-ii-electric-boogaloo/

With that supply chain risk in mind, several of the top WordPress contributors and the Linux Foundation began working on the FAIR Package Manager project, a “federated update and plugin-distribution network.” Essentially, their work is focused on creating a federated distribution network—think BitTorrent for WordPress plugins. Instead of one central server controlled by Matt, hosting companies can run their own mirrors while still participating in a unified ecosystem.

Some important highlights of this newest initiative include:

• It is not a “fork” of WordPress. It’s basically server components, focused on package distribution mechanisms rather than core CMS functionality.

• It has 100+ contributors and the Linux Foundation was explicitly brought on for neutral oversight

• This oversight comes in the form of a “technical steering committee” which is led by folks like the architect of the WordPress API, Ryan McCue and includes participation from key people on the Linux side, like Jory Burson (VP of Standards)

Mirror projects aren't new, but FAIR's governance structure reveals something important about what went wrong with WordPress. With the project's repository now public on GitHub, I analyzed its charter, system design, and roadmap, to get a good look at this new entrant.

First, the project charter. Linked here, the charter outlines the mission, scope, and governance details in extremely dry legalese. In plain english, it basically says the following:

• Mission & Scope:

  • Mission: make tools for digital content publishing and a package ecosystem, plus the infrastructure to support those tools.

  • Scope: collaborative development that supports the mission, which includes documentation, testing, localization, integration and whatever else helps the development, deployment, operation or adoption of the open source project.

  Governance Structure:

  • All technical oversight goes to a Technical Steering Committee (TSC) made up of "Organizers"

  • Anyone can become a "Contributor" by contributing code, docs, or other work

  • Contributors can get promoted to "Organizer" status (with commit/approval rights) by majority vote of existing Organizers

  • Company representation is capped - no single company or group of related companies can control more than 30% of Organizer votes

  • The TSC can elect up to 3 co-chairs to run meetings, but co-chairs can't work for the same company

  • All meetings are supposed to be open to the public

  Decision Making:

  • They aim for consensus but can fall back to voting when needed

  • Requires 50% attendance for quorum at meetings

  • Most decisions need simple majority, but some big changes (like license exceptions or charter amendments) need two-thirds approval

  • Can make decisions electronically/asynchronously if needed

  Legal Framework:

  • It's organized under LF Projects (Linux Foundation) as a Delaware LLC

  • Code must use GPL v2+ license with Developer Certificate of Origin sign-offs

  • Documentation uses Creative Commons licensing

  • Contributors keep their copyrights (no copyright assignment required)

  • LF Projects holds all trademarks

  • Must operate "transparently, openly, collaboratively, and ethically"

Looking deeper at the steering committee and contributors, the fact that WordPress leaders like McCue but also Carrie Dils and Mika Epstein are involved, speaks to the fact that this is an initiative with deep ties to the WordPress community. On the other hand, something else to note regarding the governance mechanism and overall distribution of influence is that it is a direct inverse of the centralization of influence under Matt and his multiverse of brands and organizations. See the evergreen meme for a visual of what I mean:

As always, full credit to OP, https://x.com/lazerwalker/status/1845146696483037546)

By creating a committee of people from a variety of organizations with public requirements, this project is creating a decentralized alternative to the existing WordPress.org plugin and theme ecosystem that Matt sits on top of. Of course, as most initiatives that revolve around protocol adoption, network effects continue to be very important. This alternative requires buy-in from a globally distributed community of contributors who may not have as much skin in the game or interest as the leaders and developers of the project .Here’s another visual of what I mean:

Credit to the eternally wise xkcd for the above meme

Getting this buy-in will require execution on an ambitious roadmap and system design (linked here and here) that includes:

• Decentralized Architecture: inspired by Linux Package Distribution, Composer (package manager for the PHP ecosystem), and AT Proto (protocol behind BlueSky, the infamous alternative to the centralized platform formerly known as Twitter), the roadmap puts forward an independent and decentralized architecture made up of: Repository Nodes, Aggregators, and Extras (e.g. Analytics)

• Repository Nodes: servers that provide package zips and certain meta-data about the packages (e.g. name, description, images, FAQ). These nodes are canon and are “fully open to use by anyone.” Basically, they store the actual plugin files and metadata. If you squint, you can see them as sort of individual WordPress.org alternatives that anyone can run—whether for internal company use, public distribution, or a mix of free and premium plugins

• Aggregators: servers that provide any service that collects information about packages into one place (hence, aggregator). Includes directory for package discovery, a way to handle moderation, and other "meta" services. They do not contain zips or core source code, instead they point to the actual Repository Node for the canonical information and downloads

• Analytics: the extra with the most detail actually presented, the analytics module will collect download and usage numbers based on WP installs directly. This introduces an interesting area of tension and break from the cited decentralized inspiration of AT Proto, because as the authors note: “fundamentally, centralised analytics are at odds with a decentralised system.” The compromise being made here is that the analytics component is “intentionally centralised, and as a result, is designed to be outside of the "critical path" of the typical usage.” It’s positioned as a neutral data provider for the common good, but does allow for the other nodes to collect their own data

 

Ambitious might be understating it. They're not just building an alternative plugin directory - they're designing an entire protocol that would let anyone run their own plugin store while still participating in a unified ecosystem. It's like trying to replace Amazon with a network of independent bookstores that all share inventory information. Some of the risks and challenges they’ve already identified include:

• The "ACF Problem": Right now, if WordPress.org gets compromised, a malicious actor could hijack any plugin. Their system uses individual package signing to prevent this

• Vendor Lock-in: Premium plugin companies currently have to hack their way into WordPress's update system with custom solutions

• Discovery Issues: There's no good way to find plugins outside of WordPress.org's directory

• Centralized Control: Matt/Automattic controls the main plugin repository, and there's no real alternative

• Package IDs: They need a way to uniquely identify plugins across the entire decentralized network. They're considering using either domain names (like reverse DNS) or fancy distributed identifiers (DIDs) that would let plugins move between different repository hosts

• Trust and Security: Without a central authority, they need cryptographic signatures and public key infrastructure to verify authentic plugins

• Network Effects: The whole thing only works if lots of people adopt it - classic chicken-and-egg problem

The writing was on the wall when 150 employees took buyouts rather than support a crusade. Now, the WordPress community is voting with its code. FAIR represents more than technical infrastructure—it's a referendum on centralized control that is starting off on Day 1 by putting its money where its mouth is. It’s being offered “to Automattic, WP Engine, GoDaddy, Newfold—everyone,’” says Marucchi, who is also a leader on the project. 

I do want to take a quick victory lap on our prediction last year on the effects that the drama would end up having on industry. The project's success hinges on network effects, but the initial conditions are promising. In the spirit of prediction, I'll throw a new, updated take here: FAIR will succeed. The economics are obvious: hosting providers can't afford governance risk, plugin developers need distribution certainty, and enterprise users require supply chain stability. The convergence of technical leadership, enterprise backing, and community support makes adoption inevitable, not just possible.

References

1. Munroe, R. (n.d.). Standards [Web comic]. xkcd. Retrieved [June 19, 2025] from https://xkcd.com/927/ (xkcd)
2. FAIR Package Manager Contributors. (n.d.). FAIR Package Manager. GitHub. Retrieved [June 19, 2025] from https://github.com/fairpm (GitHub)
3. Linux Foundation Projects. (n.d.). FAIR Package Manager Charter [PDF document]. LF Projects. Retrieved [June 19, 2025] from https://lfx-cdn-prod.s3.us-east-1.amazonaws.com/project-artifacts/fair-package-manager/fair-package-manager_Charter.pdf?v=1749049715416 (LF Projects)
4. FAIR Package Manager Contributors. (n.d.). System design discussion. GitHub Discussions. Retrieved [June 19, 2025] from https://github.com/orgs/fairpm/discussions/24 (GitHub)
5. FAIR Package Manager Contributors. (n.d.). Initial design documentation. GitHub. [Retrieved June 19, 2025] from https://github.com/fairpm/fair-protocol/blob/main/docs/initial-design.md (GitHub)
6. Fast Company. (n.d.). WordPress veterans launch FAIR project to tackle security and control concerns. Fast Company. Retrieved [June 19, 2025] from https://www.fastcompany.com/91347003/wordpress-veterans-launch-fair-project-to-tackle-security-and-control-concerns (Fast Company)

 

Disclaimer