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.
4 Comments