Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
When you find a new open source library / project, what criteria do you look at before incorporating it into your source base.
Are there legal questions you need to answer?
Do you look for a certain amount of development velocity?
Is the community buzz a good enough reason?
Does your decision change if you are the one on the line for the project?
Does the complexity of the domain or code change your way you think about it?
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:
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:
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?
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.
In addition to the answer stated by Yannis Rizos, I'd try it out in a short side or test project if possible. This will allow you to get familiar with the quirks of a product before any important is at stake. The project shouldn't be too small, as this would leave too much of the codebase unexplored. Take it for a spin to see if can do what you want from it without too much of a hassle. If you can't get the basics working on your own with the help of the documentation and a question or two to the project community, you might want to consider looking on to a more suitably supported codebase. If the initial test works out for you, you can start using it for real. I've had to deal with this problem in the past, and after the first two times I've made it a rule for myself to test new things before taking it into production, no matter what the rep was or the apparent level of documentation.
BP wise: introducing new stuff should never be done without some form of a preparation/learning phase.
