3 big steps toward building authentic developer communities

How do you build community while also meeting the needs of an organization? These three steps can help.
325 readers like this.
A community building a barn

Opensource.com

As more software businesses are selling open source products, we've seen a corresponding rise in the emphasis of building out developer communities around these products as a key metric for success. Happy users are passionate advocates, and these passionate advocates raise overall awareness of a company's product offerings. Attract the right vocal influencers into your community, and customers become more interested in forming a relationship with your company.

Doing community building the right way, however, is a delicate balance. Undercut the needs of your user community in favor of driving sales, and your company will face a decrease in adoption and unfavorable brand awareness. Meanwhile, too little focus on the bottom line isn't good for the company. So how can this tension be balanced effectively, especially in a world in which developers are the "new kingmakers" and meeting their sensibilities is a cornerstone of driving corporate purchasing decisions?

Over the past year, I've thought a lot about how to do effective community building while building the business bottom line. In this article, I'll outline three big steps to take toward building authentic, productive, sustainable developer communities.

1. Understand the value of community members.

While CEO of MySQL, arguably one of the most successful open source software businesses of all time, Mårten Mickos said that success in open source business relied on serving two audiences well:

"Free and open source software business won't work unless you serve both those who spend time to save money and those who spend money to save time."

For organizations providing open source software solutions, understanding the value of each participant in your company's ecosystem is a vital part of making your business successful. Your customers, your engineers, and developers who use only your company's open source offerings are all a part of your community.

Those people who use your company's open source bits but none of your commercial offerings represent a valuable part of your business ecosystem; they are often passionate advocates, vocal influencers, and a boon to your QA and developer team for their bug reports and identification of important edge cases.

2. Set clear expectations for community contribution.

There's nothing wrong with making explicit asks of your community for help. If you're hoping for advocacy, encourage your community members to speak at meetups or conferences about your technology; developers want to associate their reputation with the software they find useful and elegant, especially if it's new and shiny.

If you're looking for bug reports and pull requests, encourage them in a few simple ways:

  • Respond to bug reports quickly, ideally within 48 business hours, even if it's just to let the reporter know you're looking into it.
  • The same goes for pull requests; you don't have to merge every PR, but take a few moments to evaluate the PR, comment on the work created, and, if not merging, provide a brief explanation for why your company is not accepting the code.
  • Have a sane contributor license agreement so that legal agreements do not become a hurdle for community contribution. For example, expecting a community member to sign a complex legal agreement to make a simple documentation update is an unreasonable barrier and exhausts the spirit of volunteerism amongst your community members.

Even if you're just hoping developer fans of your product will sport your company's stickers on their laptops, making the rules of engagement — and explaining the value of contributing — for your community explicit is a good practice. Taking the time to contribute well-written bug reports means the software improves for all users. Teaching others how to use your software comes with the gratification of having helped someone else, while also creating a larger potential customer base for your company. Contributing to your company's code base usually comes with a corresponding rise in prestige in your community, and increased employability as your company's products see wider adoption.

You'll find that many users of your free (and open source) software are happy to spend their free time contributing to your success because they'd like to “give back" in exchange for the value they've gotten from your product.

3. Be consistent.

Interactions with your community members — be they your customers, your users, and even your own company's developers — should be consistent. Inconsistency breeds a lack of trust, and trust is a fundamental component for successful communities and companies.

Having a clear, easy-to-find roadmap published so that everyone knows what technical direction you're heading helps with that. No one wants to spend time polishing a pull request that your company won't accept because a similar feature is already in the works, and those who do can easily shift from passionate advocates to vocal detractors.

Likewise, if your product line is focused on supporting your open source software products, don't provide “free" support to do a good deed for your user community. All interactions within your community set norms, and community members can come to expect your employees to go above and beyond for them for every problem if they go above and beyond once. There is nothing wrong with helping your support staff say no to requests that eat into building the company's bottom line, especially when those same folks providing support are your company's developers, who need to focus most of their time on building the underlying products that compel customer interest in purchasing a support contract.

What steps would you add to this list? Let me know in the comments.


Amye Scavarda will present Building Authentic Communities: Upholding Developer Values while Delivering Customer Value at the 20th annual OSCON event, July 16-19 in Portland, Oregon.

Leslie Hawthorn headshot
Leslie Hawthorn has spent her career creating and cultivating open source communities. She has driven open source strategy in Fortune 10 companies, pre-IPO startups, and Foundation Boards including senior roles at Red Hat, Google, the Open Source Initiative, and Elastic. She currently leads the industry verticals community strategy team within Red Hat’s Open Source Program Office.

4 Comments

Great article Leslie! I would add Communication to that list.

I am in this exact situation; a company producing an open source CMS, with a global developer community.

Keeping that balance between the players (company employees, customers, partners, developers etc) requires communication at several layers, between several of the players involved.

Excellent point, Robin! That's a huge section of the talk this article comes from. If I ever get to reprise it and it's videoed, will send you a pointer.

In reply to by robinmuilwijk

It's also a very good idea to use tools and methods that are consistent with your end goal! If you're an open community, for example, it's best to use open tools. If, say, you adopt Slack for your communication (as many open communities do, unfortunately), you're undermining an open culture - there's some real dissonance in forcing your potential contributors to agree to 3rd party proprietary terms to participate in your open community (and the fact that you're giving a third party total control of your community's collaboration).

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.