Community or software? You decide which matters most.
Every member of the WordPress community must decide what’s most important: the software or the community.
Instead of attempting to recap the daily actions and the barrage of information, I’d encourage you to keep an eye on bullenweg.com, which seems to be outlining the actions over time. That site clearly has an anti-Mullenweg viewpoint, fwiw.
The Matt Mullenweg and WP Engine saga is dividing the WordPress ecosystem, with some supporting Mullenweg and others questioning the path he's chosen. Whether you agree with Mullenweg or not, his actions have clearly divided an otherwise reasonably balanced community.
To be clear, Mullenweg has caused community frustrations before—this tweet calls out a number of them from over the years. However, this latest saga is definitely the most polarizing, and it’s affected the community more deeply than any prior, partially due to the actions Mullenweg has taken, though I think the primary issue is back to one of definitions, specifically defining and understanding what “WordPress” Mullenweg is protecting.
I promise, this isn’t a “What is WordPress?” post. Okay, it kind of is, but unintentionally so.
Started as a fork of b2 in 2003, at its core, “WordPress” is open source content management software. Over the years, the software itself has grown and matured, allowing it to support a wide range of use cases, from its original purpose as “blogging” software, to powering the websites and digital presences of some of the biggest publishers and largest companies in the world[1].
But, how did WordPress evolve enough to even be considered by publishers and enterprise organizations? What sparked this growth around the world? Large organizations have certainly jumped on the bandwagon, but the initial spark wasn’t enterprise organizations.
The answer? Community.
The WordPress Community grew rapidly. Initially composed of bloggers, engineers, and end users, the community flourished, envisioning new ways of using WordPress, new markets that could benefit from its technology. Tens of thousands of plugins and themes were written, encompassing these new markets and ideas. WordPress, long considered a “blogging” tool, was now a content management system. Or a CRM, or an LMS. WordPress could now be anything. This wasn’t Automattic ideating new ways to use WordPress—rather, this was the community—the ecosystem—using individual expertise and understanding of bespoke markets to implement new ideas atop WordPress.
Certainly, Automattic, with its large presence, capital funding, and ability to push into new markets, contributed to the overall evolution of WordPress. Through its contributions to the software and through its ability to use the right vocabulary with, and provide the right support to, enterprise organizations that sought to adopt WordPress, Automattic was instrumental, especially on the key “blogger” and “enterprise” use cases, embodied in WordPress.com and WordPress VIP, respectively. But, they weren’t alone.
And plugins were only the beginning. As just one example, in the early years, the Japanese WordPress community maintained an effective “fork” of the software, localized to Japanese, with both translation and code modifications. The situation wasn’t ideal, and certainly wasn’t scalable to additional locales. With engineering improvements paid for by Mullenweg, the necessary changes were brought into the WordPress core software, along with better internationalization. This, combined with the strength of the ever-growing event program composed of meetups and WordCamps, meant WordPress was quickly translated into dozens of languages, made available for free on WordPress.org. The promise of one download—one zip file—was finally possible. Hundreds of international markets opened up in a few short years, and WordPress’ influence was further cemented.
The ecosystem continued to grow beyond community contributions. WordPress agencies and hosts spun up rapidly, providing individualized services, based on the specific needs of their markets. Looking for a managed WordPress host? In 2011 there were but a handful. In 2024? Dozens providing a global presence; hundreds with regionalized services around the world. In parallel, agencies numbering from the tens-to-hundreds of thousands exist today, all building on WordPress, all expanding its reach.
Substantial praise should go to Mullenweg for his actions in these early years, for having the vision to let the community thrive and support it in many of the right ways. It wasn’t always perfect, to be clear—Mullenweg has long created controversy[2], both in his actions and his effective control over WordPress, including the WordPress Community[3].
What’s clear, with the benefit of two decades of hindsight, is that the software begat the community begat the software begat the community, and on and on, ad infinitum. These two things are intertwined—WordPress is software, but it’s also a vibrant, diverse, global community, which builds that software and creates an ecosystem around that software, which further grows the community, which further supports the ecosystem.
You cannot separate WordPress-the-software from the WordPress Community. And yet, that’s what we must do, at this stage of Matt Mullenweg and WP Engine saga.
In evaluating the reactions from community and Automatticians alike, there are primarily two camps: those that agree with Mullenweg on his analysis of WP Engine’s contributions, and those that don’t. But, within both camps, there’s a cross section of the community that emphatically does not agree with Mullenweg’s actions.
Mullenweg and I agree on the key argument here: while the community is strong, more contributions would only bolster that strength and ensure WordPress exists in the decades to come. WP Engine’s contributions to, and support of, the ecosystem, while substantial[4], are only a part of what WordPress needs to survive in the long term. Should WP Engine be held to such high standards, with regard to WordPress’ long term survival? I think that’s a key open question.
Still, there have been years-long complaints within the WordPress Community about the metaphorical stranglehold Automattic has on WordPress-the-software. Who oversees WordPress core development? Automattic. Who oversees the Gutenberg project? Automattic. Why is this the case? I’d argue there are two primary aspects at play.
First, Automattic shows up. Mullenweg has put his money where his mouth is—regardless of where you stand on the Five for the Future program[5], a significant portion of Automattic’s team (approximately 5%) are devoted to the WordPress Community, including engineering and design of Gutenberg and core. I would love to see WP Engine devote significant resources to WordPress core development. But, I would love to see everyone devote such resources, from BlueHost, DreamHost, and GoDaddy, to every other host, agency, or plugin development team building for WordPress. And I think devoting resources is considerably more valuable than writing an 8% check to Automattic. If other organizations devoted such significant resources, they would certainly have a seat at the table when building the future of WordPress… Right?
The second aspect to consider is direct access to Mullenweg. While certainly not every Automattic employee interacts with Mullenweg daily, the direct, one-step, or two-step access to the project lead and BDFL mean designers and engineers are able to build and iterate quickly. This is counter to how Mullenweg interacts with the broader WordPress Community. A quick (pre-WP Engine saga) search in Slack, on the make.wordpress.org blogs, and in GitHub/Trac reveals very little public feedback or direction from Mullenweg, beyond an occasional comment. Certainly, Mullenweg must be providing feedback, but it’s happening behind closed doors, within Automattic.
Candidly, I’m not certain this second aspect can be overcome. It would require either a change in overall project governance or a change in the closed behaviours that Automattic employs.
Let’s accept, for the sake of argument, both aspects can be overcome. Let’s accept that every company benefiting from WordPress should give back, specifically to WordPress.org, and should do so relative to the overall size of their WordPress operations (say, 5%). Let’s even say we need this level of dedication from companies, to ensure the survival of WordPress-the-software, long into the future. What is the right approach to establishing this standard, and ensuring companies to devote such resources?
Mullenweg’s actions during this saga have been harsh. There really isn’t another word to describe them. From banning community members because of their employer, to taking over the ACF plugin under the auspices of “security;” the actions taken feel well-beyond reasonable. Imagine if another ecosystem took these actions? In fact, go read this post from David Heinemeier Hansson (DHH), the BDFL of Rails, and a person I rarely agree with. Here’s an excerpt:
Imagine this happening on npm? Imagine Meta getting into a legal dispute with Microsoft (the owners of GitHub, who in turn own npm), and Microsoft responding by directing GitHub to ban all Meta employees from accessing their repositories. And then Microsoft just takes over the official React repository, pointing it to their own Super React fork. This is the kind of crazy we're talking about.
Healthy, robust debate no longer seems possible. Mullenweg appears to be on a war path, with no end in sight, having promised surprises on a daily basis. In turn, the community is reeling.
Twitter/X is filled with messages from community members—to say nothing of the numerous blog posts and messages—mentioning unexpected Slack or WordPress.org deactivations and blocks, without notification or clear rationale. Others have explicitly paused their contributions. Many of these individuals even agree with Mullenweg’s premise that WP Engine should contribute more. There must be another way to wage this war, one that doesn’t entangle the community indefinitely or cause permanent damage to the trust WordPress has built over the past two decades.
What’s clear to me is this: in his effort to protect the future of WordPress-the-software, Mullenweg is sabotaging the WordPress Community, cutting off one’s nose to spite one’s face. This community that helped shape WordPress into a robust platform, opening new markets globally; this community that creates open source plugins, themes, translations, and more. Instead of WordPress being both a thriving community and a stable piece of software, WordPress is rapidly becoming solely software, and solely supported by Automattic.
As the war against WP Engine wages on, Mullenweg has decided that WordPress-the-software is the only thing that matters. Now, every member of the community—including every Automattician—must also choose: community or software? Which is more important to you? Which most embodies “WordPress?”
Will you support the fight against WP Engine, prioritizing Mullenweg’s view that long term contributions are what will make WordPress-the-software survive for the next hundred years, and accepting that his actions will absolutely damage the community built around WordPress over the past two decades?
Or, will you support WP Engine in their counterfight against Mullenweg’s actions, implicitly accepting that massive, private equity-backed corporations do not need to contribute directly to WordPress-the-software, and trusting that the community and software will survive, in spite of non-ideal actors which may slowly spread and poison good actors?
While the community and software have been intertwined since the very beginning, in this moment, Mullenweg has detached them and each of us must consider our options and decide for ourselves.
WordPress expansion and growth in enterprise markets is something I wrote about previously—outlining how much of WordPress growth was built on mundane risk management terms, and how this saga will cause risk management organizations to re-evaluate WordPress. ↩︎
See again this tweet outlining a few of the major ones. ↩︎
On that latter part, throughout WordPress’ history, many have questioned the overall governance of the WordPress project, directly challenging whether WordPress needs a “benevolent dictator for life” (BDFL), which are quite common in the open source space. Those questions often led to organized efforts to rethink the project’s governance. Some of these initiatives had deep consideration—members of the community thought about what a governance structure could look like for a project as large and diverse as WordPress. Parallels have been made to other open source projects, with successful governance structures as well—in the CMS space, both Drupal and Ghost embody structures that allow for more voices within leadership, and less control from a singular individual. But, this also isn’t a “WordPress governance” post. ↩︎
I find it impossible to argue that WP Engine does not contribute to the community. Their support of open source projects like ACF, Local, and Genesis (among others) have been pivotal to WordPress’ growth. Arguing otherwise is disingenuous, at best. What seems at question is whether supporting the community outside of WordPress.org contributions is as “worthwhile” as inside WordPress.org. I say yes, but I can understand the counter argument. ↩︎
See the footnote right above this one. This topic absolutely deserves thoughtful analysis. ↩︎
