In the first blog of this series on navigating open source risk, I discussed how licensing can impact your ability to deliver software, as license changes require time from lawyers to help interpret these new licenses. This time, I’ll explain the risks that exist in the contributor community and among organizations.
Open source projects thrive when the contributor community thrives. An active project is like a sourdough starter: always bubbling and changing. When you see that activity, your trust level rises. Unfortunately, we often assume they’ll always be there and when they’re suddenly not, we start to understand how much we count on them. By overlooking the importance of contributors we also underestimate the risks introduced when they go dormant or exit a project. Many of us don’t spend as much time thinking about contributor risk as we should. For the open source projects that you rely on, what would happen if a key contributor won the lottery, retired on a beach, and never contributed again? Could the project continue uninterrupted? When I think about contributor risk, I always remember the xkcd comic showing all modern infrastructure built on top of a project maintained by a random person in Nebraska. Unfortunately, this scenario is probably more common than many people realize.
One of the biggest examples of this was a couple of years ago when it was discovered that OpenSSL had a security bug in their cryptography library, referred to as Heartbleed. OpenSSL is a technology that almost every company in the world uses in one way or another, and it was during this crisis that most of us learned that OpenSSL received about $2000 in donations per year and was maintained mostly by a single person. In other words, a piece of software that is widely used by almost every company in the world had almost no resources to maintain the software. This is only one example; there are probably hundreds or thousands of other open source projects in the same or similar situations. In this case, the Linux Foundation stepped in to provide funding for people to work on OpenSSL and other similar projects on a full-time basis. As covered in my prior post, projects under a neutral foundation will have a lower overall project risk.
While this situation was resolved relatively quickly, we might not be so lucky in other cases, so evaluating contributor risk is important because it can disrupt our businesses. Contributor risk looms large for complex projects or those that contain technologies that require specialized expertise, like with Heartbleed and OpenSSL. The risk is lower for less complex projects built with commonly used technologies that could be maintained by a greater number of people.
You should also look at organizational diversity as part of the health and risk for open source projects. If all or most of the contributions are from the employees at a single company, what happens when that company has a shift in strategy, or gets acquired, or runs out of money and goes out of business? Would the project be able to continue if the company pulled all of its employees out of the project? Again, it comes down to risk and whether you are willing to take that risk.
As I mentioned in my previous blog post in this series, most business decisions boil down to an assessment of risk and making tradeoffs. As a company, we all need to think about contributor and organizational risks in light of how we’re using these projects within our business. If we build products on top of an open source technology, we want it to be as low of a risk as possible. On the other hand, if we are using an open source project as a small part of some non-critical infrastructure, we can accept more risk. Risk, like most things, exists on a continuum. We need to think about the risks we might be taking and make informed decisions about which risks to accept. Deciding which risks we are going to accept is the beginning, not the end, of the process, since we should also be thinking about how we might want to monitor and mitigate those risks over time.
This is the second in a series about assessing the risks of open source software. Next, check out our blog post about responsive and healthy communities.
Thanks to Annie Spratt for providing this blog’s feature image.
