Here's my checklist regarding project maturity:
Has the project reached its initial milestone?
I would avoid adding any code if it hasn't reached its self described initial milestone. I don't suggest that you should always trust a developer claiming that his project is production ready and always try to evaluate such claims, but you should definitely trust her when she tells you its not, ie labeling the software as version 0.x, alpha, beta, release candidate and so on.
Is there adequate documentation?
A perfect project would offer:
- User guide full with examples
- An integration / extension guide if it's a library
- API documentation
- Fully documented source code
- A public issue tracker
Are the developers still committed to the project?
You can never tell if the developers will stay committed in the future, unless of course it's a foundation / company backed project. But you can almost always tell if they are committed right now, by checking for:
- Recent commit activity
- Recent features (not just bug fixes)
- Recent documentation activity (docs updates, blog posts etc)
Also a good indicator of project maturity is a second generation of developers, active developers who got involved after the initial milestones.
Are the developers reachable?
- Do they respond to bugs?
- Do they provide other means of contact, apart from a generic issue tracker? This is a minor item on the checklist, but for single developer projects alternative means of contact could help in cases like the "case of the missing developer".
Now, for your more specific questions:
Velocity
In a project with a public issue tracker I would definitely check to see how much time does it take for issues to get closed. Of course speed doesn't always mean quality, so I'd probably go through closed issues, pick a few I'd consider important and evaluate the developers response time and quality.
Licence compatibility
As for legal issues, never integrate an open source project in your codebase if you are not 100% certain that your use of it is compatible with its licence. If in doubt, you can always ask the developers of the project, or even ask here.
Community hype
You should always evaluate hype. Recommendations from fellow developers are almost always a good enough indicator of project maturity.
Every item on the checklist is optional, except licence compatibility. I've integrated a lot of dead and or undocumented projects in my code, it always depends on what your specific needs are and how you see your own code evolving.