When validating library quality, we like to take a look at some metrics like the time of the last commit or the number of stars as if those relate to quality. It's the easiest thing to do, instead of validating the quality by other means, we go with the easiest approach of following everybody else.
With this we save time, which means saving money for our employers, but there is a price we pay. It is not free. We risk choosing the popular option instead of the better one.
What if instead of looking at the stars, we focused on reading every library we included? It's all open source so this is a great benefit of it, being able to read the source code.
Easy, right?
Not really. Reason for this is that we use the baterries included libraries, popularly known as frameworks, which are large in scope and that's what prevents us from reading the source code in a reasonable amount of time. Unfortunately those projects are usually more popular than the smaller alternatives.
The larger the scope of a library, the more it needs to be maintained, so the perceived status of it is that it's being actively developed. Meanwhile, the smaller libraries don't need so much maintenance, so if we only look at the time of the last commit as a metric for determining the quality we'll go with the larger one and we'll perceive the smaller one as collecting dust.
If we used libraries that are focused on a single feature more, we would end up having codebases that are more easily understandable by a single person in their entireties. [1]
We could say that the point of having libraries is abstraction, which hides away the nasty implementation details in a black box. In my opinion, programmers need to know at least the basics of how those black boxes work internally in order to be able to construct quality software with them. That's easier with libraries with narrower scope.
The biggest risk of going of reading source code of libraries to be included is investing time in libraries we're not going to end up using. Good practice for alleviating this risk is by only considering small libraries. [2]
There are a lot of benefits from reading the source code, so why not do it more often? Especially when it comes to something as critical as deciding if library should be used or not.
Niklaus Wirth writes that a system that's not understood by a single person in it's entirety shouldn't be built. Read more about that in his excellent paper A Plea for Lean Software [1995].
Check out a mirror of microrb.com as a way of finding small libraries in Ruby community.