Open source is the dominant trend in enterprise software development today, as the technical features, community support, and cost advantages appeal to many organizations. Despite its prevalence, most enterprise teams aren’t fully aware about all that open source entails, even as they search for and include it in their builds. Many assume the technical, licensing, and distribution constraints are equivalent to commercial software, when the reality is anything but.
Before selecting and using an open source package, consider these five things:
1. Technical issues
The risk most familiar to developers is that of an open source package not performing as expected, whether it’s in set up, integration, or deployment. Usually, this results in time and money spent on researching and fixing the problem, as teams don’t have deep in-house expertise supporting all the packages in use. And more often than not, critical production issues are the result of interactions between packages and the environment, not a single root cause.
Does your team have the skills and experience necessary to prevent and fix issues in your product or production stack?
2. Code security
Open source is created to fill gaps in technology but there are instances of packages not undergoing security design or testing at all. If the package isn’t tested with vulnerabilities and threat vectors in mind, a product has the potential to be compromised.
Is your team aware of all package vulnerabilities and does it have a way to stay on top of the latest updates and patches?
Most open source licenses require some form of acknowledgment when code is reused in other projects and they all include a clause that specifies how software is to be reproduced and distributed within a product. This may include conditions on access to the source code, providing copies of the license, trademark use, or a variety of other conditions.
Is your team aware of and compliant to all the open source licenses in your product or production stack?
If the open source code is changed in any way, most licenses include requirements on how the modifications are tracked and notices given.
Is your team aware of and compliant to all the modification requirements specified by the open source licenses in your product or production stack?
Some open source projects are managed by different licenses and some of these can conflict with each other (for example, the GNU General Public License is incompatible with several free software licenses), making it difficult to determine obligations. Projects with nested licenses make the analysis even trickier.
Is your team aware of any licensing conflicts?
A simple way to manage open source risks
There is one simple process to manage these risks effectively: take open source seriously. This means establishing an inventory of all open source packages and versions (including those “unknown” ones included by developers – these can be found with scanning tools), performing regular audits to understand licensing and compliance gaps, and obtaining expert-level technical support for all packages. Building these up internally can be challenging and cost-prohibitive, so consider outside tools and services to help design and implement open source management practices that protect the organization.