For better or worse, people are looking at package downloads, github stars, and github issues as measures of a package’s ‘aliveness’. Obviously, there’s lots of issues with this:
- Github issues can be a measure of either a package’s popularity; or a measure of it’s bugginess.
- Github stars aren’t a good measure when packages are forked, and maintenance hops to a new repo.
- Package downloads aren’t reliable because of module dependency distortions.
- Package downloads aren’t reliable because of spamming from continuous integration servers.
But stars, issues, and downloads are the only metrics people have to work with, so that’s what they use.
Personally, for the companies I work with, we’re more interested in design coherency, package integration, high signal:noise ratios… what we colloquially call a ‘.NET’ approach. So the metric there would be something like
SUM [ number of QA tests / number of methods ]_package(0->n)
Basically a measure of QA test coverage over a predefined package space. When Meteor first published around ~0.3, it had a small package space with Tinytests across all the packages, and had very high internal consistency. When Atmosphere was released, and there were less than a thousand packages, there was high internal consistency. In both cases, high signal:noise ratio.
As we add NPM support, the signal:noise ratio is tanking as everybody adds their preferred library. It’s great for adoption; but lousy for internal consistency and user experience. And that’s where all these threads and discussions are coming from.
Release tracks and distros are one possibility for counterbalancing that trend, and improving the signal:noise ratio. But it’s a somewhat untested approach in the Meteor ecosystem. The Meteor Guide is another attempt at boosting signal. There are various features that could be added to Atmosphere to boost signal; but the latest word is that it’s being deprecated in favor of the sprawling mess that is Npm*.
*A useful mess, to be sure; but I shudder to think of the days of my life I’ve lost in investigating abandoned packages on Npm; it’s got 100,000+ packages; and a Pareto distribution suggests that 80% or more of them are abandoned; ug.