There are some open source projects that I'd like to incorporate into a product at work. We don't have the bandwidth nor the subject matter expertise to do it ourselves. I found these by searching in Google. I'm unaware of any "major players" that utilize the projects, but I'm pretty encouraged by what I see.

Now, I'm a bit concerned about the amount of risk I'm exposed to by using joe-blow's open source project. If it takes me 95% of the way there, perhaps the remaining 5% is easy to add or fix. Perhaps it's non-trivial.

How do people go about determining whether an open source project is mature enough to use in a product?

This is not a hobby project, so stability, maintainability, etc. are paramount.

  • You never know for sure. Is Windows mature enough? Test it and try to contact developers - personal contact (emails?) can say much about sanity/maturity of the project they have created. – SChepurin Mar 10 '13 at 6:15
  • 3
    The only important thing is whether it fits your requirements. If it does, you simply use it. If it's not "mature" (the definition of which is debatable), you can start contributing to the code/discussion/docs/community/bugs/xyz to mature it. – treecoder Mar 10 '13 at 6:38
  • 1
    Write a really good set of unit tests before you include the new library in your actual product. – Jim In Texas Mar 10 '13 at 14:34
  • @greengit: It does not even have to fit all requirements as long as no alternative fits them better. – Jan Hudec Mar 12 '13 at 9:04

The criteria I use, providing that the project fits my requirements:

  1. Is there an active community, with people able to provide assistance?
  2. Is the license appropriate to my development?
  3. Is the product still under active development?
  4. Is it a commonly used framework?
  5. Can I find any reviews / blog posts / etc of the product and how people have integrated with it?

4 & 5 don't really help for niche projects which it sounds like yours is.

The single most important thing is does it meet your requirements? If you feel that it does, the next thing to do is to make a harness to test the project and see if you can do what you want it to do. This will give you a feel for its API (if it's a library) and how it works.

At the end of the day, if there is something open source that does 90% of what you do, fork it, add the extra functionality and return it to the community. I've done this before on commercial projects.

  • 6
    Never forget that the 95% done means there is only 95% left to do.... – mattnz Mar 10 '13 at 4:54
  1. For framework, I generally only go with large and mature framework with lots of prewritten modules and large community. Generally, choosing one framework over the other would not really reduce the amount of work you need to spend on your own code by much, some framework may encourage a more beautiful code, others may make certain operations easy, but they generally sum up to very little difference to total development effort. However popular frameworks would have more prewritten modules you can leverage off and that's how you can usually save much more time and effort.
  2. For small non framework library, generally you'd be able to make modifications yourself if needed without much problem, so usually I'd consider having community as an added bonus. Most small libraries are only managed by a single person, but they still are better than building yourself. For large libraries though, having a mature, active community, and documentation is essential because you're unlikely to be able to make changes yourself as easily.
  3. License is essential. For one-man libraries, it's likely that you'll need to make modifications to the library, therefore it's essential that their license allows you to do so under terms you'd agree with.

For small libraries, you should always assume that you'll need to fork and that the project is already abandoned. This is usually not a problem, especially if the project is hosted on Github or BitBucket, because they make forking other people's project stupidly easy. For small libraries, you can always take over the maintenance of the project yourself, if the original maintainer is gone or if they're planning to take the project direction to places you don't want to go to.

I'm less concerned with project activity, mature library that have achieved their sense of "perfectness" generally would only need to do bug fixes, so their activity slowed down. Project activity is only important if the library involves a target that is actively evolving, for example, a wrapper for external service would need to be constantly updated as the external service evolves, so active development is essential, but a math library would not need much new development once it has all the feature it needed.

For larger libraries, things become more difficult. Taking over is much more involved, fortunately larger libraries generally do not move as fast, as they're generally more mature.

As @Sam said in his answer, I agree that the most important thing in evaluating open source library is how much it fits your requirement. Once any license issue is sorted out, using an open source library is rarely a mistake because you can always fork if things go south.


Look in the project's bug tracker. If you see lots of tickets filed by lots of different people, and responses coming from a variety of people too, then that's a good sign. More bug tickets == bigger user community == more likely to be ready for production use by you.

  • 2
    While that's definitely a way to see if a project is being used in some capacity, you need more context than simply a count of bug tickets to know if the project is reliable enough for a production system. If, for example, the majority of the bug tickets have been open for awhile and are still not resolved, I wouldn't want to incorporate it into a business critical system. – Derek Mar 11 '13 at 20:36
  • Actually, I think it's okay if even a majority of tickets have been open for a while and are not resolved. This can be more an indication of the size and engagement of the user base than of anything about the software itself. More on that topic here: rants.org/2010/01/bugs-users-and-tech-debt. – Karl Fogel Oct 22 '19 at 16:31

The news is not good, but that doesn't mean it's incorrect: You do not know.

If there were analogous implementations in production, you would know it's feasible, but as you said no "major players" use the projects.

If you had developed in house, then you'd know, but as you said, you don't have the resources.

It's reasonable to want to know, but... you don't.

I hope this answer does help, because you should have contingency plans for pulling the plug on any technology that you depend on but don't control... and knowing that you don't know if it's dependable is a step in that direction.


The question has to be put differently. What you are really asking is is using this open-source project the best way develop the product?

That necessarily involves not just the open source project in question, but also your other options. If your only other option is writing everything yourself, than you are better off using the project if you can understand it's code enough to be able to modify it.

Than of course the other question arises whether your project is viable at all. I.e. you need to estimate the effort including any risk of having to fix or complete the functionality you hope is provided by the open-source code. If the project is not widely used, you will have to review the code for that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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