When considering whether to use open source software for a project, it pays to do a little investigation into the project to help you decide whether the project is the best option or if you should continue to look elsewhere. In evaluating a couple of projects recently, it was clear to me that I tend to think about a number of things when looking at a project, but hadn’t taken the time to think about it in detail. On a high level, I tend to think about a number of different issues as I look at a project.
Project activity
Does the project have recent commits, or has it not been touched in years? If the project has lots of recent activity, that may mean undergoing considerable change and maybe be unstable. If that’s the case, it pays to look for a release schedule and see whether you can find a stable version to work with, or if living with some uncertainty is fine. If there’s been no activity in years, this can be a sign of an abandoned project. Never use this metric in isolation though, stable software in wide use may not change often, so you should look deeper.
Open Issues
How many are there? Do the issues receive attention and responses from the developers. Are there duplicates for the same issue? If a project doesn’t even use an issue tracker, you will need to understand how the developers are made aware of bugs or enhancement requests. If there are many similar issues or unresolved issues with many “me too” comments and no response from developers, this often means the project is either abandoned or the developers have been overwhelmed. The fact that the project is getting lots of attention is a good sign, but if most users are frustrated, you will probably be as well.
Documentation
Is there any documentation, and what is the quality? Some projects only need a basic README and you’ll be off and running, but if the project is a bit more complex you’ll want to be able to get an overview without having to read all the code. If you want to get involved with an open source project, helping write documentation is usually a great way to help out the project, and you’ll learn the software.
Getting Started
How hard is it to install the software and verify your use case? For some software packages, you can expect this to be fairly involved, but at least a simple smoke test should work easily. This is usually where you’ll discover whether a project will even be compatible with your environment due to version mismatches, prerequisites, resource usage, efficiency, or other metrics. Make sure you consider how you’ll use the software. If it runs in a test sandbox great, but you need to deploy it with your own software packages, you’ll want to at least verify you can do that.
Ecosystem
If the package is meant to work with other packages or systems are there multiple options available, or is it highly coupled to another project or system that you may not want to be tied to in the future? If you choose this project, will you be locked into a specific OS, programming language, language version, backend integration, programming style, deployment option, cloud vendor, or any other situation that you may want to avoid. Consider whether this is likely to be an issue for you in the future.
Code quality
If you have to fix things yourself or dig into code immediately to overcome missing documentation or troubleshoot an error message, you’ll probably end up reading and modifying code. Read through it and get a feel for the quality. Are the comments helpful? Is test coverage decent, and do the tests help you understand the functionality? What is the effort to setup a development environment if you need to make a change?
Project structure
What are the steps to contribute, and will you be able to have an impact on the project? Of course, one of the biggest benefits of open source is that you can contribute to project in multiple ways. This could include creating issues for new bugs you find, providing bug fixes and enhancements in pull requests, improving documentation, or just helping spread the word about the project. See if you can tell if the development team is receptive to contributions and feedback and doing a good job of fostering community. You may want to see if the project has a code of conduct.
Corporate backing
For larger projects, corporations may be backing the development of the software as opposed to smaller independent projects where the developer is scratching their own itch. In the cases of corporate development, you may want to consider the motivations for using open source. If the project is only really useful in their paid or licensed version, you have to consider whether you’ll just be better off buying the licensed software or looking at closed source competitors. Another option is building your own version of the features they charge for. If your use case is simple enough, this may be a great solution.
License
I’m no expert in licensing, but if you’re picking open source software for use in a commercial product or for your company, make sure you talk to your lawyer if you don’t think you can abide by the licensing terms.
I’m sure there are other things to consider, let me know if I missed anything important when evaluating open source software.