How Do I Evaluate Open-Source Technology?
Back in February I focused on 3 questions I ask myself when evaluating new technology for an organization. That article was especially relevant to me as I was recommending a new core piece of technology to a client. Since then, I’ve wanted to add as an addendum to that article some of the steps I go through while evaluating open-source technologies and libraries.
When I start to review open-source technology for clients, there are a series of questions I seek to answer beforerecommending it. Here are 5 questions I ask while evaluating open-source tech for an organization:
1. How long has this open-source software been available?
I like to start here. As I referenced last time, I don’t mind pushing the envelope, but I like to be strategic about it. I tend to choose open-source software that has been proven over time. For example, there is a reason why large swaths of the internet use Bootstrap as a CSS framework. One reason is it has been around for a while now, is pretty ubiquitous, and simple to use. The easiest place to find the age of an open-source library is not GitHub, however. You’ll have an easier time on a package manager site, such as NPM or NuGet, and looking at the version history dates there. Put another way, I don’t care how long software has been in development. I care more about how long it has been used by others.
2. How large and involved is the community around this software?
I like to see a large community actively progressing their software along before I recommend an open-source solution. There are two data points of particular interest: the number of contributors and how actively they commit. On a site like GitHub, this is easy to find. Click the Insights tab on any given repository and click the Contributors pill on the left side of the screen.
The green graph is an excellent visual representation of the project over time. The image above of MassTransit shows continuous development of the platform and two very strong contributors at the top of the list. A picture is worth a thousand words and this picture will help gain confidence in something you are about to start using.
1. What kind of defects are currently open against the software?
I have decided against recommending software based on this single criterion. Major defects left unresolved, security holes that weren’t patched immediately, a propensity to close defects without resolution, etc. all come into play. Reviewing this list before I begin working with an open-source library has saved me hours, and even days, of time. If you take nothing else from this article, take this one piece of advice with you. Between GitHub, Stack Overflow, and a basic web search, I have a good idea of what I am dealing with before I begin my work.
2. Are there good writeups and examples on how to get started?
I like to search the web for some good examples of how to integrate with the software. Were the writeups current? Were they correct? Are there multiple examples to choose from, or only one or two? Do they make sense or are the explanations lacking? While this is not a showstopper by itself, it can be a red flag in conjunction with some of the other questions here. This helps me gauge exactly what I’m up against and how to communicate the effort involved with any integration efforts that might ensue.
3. What kind of licensing does this software have?
When building software, I try to help my clients reach their goals. The best design and implementation decisions can lead to great production success. And while congratulations can be in order, it can all be undone with a lawsuit from an open-source developer. There’s no need to put anyone in this position. It’s worth the few minutes to verify the licensing of the software to be sure you are in compliance. Undoing or rewriting software under duress is never fun.
After I answer these questions, I generally have a clearer picture of what I’m working with and whether or not I want to proceed forward using an open-source library. This bit of assessment up front will save you and your client and/or company a lot of time. So, before you proceed with an arbitrary npm install next time, take a few minutes, dig a little bit into the path you want to take, and see if it will pan out the way you think it will. Most of the times it will. But it is worth it to avoid the times it won’t.