Open Source Projects  “In open source, we feel strongly that to really do something well, you have to get a lot of people involved.” Linus Torvalds, Creator of Linux Working on your own projects for a portfolio or even pairing up with another learner is great, but there are skills you won’t learn until you work with other developers in real-world projects. How do you get real-world experience while you are still learning? By contributing to open source software. Open source is defined by Wikipedia as, “a product [that] includes permission to use its source code, design documents, or con- tent. It most commonly refers to the open-source model, in which open-source software… released under an open-source license as part of the open-source-software movement.” In an open source environment, developers upload their code and let other program- mers see, update, and use it (usually) for free. These other programmers will probably use different tools and employ different writing styles than you, and you will have to learn the different standards for merging your code into theirs. You will learn about testing, deployments, and versioning your work, all of which push you to learn and grow much more quickly than you would on your own. Open source code usually lives in repositories, or ”repos” on sites like Since Github is the most common place to host these repositories, you will become intimately familiar with it as you progress on your coding journey. You are going to be interacting with open source tools and software made by other technologists every day as you are learning and throughout your ca- reer. This chapter will guide you through the process of finding and contributing to open source projects.  Finding Beginner-friendly Projects It can be daunting to contribute to another person’s project for the first time. Thinking that you are not qualified and less capable than others is a common setback for beginners. It is also hard to go from reading and understanding code that you wrote yourself to something another person wrote. You can start off very small by making simple updates to documentation files – the files that explain how some piece of software works to humans – or by creating a text tutorial for a particular piece of software and submitting it to the people who maintain that software. If you speak multiple languages, you can also offer to translate text in an open source web or mobile app. This will help you get used to the process and you can work your way up from there. Many communities around open source projects have implemented methods to welcome new developers who want to con- tribute. If you look at any repository on Github (Scout App for example), there will be an ”issues” tab at the top. Click on that and you will see a list of problems with the software (bugs), questions from users, requests for additional functionality, and more. Most projects will separate all of these different issues with ”tags” so you can easily tell them apart when scrolling through or searching for them. Tags are all of the colorful words next to the issue’s title: Most of the time, the coders who own and maintain one of these repositories will be more than happy to let you contribute and may even help walk you through the process. A good place to start is by looking for issues that are tagged something like ”help want- ed” or ”good first issue”. Here are some places that I highly recommend when starting out: Pick an issue on the list, click on it and scroll down through the comments. If you understand what the problem is and no one has posted that they are actively working on it, you can make a comment saying you would like to try. This could mean testing out the problem to see if it is really a bug or updating the actual code. If you do not understand the problem fully, feel free to post a com- ment asking for clarification. You will use a plethora of libraries in your personal projects as you are learning to code. Soon you will realize that none of them are perfect! There will be plenty of quirks, bugs, and misspellings. Why not volunteer to fix the problems that you find since some- one else built the software for you to use for free? You won’t always be able to fix the problem, but it doesn’t hurt to create an issue about it and try to find a solution. If you do not spot any problems yourself, you can always search through the issues in these li- braries as well. The examples I list above are just related to JavaScript. Here is a more comprehensive list of other projects that are friendly to- wards beginners as well: awesome-for-beginners. More recommendations for contributing are listed on my website:  How to make your first contribution Contributing to open source projects has several steps involved, as well as some new terminology. Fortunately, this process has been fairly standardized. Here, I’m going to describe the process you can use for updating documentation or language translations. To perform more complicated contributions, you will have to learn a tool called Git and how to pull and run the code locally on your ma- chine; then make changes and push it back up to Github and request to merge your changes into the repo. The easiest way to get started is to contribute to your own project! You make your own repo on Github, then merge in changes that you make yourself. This will get you used to the process and make it less intimidating when you want to make changes to other peoples’ projects. First, signup at if you do not have an account already. Second, click the plus button in the top right-hand corner and then select ”New Repository”. Give your project a name (you can update or delete it later). Make sure you select ”Initialize this repository with a README” so you have a file to edit later. Then, click ”Create Repository”. Notice that there is already one file there by default called (because you told Github to create it when you set up the repo). This is a standard file found in most repos that describes important details about the project such as where to find help, how to download, install, and use the code, and steps or rules for contributing. When you first go to any repository, the styled output of the file displays after the list of files, it is the first thing a visitor will see about a project. The “.md” at the end of the filename stands for Markdown, which is a markup language like HTML, but for formatting text. You can make headers, paragraphs, lists, and many other elements that you would create in a word processor, except you are doing it with code. I won’t get into too many details here, but I have some links for learning markdown over at my book resources page. Markdown is easy to learn and it is good to know the basics. To edit the file, click on the pencil icon in the upper right corner of the README. Now, let’s add some markdown to the file. I’m adding a subheader here using `##` and then a list after it. Since everything has to be typed out in markdown, it would be really annoying if you had to renumber a list every time you wanted to move around or delete an item. Fortunately, Markdown lets you just use the number 1 for every list item and then it will number them correctly when it renders the styled page. After you make your changes, you can scroll down the page to the ”commit changes” box and enter a description of the changes you made – this is known as a ”commit message”. You will be writing a lot of these over the coming months and years. In the future you will be creating a new branch and requesting to merge it in with the current code by making a ”pull request”. It is fine to leave the option “Commit directly to the master branch” for now though. Press the ”commit changes” button and you are done! You just made your first contribution! That’s the same general process you will have to use when contributing to any repository, but it is missing one step. When you created the codebase on Github, you have all of the rights to update it. When someone else owns the repo, you can’t just update it without their permission. That’s where pull requests come in. A pull request (PR) is when someone wants to merge their code changes into the original repository, but needs permission. The changes must be made first, and then the request is made to update the original which gives the owner and other community members time to review, comment on, or request changes to the new code. Github lets you do this from its website. You click on the edit icon and it will show you the same interface as before, only with a message like this at the top: You do not have to understand what branches and forks mean yet. That will come when you start learning Git. Make your changes, scroll to the bottom, and write a commit message detailing the changes you made. The wording will ask you to propose file changes this time: Clicking the ”propose changes” button will automatically create a PR for you that you can view in the ”Pull Requests” tab on the Github repo. Since the coders who work on these projects are almost always doing it for free, give them some time to get to your re- quest. If they haven’t responded in a week or two, you can post a comment on your PR tagging them (using @their_username) to remind them to take a look. Sometimes it takes a while or they might not end up merging your changes. Do not worry if that hap- pens. It is a great learning experience whether or not your changes get accepted.  Conclusion The term ”open source” in this context is referring to community-driven tools where anyone can read through the code and attempt to contribute and make the project better. There are a great number of these projects, and you should be making simple contri- butions within the first few months of your learning. Contributing to open source is a great idea for the following reasons: •It teaches you know how to use version control (Git – you will learn this in your studies). •You learn how to work on projects with other people. •It teaches the important skills of updating and enhancing codebases that you did not create. These are things you will spend a lot of time doing as a professional! •You are giving back to a community from which you benefit so much. As a programmer, you will be using free re- sources to learn and get help all the time. It is important to give back as well. This makes you look good and feel good. Action Steps: 1.Select an open source project and start reading through the issues. 2.Take note of any bugs or feature requests, especially if they are tagged as ”easy”, ”documentation”, ”translation”, ”first- timer”, or similar. 3.Make the requested changes to the code. 4.Create a PR. 5.Add a link to the PR you created in the original issue. It is a good idea to link the original issue in the PR description as well. 6.Check up on the PR to see if anyone has commented on it.