Since I’ve done a lot of this over the years, I thought I would share with you my experience in evaluating and picking Open Source projects to use inside closed-source companies. (It may very well be different at companies that Open Source their own stuff – I don’t know.) This isn’t to say that I always pick winners – I’ve definitely been burned. Hopefully, though, my experience will help in making the best decision you can with the information you have at the time.
What should you be looking for when you don’t want to reinvent the wheel and want to use something someone else has done in his or her free time? (Yes, I’m being a bit facetious, as I know that several companies stand behind Open Source projects; however, most of them are still maintained by volunteers.)
- Project inception date – when was this project started?
- This doesn’t tell you anything on its own, but combined with some of the other criteria below, it can help you. Are they young, un-tried? Or are they old and stable? These two criteria are probably more viable than if the project is old and hasn’t had a release in over a year.
- How many developers?
- Is there one lone developer working on it? This is a bad sign in general.
- Does it have 4 or 5 solid developers who are contributing regularly to it? Is there good feedback from the community and other developers? This shows a much healthier project.
- Mailing list size/questions/activity
- How active is the mailing list? What kinds of questions are being asked on the list? A healthier project will have a lot of questions on a mailing list, with a fair amount being “How do I…?” questions, with timely responses by non-core developers/users.
- If recent activity has slowed check to see when they last made a software release. If a release hasn’t been made in a while, it’s probably a good idea to move on.
- When did the project last make a software release?
- If it was more than 6 months ago, check the mailing lists. If those are dead it’s probably a good idea to move on. If they’re still active then take another look, but be wary.
- How frequently do they release?
- Do they make a release every few months? Do they have a project roadmap (that’s current?)? If neither of these is true, then you might want to be careful in picking this one.
- Is it stable?
- How long has the project been around? More than a year, with multiple releases? Good. Also look at bug reports. How quickly are they being fixed and released into new versions?
- Also something to keep in mind: does this project continually change it’s API in the name of progress? If yes, then it isn’t necessarily a good choice for what you want, as upgrading to a new version down the road may be a huge pain.
- What are your needs for the tool/library?
- Does it have all the hooks or features you need? Or 90%, 80%…?
- Can you easily modify or extend it to use in your project?
- Is it language-compatible? Can your developers understand it easily enough, or get up to speed on it quickly?
- Is the software license compatible with your existing software?
- What is the cost of support? Do they have any support options available? Are there other companies that support this library/framework? (A yes is a good sign of a healthy ecosystem.)
- Support can also mean a good, active mailing list
- Or, support can take the form of training, companies that make money off training for said framework/library can be seen as a good sign (generally speaking, but it can also speak to the complexity of said framework/library)
Do you have any other criteria that you use when you’re choosing an Open Source library or framework? Please share in the comments below!
