Honestly, I think it's better as a question/koan than as explained. Asking yourself how good these each of signals really is and asking yourself how they could fail is probably much better than having a random internet commentator try to talk you into it.
But:
- last commit: I'm not surprised to see this here. Almost the entire industry is deeply invested in the idea that software can never be done, only abandoned, so deeply it's almost invisible. And projects with enough surface area likely are like the proverbial shark: either moving or dead. But for modules with limited, well-defined functionality, reaching a steady state where the project is actually done and updates are rare should actually be a sign of quality.
- number of contributors: again, I suspect that where this coheres with quality, it's probably correlated with size/surface area. Plenty of limited, well-defined projects probably are good with one or a handful of contributors.
- interfaces: are we talking about presentation of the project? Or the UX of an app? Either one could be a sign of overall craftsmanship, or it could be a sign that the author is concerned with appearances/marketing.
- code quality: tautologically true (code quality is related to project quality) but not helpful. One might easily mean "do the authors of this module follow my favorite code style guide," in which case I think this is extra likely to lead you astray.
- unanswered issues: unanswered issues seem like a great signal. If they're present (and real), the author(s) either can't fix them, or the project is abandoned while actually needing improvement. Inversely, if there are answered issues, the project is being used and attended to.
