How To Evaluate Open Source Software

One of the best benefits to open source software is how it can fill in the gaps when developing applications. At times it makes sense to look around and see if anyone else has already solved the problem you are looking at, especially if it is a common feature. Unfortunately, not all open source projects are built the same, and deciding to adopt someone else’s code into your project must be carefully considered. Here are seven steps to starting a successful long-term relationship with an open source project.

License

The first thing to look at is the what license the code has been released under. If the license is incompatible with the intended final project, there’s really no need to look at the project further. Do you intend to release your final project as open source? If so, than the GPL or one of it’s relatives might be a good fit. GPL code is also generally acceptable in use in web applications, where you are not redistributing a final binary and the product is the service the application provides. However, if you are planning on selling your application, avoid the GPL like the plague. Friendlier licenses like BSD and Apache give the author leeway to build whatever they like, and distribute it however they like.

Activity

Second, take a look at the project’s public repository. When was the last time it was updated? Look at the commit history, how often is the project updated? Many times, a developer will have an idea, throw together a repository and release it to the world, and then drop it like a hot potato and walk away. Code moves fast, and if the project you are looking at has gone for a year or two without an update, it’s likely that the project has been abandoned. It is still possible that the code is fantastic, but if the project has been abandoned you really need to ask yourself if you are willing to take it over.

Age of project

The best software is iterated on over time, continually getting a little better, bit by bit. (or is that byte by byte?) If the project you are looking at is fairly young, say, less than a year or two, you may want to consider looking a little deeper into the projects intended audience and purpose. New code can be good, but personally, I don’t like the idea of beta testing anything in one of my projects going into production. It’s generally better to let someone else battle harden the code before you pick it up.

Unit tests

Unit tests are hard. If the author or authors of an open source project took the time to build unit tests into it, it’s a good bet that they intended the project to be used in production. The existence of unit tests is a good indicator of a serious project, however, the proof is in the pudding, as they say, so you will need to take a look at the unit tests, and see what they actually do. Looking at the code of the unit tests brings me to the next point:

Code quality

Start browsing through the code. How does it work? How is it written? Do you see any obvious rookie mistakes in the code? Any indicators that whoever wrote it didn’t really know what they were doing? It is tough to read someone else’s code, but if you are going to be adopting this project for the long haul, you are going to need to know what it does and how it works. If you don’t, you are going to run into issues, especially if you intend to use the code in a way slightly different from the original authors intent.

Basic use test

After perusing the code till you are comfortable with it, the next thing to do is to build a quick, throw-away project that uses nothing but the absolute minimum needed to test that the code actually does what it says it does. Does it compile in your environment? Are the right hooks in the right places? If the project is good, it will probably come with just such a sub-project that showcases its capabilities and describes how to integrate.

Modification test - Finishing up

I consider this an optional test, since bending the project to do something outside of what it was meant to do is probably more trouble than it’s worth. However, if you know that you are going to need to do some modification anyway, it may be worth your time to do it outside of your main project to see how the code behaves. Does it start to break in unexpected ways? Is it actually a little more brittle than expected? Or, does it bend and flex to accommodate use outside of the norm?

If you follow these guidelines, you can be confident in your choice of open source code to include in your main project. If you have additional ideas or other experiences, I’d love to hear about them in the comments.