Over the weekend, the WordPress.org team officially forked the popular Advanced Custom Fields plugin. Anyone with the plugin installed will get the new Secure Custom Fields plugin maintained by the WordPress.org team instead.
This is the latest change in the ongoing battle between WP Engine (the maintainers of Advanced Custom Fields, aka ACF1Both Advanced Custom Fields and ACF are trademarks registered (pending) by WP Engine and are used in this article to refer to the plugin and the team that builds it.) and Matt Mullenweg (co-founder of the WordPress project, leader of the project, and CEO of Automattic). It wasn’t the most popular move.
Disclaimers
Before delving into any analysis or opinions, let me lay a few things out.
- I am not a lawyer. My opinions are informed not through intense legal education or review but from lived experience working in this space and my own personal feeling and sense of ethics.
- I do not now nor have I ever worked for either WP Engine or Automattic, though I did at one time apply to work for the latter. I have previously hosted both my own sites and clients sites with both parties but currently choose to self-host all of my projects.
- I have no economic ties to any of the players in this current battle. Nor do I even work professionally with WordPress today – while I did work with and volunteer within the community for over a decade, I’ve been focused on other endeavors for the past ~8 years and merely use WordPress personally.
- What follows are my opinions. I reserve the right to change them on the availability of new information. You have no obligation to agree with me; I have no obligation to engage with any disrespectful disagreement.
(At Least) Two Sides
Few disagreements are ever truly binary. For simplicity, though, I’m only covering two specific angles.
On one side is a team who maintains2The plugin was originally created by Elliot Condon then acquired by Delicious Brains, which was in turn acquired by WP Engine. a wildly popular freemium plugin3The core ACF plugin is free, but attempts to up-sell users to a paid “Pro” version supported by WP Engine external of the otherwise free community repository. for WordPress alleging outright theft of their project by Matt and the WordPress.org team.
On the other is the cofounder of the WordPress project, who directly owns and manages the WordPress.org domain and its projects, forking a popular plugin in the name of security.
Many on Twitter, Slack, and even Reddit have jumped up to declare the latter to be the villain in this story. While it’s easy to cast blame on an individual, the reality is not so easy.
Repository Bans and End Users
Since last month, WP Engine has been banned from leveraging the free resources available on WordPress.org – a domain and project owned directly by Matt Mullenweg, who they are currently suing. This means they cannot leverage the free plugin and theme repositories on their sites. It also means their team cannot update and maintain any plugins or themes they’ve contributed.
Which leaves end users – many of whom are entirely unaware of this ongoing drama – in a hard spot. They are potentially exposed to vulnerabilities should they arise as the team can’t actually fix the issues and push out updates.
The right thing to do is to fork the plugin – Matt and his team can provide ongoing updates and WP Engine can go a different way.
Creating and maintaining a fork raises several tricky issues:
- How will the team inform and educate end users about the fork? Remember, most users of WordPress aren’t developers in the first place. Just explaining a fork is tricky – also explaining the politics behind why the fork exists is harder still.
- Given the active legal dispute began over trademark misuse, how can Matt and his team continue to provide updates (even if just for security) to ACF users without risking a further legal battle over potential misuse of ACF’s trademarks?
My preference would be for either a friendly fork or for the WordPress.org team to float security patches back upstream to ACF. Given the enmity of the legal battle at play, neither of those seem possible at the moment. So seeing the creation of a renamed fork4The Secure Custom Fields plugin is using the same slug as ACF used previously to force end users from one plugin to the other. Ideally this will change down the road to remove all uses of “acf” from the plugin, but that’s up to the development team. was equal parts a surprise and an acceptable conclusion.
Right and Wrong
At least one person reached out to me over the weekend to ask if I was “still supporting Matt” after the plugin fork. To answer as succinctly as possible: yes.
We’ve disagreed about many things over the years. Sometimes publicly. More often in private. We’ve held impassioned debates on Trac, vehemently argued on Twitter, at least once debated in person at a WordCamp. At the end of the day, we agree on far more than we disagree.
Had our situations been reversed, I would not have employed the same tactics. But seeing from the outside where things started and how they’ve progressed, I can neither find fault with them either.
- 1Both Advanced Custom Fields and ACF are trademarks registered (pending) by WP Engine and are used in this article to refer to the plugin and the team that builds it.
- 2The plugin was originally created by Elliot Condon then acquired by Delicious Brains, which was in turn acquired by WP Engine.
- 3The core ACF plugin is free, but attempts to up-sell users to a paid “Pro” version supported by WP Engine external of the otherwise free community repository.
- 4The Secure Custom Fields plugin is using the same slug as ACF used previously to force end users from one plugin to the other. Ideally this will change down the road to remove all uses of “acf” from the plugin, but that’s up to the development team.