7 Tips For Contributing To Open Source Projects On Github For Beginners

Github is a free version control system that is often used for hosting code for software projects. There is an option for putting your code in free public repositories where everyone can see, access and download them or in a paid private repository where only you and those you authorize can access them.

Even with major competitors such as Mercurial and Subversion, Github still stands out as the most popular code hosting platform and the favorite for many developers.

As of April 2016, GitHub reports having more than 14 million users and more than 35 million repositories, making it the largest host of source code in the world.

Contributing to open source projects on Github can be a great way to:

• learn about about VCS(version control system),
• learn about project collaboration and team work
• improve your coding skills.

When starting out it can be challenging to settle on the right projects worth spending your time, energy and resources on. Choosing the right project could mean the success or failure of your leaning process and growth as a professional web developer.

With millions of projects on Github, how do you choose the project that you should spend your time on?

In this article I highlight 7 tips that will make it easier for you to find the right projects to contribute that will take your career to the next level and help you find a job.

1. Choose a project you care about

When looking out for a project, don’t just pick on any project in your favorite programming language and start working on it.

Contributing code to an open source project is a long term commitment you are making with that project.

Once you fix one bug or produce that one killer feature, you will be sucked deeper into the project. Building software is a process that doesn’t end when the feature is ready.

Related: Top 15 Best Coursera Courses & Specializations To Take in 2018

Choosing a project that solves a problem you actually care about will keep you motivated to continue building more features and remaining part of the team. It will keep you in the project for the long term.

The more you stay on a project, the more you learn about it and get to understand it deeper.

When you get a strong understanding of the software as a whole you are able to optimize the code you previously wrote for better and optimal performance.

2. Only consider active projects

You are seeking to learn a ton of stuff by writing more code on projects that matter. The last thing you want to realize after putting your time and energy into producing a feature is that the project was discontinued by the owner.

By the fact that the original coder who had the dream for this project abandoned it, it means it might have become less interesting or something.

So what’s your guide for identifying an active project?

Only consider a project that had the last pull request merged less than 2 months ago. A project owner that is encouraging contribution from git-hubbers will seek to respond to issues and pull requests in time.

A project that is alive needs to respond to feedback from users. If the last time someone was on that project was 1 year ago, then it’s most likely the owner of the project is not paying much attention to it anymore.

3. Take a project with few contributors

The more contributors there are on a project, the stricter the rules before you can get featured especially if you are beginner developer.

Strict rules serve to:

• enable you contribute better quality code
• make the community around the project more organized.

But when you are getting started you need a project that offers you a lower barrier to entry. In fact most of these projects will want to see your previous contributions elsewhere in order to asses your standards.

Definitely you haven’t contributed anywhere before so you are most likely at a disadvantage.

When a project is stormed  by many contributors, chances of conflict where people work on the same feature are high.

You might work yourself out building a feature only realize once you are done that another software developer built it yesterday and the pull request is already merge. Things can get a little messy easily. Not interesting for a newbie.

A pull request that got merged with the main project is just as exciting. It means people are picking up what you are doing! 

When you join a project with a few contributors, your presence will be highly appreciated even if you are a beginner.

Often than not you will find a small team more united and coordinated that a grand collection of coders. They will be willing to even help you with your code because they care about keeping you around and this will be a great opportunity to learn.

4. Take on small size projects

By small size projects I mean the size of the code base. You might think the size of the code base doesn’t matter because you will focus only on the feature that you are building.

The fact is, it’s not as simple as that.

In order to contribute effectively to a project you will need to understand how the whole application works.

You will need to have a proper understanding of among other things:

• the flow of logic
• the way input and output is manipulated
• error handling, and
• dependency management.

When you are a beginner developer, a single file with even 5,000 lines of code will be an outright intimidation.

It is very exciting to be mentioned as a contributor to a big project like the Django framework but your chances of getting such a shout out when you are a newbie are close to nil.

With a small project, you can go through the whole code base within a few hours and get to have a general feel of the flow of logic.

When a project has a small code base it is easier to figure it out when something breaks than when you are to deal with a monolithic code base with overs 100,000 lines of code.

After you have more experience collaborating on projects, you will have the confidence to face huge code bases because you shall have already understood how most applications are laid out, even if they use different frameworks.

But trying to prove this when you are a beginner will prove a real pain.

5. Don’t shoot for the popular projects

Of course you should shoot for the stars so you can land the moon.

In fact you want to contribute to a project that matters, a project that probably every hiring manager already knows about.

Popular projects, even if they have a few contributors sometimes, always impose high standards of code in order to maintain their quality, performance and pride.

After couple of contributions to less popular projects,  you’ll definitely be well placed to contribute to these popular projects. But before that happens, you need a starter project.

Most beginners write horrible code:

• without proper commenting
• without proper variable naming patterns, and
• poorly optimized

 

You need to make work easier.

The best way to make work easier is to get your skills honed by working on a more suitable project for the start.

Then you can come back when you are well baked. If your code is awesome, you’ll definitely be warmly welcome.

As I already mentioned above, popular projects have a higher barrier to entry than the less popular.

6. Visit the issue tracker first

You have now identified a project to contribute to.

You probably already have a idea what you want to build.

Maybe you have been using this software for sometime, which I highly recommend, and you know a bug you’d love to get fixed.

But, hold your racing horse a little bit.

Every open source project has an issue tracker. This is where feature requests and bugs are reported.

Someone probably has already reported your feature or bug. Chances are high another developer is already working on it.

You don’t want to work yourself out and then discover you duplicated the work of another developer.

If both of you have the exact same code solving the same problem, only one will be merged. So what’s in it for you if you were the one left out?

Take sometime to read through the issue tracker. Probably what you think is a bug is actually a feature of the software!

Often than not the community has already debated about it and closed it down.

So checking this out will really save you from spending you energy on what will never see the light of day.

I would advice that if you want to fix a bug or build a feature:

1. Go through the issue tracker.
2. Choose a bug or feature that has already been reported.
3. Pitch the project admin with the idea.

This way you are sure there are guys who will be excited about your new feature when you are done because they already requested for it.

Fixing a bug that has already been reported means many people probably have faced the same bug, so your efforts to fix it will really be appreciated.

And as a beginner this is a real ego booster!

7. Pitch the admin before you start

You have done your research, settled on a suitable project and chosen the bug you wanna fix.

So you are tempted to jump right in and kick the hell out of your way.

But wait:

One of the key pillars of a successful open source project that involves a collaborating  team is communication.

Get to know the project owner or the person who will finally merge your pull request.

Let them know what exactly you want to build and why.

These people are at a better place to recommend to you the features or bugs that really really need fixing.

They could as well be clearer to you as to which bug is already being worked by someone else and which ones are pending.

As a beginner, you will need the good will of these guys in order to find your way around with much ease.

Contributing to Github projects is a strong show of your capability when you are looking for a job with a reputable company. It’s well worth the effort.

As a beginner learning to code and a beginner to Github you are bound to face a few challenges, just like you’d while tinkering with anything new. But after a couple of tries you will become a star.

All you need is consistency and to put in the hours of work..

With these tips I hope you will find it easier to find you dream open source project and have a happy coding experience while building your software development career.

Have you worked on an open source project before?

What were your challenges when finding a suitable project?

Please share your thoughts in the comments below.