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.



IBM Technology

오픈 소스 소프트웨어란 무엇인가요?

오픈 소스 소프트웨어는 무료로 배포되지만, 무엇보다 사용자와 개발자의 자유를 강조합니다.

역사적으로 대부분의 소프트웨어는 민간 기업이 개발하여 독점 소프트웨어를 판매했습니다.

오픈 소스 프로젝트는 1980년대에 주목받기 시작했고 Linux와 함께 크게 증가하여 독점 소프트웨어와 오픈 소스 소프트웨어가 혼재하게 되었습니다.

RHEL의 무료 버전인 Red Hat의 CentOS는 회사와 개발자 모두에게 혜택을 주는 오픈 소스의 윈윈 상황을 잘 보여줍니다.

GitHub와 같은 리포지토리(리포지토리)는 코드 공유, 버그 보고 및 개선이 가능한 협업을 용이하게 합니다.

기여자는 로컬 사본을 만들고, 변경한 후 풀 리퀘스트를 제출하여 변경 사항을 공식 코드에 병합합니다.

커미터는 풀 리퀘스트를 검토하고, 코드 표준을 적용하고, 테스트 코드를 요구합니다.

커미터가 되려면 입증된 실적과 다른 커미터의 지지를 받아야 합니다.

오픈소스 프로젝트는 1인 프로젝트부터 대규모 개발자 작업까지 그 규모가 다양합니다.

오픈 소스 프로젝트의 공식화 및 거버넌스

특히 상업적 이해관계가 있는 대규모 프로젝트는 구조를 공식화하여 일반적으로 재단(예: Apache 재단)을 구성하는 경우가 많습니다.

오픈 소스 라이선스(GPL 등)는 코드 배포, 수정 및 사용 방법을 정의합니다.

오픈소스 프로젝트는 사용자, 기여자, 커미터 및 재단 회원으로 구성된 커뮤니티에 의존합니다.

오픈 소스 프로젝트의 성장과 지속 가능성

프로젝트는 기존 오픈 소스 프로젝트(예: Unix 기반 Linux)를 기반으로 구축할 수 있습니다.

커뮤니티의 관심은 기여자로 이어지고, 기여자는 커미터가 되어 자생적인 순환을 만들어냅니다.

Google의 Kubernetes와 같은 업계의 기여는 프로젝트의 성장을 크게 촉진할 수 있습니다.

개인은 버그를 신고하거나 수정하여 기여할 수 있으며, 결국 커미터가 될 수도 있습니다.