The WordPress ecosystem is on fire, and not in a good way. What started as pointed remarks from Automattic CEO Matt Mullenweg at WordCamp US has spiraled into one of the most dramatic confrontations in open source history. WP Engine has been banned from WordPress.org resources, cease-and-desist letters have flown in both directions, and the community is left picking sides in a fight that touches the very foundations of how open source projects coexist with commercial interests.
As someone who has watched open source evolve from a fringe movement to the backbone of the modern software industry, I find this situation both deeply concerning and oddly inevitable.
What Actually Happened#
The timeline is dizzying. In late September, Mullenweg publicly called out WP Engine at WordCamp US, accusing them of being a “cancer to WordPress” and claiming they profit from the WordPress brand without giving back proportionally. WP Engine fired back with a cease-and-desist letter. Then Automattic blocked WP Engine’s access to WordPress.org plugin and theme repositories, effectively cutting off automatic updates for millions of sites.
This week, the situation has only intensified. WP Engine filed a lawsuit against Automattic, alleging abuse of power and trademark violations. Automattic, in turn, offered employees a severance package to leave if they disagreed with the company’s stance — and roughly 159 people took the deal.
The technical fallout is real. WP Engine customers couldn’t receive plugin updates for a period, creating genuine security concerns. A temporary reprieve was granted, but the uncertainty remains.
The Governance Problem Nobody Solved#
Here’s the uncomfortable truth that this situation exposes: WordPress never properly separated its open source project governance from its commercial interests. WordPress.org — the repository, the plugin ecosystem, the update infrastructure — is effectively controlled by Automattic. The WordPress Foundation exists, but its role in governing the project’s infrastructure has always been murky.
This is not a new pattern. I’ve seen similar tensions play out in other projects over the decades. The difference is that WordPress powers roughly 43% of the web. The blast radius of a governance failure here is enormous.
Compare this to how other major projects handle the divide. The Linux Foundation, the Apache Software Foundation, the Cloud Native Computing Foundation — they all maintain explicit separation between the open source project and any single commercial entity. It’s not perfect, but it creates checks and balances.
WordPress never built those guardrails, and now we’re seeing why they matter.
The “Giving Back” Debate#
Mullenweg’s core argument is that WP Engine doesn’t contribute enough to the WordPress open source project relative to the revenue they generate from it. He’s proposed a framework suggesting that large WordPress hosting companies should dedicate a percentage of their resources to core development.
There’s a kernel of truth here. Free-riding on open source is a real problem, and many companies do extract enormous value from projects they barely contribute to. But the way this argument has been weaponized — using control over project infrastructure to punish a commercial competitor — sets a terrifying precedent.
If the maintainer of an open source project can unilaterally cut off access to critical infrastructure because they feel a company isn’t “contributing enough,” then every business built on open source should be worried. Who decides what “enough” means? By what process? With what accountability?
I’ve been building software on open source foundations for three decades. The social contract has always been: the code is free, you can use it commercially, and contributions are welcomed but not coerced. Breaking that contract — even with good intentions — damages trust that took years to build.
What Developers Should Watch For#
If you’re running WordPress sites (and statistically, many of you are), here’s what to pay attention to:
Update infrastructure: Make sure you have a plan for plugin and theme updates that doesn’t solely rely on WordPress.org. Consider manual update workflows as a backup.
Hosting diversification: If you’re on WP Engine, you’re directly affected. But even on other hosts, think about what happens if this pattern repeats with a different target.
Fork potential: There’s already talk of forking WordPress. Whether that materializes depends on how this conflict resolves, but it’s worth monitoring. A fork would fragment the ecosystem but could also lead to better governance.
Plugin dependencies: Audit which plugins are critical to your sites and whether they have alternative distribution channels.
My Take#
I have enormous respect for what Matt Mullenweg has built. WordPress democratized web publishing in ways that changed the internet. But this approach — using infrastructure control as a weapon in a commercial dispute — is wrong, regardless of how valid the underlying complaints about contribution might be.
The open source world needs to have an honest conversation about sustainability and fair contribution. But that conversation needs to happen through governance structures, not through unilateral executive action. The WordPress Foundation should be the entity making decisions about WordPress.org access, with transparent policies and due process.
What we’re witnessing is what happens when a project grows to dominate a significant portion of the web without ever building the institutional frameworks to match that responsibility. It’s a cautionary tale for every open source project that’s outgrowing its governance model.
The code may be open, but the power structures around it matter just as much.
This is part of my Developer Landscape series, tracking the trends and shifts that shape how we build software.