Modern software development makes use of hundreds of thousands of open-source software libraries and in some cases full applications. This page is written primarily for a non-technical audience and will presume no prior knowledge of the landscape - so questions, however small, are welcome.
This piece was originally written to help non-technical internal audiences better understand how open-source interacts with traditional procurement processes in the Enterprise. If you're a technical person looking for some literature to help your organisation understand the impact open-source has on it or are a non-technical person looking to gain an understanding of the same - then this piece is hopefully for you.
What is Open-Source Software?
From Wikipedia:
“Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is a prominent example of open collaboration, meaning any capable user can participate online in development, making the number of potential contributors' indefinite. The ability to examine the code facilitates public trust in the software.”
Open-source software is an exceptionally prominent type of software in the world today, with many languages, frameworks, and even programming tools being open source.
Open-source projects are mostly maintained by groups of volunteers often with corporate sponsorship or managed by companies, who provide the software to sell either consulting or support contracts.
In its most common form, open-source software is shipped as software libraries that can be incorporated into your own applications, by your own programmers.
Open-Source Software and Your Applications
Even if you're not aware of it, most organisations use tens to hundreds of thousands of open-source libraries in the software that they build. This is the default position in technology - to labour the point - the world's most popular web framework, React - which many organisations build all this webapps in - is both open-source, and depends on 1391 additional open-source packages. So, to build any of those web applications, just to start, would be using 1392 open-source packages. For every website.
The proliferation of open-source in this manner can appear uncontrolled if you’re not familiar with the ecosystem, and in this document, we’ll cover some of the strategies organisations use to adopt open-source safely. Most of these processes should be pleasantly unremarkable and are standard across the technology industry.
Open-Source and Licensing
By default, it's common for teams to be permitted to use open-source software with permissive licenses. This means, licenses where there is no expectation of the organisation sharing their own software or modifications - common examples of these licenses include, but are not limited to the MIT license, and the Apache2 license. It's also common to see organisations license open-source software that is available to businesses under commercial terms, in lieu of contributing code back.
These dual-licensed pieces of open-source effectively allow organisations to pay, instead of contributing, and this model is used to help open-source projects become sustainable.
Because authoring open-source software in a sustainable manner is often a challenge - the projects maintainers or core contributors are frequently working for free - a culture of commercial licensing, consulting, and support contracts has grown around open-source software.
Commercial Support for Open-Source Software
If this sounds confusing, it’s because it often is!
It’s possible, and common, for multiple commercial organisations to exist around supporting open-source software. For the most part, because of the nature of open source - people don’t opt for support. This is because the prevailing attitude is that if an issue occurs in an open-source library, then the consumers can fix it and contribute those changes back to the community.
However, for certain categories of open-source - commonly when it’s entire open-source applications instead of libraries, it’s prudent to make sure you have a support relationship in place - and even more important where the open-source application occupies a strategic place in your architectural landscape. Furthermore, it’s often the correct ethical position to take, and helps ensure the longevity of projects that organisations depend on.
Quality Assurance of Open-Source Software
As a result of the complex nature of the development of open-source software - that it’s code, developed by unknown persons, and provided as-is for consumption, with no legal assurance whatsoever - it’s important that you surround your use of open-source software with the same software development practices that you'd expect from software you author yourself.
What this means is, that where you consume open-source libraries:
- Surround them with unit and integration level automated testing to verify their behaviour
- Execute static and dynamic security scanning over the libraries (often referred to as SAST and DAST)
- Use security scanning tools that track vulnerabilities and patch versions of the libraries to make sure they’re kept up to date.
The fact that you’re doing these activities makes our use of open-source libraries safe at point of consumption - augmented by the fact that of course, you'll have full control of what and when you update, and you can read all the code if we so choose.
Procurement and Open-Source Software
With traditional, paid for software, a procurement process is required to license software, and subsequently start using and developing with the application or library. With open-source, the software just… exists. It can be included from public package management sources (the places that you download the software to use), and development can start with it immediately.
However, this inadvertently circumvents and entire category of assurance that would exist in traditional procurement processes around software. With most of the open-source software that folks use, the burden of quality and assurance is on your own teams at the point of integration. This means that by wrapping the libraries you use in your own software development lifecycle activities like automated testing and scanning, you treat those libraries exactly as if they are code that you author.
But there exists three kinds of open-source as oft consumed:
- Open source for which you do not require a support contract and can test/integrate yourself
- Open source that you desire support for from a maintainer or organisation providing those services
- Open source that is available commercially under dual-licensing - requiring payment for commercial use
For the first category of open-source, you are on your own, and your own internal development processes must be enough. For the two subsequent categories of open-source, in Enterprise, you will inevitably require a procurement and assurance process.
Important Questions for Open-Source Support
Traditional assurance process often centres on the organisation providing the support - their policies, their processes, their workplace environment, and their security. In open-source projects these questions are often nonsensical; there are no offices, there are no staff, the work is done at the behest of contributors. But as you evaluate support contracts with vendors, it’s important to understand their relationship with the product and what kind of support and assurance that they can provide for the payments you make to them.
Here are some sample questions that might replace more traditional assurance questions in open-source procurement processes.
“What relationship do you have with the project?”
Ideally, you would purchase support from the core authors of the project, or the organisation formed around it.
Good answers: “we are the core maintenance team”, “we are core contributors”, “we have commit rights”
Bad answers: “None”, “we are a consultancy providing extra services with no relationship with the project”
“Do you have a process in place to vet contributors?”
Code changes should be reviewed by maintainers.
Good answers: “Changes go through our pull request and testing process, and are accepted by maintainers”
Bad answers: “None”, “we take any contributions without inspection”
“Do your contributors sign any legal agreements formally granting ownership of their contributions to the project?”
Larger open-source projects, or corporate sponsored projects, often have paperwork to ensure that there can be no copyright claims made against the software by employers of contributors. For example, Microsoft use the Contributor License Agreement to ensure this.
While not exceptionally common, it’s a good question to ask.
“Do you have the ability to integrate any bug fixes required back to the main project source?”
You would ideally buy a support license where any bug fixes were integrated into the main project, and not a fork for your own benefit.
Whilst this might sound counter-productive, this ensures that you don’t end up using a “forked”, or modified version of the main project that can drop out of active development.
“Are there any special feature request processes or privileges that come with this support contract?”
Ideally, if you are buying a support contract, it would give us priority in feature requests.
“Do you, and if so, how do you, provide security scanning and exploit prevention in the software?”
Even open-source software is expected to be tested, have build pipelines, and be reliable - doubly so if you’re paying for support licenses.
“What is the SLA on response to bug reports?”
Equally, it’s important to know the service level you’re expecting from support contracts - to manage expectations between both your internal teams and the support organisation.
“Do you have a process in place to support us in the case of a 0-day vulnerability?”
0-day vulnerabilities are “live, fresh bugs, just discovered” and there should be an expectation that if a support body becomes aware of a bug in the software they are supporting, there would be a process of notification and guidance towards a fix.
Conclusion
The use of open-source software is a huge positive for commercial organisations (who effectively benefit from free labour), and to use it both sustainably and ethically, it's important to be aware of both your responsibilities around assurance, and those of any partner you choose to engage with.
Paying for software, and open-source, is one of the most ethical ways organisations can interact with the open-source community (short of contributing back!) and should always be considered where possible.
Top comments (2)
I'd quibble about: "means, licenses where there is no expectation of the organisation sharing their own software or modifications".
The issue is more about not having an obligation such as would be required by a copyleft license. Whether or not there is a general expectation about sharing (or "giving back") is harder to say anything clear about. Personally I get surprised when people who set a weak license then feel miffed when people do the very thing that such a license enables.
The other aspect about this is that the obligations of copyleft only apply when further distributing the "own software or modifications". If the Open Source software is merely being used and adapted inside an organisation then that is not normally treated as "distribution". This aligns to most copyright regimes treating the creations of employees as belonging to the employer anyway.
That distinction is an important difference between organisations who will merely use Open Source for themselves, versus those who will use it to make a product for distribution/sale.
Interesting perspective - and I don't disagree.
The target audience for this piece was originally folks working in a business that was adopting and building software with open-source, so I think the original bias there is present.