BuddyX

13 min read · 2,584 words

The WordPress Dilemma: Dictatorship or Democracy? A Response to Jack Arturo’s Concern

The WordPress Dilemma: Dictatorship or Democracy? A Response to Jack Arturo’s Concern

In October 2024, Jack Arturo, founder of Very Good Plugins, maker of the popular WP Fusion integration plugin, posted a tweet that captured a frustration a lot of WordPress developers had been quietly sitting with for years: “I have no time for dictators, especially ‘benevolent’ ones. 43% of the web is too much to be at the whim of a single person.” He floated the idea of some kind of governing committee replacing single-person leadership over the project. At the time, it read as one respected developer’s provocative opinion piece, worth a response but not obviously the start of anything larger.

Revisiting that post now, with a full picture of what followed, it reads less like an isolated complaint and more like the opening line of a story most of the WordPress world ended up living through over the following year.

It turned out to be a preview. Within weeks of that tweet, the dispute Arturo was gesturing at stopped being theoretical and became the most consequential governance crisis in WordPress’s two-decade history, one that’s still reshaping how the project’s infrastructure works.

What actually happened after that tweet

In September 2024, WordPress co-founder Matt Mullenweg publicly and sharply criticized WP Engine, a major managed WordPress hosting company, accusing it of profiting heavily from the WordPress ecosystem while contributing comparatively little back to core development, and of misusing the “WP” branding in ways that implied an official relationship with WordPress that didn’t exist. WordPress.org, the nonprofit-adjacent infrastructure that hosts the plugin and theme directories most WordPress sites depend on for updates, then blocked WP Engine’s servers from accessing those update systems, which meant WP Engine’s customers temporarily couldn’t pull plugin and theme updates through the normal channel. WP Engine sued, alleging attempted extortion tied to licensing demands around the WordPress trademark; Automattic, Mullenweg’s company, countersued. A court later ordered access restored while litigation continued.

The dispute escalated further when Automattic took control of Advanced Custom Fields (ACF), one of the most widely used plugins in the entire WordPress ecosystem, owned by WP Engine after its acquisition of the plugin’s original developer, and republished it under a new name, Secure Custom Fields, without the owning company’s consent. Using WordPress.org’s administrative control over the plugin directory to take over a competitor’s actively maintained product was something the community had never seen happen at this scale, and it turned a business dispute between two companies into a much broader question: if the infrastructure millions of sites depend on for updates can be used as leverage in a commercial fight, what does that mean for everyone else building on WordPress, entirely unrelated to the original dispute?

Why this went beyond a two-company dispute

The ACF takeover specifically is what turned Arturo’s tweet from an opinion into something a much wider swath of the developer community started taking seriously. A plugin’s identity, its brand, and its update channel had always been treated as safe from that kind of unilateral action, regardless of how large or commercially successful it became, that assumption was part of the implicit trust that made WordPress’s open ecosystem work at all for a company building a business on top of it. Once that assumption broke, even developers with no direct stake in the WP Engine dispute had reason to ask: could this happen to my plugin, my theme, my business, if I ever end up on the wrong side of a disagreement with the people who control the update infrastructure?

Automattic offered its own employees a buyout for anyone who disagreed with the company’s direction on the dispute, and a meaningful share of staff took it, a visible signal that the disagreement wasn’t confined to outside critics but extended inside the company steering the project itself. Prominent contributors across the ecosystem publicly stepped back from volunteer core contribution work, citing the concentration of authority the episode had exposed.

What Arturo and others were actually proposing

The core proposal, echoed independently by other voices in the community around the same period, including governance-focused commentary specifically arguing WordPress needed more structured, inclusive leadership rather than decisions resting with one person, wasn’t a call to abandon WordPress or dismiss what Mullenweg’s leadership had accomplished. Gutenberg, the block editor, and WordPress’s sustained relevance through multiple platform shifts over two decades happened under that leadership model, and few serious critics dispute that record. The argument was narrower and more structural: that a project powering roughly 43% of the web had outgrown a governance model where trademark control, plugin-directory administration, and update infrastructure all sit under the discretion of one person and one company, with no independent check on how that authority gets used.

The proposed alternative, some form of steering committee or foundation-style governance, distributing decision-making authority the way Python’s Python Software Foundation or the Linux Foundation structure oversight of their respective projects, wasn’t a new idea invented in this dispute. It’s the standard governance pattern for open-source projects that reach WordPress’s scale, and the 2024 crisis is what turned a longstanding, mostly theoretical suggestion into something with real, immediate urgency behind it.

What’s changed since, concretely

The most tangible outcome has been the emergence of community-built infrastructure explicitly designed to reduce dependency on any single centralized authority over plugin and theme distribution, independent initiatives building alternative repository and update mechanisms that don’t route through wordpress.org’s existing chokepoints. That’s a direct, practical response to the exact vulnerability the ACF episode exposed: as long as every WordPress site’s plugin updates flow through one gatekeeper, that gatekeeper has leverage nobody had fully reckoned with until it got used. Building genuine redundancy into that infrastructure, even partially, is the closest thing to Arturo’s “committee” proposal that’s actually materialized, not through Automattic adopting new formal governance, but through parts of the community building around the risk rather than waiting for it to be resolved from the top down.

The litigation itself has continued working through the courts on a timeline separate from the community response, with both sides pursuing their claims rather than reaching a quick settlement. It’s the kind of dispute that will likely take years to fully resolve through the legal system, independent of how the community-level governance conversation evolves in the meantime, court timelines and open-source governance debates simply don’t move on the same schedule, and treating the two as though they’ll resolve together is a mistake worth avoiding when trying to read where things actually stand.

What this means if you’re running a WordPress business today

For a plugin or theme developer, an agency, or anyone whose livelihood runs through WordPress, the practical lesson isn’t “WordPress is unsafe to build on”, the platform’s install base, the plugin ecosystem’s depth, and its overall stability haven’t meaningfully changed for the average site owner running standard core, theme, and plugin updates day to day. The lesson is narrower and more specific: understand exactly where your dependency chain runs through centralized infrastructure you don’t control, and factor that into how much single-point risk you’re comfortable carrying. A business built entirely around a plugin distributed solely through the official directory, with a brand that could theoretically become a target if it ever grew large enough to draw the kind of attention WP Engine did, is carrying a different risk profile than one with more diversified distribution.

That’s not paranoia, it’s the same kind of platform-risk thinking anyone building on any dominant platform (an app store, a cloud provider, a social media API) should already be doing, and the 2024 dispute simply made the WordPress-specific version of that risk visible in a way it hadn’t been before, for a community that had largely never needed to think in those terms.

Did this actually affect ordinary site owners, or just the developer community?

It’s worth answering this directly, since a lot of the coverage understandably focused on the dispute between two companies and the philosophical governance debate it triggered, which can make it hard to tell whether an average small business running a standard WordPress site actually needs to care. The most direct real-world impact was narrow but genuine: WP Engine customers specifically experienced a period where automatic plugin and theme updates through the standard wordpress.org channel were blocked, which meant sites on that host needed to rely on manual update workarounds or their host’s own tooling during that window. For the vast majority of WordPress sites hosted elsewhere, day-to-day functionality, publishing, plugin updates, theme changes, continued completely normally throughout the entire dispute, since the block was targeted specifically at WP Engine’s infrastructure rather than the update system broadly.

The more diffuse impact, for site owners who never noticed any functional disruption at all, is the erosion of a certain kind of unexamined trust, the assumption that the infrastructure underneath a WordPress site is neutral, predictable, and immune from being used as leverage in a business dispute. That assumption held for two decades without serious challenge. Whether or not it affects your specific site’s day-to-day operation, it’s a reasonable thing to know about if WordPress underpins any part of a business you depend on, the same way it’s reasonable to understand the terms of service and platform risk of any other piece of critical infrastructure, even if you never expect to personally run into trouble with it.

How other open-source projects handle this, for comparison

It’s worth looking at what the alternative governance models Arturo and others pointed toward actually look like in practice, since “a committee” can mean very different things depending on the implementation. The Python Software Foundation oversees the Python programming language through an elected steering council, with the language’s original creator having formally stepped back from unilateral authority years ago specifically to distribute that decision-making power more broadly, a deliberate, negotiated transition rather than one forced by an external crisis. The Linux Foundation operates as a neutral, vendor-independent nonprofit hosting body for the Linux kernel and a large number of other open-source projects, structurally separating the organization that holds infrastructure and trademark authority from any single company’s commercial interests. Drupal, a WordPress peer in the CMS space, is governed through the Drupal Association, a nonprofit with an elected board, membership structure, and formal decision-making processes distinct from any single company’s ownership.

What each of those models shares is a structural separation between “who does the technical work” and “who holds ultimate authority over trademark, infrastructure, and direction”, a separation WordPress has never formally had, since Automattic (Mullenweg’s company) and the WordPress Foundation (which holds the trademark) have always been closely intertwined with his personal leadership rather than operating as genuinely independent bodies. That’s the specific structural gap the 2024 crisis exposed, and it’s the gap any future governance reform would need to actually close rather than paper over with new titles on the same underlying arrangement.

How hosting companies and the broader ecosystem responded

The dispute didn’t stay contained to Automattic and WP Engine, it forced every major WordPress hosting company and plugin business to think concretely about their own exposure to the same kind of risk, even those with no direct involvement in the original disagreement. Some hosting providers publicly reaffirmed commitments to open-source principles and community-controlled infrastructure as a competitive differentiator, positioning themselves as safer, more predictable partners specifically in contrast to the uncertainty the dispute had introduced. Others quietly began evaluating contingency plans for plugin distribution and update delivery that didn’t depend entirely on wordpress.org’s infrastructure remaining neutral and predictable, the same kind of thinking that produced the independent repository initiatives mentioned above, just happening at a business-planning level rather than a pure developer-tooling level.

For plugin and theme businesses specifically, the episode prompted a wave of genuine reconsideration about distribution strategy, how much to rely on the official directory alone versus building direct-sale channels, and how defensible a product’s brand and trademark position actually was if it ever grew large enough to draw the kind of scrutiny WP Engine did. None of this was really new advice, diversifying distribution and understanding platform risk has always been sound business practice, but the crisis made the abstract argument concrete and urgent in a way it hadn’t been before for a lot of smaller developers who’d never seriously considered it.

Practical guidance for choosing a WordPress host or plugin dependency today

For anyone making real business decisions in this environment rather than just following the news, a few practical questions are worth asking that weren’t as pressing before 2024. When evaluating a hosting provider, it’s worth understanding how they’ve positioned themselves relative to this dispute and what contingency plans, if any, they have for update delivery disruption, not because disruption is likely on any given day, but because the 2024 episode proved it’s no longer a purely theoretical risk. When choosing which plugins to build a business-critical workflow around, it’s worth favoring options with either a broad enough install base that unilateral action against them would be reputationally costly, or a clear independent distribution channel beyond the official directory alone, over a narrower, single-channel dependency. None of this requires panic or a wholesale rethink of using WordPress, it requires the same kind of ordinary platform-risk diligence any serious technology decision deserves, applied to a risk that’s now demonstrably real rather than hypothetical.

Where the governance conversation actually stands

Arturo’s original framing, dictatorship versus democracy, was always a simplification of a more complicated reality, and it’s worth being honest about that rather than treating either pole as fully accurate. WordPress was never a pure dictatorship in the sense of one person personally reviewing every decision; a large, distributed contributor base has always done the actual work of building the software. But it also wasn’t a democracy in any formal sense, there’s never been a voting body, a board with independent authority, or a mechanism for the broader community to overrule a decision about the project’s central infrastructure. The 2024 crisis didn’t create that structural reality; it just made the consequences of it impossible to ignore.

Whether WordPress ends up with a formal governance body years from now, or whether the informal, community-built redundancy that’s emerged since 2024 becomes the de facto answer instead, the debate Arturo’s tweet crystallized isn’t settled, and it shouldn’t be treated as resolved just because the initial news cycle has passed. For anyone with a real stake in WordPress’s future, which, at the scale the platform operates, is a genuinely large share of the web, it’s worth staying engaged with how this actually plays out rather than assuming the crisis that started in late 2024 was a one-time event rather than a preview of a structural question the project still hasn’t fully answered.

A final word on Jack Arturo’s original point

Reading his tweet again with the benefit of hindsight, what stands out isn’t that he predicted the specific shape the crisis would take, the ACF takeover, the lawsuits, the employee buyouts, none of that was foreseeable from a single tweet about governance philosophy. What holds up is the underlying diagnosis: that concentrating this much authority over infrastructure this many businesses depend on, in one person, was a structural risk regardless of how well-intentioned or historically successful that person’s leadership had been. Good leadership reduces the odds a latent structural risk gets triggered; it doesn’t eliminate the risk itself. That distinction is worth sitting with, whichever side of the “benevolent dictator” debate you land on personally, because it’s the actual argument underneath the more provocative framing, and it’s an argument that outlasted the specific dispute that made it suddenly urgent.

Reading
13 min · 2,584 words
Published
Oct 7, 2024
Shashank Dubey
BuddyX contributor

Writing about WordPress communities, BuddyPress, BuddyBoss, LMS plugins, and the business of paid communities.

Keep reading

More from the BuddyX blog

Browse all posts on community, WordPress, BuddyPress and the studio of plugins behind BuddyX.