Provide helpful plugin stats and insights

[markzahra]

In changeset 12097, the active install growth chart shown for each plugin in the plugin directory was removed "due to insufficient data obfuscation".

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

They should be brought back and improved rather than taken away, as was brought up in the original discussion in ticket 3016.

[johnjamesjacoby]

See also this comment from @mnelson4 on 3018:

I assume this was a closed-door security or privacy decision taken by a larger group than just the committer.

This assumption is correct. 💯

They should be brought back and improved rather than taken away

I do not have any doubts that this is the longterm goal. 🛣️

---

Out of my own curiosity, I invested 2 hours on Friday reviewing how these charts worked before they were removed.

• I've independently identified precisely why these charts were removed the way that they were
• I would not have made any different decisions had I been in on the decision making process

For a bit of boring backstory, around 2008 the BuddyPress project was interested in obtaining these same stats. In fact, I'll just call this feature "Stats" since that's easy to grok. Back then, WordPress.org and bbPress.org had rudimentary but still functioning Stats APIs for counting downloads per release and independent installs, so BuddyPress just copied what already existed – but we knew that approach would never scale for all plugins. 📈

And that was the experiment/plan for BuddyPress.org – that "Groups" would be "Plugins" with their own forums, members, etc... It was actually live for a while, and I consider it a really cool little side-quest on WordPress.org that never panned out. 🧙‍♂️

Our original primary concern was: revealing active install charts & graphs for all plugins & themes may not actually be healthy for the entire community, because it is impossible to resist using that single number to speculate about things those numbers may or may not imply – quality, security, performance, earnings, success, etc... and when that scales to inevitably comparing data across multiple plugins & themes, is any of that actually healthy, positive, or a real goal? 🏥

We decided, back then, together, that it wasn't – not because it was not useful, but because it likely would be harmful.

Later on, when the next generation of fine folks brought it up and worked on it again, it was with the above knowledge imparted on to them, and I have a fuzzy memory of Matt announcing the feature at a State of the Word with an asterisk of minor trepidation – but I may be misremembering 😅

All of this is my own independent way of saying/confirming/comforting, that the importance of this feature is very well understood by the team of people who build & maintain WordPress.org, and I trust that work is happening to determine its fate & future even if I cannot see it myself 💞

Hopefully this helps more than it hurts 🫶 and everyone please /slap me with a trout if I've spoken out of turn 🍣

[markzahra]

Replying to johnjamesjacoby:

Hi John, I'd like to clarify a few things from your reply since it's left me with more questions than answers, unfortunately.

See also this comment from @mnelson4 on 3018:

I assume this was a closed-door security or privacy decision taken by a larger group than just the committer.

This assumption is correct. 💯

What is this confirmation based on? Were you part of the group or are aware of who formed part of that group, or is your confirmation based on something else?

They should be brought back and improved rather than taken away

I do not have any doubts that this is the longterm goal. 🛣️

Again I must ask - is this your personal opinion or something that's a fact and based on your knowledge from internal discussions that were not made public to the community of plugin developers?

• I've independently identified precisely why these charts were removed the way that they were

Can you please confirm where you've identified this so that the rest of us can have a look, please?

• I would not have made any different decisions had I been in on the decision making process

This comment implies that you weren't part of the decision-making process, so I come back to my first question above.

Our original primary concern was: revealing active install charts & graphs for all plugins & themes may not actually be healthy for the entire community, because it is impossible to resist using that single number to speculate about things those numbers may or may not imply – quality, security, performance, earnings, success, etc... and when that scales to inevitably comparing data across multiple plugins & themes, is any of that actually healthy, positive, or a real goal? 🏥

What is wrong with being able to speculate about those factors exactly? And what is wrong with comparing that data across multiple plugins and themes? Knowing where you stand and how your product's changes are performing is healthy and positive since it leads to better quality products for millions of WordPress users around the world.

We decided, back then, together, that it wasn't – not because it was not useful, but because it likely would be harmful.

What are the potentially harmful aspects? And who would it be potentially harmful to?

That's not clear yet. Seeing the number of developers that have confirmed how these stats helped them grow and improve their plugins during the past couple of days, this statement seems contradictory to what the community is actually saying.

Later on, when the next generation of fine folks brought it up and worked on it again, it was with the above knowledge imparted on to them, and I have a fuzzy memory of Matt announcing the feature at a State of the Word with an asterisk of minor trepidation – but I may be misremembering 😅

What's the feature being referenced here? And what was Matt announcing about it?

All of this is my own independent way of saying/confirming/comforting, that the importance of this feature is very well understood by the team of people who build & maintain WordPress.org, and I trust that work is happening to determine its fate & future even if I cannot see it myself 💞

We all hope for that, but the lack of communication is not comforting.

[johnjamesjacoby]

Replying to markzahra:

Replying to johnjamesjacoby:
What is this confirmation based on? Were you part of the group or are aware of who formed part of that group, or is your confirmation based on something else?

I independently reviewed all of the related code.

I saw what had happened, and wanted to better understand the problem so I could participate in the conversation with some education, much like you and everyone else who is feeling uneasy about it.

Again I must ask - is this your personal opinion or something that's a fact and based on your knowledge from internal discussions that were not made public to the community of plugin developers?

It is my opinion, and also from discussions that were probably public and not intentionally private 14 or so years ago.

Can you please confirm where you've identified this so that the rest of us can have a look, please?

Not exactly, because not all of the code responsible for keeping WordPress.org running is publicly available, and the part you want to see is outside of the Meta repository.

This comment implies that you weren't part of the decision-making process, so I come back to my first question above.

See my first answer. 👍

What is wrong with being able to speculate about those factors exactly?

See my paragraph for my answer. 🤣

Personally, sure... speculating can be fun! Celebrating when I've guessed right and mourning when I've guessed wrong. I spent a lot of years at various poker tables, and what I learned about myself is that I enjoy inventing and producing more than guessing using incomplete or inaccurate information. 🃏

Knowing where you stand and how your product's changes are performing is healthy and positive since it leads to better quality products for millions of WordPress users around the world.

Yes, of course this is true. I said as much re: BuddyPress early days 🧡

But, see my next answer ⬇️

What is wrong with comparing that data across multiple plugins and themes?

In my opinion, it does not really prove very much, because there are too many differences & variables.

I.E. BuddyPress had 200k installs, but that does not prove it is better than BuddyBoss; and BuddyBoss growing does not alone validate any one thing to help BuddyPress grow too.

What are the potentially harmful aspects? And who would it be potentially harmful to?

@joostdevalk recently suggested that Automattic has an unfair competitive advantage because they have access to more accurate stats. I will go one step farther and say, that if a goal with any data is to be fair to each other with it, that includes a responsibility to serve up the same data with the same interface to everyone, and to prevent people from accessing it in anyway that is unintended or unfair.

...which is essentially what has happened, here.

Seeing the number of developers that have confirmed how these stats helped them grow and improve their plugins during the past couple of days, this statement seems contradictory to what the community is actually saying.

I know how it feels when you ship a new feature and you see the numbers change. It's rewarding, fun, and it's just a really cool experience overall to validate that you are making a difference.

Consider the reasons why YouTube, Instagram, etc... are experimenting with hiding or limiting the way that they display engagement in their apps & websites – because they've seen the human side when users only feel increasingly negative self-worth while they're stuck in a loop comparing themselves to everyone else – and it is the most likely outcome of implementing Stats wrong.

What's the feature being referenced here? And what was Matt announcing about it?

Active installs for plugins. Again, I might be wrong. That happens a lot. 😆

We all hope for that, but the lack of communication is not comforting.

When a security issue is identified in one of your plugins, you work privately to deploy the best fix as quickly as you can.

That privacy is not intended to hurt your community of users, but you are intentionally excluding many people to protect them from some people.

I understand how unannounced changes may not feel good, but they almost always feel less bad than had that change not happened and whatever was broken had stayed broken.

---

I feel as though this discussion format is not ideal, and is not how Trac is intended to be used.

I've also inserted myself into the middle of a thing where it is not appropriate to share all of the facts, while also feeling obligated to utilize the tools I have available to independently asses the situation and report back what is safe to share.

Sincere apologies in advance again if I'm only mucking things up. 🙏

[joostdevalk]

I agree with @markzahra that this should be brought back ASAP. Plugin developers rely on this data to see whether they're doing the right thing for their customers. If there are reasons to want to replace this data with something, I'd suggest:

• bringing back the data until the alternative is available;
• opening a discussion with the community of plugin developers about whether the alternative suits their needs;
• developing out in the open, as befits an open source project, and being very specific about what these stats represent.

I understand @johnjamesjacoby's need to defend the Meta team and try and be nice to everyone involved. I don't disagree that they should not get shit for this personally. Which doesn't mean that this decision should not be challenged, loudly, with project leadership.

So, @matt, @chanthaboune, while I hope and want to believe this was not done for anti-competitive reasons, the optics are against you. The fact that we don't have open numbers about installs, like literally every other Open Source project does, seems in itself a weird decision.

I've heard two reasons mentioned in the past for not showing them:

• Security
• The data is invalid

The security argument
Obfuscating plugin install numbers for security reasons, which is what's often mentioned, is honestly reasoning I personally disagree with. You can get data on large plugins quite easily through other sources, if you want to decide which plugin to hack. WordPress not showing plugin install data doesn't help security, but it does make it harder to ascertain how many sites are still at risk when something is happening. What's needed for plugin developers is this data which shows direct feedback without lag. Security through obscurity is not the way.

The data validity argument
The fact that these numbers might not be entirely valid (because they contain loads of test installs, and perhaps a dozen or so other reasons) is something that we could (and probably should) just add in a note in the interface. The trends in this data are super important for plugin developers, as seen by the many many people that have responded to ​this in Slack.

So: I implore you to open up this data. First by bringing it back, and then potentially by building something even more open for plugin developers to look at.

[joppuyo]

It's sad to see this feature being yanked so quickly, it has been very useful for many plugin developers.

If insufficient data obfuscation is truly the reason for this change, I think the best course of action would be to implement the missing obfuscation rather then removing the whole feature that many people are relying on.

I hope we will be able to see this feature returning in the future.

[iansadovy]

I am running a project that helps to sort out and organize different metrics connected with WP plugins.
So, I'm communicating with lots of plugin developers, and they find the active installs growth metric extremely valuable.

If there is a security issue, there should be a fix (or an alternative approach). Simply disabling it - can't be a long-term solution, it damages the community.

[matt]

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.

[joostdevalk]

Replying to matt:

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.

Can you elaborate why you feel that’s a problem? It feels like people remixing open data is exactly what it’s intended for?

[rainbowgeek]

Please make this data available at least for the current authors of the plugin.

It will quickly solve any security/privacy/hacking issues.

Thanks

[joppuyo]

I think the root issue here is that the active user statistics become less and less useful the more users the plugin has because of the rounding. Eg. if you have more than a million active users, the count is rounded to the nearest million.

And since there is a huge difference between one million and two million it's very hard for plugin owners to know the real count of active users, for example, is the user count going up or down on a month-to-month basis? That's why many developers have relied on active growth data to track this metric.

So making the active user count less rounded and more useful would diminish the need for the user growth statistic.

[webzunft]

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.

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.

[vanyukov]

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 think what's important is to communicate to the community - Is this or is this not a security related fix? Without clear comms, this seems like one of those behind closed doors decisions that hurt developers and ultimately the end-users.

[johnjamesjacoby]

It feels like people remixing open data is exactly what it’s intended for?

The Active Installs endpoint for Plugins was not built with the intention of the data ​being scraped.

1. It was not published on the ​WordPress.org API page
2. It is not used by WordPress Core
3. It was used publicly in Meta once: in the theme > in the JavaScript > for the intended chart
4. The amazing WordPress.org Systems Team designed & maintains a robust hosting setup, but unanticipated overuse of any API will have negative consequences for other areas (not to mention costs).

---

Is this or is this not a security related fix

Yes, it is.

---

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.

One reason I have not seen mentioned yet here explicitly, is that APIs like the one in question – when working as intended – enable extremely neat learning (and business) opportunities, specifically for a subsection of data scientists that currently do not have much reason to be attracted to WordPress.org as a source of data to analyze, study, and glean insight from.

In other words, the folks who had identified & implemented the API may not have felt any need to consider their own ethical consequences, because they were pioneering & learning how to work with a fascinating new data source that was not explicitly unavailable even if it was not explicitly open.

Maybe it was just... fun?

I think... there is an opportunity – even if it is not in "our" wheelhouse, even if not existent – for the WordPress Project to similarly pioneer & prioritize an ethical type of relevant, anonymized, obfuscated statistical analysis interface (much like how GlotPress does such an awesome job with i18n, etc...) to help influence how the web could democratize data collection. 💙

[DarkoG]

If you can't see your plugin's performance - it's not interesting to continue developing it, the motivation will be gone. After all, the goal of every plugin developer is to offer quality software and ensure growth. As of now I will not publish any new plugin if there are no statistics to monitor the performance.

If you are stubborn on this and plan to continue pushing this unpopular move, at least provide some private area for developers to see stats.

[quantumcloud]

A sudden drop in active install growth is also a good indicator if a bug was introduced in the last update. We request you to bring this feature back. If the feature is made available only to plugin authors and contributors that would mitigate the security and mass abuse.

[ndiego]

I am likely reiterating what many have already said, but I want to share my experience as an aspiring WordPress developer back in the day. It was a huge deal to me whenever I would release a plugin on the repo. I would literally check the growth and download charts every day. If there were a dip, I would challenge myself to add more plugin features, improve the description in the repo or provide more detailed screenshots. Access to data about my plugins encouraged me to make them better.

Most of us following this ticket are established WordPress professionals at this point. While this data is still extremely valuable to us, I want to stress how vital data like this is to first-time plugin authors and aspiring WordPress professionals. I know the data itself was flawed, and I am sympathetic to the obfuscation argument. However, I believe the lack of information about how a plugin is performing disincentives new plugin submissions and, more importantly, the continual improvement of existing plugins.

Plugin data has played an essential role in making the repository what it is today. There is always room for improvement, perhaps by making data private to plugin authors. But in the end, I think we can all agree that a vibrant and flourishing plugin repository has an incalculable benefit to the WordPress community. Let's strive for a compromising solution that satisfies all parties involved.

[dmccan]

Replying to matt:

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.

All of the comments are from a plugin author's point of view. The plugin directory exists for end users to extend core WordPress. As an end user I found the active install growth chart useful for judging a plugins health, just like checking the star reviews and the support threads.

[dmccan]

If the stats availability was being misused or was a security issue, and that was pulling the team away from other day to day required work, then disabling them until there is a fix seems reasonable.

On the general issue of stat availability, as a community member I was somewhat put off by the presence of stat aggregators that people need to pay for to access. I get it that the creators of those businesses were clever and being good entrepreneurs, but I think that knowledge should be available to everyone. What about the developers of free plugins that cannot afford to pay for the secret knowledge? So I support having more stats available to everyone.

[joppuyo]

Replying to dmccan:

On the general issue of stat availability, as a community member I was somewhat put off by the presence of stat aggregators that people need to pay for to access. I get it that the creators of those businesses were clever and being good entrepreneurs, but I think that knowledge should be available to everyone. What about the developers of free plugins that cannot afford to pay for the secret knowledge? So I support having more stats available to everyone.

It was possible to get the accurate active installs count using and API provided by wp.org and a basic math formula: ​https://benjaminintal.com/2020/09/12/how-to-get-the-actual-number-of-active-installs-of-your-wordpress-plugin/

You could do this yourself using a script or even by hand using an Excel sheet. I don’t really see how it’s a problem if someone turns this into a commercial service, after all, hosting servers isn’t free and plenty of companies have built commercial services around the WordPress ecosystem (incl. Automattic itself)

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

[jeangalea]

@johnjamesjacoby You are insisting this is a security fix, but have not provided any evidence to this effect. Given the overwhelmingly negative effect of the change on plugin developers, someone needs to answer the question honestly.

[dmccan]

Replying to joppuyo:

Replying to dmccan:

On the general issue of stat availability, as a community member I was somewhat put off by the presence of stat aggregators that people need to pay for to access. I get it that the creators of those businesses were clever and being good entrepreneurs, but I think that knowledge should be available to everyone. What about the developers of free plugins that cannot afford to pay for the secret knowledge? So I support having more stats available to everyone.

It was possible to get the accurate active installs count using and API provided by wp.org and a basic math formula: ​https://benjaminintal.com/2020/09/12/how-to-get-the-actual-number-of-active-installs-of-your-wordpress-plugin/

You could do this yourself using a script or even by hand using an Excel sheet. I don’t really see how it’s a problem if someone turns this into a commercial service, after all, hosting servers isn’t free and plenty of companies have built commercial services around the WordPress ecosystem (incl. Automattic itself)

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

On reflection, my feeling about the aggregators may have been a reaction to the presentation of the teaser data and marketing.

I see what you mean, that an individual plugin developer could use Excel to get the data about their plugin, if the technique was known and officially sanctioned. An individual with Excel wouldn't have access to the aggregate data across all of the plugin directory. I wonder if access to the aggregate data enabled manipulation of the directory, like bad use of SEO.

[robscott]

Replying to matt:

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.

The spirit of open-ness. Scrapers are gonna scrape. But the data belongs to everyone. Let plugin developers have access to it; don't hoard this data.

[dancameron]

Replying to jeangalea:

@johnjamesjacoby You are insisting this is a security fix, but have not provided any evidence to this effect. Given the overwhelmingly negative effect of the change on plugin developers, someone needs to answer the question honestly.

Without the transparency on this security-related issue, the community (or future members within .org) cannot learn/progress security in other areas. As a tenant of Open-Source, we should all agree and adhere.

[himrfaruk]

Sweeping active growth chart is not welcomed. If it's a security concern then why don't just provide private area for developers to see stats? And if the stat is not accurate there could have improvements to see growth insight instead of removing the active install growth metric. Please clarify the true motive of the reason behind removing this.

[markzahra]

Replying to matt:

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.

Hi Matt, are the reasons posted so far and the 90+ people watching this ticket enough of a reason to reconsider the decision?

From a user's perspective, this chart is what tells me whether a plugin is doing well or struggling. If the chart shows some struggles, it tells me I need to investigate further to see why that's happening. Is the plugin being abandoned? Are the developers doing something shady that people aren't liking? Is there an alternative plugin offering something better?

Please note that we are yet to be given a clear reason for this sudden removal 5 days later. This is only leading to frustration and speculation among the community. If you don't want to give us an honest answer and there is no real security risk, can you please just bring this chart back and start a conversation with the developer community to find ways to improve upon it?

The response from the community is as clear as can be.

[podz]

Matt: "If someone has reasons to bring it back"

Since when does removing information from a community help that community?

If you reply, please be explicit so everyone that has helped WordPress become what it is can understand why your move here is the positive you believe it is.

[elrae]

Replying to matt:

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.

We still haven't gotten concrete answers as to why it was removed other than it prevented obfuscation and now vague insinuations people are scraping the data. If you have actual arguments on why it shouldn't be brought back, please supply those so it can be considered as well. If the data is being scraped, enable rate limits and blocks on the offending IPs and scrapers. There's tons of other stuff I'm sure being scraped and downloaded daily but those don't get removed.

[nataliemac]

Replying to matt:

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'd like to lay out a few of the ways we were using that data for our plugins.

Knowing at least some details about active install growth allowed us to proactively plan for support needs. We currently have two full-time staff handling support tickets, and over 90% of those are support requests from free users of our plugins. Knowing how quickly our active installs are growing is a key leading indicator that we track to determine when we need to start the hiring process to add to our support team. That process can take weeks or even months as we're small and hire carefully, so it's really important that we're able to be proactive about the process to hire at the right time. Without that data, we have to rely on lagging indicators like support volume alone, which means we might make important hiring decisions too late and the quality of our support might suffer.

Additionally, when we release new features or make large changes to our plugins, we always closely watch the active install growth numbers in the following weeks. Without access to that data and having to rely only on the public rounded number, we could lose 50% or more of our active installs without knowing it. We know from experience that only a tiny percentage of users will file support tickets if there's a problem and an even smaller percentage will leave reviews. Without active install numbers updated regularly, we have no reliable way to judge whether a change to a plugin was a positive or negative one until much later. And by that time, we may have permanently lost a significant portion of our users.

Another key leading indicator we were tracking was the number of support requests per active install. Whenever we've seen that number tick up, it's been a sure and early sign that there's an issue in the plugin and we've been able to have everyone drop what they're working on to focus on fixing the issue and minimizing the impact to users. If we see an uptick in support without knowing our active install numbers, it's not possible to tell right away if we're growing and gaining more installs, or if there's an issue in the plugin that needs an urgent fix. Without that data, we might figure it out too late.

Our only interest in the active install numbers is for our own plugins. It was all data we were using to make good decisions with our plugins. We'd be perfectly happy to have the data kept private per plugin and only available to plugin authors, but we'd really like to have it back. Not having that data really hurts our ability to serve our users and make our plugins as useful as possible.

[carlhancock]

I'm struggling to see why the active install growth chart or being able to use this type of data to compare a plugins performance against another is some sort of problematic use case or some sort of security issue?

If it is some sort of security concern as to why this information needs to be obfuscated to the point that simple raw numbers in the form of that chart is problematic it would be extremely helpful for whoever was involved in the decision-making to actually explain why it's problematic.

The chart wasn't displaying PII data. So this isn't an issue of PII data being exposed. It's not a privacy concern. It has been stated in this trac thread that it is indeed a security concern. Can someone explain exactly why it's a security issue? Given the chart is not being displayed any security issue it supposedly posed should now be moot so an explanation of exactly why it's problematic should be possible.

I'm also curious as to why people think this data should be private once it's made available once again. That seems to run counter to transparency and openness which are the hallmarks of an open source project. Especially when it is not PII data we are talking about here.

If it is some sort of knee-jerk reaction to relatively new developer-focused solutions like wpMetrics it seems pretty crazy to hamstring the plugin community as a whole because of dislike for this type of usage of the API.

This data was vital to plugin developers for a wide variety of reasons already mentioned here. Not knowing the health of your plugin in the repo (and this data was part of knowing the health) impacts product decision-making. It can impact motiviation and desire to work on a plugin for those that aren't commercialized in some way and are just doing it out of enjoyment. A lot of times that enjoyment comes from the motifivation you get seeing something grow. And that chart was a great visual way to do so. It also impacts things like business decisions related to things like acquisitions and knowing how a plugin is performing. If it's growing or if it's declining and how quickly.

Hopefully someone can explain in more detail exactly what the issue is so that people at least have something to go on. In the absence of a legitimate explanation as to why the active install growth chart poses some sort of security concern or why the data wasn't deemed obfuscated enough all people have to go on is wild speculation, hearsay, rumors and guesswork. Which is never a good thing for the community.

[maartenbelmans]

I vote to bring this back, like many others. We haven't been given a clear reason as to why this was removed and it does not sit well with a large part of the community judging from this ticket. I understand why the community is suspicious that something else is playing here. The fact that it ran for 5 years without anybody saying anything speaks to that.

If this is indeed an issue about scrapers, privatising fixes that.

If there is another issue at play, I'm sure there are better ways to tackle it, like a conversation for starters.

It's no secret the plugin repository is being used by businesses. They release a free version as way to drive traffic. There's nothing wrong with that as those are great plugins used by millions. Yet that group of people seems to be consistently overlooked when it comes to the repository. There's no data to track, no way to fight pesky reviews that are clearly misunderstandings, no way to add images, ...

The only thing they did have was the active install growth. I'm not sure who is benefiting from the decision to take it away but it is, again, not that group of people.

[bfintal]

@matt & others: If you read all the comments above, most of us plugin authors are just after more data for our own plugins so we can understand our own plugins better.. all so we can make our own plugins better.

I for one keep track of this metric for my plugin weekly. I'll paste here what I mentioned in one of the threads in Slack:

---

It matters if your rate grew or shrank. Imagine if you put out a change in how your plugin - improved a feature, updated your UI, changed the location of a major button for example, then after a week or two, you notice that the growth chart is going down - this might be an indicator that the change might not be good. Why? Because people are uninstalling. If it's the same or going up, then you might be good to go. Of course there are lots of other factors, like another solution coming in or something. But without the chart (and if you have 20k+ active installs), you will not know about any of this.

Now if you think that users will voice out their concerns in the support forum, baed on experience, the vast majority of users will not let you know their concerns, they will more likely uninstall your plugin or something worse like rant in socmed or leave a 1-star rating.. which we all don't want.

---

I see security was being mentioned as a cause for the removal. If that's the case, make the metric accessible privately to plugin authors, so we can understand how our own plugins are doing. Make it so that when a plugin author is logged in, that's the only way you can see the data. This would also solve the issue of publicly scraping data.

Also, it wouldn't hurt to provide us with more data about our own plugins too. If we really want the plugin ecosystem to thrive, we need to change and things need to be a two way street.. you need to help the plugin authors and give us more beyond what little data we have right now.

[zorem]

Replying to markzahra: I think that plugin developer should strike, no more support, updates and adding new plugins to the repo unless WordPress will return the growth chart and also will give the developers more stats about the plugin performance in the repo.

In changeset 12097, the active install growth chart shown for each plugin in the plugin directory was removed "due to insufficient data obfuscation".

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

They should be brought back and improved rather than taken away, as was brought up in the original discussion in ticket 3016.

[matt]

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

[maartenbelmans]

Replying to matt:

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

Hi @matt

Why not bring back the growth chart but only visible to plugin owners? That would stop these services from scraping the API entirely as there is nothing to scrape. Am I missing something here? The solution seems simple.

[dyszczo]

Replying to matt:

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I think it's good to point out that the graphic chart itself can be scraped almost as quickly as API. CPU power is really cheap these days, and the task is not that hard. So it's not about the API.
It's about data that is crucial for the community but remains hoarded under the pretense of 'security' for some surreptitious reason.

For ecological reasons, the API seems a much better choice.

[robscott]

Replying to matt:

Replying to joppuyo:

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

It seems very much worth building an API.

The primary justification for even storing this data is if its made available to be consumed - and to all.

If not plugin owners, then who does have the right to consume information on plugin installation growth? If nobody, then presumably WordPress shouldn't store it at all. If *anybody* does have the right to consume this data, then how does one obtain this permission?

[tombombadil]

Replying to matt:

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

@matt to simplify. You talk a lot about supporting the community. Some day your team cut out an important functionality. When the community rationalizes to you its value, you inform that there was never a promise of its availability.

it's not the right attitude if the community is really important

[markzahra]

Replying to matt:

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

@matt, the chart in its current state, no matter how it came about, was helpful, so please bring it back while we work as a community to create a better solution for the future.

Holding this information hostage from plugin developers is only going to cause more problems for everyone involved and WordPress as a whole. As you say, feedback loops are important, so please give us back the only valuable user feedback that we've had from the repo

Once we have this chart back, we can then open a separate trac ticket to discuss what the future version of plugin stats could be like for developers. This is the best way forward for everyone.

[codeamp]

I'm probably not adding much original information to this ticket but I do think its important for plugin owners to chime in, to show that we care about this and that it affects us.

First, re usefulness of the chart:

1. It is literally the only way to know how your plugin is doing - which in itself, is pretty bad - the removal of it just put blindfolds on everyone - so we have to wait until the next tick of install growth (up or down) to get any idea - it's not reasonable - this can take 6 months or more in some cases, and literally forever if your plugin is neither going up or down in active installs.

2. It provides motivation - especially for plugins without commercial setup (ie free plugins) and new devs.

Thoughts:

1. If there was a security issue, now that it no longer exists, we can publish the information surrounding it.

2. If there was a security issue, enabling this for repo owners only (for now) would surely mitigate such a security issue - that would have been a much better short sighted response to this.

3. If scraping is a problem (2) would solve it in the interim - but I don't think this is a good way forward - we should be embracing openness, nonetheless its much better than complete removal.

4. We keep seeing responses to cherry picked questions, but no real answers to the main questions - please lets just be clear and address the most important concerns first - it seems everyone is asking pretty much the same things.

5. My knee jerk reaction was, ok, lets start a new repo, but we can't, because we can't hook into the plugin/themes/block directory without installing a plugin to begin with.

6. So considering we are locked in to the repo (if we want our users to have a first class experience) why are we not looking to improve the repo/metrics for devs - it hasn't been updated for years, and now it feels like we're going backwards. If its a (human) resources thing, I'll throw my hat into the ring and set some time aside to work on this kind of thing.

The way that this has been dealt with has made me seriously question if WordPress is the right platform for me, for the first time in years - it's made me and my business feel vulnerable.

Anyway that's my two cents, this is an important issue.

[mariusvetrici]

The chart was very useful.

I'd like to see it back and eventually improved.

Thanks.

[joelcj91]

This is not good. Please bring it back. Make it available for the plugin authors (at least). I don't understand how that's a security issue. Why is nobody willing to explain that? 😕

[alekv]

I only have two things to add because others have mentioned everything else that I could think of.

1. I add my vote to bring back the growth charts and the numbers.

2. If you bring it back, provide the API to access it. IMO it is a full-in or nothing at all decision. I don't think making the growth charts private to only the developers will work long-term. That data will leak eventually and cause more stir.

[themeisle]

I think this is useful not only for us as authors, but for users. There are a lot of plugins or themes with a lot of installs, but pretty much no new installs in a while.

[pluggabl]

Echo the comments already posted, please bring back the chart. If there are security/scraping issues - how about just giving the access to plugin authors?

[quiahuitzin]

This decision obviously supports paid plugins, as they can keep track of their use since they are being paid.

No doubt it will demotivate free plugin developers, as they will see no impact on the effort they make.

This decision is one more step away from WordPress as an open source framework.

[foack]

This is really bad... I loved using the chart to determine whether or not to install a plugin.
There's always a sour taste to using a plugin that hasn't grown for a reasonable time, as there's no need to properly maintain it in that case.

[lkoudal]

Please bring back the chart :-(

[Annubis]

perhaps this is the ultimate goal - from free cms to a paid closed one

Replying to quiahuitzin:

This decision obviously supports paid plugins, as they can keep track of their use since they are being paid.

No doubt it will demotivate free plugin developers, as they will see no impact on the effort they make.

This decision is one more step away from WordPress as an open source framework.

[diegoversiani]

This is really bad. The plugin stats are around 90% less useful now.

I reiterate all the reasons to bring it back mentioned by others.

It is as if, as a business, you could not know how much sales or returns you had in a certain period. Totally shooting in the dark.

Even if the ultimate goal is to move WordPress to a closed CMS rather than open source as mentioned by @Annubis, I bet plugin developers on closed platforms like Apple App Store, Google Play and even Shopify probably have enough data to make informed decisions about their products.

Also, all successful closed platforms have some sort of 3rd-party extension developers working with them.

@matt, please bring the active install growth chart back, at least privately to the plugin authors until a better solution is defined and implemented.

[alexmigf]

We all agree that it's important for plugin developers to have this chart since no more data is provided, but if WordPress is really concern about security I think there will be other areas with higher priority. Removing this chart without consulting the community it's a shame and doesn't reflect the openess of this project at all.

[andrewmrobbins]

Add the chart back please. I rely on it to sustain my business.

[dlocc]

Replying to matt:

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

I reiterate what many others have said before me: The chart shouldn't have been removed in the first place without more transparency and discussion.

However, I am encouraged when I read "I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator". At least this tells me there's some hope we'll get back the data we lost, and potentially more data in the future.

I do have to temper this hopefulness, though, due to the mere fact that it seems WP.org leadership and Automattic seem to be working more against the community than with the community lately. It's an unfortunate feeling and I'm obviously not alone.

[carlhancock]

Replying to dlocc:

Replying to matt:

Replying to joppuyo:

I guess only issue I see if these kinds of services put unreasonable pressure on w.org servers. I’m not familiar with the terms of service of the API.

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

I reiterate what many others have said before me: The chart shouldn't have been removed in the first place without more transparency and discussion.

However, I am encouraged when I read "I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator". At least this tells me there's some hope we'll get back the data we lost, and potentially more data in the future.

I do have to temper this hopefulness, though, due to the mere fact that it seems WP.org leadership and Automattic seem to be working more against the community than with the community lately. It's an unfortunate feeling and I'm obviously not alone.

These stats weren't just valuable to plugin developers.

They were also key stats that are also used by WordPress users that use this data to make decisions on what plugins to use. They directly play into decision-making on which solution to use.

Every time I've installed a plugin from the repo I always check this data to see what it's trajectory looks like.

I don't want to get into using a plugin in the repo if it appears to be on a downward trend (along with other data points such as reviews, etc.) to evaluate solutions I want to rely on from a business standpoint to power my web site.

This information isn't just about plugin devs evaluating their plugin performance. It's also about users evaluating the plugin performance.

[shawfactor]

The biggest benefit to these stats is to the author. More than once I’ve picked up an issue with a plugin I’ve updated when I’ve seen the installs fall. Unfortunately users don’t always tell you but statistics do

I’d actually argue for complete transparency but if we can’t hVe that then the authors need this info back urgently

[dancameron]

Based on the lack of respect from @Matt (and the team) in providing transparent reasoning, it’s safe (for me) to assume this was done selfishly. Otherwise, we’d have answers by now, i.e., why they’d be okay with removing a feature, so many developers depend on.

I don’t want to speculate what those selfish reasons are; however, the lack of transparency fosters conspiracy.

Was this decision made by Automattic?
Does Automattic want to hide the fact that their plug-in adoptions are in decline? Or that all plug-in adoption is declining, I.e., WordPress.
Does this data: level the playfield for outside investment into trending plugins, and do they want to have an advantage with the data they gather from the multitude of plug-in installs?
Does Automattic have access to this data directly or indirectly (via connections with team members)?
Seriously, what is the purpose of hiding this data if not for selfish reasons?

[hasanet]

This is really a bad move. I have few small scale plugins. I regularly check my "Active Install Growth" chart to understand the market, whether my plugin growing or not. Few weeks back, one of my plugins had a negative growth. Immediately I realized there may be a bug and there was one. Once I fixed it, installation growth move back to positive.

Most users don't leave any feedback or contacts the author if anything is wrong. For us, our most convenient way was checking this growth.

I request the core team to bring this feature back.

[georgestephanis]

To sum up a lot of the prior discussion for new folks coming in --

This chart was removed due to a Security or Privacy concern. 👇🏼

Replying to johnjamesjacoby:

I assume this was a closed-door security or privacy decision taken by a larger group than just the committer.

This assumption is correct. 💯

Due to the fact that the specific details of the relevant concern not having been disclosed yet, it is likely that it cannot be yet shared without putting users at risk (I was not involved, I'm just speculating on that due to my own experience with deploying security-based changes in the past).

Replying to markzahra:

@matt, the chart in its current state, no matter how it came about, was helpful, so please bring it back while we work as a community to create a better solution for the future.

This chart was removed due to a Security or Privacy concern. As such, it cannot be re-introduced in its current state without reintroducing the same Security or Privacy concern once more.

Matt has agreed that the data from this has been useful for plugin authors, and stated that adding more data for plugin authors will take some work, but is doable. 👇🏼

Replying to matt:

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

What may be most useful, rather than saying "we want the chart back" would be to have a productive discussion about what metrics and data would be most important to have, and then find ways to expose that data, if it is safe and sufficiently anonymized so as not to mess with user privacy.

[elrae]

Replying to georgestephanis:

To sum up a lot of the prior discussion for new folks coming in --

This chart was removed due to a Security or Privacy concern. 👇🏼

Replying to johnjamesjacoby:

I assume this was a closed-door security or privacy decision taken by a larger group than just the committer.

This assumption is correct. 💯

Due to the fact that the specific details of the relevant concern not having been disclosed yet, it is likely that it cannot be yet shared without putting users at risk (I was not involved, I'm just speculating on that due to my own experience with deploying security-based changes in the past).

Replying to markzahra:

@matt, the chart in its current state, no matter how it came about, was helpful, so please bring it back while we work as a community to create a better solution for the future.

This chart was removed due to a Security or Privacy concern. As such, it cannot be re-introduced in its current state without reintroducing the same Security or Privacy concern once more.

Matt has agreed that the data from this has been useful for plugin authors, and stated that adding more data for plugin authors will take some work, but is doable. 👇🏼

Replying to matt:

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

What may be most useful, rather than saying "we want the chart back" would be to have a productive discussion about what metrics and data would be most important to have, and then find ways to expose that data, if it is safe and sufficiently anonymized so as not to mess with user privacy.

It was never explicitly stated it was removed for a security or privacy concern. It was removed due to "due to insufficient data obfuscation" which to me does not mean security or privacy. Privacy is PII which this chart did not include. The obfuscation is because "we" (whoever we is) did not want people to be able to see "exact" stats. Framing a summation of this as a privacy or security update isn't accurate. What may be most useful is if Matt stops flying by with 1-2 sentence non-answers and finally addresses in detail and plain language WHY this was removed. Short of that it should be reinstated ASAP and work on better charts in the future.

[Cybr]

This is the data Apple provides their App developers, which is actually useful: ​https://developer.apple.com/app-store-connect/analytics/.

Plugin impressions, bounce rate, etc., are already recorded via Google Analytics on WordPress plugin pages, but those are never disclosed. This raises the questions: Who can see it, why can they see it, and do they have a competitive advantage over others with this data?

Anyway, much like tackling music piracy, the only way to go against scrapers is to build a better system that people genuinely want to use. And likewise to not providing data: "Without music, life would be a mistake -- Friedrich Nietzsche"

[georgestephanis]

Replying to Cybr:

Plugin impressions, bounce rate, etc., are already recorded via Google Analytics on WordPress plugin pages, but those are never disclosed. This raises the questions: Who can see it, why can they see it, and do they have a competitive advantage over others with this data?

That's data I'd never actually considered, but could be tremendously useful if aggregated and presented. What search terms lead the most folks to your plugin, what percentage of visits to the page result in clicking on the "download" or install button. It could get tricky with as much interaction happens within wp-admin for finding and installing plugins though, and how much could be done without cookies / gdpr concerns.

[badsha_eee]

Please bring back the chart!

[tombombadil]

Replying to georgestephanis:

What may be most useful, rather than saying "we want the chart back" would be to have a productive discussion about what metrics and data would be most important to have, and then find ways to expose that data, if it is safe and sufficiently anonymized so as not to mess with user privacy.

It would be more productive not to remove an important chart and leave plugin developers without an important tool. Instead, the change could be consulted, a "feedback loop" could be applied, and changes could be implemented together with users.

We are not writing about the data exposing feature in this thread. It's a fail. And it's seems to be critical for WordPress developers.

[giuse]

That chart is useful to understand if a plugin has a bug, or generally something wrong.
More than once I realized a plugin of mine had a bug thanks to that chart.
Removing that chart means doing something against the WordPress ecosystem.

"This chart was removed due to a Security or Privacy concern".

Sorry, I don't believe that. It's more probable. It was removed because someone sells services that give you active installations. Plugin authors are now more likely to buy those services.

Please, don't think plugin authors are so stupid, and bring back the chart! Promises about giving stats are not enough. We want that chart back, and we wanted it now!

[progmastery]

I don't think there is any security issue if third parties know how many installs my plugin has.

The data should be available to the whole WordPress community, not only to plugin authors.

• customers benefit because of knowing this information, each +1 active install adds to the credibility of a plugin,
• this encourages competition and market research and makes the plugins repo overall better.

If there is an issue with the load of servers because of abuse, this can easily be fixed through rate limits and better protection.

We don't want wp.org to become like Amazon or other marketplaces where the marketplace gets a competitive advantage because of having all the data, while each author has only limited data.

[eliasatcluevo]

Bring back the active install growth chart ASAP please. This is the one and only key metric we plugin developers have for plugin growth.
If there are concerns about usage of the data from third parties then fix that or make the chart only available for the authors, but don't just disable it completely...
This is really bad practice and I must say my trust in the whole ecosystem really suffers from such actions.

[bakemywp]

The chart is very useful, please bring it back. Our ecosystem doesn't need to be treated like this.

We deserve better.

[satindersingh]

You can make these stats private to plugin owners only to protect them from third party misuse.

Replying to matt:

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.

[d4d5bh6]

Please, please really bring them back ASAP.

[fahimmurshed]

Bring back the chart.

[uglyrobot]

I can't add anything new to the discussion, but throw my hat in the ring as a plugin dev who relies on these stats:

My guess on motives from experience of running large APIs is that it's fairly trivial to artificially inflate these number with bots. Which takes up much dev time for the constant battle of trying to scale to load and adjusting algos to attempt to filter out this bad data.

Assuming that's what's happening here, we have 3 options:

1. Nuclear option a kill the whole thing (not acceptable)
2. Open the data up fully and continue the fight to clean data up as much as possible. I believe despite the data being messy, there is much more value added to the community as whole having it fully open and transparent to all, and easily extendable by a powerful API. Competition is good for users and plugin devs, leading to better quality and experiences.
3. Remove the motivation to game stats by making it only available to the plugin devs
   1. Fully transparent numbers please, I want to know my actual install count!
   2. Possibly later add in some more simplified public stat for users, like a growing/declining indicator arrow with %.

[zebulan]

Regardless of intention, it sure looks bad when a feature deemed so useful by plugin devs is removed without prior notice, and without any solid reasoning given even after much probing.

And yet it's the plugin devs who are expected to give answers? WP made the first move; the burden of proof should be on WP, not the plugin devs.

And then there's bizarre statements like this:

Even if 10,000 people commented and appeared to agree that would still be a small fraction of the wider WP community. That’s one of the hardest things to navigate in open source, and product and community development generally.
​https://twitter.com/photomatt/status/1577739784453124096

This implies that there's a significant number of people who would prefer that the stats be removed. But if that were true, where are they and what are their arguments? Again, the burden of proof is on WP, not the plugin devs.

Let's say WP decides one day to remove its built-in comments functionality. You could post the same tweet and it would be just as "appropriate". So what if 10,000 people want to keep the comments feature? We don't know what the wider WP community thinks, so I guess it's okay to remove it without prior notice and without explanation! Gee, open source sure is hard to navigate, isn't it?

I don't want to believe that WP is doing this for reasons of greed, pride, or some other sin. But it's hard to blame anyone for making such an assumption when all that has been provided thus far are unannounced decisions, poor arguments, and unfair deflections of responsibility onto the plugin devs.

From top to bottom, this change has been handled poorly, to put it nicely.

[monzuralam]

Please bring back the chart! It's beneficial for developers. If it's not shown publicly then show it only for developers.

[hasanet]

I am really just amazed to see the response from "Core" team. Not a single straight forward answer why this was removed and why was not the community informed about it. They are just asking us "Plugin Devs" to justify our cause?

[paoltaia]

I would like to see the chart reinstated too, and possibly, I would like to see more stats added rather than removed. 😔

That said, we still have a rudimentary way to see if our plugin's active installs are growing or shrinking. ☝️

The popular plugin list is still there (and hopefully, it won't be removed or altered).

AFAIK active install count is the only ranking factor of the popular plugin list.

If your plugin is moving up on that list, it is likely growing 👍 (or at least shrinking less than other plugins).

If your plugin is moving down, it will likely shrink 👎 (or at least grow less than other plugins).

I know it is not ideal, but it is what it is, and that is all we got. ¯\_(ツ)_/¯

Because wp.org only shows 99 pages (the 1st 1980 plugins), we quickly built a site to provide those basic stats to all plugin authors.

The list is elementary and shows if a plugin is ranking higher or lower than the day before and how many positions your plugin needs to climb to reach the next milestone (for example, from 10k to 20k installs)

It is refreshed daily and can be found here ​wp-rankings.

I hope it helps the community.

[isharis]

As a step 1, please bring back the statistics chart for the plugin owners only.

[Kopepasah]

There is no doubt this feature has been valuable for many plugin developers, and numerous people have given excellent reasons to bring it back until a better solution can be determined.

If that is not done, then one drastic downside is plugin developers create their own reporting engine within each plugin, causing unnecessary functionality to exist on a users site, because this metric is no doubt valuable. While I 💯 do not agree with this approach, I definitely see this as something many others would consider, and that's not good for the users.

This must be reverted.

[gwsharsha]

Please bring back active install growth chart atleast to plugin owners

[podz]

It is time to join the damn dots.

Read this:
​https://make.wordpress.org/core/2022/09/11/canonical-plugins-revisited/

Now read this:
​https://wptavern.com/wordpress-org-removes-active-install-growth-data-for-plugins

Who has access to ALL THE DATA?
Matt.
The guy who runs wp.org and wp.com and Automattic

The guy who can say "Hey, that plugin is getting traction, put it in Jetpack."

Oh yes, Jetpack..... the plugin that tells Automattic everything about plugins and themes.
Not in the wp.org repo? Doesn't matter, Jetpack will report on installs, activations, deactivations. That's the same Jetpack which has shadow profiles for websites it is installed on. That's the same Jetpack led by a8c employee GeorgeS who commented above about some spurious 'security' concern. That's the same Jetpack which if your wp install is in /public_html will crawl and report on EVERYTHING in public_html

wordpress.org used to have an 'extend' menu that covered plugins and themes
'embrace' has got wordpress to where it is
Now Matt wants to use that last E and you all know what that stands for.

[subscriptiongroup]

Disclaimer: I am not a plugin developer (of public plugins) nor a core contributor, but have been using WP and WC for many years for a business that grew from nothing to multi-million thanks to WP, WC and various plugins both made internally and some bought from marketplaces. I have no intention of swaying in either side of the argument, but will write the below to offer some food for thought - take them or leave them, but please don't take my comments personally if you disagree.

We are now in the process of re-platforming to Shopify and there are many reasons behind this, with core and plugin performance being the biggest contributing factor. We do this knowing there are limitations, lack of flexibility, additional costs and loads more.

I am not a Shopify expert, but as a system architect, one area they seem to be winning, is marketing and lack of transparency. If you look at their app store, there are no install details, only reviews and even big plugins have less than 1000 reviews, even though they claim to have thousands of users.

To the average joe, who's not a developer, Shopify looks ideal because it's SaaS, easy to install, fast, secure, extendable and even people who struggled with WP/WC have created a Shopify site with minimal dev assistance. Have you tried googling anything related to them or their plugins being hacked to see what results you get? Negligible compared to what you get on the WP ecosystem where "security" companies fight for who's the best, and in many cases use false data or exaggerate on their findings.

You then see people arguing about everything, from small to large issues. I remember the days people (myself included) argued against Gutenberg, even considered forks of WP, yet for the past year, we've been using it as the only editor for our WC store, and have even moved to FSE, something you get out of the box on other platforms.

On the topic of showing the installation statistics, have you actually wondered if those are truly accurate? We have our main site and 6 staging environments (often more), running 24/7. Can anyone confirm if those are excluded from the stats, because if they are not, they are skewing the active installs. If they are excluded, are there any particular rules for it? So do they only exclude installations that exist on localhost and ones that include "staging" or are they clever enough to exclude all duplicate sites? I've used a number of paid plugins that gave you free installs on stagings, that didn't exclude all our stagings and had to contact their support to have them removed.

Those charts look cool and a plugin with loads of installs is probably great, but can you really trust it without knowing who's actually using it? A plugin that's used by thousands of WP sites will probably not fit our needs, because those sites are likely much smaller than we are and probably have just a few visits per day (like millions of sites out there), yet the average user will install it thinking it's great.

Personally, I think giving plugin developers those stats for their own plugin is a must-have, it should be granular and should include some additional details where available, but I wouldn't display those charts publically, because they can harm a plugin, or make it look better (and safer) than it really is. On sites that have the tracking option enabled, I would even consider passing (some) details to the plugin developers.

WP/WC needs quite a lot of changes, (especially in marketing) otherwise, it risks losing even more sites to other platforms, at which point (if not sooner) developers will start abandoning it and those charts will be useless anyway.

fun fact, some weeks ago, I was looking at a plugin and noticed the chart had a strange installation pattern. Around the start of each month, it had a massive spike, then numbers kept going down for the next few days, until they reached a quite low number and hovered around it till the start of the next month. At the time, I thought "that's odd", but i didn't think of taking a screengrab and i can't remember which plugin that was. My thinking is those figures were skewed by someone/something spawing new WP sites automatically and using that plugin every month, for who-knows-what (maybe reporting?). Can anyone categorically confirm if this was a one-off example and if those stats we're arguing about are really indicative of active WP sites that are actually visited by humans? Seems to me that even Automattic cannot (or possibly are aware of bots), so I wouldn't have much faith in those charts, or even the active installs.

Another thought for plugin developers who offer a "pro" version. Could those "fake" installs (assuming my theory of including stagings in those numbers is correct) explain why you see a low conversion rate? If my business uses your plugins and we account for 7 of your installs (as explained above), you'd probably be thinking "what can i do to get those 7 sites to pay", but in reality, the answer is "nothing"...

[DavidAnderson]

Related ticket - ​https://core.trac.wordpress.org/ticket/43492 . As per the contents of that ticket, the behaviour of a default WordPress install in sending a list of your installed plugins (and other items) with your site URL (which is in the header of the wp_remote_*() API call sending the information, and usually allows personal identification) to wordpress.org without consent or notification was identified as forbidden by European privacy law a few years ago.

[quadlayers]

Hi there! I'm Francisco founder of QuadLayers
I've been developing WordPress plugins for the last fours years, dedicating my entire life to this purpose, mounting a business, building a team, etc
Since the very first day I have been very disappointed with the treatment of plugin reviewers, they don't even say "hello", when they contact you via email.
However, this is too much... Statistics are a fundamental part of the feedback we receive about our products, actually, the old statics were very poor.
Matt recently asked that we all should contribute a 5% percentage of our profits to WordPress core development in the "Five for the Future" initiative.
I'm wondering...
How do you expect us to continue contributing if we can't keep our products profitable?
How do you expect to generate a community if the review team isn't capable to say "hello" when they contact you?
This behavior triggers all the red flags. I wonder if it is time to look at new horizons, looking for new open-source communities.

[robinwpdeveloper]

The chart was really helpful to the plugin developers.
I vote to bring it back.

Please don’t disappoint us :(

[thisisandrewpalmer]

Our plugins are measured via our licensing and API system which is much more accurate and allows us to market more efficiently. It's not the fact that the data has been hidden on dot org, its the way the data was removed, if this is a community project then there should have been discussion around this.

By simply removing a thing with zero discussion prior to removal, fully demonstrates to me, that WordPress is a community of one and whatever that one says - goes, no discussion, no explanations, no empathy. Any further explanation is moot, what is done is done and how it was done there is not a damn thing anyone without the keys can do about it.

Reminder: The person that was charged to remove this item is paid by ​https://audrey.co/ who are an Investor in Automattic and the CEO of Automattic is Matt Mullenweg. No further explanation as to who ordered/authorised this deletion is required and, no one is as empowered as Matt to answer the call for a full explanation as to why a community project that relies on thousands of contributors leaves so much power to one individual. As director of WordPress, I imagine Josepha will be asking whether her position is untenable given (as far as I can tell), she was unaware of this major decision which has had a negative effect on so many contributors.

[anon6675309]

Honestly, I can live without this. The more important question is, what is the surprise tomorrow?
WordPress is GREAT. I have nothing but gratitude and respect for the creators and the administrators of this amazing ecosystem. But apparently there are too many surprises. Not sure what problem are those surprises supposed to solve.

As far as active installs, it is not the end all. I probably would not pay a third party for it. But it is not bad, particularly if you have a low active install number. I like to see if people are leaving in droves and take action if I can help it. For larger numbers is not really useful.

[Otto42]

#6521 was marked as a duplicate.

[beardev]

We also would be interested in growth chart feature. Please don't leave plugin developers blind.
Thank you!

[majick]

If the intention is to obfuscate data to prevent it from being scraped, this can be still be done by removing it from public view, while still allowing plugin authors access to their own plugin's download statistics. Is this not a simple permissions problem that is easy to solve this way?

[jegstudio]

Replying to markzahra:

Replying to johnjamesjacoby:

Hi John, I'd like to clarify a few things from your reply since it's left me with more questions than answers, unfortunately.

See also this comment from @mnelson4 on 3018:

I assume this was a closed-door security or privacy decision taken by a larger group than just the committer.

This assumption is correct. 💯

What is this confirmation based on? Were you part of the group or are aware of who formed part of that group, or is your confirmation based on something else?

as someone who recently just got released from suspension, and also got a review report rejected by @Otto42, I do not have the intention to defend Automattic or people who work behind meta team. But i can confirm that it's true if there is a security hole on active install. anyone can inflate any plugin active install, and it must be huge problem for plugin repository.

Active install count relies on user input. and it's possible to alter the behavior & response. WordPress team should really consider hiding active install from the public and make it private. having those data publicly (active install & growth) causes more harm than good in my opinion, especially if WordPress cannot really trust the data from the user. its also invite people to attack other people plugin by leaving bad review if they feel threatened by other plugin growth. Those data should only be accessible for private and provide no reward for having high active install (for example on search).

btw. we are not suspended because of this issue. and even if we can inflate plugin active install, we won't do that for our benefit.

I'm pro to make those data private only for plugin owner (active install & growth) and provide no benefit for active install count.

[forrestkirby]

Please, bring back the active install growth chart.

[anik4e]

This is definitely a bad move. Please bring back active installation growth chart.

[jorcus]

Please bring back the active install growth chart at least for the plugin author to view it. very much appreciate!

[Jules Colle]

I vote to bring back this feature

[stergosz]

I'm not going to offer any new arguments in this discussion, just going to reiterate what others have already said that this was a helpful metric to plugin authors and should be brought back until a better alternative is in place (even only to plugin authors).

Furthermore, I expect more analytics/metrics in the future so we can further analyze our plugin's performance as already suggested here.

[podz]

11 days

97 responses

Last response from Matt Mullenweg was 6 days ago

As an ex-employee of Automattic - who am I? - search for Podz - ​https://ma.tt/2006/04/a-little-funding/ - I left Automattic in April 2020 at a time and date of my choosing - I cannot emphasise enough that this thread, this protest, this THING THAT AFFECTS YOU - you the plugin creators which helped propel WP to what it is today - will NOT be changed by this thread.

Matt's MO is to deliver a Matt-Bomb which is effectively "This Is My Decision And That Is That". Commonplace within Automattic.

This decision is a Matt-Bomb.

His other MO is to ignore everyone until they tire of protesting and stop.
Look at this thread and see how the protesting is slowing, stopping.
He knows he is winning and he doesn't give a flying crap about you.

If - and this really is on you - you believe this is

• fundamentally wrong
• that Matt has gone from BDFL to DFL
• that Matt is prioritising Automattic over WordPress
• that Matt has pulled a long con of "Extend, Embrace, Extinguish"
• that you can more eloquently explain how this is hugely detrimental

then you have to change how you are engaging with this decision by Matt and take the facts to other sites.

Making noise here as useful as throwing snowballs at an inferno.
Yep, I too am such a snowball but my target is not Matt.
It's you.

Here's a quote from WPTavern:
"Even if 10,000 people commented and appeared to agree that would still be a small fraction of the wider WP community,” Mullenweg responded. “That’s one of the hardest things to navigate in open source, and product and community development generally."
Hands up anyone apart from Matt or (a staggeringly small number of) Automattic employees who thought that Gutenberg was a good idea.
Matt is very clearly telling all plugin developers that he does not give a flying crap about you.

WP Classic Editor stands at 5 million+ installs...

Here's a thing: one of Matt's long term goals is to get John Gruber of Daring Fireball to move to WP. This is one of the reasons Markdown is supported by WP. How would John Gruber feel if he did move and Matt pulled the rug on something? How would JG's followers feel if they jumped platform too?

This would seem to be very important:
Canonical Plugins.
Go read this:
​https://make.wordpress.org/core/2022/09/11/canonical-plugins-revisited/
Selective quote:
"Documentation: Experiment with adding more inline documentation to wp-admin interfaces."
I was asking for this back in 2004/5!
I was asking for this when I joined Automattic
I was asking for it even more when the "Calypso" admin interface for wordpress.com blogs was - I'd like to say launched but it was more that it was thrown into water and watched as it slowly slowly drowned over years ....
What happened?
NOTHING
Until now
Nothing until the day Matt decides what Automattic will do with regard to plugins. Some nonsense about inline docs where if people click it that could be a negative, or maybe someone just clicked a ? to see what happened, or maybe they were stuck and the ? screen helped them, or they clicked the ? and realised the plugin was not what they needed and uninstalled. What information will Automattic give you? Probably none.

Who has all the data about plugins?
Matt

Regular readers of Hacker News will be aware of posts along the lines of "I made and sold this app for iOS, Apple copied it, banned me and now I'm broke"

Who had all the data about apps?
Apple

Usual response on HN?
It's along the lines of "Don't build apps for walled gardens"

Again, who has all the data about WP plugins
The CEO of Automattic

I will not post again (maybe) to this thread because I do not know how I can better spell things out.
Matt Mullenweg is very happy to have you help make WP what it is
And now he will be keeping the entire pie for himself

I first met Matt in London 2005.
He seemed to be a decent guy
Somewhere since then something changed.

[giuse]

@Plugin authors, please, join this Slack group: ​https://join.slack.com/t/pluginauthors/shared_invite/zt-1hfj7w6up-rLBRNEpQPFGzXttSDyKpKg

We can discuss together the best solution for everybody. The invitation is only for plugin and theme authors.

[Gabriel Reguly]

Please bring back the active install growth chart.

At least for the plugin author to view it.

[webdevmattcrom]

I've been chatting with folks publicly and privately about this for the past few weeks to formulate my thoughts and make sure I'm not just adding to the "noise".

The core of the issue here is that plugin/theme authors need MORE actionable data, not less, and plugin authors are afraid of what this move means for them in the long-run. At the same time, the active install charts really weren't all that informative in the first place. Having far more actionable, real plugin statistics would be far better. Afterall, it's the plugin and theme authors that are powering the giant creator economy and pushing more and more WordPress adoption.

My recommendation is the following:

1. We should NOT bring back the charts as they were at all, which would mean closing this ticket
2. We instead start a process of talking publicly and with intention and strategy on what it would look like to have real actionable plugin/theme stats that authors need.

Why is this so important?
The consequences of removing active install data is that plugin authors have less trust in the long-term viability of .org as a source of information for their continued growth. This will mean (and already does mean) that companies that fund plugins will be rolling out their own forms of telemetry -- which will lead to another "wild west" type situation where data is being collected in and through WordPress in a wide variety of ways and become another big thing for the small volunteer plugin team to strictly police.

If there was a .org structure for actionable and non-invasive plugin data that was more actionable and reliable, then plugin authors wouldn't have to re-create this system individually, and they would also have more actionable data to grow with. Thinking REALLY big, it would be ideal that such a system could even be extended in a privacy-focused manner for plugin authors to get specific telemetry about their unique features and uses as well.

Let's close this ticket as "wont fix" and move on to more important and longterm strategies that actually benefit the plugin community. The longer we haggle over these ineffective charts, the longer it'll take to actually start getting real plugin data that is meaningful.

[andrewmrobbins]

@webdevmattcrom

I agree with everything you're saying, but in the meantime, just add the chart back. How hard could it be? It's probably one line of code.

Otherwise, how long are we going to have to wait until we get stats again? 6 months optimistically?

[quadlayers]

@webdevmattcrom I agree with you but @andrewmrobbins take words out of my mouth. In the meantime bring back the active installs chart...

On the other hand, Matt's words have left me very concerned about the collaborative spirit of WordPress, it seems to have become a sort of dictator.

The opinion of 10,000 WordPress developers is not enough to reverse his option? I wonder how many developers we are?

So, this leads me to think, that in addition to a better statistics system, we need a voting system that takes into account our voices.

[webdevmattcrom]

Replying to andrewmrobbins:

@webdevmattcrom

I agree with everything you're saying, but in the meantime, just add the chart back. How hard could it be? It's probably one line of code.

Though I don't believe there's been a real solid reasoning given for removing the charts, I do believe there were reasons -- I wish @matt would provide all his reasoning clearly so we either have consensus or more informed discussions but it is what it is.

But assuming there were real reasons to remove the charts then they're not coming back and the ship has sailed. Move on to bigger better ideas.

[alh0319]

Posting after having time to think about ​Otto's comments on WP Watercooler, specifically that this thread is being monitored for ideas for future charts that are being discussed in private Slack channels or DMs.

I cannot emphasize enough that conversations about what to replace the active growth chart with should be happening in a public Slack channel or on a Trac ticket. This data should belong to the community and the community should be able to participate in deciding how (or not) to display it.

For my part - if feedback here is truely being considered - this is what I need to see:

As near to accurate as possible active install counts by day. It doesn't have to be a chart as long as I have the ability to create a chart. A table or API endpoint would be fine. The data should be available for the past 6 months at a minimum.

We need this data to know if we're making the right choices both in our development efforts and also our marketing. Having a data point that is only updated monthly would not be sufficient because it would be more challenging to draw connections between marketing campaigns and install growth.

On that note, if we're talking "wishlist" for data, I'd also like to know...

Things that tell us if our readme and other ranking factors are on track:

• Number of searches (or impressions) for target keywords
• Average ranking for target keywords for timeframe (month)
• Conversion rates from impression to install for target keywords

Things that tell us if we may have a problem with our plugin:

• Number of deactivations per timeframe (month, preferably week)
• Number of deletions per timeframe (month, preferably week)
• Average time from activation to deactivation or deletion

Things for better testing of releases:

• Top 20 plugins also active
• Top 20 themes also active
• PHP versions (percentage)
• WordPress versions (percentage)

I'd be fine if this was opt-in. There are several plugins that we have on the repo that I could care less about any of this data, and I have never looked at the active install growth when it was present.

I think it would be better if all of this was public data, but if it had to be made available to plugin devs only, that would be fine.

If the active install growth chart isn't coming back, fine. But let's replace it with something better and quickly.

@matt tweeted that ​hosts can query this data but that doesn't really help small independent plugin developers and it puts us at a disadvantage against plugins owned by hosting companies. We need to level the playing field and make this data available to everyone.

[markzahra]

Below are some of the ideas ​shared by Vito Peleg on Twitter, to which @matt replied that "Some of these are very doable". I'm sharing them here myself while Vito is away with his family.

"I think that perhaps instead we should have deeper tools for monitoring growth/decline:

• Time to churn (to deactivate) signals good/bad onboarding, UI/UX
• Repeat installs - how many users (anonymized) install on multiple sites for community opp & advocacy
• Time to result: dev can choose 1 single hook to trigger as “result” and the calculation checks how long from install to get there. By changing the placement of the hook devs can optimize entire flows.
• Inner page tracker: which/how many inner plugin pages users visit
• PHP ver distribution, general country-based installs, active install to review ratio

The sky is really the limit and all of this can be 100% anonymous, providing value to both users and devs with no harm to anyone."

I encourage other people following this trac ticket to focus on posting alternative solutions at this point since it has been made clear that the original version of the active install growth chart will not be brought back to its previous state. Look at @alh0319's comments above for more inspiration.

[Starbuck]

The concepts of data gathering and data reporting should be separated. wp.org provided an "evaluation" of the data it gathers in the form of statistics, and has since been faced with challenges related to how those specific statistics are used, how the statistics were removed, and how the statistics might be / should be replaced. I suggest a more open approach - just publish the data, not an evaluation of the data, and let the industry render it in whatever ways we find to be most helpful.

I think all of the problems discussed here stem from wp.org taking a "cathedral" approach to presenting data in a "one size fits all" manner. In hindsight, that fundamentally doesn't make a lot of sense given the diversity of this "bazaar" of people with so many different wants and needs. We have plugin providers and consumers. Automattic needs to understand the ecosystem. Third-party reviewers might want their own unfettered interpretation of the raw data for critique of the industry.

I suggest that "raw" data should be post to an external server/repo where it can be downloaded and processed completely independently of wp.org. Data can be pushed daily, or on a similarly tight schedule. Different kinds of data can be published on different schedules to distribute the load. The community can create mirror sites to reduce the burden on wp.org. Authenticity of data sources can be established as it is elsewhere with hashes. The schema for the data can be versioned. Other details about compression and file types need to be worked out.

The community will create sites that render the data in meaningful and alluring ways. These sites will gain and lose their own reputation for accuracy, credibility, utility, UX, and other factors. This is how plugins and themes rise and fall - the model can be applied to the metadata about plugins and themes as well.

About "raw":

• There will be concerns about confidentiality of IP addresses. Initially just the class C "/24" address should avoid most legitimate controversy.
• Data volume and frequency of downloads will be a concern. Servers that offers downloads can use a login system that throttles based on number of complete downloads per day and other factors.
• Data might be summarized by ip+site+plugin+hour, where hour=0-24 and multiple plugin downloads within a window of 1 hour are only represented with a single record. This detail can be better designed by those familiar with the data, and can be refined with more experience in upcoming versions.

In summary, for many reasons I think this renamed ticket "Provide helpful plugin stats and insights" is asking for the wrong solution. Just give us the facts and let us derive our own insight from that data. I'm sure we'll see more and better charts and tooling that allow us to understand and act on the facts more effectively. This is exactly the reason why WordPress itself is extensible, allowing people to use their own creativity to add value to the platform outside of the Core.

[bfintal]

In ​WPwatercooler episode 432 where solutions were talked about, Otto brought up that one of the reasons the growth chart was removed was because it was giving inaccurate data, and that the data you can derive from it is inaccurate.

I’d just like to bring up that in my opinion, it’s perfectly fine if that data isn’t 100% accurate as long as it’s data that we can reliably learn from. If a plugin author can derive that their plugin has 500 new active installs that week, but in reality it’s really just 371 installs, then that’s okay because we still know that it’s still somewhat accurate and we can still learn that our plugins are retaining or gaining (hopefully not losing) traction. Also, the level of inaccuracy is same for every point in the growth chart, so since we’re learning from the growth rate, then it’s still great data!

[Starbuck]

Replying to bfintal:

In ​WPwatercooler episode 432 where solutions were talked about, Otto brought up that one of the reasons the growth chart was removed was because it was giving inaccurate data, and that the data you can derive from it is inaccurate.

This is exactly why I suggest wp.org provide "raw data" and not interpretations.
Please note the above "it was giving inaccurate data". No, the data is good, it's reality - unless the data used for the chart has been modified, which is malicious, and I don't think that's been a problem. The chart was providing misleading conclusions - or perhaps through its presentation leading toward conclusions that are not valid.

Also "the data you can derive from it is inaccurate": Not to be too pedantic, but we don't derive data, we derive conclusions from data - and yes, those conclusions may be inaccurate. If wp.org tells us what to think based on a limited set of charts, and we know that interpretation is incorrect, then perhaps we should have more charts to render the data (produced by third-parties)

At the very least, people need to distinguish between "data" and "conclusions derived from data". What people see on wp.org matters. It bears a great responsibility - and the chart was pulled through recognition of that responsibility - I appreciate that. If the site doesn't take on responsibility for influencing interpretations of data then we won't need to worry about this. Of all the things here, it's not necessary to host this specific resource here, and there are consequences for doing so.

(Sorry Benjamin - Maybe I'm quibbling about words when this was just a language issue.)

If a plugin author can derive that their plugin has 500 new active installs that week, but in reality it’s really just 371 installs...

The data might tell us that today there were 300 new installations and 200 upgrades. Of these there were 280 new activations. Polling data might suggest there are 1000 total installations, of which there are 970 total activated sites. This raw data can be plotted over time. It is up to the viewer of the data to derive their own conclusions. The problem comes in when there is only one resource for this data and it's telling people what they should understand. If a plugin developer can go to multiple sites to view the same data in different ways, they can draw their own conclusions about what that data means to them. As a community we can help by pointing toward better renderings, and well-written articles about interpreting the data.

[Clarus Dignus]

Replying to johnjamesjacoby:

Consider the reasons why YouTube, Instagram, etc... are experimenting with hiding or limiting the way that they display engagement in their apps & websites – because they've seen the human side when users only feel increasingly negative self-worth while they're stuck in a loop comparing themselves to everyone else – and it is the most likely outcome of implementing Stats wrong.

What's next? Disallowing negative plugin reviews?

Bring back the active installations statistic.

[Clarus Dignus]

Replying to matt:

As has been pointed out, there was never an API made for public use or with any promise of availability, people just reverse engineered and exfiltrated the data to create the chart.

I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable.

Plugin users need the active installations statistic too, not just the authors.

Give us back the active installations statistic until a superior alternative is available.

[nauriskolats]

Really hope that we will be able to have a discussion behind this stats removal. It really helped me as a plugin developer to see at least the trend-line of how good is the plugin doing. Now I feel like plugin developers / authors are left in the dark.
Please do not kill WordPress and plugin development for WordPress with lack of transparency and bad communication.
I really would love to see an alternative to these removed stats or at least the old ones brought back to life.

[dancameron]

Replying to podz:

His other MO is to ignore everyone until they tire of protesting and stop.
Look at this thread and see how the protesting is slowing, stopping.

lol

[podz]

MM said above "I definitely think we can show some more stats to plugin authors about their own plugins, and I'm hearing that for newer plugins every new install can be a motivator. Feedback loops are important. It will take some work but it's doable."

FOUR MONTHS.

Has anything happened?

[pyrobd]

I Hope at least plugin authors get some stats about their own plugins. Better for both plugin developers and users. Four Months gone, let us not forget about this.

[msykes]

I sincerely hope they add this back, I would say that info should be privy to the plugin developer, although I'd rather see it widely available than not at all.

Now, having met and knowing some developers involved personally, I'm assuming that the reason behind the pull was warranted and the intention is temporary until a fix is made. However, I'd urge a little urgency because it really doesn't bode well with regards to who holds all the data and all the keys to the community.

To the decision makers... do you really need a good reason? The question should be asked whether you can find a WP plugin developer that WOULDN'T want to have this data made available to them?

[podz]

It's been 5 (FIVE) months.

Matt Mullenweg could have made data available.

He has all the resources needed and more.

He has chosen not to.

Why the CEO of what is an effectively a competitor to you has not given that data is anyone's guess..................

If you are a plugin dev - and given the people watching this thread - you NEED to take this issue out of trac.

HN.

Reddit.

Twitter FWIW

Mastodon

Hey - update your plugins to tell YOUR USERS!

Upthread I mentioned a 'mattbomb'

That is what happened to YOU.

If you are expecting any change here then get in touch - I have a bridge to sell you.

-- Remember, I worked at a8c from 2006-2020 in Support. I know how this works.

[nastaia]

It has been five months since the stats are removed.

We missed a lot of important data that could have been cought earlier, and affected our decisions.

Please change the priority back to high.

[quadlayers]

Hello guys,

Yes, we're still waiting for some light in the darkness. We're rolling out updates without any feedback.

[eliasatcluevo]

Please bring back the data (some more stats would also be appreciated), eat least for the plugin authors...

[rainbowgeek]

Hi there,

can we have an official update on this please?

Thank you!

[giuse]

It's clear they will not do anything.

We should do something ourselves if we want something concrete. Waiting for the reaction of someone who took so impactful decisions without any forewarning is a little naive.

If you are a plugin or theme author, please join this Slack group: ​https://join.slack.com/t/pluginauthors/shared_invite/zt-1qqlmjttt-tDXGQcTMCHCQ420og2i8sQ

We need nothing else than being many and together. Only then we can do something useful.

At the moment we are very few in the group, and we have no power at all.
So, if you want to do something, join the group. If we reach a high number of authors we can start to discuss what we can do all together.

[DavidAnderson]

At ​https://thewpminute.com/how-yoast-seo-is-tackling-the-webs-carbon-footprint/ Yoast say they know that they have 13+ million active installs of their free (wordpress.org) plugin. How did they get that information? At wordpress.org, the bands stop at 5+ million, so this must have come from somewhere else.

[paoltaia]

@DavidAnderson there is more than one service that will give you the number of websites using a specific technology. The most popular is builtwith.com. I think that's where they get that number...

[Cybr]

@paoltaia BuiltWith says 11M, not 13M. Your comment does not hold much water considering this: ​https://wptavern.com/yoast-seos-php-upgrade-nag-is-producing-a-significant-increase-in-sites-upgrading-to-php-7#comment-217602.

I discussed that on ​Slack and received this answer:

[paoltaia]

Builtwith.com offers various types of statistics, (Pro, Free, Shopify). According to this trends.builtwith.com/widgets/Yoast-WordPress-SEO-Plugin, the number of users for Yoast WordPress SEO Plugin is over 12.5 million. However, it is possible that wp.org may provide more data to certain users than others, so I wouldn't be surprised if that was the case.

[dd32]

However, it is possible that wp.org may provide more data to certain users than others, so I wouldn't be surprised if that was the case.

To be clear: WordPress.org doesn't share the exact number, other than the publicly shown rounded sets, however a number of trusted individuals who work on WordPress.org have access to some data that is not publicly shown, as it's required for their contributions, they're trusted not to share (publicly, or privately with a plugin author) any data that is not publicly available or should be considered private or unverified (or statistically maybe not 100% correct - which is the case for Active Installs, and why we round them the way we do).

Plugins don't get preferential treatment based on the author or who they know. The data made available to a plugin with 100 active installs is the same as what's made available to plugins with millions of installs.

There are many ways in which plugins and services have estimated a plugins usage, it's incredibly easy for some plugins like SEO plugins that have a "finger print" on the front end of the site (Such as kind-of-unique HTML comments or HTML tags) to be estimated simply by knowing that the entire web is "XXX million sites" and by having a script crawl the top 10million, and extrapolating from that, you can get a statistical number that's probably close to the actual number. I routinely employ this method myself to validate the WordPress.org public stats, to check that WordPress.org data is likely correct.

[Cybr]

@dd32 I'm not sure why you're gaslighting us whilst something else was said by Joost on WP Tavern.

I quote:

Struck: I think a more important question is how is Yoast getting these PHP stats.

Joost: We’re getting the data from the .org team.

The people at Yoast B.V. also work as SEOs for WordPress.org, being granted access to all Google Analytics data --- this very thread sends data to 'googletagmanager.'

I'll also leave out the undertaking between them and Jetpack. But that obviously indicates that they found their users don't necessarily overlap; otherwise, they wouldn't ​promote ​each ​other. Oops, I guess I didn't leave that out.

Let's not lie to ourselves and say that WordPress is Free and Open Source. It's riddled with trialware, adware, serviceware, and even malware. Money is to be made: it's a market, and it should be regulated as one.

[dd32]

Replying to Cybr:

dd32 I'm not sure why you're gaslighting us whilst something else was said by Joost on WP Tavern.

Struck: I think a more important question is how is Yoast getting these PHP stats.

Joost: We’re getting the data from the .org team.

There's no intentional gaslighting there - If data was provided to them, this is the first time I'm hearing about it, and it's against the expectations we place upon those who have access to it. I don't know who Joost is referring to here, as a ".org team member" is incredibly vague and could mean any number of people.

I know that Automattic (Disclosure: They donate my time to the WordPress project) has their own version of the .org data, intentionally because we don't share the .org data with their plugin and product teams - they can collect through the fact that all their main plugins require a Service connection to work, which allows them to collect statistical data.

The people at Yoast B.V. also work as SEOs for WordPress.org, being granted access to all Google Analytics data --- this very thread sends data to 'googletagmanager.'

Google Analytics data does NOT include plugin active installation data other than what is publicly shown. Google Analytics does NOT have access to any private WordPress.org data, other than end-user browser activity, anyone can see what data is sent to Google Analytics through monitoring their own browser console, we don't have any custom integrations with them that send other data in the background.

[joostdevalk]

Since y’all are talking about what I said and didn’t say; I routinely used to verify the data against multiple sources, some public, some private, we have builtwith, wappalyzer, friendly search engines, and yes sometimes I have verified against .org numbers when I spoke to a team member of the .org team that could see those numbers. Let’s not make this bigger than it is; with Yoast we do get a lot of data from a lot of sides, the whole point here is (and I’ve said from the beginning) that I think every plugin author should get all the data .org has. It’s funny how @Cybr is trying to make this about me when I’m on his side 😅

I do agree with @dd32 that the .org data might not be statistically / completely correct, I think the trend is what matters.

The fact that @Cybr is mad that Yoast and Jetpack work together has nothing to do with the topic at hand (especially so because the code he’s pointing at didn’t get released). I guess he’s not realized that Yoast and Automattic have been working together for what’s now decades. We have (opt-in) tracking data, they have (opt-in) tracking data, and yes we can both see that our user bases don’t overlap entirely. Every plugin author could build tracking like that, and have their users opt in. Many big ones do. I have literally been saying for years that that data should be coming from .org and should be provided to every plugin author.

[joostdevalk]

For tips on tracking your own data, see ​this talk of mine from 2014. Unfortunately legal complications made the plan I laid out there to share this data with other plugin devs hard, because we couldn’t 100% guarantee that there wasn’t going to be identifiable data in there. I do encourage every plugin developer to get data like this, because it helps make good decisions. Still doesn’t mean we / .org shouldn’t be providing more data to plugin developers.

[Cybr]

@joostdevalk if you believe the data should be made available to everyone, disclose the data you have obtained, but please do whatever is necessary to remove person identifying information. It will bypass this entire discussion and benefit every plugin developer. Subsequently, you’ll absolve yourself from our (I’m not alone) accusations.

If any random plugin would obtain data from its users like you are suggesting, it will crown WordPress as spyware. The plugins will then do things out of scope of their project, which is against Open Source principles (and common decency). Moreover, data is already acquired by loading assets externally — even “innocent” images do that, which I believe is also against plugin guidelines.

[joostdevalk]

You’re mending my words to make me say things I didn’t say. I have on occasion in the past seen raw active plugin install data (and nothing more, the rest is our own opt in tracking) for our plugin, and checked that against our own numbers and models. We started tracking our own data at Yoast in 2013-2014 (see the above linked video) and can extrapolate that and other data very reliably.

Please note that I’m no longer active at Yoast and have another role now, so I can no longer speak for how the team does that specifically because I don’t get into those details anymore.

Back to the issue at hand; I think WordPress.org should show the raw data to everyone, because they have value. Mostly in the trend, but also in the discrepancies.

[Cybr]

I'm sure there are plenty of bright people working on Meta who can develop something to aggregate meaningful data in 17 hours. I know I have for my update servers.

So, why hasn't there been any sign of progression for 17 months? Why are plugin developers being set aside? Are our contributions not good enough for WordPress?

[podz]

-- Matt will delete this quickly --

WordPress would not be where it is without plugins.

I have used WP since 2004, since my-hacks.php

Right now:

"Extend your WordPress experience! Browse 59,657 free plugins."

Assume that each plugin developer made 10 plugins, that means that Matt is denying data to almost 6000 developers.

SIX THOUSAND actual people.

Yes that assumption is daft, there are way more developers.

Yet I see no noise though. Nothing on HN, Ars, The Verge, Wired, The Register, Slashdot, Reddit, Facebook etc.

I have no horse in this race apart from the fact that I honestly believe that the witholding of data - data which is being used to enrich Automattic - is wrong.

It really is fundamentally wrong.

As a plugin dev data doesn't just help lead development, it also gives you that feeling that "Yeah!" as you knew you were filling a need.

I wonder what worries plugin devs about speaking out?

What power stops you?

This is not a crit, it's an honest question.

Don't answer me here, or anywhere, but something surely has to happen to at least try and stop this guy from effectively exploiting you.

Plugin devs didn't just help get WP to where it is, it also helped get Matt to his multimillionaire guru cool status.

He owes you more, far far more.

[eliasatcluevo]

Replying to andrewmrobbins:

@webdevmattcrom

I agree with everything you're saying, but in the meantime, just add the chart back. How hard could it be? It's probably one line of code.

Otherwise, how long are we going to have to wait until we get stats again? 6 months optimistically?

6 Month... that would have been good actually

[nastaia]

I completely agree with @podz on what he is saying. It's been hard for us to calculate growth after removing the chart.

We still don't know the real reason why the chart was removed in the first place. We heard that the data wasn't accurate, well, make it accurate. In the same way, you're counting the number of WordPress sites globally, you can count the number of plugins installed.