Sumana Harihareswara and Maria Naggaga gave back-to-back talks at OSCON 2016 on how we can build our open source communities in such a way that contributors feel safe and loved.

First, recognize that people participate in open source for many reasons. Some of us are lucky enough to get paid to work on it, others are doing it for a school project, and others are doing it just for fun or for the passion of the project. Start by looking at your project as an outsider and try to think about what they might find discouraging or not helpful. There are things in our projects that can be alienating. Evaluate these weird things in your projects and decide if you want to make changes or not.

What not to do

Are people afraid to share their code in public? Help them get over that by offering support and documentation.

Are there personal differences that are important to an individual? Betsy Leondar-Wright writes in this article that it’s rarely essential to impose one’s personal choices on others. A story shared by Aurynn Shaw also talks about personal preferences by identifying the problem of being highly critical of other programming languages. 

It’s 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn’t feel welcome, and I’d have learned that the idea that the Python community is welcoming wasn’t true.

I’m tired of calling people out again and again for dumping on PHP.

I’m tired of people dumping on Windows, that most popular operating system, because it’s not what we choose to use, tired of the fact that we don’t make it easy to use our tools and teach them how to move, when they’re ready.

We need to keep this kind of infighting in check. Just because it’s not what we like/believe, it doesn’t mean we should exclude community members because they don’t like what we like. It’s essential that we be encouraging in getting people off of proprietary software by providing tools to let them use what they want in the short term. It’s not essential to make people feel bad about a really hard transition they haven’t made yet. If you ask a new potential ally to change their entire lifestyle at once, you’re going to lose them.

Everyday in open source we tell people they have to learn a new language (the command line) and a new skill (open source software). Sumana (who had so many great references for us) encouraged us to read an article that addresses this controversial topic (command line versus GUI). And, one professor argues that computer science students who are trying to do their research are getting frustrated because of the command line.

What to do instead

Anytime a user gets hassled of tripped up, treat that as a bug report.

Look out for advice you’re giving new users that has the word “just” in it; this word can be passive aggressive and turn off potential contributors.

Try to avoid asking contributors to learn new simultaneous skills.

Talk to your users. Ask people who have shown up once or twice and disappeared how you could have made your community more welcoming and appealing. Maria reminded us that friendly feedback keeps people interested. Send a note to a new contributor, like this: “Thanks for participating. To learn more and please check out this post! And please come back!”

Create a code of conduct. People need to feel safe in your community.

Create good documentation. It is a key in being inclusive. Remember to write for everyone, not just yourself! Offer videos and images on the repos so that people can see what the results are supposed to look like. We need a good starting point that allow people to be fearless in jumping in to our projects. Some tools to take a look at are:

Create a cheat sheet for your new users. For example Maria loves this one for Git.