Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 19 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.