Peter Elbaum|
11.07.18 |CodeInsights

Navigating the Highs and Lows of Open Source

all things open

code

development

open source

tech

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:

Get Started

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.

A common question is “How do I get started?” or “What’s the best project for me to contribute to?” One of my favorite people in the JavaScript world is Kent C. Dodds, in large part because he goes out of his way to teach and make programming accessible to beginners. He wrote a blog post on this very topic, to which his answer is:contribute to something you use. He also mentions that the first contribution is the hardest, which is all the more reason to get started today.

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:

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/x3NwPhwC8fpic.twitter.com/rW31tFi5bM

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.

Fail Fast

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.