DEV Community

Steph
Steph

Posted on • Originally published at semasoftware.com

Basics of Open Source

What is Open Source?

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.

Image description

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).

Image description

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:

Image description

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.

Image description

Top comments (3)

Collapse
 
geraldew profile image
geraldew

Fresh paraphrasing of the Open Source concept is always good to see. Alas some small parts of your wording are either incorrect or misleading.

Calling code "private" is your own addition and not a concept used by either the Open Source or Free Software definitions. Instead the opposite concept is proprietary.

Thus it is the Open Source license that embeds a grant of freedom within the code. The license is therefore an enabler rather than a limiter.

Indeed, code that is publicly published but with no licence remains proprietary by copyright law.

Open Source licences are generally clear enough for programmers to read and go straight ahead and use the code in personal work. There might however be qualifications about further distribution of the code or modifications of it.

Your statement:

  • "Other licenses are commercial– you can only use the Open Source project if you pay for it."

is simply false as such a concept is compatible with neither definition. Perhaps you are confused by occasions of dual licensing, which is something a full copyright owner can do.

A confusion often occurs when a producer might not supply software to you unless you pay for it. But if it is Open Source then the license grants you a right to the source code to go with it. All Open Source licences grant you the freedom to redistribute it as is.

Similarly, quite a few "permissive" licenses have enough requirements for corporate lawyers to like taking a fee to clear, it doesn't only happen with copyleft ones. And neither is a problem if a derived work is remaining as Open Source.

As you've used "Open Source" with capitals (as indeed I usually do) then I recommend quoting the organisation that coined and defined that concept.
opensource.org/osd

Collapse
 
stephsema profile image
Steph • Edited

I really appreciate your sharing this—thank you very much.

We will update the white paper to include a reference to opensource.org/osd

May I ask follow up questions:

1-What term/ terms do you use to describe code that requires permission from the repository creator to gain access to that code to in a version control system?

2-What term/ terms do you use to describe code that does not requires permission from the repository creator to gain access to that code to in a version control system?

3- What term/ terms do you use to describe code that does not requires permission from the repository creator to gain access to that code to in a version control system, but does require paying for use?

We would describe #1 as “Private”, #2 as “Open Source,” and #3 as “Open Source- Commercial.” Full disclosure, our team has to explain these definitions to very non-technical audiences on occasion, so I’m sure there’s nuance missing in our summaries. Keen to hear your terminology.

Grateful for your careful read.

Stefan

Collapse
 
geraldew profile image
geraldew

Your questions are about the access to a version control system, rather than the code.

As I've already said, code becomes Open Source when an Open Source license is embedded in the code text. It retains that license as it travels. This idea, and its leverage of copyright laws predates and is independent of code versioning.

To paraphrase a little: your question is like asking whether a haiku, as a type of poem should have a different name depending on when it is written in pen or pencil.  Which is that you are mistaking the tool for the content.