Well, shit. I didn’t expect the events unfolding last week, that ultimately were mainly hurting the end users of the WordPress software, would be the end of it all. But this whole dispute between Automattic and WP Engine has been cranked up a notch over the last couple days. And that is the biggest understatement I can make.

I am deeply uncomfortable with the way this legal battle has been unfolding, with it being fought out in public and affecting end users of the software. If it would end there, maybe it would take some time, but I would be able to live with it. The developments this past week have made this whole dispute take a turn for the worst.

Earlier this week, there was the checkbox on the WordPress.org login screen, requiring users to pledge that they are in no way affiliated with WP Engine in any way. The wording (probably intentionally) was vague at best and there was no proper explanation or an official answer to questions raised from the WordPress community – by many, many people. Now not only end users, hosted on WP Engine were affected. Every single person, be it a developer or just your average user, is now confronted with a choice where the consequences of are not made clear in any way.

What truly rubbed me the wrong way, was yesterdays announcement of Secure Custom Fields. Publicly communicated to be a fork of the very popular Advanced Custom Fields plugin, in practice this has more resemblance with a hostile takeover.

The ‘fork’ of Advanced Custom Fields

In the post announcing the ‘fork’ of Advanced Custom Fields, it being renamed to Secure Custom Fields, Matt Mullenweg explains that they are invoking point 18 of the plugin directory guidelines. What is not mentioned in the post, is that this is not a fork. The new Secure Custom Fields plugin is effectively replacing the Advanced Custom Fields plugin. Even the URL to the plugin page in the plugin directory has been kept the same and when people still running Advanced Custom Fields in their website, update their plugin, it is being replaced with Secure Custom Fields.

The reviews, the ratings, the support threads, pretty much everything has remained the same. Only the name has been changed, along with a couple minor changes being actually done to the plugin code.

The reason for the ‘fork’ is explained as following:

“and are forking Advanced Custom Fields (ACF) into a new plugin, Secure Custom Fields. SCF has been updated to remove commercial upsells and fix a security problem”

While this article technically warrants the changes that have been done to Advanced Custom Fields, when it comes to fixing the security problem, specifically the items:

• “to remove developer access to a plugin in lieu of a new, active, developer”
• “to make changes to a plugin, without developer consent, in the interest of public safety”

there is no way that this whole invocation of point 18, warrants the actual changes being made to the Advanced Custom Fields plugin. This has all the characteristics of a hostile takeover. Not in the least bit, because the developers of the Advanced Custom Fields plugin, are in fact WP Engine. This has all the resemblance of being part of the legal battle, trying to alienate WP Engine even further from the WordPress community as a whole.

If this were truly a fork, the new Secure Custom Fields plugin would start from 0 downloads, 0 ratings, and 0 active installs, where end users would be allowed to make the switch to the new plugin. The Advanced Custom Fields plugin would continue to exist, resulting in two plugins existing alongside each other.

Hurting developers trust in the WordPress ecosystem

This clearly demonstrates that WordPress.org is capable of taking control of any plugin, effectively bending the rules to make their case, for their own benefit. If this were truly as point 18 of the plugin directory guidelines explains it “the right to maintain the Plugin Directory to the best of our ability”, this would have been handled differently. In the past, we’ve seen other plugins being (temporarily) deactivated or patched in the case of security issues, without the actual plugin developer being involved. This has always been done transparently and clearly communicated. When the issues were resolved, the plugin would be activated again and put back in control of the original developers.

All of this combined, sets a terrible precedent. This hurts the trust of all developers invested in the WordPress ecosystem. It doesn’t matter if you as a developer are publishing your plugins on WordPress.org, are building websites using the WordPress software and use plugins to do so. It doesn’t really matter what you are building with WordPress.

All of your hard work, years of dedication to maintaining a popular WordPress plugin. All of it, can be taken away, when you find yourself in a (legal, or whatever the context is) battle with Automattic, or the WordPress Foundation. In both cases, it’s Matt Mullenweg who is involved in leadership of both parties, so this is really a request to him: Please, please, consider alternative approaches to resolving this dispute with WP Engine. This hurts WordPress as a whole now.

As David Heinemeier Hansson said it, in his post “Open source royalty and mad kings“:

“So while I always try to keep things from getting personal, I’ll break practice to make this plea: Matt, don’t turn into a mad king. I hold your work on WordPress and beyond in the highest esteem. And I recognize the temptation of gratitude grievances, arising from beneficiaries getting more from our work than they return in contributions. But that must remain a moral critique, not a commercial crusade. You can’t just extract by force that which you believe to be owed beyond the license agreement on a whim.”