> As a community we need to accept that the above mentioned DOES happen. Pretending otherwise only hurts us all.

In fact, it happens very often when people are learning and exploring. So imagine I publish my shitty library "with a generic name and a description talking about how awesome it is". Imagine you're trying to learn $language. You buy into my deception and try to use my library. You get burned, and might be left with an impression that $language or its ecosystem is shitty, and never return, despite the fact that $language would suit the kinds of problems you're solving really well. If it happens enough times with enough libraries, $language may get a bad reputation. Preventing this becomes a matter of protecting the common good.

Hands up everybody who remembers "Matt's Script Archive"?

(Hmmm, just the greybeards. I could have guessed that I suppose...)

One way to judge that is by whether the project was consistently maintained, what kind of issues are reported and if the important ones are fixed.

So if the project seems to be ignored (no issues), if it has tons of them and no response, you won't use it or use it only with caution.

Newcomer to langue or ecosystem should use popular frameworks and libraries, so that there is help available.

There are many things short of reading the code in full you can do to lower the chances of this happening. A lot of half-assed libraries have obviously incomplete APIs that you can notice if you think about the interface provided and the nature of what the library claims to be doing. You can also look at repo activity; was it all coded in one week 8 years ago and never touched again? Does it have lots of outstanding issues?

Some things may slip through the cracks, but filtering out most of the chaff can be done without reading every line of source.

This. In my experience, GitHub issues and PRs tell you most everything you need to know about an open source library: if issues are responded to (and how quickly), the attitude of the maintainer with regards to new features, etc. Most of this can be gleamed within 20 minutes of browsing, and when you combine that with a quick 5-minute look at dependencies and tests, you can make a pretty good, educated decision about whether to use the library, and those 25-30 minutes save you hours or days of potential headaches down the road.