In his 2011 article for The Wall Street Journal, Marc Andreessen wrote that “software is eating the world.” This, he explained, is because of the amazing pace of innovation in the tech industry, which is due in no small part to the open source movement. Open source has grown up alongside the rest of the technology market, and it is the reason why so many providers can create such rich services at such low costs. In the 10 years since he wrote his famous catch phrase, the industry has embraced open source to an even greater degree. And even the largest and oldest companies that once called open source “a cancer” have now fully embraced the movement – including Microsoft.
Where Did Open Source Come From?
Open source grew out of the free software movement, which can trace its roots back to the innovative culture that surrounded electronic and computer hobbyists in the 1970s. This was the same era that gave birth to many technology giants, including Apple and Microsoft. The free software movement was a rebellion against those giants who sought to control their software and limit the rights of its users to modify and redistribute the software as they saw fit. The “free” in the “free software movement” wasn’t about offering products free of cost – it was about “free” as in freedom. In other words, you could charge for your program, but your source code had to go along with it, and the end users could do with it as they pleased.
The realities of “free software” didn’t always align well with the ideology of the Free Software Foundation, however, and many wanted to remove the focus (implied or real) away from cost entirely. In 1998, Christine Peterson coined the term “open source” to place the emphasis on source code instead, and to reify that users should have the freedom to run, modify, and share software. Since 1998, the open source movement has far surpassed the FSF in size and influence, and the sheer number of open source organizations is testament to that fact. For a project to be truly open source, it must use one of the approved open source licenses maintained by the Open Source Institute.
Just How Prevalent Are Open Source Projects in the Real World?
To get an idea of just how prevalent open source is (and how it continues to move into spaces traditionally dominated by proprietary software), look no further than the web browser you’re using right now. Firefox is open source. Google Chrome and Microsoft Edge are open source. Even Opera and Safari are based on open source projects.
Web browsers are also great examples of single open source projects that can be supported by multiple companies shipping their own products. For instance, Chromium is an open source project that was started by Google to be the base for Chrome. Chromium is now used at the core of Opera, Microsoft Edge, and dozens of other web browsers you’ll likely never hear about.
Open source also dominates at the infrastructure layer of the entire technology industry, with over 70% of web facing computers running open source web servers. And you can’t forget the poster child for open source, the Linux kernel, which is currently deployed on billions of devices world wide – and that’s just Android smartphones. That doesn’t even count its dominant position in the millions of servers at organizations like Facebook.
But What About Actual Developer Usage of Open Source for In-House Apps?
You will rarely find true developers who would not love to have the time to build everything that their applications need to function properly. The code that they build is a source of pride. Unfortunately, the reality is that developers are hired by businesses to solve problems, not to build their utopias. So whenever functionality is available that will fulfill their needs, they will use it. This can range from solutions like Drupal (a web content management platform that frees developers to focus on content and integrations) to development frameworks like Spring (which allows a developer to start coding business functionality instead of “plumbing”). In most cases, though, developers use a library to add desired functionality, such as adding a pre-built calculator to a web site.
How Is Open Source Used and Distributed?
There are many different ways in which open source projects can be consumed. The following are some of the most common ways that they are introduced by developers, along with a brief description of how they flow through a DevOps or NoOps pipeline.
Source code is always available if developers want to build a component on their own, but in most cases, they download a pre-assembled component that is ready for use.
Module
A module is the basic building block of any application. It is usually a single file that contains multiple functions. A calculator would be a great example. In this case, the functions would be: add, subtract, multiply, and divide.
Class
A class is a module that can be instantiated into an object. This means that it can keep state on its own. One example of this would be a calculator that can keep a running subtotal.
Package
This can mean different things in different contexts, but in many cases, it just refers to the component as you downloaded it. Strictly speaking (especially for languages like Python and Java), a package is a collection of modules or classes that share the same name space. In Python, packages are hosted in a single directory with a shared __init__.py file, for example, which ensures that they all start in a consistent way.
Library
Libraries are probably the most common way in which application developers leverage open source projects. A library is composed of modules, classes, and even packages that together create a group of complementary functionality. A great example of this is jQuery, which is used by 73% of JavaScript-based websites. This simplifies common functionality, such as event handling and loading data from external services.
Framework
At their core, frameworks are simply collections of libraries that have been pieced together to provide a starting point for developers. Frameworks usually rely on libraries from multiple other open source projects, and they are often opinionated, meaning that they want things done in a specific way. As long as what you need to do falls within those preset guidelines, everything is fine. The reason why so many frameworks exist is that different organizations have different styles, and not everyone likes to work the same way. For example, the top JavaScript frameworks all originated from different companies: Bootstrap came from Twitter, React came from Facebook, and both Angular and Polymer came from Google.
Next Steps
In reality, if you have any in-house development, it’s pretty much certain that you are utilizing some open source code. So you need to answer a few questions: Do you have an inventory of it? Do you know which versions you use? Do those versions have known vulnerabilities? Which licenses are you including, and what kind of exposure does that create for you? The GPL and Apache licenses can have very different impacts on how much of your own code may end up being open source if you ship applications to consumers.
All of these questions can be answered by using a software composition analysis (SCA) tool, which can identify, categorize, and report on the open source code that has been imported by your development team. Introducing SCA functionality into your DevOps toolbox will enable you to flag known critical security defects and then use those as part of the deployment criteria for production. An SCA tool like Checkmarx CxSCA could save your organization from hitting the news cycle for the wrong reasons.
Vince Power is an Enterprise Architect with a focus on digital transformation built with cloud enabled technologies. He has extensive experience working with Agile development organizations delivering their applications and services using DevOps principles including security controls, identity management, and test automation. You can find @vincepower on Twitter.
To learn more about Checkmarx CxSCA, please request a live demo here.
