| This article feels like a follow up on "On Ruby"[1] and related to "It’s OK for your open source library to be a bit shitty"[2]. The common theme I find in all three is the quality and health of a dependency. I agree with OP that stars and latest commit are not clear indicators of quality. I think more useful indicators are tests, documentations and pull requests. * Tests. These are things you can actually run to see if the library actually works. In most cases, you can read them and understand how it is supposed to be used. On some platforms even if the tests passed in the past, they may not pass now, for example using different version of the language or platform. The coverage of the tests would be nice, but it is hard to measure at first sight, therefore using the ratio of tests LOC to library LOC might be an indicator. * Documentation. The documentation itself does not change how the library behaves but it is a clear indicator whether the author expected someone else to be able to use it or not, and shows a sort of responsibility. Most of weekend hacks would not have one. * Pull Requests. If there are old and open pull requests, that seem useful, it is a bad sign for the maintainer of the project. [1] http://hawkins.io/2015/03/on-ruby/ [2] http://www.drmaciver.com/2015/04/its-ok-for-your-open-source... |