There always comes a time on a software project when you need to decide whether to build a feature or use an open-source implementation of it. People have differing views using open-source software. Some use every jQuery plugin they can get their hands on. Some will berate you for even introducing a new gem into a Gemfile. Some want to build everything from scratch. I’ve met them all. I tend to take an optimistic approach by giving open-source software a chance while still evaluating it strictly. With so much free software available now, we need a reliable way to find quality software and reduce the noise.
Why use open-source software?
We all know the awesomeness of open-source software. Open-source projects like Rails, jQuery, Chef and Bootstrap have saved countless hours of development time. It's impossible nowadarys for a real-life software project to work without using some open-source software. Why would you want to build something without using at least some open-source software?
Sometimes it's just not good a fit
One can make a case for not using some open-source projects. For example, an easy red flag in JavaScript plugins is bloat. When a non-essential part of a JavaScript application adds a large amount of code you should probably either look for an alternative or figure out how to build it yourself. Another consideration is how hard it’s going to be to integrate an open-source project with your set-up. If introducing a plugin into your codebase requires a massive refactoring just to get your system to work with it, then it’s time to look for something else.
How I evaluate open-source projects
Does it do what I need it to do?
The very first question you have to ask yourself when introducing an open-source project into your codebase is simply, “Does this do what I need it to do?” If so, then ask yourself, "How much more does it do than what I need it to do?" By that I mean, will it introduce a bunch of features that you don’t need?
A simple example is using jQuery UI if all you need is a modal dialog. jQuery UI has a hefty file size because it does a lot more than just dialogs. It would be best to consider wether you really need all those extra features or if you can find an alternative that would be less costly. In defense of jQuery UI, the team realizes this extra bloat and they provide a way for you to build jQuery UI with only the modules you need.
How much more do I need it to do?
Conversely, if the answer to the original question was no, then you have to ask, “How much more do I need it to do?" More often than not, an open-source project will not do exactly what you want. You need to figure out how much more you need it to do and if you can build what you need into that project. The extensibility of the project is very important. It’s one the biggest reasons projects like jQuery and Rails became so popular. They take your project part of the way to being done and make it extremely easy for you take it the rest of the way.
Documentation
After seeing a few demos and examples you’ll most likely want to dig right in and start integrating this new thing into your project. Before you add that gem to your Gemfile make sure this project has decent documentation. It’s disheartening when you get excited about a cool plugin only to realize the documentation is horrible. Look through the documentation before you get too attached to an open-source project.
Easy to review source code
I get annoyed when the only way to look at the source code of an open-source project is to download it. It's so much of a hassle that nine times out of ten I just stop looking into the project there and then. With services like Github and Bitbucket being so prevalent, I find it odd that an open-source project isn't on one of those or services. It tells me something is not right with the project, as if the owner doesn’t want the transparency that the code-sharing sites offer.
Popularity
There are several ways to gauge the popularity of a project. The quickest being the number of stars or forks a project has on Github. There's no scientific way of determining the minimum number of stars a project needs before I decide to use it, I tend determine that number case-by-case. In general, the more specific the project, the less stars I expect the project to have before I use it.
I follow a large number of developers on Twitter and read a lot blog posts about programming. When someone I trust with expert opinions mentions an open-source project it gives me a lot more confidence in using that project. I still need to form my own opinion, but my frame of mind is changed so I want to give a project a better chance.
In the same vein, I value my co-workers opinions very much. I’m lucky enough to work with very smart people in various different areas. When I’m vetting a project there's a chance one of my co-workers has used it or looked into it themselves and can give me their opinion on why they did or didn’t use it. Again, I still form my own opinion based on my requirements, but it’s always important to understand how other people came to their decisions.
Tests and specs
Here at 8th Light we are very dedicated to TDD and we only write tested software. Since there is so much emphasis on testing at our company, when I see an open-source project without tests it inevitably makes me scrutinize the source code a lot more. Notice, however, that I don't discount the project altogether and move on to something else. While testing is very important to me, I still give code without specs a chance. However, I do give it a much more thorough review.
Licensing
There is a lot to be said about software licensing. I could make an entire blog post about software licensing. I'm not a lawyer and can't give you legal advice, however I can tell you what I look for when choosing open-source software. Make sure any open-source software you're using in a commercial project has a license. You may see a license description in the README, or there may be a LICENSE file in the repository. Just because code is available on Github doesn't mean you can use it on your project. You should be aware of the implications of using open-source software. Aaron Kalin gave a great talk at 8th Light University about software licensing, I highly recommend spending 30 minutes viewing his presentation. It will give you a good idea of what to look for as far as licensing in open-source software and what those licenses mean to you.
Community
The final aspect of evaluating open-source software is community. Community support and participation around an open-source project is crucial. No code is an island, and no matter how perfect a piece of code is, if no one is available to support it, it might as well not exist. Make sure the project you're evaluating will be around and supported or you'll find yourself reimplementing the code down the road.