The first time you contribute your coding skills to an open-source project (or even browse GitHub to see what’s out there) can feel like you’re trying to understand hip new slang. While you might scratch your head wondering what the fork is a repo, don’t let the open-source jargon keep you from getting involved.
Contributing to open-source projects is “a wonderful thing to do if you have the time and resources to do so,” says Mariel Frank, Software Engineer at Codecademy. “It definitely looks good on a resume — but even more than that, you’re helping build a codebase that everyone can see and access. So it’s a way of helping make a lot of tech more accessible to more people.”
Getting involved in open-source software also gives you practice dealing with a codebase that’s more complex than a single programmer could handle alone, says Nick Duckwiler, Software Engineer at Codecademy. This is a common hurdle that programmers often face when they’re employed at a company of any size, so it helps to get some experience, he says.
If you’re intimidated by open-source terminology, here’s some key vocabulary that you might see — and useful definitions that will prepare you to submit that pull request (this phrase will make sense later).
GitHub: This is a popular web application that developers and code enthusiasts use to collaborate on code — GitHub is also the place to go if you want to find open-source projects. If you don’t feel ready to jump in and start working in GitHub, be sure to check out our course Learn Git & GitHub. You’ll learn all the ins and outs of the command line tool Git, plus understand the workflow.
License: Open-source projects are released under licenses that set ground rules about what people can (and can’t) do with it. These licenses also enable software to be shared and changed.
There are lots of different types of open-source licenses, and the owner of the project will choose a license based on a few factors, like how the software will be used and by whom. For example, the MIT license is short, simple, and has very few conditions, whereas GNU General Public License is more restrictive and requires you to document any changes and modifications. Here are some of the most widely-used open-source licenses that you might see:
GNU General Public LicenseApacheMITCreative Commons
In GitHub, you can find information about the repository license — plus other instructions and contributor guidelines — in the project’s README file. (For more of an in-depth explanation of how open-source software licenses work, check out Open Source Initiative.)
Owner: Whoever starts an open-source project is the owner, and they typically get full administrative access, according to GitHub.
Maintainer: The contributors who are responsible for handling a project’s big-picture vision are called “maintainers.” They might also manage the organizational or housekeeping tasks involved with sustaining the project.
Repository (or “repo”): This is essentially the homebase of a GitHub project, containing all the files, documentation, and license information that you’d need to work on it.
Fork: Forking allows you to copy someone else’s repository, so you can experiment making your own tweaks without permanently changing the repository for everyone else.
Forking is useful if you want to suggest changes to someone’s code that you don’t have access to or if you want to start a project based on someone else’s code, according to GitHub.
Clone: You can also make a copy of a GitHub repository by cloning it, which allows you to save it locally on your computer (rather than on GitHub’s server). “You use cloning when you’re working on that repository and you want to make changes,” Nick says. “Use forking when you want to make your own version.”
Branch: Here’s yet another way to make a version of a repository. According to GitHub, branches allow you to “develop features, fix bugs, or safely experiment” without messing with the other programmers’ work in the repository. To learn more about how GitHub branches work, check out the Git documentation here.
Pull request/merge: “At its core, a pull request really seeks to answer the question: What did you change?” explains Web Developer Pat DePuydt. Engineers are always submitting and reviewing pull requests (aka PRs), even outside of the open-source space — it’s one way that teams of programmers collaborate.
In GitHub, pull requests allow repository collaborators to give feedback on proposed changes to the code before they’re actually incorporated or “merged” to another branch. Here are some tips for writing a clear pull request that will increase your chances of getting it accepted on GitHub.
Commit: Revisions made to the code in a repository are called “commits.” A commit is a permanently stored change inside the staging area in a repository, and it includes a log message contextualizing the changes. “You don’t want to just submit a change without any kind of clarity surrounding what you’re doing,” Mariel says.
Issues: Wondering what needs to be worked on in a GitHub repository? Check the list of “issues,” which are suggested improvements, tasks, descriptions, or questions that are created by other collaborators in a project.
Keep in mind that posting issues to a codebase is another way to contribute to open-source projects besides writing code, Nick says. “You don’t always have to write code or actually make changes to contribute to open-source software,” he says. “Making an issue to say, like, I’ve discovered this bug, or like, I think this would be a good improvement, that’s also part of the process.” Expert tip: Search GitHub for issues labeled “good first issue” to find beginner-friendly open issues.
Code review: This is the collaborative process where developers provide feedback on your code and review pull requests. In all programming, certainly in a professional setting, you’re going to be reviewing other people’s code, Nick explains.
Hopefully this crash-course in open-source and GitHub terminology empowers you to contribute to some projects on your own. Even if you’re just at the beginning of your coding journey, these concepts might come up as you collaborate with other developers and launch a career in tech.