“Open source” sometimes feels like a new term, but it’s actually a long and established concept. While developers have created software and given away the source code under various terms since at least the 1980s, the phrase “open source” was finally formalized in 1998 to mean a recognized license where the software and its source code was available to others to learn from and re-use
Open source is a power multiplier for today’s IT organizations. IT leaders can realize significant savings by deploying open source. That’s the value of open source in the organization. Every IT leader needs to find ways to innovate, to define new value. Open source can be a great platform to do that.
Open source in the organization
In the 1980s and 1990s, most people considered “open source” as something that only computer nerds used. In that era, the focus was mostly on creating open source replacements for proprietary software.
But with the turn of the millennium, that changed. I can’t identify a specific date, but sometime in the early to mid 2000s, open source became a center for innovation. That’s when open source projects weren’t content to simply create clones of existing products, but instead aimed to create new innovations.
Today, open source is commonplace. Yet even though “open source” is now twenty-five years old, the term still feels new to some. I’ve been in meetings with other IT leaders who still wonder what “open source” can bring to their organization. Who provides support? How can they deploy a moving target?
The truth is that open source is everywhere, and it’s already in your organization. But you may not realize it.
Many products common in modern enterprises are already open source, or built on open source. The Google Chrome browser is built on the open source Chromium project, with proprietary freeware added to it. Microsoft’s Edge browser is also originally based on Chromium. Android phones are based on a custom build of the Linux kernel and other open source software.
Less visible but still present are security webcams that run Linux. The web servers you connect to on a daily basis are likely running Apache HTTP Server, a popular open source web server.
The IT leaders who continue to question if it’s the right time to bring open source into the organization are behind the curve. Open source is probably already part of your I T organizations, and has been for a long time.
The differences in open source
All “open source” licenses are not equal. The Open Source Initiative lists about 120 open source licenses, although only a hundred are considered active. The four most popular licenses are the GNU General Public License, the Apache 2.0 License, the MIT License, and the BSD License. Each is different and brings a slightly different application of “open source” to your organization.
The GNU General Public License (“GNU GPL”) is also called a “copyleft” license, and its terms declare that any software released as open source under the GNU GPL cannot be made proprietary. The GNU GPL version 3 replaced the GNU GPL version 2 in 2007, but a lot of projects still use version 2 of the license. The Linux kernel uses the GNU GPL version 2, for example.
The Apache 2.0 License is a more permissive license that provides certain patent protections. Specifically, if you sue based on software patents, your right to use software under the Apache 2.0 License is revoked. The Apache HTTP Server and Kubernetes are two examples of projects that use the Apache 2.0 License.
The MIT License is also a permissive license. At 160 words, it is also quite short. Node.js, jQuery, and Ruby on Rails use the MIT License.
The BSD License provides the most flexibility. Software distributed under the BSD License can be incorporated into other projects, including proprietary software. The BSD License has two common variants: the 2-clause and 3-clause versions. The 3-clause version has a “no endorsement” clause that states the developers cannot be “used to endorse or promote products derived from this software” without permission.
Open source means source code
Open source licenses apply only to the products that incorporate their source code. For example, an organization that wants to re-use source code released under an open source license will need to pay close attention to the terms: If the open source code is under the BSD License, there’s no problem. But if the source code is shared under the GNU General Public License, the product that uses the GNU GPL source code must also be released under the GNU GPL; you cannot incorporate source code from a GNU GPL project into a proprietary software product.
However, organizations that simply use open source software projects have an easier time. Deploying open source software within the organization is not usually considered sharing; the GNU GPL frequently asked questions list says if the software is used entirely in-house, “the organization is just making the copies for itself.” It is only if you distribute that software outside the organization that you need to pay closer attention to the distribution terms, such as providing the source code.
Open source in your organization
Organizations can deploy open source in a variety of ways. One common use case is to run open source to manage the back office or data center of an organization.
This is often an invisible way to deploy open source in an organization. Core services such as web, authentication, and logging can be performed equally well and at lower cost by migrating to Linux servers and open source software. IT leaders won’t see a hardware cost difference, but the software costs and total cost of ownership tends to be lower using open source software. Organizations might use a free (no-cost) Linux distribution such as Rocky Linux or Fedora Linux, or purchase an enterprise support license such as SUSE or Red Hat Enterprise Linux.
Running these back-end services does not magically turn an organization into an open source company. You don’t need to release any other software as open source just because open source is running part of your back-end.
