Most organizations with in-house development teams maintain their own code bases. Their developers write most of the code for those codebases themselves. However, they may choose to add third-party open source code to their codebases, for several reasons.
The most obvious is that it’s often faster and easier to incorporate a feature or build an integration using third-party code than it is to write it yourself. Why spend a week building out a new service from scratch when you can grab the code you need from an open repo on GitHub? Why reinvent the wheel if someone already invented it for you and wants you to use it for free?
Incorporating open source can also be handy in situations where an in-house development team doesn’t have the expertise necessary to implement a certain feature or service itself. Maybe you need to add a new feature to a legacy application written in a language that no one knows well, for example, so you decide to pull the code you need from an open source project instead of teaching yourself the language.
Developers may also choose to work with open source code for reasons that could be described as political. Borrowing code from third-party open source projects can help build bridges with those projects. Contributing code back builds even stronger bridges. If a company wants to establish itself as a participant in the ecosystem surrounding a certain open source project, in other words, working with its code can be a way to do so.
The Drawbacks of Using Open Source Code
While the reasons for adding open source code to a company’s internal code base are sound, there are potential drawbacks to be aware of.
One is that, to quote engineer Steve Belovarich, “when you adopt open source tools you often don’t know what you are getting.”
In other words, when you use open source code, you may understand approximately what it does and how it fits within your codebase. But unless developers spend days poring over each line of the code – which is unlikely, because that would defeat the purpose of borrowing code in order to save time and effort – the team won’t fully understand exactly how the open source code works. That’s a risk, because it means the business becomes dependent on something that its developers don’t fully understand.
Reusing open source code may also lead to licensing problems. There are dozens of different open source licenses, all of which have their own rules on how open source can be incorporated into other codebases. Some licenses let developers do anything they want with open source code. Others require attribution of the original authors of the code. Some impose restrictions in situations where the code is used publicly, but not if companies only use it internally.
Because of this complexity, it’s easy to run into licensing issues by reusing open source code in a way that violates whichever license governs it. And while it can be easy to assume that the licenses won’t really be enforced, that’s not always the case. Businesses face a real risk if they borrow open source code willy-nilly without understanding the licensing terms, and without keeping track of where the code exists within their own codebases.
Likewise, security issues can be a concern when using open source code. Open source is no less inherently secure or insecure than proprietary code. But when developers use open source without fully understanding how the code works, and without knowing which vulnerabilities may be lurking within it, they risk introducing security problems into their codebases.
When and When Not to Use Open Source Code
Deciding whether or not to make use of open source code, then, boils down to assessing whether the benefits outweigh the risks – as well as your organization’s ability to control those risks.
If adding open source to your codebase will save a significant amount of time, effort, and money by significantly reducing the amount of original coding the development team has to perform, it’s probably worth it. It may be less so if it will only save developers from a day’s work.
Likewise, if you trust the source of the code and you’re confident that it is secure, it makes more sense to lean on it. It’s generally better to use open source code from a major project than it is to pull code from a random GitHub repository.
Most important of all is the level of visibility and control that developers have over the source code they use. Regardless of how much they trust the original authors of the code or how well written the code is, it’s impossible to have full confidence that it won’t introduce security, licensing, or other issues without performing your own vetting.
That’s where Software Composition Analysis (SCA) solutions come in. SCA tools let businesses find the open source code that exists within their databases – which is important because developers don’t always do a good job of keeping track of where they add open source – so that they can assess the code for licensing, security, and other risks. In this way, SCA gives development teams and the businesses they support the ability to take advantage of the benefits that open source code offers while mitigating the risks associated with it.