As I wrote in the first article of this three-part series on the power and importance of communities, building a community of passionate and committed members is difficult. When we launched the NethServer community, we realized early that to play the open source game, we needed to follow the open source rules. No shortcuts. We realized we had to convert the company in an open organization and start to work out in the open.
We are aware that for many companies, introducing open innovation involves a huge cultural shift. We at Nethesis are always struggling with that, even if being open is our mission. But I have to be honest, it's not easy at all.
Working with open communities isn't straightforward. It's always a process of give and take. In this article, I'll discuss what organizations should expect to give to their communities if they want to succeed.
The art of giving
If your company expects to benefit from a relationship to a strong community, it has to give first in order to build a solid relationships based on reciprocal trust and transparency. And giving code is not enough. Releasing an entire open source project isn't enough.
The truth is that you have to invest in people. You have to put people first, and put people before code. As a company, you have to devote your time to building relationships—and giving first.
Building community is not an efficient short-term strategy. And even if it gets you some quick returns in three to six months, those returns will be a very small representation of the full potential value you could be reaping. It's a long journey and it takes time. Results can take months or years of work. But it pays off! Trust me.
Here are a few principles to keep in mind when you're considering building a community.
A community isn't strictly a marketing channel. It's an entirely different animal. Your community doesn't exist for you to engage in direct sales (I keep my community at a safe distance from my salespeople). You can't even use the same types of communication; in marketing, the message is from the company to the audience. In the community, the communication is primarily member to member, and you exist to make that easier.
Clarify the relationship as soon as possible. Why the organization has decided to build a community and support the project? What does it hope to gain? Conversely, what the community will gain? A company should understand community needs and expectations in order to earn his trust. You can't ask people to devote their time if they think that you're making money from their volunteer efforts. Don't leave space for grey areas here. In our case, we stated that NethServer is a community effort, founded and sponsored by a company (Nethesis). Nethesis' business model is to sell software, professional support, and services to other companies, customers, and resellers. We use a portion of our revenue to fund the development of NethServer (official site hosting, community initiatives, sponsoring, and so on). Community and company have the same target: making NethServer better and more successful. And NethServer benefits enormously from the resources that the company invests into it. The company pays NethServer coders to write features that the customers and users need and works with the community to make NethServer a better product. Because the company works out in the open and as part of the community, and because the code is released under the GPLv3, NethServer itself will continue to be free. That's a virtuous circle—everyone wins.
Community managers aren't solely responsible for the community. The entire company is responsible for running the community. Community-centric companies involve participation from as many employees as possible so they incorporate other members of staff into community discussions and initiatives. Yes, you should hire a community manager if you're serious about building community. it should be a full-time role—someone in charge of facilitating the relationships between these entities, especially in the early stages. But the entire organization needs to support the community and its mission. For example, I personally am both the voice of the community inside company and the voice of the company inside the community. Actually, to succeed at the job I must participate at a level that can appear to be disloyal to my employer and in favour of the community; I'm a kind of diplomat and translator between the community and the company. I'm really the middleman.
So next, let's discuss what your organization should expect to give if it wants to cultivate community. I'll explore five key requirements.
1. Be welcoming
You should be aware that someone's first experience of and in the community is critical, so be sure people feel acknowledged when they encounter you. They have to know what to do first after they've joined you. Follow their first posts or activities with a prompt response. Receiving a response after a few days is a bad welcome for newcomers.
In my community, for example, I create a welcoming post, in which I give my warm welcome to the new people, I ask them to feel safe and to introduce themselves: What are you working on? Why are you here?
You would be amazed at how these simple sentences unleash positive behaviors from newcomers. You show not only that you've have noticed they're here, but also that you care about them, their lives, and their aims. Suddenly, they feel at home and compelled to participate, if only to give back and thank you for the attention.
You can't set the proper cultural tone alone. Creating an ambassador group might help. This group should be the community's engine, a group that's able to set a high bar, nurture a culture, and share your community vision, mission, and values. Our Ambassadors have a set of social norms and rules that they undertakes to respect: lead by example, be humble, be inclusive, be full of gratitude, show your passion, be playful.
The don't just live those rules; they live them every single day.
2. Be inclusive
You have to create an environment in which people feel safe. It doesn't matter how fun and amazing your project is. If people don't feel safe, then they won't contribute. That's a big problem in many technical communities.
You can avoid this by creating rules that help structure a safe environment and help people lead by example. Writing your rules somewhere is not enough to create a welcoming and inclusive culture in a technical community—you have to live these rules.
In our NethServer community, we have a simple rule and invitation for new people: "Don't be afraid to ask stupid questions. Someone else will learn from every stupid question that you ask." It's a very powerful rule, and it helps us achieve an important goal: being inclusive.
Here's another (related) rule: The phrase "RTFM" is banned. "Read the F****** Manual" is not an answer. It's not inclusive. It actually excludes people, and doesn't help people feel like they can safely ask questions. Instead we point newcomers to documentation for simple solutions and give them links to specific information. Sure, that takes more time—but it is much friendlier.
3. Listen to your community first, then speak
This is very difficult. Truly listening is hard. You will be tempted to steer the discussion too much and not listen. Don't do this. Be open-minded and be ready to change your mind. Be ready to have genuine discussions and make sure your community leaders are ready to do the same.
Listening alone is not enough. You should teach your community how to successfully hold discussions and how to effectively explain their needs to one another. Show them that you're inclined to listen if they are ready to discuss everything.
For instance, members should be aware that suggesting a new feature is not enough to get that feature implemented. They have to convince the whole community that such a feature is essential for the project. They have to fight for that. Then, you have to be ready to chime in the discussion, actively listen, and distill good ideas.
As a reminder of what it means to truly listen, I always return to this quote from Simon Sinek:
"When we're close to ideas, what we hear is criticism. When we're open to criticism what we get is advice."
Remember that every time you need to reply to someone.
4. Be transparent
You'll be tempted to keep your discussions private. You should tell anyone accustomed to working secret to stop doing that and to become more transparent. Otherwise, no contributors can actually understand what is going on, and no one will feel like they can get involved.
Put another way: Try to work out loud. Show what you are working on, and keep people updated on your last achievements. Ask all community members to do the same.
Here's a concrete way to practice transparency. I could give some common pieces of advice, like:
- Have all your bugs completely public and visible to everybody
- Have all features requested exposed
- Maintain a public development planning document and a clear roadmap
- Make sure all code changes are done in the form of pull request
. . . and all of them would be perfectly applicable. But they're not enough.
Traditionally, much of the development that occurs in open source space happens in code repositories and bug trackers, and those are not places that users of the software tend to hang out. This separation between developers and users means users don't really see development discussions happening, and contributors may not always get feedback or well-deserved acknowledgments from users.
We use our community platform on Discourse for everything: support requests, bugs, testing processes, development discussions, community organization—really everything! We use GitHub just to keep track of issues, code changes, pull requests, and technical stuff. This means developers can help people with support questions, for example, or they can help with the community discussions. They could be pretty involved everywhere.
Everything is public. Everything is clear. We have a unique place to congregate as we bring everyone together.
5. Lead the support, at least at the beginning
As a company, you must take over the support requests, since asking a question and waiting for an answer for days is a frustrating feeling. That's a bad first experience for new contributors and customers alike.
But answering all the support questions is not enough, and it doesn't scale. Train your community to answer instead. It's way more sustainable in the long run.
You can't be always the only one who helps. Involving others in this process becomes essential. Here's a simple tip: call upon specific people to help other specific people. Doing that, you'll obtain three outcomes:
- Called into question, people will be more inclined to participate and lend a hand
- People feel like experts in the field, and that helps them realize their own strengths
- Newcomers will feel like they've truly helped, and they'll often be thanked for their efforts, which is very satisfying
Conclusions
So far, we've seen that open organizations can benefit from relationships with strong communities only if they're ready to give first. And giving code is not enough.
Open organizations have to provide their communities what they really need: a genuine and transparent relationship with the organization and other members. Put people first and you won't regret it.
In my next article, I'll discuss the interesting part: what your organization should expect to receive from such investment in people. You'll be able to see the kinds of benefits that will take your business to the next level—and beyond.
3 Comments