WordPress retaliation impacts community

It is too early to say what the outcome will be in the ongoing fight between Automattic and WP Engine, but the WordPress community at large is already the loser. Automattic founder and CEO Matt Mullenweg has been using his control of the project, and the WordPress.org infrastructure, to punish WP Engine and remove some dissenting contributors from discussion channels. Most recently, Mullenweg has instituted a hostile fork of a WP Engine plugin and the forked plugin is replacing the original via WordPress updates.

In the beginning of the Automattic and WP Engine spat, many people hoped that the companies would ratchet down the hostilities—or at least leave it to lawyers to sort out while leaving the larger community out of it. Those hopes have gone unrealized.

WP Engine did try to opt for the legal-only route. The day after the "reprieve" on the WordPress.org ban ended, October 2, WP Engine filed a 62‑page complaint against Automattic and Mullenweg personally, and asked for a jury trial. The suit's claims include contractual interference, computer fraud (for blocking its access to WordPress.org), attempted extortion, libel, and slander. In addition, the suit asks for declaratory judgment that WP Engine is not infringing on or diluting the WordPress, WooCommerce, and other trademarks that Automattic named in its cease‑and‑desist letter.

That is, of course, a move that was unlikely to rebuild any burned bridges between Automattic and WP Engine. It was predictable that the WordPress.org ban would remain in place, that Automattic would respond to the suit, and perhaps countersue WP Engine. However, to date, there has been no indication of a countersuit or response to WP Engine's lawsuit. Instead, Mullenweg is using other means to cause problems for WP Engine—and those tactics have spilled over to the wider WordPress community in troubling ways.

The checkbox

Participating in the development of WordPress is not realistically possible without logging into the site. Using WordPress.org is mandatory for those who would like to contribute and update plugins, access the WordPress Trac (bug tracker) instance, and more. On October 9, a new checkbox was added to the account login form on WordPress.org which reads "I am not affiliated with WP Engine in any way, financially or otherwise." If the box is left unchecked, users will get a prompt to check the box if they wish to proceed.

Naturally, many contributors had questions about this new checkbox, since its wording is ambiguous and any possible consequences are murky. It seems clear it would apply to those employed by WP Engine, but just how far does "financially and otherwise" go? Does this apply, for example, to employees of the many companies that host their clients' web sites on WP Engine? Customers with a subscription to one of WP Engine's services? A number of contributors have sought answers about this policy in the WordPress Slack, with disappointing results. A handful have reported being banned from the Slack instance after these conversations, either due to pressing for answers or questioning Mullenweg's leadership.

Javier Casares shared that his account was deactivated after he asked a series of questions in a Slack thread started by Colin Stewart. (Note that one needs to have a WordPress.org account, and be signed in, to request an account on the WordPress Slack.) In the thread, Mullenweg said that the value of the checkbox is not stored, but refused to clarify what qualifies as an affiliation with WP Engine. He advised those who had questions to "consult a lawyer".

Casares said that most people agree that WP Engine should contribute more to WordPress, but that using WordPress.org as part of the battle is counterproductive. He asked on Slack that the language be changed to indicate a user does not work for WP Engine, but that suggestion was not taken up.

Pick a side

Another participant, Terence Eden, asked on Slack whether he could send pull requests via GitHub if he was affiliated with WP Engine. After an exchange with Mullenweg that was less than helpful, Eden replied:

I've never seen anyone spread so much FUD about their own project before. I started out as sympathetic to your cause against WP Engine. But your behaviour has driven me - and many other good people - away.

He later reported on Mastodon that his account was deactivated. Andrew Hutchings, a contributor who works on WordPress as part of his work with the MariaDB Foundation, participated in the conversation as well. He wondered on Slack how many individual contributors could afford a lawyer to advise about the checkbox and added "I work for a different Foundation, one that definitely cannot afford a lawyer for me to contribute." He wrote on his blog about being banned and said that he just wanted to work on the project:

I think I speak for many in the WordPress community / ecosystem when I say that we don't want to take sides in this battle. We don't want to be forced to take sides via a checkbox. We just want to get work done, to improve WordPress for everyone.

That may not be an option. During the checkbox discussion in the #meta Slack channel Alex Sirota said: "Do you not understand what is happening here? It's pretty simple in my opinion: you have to take a side." Stewart said that if that was the intention, then Mullenweg could say so himself. Shortly after, Mullenweg said, "I want you all to be informed and involved. Not to stay on the sidelines." Sirota's account has also been deactivated now, though it is not clear whether he was banned or deactivated the account himself.

Mullenweg had also asked Automattic employees to pick a side, shortly after banning WP Engine from WordPress.org. He wrote on October 3 that Automattic had extended an "Alignment Offer" to its employees. The company provided a buyout package of $30,000 or six months of salary (whichever was higher) to employees who wanted to leave because they disagreed with Mullenweg's actions. Employees who accepted the buyout were immediately terminated and are not eligible for rehire. According to the post, 159 people⁠—⁠8.4% of the company⁠—⁠accepted the offer.

Advanced Custom Fields

WordPress's popularity has a lot to do with its plugins and themes. A vanilla WordPress installation is missing a lot of features that one might want or need to run a web site: backups, commerce features, statistics, contact forms, search-engine optimization (SEO), managing URL redirects, or adding additional content types to WordPress.

A large ecosystem has sprung up around WordPress to offer services via those plugins, paid versions of plugins with additional functionality, and paid themes to simplify site design. In turn, that helps solidify WordPress's place as the most popular content-management system (CMS) on the web.

WP Engine produces popular plugin called Advanced Custom Fields (ACF), which has more than two million installs through WordPress.org. It allows developers to add extra content fields (called custom fields) to WordPress's edit screens. This might be used, for example, as part of adding a date picker or an interface to create photo galleries for a site. ACF is, in turn, used by or in conjunction with a large number of other WordPress plugins such as Advanced Forms for ACF and WPML for translating WordPress sites.

The base ACF plugin is free, but it also has a paid version ("ACF Pro") with a yearly subscription. Both are available under the GPLv2, but users must pay for access to updates on the Pro version and those come directly from WP Engine.

On September 28, Mullenweg asked on Slack whether ACF Pro should be included in WordPress core, the components and functionality included in a default install of WordPress. That drew mixed responses in the channel. Some users noted that the ability to add custom fields was long overdue, but others had qualms about taking over ACF Pro "out of spite". Richard Korthuis asked what kind of message it would send to other developers who create paid plugins: "No matter what you think about WP Engine and the whole dispute, this [sends] developers the wrong message and would prevent future investments in new plugins".

In a now-deleted Tweet, Automattic announced on October 5, a Saturday, that it had "responsibly disclosed a vulnerability" in ACF to WP Engine. The company did not provide further details. John Blackbourn, the WordPress core security team lead, said that Automattic had breached the Intigriti Code of Conduct by "irresponsibly announcing" the vulnerability publicly. Intigriti is a company that runs bug-bounty programs for companies, including WP Engine.

On October 7, WP Engine announced a security release of the plugin. The vulnerability itself seems to be minor, according to the release notes. It is not a flaw that can be exploited remotely and it only impacts "the unlikely scenario" where a user with administrative privileges tries to attack other administrative users, or tries to gain super-admin privileges on a multi-site installation of WordPress. So far few other details on the vulnerability beyond that have been provided. Another XZ backdoor it is not.

Because its developers are now blocked from WordPress.org, WP Engine had to provide its fix to the WordPress Security team to have it uploaded to the plugin directory. There are also instructions on updating the plugin manually to receive updates directly from WP Engine.

ACF fork

Mullenweg made an announcement on October 12, another Saturday, "on behalf of the WordPress security team" that ACF was being forked as Secure Custom Fields (SCF) under point 18 of the plugin directory guidelines. That part of the guidelines states, in part, that WordPress.org may "remove developer access to a plugin in lieu of a new, active, developer" and "make changes to a plugin, without developer consent, in the interest of public safety". According to the post this move was "a rare and unusual situation brought on by WP Engine's legal attacks".

Automattic has not merely forked the ACF code and made it available under a new name to compete with WP Engine. That might raise a few eyebrows, but it would probably be considered fair game by most observers.

Instead, it has forked the code and taken over the plugin's entry, including all of its reviews, in the WordPress.org catalog. The new plugin is being substituted in place of ACF for all of the users who have installed it previously. According to the announcement on WordPress.org, sites that auto-update plugins will receive the SCF plugin automatically. Some site owners may be unaware that the plugin has been silently replaced. According to a comment by Mullenweg on Hacker News on October 14, there have already been 225k downloads of the new plugin, and he estimated "at least 60% of the sites with auto-upgrade on and using .org for updates" have been moved to the fork.

This is not the first time a company has taken control of a package distributed through a central repository, though it is rare. The left-pad incident in 2016, for example, saw npm, Inc. restore left-pad to the Node.js package repository after its developer, Azer Koçulu, removed it. That move, however, was intended to reduce disruption to the Node.js ecosystem: the removal had broken builds for thousands of projects that had included the package, and Koçulu had effectively abandoned it.

The takeover of ACF's place in the WordPress directory, on the other hand, is a punitive move by Automattic against another company that reaches beyond WordPress.org's infrastructure into millions of WordPress installs. Web developer Charles Fulton wrote about the incident and said that this is "a profoundly destabilizing action for the WordPress plugin ecosystem"; he wondered if he needed to worry about updates to core WordPress that might interfere with ACF Pro.

WPGraphQL brought into the fold

Users of ACF Pro that depend on the WPGraphQL and WPGraphQL for Advanced Custom Fields plugins may have real cause to be concerned that Automattic will look to break compatibility for ACF. WPGraphQL provides a GraphQL schema and API for WordPress sites and is a popular plugin to use in conjunction with ACF. Jason Bahl, the maintainer of the plugin, announced on October 7 that he was leaving WP Engine to join Automattic. Additionally, he said that WPGraphQL is becoming a "canonical plugin" for WordPress.

The concept of canonical plugins is loosely defined, but Mullenweg described them in 2022 as official plugins that are the first choice for a type of functionality, but too niche to be included in the core distribution. With WPGraphQL development under Automattic's roof, it seems unlikely that compatibility with ACF will be a priority.

Scott Kingsley Clark, who has been involved in a project to bring a fields API into the WordPress core, announced on October 13 that he was stepping down from contributing to WordPress core. The fields API project on GitHub has been archived with a goodbye notice that states that it pains him to stop but that he is "done making excuses for Matt's actions and will not associate myself with core any longer". He added on Mastodon.social that he was going to remain part of the WordPress community overall, and continue working on the Pods plugin.

What next?

What happens next, what Mullenweg will do next, is anyone's guess. Mullenweg's vendetta against WP Engine has spilled over into the community in a way that can't easily be ignored or avoided. His leadership of the project is being repeatedly called into question by contributors, users, and outside observers. That will spill over, if it hasn't already, into the wider commercial ecosystem and have serious consequences for plugin creators, creative agencies, and hosting providers who have invested a lot into WordPress.

More contributors are likely to step away, whether they do so publicly or simply drift away and find other things to do with their time. Quite a few users on social networks have commented that they would no longer recommend WordPress and are looking for alternatives. A fork, in addition to ClassicPress, seems almost inevitable.

There is a legitimate conversation to be had, or continued, about the commercialization of open-source projects by companies that do little to sustain open-source software but reap its benefits and pull revenue away from the companies that do put in the work. That conversation has been completely eclipsed by Mullenweg's actions to punish WP Engine.

Mullenweg the "mad king"

Armin Ronacher, creator of the Flask web framework for Python and participant in launching the Open Source Pledge, has some interesting thoughts on the topic of mixing money and open source in light of the ongoing WordPress crisis:

Is it a wise [idea] to mix Open Source and money? Maybe not. Yet I also believe it's something that is just a reality we need to navigate. Today there are some projects too small to get any funding (xz) and there are projects large enough to find some way to sustain by funneling money to it (Rails, WordPress).

He observes that he has seen too many people in open source struggle "one way or another" as a direct or indirect result of work in open source. He says Mullenweg, like other creators of open-source projects, feels wronged by seeing others find financial success from his project even though WordPress is uncommonly successful "in terms of impact, success, and financial return for its creator". Mullenweg's actions, Ronacher said, "have alienated many who would otherwise support him. He's turning into a 'mad king'".

That is deeply unfortunate, because the questions about sustainability of open-source projects, and who profits from them versus who produces them, are in need of addressing. Instead of having that conversation, Mullenweg has put questions about governance, centralized software distribution, and software supply chains at the forefront.

After decades of being a poster child for the goodness of open source, WordPress is becoming a case study in the dangers of the company-owned project model. Instead of being the safe choice, WordPress is starting to be seen as the risky one—and that perception may impact open source as a whole.