Do You Really Want to Depend on That Open Source Project?
How should an engineer go about deciding whether or not to depend on an open-source project?
I’m not talking about personal or experimental projects, but rather the kinds of situations you run into when working for a product or IT organization. When selecting open source for corporate use, the first thing you must consider is whatever legal and compliance processes exist in your organization.
If you don’t know if your organization has processes in place around the use of open source software, stop reading now and go find out.
And if the answer is that no such processes exist, stop reading now and talk to your CTO/CIO/Legal and get some in place.
You don’t want to use (or really, even download) any open source software until your organization has evaluated and documented the risks and established some guardrails. At a minimum, these are going to involve what OSS licenses are “approved for use” and which are off-limits. Many pixels have been spilled over the differences and issues around OSS licenses by people much more expert than me. So from here on out, I’m going to assume that whatever open source project you are considering not only meets your basic product requirements but also meets the compliance and governance rules set forth by your employer. That said,
Just because you can use an open source project doesn’t necessarily mean you should.
After all, one of the worst things that can happen to your project is to run into a bug in an open source dependency, only to find out that the maintainers have vanished and the community is not willing to help you out. (Let’s face it, yes, you have the code, but the idea that you can always “just fix it yourself” in any non-trivial code base simply isn’t realistic.)
Let’s talk about a few more things you might want to look at before making a final decision to depend on an open source project.
Popularity
If you grew up in America, you’ve probably internalized the notion from childhood that you’re not supposed to pay attention to popularity. But when it comes to whether or not to use an open source project, here’s a case where popularity actually matters.
An orphaned or even just a casually-maintained open source project may not get new features and critical security patches, or if it does, it may not meet your timetable. Due to the motivations of most open source developers, a popular and widely used project is much less likely to fall into disrepair. And if it does, there's a much larger community interested in taking it over.
One way to get some idea of a project’s popularity is to check the download trend on repository sites like npm.org. Or simply check the number of GitHub stars (they're not just a vanity metric) and forks.
Pull Requests
Read through the open and recently closed pull requests. You can get some idea of the current state of development and how rapidly changes and patches get applied. If there are a lot of pull requests sitting for a long time with no action, that's not a great sign for project health.
Issues
Also make sure to read the issue list, paying special attention to any bugs in features important to your use cases. Check the closed issues as well. A lot of unfixed bugs or really old bugs should give you pause, not only in relation to the quality of the open-source product but also its long-term viability.
Security Scan
Your organization's open source usage policies may have already required this, but if not, clone the repository and run some static security analyzers on the code. If you're lucky, you have access to high-end commercial scanners. But even if not, depending on the programming language there are a number of free security linters that can find many critical issues.
Documentation and Community
If you're deeply engaged in using an open source library, at some point you're going to get stuck and need help. Don't let that be the first time you check out the project documentation. It's probably right there in the repository in one or more Markdown files. Make sure it's detailed and usable.
While you’re there, look for a project roadmap, which can give you some idea of the kinds of enhancements you can expect. Besides new features that you like, you may also discover that the project will evolve in a direction that won’t meet your needs.
Also look for a large and supportive user community. They might gravitate toward doing Q&A on developer forums like StackOverflow. Or there might be a channel on Slack or Discord.
Prototype
Say you've done all of the above. Finally, grab the code or a binary and write a prototype to make sure the open source fits into your code base and architecture. Don't forget to do some performance benchmarks.
Conclusion
Beyond legal, compliance, and governance, there’s a list of some things for engineering decision makers to think about when selecting (or not selecting) an open source project. What else did I forget to mention? Reach out and let me know!
