An Easy Introduction to Open Source Projects
This article originally appeared on FOSSlife and is republished with permission.
Please visit FOSSlife for up-to-date news and resources for succeeding with free and open source software.
Welcome to open source! We have thousands upon thousands of projects available for you to use and contribute to. This might seem a bit overwhelming, but it’s going to be OK. Open source needs you and we’re here to help get you started.
So what is an open source project anyway? It seems like the answer should be easy. “It’s openly available code,” right? Well, not necessarily. It all depends on how the project is licensed. A license tells other people what they can and cannot do with a project. A project like Unity is openly available but its license states it’s only available for reference, not for modification or redistribution. Other projects are openly available but have no license at all. According to copyright law, this means the project is automatically all rights reserved, meaning it’s illegal to do anything at all with the project without the author’s express permission.
Neither of these examples are open source projects, because neither of them are licensed in a way that’s in accordance with the Open Source Definition (OSD). This is a set of ten requirements that a project must meet to be considered “open source”. If a project doesn’t meet each one of those ten requirements, it violates the OSD and, by definition, is not an open source project. The easiest way to make sure a project is actually open source is to look at the license under which it’s released. If it’s an Open Source Initiative-approved license, then you’re guaranteed that the project meets all ten of the requirements of the OSD and is definitely an open source project. That’s because the Open Source Initiative (OSI), the standards body that maintains and protects the OSD, has reviewed those licenses and confirmed that any project that uses one of them will provide the ten requirements of the OSD. Projects that use a different non-approved license or no license at all cannot be guaranteed to be open source and may be risky or even illegal to use. Some popular OSI-approved licenses include GNU General Public License (GPL), Apache License 2.0, MIT license, and the suite of Creative Commons licenses.
Notice that I keep saying “project” instead of “code” or “software.” That’s because while most open source projects are code-based or software, not all of them are. For instance, the Public Speaking repository is a text-based open source project available under the OSI-approved Creative Commons Attribution Share Alike license. The Open Source Way Guidebook is another example of a text-only open source project. Open Source Design is a community of designers whose work is available under OSI-approved licenses. The Phippy and Friends books from the Cloud Native Computing Foundation—which teach about Kubernetes and other cloud native projects—are available under the OSI-approved Creative Commons Attribution license. These are just a few examples of non-code open source projects and communities you could get involved with.
Who starts all of these open source projects, anyway? You do! Well, people just like you, anyway. Anyone can create a project, either by themselves or with friends and colleagues. All it really takes is a problem that needs solving, a solution for the problem, an OSI-approved license, and a place like GitLab to host and share your project. That’s an oversimplification, of course. An open source project is like any other project you’d undertake. It requires planning, communication, and processes or policies for how to do the work. Unlike many other projects though, an open source project also requires that “open” part. It doesn’t only apply to the code or source material; it also applies to the governance of the project. This means having open dialogue, open decision making and results, and open policies and processes. This not only ensures as many people as possible can participate, it also helps keep everyone honest and set the standard for how a project operates.
As far as how projects operate and work—a project’s governance—there’s no one answer for that. While all will share the ethos of openness, after that they tend to do things in whatever way makes the most sense for them. Each project is a unique community and culture, with equally unique needs and requirements. There’s no single rule set or governance model that can apply to all projects. The closest we can get to a rule that applies to all open source projects is “Always Read The Documentation First.” Most projects will have some sort of documentation setting expectations and guidelines for how the project operates and how to contribute to the project. I cover a lot of this information in my book Forge Your Future with Open Source, but basically you can check the project for a file named CONTRIBUTING, CONTRIBUTORS, or something similar. This file is the best place to start when you want to learn more about how a project operates. It will tell you how to make a contribution to the project and often will also list communication routes for the project (mailing lists, real time chat, etc.) and other valuable information. You can learn a lot about a project by joining these communication routes and simply listening for a while. These routes are also the best place to ask questions. It’s always better to ask how a project operates than to assume. The few minutes it takes to ask will make it much more likely that your open source experience is a good one for you and for the project.
With so many different types of governance and project operation, you’re probably thinking that it’s a miracle that any of this works at all. How do open source projects manage that? A lot of it is due to the open governance that I mentioned above. If everyone can easily see how the project operates, they’re more likely to follow those guidelines so things move smoothly. However, we also can’t underestimate the power of shared goals. The contributors and users of an open source project form its community. A community is a self-organised and self-identified collection of people sharing a concern or interest. That concern or interest—the project, in this case—forms the nucleus of the community but it’s that self-identification that’s the force holding the community together. People identify as a member of that community and want to do things to help it. The power of the community is what enables things like open collaboration and open communication, leading to the creation of amazing things in open source. The best communities leave nothing to chance and reinforce that power with a Code of Conduct that details how that community interacts and helps to ensure that the community remains an open and welcoming place for all contributors.
A shared concern or interest can help to bring people together into a community, but why do people want to donate their time and talent in the first place? Why contribute to an open source project at all? While some people contribute simply to fix something that’s been bothering or blocking them in their own work (“scratch their own itch”), many are looking for a lot more from their contributions. “Why contribute?” is such an important question that I dedicate two chapters in my book to helping readers figure out why they want to contribute and which project will help them reach their contribution goals. If you don’t know why you want to contribute or what you’re hoping to get out of the experience, you’re unlikely to be very satisfied with it and that would be a shame. Knowing why you want to contribute makes your contribution experience more successful, since you can target your efforts not only to where you can make a difference but also to where you can grow toward your own goals. It’s hard to target your efforts like that if you don’t know your goals in the first place. It’s like trying to shoot a bullseye in a darkened room: possible but pretty darn unlikely.
There are a lot of potential benefits to contributing to a project. You can get personal and professional growth by learning new technical and interpersonal skills. Programming, writing, security, accessibility, project management… There are so many things that you can learn by participating in an open source project. A lot of folks also participate for more altruistic reasons. They believe in sharing and that by releasing open source projects they can help to lift up others. Some people contribute because they believe in the Four Freedoms and the power that these freedoms have to foster equality and equity for all people. Whatever reasons you have for wanting to contribute, always remember that’s exactly what those reasons are: yours. No one else will have the same needs, goals, or constraints. Your reasons are unique and personal.
Once you know your goals and are ready to get started contributing, you’ll likely find you’ll need to know git to make much progress. Even the text-only projects listed above use git for storing, sharing, and collaborating. git can be fairly intimidating at first, but when you break it down into its fundamentals things get a lot clearer. In this article we’ll show you how to get started with git so you’ll feel a lot more comfortable making contributions.