Open Source: Freedom, History, and Collaboration
Key Points
- Open source software is defined more by user and developer freedom to modify and share code than by its lack of cost.
- The movement gained momentum in the 1980s and exploded with Linux, leading companies like Red Hat to blend proprietary products with open‑source versions such as CentOS for mutual benefit.
- For‑profit firms profit from community contributions that improve their commercial codebases, while developers gain access to high‑quality, freely extensible software.
- Collaboration hinges on publicly accessible repositories (e.g., GitHub) where anyone can fork the code, propose changes via pull requests, and have those changes reviewed.
- Approved contributors become committers, who enforce coding standards, require tests, and merge vetted changes after a proven track record and peer endorsement.
Sections
- Open Source: Freedom, History, and Business - The speaker explains that open source software, while free of charge, is fundamentally about user and developer freedom, outlines its historical emergence from proprietary roots to projects like Linux and Red Hat, and describes how companies like Red Hat benefit from community collaboration through initiatives such as CentOS.
- Open Source Governance and Community - The passage explains how committers enforce standards, how projects evolve into foundations, the role of open‑source licenses such as the GPL, and how a diverse community of users, contributors, committers, and foundation members sustains an open‑source project.
Full Transcript
# Open Source: Freedom, History, and Collaboration **Source:** [https://www.youtube.com/watch?v=PVD1LNDxOnc](https://www.youtube.com/watch?v=PVD1LNDxOnc) **Duration:** 00:06:01 ## Summary - Open source software is defined more by user and developer freedom to modify and share code than by its lack of cost. - The movement gained momentum in the 1980s and exploded with Linux, leading companies like Red Hat to blend proprietary products with open‑source versions such as CentOS for mutual benefit. - For‑profit firms profit from community contributions that improve their commercial codebases, while developers gain access to high‑quality, freely extensible software. - Collaboration hinges on publicly accessible repositories (e.g., GitHub) where anyone can fork the code, propose changes via pull requests, and have those changes reviewed. - Approved contributors become committers, who enforce coding standards, require tests, and merge vetted changes after a proven track record and peer endorsement. ## Sections - [00:00:00](https://www.youtube.com/watch?v=PVD1LNDxOnc&t=0s) **Open Source: Freedom, History, and Business** - The speaker explains that open source software, while free of charge, is fundamentally about user and developer freedom, outlines its historical emergence from proprietary roots to projects like Linux and Red Hat, and describes how companies like Red Hat benefit from community collaboration through initiatives such as CentOS. - [00:03:06](https://www.youtube.com/watch?v=PVD1LNDxOnc&t=186s) **Open Source Governance and Community** - The passage explains how committers enforce standards, how projects evolve into foundations, the role of open‑source licenses such as the GPL, and how a diverse community of users, contributors, committers, and foundation members sustains an open‑source project. ## Full Transcript
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 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 devs 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 easy to access.
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 code base.
The repo is accessible and writeable 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 change 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 a 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 you have 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 commercial interests, the handling of future changes and plans gets a lot more formal.
This formal designation typically follows a pretty standard naming convention.
It's the project name plus the word "foundation".
You think of Apache Foundation, Linux Foundation, 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 could be distributed, modified and other stuff like attribution.
The most common is the GPL.
That's the General Public License.
It guarantees four freedoms: the freedom to run, study, share and modify.
This includes commercial for-profit uses too.
Finally, it's a bit of a cliché, but 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 another open source project.
One of the best known examples is Linux, which is based on Unix.
If an open source project can get 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.
Popularity of Kubernetes benefits adopters by allowing them 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.