Developers and users, both new to the world of open source and those with more experience are prone to making a range of missteps, from cultural faux pas that impact one's relationship with or status in a project community, to technical slip-ups that reduce the utility and security of project code, to legal/licensing mistakes that can restrict your ability to deploy project code or on rare occasions, land you in court (as with any type of code, not just open source).
Let's examine these various types of missteps, the consequences of each, and your options to remediate.
Cultural Faux Pas
Open source is first and foremost a collaborative methodology for building and maintaining software. It is also regarded as a corpus of code available for use and redeployment. But accompanying these two concepts is unique culture with cultural norms for acceptable behavior.
Failure to Engage: Underestimating the Need for Community Engagement and failing to foster or manage community communication and contributions can limit the potential benefits of open source collaboration.
Cart before the Horse: Just "showing up" does not make you a trusted participant, no matter who your employer or role might be. Community engagement is a step-wise process. New participants start by lurking (reading mailings and forums). Next followed by making bug reports, feature requests and documentation additions. Maintainers are more likely to accept patches and code changes from community members who have already shown strong interest and competence.
Just Submitting Code: While project maintainers appreciate all types of participation, submitting code out of the blue does little to establish a would-be contributor's reputation or trustworthiness.
Letting Internal KPIs Intrude: Organizations that enjoy regular and significant participation in one or more open source projects can sometime try to "game" participation to take credit for the most code submitted, patches accepted, bugs resolved. Such behavior mostly just annoys maintainers but has also led to restrictions on contribution or even banishment from project communities.
Not Providing Attribution: In today's engineering marketplace, code can stand out as a developer's resume. While some developers are paid by their employers to make contributions to a project, a large swatch of open source community activity occurs on a volunteer basis. Failing to acknowledge contributions from sources beyond core maintainers does a great disservice to the yeomen's efforts that comprise and sustain open source.
Technical Issues
Technical slip-ups fall into several sub-categories:
Security Slip-ups
Assuming Open Source Is Secure by Default: Many organizations mistakenly believe open source software (OSS) is inherently secure. While the open source development and distribution paradigm offers more openness and opportunities for vetting and oversight, vulnerabilities in project code are nonetheless common and require management.
Not Monitoring for Updates: Failing to keep OSS up to date leaves organizations exposed to known vulnerabilities, as patches and updates are released frequently by the community.
Not Auditing for Vulnerabilities: Regular security audits are often neglected, leaving potential gaps that bad actors can exploit, if the code containing them is "outward-facing".
Using Moribund Projects: Relying on “abandonware” - projects no longer maintained or with shrinking maintainer communities - introduces significant risk due to infrequency and/or lack of updates and patches.
Lack of Security Ownership: Within an organization, open source code should not be an orphan. Not assigning a dedicated security resource to oversee use and integration of an open source project can result in unmanaged risks and uncoordinated responses to incidents.
Operational Missteps
Neglecting Thorough Testing: Organizations sometimes skip comprehensive testing of OSS integrations, assuming the components will work as intended, which can lead to functional and security issues.
Perfect is the Enemy of Good Enough: Delaying releases to perfect infrastructure or the first version of a project can stall innovation and reduce the benefits of the iterative open source development model.
Forking and Hoarding: A fork is defined as a copy of an existing project, that over time can seriously diverge from the upstream project. Every time an organization acquires a version of an open source project, it has potential to become a fork if the organization does not (1) accompany the main project by integrating patches and updates, and (2) does not share its own modifications upstream.
Inverse Technical Debt: Technical debt refers to additional effort arising from "quick and dirty" implementation vs. a more robust and maintainable approach. Often, when organization adopt open source as a short-cut to achieve greater functionality, they neglect to spend needed time and resources to vet, update and QA both that code, leading to an accumulation of technical debt. But the reverse can also be the case: some orgs expend great effort in repeatedly forking and recoding open source code to meet internal standards and practices, even exceeding the cost to implement the same functionality from scratch. The cost of such efforts is exacerbated by the need to re-apply patches, coding style, and other changes with every release of the open source project - a doomed exercise in an industry whose model is "Release Early, Release Often."
Winging It with Open Source: Not having clearly stated policies and processes for managing open source code leads to increasingly unpredictable life-cycle costs for software stacks with significant open source content.
Legal and Governance Missteps
The legal and governance implications of missteps with open source are perhaps the most daunting, both the corporate management and to legal staff. However, most organizations and lawyers involved in overseeing software engineering made the peace with open source software a decade ago.
Missteps involving legal and licensing issues include
Not Respecting Licensing Terms: misinterpreting or outright ignoring the specific of the licenses that govern open source project code is perhaps the most frequent misstep and one that lies behind the majority of litigation (which is actually minuscule compared to legal actions around proprietary software). Examples of such license violations include
Failure to disclose new code and changes to existing code
Not providing copies of or pointers to governing licenses
Creating derived works of open source code but treating them as proprietary / closed source while not being the copyright holder of record
Not providing full manifests and licensing information to "downstream" recipients, e.g., your customers and ecosystem partners.
Applying the Wrong License: Open Source projects can include hundreds of source files, subsystems and modules, and an even greater number of dependencies upon modules and API from other projects. While a "well-formed" project repository usually contains a LICENSE file, citing or reproducing the license that accompanies that project, other licenses can and do appear in source trees to govern subsets of project code. Ditto for dependencies. Assuming that the top-level "project license" applies to all code in a project or referenced by it (dependencies), leading to complex licensing landscapes of individual projects and project interoperability.
Mixing Incompatible Licenses: The Open Source Initiative (OSI) today recognizes about 60 different free and open source (FOSS) licenses. Those most frequently encountered "in the wild" include the MIT License, Apache 2.0, BSD Licenses (2 and 3 clause), the GNU General Public Licenses (GPL v2, v3 and LGPL) and the Mozilla Public License. There are also several thousand self-styled "free and open source" licenses (e.g., the "Free Beer License"). The terms of these licenses are not necessarily compatible, and some present challenges to combining FOSS with proprietary code. Admixture of code licensed under incompatible terms can create a "chimera", generally agreed to be unsuitable for redistribution, but OK for internal use. The author recommends that your organization utilize Software Composition Analysis (SCA) tools to catalog a complete bill of materials and to receive recommendations for remediation.
Leaking Proprietary IP: Developers may accidentally integrate proprietary code or sensitive data into public repositories when contributing back to open source, risking data leaks or intellectual property loss
General Prohibition against Open Source: while today such a prohibition might seem absurd, it wasn't that long ago that many tech companies and IT organizations, under advice from legal counsel, chose to avoid open source entirely. Today it is practically impossible to avoid touching upon, integrating and using open source software in infrastructure, applications and devices, leading to at least tacit acceptance if not universal heartfelt embrace of community-developed and licensed software.
How These Missteps Apply to Test Automation
Test Automation is susceptible to most of the missteps described earlier in this blog.
Mixed Use Cases: Most uses of open source in test automation are internal, that is, open source software is most often downloaded and integrated in a single, local organization, thereby not invoking the terms of most licenses since no redistribution takes place. However, supply of commercial solutions containing open source, e.g., Keysight PathWave Test Automation products that are built upon OpenTAP, are built by one company and distributed / sold to another (Keysight customers). For this and other reasons, Keysight chose the Mozilla Public License for OpenTAP.
Similarly, .NET middleware, published under the MIT License, and other open source components, impose minimal compliance burdens on the parties involved,
Ecosystem and Supply Chain Ripples