Open Source Software (OSS) was first introduced back in the early 90’s, but was poorly received by enterprises who viewed it as far too risky to adopt. That mindset has shifted over time as more and more startups proved that OSS was the key to quickly bringing new, innovative software products to market. In other words, more and more organizations were seeing that the benefits of OSS outweigh the risks.
But the floodgates really opened following the US government’s adoption of an official OSS policy in 2015. Since then, the incorporation of OSS into software product codebases has exploded:
Source = Security Boulevard
It’s obvious that OSS is now an extremely valuable part of the software industry, but it’s a value that too many organizations take for granted. In an effort to help better understand the Return On Investment (ROI) of OSS, Harvard Business School (HBS) recently released a paper entitled “The Value of Open Source Software” which suggests that organizations worldwide are currently taking advantage of up to $8.8T worth of OSS. This number is based on a cost estimate of $4.15B to recreate the existing pool of key open source software across ecosystems x an estimate of worldwide usage of OSS by organizations.
Some key observations from the paper include:
- Up to 99.9% of a commercial software’s codebase can be OSS.
- Just six programming languages make up 84% of the value of OSS to organizations: Go, Java, JavaScript, Typescript, C/ C++, and Python.
- 96% of the value of OSS to organizations is created by just 5% of OSS developers.
If software is eating the world, then OSS is feeding it. This has ramifications for everyone from government policymakers to software vendors to industry leaders that create software for their own internal use.
But unlocking the value of OSS is not straightforward. The problem lies in the fact that most organizations take OSS for granted and consider it a free resource to be exploited rather than a significant cost of doing business. Consider:
- Most organizations approach OSS usage tactically (primarily as a way to accelerate development sprints) rather than strategically as a foundational component of their business.
- While large enterprises are generally aware of the security, legal, and compliance risks associated with OSS, most SMBs remain wilfully ignorant.
- Awareness of OSS continues to grow, but far too many organizations still take an ad hoc approach to managing and maintaining it, increasing risk over time as components become outdated and vulnerable.
What’s required is a structured approach to OSS that begins with governance. Simply put, governance encompasses the policies and processes an organization puts in place to manage and control the use of OSS. But effective governance can be difficult to craft, leading to issues with awareness, adoption and abuse because stakeholders just end up routing around it.
Effective Open Source Software Governance
The $8.8T valuation HBS assigns to OSS is a staggering number and may actually be an underestimate since it doesn’t include operating systems. But more importantly, the majority of that value comes from just 5% of all OSS developers, with whom you probably don’t have a relationship. As a result, there are a number of risks associated with OSS (outlined below) that should be of concern to multiple stakeholders in your organization, including IT, security, legal, compliance, and more.
To reduce that risk, you’ll need to put in place rules and regulations, aka governance. There are multiple ways to initiate governance, one of which is setting up an OSS Center of Excellence (CoE) or Open Source Program Office that can define what can be used by which teams in what ways. That means assembling a cross-functional team, which can be such an expensive undertaking that it becomes a key impediment to governance adoption. That is, unless it can be shown to deliver significant ROI.
Measuring the business value of an OSS CoE has traditionally been difficult, but can now be quantified based on the Harvard Business School paper. For example, organizations use OSS for free, but if it didn’t exist, they’d have to write it themselves. The paper estimates the cost of rewriting all widely used OSS would cost from $1.22B to $6.22B. If that code is reused within the organization, the actual value can be as much as 3.5 times the cost.
While it’s unlikely that any organization would rewrite all the OSS covered in the report from scratch, it does provide you with a way of thinking about the value a CoE can deliver when executives ask about the ROI they can expect in return for investing in such a program.
Once you’ve got executive buy-in and assembled the stakeholders you can get started on governance. Some general guidelines apply:
- Consider taking a strategic approach to unifying OSS use, which likely varies across the enterprise.
- Keep in mind all aspects of OSS use, including application security, open source licensing, regulatory compliance, and IT agility.
- Plan to create training to educate all stakeholders on the OSS processes, rules, and policies you come up with.
- Get started as soon as possible fostering awareness of the strategic importance of open source from senior executives to junior developers.
The first step when it comes to creating OSS governance is to assess the appetite for risk that your organization is willing to accept. Risk is inherent in multiple aspects of OSS use, including:
- Licensing – while there remain a number of popular OSS license categories (e.g., permissive licenses like MIT; restrictive copyleft licenses like GPL, etc.) the number of actual licenses is proliferating, some of which are unique to the specific OSS or organization that created it.
- Legal teams will need to review the licenses of OSS already in use, as well as other common OSS licenses, in order to determine which ones fit within their risk tolerance.
- Compliance – regulated industries must ensure that the OSS in use within the organization meets existing legal requirements.
- Compliance teams will need to encapsulate regulatory requirements (e.g., PCI-DSS, HIPAA, SOX, GDPR, etc.) within the rules for OSS use, along with criteria that define acceptable implementations.
- Security – exposure to security vulnerabilities are an inevitable part of OSS use.
- Security teams will need to define the severity level of a vulnerability that is acceptable, as well as SLAs for remediating those vulnerabilities that exceed the threshold, and whether developers are able to create internal patches, etc.
- Maintainability – some OSS may not be fit for use based on a number of factors, including author reputation, frequency of updates, End Of Life status, etc.
- R&D will need to define the limits of their tech stack, including such factors as the oldest acceptable version of a language, when a component is to be considered outdated, etc.
- Support – most OSS lacks commercial support.
- IT will need to decide what kinds of OSS (products, frameworks, libraries, etc.) they are comfortable supporting themselves versus those that will require third-party commercial support.
Once the risk for each area has been assessed and the rules established to minimize that risk, the governance policy can be articulated. Before disseminating the policy, make sure to document:
- Questions – how will questions about the policy be handled? Is the board responsible as a whole, or can individual team members deal with specific questions in their area of expertise? Regular policy update windows should be scheduled, whether or not an update is actually needed.
- Exceptions – how will exceptions to the rules be handled? Take care to create an exception process that is detailed enough to document the risk being accepted, but not overly onerous, which will only result in stakeholders routing around the process and introducing unknown risks.
- Goals & Measurement – how will you know whether the governance you’ve put in place is successful? Define the goals for your policy, how you will measure success, and the frequency with which you’ll review performance.
Following the guidelines listed above will set you on the right path to OSS governance. Ongoing success requires you to educate, promulgate, and enforce it.
Conclusions: OSS Governance Enforcement
The trick to good governance is to make compliance as easy as possible to adopt and enforce. After all, it does no good to have a policy if there’s no way to check that stakeholders are complying with it, and the best way to ensure compliance is through automated enforcement.
Partnering with an open source veteran like ActiveState is one way to go. Not only can we provide you with the expertise to draft your governance policy in a robust and adaptable manner (because things will change), but we can also help automate and enforce the rules and processes you require via our ActiveState Platform.
The ActiveState Platform provides your teams with access to securely built OSS, while making it easy for all your stakeholders to collaborate on key requirements around licensing, security, and maintainability. And our commercial support terms make it easy to adopt OSS safely and securely.
Next Steps:
For more information on managing the risk of OSS use, watch our webinar on Achieving the Impossible: 3 Steps to Minimize Risk & Reap the Benefits of Secured Open Source
