Open Source software increasingly dominates application stacks across industries. Enterprise software builds on Linux, Jenkins, Kubernetes and other platforms and middleware; device software looks to Android, Linux, GNU, and myriad other platforms and tools, as well as open source code used to test those devices.
Despite the popularity and ubiquity of open source, many organizations still retain misgivings about using it. This blog examines those misgivings, debunking some concerns, and examining the truth behind others. Whenever possible, the topics are related to open source in Test Automation
Open Source is inherently less secure than proprietary code
FALSE
Open source software (OSS) simultaneously enjoys a superb reputation as a source for cybersecurity tooling and less-than-stellar (if undeserved) repute for suffering from vulnerabilities that facilitate data breaches and other attacks. Given that OpenTAP is an active open source project, supported by an array of open source plugins, members of the OpenTAP ecosystem often puzzle over the security of this test automation platform and of OSS in general.
The security of open source software begins with a counterintuitive presumption, that the more open and visible software is, the more secure it is likely to be. Here, Eric Raymond’s oft quoted Linus’s Law applies, states that “given enough eyeballs, all bugs are shallow”. The same logic, in general, applies to detecting vulnerabilities. One reason some people believe open source software is less secure is that all detected vulnerabilities are disclosed to their communities, where proprietary software bugs are often kept quietly until the next release. This, of course, does not really improve the security of such proprietary software.
How Secure is OpenTAP?
OpenTAP is an open source project with dependencies on multiple other projects, and so is subject to the vagaries of vulnerabilities in OSS code (especially in .NET). Like the rest of OSS, OpenTAP enjoys the oversight of overlapping communities:
Dedicated maintainers at Keysight and other OpenTAP ecosystem participants
End-users, integrators and other contributors
Product development teams at Keysight, who build hundreds of PathWave products on the OpenTAP platform
OpenTAP is first and foremost a test automation platform, deployed in the lab and on the test bench, across the end-product lifecycle.
You can learn more about open source cybersecurity and OpenTAP from another blog on this site: OpenTAP and Open Source Cybersecurity.
Open source has no documentation
FALSE
While open source traditionalists claim that "the code is the documentation", open source software enjoys a range of documentation, usually on a per project basis:
project wikis
online man pages
build-in command-line descriptions
support forums and discussion platforms, e.g., Stack Overflow and the OpenTAP Forum
for broadly-used projects (Linux, Android, Kubernetes, etc.) bound books
numerous tutorials and online classes
And, unlike proprietary software, open source by definition is accompanied by source code, the most definitive type of documentation (but it's not for everyone).
To learn more about OpenTAP documentation, see OpenTAP Documentation.
Open source software is "public domain"
FALSE
The term public domain is often misapplied to open source software. Public domain has a very specific meaning, at least in the American legal system:
The public domain consists of all the creative work to which no exclusive intellectual property rights apply. Those rights may have expired, been forfeited, expressly waived, or may be inapplicable
By contrast, free and open source software is by definition subject to an open source license, made enforceable with a copyright claimed by a person or organization. True public domain software does exist, but it is rare and seldom very useful. True open source software must also follow the Open Source Definition from the Open Source Initiative.
Open Source costs more than commercial/proprietary software
IT DEPENDS
The cost of open source, as for all types of software, is quantified as Total Cost of Ownership (TCO). TCO can include a range of expenses:
Cost to acquire or to develop the software
Organizations have been acquiring commercial/proprietary software for many decades with a perpetual license, that is, one that grants them usage rights for an unlimited period of time, usually with time-based support, contracted on an annual basis at additional cost, for access to technical support and updates. More recently, many software vendors have migrated from perpetual licensing to a subscription model, usually renewed annually. For desktop or workstation software, this cost further scales by the number of users enabled; for server software, the cost can scale by the number of server blades, clusters or cores; for embedded system, deployers are usually charged a mix of costs for a project, tools and the number of run-time licenses.
For open source downloaded directly from a project repository, the acquisition cost is effectively zero. Alternately, acquiring organizations can choose to source project code from a vendor, typically a company active in developing and maintaining the open source project. Suppliers of commercial open source typically also employ a subscription model, with costs comparable to proprietary software, but usually less.
Many organizations still choose to develop their own applications, especially for provision of services internally or over the web. This approach is usually the most expensive option.
Cost of support, via third parties or self-support
Support for open source project code, whatever the cost, offers greater freedom of choice and reduced lock-in to a single vendor. In many cases, the organization responsible for launching, distributing and/or maintaining the project code also offers a commercial-quality distribution and profession support, including an SLA (service level agreement) and sometimes also warranties and indemnification for the code in source and binary forms. Examples include Red Hat with RHEL, Cloudbees and Jenkins, MongoDB from MongoDB, Inc. and others.
Another scenario involves multiple third parties, which may or may not be directly involved in the development and maintenance of a project, productizing and/or supporting it. Examples include embedded Linux from MontaVista, Wind River and others; Git-based public and private SaaS repositories from GitHub, GitLab and Bitbucket, and a whole ecosystem of support and SaaS vendors for OpenStack, Kubernetes and other cloud infrastructure services and platforms.
Organizations that integrate open source into their software portfolios and application stacks can also choose to forego commercial support, relying instead on community and internal resources. This approach can be highly cost-effective but presents greater risk, especially for business-critical and mission-critical use cases.
Training cost
Training costs seldom account for a major share of expenditures associated with an opens source project. As with support, training for open source applications and infrastructure is available through multiple channels and over a range of media - in-person, remote, web-based, etc. As with any type of software, training for open source is usually a worthwhile investment.
Compliance costs
An area where using open source software incurs costs not present with proprietary software lies in compliance
The cost of compliance can include acquisition/licensing of Software Composition Analysis (SCA) tools, third-party scanning, auditing and remediation, and headcount to support compliance staff or an Open Source Program Office (OSPO).
Your TCO mileage may vary
Even considering the above costs for integrating and deploying open source software, it helps you avoid vendor lock-in, provides greater choice and flexibility and still usually offers lower costs over its lifetime.
Organizations lose control of IP if they use open source software
FALSE
The notion that using open source together with proprietary software will force developers and integrators to disclose their closely-held IP stems from multiple factors:
misunderstanding the compliance requirements of reciprocal / copyleft licenses
overly conservative legal teams avoiding the perceived risk to intellectual property
anti-FOSS propaganda and pro-FOSS zealotry
There are circumstances in which an organization would be required to disclose source code due to admixture with and dependencies upon open source software governed by copyleft licensing – GPL-family licenses and a few other reciprocal licenses. But given that GPL licenses comprise just over 20% of all open source (a number that is declining) and that there exist well-understood rules for limiting copyleft exposure, as well as alternate versions of many GPL-licensed projects under non-copyleft licenses, your IP risk is actually quite low and straightforward to mitigate.
OEM-friendly OpenTAP Licensing
OpenTAP is designed and licensed to provide the greatest possible flexibility to users and to developers of plugins. The OpenTAP core is released under the Mozilla Public License version 2.0 license which:
Imposes no significant impediments or obligations to test and measurement users
Encourages (but does not require) contribution of modifications back to the OpenTAP community
Is compatible with other permissive open source licenses such as MIT and BSD
An open source test framework will force its license on the code/device under test
FALSE
As described in the previous section, OpenTAP employs the OEM-friendly Mozilla Public License, imposing the most minimal set of obligations on users and deployers of the platform. OpenTAP users and OpenTAP plugin developers, while probably best served by choosing Mozilla, MIT or BSD licenses for their own code, can choose almost any open source license for releasing code, and can also retain all rights to their code under a proprietary license as well.
See the white paper Choosing a License for your OpenTAP Plugin or the blog series on the same topic to learn more about best licensing practice for OpenTAP plugins.
You can't charge for open source software
FALSE
Free and Open Source Software provide entrepreneurs a rich and broad set of opportunities for offering commercial products and services based upon project code:
Use OSS to deliver a service
Sell services, support, information for/about OSS
Publish information about OSS to garner advertising revenues
Sell hardware for/with OSS
Host an exchange for the product of an OSS tool or platform
Open source/commercial dual licensing
Offer OSS with commercial upgrades
Integrate, package and distribute solutions of OSS
Achieve strategic objectives, rather than direct revenue
Disintermediation of a competitor
and many others. Learn more from the blog Monetizing Open Source Software.
Open source development is unmanaged
Open source development has been (absurdly) compared to the Infinite Monkey Theorem: a monkey or a team of monkeys, hitting keys at random on a keyboard, will eventually produce a given text, like the works of Shakespeare (or the Linux kernel, or even OpenTAP).
Open source development is anything but unmanaged or random; nor does it require vast amounts of time to achieve results. If anything, the open source development methodology has been shown to provide better results with fewer resources in impressively shorter amounts of time than traditional closed/proprietary methods. This isn’t by magic – these effects are realized through the advantages of open collaboration. But don’t take our word for it.
Using Open Source Software to Speed Development and Gain Business Advantage – The Linux Foundation
Open Source Management – the QuintaGroup
My favorite open source project management tools – opensource.com
