Table of contents
What is Open Source?
Note that this is a summarized definition of Open Source, intended for Beginner and Intermediate Audiences. For Advanced and Expert audiences we recommend you review the definitions at the Open Source Initiative.
Open Source code is code that is accessible to everyone, and (almost always) is created and maintained at least in part by members of the public.
“Accessible to everyone” means a viewer only needs to create a user account on a version control system like GitHub, Once they do that, they can see Open Source projects.
The opposite of Open Source code is private code. To access private code, not only do you need a version control system account, but you also need an invitation to that private repository (code is stored in repositories, one or more repositories make up an application).
“Created and maintained at least in part by members of the public” means that 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 leadership of one or more repositories– set out guidelines for 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.
Say more about what Open Source Maintainers do.
Open Source Maintainers are responsible for organizing Open Source projects.
This includes organizing the work of Contributors, including the processes for recommending improvements, adding proposed code, and approving that code. 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, too. 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 to 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 tome 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 examples of Open Source?
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 that Cumulus is actively under development — there are changes made within minutes of this screenshot.
From here you can dig in and see that one repository within Cumulus, also named Cumulus, has 2810 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, always a good idea to fully familiarize yourself first with the project, to be respectful of the hard work of the Maintainers and Contributors who came before you.
For example, you should always read the How to Contribute Guides first, 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.
And 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 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 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 can make 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.
Those are the technical answers.
However, there are also important legal– and 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.
Good news, 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. There is great software that can help.
Those are the legal issues. Let’s talk about the 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 code better.
Thankfully there are many ways to give back to Open Source, and not just by coding.
- As an individual, become a Contributor or a Maintainer to 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
OK, now that I’ve covered some of the basics, let’s turn back the discussion from the EddieHub sessions about Open Source.
