[Feature Request] historical adoption metrics

[smartin015]

What do you want to see implemented in the plugin repository?

I'd like to see some longer historical data around plugin adoption, to complement the 7-day and 30-day active user metrics already published.

It would be fantastic if there were multiple historical dumps of weekly/monthly plugin stats, in addition to the current json dumps in https://data.octoprint.org/export/. Even something as simple as "copy the current json files into a /yyyy/mm/dd/*.json folder" run once a week would be enough to do some manual analysis.

Even cooler would be a graph on each plugin page that shows how adoption has trended over time.

Why, what problems would be solved by this?

The "new installs" and "active instances" stats sections to the right of each plugin are great! But as a plugin maintainer, I'd like to know more about how my plugin has performed over time - whether adoption is growing or shrinking, and by how much.

With this information, I can see if my development effort has been worthwhile, or if people are losing interest / leaving for something else.

Any additional information you want to provide?

Happy to help contribute to make this happen, although I haven't been able to see how the data export stuff works from a brief search through octoprint's repositories.

[jneilliii]

A couple of us have done our own where we are scraping the exports and storing in our json file. You can see mine here and Charlie and Taylor have done similar ones.

https://jneilliii.github.io/OctoPluginStats/

https://octopluginstats.vercel.app/

https://the-eg.github.io/plugins-dashboard/

[cp2004]

I was just typing out the same set of links...

[smartin015]

Wow, thanks for those links! I'll look into setting up an instance of my own.

Bit of a shame it has to be a separate instance though, since it appears I'm not the only one that's thought about this. Y'all can do what you like with the FR - I'll leave it open in case you think there's merit in a more central solution with less scraping.

[cp2004]

Bit of a shame it has to be a separate instance though, since it appears I'm not the only one that's thought about this.

The positive spin on it - you get to customise it to what you want and I learnt a bit of React/MUI stuff at the time doing it as an experiment 🙂 . Ideally, the less things that we can maintain the better - it may benefit a few plugin authors, but it is adding more stuff to maintain across the octoprint.org sites for a very small number of people, often just one.