A note on the importance of empathy when communicating on GitHub: Do not assume intent when you read an ambiguous comment. Most likely there is none. You can have better conversations if you make your text-only communication less ambiguous. https://t.co/x3NwPhwC8f pic.twitter.com/rW31tFi5bM
— Igor Minar (@IgorMinar) February 21, 2018
Most developers are encouraged to contribute to Open Source Software projects. For many, the process of working on open source has its share of ups and downs. You open yourself up to learning, skill growth, giving back and collaborating with people the world over. But you can also run into personality conflicts and the difficulty of contributing in a crowded space.
How does one navigate these fluctuations? How does one even begin to contribute to OSS, or know which project to pick?
I explored these topics last week in a talk at All Things Open. I covered how to get the most out of contributing to open source while providing the most value for projects. As part of the 101 track, the talk was oriented to beginners. It explored several ways to start contributing, and strategies for dealing with some of the more difficult aspects of doing so. These strategies come from a case study of my own early contributions to open source. Here are a few takeaways for those that want to get started in open source software:
I’ve found that the hardest part of doing something intimidating is getting started, and open source is no exception. It can be paralyzing to consider all the possible projects and ways to contribute, not to mention that most have a particular process for submitting a Pull Request.
Assume the Best of Others
There are two realities that contribute to conflicts in open source (and other contexts as well). First, written communication is most common. Second, text is a terrible medium for important nuances of communication such as tone, body language and facial expression. Angular core member Igor Minar tweeted a few days ago about this occurrence:
It’s easy to misinterpret text, especially if we’re feeling sensitive or insecure. Though sometimes people intend to attack, assuming the best of others will ultimately lead to the most harmonious and productive working relationships.
Use Pre-Existing Skills
One misconception is that contributing to open source software is all about writing code. It’s not. Open source projects need a lot of help aside from contributions to the codebase. That’s great news! It means that more people can get involved. Projects need people with skills in writing, editing, social media, community building, foreign language and design, among others.
Two of my first contributions to open source had nothing to do with code. My first contribution was translating part of the React documentation to Spanish. My second contribution leveraged my writing skills to produce a screencast outline for Operation Code, which is an organization that connects veterans with coding education.
Many people have skills that would enable them to immediately contribute. What’s more, a community of people with varied backgrounds has a richness and diversity in perspective that would be lacking otherwise. Open source projects need people with all kinds of skills.
This is the hardest piece of advice to accept, but the one with the biggest personal payoff. I’ve found making mistakes is one of the best ways to learn. Learning this way is usually painful, and a public forum such as GitHub (which houses many open source projects) could heighten that feeling for some. That said, making mistakes is part of deliberate practice. This is the part of performance theory that states that you get better by continually and systematically stretching your comfort zone. Simply put, that painful feeling of figuring something out for the first time is the feeling of getting better.
Well-maintained projects have defined contribution processes with plenty of checks and balances, so there’s no need to worry about a bug getting through. People are typically nice to beginners, but if you come across a troll or a toxic community, don’t be afraid to take your talents elsewhere.
Anything worth doing is hard. Hard things don’t come easy at first. Contributing to open source software is worth the pain, and now is the best time to start.
Find my slides from ATO here.
Peter Elbaum is a software engineer for Smashing Boxes, specializing in Angular, React and Redux.