The Beginner’s Guide to Open Source, Part 1: How to Start Contributing to Open Source Projects

This is part one of a four-part series on getting started with open source projects. Check back for new parts in the following weeks.

Most modern software developers depend heavily on open source tools and libraries. But relatively few of us contribute back to open source. It's not difficult to support the open source projects you use every day, and the efforts you make will have tangible effects on the quality of that software.

Have you ever wanted to contribute to an open source project, but didn’t know where to start? It's not uncommon to look at a project's code on GitHub, feel overwhelmed by the complexity, and want to dash away. If you feel this way, you shouldn’t.

Successful open source projects thrive on a wide variety of contributions from people with all levels of coding skills and commitment. Any time someone fixes a compiler warning, closes a bug, or adds to the documentation, progress is made. Put a lot of those contributions together and great things can happen.

So, ready to get started? First, consider what you can do to contribute to the projects you already use every day. If you do any programming these days, chances are you’re using open source projects. Languages like Ruby and Python and frameworks like React and Node.js are all open source projects. The developer tools you use are probably open source as well. The Atom editor, Eclipse IDE, Nginx, and Apache web servers are open source, as are the Tomcat and Jetty Java servlet containers. In fact, we have a number of open source projects here at New Relic.

Start by contributing to the projects you use every day; the projects you're most familiar with will be the easiest to get involved in. Here are five ways you can get started on your own.

1. Report a bug to the project's issue tracker

Reporting an issue to a project’s issue tracker, such as GitHub Issues, is one of the easiest ways to support the open source projects you use. Most open source projects have iso trackers–typically using something. Sometimes when we discover a bug in software, we're in no mood to go out of our way to report it. We want to work around the problem and move on. That's fine, but be sure to report the bug as soon as possible while it's still fresh in your mind. Report all the details you can about showing the bug's behavior and explain it just like you'd want a user to explain a bug to you.

Sometimes, of course, the bug isn't even in the code, but in the documentation. Maybe you’ve come across an out-of-date reference to a feature that no longer exists, or even just a typo. These documentation bugs are just as real as bugs in code, and they should be reported in the issue tracking system.

But most bug reports received by open source projects are terrible. They’re often one-liners that vaguely describe a problem and don't provide details about how it happened, where it happened (which browser, which OS, what type of device, and so on), or provide any steps to reproduce the bug.

This gives you two great opportunities to contribute in a way that gets you noticed and genuinely helps the project.

First, if you encounter a bug in an open source tool you're using, document it as thoroughly as you can. Include details like OS, browser, device type (mobile/desktop/laptop). Include detailed steps to reproduce the bug, and add screenshots if possible.

Next, try to reproduce, verify, and document bugs discovered by others. Follow the same steps you'd follow when reporting your own bug. See if there's any new information you can add. You might add a comment like, "I found that calcScreenResolution() only shows this behavior in Chrome, but not Firefox." Details like that can be a huge help to developers working to solve the problem. This turns terrible bug reports into detailed, actionable information the project's developers can use.

If the project accepts one of your bugs as a valid issue, offer to fix it, and ask what they'll expect in terms of unit tests to verify the bug is fixed. This can be a great way to contribute your first code to a project because you're not just reporting a problem–you're also offering to solve it.

2. Volunteer to write documentation

Precious few developers are eager to write documentation, but it’s critical to the success of open source projects. What’s the first thing you look for when exploring a new project? The documentation. And what’s the first thing you look for in that documentation? Examples of how to use it.

But starting out writing code when first joining an open source project can be a challenge. It's often tough to contribute code until you've taken time to understand the codebase, its coding conventions, and testing requirements.

Writing documentation helps you learn the codebase–you'll often need to read and understand the code you're trying to document. This gives you a sense of how the project hangs together and how the code works.

Documentation can be a good starting point because it's a sore spot for many open source projects.

And don't overlook the social aspect. Open source projects commonly have senior developers who own part of a project's codebase. These owners aren't always friendly to outsiders. Writing documentation gives you a chance to get to know the developers working on the project, and gives them a chance to get to know you.

So when you're ready to make your first code contribution, it won't be coming from an outsider. It'll be coming from that brave person who dove in and wrote the docs nobody else wanted to write–and the rest of the team will be happy to help you get your first code pull request accepted.

3. Attend a (virtual) meetup

There’s no higher bandwidth medium for the transfer of knowledge than face-to-face at a meetup or user-group meeting. If you’re close to a city of any size, chances are there are several meetups or community events nearby.  Meetups are typically free to attend and cover all sorts of technical topics. The bigger your city, the more likely you are to find more specific topics, while smaller cities will have more general meetups.

In 2020, however, we've had to quickly adapt to a world where we can't meet up in person.

This presents challenges, but also offers opportunities. While we can't meet face-to-face, we can attend virtual meetups. Virtual meetups provide the chance to talk to project contributors from around the world–an opportunity that wasn't always available before.

Virtual meetups let you introduce yourself to a project's contributors. You’ll have a chance to express your interest in contributing, explain your skill set, and ask the project members to suggest a good starting point.

Asking a project's leaders what they need is often the best way to get started. Virtual meetups are the ideal place to do it because it's the easiest way to communicate with project leadership directly.

Posting messages online can work, but there's a lot more noise. It's easy for your question to go unnoticed in a busy forum or get lost in the project lead's overflowing email inbox.

4. Blog, tweet, and answer questions online

You don't have to contribute to a project directly to help it.

Most developers have solved tough issues they’d faced with an open source library. Next time it happens, write a blog post about how you solved it. You're probably not the only person who had the problem, so sharing your solution helps other people who use the library.

Write something in your blog about how you’ve used the software, especially if it describes a problem you had and how you solved it. Writing up the story of your problem and solution adds to the project’s body of knowledge, even if it’s not part of the project’s official documentation.

Next, check for people asking questions about open source libraries on sites like Stack Overflow, the preeminent Q&A site for programmers helping other programmers. If your expertise runs more toward server administration, StackOverflow’s sister site Server Fault is a great place to help contribute your knowledge. Answer any questions you're able to help with.

Of course, many projects have their own dedicated forums, mailing lists, IRC, and Slack channels. Sign up for one and see how you can help. The newbie you help today may contribute something that you end up using in the future.

Finally, if you find an open source library you love, or an open source tool that saves you a ton of time, Tweet about it! Let the world know, and help the project grow its user base.

5. Start with issues for new contributors

Some open source projects are very organized and specifically designate certain bugs and feature requests suitable to new contributors.

For projects that have a good list of beginners’ issues, browse through the features, and pick the simplest one you can find–even if it seems too simple. Solving it will likely end up being more complex than you're assuming.

Express your interest in fixing the issue, and wait for the project to assign it to you.

Before you start writing code, be sure to review the project’s coding standards and testing requirements thoroughly. Look in the project’s source tree for a document called “README” or “CONTRIBUTING”—they’re aimed directly at you. Do everything you can to make it easy for your pull request to make it through code review on the first try. Project maintainers get frustrated by low-effort contributions, and a lot of pull requests are rejected for unforced errors like missing unit tests.

Once you’re confident you understand what’s needed, get to work on fixing the issue!

Don’t be afraid to communicate

Projects always need help on all sorts of tasks you might not think of, from updating the HTML on the project website to writing articles to updating the site design, to simple mechanical tasks like updating all the copyright dates in the source files. If the project doesn’t have things laid out in a handy document, you may want to announce publicly that you’d like to help and ask for pointers.

Let others on the project know that you’re available, and give them an idea of your skills. Join the project’s developer mailing list, visit the associated Slack or IRC channel, or even take to your own Twitter account.

No matter what your background or experience level, chances are there’s something you can do to help your favorite open source project. Start with a few small steps to dip your toes in the water, and pretty soon, helping the open source community will become an everyday part of your life as a software developer. And open source software will be better for your contributions.

But different projects have different needs. If you're interested in an open source project, spend some time in its community and get a feel for how the project works. Then you'll be in a good position to determine the best way to start contributing.

And most importantly: have fun! You’re giving back to the open source community and building new skills–but it’s important to enjoy contributing to open source if you plan to keep doing it over the long term.

Want to contribute to an open source project at New Relic? Check New Relic Open Source and start contributing today.