WordPress governance risk business owners keep ignoring

On 9 September 2026 Automattic's board placed founder Matt Mullenweg on paid leave against his wishes, with CFO Mark Davies stepping in as interim CEO. Mullenweg remains on the board, and remains leader of the WordPress project.

If your storefront runs on WooCommerce, that last sentence is the one that matters. The WordPress governance risk business owners carry has always been structural rather than technical, and it just became visible enough to put on paper.

What actually happened

Per TechCrunch's reporting, board members including the CFO, Ann Dunwoody, Toni Schneider and Sue Decker initiated the action. The article does not state the board's rationale.

WordPress.org's executive director Mary Hubbard was explicit that the open-source project is unaffected: Matt remains the leader of the WordPress project, she remains executive director, and teams, priorities and work continue as planned.

Take that statement at face value and it is reassuring about continuity. Read it structurally and it describes something new: the commercial company and the open-source project, previously aligned through one person holding both roles, now have that person accountable to a board in one and not in the other.

Running underneath is litigation with WP Engine, ongoing since October 2024, arising from Mullenweg's position that WP Engine profits from WordPress without contributing back and his demand for an 8% royalty.

Why a business should care about any of this

The instinct is that this is industry gossip. For most software it would be. WordPress is different for a specific, boring reason: an unusual amount of commercial infrastructure depends on decisions made by a small number of people in a project with no conventional corporate governance over it.

The WP Engine dispute already demonstrated the mechanism. A commercial disagreement produced changes in access to project infrastructure, and businesses who had made no decision and taken no side found their hosting arrangements caught in it. Whatever the merits, the lesson for a dependent business is the same: the thing you depended on was not only the software.

This is not an argument that WordPress is unsafe. It powers an enormous share of the web and will continue to. It is an argument that the risk you are carrying is a governance risk, not a technical one, and governance risk does not show up in an uptime report.

What your actual dependency chain looks like

Most WooCommerce businesses have never drawn it. Written out, it runs roughly: your revenue, on your storefront, on WooCommerce, on WordPress core, on the plugin ecosystem, on WordPress.org infrastructure for updates, on the project's governance.

Every layer above the last is software you could in principle fork, host or replace. The last one is not software. It is a set of decisions about who may publish to the plugin directory, whose updates reach your site, and what the project does next — and it has never had the kind of foundation-based governance that insulates, say, Linux or Kubernetes from any single company's internal politics.

The three questions worth answering this quarter

Not "should we leave WordPress". That is almost always the wrong question and the answer is almost always no. These are better.

Could you keep taking orders if wordpress.org were unavailable for a month? Not permanently — for a month. If the answer depends on nothing needing an update in that window, you have a dependency you have never tested. Sites that pull updates from a single origin should know what happens when that origin is unavailable, the same way you would for any other supplier.

How many of your plugins have one maintainer? This is the more likely failure and it has nothing to do with the board. Commercial plugins carrying checkout, tax or shipping logic are frequently maintained by very small teams. Count them, and note which ones would stop your checkout if abandoned.

Where does your customer and order data actually live, and how do you get it out? The realistic mitigation for platform risk is not a migration plan on a shelf. It is knowing that your data is exportable in a usable form, tested, on a schedule. Businesses discover the gaps here at exactly the moment they can least afford to.

How this compares with the alternatives

It is worth being even-handed, because every alternative carries the same class of risk in a different shape.

A hosted platform replaces governance risk with commercial risk. Shopify or BigCommerce cannot have a board dispute that changes your plugin directory, but they can reprice, deprecate an API you depend on, or change terms — and you have no fork available at all. What you gain is a contract and somebody accountable for uptime.

A foundation-governed open-source stack spreads the decision-making across organisations, which is exactly the insulation WordPress lacks. The trade is a smaller ecosystem: fewer plugins, fewer agencies who know it, more work you do yourself.

Fully custom removes third-party governance from the equation and makes you the governance. That is the right answer far less often than it is proposed, and it is only defensible when the commerce logic itself is a differentiator rather than a cost.

None of these is safer in the abstract. They relocate the risk to a place you may prefer, and the useful exercise is deciding which kind of surprise your business could absorb.

What we tell clients on WooCommerce

We build and modernise e-commerce platforms, and we are asked whether to stay on WordPress more often than any other platform question. The honest answer has three parts, and it has not changed this week.

Stay if the platform fits. For a catalogue business with standard fulfilment and a content-heavy front end, WooCommerce is a good answer and replacing it is a large cost for a small benefit. Governance risk is a reason to prepare, not to migrate.

Reduce coupling where it is cheap. Keep customer and order data exportable and exported. Keep business logic that is genuinely yours — pricing rules, fulfilment workflow, anything a competitor could not copy — out of plugins and behind your own service where practical. This is good architecture regardless of who runs Automattic.

Reconsider the platform when the fit breaks, not when the news breaks. The signals that justify moving are operational: checkout logic that has outgrown the plugin model, performance you cannot fix, or a workflow you keep bending the platform to accommodate. Those are the same signals as in any custom versus off-the-shelf decision, and none of them appeared on Tuesday.

The cheapest insurance available

One practice covers most of this and almost nobody does it: take a restorable backup of the whole stack — database, uploads, plugin versions, theme — to storage you control, on a schedule, and restore it somewhere else once a quarter.

Not because Automattic is going to disappear. Because a restore you have never performed is a hypothesis, and the failure modes that matter here are all the same shape: something you depend on stops behaving the way it did, and your options are determined entirely by whether you can stand the site up somewhere without it.

The quarterly restore is what converts "we have backups" into a known recovery time. Teams that run it discover the gaps in an afternoon — a plugin licence tied to a domain, an upload directory nobody was capturing, a database user that only exists on the live host. Teams that do not run it discover the same gaps under pressure, with the shop down.

The general lesson, which is not about WordPress

Most businesses maintain a risk register for suppliers they pay and none for the ones they do not.

Your payment processor is on it, because there is a contract and an invoice. The open-source project your entire storefront is built on is not, because it is free, it has always worked, and there is no account manager to ring. The absence of a bill is doing a lot of work in that reasoning.

The fix is not paranoia. It is a single line in the register naming each critical open-source dependency, who governs it, and what you would do for ninety days if that governance produced an outcome you did not like. Most entries take ten minutes and stay unchanged for years. The value is having written it before you need it.

If you would like a second read on your own chain — what is genuinely load-bearing and what only looks it — that is a short conversation, and it is worth having while nothing is on fire.