At Atomic, we often create a lot of value for our customers by combining our high-quality custom software with open-source, third-party software libraries. This saves money that would otherwise need to be spent reimplementing core functionality, and it provides the quality that comes with the feedback loop only widely-used software can generate.
But selecting these libraries is not a task to be taken lightly. Just as the right library can offer a lot of value, the wrong library can create a lot of pain. To make sure your decision will benefit your project, ask yourself a set of questions.
Do You Even Need a Library?
It goes without saying, perhaps, but you don’t always need to bring in a library. Often, the platform you’re developing on has a built-in, high-quality method that can help you achieve your goals. It may be simpler, more cost-effective, and more future-proof to build abstractions or simple logic around those built-in APIs to achieve the results you want.
But beware of going too far in this direction. Sometimes problems can look simple on the surface but have an amazing number of edge cases you’ve never heard of—though the library authors have. If you’re dealing with data formats, for example, you’ll want to look harder for a good implementation to avoid an over-simplified approach.
Are You Licensed to Use It?
Once you’ve decided you need a third-party library, the very first thing you should do is make sure you’re licensed to use the one you’re considering. Just because someone posted code on GitHub doesn’t mean you have the rights to do anything but read it. The author must explicitly license the code in a way that is compatible with your project. Look for a ‘LICENSE’ file in the code you’re about to import, read the code headers, get it in writing from the author—but, above all, make sure you have a license.
The specific license used matters, too. Most of the time, code with a permissive license such as the MIT license will work for your project. But it’s still very important to completely read the license and weigh it against how your project will be used and distributed. If you don’t, you could be setting your project up for serious pain down the line.
Is the Project Well-Maintained?
Look for signs that the library is well-maintained. This doesn’t necessarily mean that there are very frequent updates—at times, a lot of updates could actually be a sign of trouble, as the library may be moving faster than your project can keep up with. In fact, a well-maintained project may *also* be mature and rarely need updates anymore.
What you want to see is a project that makes releases when it needs to, takes into account API stability (avoiding unnecessary breakage of code, like yours, that depends on it), values code quality, tests its code well, and carefully considers new features and broad appeal instead of piling everything everyone could possibly want into the codebase.
Making these judgments takes time, but a steady hand on the tiller pays dividends when it comes to library maintenance.
What Is the Community Like?
The core development team is important to an open-source project, but they are definitely not the only important people. It’s a good idea to look closely at the community around the library you’re considering.
Is the community engaged? Are there people who are clearly using the software, diving in to help support each other and diagnose issues? Are people contributing patches? Volunteering to test new releases? Are they friendly and helpful toward newcomers, encouraging them to work toward solutions and pointing them toward resources they can use? Do people give presentations on the software?
All of these are signs that the community is healthy, providing a solid support network for the library to live on and maintain its quality.
Can You Contribute?
If you’ve gotten this far and the library is looking good, consider asking yourself one more question: can you participate in the project?
Even with the best libraries, you’ll find yourself in trouble from time to time because of your own confusion, bugs, or the need to work outside the box—and other users of the library will find themselves there, too. Open source works best when everyone contributes in whatever way they can: helping to build the community, providing patches, or writing documentation.
That may be difficult or impossible due to the nature of your work, but you should be prepared to discuss the value of contribution with the people who can help you do so. Explain the value of everyone contributing, and how the contributions of others have already helped create value for your work.
When all of these questions have been answered to your satisfaction, you’ll be well on your way to making an informed decision on choosing an open-source library for your project.