Alessio Fattorini
In The Open Organization, Jim Whitehurst defines an open organization as one that "engages participative communities both inside and out." For Whitehurst, the success of future organizations depends on their ability to successfully interact with, learn from, and support the broader communities surrounding their work and their products.
But working this way doesn't come naturally to all leaders. In this chapter, I'll not only explain the important role community plays in an open organization's existence but also explore why an organization would want to build a community in the first place. I'll share with open leaders the lessons I've learned leading my own open organization for several years, because I really do believe it's the best way to generate new innovations today.
When we launched Nethesis in 2003, we were just system integrators. We only used existing open source projects. Our business model was clear: Add multiple forms of value to those projects: know-how, documentation for the Italian market, extra modules, professional support, and training courses. We gave back to upstream projects as well, through upstream code contributions and by participating in their communities.
Times were different then. We couldn't use the term "open source" too loudly. People associated it with words like: "nerdy," "no value" and, worst of all, "free." Not too good for a business.
On a Saturday in 2010, with pastries and espresso in hand, the Nethesis staff were discussing how to move things forward (hey, we like to eat and drink while we innovate!). In spite of the momentum working against us, we decided not to change course. In fact, we decided to push harder—to make open source, and an open way of working, a successful model for running a business.
Over the years, we've proven that model's potential. And one thing has been key to our success: community.
Together with the Nethesis guys, we decided to build our own open source project: our own operating system, built on top of CentOS (because we didn't want to reinvent the wheel). We assumed that we had the experience, know-how, and workforce to achieve it. We felt brave.
And we very much wanted to build an operating system called NethServer with one mission: making a sysadmin's life easier with open source. We knew we could create a Linux distribution for a server that would be more accessible, easier to adopt, and simpler to understand than anything currently offered.
Above all, though, we decided to create a real, 100% open project with three primary rules:
- completely free to download
- openly developed, and
- community-driven
That last one is important. We were a company; we were able to develop it by ourselves. We would have been more effective (and made quicker decisions) if we'd done the work in-house. It would be so simple, like any other company in Italy.
But we were so deeply into open source culture that we chose a different path.
We really wanted as many people as possible around us, around the product, and around the company. We wanted as many perspectives on the work as possible. We realized: Alone, you can go fast—but if you want to go far, you need to go together.
So we decided to build a community instead.
We realized that creating a community has so many benefits. For example, if the people who use your product are really involved in the project, they will provide feedback and use cases, write documentation, catch bugs, compare with other products, suggest features, and contribute to development. All of this generates innovations, attracts contributors and customers, and expands a product's user base.
But quickly the question arose: How can we build a community?
We didn't know how to achieve that. We'd participated in many communities, but we'd never built one.
We were good at code—not with people. And we were a company, an organization with very specific priorities. So how were we going to build a community and foster good relationships between the company and the community itself?
We did the first thing one must do: study. We learned from experts, blogs, and lots of books. We experimented. We failed many times, collected data from the outcomes, and tested them again.
Eventually we learned the golden rule of the community management: There is no golden rule of community management People are too complex and communities are too different to have one rule "to rule them all."
One thing I can say, however, is that an healthy relationship between a community and a company is always a process of give and take. In the rest of this chapter, I'll explain what that means.
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 into an open organization and start working in the open.
We are aware that for many companies, introducing open innovation involves a significant 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 at all easy.
If your company expects to benefit from a relationship with 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. If you're a leader hoping to leverage the power of community, remember the following.
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.
Why has the organization decided to build a community and support the project? What does it hope to gain? Conversely, what will the community gain? A company should understand a community's needs and expectations in order to earn its 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 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.
Great leaders ensure that the entire company is responsible for working with the community. Community-centric companies involve participation from as many employees as possible, so they involve other staff members in 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 the 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 favor of the community; I'm a kind of diplomat and translator between the community and the company.
I'm really the middleman.
Next, let's discuss what your organization should expect to give if it wants to cultivate community. I'll explore five key requirements.
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 offer my warm welcome to the new people and 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.1 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.2 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.3 Our Ambassadors have a set of social norms and rules that they undertake 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.
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,for instance, 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."4 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@#&ing 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.
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.5
Remember that every time you need to reply to someone.
You'll be tempted to keep your discussions private. You should tell anyone accustomed to working in 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!6 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.
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 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 (and open leaders) have to provide what communities really need: a genuine and transparent relationship with the organization and other members. Put people first and you won't regret it.
As I've already mentioned, our product wouldn't be what it is today without the vibrant community that surrounds and supports it. So let's discuss how that happened by exploring what your organization should expect to receive from its investment in people. You'll be able to see the kinds of benefits that will take your business to the next level—and beyond.
Let's review six benefits.
"Open innovation" occurs when a company sharing information also listens to the feedback and suggestions from outside the company. As a company, we don't just look at the crowd for ideas. We innovate in, with, and through communities.
You may know that "the best way to have a good idea is to have a lot of ideas."7 You can't always expect to have the right idea on your own, so having different point of views on your product is essential.
How many truly disruptive ideas can a small company (like Nethesis) create? We're all young, caucasian, and European—while in our community, we can pick up a set of inspirations from a variety of people, with different genders, backgrounds, skills, and ethnicities.
So the ability to invite the entire world to continuously improve the product is no longer a dream; it's happening before our eyes. Your community could be the idea factory for innovation. With the community, you can really leverage the power of the collective.
A community can be your strongest source of valuable product research.
First, it can help you avoid "ivory tower development." As Stack Exchange co-founder Jeff Atwood has said, creating an environment where developers have no idea who the users are is dangerous. Isolated developers, who have worked for years in their high towers, often encounter bad results because they don't have any clue about how users actually use their software. Developing in an ivory tower keeps you away from your users and can only lead to bad decisions. A community brings developers back to reality and helps them stay grounded. Gone are the days of developers working in isolation with limited resources. In this day and age, thanks to the advent of open source communities, research departments are opening up to the entire world.
No matter who you are, most of the smartest people work for someone else. And community is the way to reach those smart people and work with them.
Second, a community can be an obvious source of product feedback—always necessary as you're researching potential paths forward. If someone gives you feedback, it means that person cares about you. It's a big gift. The community is a good place to acquire such invaluable feedback.
Receiving early feedback is super important, because it reduces the cost of developing something that doesn't work in your target market. You can safely fail early, fail fast, and fail often.
And third, communities help you generate comparisons with other projects. You can't know all the features, pros, and cons of your competitors' offerings. The community, however, can.8 Ask your community.
Communities enable companies to look at themselves and their products from the outside, letting them catch strengths and weaknesses, and mostly realize who their products' audiences really are.9
Let me offer an example. When we launched the NethServer, we chose a catchy tagline for it. We were all convinced the following sentence was perfect:
NethServer is an operating system for Linux enthusiasts, designed for small offices and medium enterprises.
Two years have passed since then. And we've learned that sentence was an epic fail.
We failed to realize who our audience was. Now we know: NethServer is not just for Linux enthusiasts; actually, Windows users are the majority. It's not just for small offices and medium enterprises; actually, several home users install NethServer for personal use. Our community helps us to fully understand our product and look at it from our users' eyes.
In open source communities especially, communities can be a welcome source of product development.
They can, first of all, provide testing and bug reporting. In fact, if I ask my developers about the most important community benefit, they'd answer "testing and bug reporting." Definitely. But because your code is freely available to the whole world, practically anyone with a good working knowledge of it (even hobbyists and other companies) has the opportunity to play with it, tweak it, and constantly improve it (even develop additional modules, as in our case). People can do more than just report bugs; they can fix those bugs, too, if they have the time and knowledge.
But the community doesn't just create code. It can also generate resources like how-to guides, FAQs, support documents, and case studies.10 How much would it cost to fully translate your product in seven different languages? At NethServer, we got that for free—thanks to our community members.
Communities can help your company go global. Our small Italian company, for example, wasn't prepared for a global market. The community got us prepared. For example, we needed to study and improve our English so we could read and write correctly or speak in public without looking foolish for an audience. The community gently forced us to organize our first NethServer Conference, too—only in English.11 A strong community can also help your organization attain the holy grail of marketers everywhere: word of mouth marketing (or what Seth Godin calls "tribal marketing").12
Communities ensure that your company's messaging travels not only from company to tribe but also "sideways," from tribe member to potential tribe member. The community will become your street team, spreading word of your organization and its projects to anyone who will listen.
In addition, communities help organizations satisfy one of the most fundamental members needs: the desire to belong, to be involved in something bigger than themselves, and to change the world together.
Attracting new users costs a business five times as much as keeping an existing one. So loyalty can have a huge impact on your bottom line.
Quite simply, community helps us build brand loyalty. It's much more difficult to leave a group of people you're connected to than a faceless product or company. In a community, you're building connections with people, which is way more powerful than features or money (trust me!).
Open leaders should never forget that working with communities is always a matter of giving and taking—striking a delicate balance between the company and the community.
And I wouldn't be honest with you if I didn't admit that the approach has some drawbacks. Doing everything in the open means moderating, evaluating, and processing of all the data you're receiving. Supporting your members and leading the discussions definitely takes time and resources. But, if you look at what a community enables, you'll see that all this is totally worth the effort.
As my friend and mentor David Spinks keeps saying over and over again, "Companies fail their communities when when they treat community as a tactic instead of making it a core part of their business philosophy."13 And as I've said: Communities aren't simply extensions of your marketing teams; "community" isn't an efficient short-term strategy.14 When community is a core part of your business philosophy, it can do so much more than give you short-term returns.
At Nethesis we experience that every single day. As a small company, we could never have achieved the results we have without our community.
Never.
Community can completely set your business apart from every other company in the field. It can redefine markets. It can inspire millions of people, give them a sense of belonging, and make them feel an incredible bond with your company.
And it can make you a whole lot of money.
Community-driven companies will always win. Remember that.
Footnotes
-
https://community.nethserver.org/t/weekly-welcome-to-new-members-25-jul-16/3999 ↩
-
https://community.nethserver.org/t/nethserver-ambassadors-group/4782 ↩
-
https://community.nethserver.org/t/thoughts-about-nethserver-mission-vision-and-values/4080 ↩
-
https://www.goodreads.com/author/quotes/52938.Linus\_Pauling ↩
-
https://community.nethserver.org/t/improve-our-communication/2569 ↩
-
https://community.nethserver.org/t/nethserver-conference-in-italy-sept-29-30-2017/6404 ↩
-
http://cmxhub.com/article/community-business-philosophy-tactic/ ↩
-
https://opensource.com/open-organization/18/2/why-build-community-2 ↩