Over the past year and a half, the WordPress ecosystem has been consumed by the dispute between Automattic and WP Engine. The legal battles, the public confrontations, the hostile takeover of Advanced Custom Fields. I’ve written about these events as they unfolded. A lot of people have. A lot of opinions have been shared, from all sides.

Most of that conversation has focused on the people involved. On who said what, who was right, who went too far. And while those conversations have their place, they’ve been a distraction from something more fundamental. A structural problem that was there long before this dispute started, and will be there long after it ends.

Earlier this week I wrote about the silence in the WordPress ecosystem. The fear that keeps so many developers from voicing unpopular opinions. After nearly twenty years in this ecosystem, I’ve been part of that silence for too long. This post is me following through on breaking it. And I’ll warn you upfront. This one might be uncomfortable.

A structural problem hiding in plain sight

WordPress.org, as it currently operates, is a single point of control over the distribution of plugins and themes. One entity controls the plugin directory. One entity controls the update mechanism. One entity decides who gets to distribute their work through the most important channel in the ecosystem.

That’s not a governance flaw that emerged during a crisis. It’s the architecture. And the events of the past year simply showed us what that architecture looks like under stress.

I want to be clear about what I’m arguing before I go further. I’m not suggesting that anyone should leave WordPress.org.

The plugin directory has real value as a discovery channel, and the people who’ve maintained that infrastructure deserve respect for that work. What I am arguing is that it should be one channel among several. Not the only one that matters. That we should treat distribution the same way we’d treat any other critical dependency: With decentralisation and fallback options, and with a clear understanding of what we’re trading for convenience.

What the ACF takeover actually proved

When WordPress.org took control of the Advanced Custom Fields plugin it demonstrated something that every plugin developer should have taken note of.

It proved that the infrastructure we all depend on for distributing our work can be used against us. Not theoretically. Not hypothetically. Actually. In practice. On a Saturday.

You can agree or disagree with the justification. That’s not the point. The point is that the capability exists and it has now been exercised. And if it can be exercised against WP Engine, it can be exercised against anyone.

That’s not fear-mongering. It’s a structural observation. When a single entity controls the primary distribution channel and the update mechanism, every developer who depends on that channel is operating at the discretion of that entity. For most of WordPress history, that discretion has been exercised reasonably. But “it’s been fine so far” is not a governance model. It’s a prayer.

FAIR tried to solve this

This is where I want to talk about something that deserves more attention than it has received.

Earlier this year, Joost de Valk and Karim Marucchi announced that they were stopping FAIR as far as WordPress goes. FAIR is the federated package management system they had been building under the Linux Foundation. It was designed to be exactly the kind of alternative the ecosystem needs: A neutral, community-governed infrastructure layer for plugin and theme distribution. Decentralised by design. Not controlled by any single entity.

The technical project worked. They built it. It was real, it was functional, and it was a serious attempt at solving the structural problem I’m describing.

It failed anyway. Not technically, but economically.

The hosting companies and large ecosystem players that would have needed to support FAIR for it to be viable chose not to invest. Not because they disagreed with the premise. But because investment means commitment, cost, political risk and effort. The current situation, however uncomfortable, was predictable and probably safe enough. The status quo won, not because it was better, but because it was easier.

Joost and Karim put it plainly: “You cannot build alternative infrastructure of this magnitude on goodwill alone.”

Here’s the part that should make all of us uncomfortable. In trying to understand why the ecosystem wouldn’t step up, they arrived at an insight that resonated with me deeply. The economic tension underneath all of this is real.

Too many companies benefit from WordPress without contributing proportionally. It’s been this way for years. Matt Mullenweg has been pointing at it loudly. On that specific observation, he’s not wrong. The methods to prove his point have been wrong, in my humble opinion. The damage has been real, while the structural incentive problem remains.

When the companies that generate significant revenue from WordPress are unwilling to invest in a neutral stability layer, that tells you something about the ecosystem’s incentive structure. And it tells you something about the limits of waiting for someone else to fix the problem.

If the ecosystem won’t decentralise, individuals must

This is where my thinking has landed, after watching all of this unfold.

The top-down approach to decentralising WordPress distribution has been tried. It was a credible, well-structured attempt backed by the Linux Foundation. The ecosystem declined to support it. That path, at least for now, is closed.

But decentralisation doesn’t only work top-down. It also works bottom-up.

Individual developers and plugin vendors can take ownership of their own distribution. Run your own update server. Host your own downloads. Build direct relationships with your customers without a mandatory intermediary. Reduce your dependency on WordPress.org not out of spite, but out of a simple principle: When a critical part of your business depends on a single entity you don’t control, you’ve optimised for the wrong thing.

Is this harder than uploading to the plugin directory and letting WordPress.org handle the rest? Absolutely. It means building or adopting infrastructure that you maintain yourself. It means taking responsibility for updates, for distribution, for the customer relationship end to end. That’s real work and I understand why most people would rather not do it.

But we’ve seen the cost of the alternative. We’ve seen what happens when the convenient option turns out to have strings attached that nobody read. And we’ve seen that the ecosystem as a whole is not willing to build the institutional alternative.

So the question for individual developers becomes: Are you comfortable with the current level of dependency, or not?

The WordPress community has always been good at building things. We’ve just accepted centralised distribution as the default for too long. I think it’s time we start building differently. Not by waiting for someone else to build the solution, but by taking ownership of it ourselves.

Where I stand

I’ve been reflecting on my relationship with WordPress for a while now. After nearly twenty years, I still believe in what WordPress makes possible. I still build with it every day. That hasn’t changed.

What has changed is my comfort with the defaults. I’m no longer willing to treat centralised distribution as an inevitability. I’m no longer willing to assume that the current structures will always serve the community’s interests. And I’m no longer willing to stay quiet about it.

The future of WordPress product distribution is decentralised. Not because someone at the top decided it should be, but because individual developers are going to start building it that way. One update server at a time. One direct customer relationship at a time. And I intend to be one of them. Not just in what I write, but in what I build.

That future is going to be less convenient than what we’re used to. Convenience is a wonderful feature. It is also a terrible foundation.