By watching this video, you've taken advantage of software created by an open-source community of developers. But what does that really mean, "open source"? Is it just another way of saying "free" software? Well, it's true that open-source software is distributed at no cost, but that's missing a much larger point.

It's really about freedom. By this, I mean the freedom for users and developers to do much more with open-source software. Okay, a quick bit of history. How did open source come about? Years ago, most large software projects happened inside private companies.

They sell their proprietary software, typically with after-sales support. Then, in the early eighties, interest in open-source projects picked up. But it really took off about a decade later with Linux. That's when developers began combining the two approaches, mixing proprietary software with open source.

Red Hat is one of the best-known examples with Red Hat Enterprise Linux, or RHEL. But RHEL has an open-source counterpart called CentOS. It's the free version of RHEL. So why did Red Hat donate the CentOS source code to an open-source community?

It's not about charity. Like a lot of for-profit companies, they've worked out a win-win situation. On one hand, the company gets help building and improving the base of their commercial product. On the other, open-source developers get commercial-grade code at no cost and the freedom to extend it.

Okay, with that history behind us, let's cover the mechanics and answer a few "who does what" questions. As I mentioned earlier, open source allows you to improve and build upon a base. To get that done, you first need a few things.

We begin with a repository. If you're going to share and collaborate, you need to make it easily accessible. Repositories, or repos as most developers call them, are collaboration platforms like GitHub where you can get source code, report bugs, or suggest improvements.

But more importantly, developers can contribute code that improves or fixes the existing codebase. The repo is accessible and writable anywhere, so anyone can propose changes. The authors of these changes are referred to as contributors. They create their own local copy of the official repo and make changes.

They ask for their changes to be merged into the official code with what's called a pull request. Anyone can be a contributor, but established members are what are called committers. They have review authority on any proposed changes. A committer is responsible for evaluating the pull request.

The pull command copies down their change, and then they have a chance to review it. If they agree with the changes, it's merged back into the main code. Committers enforce code standards and usually require test code to demonstrate the code works as promised.

Becoming a committer requires a proven track record and other committers who are willing to vouch for the quality of your work. It's worth mentioning here that there's no requirement that an open-source project be a certain size.

It can be a one-person passion project, or a huge developer effort. No matter its size, thanks to a common collaboration platform, open source isn't a free-for-all development project. In fact, once a project reaches a significant number of interested parties,

And especially with commercial interests, handling future changes and plans gets a lot more formal. This formal designation typically follows a pretty standard naming convention: the project name plus the word "foundation." Think of the Apache Foundation, the Linux Foundation, the Eclipse Foundation—you get the idea.

Okay, this brings us to a final player: lawyers. Or, more accurately, the open-source license that spells out how the source code can be distributed, modified, and used, including attribution. The most common is the GPL, the General Public License.

It guarantees four freedoms: the freedom to run, study, share, and modify the software. This includes commercial, for-profit uses, too. Finally, it's a bit of a cliché, but the success of an open-source project takes a village.  The common term is a community. It is made up of users, contributors, committers, and foundation members.

So, basically, an open-source project starts with a great idea, developers, and some code. But projects don't have to start from scratch. They might start from another open-source project. One of the best-known examples is Linux, which is based on Unix.

If an open-source project can gain community interest, it gains contributors. Contributors eventually become committers. That user-contributor-committer cycle continues. With a good idea and a bit of luck, a project gets enough regular contributors and committers that its growth becomes self-sustaining.

The cycle can also be turbocharged by industry contributions. For example, Kubernetes was open-sourced by Google. Since it was based on their internal development, it benefited from Google's experience with container orchestration. The popularity of Kubernetes benefits adopters by allowing them to rely on a foundational layer of software.

Developers can then focus their efforts on other projects, just like Red Hat did with RHEL and OpenShift. So, what can you do if you want to join the open-source movement? Start by becoming a contributor—or just reporting bugs. Once you have experience with the code, start by contributing bug fixes.

Once a few of your submissions are accepted, you're well on your way to becoming a committer.

Open Source Explained

Whether it’s AI, automation, cybersecurity, data science, DevOps, quantum computing or anything in between, we provide educational content on the biggest topics in tech. Subscribe to build your skillset, learn about new trends, and gain insights from IBM experts. 

This channel follows the IBM Social Computing Guidelines.



Open Source Explained

Open Source Explained

Scripts