The second signal I look at is activity. If a project hasn't had a commit somewhat recently, then there is a good chance it's not actively worked on, or does not serve a very large audience.
To be clear, not having a large audience isn't always an issue, every project starts with 0 forks, but it's always tough relying on a project that has open Pull Requests sit un-merged simply because the original author has abandoned the project.
If the project has a small user base, the third signal I try to use is to look through some of the code base and documentation. Can I jump in and make a fix, or is the code style so esoteric that it would take me a long time to grok.
If it is close to what I need, I submit a pull request against it. Depending on the reception and how people take it, and how easy it is to get it accepted is good signal on how easy it is to work with the project.
When doing the PR, you get a feeling of how the code looks. Is it straightforward? Commented? Do you like the style, do you see obvious errors? Any red flags should be noted.
At any point, if you think you can do better, you can fork it or start over from scratch and do it yourself, with a lot more information on what you need, and what the possible pitfalls are.
I think many people spend too little time on qualifying open-source dependencies or tools that they will use on a project. It'll do you a lot of good to dig into the source for an hour or so. If nothing else, read through the source that makes up the surface of the API that you are going to be using.