I’ve been keeping a collection of observations about my experiences building communities from a corporate platform. I poke at the piece occasionally to remind myself whenever I have to engage a community. The ideas are largely based on interactions with software communities, but ultimately I’d like to explore the underlying community development process itself that drives the creation of all communities in all fields. So, this is all just a work in progress.
Image: Beijing, China, 2008, OpenSolaris
Communities are about people. Granted, there are many components involved in the community-building process, but people are by far the most important. So don’t get so distracted with all the logistics and politics of building that you lose sight of the people — especially three groups of people: (1) people you are trying to attract (participants), (2) people you need to help you build (leaders), (3) people who get in your way (trolls). Once you realize this you can focus on what’s most important in any part of any community-building project.
Here’s a little secret about community development that isn’t very well discussed: The process is natural. Actually, it’s necessary for survival. It happens all over the world, and it always has throughout human history. People gather. They form groups. They want to help. Leaders emerge. That’s just what humans do if given even the slightest chance. Sometimes these activities take place in public, while other times for obvious reasons everything needs to be hidden. So, the underlying process of community development is innate. However, communities don’t necessarily scale very well without organizers actively leading people and building infrastructure to hold things together. That’s the catch. That’s where things can get difficult. So, as you build, start by understanding that your most important community-building tool is human nature itself. And, just to be a bit contrarian, please also recognize that human nature itself can also blow things up in a spectacular fashion. That, too, is natural.
Building communities is an active and cyclical process of planning and implementing. Some people balk at that notion because they believe communities ought to grow organically as people get together. Natural growth occurs during the initial stage when things are small, but to scale a community you need some planning and resources and some builders — generally called managers or organizers. You have to build infrastructure, engage new people, and manage resources from diverse sources including corporate, foundation, individual, and nature itself.
But the planning process doesn’t have to be complex. Good community building concepts are based largely on two principles: open communications and open development. Basically, working in the open and talking in the open. In other words, if you really want to grow, you need to talk to a lot of people and talk to them all the time. And you need to provide ways for people to contribute back by creating and sharing their work with you and everyone else. Then the process of the community’s work itself helps build community because it generates more communications and more work. And around you go.
So building starts with planning. This is not optional. Write a plan. Start with one piece of paper. What do you want to build? Why? With who? Where? When? How? Then start. Get some feedback. Update your plan. Expand it. Publish it. Repeat. A lot. Think in terms of generating some quick momentum in a series of small iterative steps as part of the planning process, rather than planning forever before you ever go out and actually build anything. Remember that planning and building are tethered. Focus your building efforts on moving in the direction of your plan. But remain flexible in your planning so you can change direction when you have to (and you will have to). That last bit represents quite a balancing act that needs active management because the sole purpose of a plan is to get you off the couch. The final product rarely looks exactly like the initial plan.
Get outside. You can’t build a community from behind a corporate firewall or from inside your house. Conversations, ideas, arguments, plans, meetings, mailing lists, forums, websites, social networks, source code, documents, tools, people, infrastructure, artwork, whatever — get it all outside!
That’s the only way anyone will ever know you even exist. And it’s the only way anyone will ever have a fair shot at participating and contributing back and helping your community grow. Note here that I’m intentionally combining the community-building process with the product or service the community ultimately delivers. So, if you are building an Open Source software community, for instance, than all the things engineers need to build the software are also the things you need to build the community because that’s how you engage new people and keep the people you already have. All tools are community-building tools. The goal should be to provide a lot of things around which people can gather, talk, and work. And don’t wait until you have everything done to put your stuff outside. Just put the bits outside in pieces and let things grow and come together from multiple directions over time. Yes, this will be messy. But communities are messy. Get used to it. This concept may also seem anti-intuitive and even confusing but it’s critical for building momentum. And this takes time. You build in pieces. And transparency is required to facilitate the process. You can’t live in two worlds if you want to build a community. You have to build outside.
Of course, there is an important exception to this transparency rule. If you are building, say, a political moment for the purposes of social liberation then you’ll obviously have to be more discreet. You’ll have to find a way to make your stuff available to some but not all. In general, though, if you’re not overthrowing a dictatorship, you ought to be transparent.
Communities thrive when people are encouraged to participate, to form trust relationships, and to earn their way based on merit. Make sure the procedures for getting involved in your community are well documented and understood by everyone. You can look at this issue as the distinction between a community and a program (such as a marketing, customer, or developer program). Most traditional organizational programs go one way — usually from a company to a market. But communities go two ways (many ways, actually) and involve just as much coming as going. Also, participation is really about doing things in the community, not talking about doing things in the community or offering a limited number of things that people can do. Remember that these distinctions are clear to anyone who participates in communities so don’t bother faking it.
When communities are small and organic those who participate generally do most of the work. As a result, those who do get the privilege to lead. And those are also the people whose voices are heard above all others no matter how noisy it gets. That’s the concept you need to embrace to scale things as well. Basically, encourage people to earn their credibility based on the work they contribute to the community — not the title they bring from their company or university or any other organization. If you want people to stick around and help the community grow, you will have to enable people to participate directly in as many of the operations as possible. So, let go. The more you keep control and the more you centralize the more you will reduce participation and hinder growth. You can build very large programs by keeping control if you have lots of resources and customers/followers, but most community people will not engage unless they can directly participate and contribute to the creation of the community itself.
Define the contributions you want. Get specific. Give general categories and detailed examples. And expect the community to offer more examples and things you hadn’t even thought of (that’s the goal, actually). For instance, here is a general list of contributions to a software development project: code, tests, presentations, user groups, translations, university courses, training materials, websites, evangelism, documentation, bug tracking tools, source management tools, governance. Etc. Although many of those items are technical and require expertise, many are not technical at all and can be done by many people in the community. In other words think about a variety of contributions you want to encourage, publish a list, and then let that list grow in the open. Then when things start coming in start pointing to the people who are contributing. You want to always call attention to contributions. In most communities everyone knows who really contributes because work speaks louder than words, and the contributors are generally working with each other in the open. But as things grow in size and complexity it doesn’t hurt to thank people in public once and a while and keep a public record of who’s doing what. But do this in an understated way. Keep it classy. Be mindful of your community’s personality.
If you are building a technical community you’ll be presenting to a lot of technical people. But remember that the biggest problem with most presentations in high tech is that they are too long and they focus too much on describing the technology itself. That may be fine for a classroom or an interactive tutorial session or a presentation where the engineers are talking to other engineers. But the act of building a community is actually not primarily about technology. It’s about people. So, explain your technology, sure, but focus more on how people can get involved and contribute directly to the technology and to the community and how that benefits everyone. Most technical presentations have one slide at the end with a list of lists to join. If you are a builder, though, that one slide is not enough. Don’t focus your talks on your technology. Focus your talks on contributing to your community.
You have to go to conferences. But don’t feel you have to always present something. Participating in the sessions, asking questions, and engaging in hallway conversations and social events are all just as important as presenting formal papers. Just being there is critical. All communities need a mix of face-to-face and online interactions to create a feeling of community. And if you are at an event don’t miss the opportunity to do a rapid-fire lightning talk! Most good conferences offer these opportunities and you should always be prepared to do this off the top of your head with no notes and no slides.
Also, add user group meetings to your list of conferences to attend. Or better yet start a user group. If you start a user group do it in a bar or coffee shop or something. Start small and social and let the technical presentations grow slowly as more people bring their own experiences to the group. Don’t feel you have to always have a big technical presentation with a 100 people in the room each user group meeting. That’s not realistic for the vast majority of groups. Maybe try technical sessions quarterly but meet monthly in a bar for food and beer and then discuss things on a mailing list in between meetings. Start small. Look for ways to build tradition through repeated experiences. Take lots of pictures or video of people at meetings, too. Photography is a remarkably powerful community-development tool because cuts cleanly across language and cultural barriers. Over time a little culture will soon develop and that’s the glue that will hold your group together. After user groups grow a bit, look to connect multiple groups so they can collaborate and start running small conferences.
If you are going to build a community, you ought to spend some time figuring out the physical infrastructure you’ll need to support all the people you want to attract and all the work they produce. As for online tools make sure your website design is modular so you can grow fast and in new ways as your plans change. Also make sure you build your site so it can be localized into dozens of the most common languages, and encourage the community do contribute those content translations as well. Here are some other questions to consider. Do you offer a sandbox for experimentation where people can run their own projects and break things and learn? What tools and processes are necessary to collect and host the project’s artifacts, such as source repositories, review and testing systems, defect tracking applications, content management services, and communications systems (blogs, wikis, social software, etc)? Who has access to those systems? Do you need lower-tech items like vehicles and storage facilities? Video, audio, and other recording devices? What trades will you and your community be interacting with? Any unions involved? Companies? Universities? Governments? Are your systems secure? Whatever you do, plan to build your infrastructure to not only transmit information to people but also to accommodate a wide variety of contributions coming back.
Governance is all about frameworks and social structures to help people get work done. Governance can facilitate community growth quite nicely or it can kill a community with too much bureaucracy. If you are looking for true community governance then don’t launch with your processes already baked. Instead, let it emerge over time as needed. It will evolve anyway so you may as well keep it small and flexible to start and then scale what works. Here are some questions to consider. How will your community run itself? What will the social organization look like? Who has access to what resources and how do they earn privileges over time? Are the social structures tied into and consistent with the development processes, and are those processes expressed in the software and infrastructure? How will everyone make decisions? What is your leadership model and how will you distribute that concept around the world? How will you call attention to contributors? How do you resolve conflicts?
These are questions that need addressing whenever any large group of people comes together to collaborate on anything. When you are small, you can manage governance easily in your head, but when you grow globally and in complexity you need to document the behavior you want to encourage and set some rules around how to manage things. It doesn’t have to be all pervasive, but people need to know where they stand and what’s expected of them. Also, the people who write the governance systems should be the same people who run the community. There can be no separation here. The people who are doing the work need to write the rules of engagement.
So many people claim they lead. Maybe they have a big hairy title or powerful position or know someone special, or maybe they have lots of cash and feel everyone should just follow along quietly. That’s not how leadership generally works in a healthy community, though. And even if there is a powerful single leader at the top there are always opportunities to lead in other areas. In a good community, leadership is distributed much more horizontally than vertically. There is simply no other way to scale a community to motivate people and manage the operations to support large numbers of volunteers. And spotting great leadership in a community is simple. Just look around for who’s talking and for who’s doing. Engage the ones who are doing. From that pool of people you can carve out a group of leaders to help build the community. Chances are those people won’t bark orders at others, but instead they’ll encourage people to work right along with them and people will want to. Also, real leaders don’t duck when things get hot. They don’t get hard to find when things get confusing or uncertain. They stay visible. And they step up and act because things need doing. Leadership is demonstrated via action, and anyone can lead because anyone can act.
Once you’ve established some criteria for your leadership model and start attracting and distributing leaders, a culture will grow as your community grows. This is good. But as a leader you have to be aware of what’s growing. What are your community’s values? What does your community stand for? What do you stand for? Don’t just think about this stuff casually. Make it core. Write it down. Build it. Things get painfully clear when you actually build something rather than just talk about something. Just having a written specification is nice, but it’s ultimately useless unless something gets built. It’s in the building that you find the bugs.
If you want to grow — and you always want to grow — you need to go back to school and hang out with young people. They think differently than you do. They don’t know everything, but they will open up your mind. Get your projects in front of students and professors at universities in emerging markets first. Start with India and China and other rapidly growing regions for obvious reasons — they have the most students and they are extremely interested in reaching out to learn. But don’t neglect the established areas in the U.S. and Europe as well. University visits are probably the single best way to ensure that your community has a shot at surviving the future. You will always need new ideas and fresh energy so neglecting universities is not an option. It needs to be a top priority. By the way, building communities at universities is seriously fun.
Build your community with a global perspective in mind. Where are the developers or users or contributors who could potentially join your community? Go there. A lot. But when you go global you’ll run into all sorts of interesting language, cultural, and even governmental issues that will slow you down. To manage this, look for bilingual people who can help build the community locally, and then work with those leaders to create a global network of communities. You will never have one community around the world, so don’t expect everyone to just follow you (or even understand you). Instead, you will have many communities and they will express their own independence quite differently. Your job is to encourage them to be as independent as necessary, but also to help them connect to other regions so they can contribute to the overall community. This is not easy. But it’s necessary. And it can be an interesting source of really innovative ideas as emerging markets develop.
If you are building a community from inside a large organization, go meet your marketing people. They can help publicize your project formally at conferences or within press/analyst operations or at corporate customer meetings. And they can offer a perspective you may have not considered on important issues such as trademarks, branding, media, advertising, and competition. Everyone thinks they can do marketing. But obviously most can’t. And don’t listen to those quick to judge marketeers — especially when they don’t even come from a marketing background and don’t understand the issues. Talking about innovative marketing and doing great marketing are two entirely different activities. So, just go find some good marketing people who do marketing for a living and inspire them get involved in your project. If you can find marketing professionals who are also familiar with community development that’s cool. If not, teach them. That’s part of your job.
But perhaps the most important aspect of getting marketing involved in your community is you need to quantify the value the community brings to your organization. The term community development can sound too much like charity to some executives who control corporate resources (stuff you need, such as developers, infrastructure, documentation, source code, advertising, expenses, etc). So, write a marketing plan based on your community development plan. You need both. Metrics. Value. Messages. Business development. Branding. Revenue opportunities for new products. Contributions coming in that your organization could have never produced alone from behind the firewall. Whatever. Get creative. But wrap the entire package in a context of money. You are building a community to generate value for your company’s shareholders. Period. If you are not using that language you are in trouble. Finally, although community development plans should be public, corporate marketing plans should be private.
This is much bigger than marketing and it’s somewhat different as well. Advocacy is not about specific marketing disciplines such as advertising, branding, or public relations. Instead, advocacy is about direct, unfiltered engagement at all levels. And it should promote active participation and contribution as the core message. It’s also messy and time consuming. It’s about many-to-many conversations and not one-to-many. Advocacy can include marketing, but it also includes engineers and project managers and support services and anyone else who wants to get involved. Everyone works. Everyone organizes. Everyone talks. And everyone in public. That’s advocacy. Also, you are the best advocate for your own work, right? Well, that’s why you need to assume the responsibility for communicating your own work in your own way. Don’t just give this function to corporate marketing and walk away. Be involved. Do it yourself. And teach others to do it for themselves too. And remember that building communities is ultimately a social exercise so people should have fun as they participate, and you should have fun as you build. Also, you want to draw people in to your community, right? You want to encourage people to stick around, right? Make it fun to hang out. Give people the opportunity — and the permission — to advocate and they will have a ball.
Finally, if you are in a corporate setting don’t worry about letting your people go out in public and talk it up with the community. Relax. They won’t leave. They’ll come back. I get this bit all the time: “I can’t let my people out because they’ll just leave and get a new job at a competitor.” Actually, the opposite is more likely. If you keep your best people locked in a cage they’ll eventually get frustrated and split. Your best talent is already connected externally anyway. Instead, if you give them a public platform from which to build your community and trust them to use your property responsibly, they will honor that trust and stay. Why? It’s in their interest to stay because they’re benefiting from the experience. If you don’t trust, though, you can’t build a community anyway so this point may be moot for some. It’s obvious to everyone else, though.
Are you familiar with all the legal issues you will encounter while building your community? Get to know trademarks, copyright, contributor agreements, licenses, patents, contracts, and any other legal issue related to your field. These things will not necessarily help your community grow, but they can certainly stop things jet quick if you don’t consider them at all. Engage some lawyers. Teach them about the needs of the community, and ask them to teach you the realities of the law. The education should always go both ways.
That’s it for now.