Working in the open source community can be a fulfilling experience. Helping others is fulfilling, after all. There are also material benefits to open source participation, but I’d wager most open source contributors volunteer because they enjoy it.

So if people do open source because it makes them happy, then the joy that they experience is important. Happiness drives open source, and by extension, the entire tech industry. We need to protect it, and help it grow.

Justin Searls has a great presentation called The Social Coding Contract that I’d highly recommend.

Turns out that the most important part of open source isn’t the code, it’s empathy. And it’s difficult for empathy to thrive in a community that mainly communicates through text.

If someone makes a mistake, like opening a duplicate issue, it’s important to be gentle. This is probably a beginner, and they probably didn’t know that they should look for existing issues before opening one.

The problem of text-based communication is that there is no tone: beginners often interpret the tone of messages from existing contributors to be negative. Well-intentioned library maintainers can inadvertently hurt a beginner’s feelings.

The beginner feels hurt and ashamed. Open source looked fun but it wasn’t.

They don’t want to contribute anymore.

On the internet, there is no such thing as “neutral” – your words are either interpreted as praise or as criticism. A library maintainer holds a position of respect from a beginner’s perspective; that praise or criticism will be amplified.

The solution is to be really positive in text communication, especially when replying to someone who seems to have made a mistake. It sounds like a lot of work, but being gratuitously positive only takes a few easy steps.

To improve beginners’ open source experiences, I offered my services as Copy Editor Extraordinaire to help the CocoaPods team make their boilerplate responses gratuitously positive.

These responses are pre-written and posted to issues that appear to be opened in error. They’re often the first contact a beginner has with a CocoaPods team member.

Consider the following, original response.

Hey there, thanks for your report. I’ve moved this issue over to { here } for a bit better organisation.

Thanks!

Great work, CocoaPods! The “Thanks!” at the end is a fantastic example of effective exclamation points. Let’s keep going even further and add one to the first sentence. Everybody loves exclamation points!

Hey there, thanks for your report! I’ve moved this issue over to { here } for a bit better organisation.

Thanks!

Awesome!

Let’s look at the next boilerplate response.

Hey there, thanks for your report. I’m going to close this issue since we already have one for it { here }. Please try to search existing issues / try the latest version before filing issues.

OK, cool cool. We’ve got a good base to build on. Let’s add our customary exclamation point to the opening sentence and see what we can do…

Hey there, thanks for your report! It looks like this issue is already open { here }. If that’s not right, just re-open this one. And remember, try to search existing issues / try the latest version to see if an issue has already been filed 😄

This is a lot more positive. Instead of “I’m going to close this because you made a mistake”, I’ve rephrased it to “I think this might be a duplicate, but I could be wrong, so let me know if you disagree.” Instead of “please try to do this thing before trying to help”, I’ve rephrased it to a customary, nearly perfunctory “always remember, kids, to play safe!”

And emojis never hurt 🎉

Let’s take a look at the last one.

This was fixed by { commit } and is in the { version } release.

Please search existing issues / try the latest version before filing issues.

Yikes! No greeting, just a matter-of-fact “this is fixed” and a reminder to not make the same mistake again.

Think about the power dynamic between a potential beginner and a library maintainer – from a beginner’s perspective, this could seem really harsh!

Let’s start over. We need to tell them that we think it’s fixed, and remind them to search for existing issues.

Hi there! Looks like this was already fixed by { commit } and is in the { version } release. Let us know if you’re still experiencing this problem, and don’t forget to search existing issues / try the latest version to see if an issue has already been fixed 😄

Awesome! Establish a friendly tone, let them know where you think the issue was fixed, and add a gentle reminder of how to be a good open source citizen.

And again, emojis never hurt 🎁

Remember, there’s not such thing as “neutral” text communication, so err on side of positivity. Avoid neutral language. Over-compensate by being extra nice.

These are examples of small changes you can make in the way you communicate with other developers that avoids hurt feelings – it costs nearly nothing, helps beginners build confidence, and to be honest, it feels nice to be nice!

Orta recently gave a talk called Being Nice in Open Source. I recommend you watch it. He gives a list of examples of ways to be nice in open source, and the benefits of being positive.

We all have the opportunity to make everyone’s experiences in open source just a little bit better.

Let’s choose take advantage of that opportunity!

Let’s be nice!