Edit: turns out what I have in mind nearly already exists at http://eirikb.github.com/nipster
In inactive problem domains (such as linting, which these days sees few commits and has almost no competition), you wouldn't need as strong a decay coefficient. Lack of activity suggests a solved problem or something that is no longer a problem.
Highly active areas such as asset management (ender.js, browserify, require.js, etc.) you'd probably need some sort of coefficient for that problem domain. Tagging could be used to strictly or loosely assign packages to a problem domain.
Acceleration is another issue worth considering. How quickly is a project being adopted among those that matter.
Anyways, it's not a trivial problem to solve by any means once you get around to measuring social aspects surrounding a module, but it certainly is a step in the right direction. It's also a problem whose solution can be continually refined.
TBH, I reckon that any refined system is going to look increasingly like a financial mark where certain behaviors are analogous to actions like put and call options.
It'd be awesome to have a smidgen of transparency into private repositories in the form of aggregated gripping of the require() statements in active private projects. You could go even farther and look at the number of method invocations of a particular library.
It would be cool to be able to view such data in the same way Google Trends works. For example, it'd be interesting to compare optimist, nopt, commander and nomnom.
(going to stop now because I'm just rambling now. hehe)