It’s almost 2017!

Over the last year, we launched an app to help professional developers learn something new every day. We ended our beta and launched properly this summer, and over 200,000 developers joined us. Towards the end of the year we started to add help for newer developers, too.

We’ve spoken a lot to the people that use Enki, and one common question was “how can I get more involved in open source?”. Many people wanted to contribute for the first time but were unsure how; others were just nervous and intimidated by open source in general.

So, we’ve made it our New Year’s Resolution to help as many developers as possible contribute to Open Source in 2017, and we’re building some tools to help.

If you’re interested in being notified when these tools are available, whether you’re a newbie to open source or a more regular contributor, sign up here: http://opensource.enki.com

How to contribute to open source for the first time

Contributing to open source for the first time can be quite intimidating, but the only way to test if the water is warm is to dip your toe in.

Finding a Project

The first step is finding a project. Here are some tips on things to consider when looking for a project:

You should be excited by the project. It is much better to contribute to a project you use or like. If you’re not interested in the project you’re working on, it’s harder to stay motivated and there’s less chance you’ll find the challenges rewarding.

It is much better to contribute to a project you use or like. If you’re not interested in the project you’re working on, it’s harder to stay motivated and there’s less chance you’ll find the challenges rewarding. You should contribute to a project that is looking for help. Some projects aren’t looking for contributors. For early open source contributions, try to stick to projects with a contributing guide or that are tagged and noted as looking for help.

Some projects aren’t looking for contributors. For early open source contributions, try to stick to projects with a contributing guide or that are tagged and noted as looking for help. You should contribute to a project that is still active. There are a lot of abandoned projects out there. Let’s save reviving repos for another day.

There are a lot of abandoned projects out there. Let’s save reviving repos for another day. You should only contribute if you’re happy with the licensing. It’s certainly worthwhile researching what you’re comfortable with when it comes to licensing before you jump into a project.

With this in mind, head on over to the following resources:

Up For Grabs — collects projects that are actively looking for and requesting help. View projects by language and explore tagged issues requesting help.

Issue Hub — browsing items tagged ‘help wanted’ on Issue Hub also shows projects requesting help, with additional tags showing issues that are suitable for beginners.

Open Hatch — search tools to find open source projects you can join, and interactive lessons to practice if you can’t find one you like.

First Timers Only — twitter feed that posts issues available for first time open sources contributors only.

If you’re a more regular open source contributor, here are some resources that you may find useful to find projects:

Code Triage — an issue in your inbox every day, from your favourite projects.

Pull Request Roulette — roulette of pull requests to open source projects waiting for a reviewer.

Once you’ve found a project you like, it’s time to dive in to your new life as an open source developer.

Making a Contribution

Even the smallest contribution can ramp up your confidence — a large part of the hurdle is not the implementation of a feature or of a bugfix, but actually learning how to contribute. You can do this with smaller contributions and build up your confidence towards submit code.

Track issues. If you find a bug in an open source package, report it into the project’s issue tracking. Once issues are reported, others can get to work on fixing them. A thorough and detailed write-up can be extremely helpful for the project maintainers.

If you find a bug in an open source package, report it into the project’s issue tracking. Once issues are reported, others can get to work on fixing them. A thorough and detailed write-up can be extremely helpful for the project maintainers. Verify issues. If you haven’t found a bug yourself, you could instead check the issues available and help improve the existing ones. Reproducing a bug, or failing to reproduce a bug, on different operating systems can provide additional information about a problem to the project maintainers. This can be invaluable to the developers trying to narrow down the cause of a problem.

If you haven’t found a bug yourself, you could instead check the issues available and help improve the existing ones. Reproducing a bug, or failing to reproduce a bug, on different operating systems can provide additional information about a problem to the project maintainers. This can be invaluable to the developers trying to narrow down the cause of a problem. Add documentation. The documentation is the first thing people come across when using a new project. If you’ve been using an open source project, consider adding examples of use to the documentation. Practical examples and thorough documentation can help new users understand projects much more quickly.

Your first Pull Request

If you’re ready… dive in to submitting code. It’s a simple process:

Read the contributing guidelines for the project.

Fork the repo and get the project working locally.

Claim the task you’d like to work on.

Get to work on your PR.

Here is a great resource by Dean McDonnell for a more in depth step-by-step contribution process. Highly recommend following his guide if you’re feeling unsure about any of the steps.

Open source is a challenge, but it is also fun, rewarding and highly educational. It’s a great way to learn more about projects you use, and work with exceptional developers around the world. Everyone in open source started out the same way, so disregard your doubts and fears and get to work on your first open source PR in 2017.

Oh — and if this post wasn’t enough help, here’s a useful and free video course by Kent Dodds: How to contribute to an open source project.

And once again — if you’re interested in being notified about our tools to help with open source contribution, head on over here: http://opensource.enki.com

Happy new year!