WordPress developers get very little information about the performance and growth of their plugins in the WordPress plugin repository.
As of late last week, it has been taken a step further when someone within WordPress’ leadership decided to remove the active install growth chart.
One Chart is all we had
This was essentially the only valuable statistic that plugin developers could rely on to gauge the performance of their plugins in the WordPress repository, even if it wasn’t entirely accurate.
For example, the screenshot above showed a potential problem for Spotlight Instagram Feeds in June 2022. Further investigation showed that it was related to our ranking in the repo, so we dug deeper. We found that we hadn’t updated some important numbers and after doing so, the recovery began.
So clearly, this chart provides value.
It’s the only stat within the official plugin repository that gives developers an indication of how real people are reacting to the time being invested.
Now, all we have left as developers is the active install count. This number updates itself every 10,000 up to 100,000 active installs. So the moment you hit 20,000, you have no idea how well you’re doing until it hits 30,000 – if it does. We’re in the dark.
It all started one Friday morning
On Friday 30th September when I went to check the active install growth chart as I do every last day of the month. It was gone. Thinking it may be a bug, I tweeted about it to see if it was just me.
It wasn’t. The chart was officially removed in a commit by Scott Reilly (coffee2code), a Tech Ninja at Audrey HC, LLC – an investment and research company run by Matt Mullenweg – WordPress co-founder and CEO of Automattic.
The reason given? “[…] insufficient data obfuscation.”
A discussion ensued on Post Status Slack, The WP Minute Slack, Twitter, and a few other channels.
After I brought the issue up in the official WordPress Slack’s meta channel, it was brought to my attention that a trac ticket was the best place to make our voices heard.
So I opened trac ticket #6511.
[midroll_1]
The official… response?
The chat in the meta Slack channel continued and many developers jumped in to back the trac ticket. Soon after, we got an official response.
Josepha Haden, Executive Director of the WordPress project, stated that:
“The data shared is always a bit obfuscated so that it’s harder to “game the system”—the same reason we don’t have running leaderboards for contributions. […] suggestions are welcome for how to get some data for you all while doing our best to stick with a “co-opetition” mindset.”
Co-opetition is essentially cooperative competition. That means that the whole idea behind this mindset is for competitors to work with each other to acquire the highest value. So doesn’t this sudden removal of information go against that mindset?
After asking where is best to have an official discussion about the matter, the original committer, coffee2code, replied to say:
“Yes, the newly created ticket is the best place to discuss any replacement for the active install growth chart. As @chanthaboune [Josepha Haden Chomphosy] mentioned, the implementation made it possible to deduce the stats we were looking to obfuscate.”
We got an answer, but it didn’t answer our questions
The official replies in the WordPress Slack channels have so far left us with more questions than answers and it has been a frustrating few days for plugin developers and owners.
Matt Cromwell of StellarWP and Joost de Valk of Yoast SEO were just two of the people posing valid questions.
Matt asked: “Who’s “we”? Which stats? Why obfuscate plugin data that is not PII?”, also adding: “And why no discussion? Just secret backdoor convos that make sweeping changes overnight that hurts the plugin community.”
And Joost added: “So, @chanthaboune [Josepha Haden Chomphosy] @matt [Matt Mullenweg]: the real data exists. Automattic is one of the companies buying plugins and has access to the exact data and now even more than before, others do not. The whole coopetition nonsense is all interesting, but I would say this is an unfair advantage. Literally every other open source system out there just opens these numbers publicly, and so should we.”
On Monday, Matt Mullenweg chimed in
Matt Mullenweg took to the trac ticket and posted his own comment that you can see below.
“Thank you for the feedback, and I do realize that there were a number of third party commercial and free services scraping these data en masse and using it.
If someone has reasons to bring it back that haven’t been presented above already, please add it to this thread so we have the best possible presentation of that side of the argument to consider.”
I guess it’s something. Kind of.
He thanks us for the feedback and requests even more reasons to bring the chart back. So does that mean it wasn’t a security issue?
Surely, if it was indeed a security issue, he wouldn’t have asked for reasons to “bring it back”. He would have asked for alternatives, right?
A few people have already replied to Matt’s comment. Joost de Valk in particular is asking: “Can you elaborate why you feel that’s a problem?”
He adds: “It feels like people remixing open data is exactly what it’s intended for?” This is a valid question since it’s how the community has been using it for years, so if there’s another reason for it being there, no one seems to be aware of it in the first place.
If Matt wanted just one reason, this is it
Thomas Maier of Advanced Ads followed up with his own direct answer to Matt’s question:
“Motivation. I have a couple of free-only plugins in the repo. Seeing one of them grow is extremely motivating to spend more of my free time maintaining them. It happened more than once that I didn’t spend time on a plugin, then saw that it gained popularity, and then started maintaining it again. Seeing new installs decline is demotivating. But it can also be an indicator of a project not being that useful anymore. I can then lower my engagement with it and focus on plugins that are needed more. To me, either growth or decline is motivating to spend time on free projects. I will have a hard time motivating myself to test all my free plugins when the next WP version update email is asking me to do that.”
Isn’t this reason enough to bring it back?
If Matt really believes in the idea of the repository being focused on free plugins, not freemium (read Iain Poulson’s WP Trends newsletter, “Second-Class Third-Party Developers”, to understand why), then this alone is enough reason to bring the chart back.
The lack of answers is leading to speculation
Speculation is everywhere at this point.
After bringing up this issue on Friday morning, I have spoken to a lot of developers and business owners. In almost every conversation, one theory or another has been brought up.
From attempting to hide WooCommerce’s apparent recent decline to Automattic keeping the data for itself to obtain an unfair advantage over its competition, I’ve heard it all.
As farfetched as they may sound, no one is providing a clear answer to counter them.
John James Jacoby, a developer at Awesome Motive, chimed in from his personal perspective and experience working with the Meta team, stating “The commit message literally says “insufficient data obfuscation” which highly suggests it is a matter of data security”.
The problem with this comment is that it too is speculation and no one from the people involved in the decision has backed it up.
As I said above, Matt Mullenweg himself is now asking for reasons to bring it back rather than addressing the first question we all had – why? – so this theory seems to be disproven.
We get knocked down, but we get up again
Every time something like this happens, the developers who build and support the 60,000+ plugins on the WordPress repository get knocked down a step.
But we get up again.
We ask for the clear answers that we deserve. We tell our side of the story. We propose viable solutions. And we make our voices heard.
So here are the questions that are yet to be answered:
- Why was this chart removed in the first place, in detail?
- If there is a security issue, what is it?
- If there is a security issue, how was it found only years after implementation?
- If it can’t be brought back to its previous state, what are the alternatives?
- Were alternatives considered before the decision was taken to remove it?
- Why was there no communication with the developer community before or after the change was made?
If anyone reading this has the real answer to these questions, please share them.
We need to support each other
When I brought up this issue on Friday morning, I was hoping for support from the community and I’m glad to say that it’s exactly what has happened.
From solo developers to well-known names in the WordPress industry, a lot of people are standing up to be heard, and this is how it has to be done.
Even if we’re competitors in business, we all form part of one community and one industry. If we want to see positive change, we have to come together and play our part.
At this point, I encourage all of you who develop or support a plugin in the WordPress repository to have your say. Post a comment on this trac ticket and show your support for the community as a whole.
Let’s find ways to support plugin developers rather than knock them down.
