WordPress.org Removes Active Install Growth Data for Plugins

Over the weekend, WordPress.org meta contributors removed the active install growth charts for plugins, a key metric that many developers and a handful of services rely on for tracking. “Insufficient data obfuscation” is the cryptic reason cited for the charts’ removal, but the decision-making process was not transparent.

In a ticket titled “Bring back the active install growth chart,” RebelCode CEO Mark Zahra contends that this data is useful for gaining a long-term perspective on a plugin’s changes in installs.

“These stats are actually very useful for plugin developers and it’s really and truly one of the only indications of the growth or decline of a plugin over time,” Zahra said. “These graphs at least give us an idea of the performance of a plugin before and after we make certain changes, helping us get a better idea of how helpful they are for WordPress users.”

Plugin developers were left to speculate on the reasons for the removal and took to the #meta Slack channel in search of more information. Feedback from plugin developers indicates this was an unpopular decision and a failure of communication.

“I want to echo disappointed in that chart being removed,” Equalize Digital CEO Amber Hinds said. “I hope we’ll hear something soon. In an ideal world this commit should be rolled back pending community discussion.”

Zach Tirrell, product manager at Liquid Web, said, “We get very limited metrics from the plugin directory and this one was very important to plugin authors.”

WordPress Executive Director Josepha Haden-Chomphosy joined the discussion in the channel but had very little information to offer about why this change was made without any public discussion.

“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,” Haden-Chomphosy said.

“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 a term coined to meld the concepts of cooperation and competition to create a system where different vendors cooperate for the benefit of the system while still competing. Haden-Chomphosy did not elaborate but it seems that obfuscating data had been deemed a necessary sacrifice for the sake of co-opetition.

Audrey Capital-sponsored meta contributor Scott Reilly, who committed the change, said “the implementation made it possible to deduce the stats we were looking to obfuscate.”

Not all plugin authors agree that these stats need to be obfuscated, nor do opaque decisions like this one inspire trust in those who are cutting off access to the data.

“The real data exists,” Yoast founder Joost de Valk said. “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.”

It has still not been confirmed whether this decision was rooted in a security issue, but de Valk and others are imploring WordPress.org’s decision makers to bring the data back until a suitable alternative in available. Participants on the ticket have also urged WordPress’ leadership to open a discussion with the plugin developer community about what would data would help them in the creation of an alternative.

“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,” Matt Mullenweg commented on the ticket.

“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.”

After a 10-month hiatus from his WP Trends newsletter, Iain Poulson returned today with an issue titled “Second-Class Third-Party Developers” that identifies this clawback of active install growth data as “a symptom of the wider issue that WordPress doesn’t really want to support third-party developers who build freemium plugins.”

“Because of this, the data insights for developers is severely lacking and it’s one of the reasons I created Plugin Rank and why other solutions like wpMetrics exist and both will be impacted by this change. That’s not to say other platforms and marketplaces are perfect, but they don’t seem to work against developers like WordPress.org does. As a plugin developer trying to grow a business, data is everything and the data from the directory is poor and requires a large overhaul to improve what is collected.”

Poulson contends WordPress.org could even go beyond the previously offered data and add new installs per day/month, how many existing sites updated per day/month, and the search terms leading to the download.

“Freemium Plugin developers shouldn’t be treated like second-class citizens in the ecosystem,” Poulson said. “Even developers with just free plugins should be able to see decent statistics. There’s no incentive to keep developing plugins if you don’t know people are using them.”

Beyond the lack of meaningful data for developers who are trying to monitor the trajectory of their free plugins, the non-transparent decision from the meta team seems to be the greater issue at hand for many participants in the resulting discussions. The sting of another closed-door decision cannot easily be explained away with a fancy portmanteau that promotes cooperation without adequate communication.

If plugin developers cannot be trusted to act “co-opetively” with this data, will WordPress continue collecting it? Who has private access to it? Why weren’t alternatives explored before silently removing access? These questions need to be answered in the process of finding a way forward for improving plugin data after this decision.

22

22 responses to “WordPress.org Removes Active Install Growth Data for Plugins”

  1. The real questions is why was this decisions made in the first place? If a sone dedicated people can use the trend data to determine real plugin numbers that is hardly a big deal, in fact there is a good argument that everyone should have this data anyway

    But if it is a problem the answer is to hide the number by default but leave it available for the author and contributors. Obviously this would take a while to build but the status quo is not a major problem so it isn’t urgent

    • And if it’s as problem for third parties to have access to the precise install numbers, then it’s a bit of a strange solution to end up with Audrey Capital or Automattic employees being allowed to have those access to those precise numbers for plugins that are competing with their own ones, but the actual plugin author not allowed to have them. How was that solution arrived at?

  2. Deeply disappointed, this is yet another instance of top down decisions. WP now feels more and more like a corporation than an open foundation. Even corporations try to listen to their base and users.
    Those charts provide no personally identifiable information so there is no need to remove them.

    From a user’s perspective, I use those charts when comparing between plugins to know which one is growing and more likely to survive on the mid to long term, and thus which one I should use.

    And from a devloper’s perspective, those charts help deciding which plugins to develop add-ons for.

  3. I agree that this nontransparent change is not the way to go, and I feel these stats should be available to plugin authors. Also, for end users these stats do give an idea of how popular the plugin actually is at a given time. Pretty useful in my opinion. But …

    Why not take control and register the plugin installs yourself? Build a small piece of central software, report some details to that when your plugin is installed and activated. You’d be able to gather a lot more details and statistics of the use of your plugin. You could gather a lot of meta data about the wp install, for example.

    This might cause GDPR/AVG and plugin guidelines issues though, I’m not entirely sure.

    • Your proposal is forbidden by the plugin directory guidelines, which disallow any sort of “phone home” – which in my view is a good thing (if allowed, it would likely need too much policing of the authors abusing the facility to be viable); but for balance, there needs to be a corresponding provision by wordpress.org who have the stats to allow plugin authors to see them.

      • Actually, phoning home like this is allowed. However, it must be opt-in only. So it can’t be enabled by default. It’s pretty common for plugins in the repo to already do this. WooCommerce does it. Just about any plugin that is monetized using the Freemius platform does it, etc. You just need to ask for permission before doing so.

  4. For developers, this is yet another example of the people behind WordPress claiming to be working with you while actively working against you. There is only community so long as it serves the needs of the people at the top.

    Iain is 100% correct. Actions like removing this data, without warning, show contempt for the plugin community. Even if that isn’t the intent, the fact that the people making these kinds of decisions can’t anticipate backlash or don’t care about it is telling enough on its own.

    So much of the messaging from the top of the food chain feels like it’s coming from parents telling their children that they know what is best for them. It’s condescending, it’s gone on for years, and it’s never going to stop.

  5. WordPress: “We want to move towards a system where we have ‘canonical’ plugins which can considered the standard.”

    Also WordPress: “We are removing metrics from the plugin repository before they help contradict us when we give the ‘canonical’ labels to our own plugins, which may not actually be the most popular with users.”

    Bad look, Automattic.

  6. This decision is against the WordPress ecosystem, and it’s not acceptable.

    Looking at the stats plugin authors can understand if their plugin is having issues.
    Many times the users don’t open any tickets on the support forum, but the installation growth goes down.
    When you see those numbers going down more than usual most of the time it usually means your plugin is having a problem that you should detect and solve.
    The only advantage that I see in removing those numbers is making money with other services that sell that information. That information still exists, it’s only not displayed anymore. Those who will give that information will do it for their own interests.
    Or, another possible reason is that those who have access to that information will use it to have an advantage over other plugin authors. For example Automattic?

    Sorry, this doesn’t look open source. This looks more like a kind of mafia act.
    Removing that information is not acceptable. Please, restore it.

  7. “Audrey Capital-sponsored meta contributor Scott Reilly, who committed the change”

    In other words, someone employed directly by a known control freak and “benevolent” dictator has taken away data from everyone else that said dictator can use to his advantage for his other company.

    Joost is right and more than that this is an antitrust issue. The WP community needs to start launching legal action against the anticompetitive practices going on.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.