I asked on Twitter what advice experienced contributors would give to newcomers in open source. This post features some of the best advice people shared specially for you, in a step-by-step process to help you overcome initial barriers and feel confident about your first contribution.
Open source software is already integrated into our daily lives, even more if you are working with IT. A recent research about open source usage shows that 66% of companies will first look for open source solutions before considering any other options – it’s became the default option, for a number of reasons: more stability brought by collaboration and team work, transparency, and the possibility of suggesting new features and improvements at any time, by contributing with a pull request. This also explains why more and more companies are getting actively involved with open source nowadays.
Many are the real benefits of engaging in open source, but how hard it is to get your first contribution out there? What are the best ways of getting started, and what should you expect as a newcomer? How to make the most of this experience?
To answer these questions, I asked on Twitter what advice experienced contributors would give to newcomers in open source. This post features some of the best advice people shared specially for you, in a step-by-step process to help you overcome initial barriers and feel confident about your first contribution.
Overcome the Fear of the First Time™
I know, I know – it’s normal to be afraid. The contribution itself (code, documentation etc) is actually the easiest part of the whole thing – getting the pull request out there is the real challenging part, since you will be exposing your content for review. But you should always remember that all those people who are into open source had their fears when they did it for the first time, too. It’s natural and you can overcome it! If you want to know how I did it, check this post I wrote on dev-human.
— numerodix (@numerodix) September 25, 2015
@erikaheidi Don’t be afraid. You’re starting a discussion.
— David Yell (@YellDavid) September 25, 2015
@erikaheidi don’t be scared – everyone had his first contribution
— Marcel Pociot (@marcelpociot) September 25, 2015
@erikaheidi Don’t be afraid, my experience was more often than not having friendly people helping you with it
— Christian Müller (@daskitsunet) September 25, 2015
@erikaheidi don’t be afraid of feedback and take “tone” with a pinch of salt.
— James Brooks (@jbrooksuk) September 25, 2015
@erikaheidi “Don’t be afraid to ask for help.” If you’ve never done a PR, it can be strange and weird, until somebody shows you how.
— ?? ??? ??? (@bopp) September 25, 2015
Choose a Project
Once you are motivated to start contributing, comes the hard task of choosing a project to submit your first pull request. How to choose one? Well, the most important thing here is that the project needs to be welcoming for first-timers, so they will help you in the process. Another good criteria is to choose something you actually use – this will give you a better background on the software and how you could help improving it.
— Yamila Moreno (@yamila_moreno) September 25, 2015
@erikaheidi Contribute to a project that has welcoming maintainers, browse closed issues to see interactions w/ contributors and maintainers
— Joe P Ferguson (@JoePFerguson) September 25, 2015
@erikaheidi contribute to something you use. Living with your code is a great way to gain experience.
— Stuart Herbert (@stuherbert) September 25, 2015
@erikaheidi Start using open-source; the best contributions are those we know that are important because we’re really using the project.
— João Batista Neto (@netojoaobatista) September 25, 2015
— vinney cavallo (@vinneycavallo) September 26, 2015
@erikaheidi the smaller projects. big projects are too intimidating for newcomers. I love the Particle libraries for instance
— skoop as a service (@skoop) September 18, 2015
Read the Docs
Open source projects usually have a Contributing doc with specific guidelines for making contributions. It is important that you know these guidelines to avoid frustrations later – it’s no cool to get a pull request with code that is clearly out of standards, or doesn’t follow the project ideology, or something else that you should already know because it’s in the docs.
@erikaheidi Read the CONTRIBUTING[.md|.txt] of the project and don’t be afraid to talk to others 🙂
— FooBarbe (@lovenunu_) September 25, 2015
@erikaheidi Follow the code style, naming conventions, and such used in the rest of the codebase.
— Raymond Moul (@rmmoul) September 25, 2015
— Unknwon (@joe2010xtmf) September 25, 2015
Choose an Issue
Start small: this was undoubtely the most common piece of advice people shared – getting started with small contributions makes the whole process simpler, less stressfull, and it’s a great opportunity to get acquainted with the tools of the trade. Documentation, tests, typo fixes – any contribution is a valuable contribution! Also, it’s a good idea to follow YourFirstPR on Twitter – they are constantly showcasing starter issues on Github, specially for beginners.
@erikaheidi start small. Fix a bug or documentation. Don’t feel you have to jump into something bigger than you’re comfortable with.
— Matt Brunt (@TheMattBrunt) September 25, 2015
@erikaheidi as most have said – start with documentation and testing and bugs – don’t do huge rearchitecting as your first contribution!
— auroraeosrose (@auroraeosrose) September 25, 2015
@erikaheidi documentation is a good start. Also, small fixes helps you get noticed. Don’t jump big without talking with core team.
— Alfredo Juárez (@alfrekjv) September 25, 2015
— Tom Berger (@intellectronica) September 25, 2015
@erikaheidi Small contributions are valuable contributions too!
— net cat (@zeigenvector) September 25, 2015
@erikaheidi Find a project that solves a problem for you, use it, find problems with it and contribute fixes. Small fixes are great!
— taotetek (@taotetek) September 25, 2015
Good communication is essential in any team activity. You should try to communicate with the project maintainers since the very start, before getting any contribution started, to avoid frustrations and time spent on changes that won’t get accepted. When proposing a change, also, it’s important that you explain in details what was changed and why.
@erikaheidi Communicate early and often.
— Michelle (@michellesanver) September 25, 2015
@erikaheidi Listen first.
— Cal Evans (@CalEvans) September 25, 2015
@erikaheidi never stop asking questions, no matter how simple or stupid they sound.
— PHP Berkshire (@phpberks) September 25, 2015
@erikaheidi “Don’t be afraid to ask a lot of questions”
— alganet (@alganet) September 25, 2015
@erikaheidi Don’t code blind: talk to authors/contributors of the project you want to work on: tweet them, join IRC channels, ask questions!
— Steffan Harries (@Bendihossan) September 25, 2015
@erikaheidi explain your change with *lots* of detail ????
— Taylor Otwell (@taylorotwell) September 25, 2015
Just Do It!
When you have a project and an issue to work on, it’s finally time to get it done! If you need help with Git and the Pull Request process, don’t be afraid to ask the project maintainers. Also, check this excellent guide by Rob Allen explaining how to create a pull request on Github. A more in-depth guide can also be found on this post from Dean McDonnel: Getting into Open Source for the First Time.
@erikaheidi Patience and braveness. Do your best each time your do a PR, and that should be enough.
— Marc Morera (@mmoreram) September 25, 2015
@erikaheidi It doesn’t have to be perfect in the first PR, it just opens the door
— Chris Cornutt (@enygma) September 25, 2015
— Christopher Hamilton (@39digits) September 25, 2015
And If Things Don’t Go as Expected…
There’s always a chance things don’t go as expected, but you should not feel frustrated or discouraged – remember the world of open source is not always perfect, and not all projects have great and welcoming maintainers. Also, even good ideas and good implementations can be rejected by some project maintainers – they have the right to do so if they want to. If you had a bad experience in your first contribution, don’t give up – I promise you, for every not-so-friendly project out there, there are at least 5 amazing projects that would love to get a contribution from you.
@erikaheidi A not accepted PR doesn’t necessarily mean that the code or idea was bad.
— Claudio Zizza (@SenseException) September 25, 2015
@erikaheidi also, don’t forget some people are assholes
— Gary Hockin (@GeeH) September 25, 2015
@erikaheidi Don’t give up just because someone treats you like shit. Firm and polite persistence pays off.
— GrumpyPower9 (@grmpyprogrammer) September 25, 2015
— WhereMyContainers@ (@DoerteDev) September 25, 2015
Do you have any other advice for people who are getting started with open source? Sharing is caring – open source it in the comments! 🙂