Open source code is code that is freely accessible to everyone and is generally developed and maintained by the general public.

“Accessible to everyone” means a viewer only needs to create a user account on a VCS(Version Control System) like GitHub. Once they do that, they can view the available open-source projects.

The opposite of open-source code is private code. To access private code, not only do you need a VCS account, but you also need an invitation to that private repository (code is stored in repositories, one or more repositories make up an application).

Not only can viewers view the code, but they can also make suggested changes such as features or bug fixes, and can review others’ code.

The maintainers of the open source project– the admins of one or more repositories– set out guidelines for the contributors of the code on how to write, propose and review code. There are almost always fewer maintainers than contributors.

Again, by contrast, private code relies on a private group to maintain the code. Typically these private groups are employees of companies, government agencies, or non-profit organizations.

‍

What do Open Source Maintainers do?

Open source maintainers are responsible for managing open source projects.

This includes organizing the work of contributors, including the processes for recommending improvements, adding proposed code, and approving the code changes. Maintainers can approve code (in GitHub, via reviewing pull requests), and contributors can too, depending on the project’s guidelines.

But maintainers do a lot more than that. To quote a few of the maintainers who spoke:

Being a maintainer is not just about coding, it’s about finding issues that are really good, especially for first-time contributors to the repository. I try to sit down and go through the code and see if I can find good first issues on a fairly regular basis so that I can help new people get involved with our code.

Being a maintainer often involves walking people through how to get started, or matching them to an issue.

I do a lot of code review as a maintainer. I really like it because it helps me to learn how to code better as well, and helps me become a better communicator.

Importantly, being a Maintainer can be more about working directly with the code:

So, to me, being an Open Source Maintainer is very little about the code and very much about the community– creating a space where people feel encouraged to contribute, especially new contributors. It’s very important to me to lower the barrier to entry and create spaces where the community can support each other, you know, as a, as a maintainer.

‍

What are some examples of Open Source Projects?

A neat example of open source code comes from NASA.

Here’s the link to NASA’s open source code: https://github.com/nasa

NASA has published 413 open source projects, some of which are combined to create applications.

One of the applications is Cumulus, which is used to collect information about the Earth’s atmosphere.

Pro Tip: It is incredible what code is available for exploration via Open Source. Go take a look!

You can see that Cumulus is actively under development — there are changes made within minutes of this screenshot.

From there, you can dig in and see that Cumulus has 2800+ finalized or rejected changes (closed Pull Requests) and 10+ changes that haven’t been accepted yet (open Pull Requests).

From here, you could jump right in and start code reviews or tackling issues…… but you shouldn’t.

It’s always a good idea to fully familiarize yourself first with the project and to be respectful of the hard work of the maintainers and contributors who came before you.

For example, you should always read the repository’s contributing guidelines, like this one:

How big is Open Source?

It’s huge, and it’s growing every day.

One estimate is that there are 180,000 Open Source projects.

Open source code is incorporated into many other projects. One recent estimate found that 96% of all applications included some Open Source code.

GitHub estimates that 19% of code contributions went to open source projects:

Open Source contributors and maintainers can come from all walks of life and are around the globe. 80% of Open Source contributors in 2019 came from outside the US.

Employees at RedHat/IBM, Google, and Microsoft are among the major contributors from private companies.

What about the actual number of open source contributors? Answers vary, it’s not as easy to tell as you might think. A 2019 study estimated that there are 7 million developers who are not paid for their work– not all of them are working on open source projects, and many developers who are compensated for coding are also working on open source. So let’s agree it’s a very big number.

‍

Can anyone use Open Source code once it’s created?

Sort of.

It is technically possible to take any open source project and make a copy of it– that’s part of what it means to be open source.

If you want to learn and explore, it makes sense to make a copy of the repository and get to know it.

It is also technically possible to reference or use that open source code in another project, whether it’s open source or private.

These are the technical answers.

However, there are also important and legal or, in my view, ethical considerations.

First, the legal ones. All open source code comes with a license, which lays out how you are allowed to that code. Private code has licenses too.

These licenses vary substantially. Some licenses are quite permissive– you can do whatever you want with the code. Other licenses are commercial– you can only use the open source project if you pay for it.

Finally, some licenses have very particular requirements: if you use the code and share it, you are required to give away any code you create for free as well. This is called a “Copyleft” license. Violations of Copyleft can be a big deal for companies– such as lawsuits.

What does that mean for you?

First, know that there is no way to tell what kind of license it is just based on having access to it– you have to read the license.

The good news is, if you are exploring the code to learn from it, there’s nothing to worry about.

If you are using the code personally– not just exploring it, but putting the code to work– then you need to read the license file. If it’s a commercial license, do the right thing and pay for it.

Pro tip: If you are at a company or organization that is using open source code, please check with your colleagues about setting up a proper approach to organize and vet the usage. Send your colleagues or your company’s lawyer, this article to read how open source can put your business at risk.

Those were the legal issues. Now, let’s talk about ethical issues.

Open source code is only based on the community of millions of coders who make it possible.

Even if the license type is permissive, I believe all open source users, whether individuals or teams have an obligation to give back to the communities who’ve created the code.

From my Scouting days, there is an expression–

Leave a campfire better than you found it.

This can apply to codebases generally, but it also applies to open source: if you use open source code, you should help make that open source code or other open source projects better.

Thankfully, there are many ways to give back to the open source community, other than by coding:

• As an individual, become a contributor or a maintainer of the code
• As an individual, become a contributor or a maintainer for the community
• As an organization, donate to open source projects that your company uses
• As an organization, donate goods or services (such as your company’s software) to open source projects

Conclusion

Hence, we’ve covered the basics of open source and learned what is open source and how and why to use it.

Also Published here