On long term sustainability for third party plugin devs

Thanks man!

1 Like

Perhaps I should use a different popularity metric. An alternative metric is the rank of free plugins added to VCV accounts in the last N days. However, this would prefer new plugins to old ones. Any suggestions for a metric?

For me that you be great, but with the caveat that I personally am kind of competitive, and actually look at those rankings. It’s frustrating to see abandonware modules up higher in the rankings. as to what’s best for users, I don’t know.

Depends on what you’re trying to sort for with the ratings.

  • Total installs/adds to accounts will reward older plugins just because they’re more likely to have been installed. Does the plugin “lose” a point when someone unregisters it? If a lot of accounts are made, live for two weeks and die, do those old plugins keep their prestige?
  • Having rating epochs (ex. every week, or such) and sampling the plugin roster from people who have had update checks done that week, might be fair since it will only count the choices that active Rack users are making. (Can run these through some exponentially weighted moving averages to smooth out the jitter.)
  • A variant of the above that doesn’t require a lot of querying (although is going to be less fair) is probably to give a point the first time someone adds a plugin, but subject the scores of plugins to cooling (c.f. https://www.evanmiller.org/rank-hotness-with-newtons-law-of-cooling.html)

Just some thoughts.


@Vortico I don’t remember how current metrics are implemented, but a simple fit could be a “weighted” average for each plugin, i.e. number of subscriptions (downloads) divided by span period of exposure (days elapsed since the first publication and availability in the Plugin Manager). This don’t get rid of inevitable deviatons and anomalies (plugins dismissed then reintegrated, false downloads, etc.) and don’t accounts for trends or peaks or windowed view (last N days for example). Furthermore it should retain as “popular” also what’s more appropriately “hot” (it could be the case of Blamsoft if we consider only the period since its plugins are free, I think it got many downloads in few days, so it should result “popular” although it’s surely “hot” while the status of “popular” will make sense if users will keep downloading it at constant rates).
To not unbalance the ranking for “popularity”, another solution could be a no-go solution, I mean, do not expose a precalculated metric, but to expose raw splitted datafields: 1. total downloads - 2. time elapsed from the date of public release in the PM - 3. other optional evidence data, for example “max downloads per day” or “average downloads in the last week”.
One note, I supposed that the raw collectables data are at hand, that’s not obvious thing.

There’s another, more classical open source approach.

What we currently have looks like a whole bunch of rock stars making their own thing. Kind of fits with the music theme I guess, but it’s prone to flutter with the whims of personalities involved.

I wonder if anyone is interested in a more collaborative approach. A plugin with modules designed more carefully and slowly, contributed and maintained by multiple people with the intention that the project lives beyond any one person’s enthusiasm for it.


Sounds like an interesting experiment, if “design by comitee” can be avoided.


I wonder if anyone is interested in a more collaborative approach. A plugin with modules designed more carefully and slowly, contributed and maintained by multiple people with the intention that the project lives beyond any one person’s enthusiasm for it.

I think that unless they specifically state otherwise, plenty of module developers would accept at least comments, and likely PR’s if their projects are on GitHub. I know that I’ve accepted both additional modules and a full redesign, and I’ve seen similar activity on other modules available on GitHub.

it’s worth opening up an issue and broaching the conversation, especially if there’s something that interests you.


So you want the Firefox of plugins? :stuck_out_tongue:

Absolutely. I’ve filed feature request issues on no less than 10 repos in the last year.

1 Like

@Patman maintainers don’t have to accept every PR :slight_smile:

1 Like

Oh I know. I was just being a smartass :wink:

1 Like

After the recoil of Animated circuits and Blamsoft I wonder what guarantee users have before spending money on modules that will possibly be released for free in the future?
What guarantees do we have that the payment modules will continue to be supported?
If these small companies have decided to endorse the project, can we expect large developers to join the project?
I hope that in the future VCV rack adopts a model that guarantees more for both users and developers.

I’ve seen apps go free after years of pay on app stores - SwiftKey comes to mind the most here. I wouldn’t be surprised if things end up going this way down the road, with something along the lines of a different skin architecture allowing for paid reskins of modules, or, as @modlfo has done, bonus modes for paid users.

Allow module/module series upvotes? Breakdown by both all-time/last month? I think the community is serious enough to not abuse the system


Yes, complete with foundation.

But seriously, I’m wondering if a vcvrack plugin project would work as an explicit community development effort. Sure, some devs welcome feedback, ideas, possible implementations. I’m just talking about pooling resources. With the aim being to keep plugins alive, even after original authors lose interest and move on.

Personally I quite like the overall metric. I guess it depends on what we want to measure, but “how many people currently have it installed” seems like a good call.

Might drop the counts for accounts that haven’t connected for a period, like 6 months or something. It might be good to get more detailed metrics in a separate page per plugin, if you’re willing to go to that level.

In that, a timeline of when people added/removed plugins would be good. Some way of collecting how often a module is instantiated, with a similar usage timeline, could be interesting, but it might be too invasive.


Great suggestion !

I am sure it would work. We are just at the start of the life of VCV. There has not been the consolidation of development efforts, more shared development and building of more advanced libraries for module development and the essential weeding out of obsolete modules.

This has happened to almost all open source projects that I have taken an interest in over the years. I do not see any reason why VCV should be different.


like these guys in php-land?

I’m learning vcvrack dev right now and would help/join any collab effort to maintain certain plugins etc.

1 Like