32
loading...
Contributing To Open Source - Getting Started
Contributing to open source projects can be very fulfilling, but getting started may be intimidating and confusing. Most large open source projects have steep learning curves which can be off-putting for the first-time contributor. However, there are a lot of opportunities to get started and thrive, even if you’ve never contributed to an open source project before.
Open source is incredibly valuable. Where would the Linux kernel be without the 13,500 developers and 1,300 companies that have contributed since 2005? And what of the thousands of projects built on its back?
These days, every project you start is built using packages and building blocks from those who came before you. You can stand on the shoulders of giants. The wheel has already been invented, and it’s more reliable and battle-tested than anything you could build in-house. Open source software has been essential for developers, companies, and, ideally, consumers.
However, there would be no giants, no blocks, no wheels without communities, contributors, and passionate people to drive these projects forward. These are ordinary people doing extraordinary things.
Although the main objective of open source is to create accessible and valuable software for everyone to build off of, contributors can find a plethora of personal benefits from contributing. You will sharpen your technical skills, nurture your interpersonal communication skills, and practice giving and receiving feedback.
Okay, so you’ve decided you want to become a contributor but you’re not convinced that you’ve got what it takes. You’re feeling quite intimidated actually. That’s okay. You’ve never done this before. Every contributor has had a first contribution and open source projects tend to culture empathy, patience, and understanding.
In my experience, successful open source projects have maintainers and communities that are the friendliest on the planet. They are excited and enthusiastic about someone wanting to contribute. Often they’ll be active on Twitter, Slack, Discord, and/or another platform that you can join and speak directly with the maintainers and other contributors. Many large open source communities even have their own community guidelines that boil down to “Don’t be a jerk”. These communities welcome new contributors with open arms.
One of the best ways to find an open source project to work on is to look to open source software that you already use. Tools, packages, frameworks, or languages that you work with regularly and enjoy using could be great candidates. To find out if the project is open source, check its license and if it accepts contributions. It’s also important to check that the project is actively maintained. Are the pull-requests sitting dormant or are the maintainers providing feedback? Are the issues getting acknowledged or are they sitting there stale?
If that approach doesn’t work for you, try using GitHub to explore. I recommend starting your contribution journey with languages and frameworks that you’re familiar with. It’ll be difficult enough to get up to speed on the codebase, but if you’re already familiar with a framework’s best practices and typical layout, you’ll have a more successful time hitting the ground running.
GitHub has excellent search capabilities to find open source projects that are actively seeking out new contributors. By searching for the right tags and filtering by languages you know best, you can quickly find new issues that beg for assistance. Some great tags to search for are:
GitHub also suggests projects you may like based on the people and repositories that you have starred, follow, or watch.
Once you find an issue that you feel confident in tackling in an active project that has a culture you feel comfortable in, it’s time to get your hands dirty! The first thing you will want to do is to “claim” the ticket. It’s a bad idea to run off and solve the problem without communicating your intentions to the maintainers. Instead, reply to the ticket in question by volunteering yourself for the task. This allows the maintainers and other contributors to know this ticket is being actively worked on and the maintainers may have requests, suggestions, or guidance to help solve the problem.
Start small. Pick tickets that are easy and have the smallest contribution and code changes when you first start. Not only will this enable you to slowly get familiar with the codebase, but it will also build your confidence and credibility before you try taking on harder tasks.
After you have picked up a ticket and think you have finished it, do your research before you open your first pull-request. Carefully read the documentation, code, and discussions related to this ticket to get the best understanding of how to handle the problem. If you’re stuck, reach out to the community and ask for guidance, clarification, or mentorship.
Once you feel confident that you’ve solved the problem, it’s time to submit a PR. Look in the project for a CONTRIBUTORS.md file--most open source projects on GitHub will likely have this within their project. This file will contain instructions on how this project would like PRs to be submitted by contributors. They may request strict branch naming conventions, PR titles, documentation or tests, comments, or other things in pull-requests. GitHub also has a great checklist on what to check for before you open your pull-request.
Create the PR and follow the PR template if the project has one. Be sure to link back to the original ticket. The maintainer may request changes or want to have a discussion about your changes. It’s normal to have a back-and-forth before a PR is accepted. Work with the maintainer until your PR is ready to be accepted.
Once your PR passes the maintainer’s review, they will merge your code in.
Congratulations! You’re an open source contributor!!
Open source projects benefit dramatically from Ephemeral Environments on every pull-request. We love open source and are dedicated to giving back. Contact us to find out how we can help fuel your rocket through preview environments and help put confidence in contributor’s PRs.
32