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 ) like . Once they do that, they can view the available open-source projects. VCS(Version Control System GitHub 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 (code is stored in repositories, one or more repositories make up an application). repository 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 of the open source project– the admins of one or more repositories– set out guidelines for the of the code on how to write, propose and review code. There are almost always fewer maintainers than contributors. maintainers 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 ), and contributors can too, depending on the project’s guidelines. pull requests 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 , which is used to . Cumulus collect information about the Earth’s atmosphere : It is incredible what code is available for exploration via Open Source. Go take a look! Pro Tip 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 ( ) and 10+ changes that haven’t been accepted yet ( ). closed Pull Requests 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. found that 96% of all applications included some Open Source code. One recent estimate that 19% of code contributions went to open source projects: GitHub estimates Open Source contributors and maintainers can come from all walks of life and are around the globe. in 2019 came from outside the US. 80% of Open Source contributors 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. 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. A 2019 study ‍ Can anyone use Open Source code once it’s created? Sort of. It is technically possible to take any open source project and of it– that’s part of what it means to be open source. make a copy 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 that open source code in another project, whether it’s open source or private. reference or use 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 . Violations of Copyleft can be a big deal for companies– such as lawsuits. “Copyleft” license 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. : 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, to read how open source can put your business at risk. Pro tip this article 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 , 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. can apply to codebases generally 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

Too Long; Didn't Read

Making security fun one episode at a time

Understanding Open Source Contributions

Too Long; Didn't Read

Steph

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Understanding Open Source Contributions

Too Long; Didn't Read

Steph

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES