Seeing programming as a social activity changes how we build communities around programming. We should focus on building a community, and not on building a codebase, argued Ash Furrow at Craft. He suggested using a code of conduct, moving long or heated discussions into a Skype call or Google Hangout, avoiding fixing easy issues yourself, and distributing power and responsibilities.
Ash Furrow, senior engineer at Artsy, spoke about building open source communities at Craft 2017. InfoQ is covering the conference with Q&As, summaries and articles.
InfoQ interviewed Furrow about programming as a social activity, how you can promote empathy in open source communities, how to make it easier for people to contribute to open source, what can be done to recognize burnout early or prevent burnout of open source maintainers, and the benefits that organizations can get from open source.
InfoQ: You stated that "programming is a social activity". Can you elaborate?
Ash Furrow: Let’s think about what programming is. Programming isn’t just typing; it’s reading/writing documentation, asking questions, and reading/writing code. These are all forms of communication with people and not machines (code should be written for people to understand, and only incidentally for computers to execute). Communication is a very social activity, and I think sometimes programmers fail to acknowledge the important of communication within our field.
Seeing programming as a social activity changes how we build communities around programming; we should focus less on the code, and more on the community. And that’s going to require empathy.
InfoQ: How can you promote empathy in open source communities?
Furrow: Empathy is especially difficult to cultivate in online communities because we primarily communicate through text. Text has no nuance, it has no tone. That’s why I encourage maintainers to move long or heated discussions into a Skype call or Google Hangout as early as possible. Seeing another person’s face and hearing their voice helps us remember that we all want what’s best for the project.
A code of conduct can also go a long way towards letting people know that they’re welcome to participate in the community without having to worry about getting bullied or harassed. Software should be written for everyone and the only way that’s going to happen is if it’s written by everyone; that won’t happen unless we explicitly welcome folks who have historically been excluded from programming communities.
InfoQ: What can maintainers do to make it easier for people to contribute to open source?
Furrow: Focus on building a community, and not on building a codebase. Avoid fixing easy issues yourself, but rather create a new GitHub issue and label it "fit for newcomers" so someone else can feel good about fixing it. When someone opens an issue, thank them.
Sometimes, you’ll disagree with a community member. When that happens, I like to use the LARA approach: Listen, Affirm, Respond, Add.
- Listen – reread what they wrote and give them the benefit of the doubt (pretend your best friend wrote the comment).
- Affirm – find something you agree with and say so.
- Respond – keep the discussion civil and kind.
- Add – facts, counterexamples, a reference to the project vision document.
InfoQ: You mentioned the risk of burnout for open source maintainers. What can you do to recognize burnout early or prevent burn out?
Furrow: Distribute your power and responsibilities as early as possible. That means giving people rights to merge pull requests and review new issues. It means adding contributors as owners to your Ruby gem or CocoaPod. And it means protecting your master branch from force pushes.
Ideally, an issue could be reported, diagnosed, and fixed without your involvement at all.
InfoQ: What benefits can organizations get from open source?
Furrow: Organizations can benefit in a few key ways. First: reputation. As an employer, you can’t have enough reputation, and contributing back to open source helps you get that. Reputation will attract developers to your company, and keep them there. Next: free training. If your open source code is popular, then new hires will probably already be familiar with it. Finally: free contributions. With more eyes looking at your code, and more developers using it in production, you’ll get new ideas for features, QA testing, bug reports, and pull requests that improve the code – all without having to pay anyone.
As an aside, I believe working in open source environments helps engender a culture of curiosity and of learning from mistakes. These attributes are linked to psychological safety within an organization, which leads to happier employees and more productive teams. So open source can help your team write better code, faster, and with fewer bugs. And they’ll feel great too. Win-win.