I very much like how GitHut used issues/commits. In my interpretation:
(1) If your project has a lot of commits and few issues it has a very high quality.
(2) If your project has a few of commits and many issues it has either very low quality or is not being developed.
(3) Having a lot of commits and a lot of issues and vice versa is kinda expected, since new features(commits) often introduce new bugs and small projects often have few of both.
When you cross that with popularity(new forks, new watchers) over the years you can narrow (2) with some confidence.
Using that approach is trickier when it comes to comparing languages, but the data GitHut gives seems to be in line with common knowledge, at least when it comes down to open source software and and when you compare the most popular languages.
Hard to say much for sure without breaking down the details, who's discovering the issues, how many are real, how many are serious/blockers versus minor annoyances with workarounds or feature requests, are the commits new features, bug fixes, refactoring, etc.