Open source is everywhere. It is highly visible, easy to acquire, use and deploy. The facility of acquisition and use can give open source, collectively, the appearance of a tech candy store, tempting developers and end-users to take fists full of open source code, sometimes without regard for the implications for intellectual property, security and general overhead.
Open source (including Free Software may indeed be free to acquire, use and deploy, but that usage is accompanied by a set of risks, some of which are shared with traditional proprietary software, while some are not.
Risks from Open Source
Risks accompany open source software across two primary activities, deploying and redistribution, and include
IP exposure from disclosure requirements
Vulnerabilities in open source code
Risks from non-compliance to the terms of open source licenses
Version proliferation through integration of multiple instances of the same open source code
Fortunately, these risks are all extremely manageable, through common sense management of open source within your organization.
Managing Open Source
To address the risks laid out above, as well as other risks, it's key to manage open source at your organization, intentionally, preemptively and thoughtfully. Too often organizations try to address issues retroactively.
Open source management falls into eight areas of focus, built upon and harmonized with an underlying open source strategy:
Strategy - What are your business and technical objectives for the use of OSS in general and in managing open source in particular? Does open source represent a strategic methodology and portfolio of available code or just a convenience?
Discovery - How do your developers find the best Open Source Software? Does your staff make use of available tools? Follow news and blogs? Confer with outside colleagues?
Review and Selection - How does your organization evaluate and approve the use of OSS? Do you have actual processes for the evaluation? What criteria do you apply? Do you maintain a catalog of pre-approved open source software components?
Procurement - How does your procurement organization manage the risks associated with OSS incorporated in commercial deliverables? Do you obtain open source software components from commercial vendors? What sort of ingress and integration processes do you employ?
Code Management, Maintenance and Support - How do you track and maintain open source components in your code base? Do you have processes for keeping those components up-to-date (especially for security updates)? How do you obtain support for that software?
Community Interaction - How does your organization participate in open source communities? Are you contributing to those projects (not code so much as bug reports and feature requests)? If the technology is crucial to your organization, do you have a plan to contribute code or even assume leadership in the project? Have you assigned "code owners" for at least key open source projects?
Compliance - How does your organization ensure compliance with the licenses of OSS it uses? Has your legal team reviewed the licenses associated with those software components?
Executive Oversight- How do your company's executives participate in the management of open source software to provide appropriate oversight? What is in the level of involvement by line-of-business management, engineering management, C-level and corporate counsel? Are executives involved "hands-on" or only through the reporting chain?
This list of open source management imperatives is not intended to be daunting nor to discourage readers from using and deployment open source software. At this point in tech history, it would be both impossible and frankly, unwise to walk away from or prohibit integration and deployment of open source - it is so ubiquitous that developers and engineering managers take its existence and utility for granted.
Implications for Test Automation
Test and measurement is a very "safe" place to use and deploy open source:
Most use cases are inward-facing, in labs, on test benches and on production lines
The internal use cases thereby present fairly low security risks
Code in these use cases is seldom redistributed, limiting or eliminating compliance requirements
But common T&M use cases also require more rigorous management:
Sharing of test platforms across partner and customer ecosystems, e.g, plugins and drivers
Building instruments and test platform with open source
Offering remote user interfaces as web and cloud applications built on open source
What about OpenTAP?
OpenTAP itself represents a very low-risk body of code:
It is seldom directly facing end-users and the rest of the internet, limiting the risk and gravity of vulnerabilities
Its relatively modest size (152 KLoC) makes it easier to manage
Written in C#, its most significant dependency is upon Microsoft .NET, a popular, well documented and OSS-friendly framework
Compliance with the OpenTAP Mozilla Public License is very straightforward with minimal associated obligations
However, the universe of OpenTAP ecosystem plugins has a different risk profile. We'll explore the risks inherent in any ecosystem in another blog.