Open-Source: What it is and why you should be involved.

This post will highlight:

• What open-source is
• How you can contribute
• Where to start looking for projects and issues

Do you like going to the park? Maybe not right now because it’s the end of October and well, winter is coming! But what if your favorite park wasn’t maintained? What if no one took responsibility or ownership of the park and peoples trash just piled up and other peoples dog poop was just scattered everywhere waiting to be stepped in? You’d probably stop going to that park. But what if there was a collective group that took it upon themselves to take ownership and pride in their favorite park and started contributing just a little bit of time each week to turn something that was either nothing to begin with or in a really bad state, into something beautiful and useful for other people to enjoy and enhance their lives with? Aside from most likely your tax dollars taking on the effort of maintaining your favorite park, this analogy is sort-of like how open-source software (OSS) works. Open-source software is software that is available to anyone. It can be downloaded and/or used on as many devices as you want. You can take the source code, manipulate it however you want and redistribute it to as many people as you want. This is so because open-source software exists on licenses like the MIT licenses for example. While this is mostly in the perspective of the end user and how open-source software relates to them, as a developer you can be a contributor to open-source projects, you can take some ownership in making the world a better place through the use of software! When contributing to open-source it will do you good to consider who the project maintainers are and try and make an open line of communication with them. I don’t mean bug them to death with questions and expect them to hold your hand through the process, you’re an adult (or maybe you’re not, all the more to you for getting started early), you don’t need someone to hold your hand, but there are a few guidelines that will help you in your effort of making your first contribution, and potentially getting your first merged PR, to an open-source project! I didn’t come up with these things on my own, I was taught them, so Ill just be relaying this advice to you.

Finding a Project

When looking to make a contribution to an open-source project, find a project you can be passionate about, and hopefully one that has a lot of issues to choose from. Don’t pick just any project, choose one that means something to you. This way you’ll have vested interest and will be more likely to take the issue you are attempting to tackle more seriously, plus you’ll feel much better about contributing to something you’re passionate about rather than something you could care less about. I recently worked towards making my first contribution to an open-source project with a small group of people I know from the dev school we go to together. We were given a project from our instructors so we didn’t really have the option of choosing one, though the project we were assigned is an incredible one. Our instructors also gave us a list of issues that would be good for us to attempt to solve.

Finding a Good First Issue

Finding a good first issue is key. Don’t take on more than you can handle and don’t try to show off your skills just yet, in fact look for the easiest thing you can find. This is a great way you can get used to how the communication will work between you and the project maintainers. Sometimes repos () will have labels on issues the maintainers think are good for first time contributors. Look for something like this when going through the issues of the project you’ve chosen. When you find an issue you think you want to work on, write a comment on that issue and tell the maintainers you’d like to work on it. They might not want you to work on that particular issue due to some conflicting reason, though most likely they’ll assign it to you and give you the go ahead. Don’t feel like you can’t get started while you wait for a response from the maintainers either, just be flexible in that they might ask you to stop and move to something else. For our first issue, we chose one that just needed the css tweaked a bit. It was approachable, not over whelming, and its was something we were very confident we could solve.

Getting Started and Familiarized

This part can be tricky. Once you’ve chosen an issue to solve, then you’ll need to get the project running on your local machine and it’s likely that the code base will be a large one, depending on the project of course. There might be a lot of dependencies you’ll need to install just to get the project running. There weren’t many for our project but that doesn’t mean it wasn’t difficult. For example, on the project our group contributed to, we needed to install a specific version of Ruby, a specific version of Rails, PostgreSQL, Phantom JS and a Gemfile with a list of Gems to install. It doesn’t seem like much but we ran into a big problem with getting the specific version of Ruby that was required for the project to run on our machines. We ended up having to use RVM to switch versions, which was one more thing we had to learn to even get the project installed and running on our local machines. Once we had the project running we realized the project was built in Angular written with Coffee Script and used Active Record for interacting with the data coming from the back-end. These were all things we had to familiarize ourselves with in order to comfortably get into the project.

Filing Other Issues

This may or may not be something you’ll need to do, or even something you’ll run into along the way, but for us it was. When you get things running on your machine and begin working on your issue, its likely you may notice something else that just doesn’t work quite right. If you’re working in your local environment when you notice these things, then go to the live site and see if it is the same there. You don’t want to be bringing things to attention that don’t need to be, the maintainers have enough on their plates as it is. Once you think you’ve found something that needs attention, go and thoroughly check the issues that already exist, it’s likely that the issue has already been filed and therefore you don’t need to do anything, except maybe come back to it and try to solve it yourself once you’ve finished what you’re already working on. When filing a new issue, be sure to be as thorough as possible when describing what the issue is. Use screen shots to show visually what it is you are trying to say and make it as easy as possible for someone reading the issue to go on the live site and see exactly what it is you are talking about. For us, we ended up filing two new issues to the one we were assigned. We didn’t even get our PR merged due to it relating to a security measure that wasn’t immediately noticeable. It would be easy to feel like we took two steps backwards for the project, but filing issues is still moving the project forward.

Making the PR

When you think you’ve finished working on the issue and everything is solved, get a second pair of eyes on it before making your pull request. It’s always a good idea to get peer review no matter what, but for your first contribution to an open-source project I’d say it’s necessary, you don’t want to potentially embarrass yourself by submitting something that’s way off base. This would also be why the maintainers will tell you you need to pass all the test before making the PR, so be sure and test your fix before submitting it. Also, while Im on this note, be sure to adhere to any naming or stylistic conventions that the project maintainers have specified. You can find these in the CONTRIBUTING.md file that most projects will have. You’ll also find here how you should format your commit messages, how to write the description for your pull request and how to file a new issue.

Leaving an Issue

Sometimes you might not be able to solve the issue you got assigned, or you thought you had the time to give to the project but it turns you don’t, or you did have the time but your boss dumped a load of unexpected work on you and now you have to bail. That’s ok, just un-assign yourself from the issue and leave a note letting the maintainers know you won’t be able to work on it any longer. Do not just leave it undone without un-assigning yourself and letting them know.

Conclusion

As far as I understand it, there are only benefits to contributing to open-source software. You get great practice coding while contributing to something meaningful and helpful for other people all while bolstering your resume. Not to mention that while you are looking at and reading through all this code, you are probably picking up some good habits and know-how from the developers that originally wrote the code. Just this past Friday I sat down with someone who got his job (which is an awesome and very interesting job doing something that will probably change world in a big way, I’m not even joking) because of his open-source contributions. FreeCodeCamp has an excellent resource of where to get started with these things, . Off with you now, go and do great things.