Whether a software architect makes the decision as part of an app’s planning phase, or it’s simply dragged in by a developer trying to complete a task, the accessibility and availability of open source makes it easy to just download and build into an application without thinking more about where it comes from.
But why even care about where it comes from?
Any organization that pays the smallest attention to open source management has methods and tools in place to identify and mitigate the risks that come along with it – risks relating to security vulnerabilities, license obligations, and operational concerns. So, if dev teams can keep at bay the risks related to not knowing where the open source software comes from, why does it matter to know more than that?
There are some risks that developers simply cannot quantify, risks that don’t get reported in vulnerability feeds or underlined by lawyers. But they’re risks that can still cripple an application and pose big issues to those that depend on the applications. To better understand this risk, take a closer look at the open source the team depends on, how it’s developed, and who’s doing the development work. It's crucial to understanding the stability and viability of open source projects that may serve as the foundation of the applications that run the business. In turn, understanding this can help guide efforts in avoiding the type of risk this introduces.
There’s a very widely held belief that every open source project gets propped up by thousands or millions of developers pitching in to develop and improve it regularly. While it’s often true for some popular projects, like Kubernetes, it’s most frequently not the case.
The Linux Foundation’s FOSS Census II found that, of the top 50 non-npm projects, 23% had one developer accounting for more than 80% of the lines of code in the project. Additionally, 94% of the projects analyzed had fewer than 10 developers responsible for 90% of the lines of code. The bottom line: only a handful of developers maintain almost all of the most widely used open source. That certainly leads to a concerning “hit by a bus” factor.
A developer doesn’t have to get hit by a bus to make this an issue though. Developers can abandon projects for any variety of reasons. They can lose interest, move on to other projects, get tied up with other work-personal obligations, or they can simply burnout. They can grow tired of contributing their best efforts to thankless work—work that gets leveraged by big companies that make lots of money off their hard work.
When companies choose an open source project to build proprietary software on top of an open source project maintained by one or two developers and one or both of those developers decides to stop contributing, the applications and the business suffers.
Now, this isn’t a huge issue with every single open source project. If the user interface project used for an eCommerce platform fizzles out, most developers go and replace it with another one. But this may not always be the case. The Census II found that a considerable number of projects (millions) that serve as foundational elements of modern applications are developed by a small group of contributors. What would the organization do if the operating system, back-end server, and logging framework lost developer support?
Put aside the operational risk of running applications with unmaintained and outdated code, what about the security risks? Companies depend on these projects to identify vulnerabilities and issue patches or newer versions that fix those security issues. If there’s a burned-out or absentee contributor, there’s nobody to find, fix, and responsibly disclose vulnerabilities. However, attackers will find vulnerabilities, and the team will have to work on exploits instead of patches or disclosure efforts.
Organizations do have the opportunity to contribute to preventing open source developer fatigue. Here are some ways that organizations do this today:
- If the organization depends heavily on a particular project, encourage and allow the developers to contribute. This remains a reason why the Kubernetes project stays so strong and has so many contributors.
- Fund initiatives and pay developers, both inside and outside of the organization for their time spent contributing to open source projects. The Linux Foundation’s Community Bridge33 or GitHub’s Bug Bounty34 and Sponsors35 programs, match open source projects and developers with funding from private companies that rely upon them. Also, in August of 2021, Google pledged $10 billion over the next five years to strengthen cybersecurity, with $100 million to support third-party foundations, such as OpenSSF to help fix free and open source software security vulnerabilities.
- Pay developers to maintain the projects the company relies on as part of their on-the-clock job.
- Hire the contributors of the company’s foundation dependencies and let them work on those projects in their free time.
It’s important for the industry to understand that open source development burnout is real and can have a significant impact upon those who depend on the projects they maintain. Incentivize and recognize efforts. Don’t just take, but give back to the community.
Mike McGuire, senior solutions manager, Synopsys Software Integrity Group
