Chapter 2. Communities of practice
2.4. Principles for Cultivating Communities of Practice
In his book Cultivating Communities of Practice, Etienne Wenger proposes seven principles for successfully cultivating communities of practice. Anyone who is responsible for moving a community forward towards its goals should consider reading it.
2.4.1. Design for evolution
When starting a new community effort, it's difficult to know what form it will take. Volunteers are not employees; they can only be influenced, never ordered. Some may take passionately to the proposed project; others may only be able to give some of their time.
Be ready for that. Concentrate on simple lists that encourage accountability. Know who's doing what. Maintain a flexibility of structure, so that if someone to have an idea that takes your effort in a completely different direction, you don't have to change all your rules. Only have as much "governance" as you need at the time, never more.
Also: volunteers leave. It's a fact of life. Make it easy to hand off tasks to newcomers, and work to generate newcomers, so that your old-timers don't feel obliged to continue doing work that they no longer have the time or inclination to do.
At
teachingopensource.org, there are a number of working groups. Some of them are active; some of them are not. Creating a new working group is deliberately kept simple; identify a "leader" in charge of moving things forward, and claim a wiki page, and you're all set. Working groups are evaluated periodically by the entire group, and if it's generally agreed that no progress is being made -- often because the leader doesn't have the time required -- the working group either finds a new leader, or is disbanded. Simple process, until more complex process is needed.
2.4.2. Open a dialogue between inside and outside perspectives
In any community there are always "insiders" -- i.e., the people who understand the problem space very well, the people who are at the core of the domain space -- and people who are "outsiders", but have enthusiasm, some domain knowledge, and a willingness to help. A successful community uses both of these perspectives effectively, because it's the outsiders who are most likely to impart new energy and new perspectives.
There are different kinds of insiders and outsiders. A company's employees can be the insiders, and the customers can be the outsiders. One particular team can be the insiders, and other employees can be the outsiders. Beyond companies, longtime members of a community become insiders over time, and newcomers almost always start as outsiders.
For example, when Red Hat first started the Fedora project, many of the critical decisions were taken by a committee composed only of Red Hat engineers. A number of critical tasks were assigned to "insiders", and these tasks languished. In the meantime the "outsiders" struggled to find meaningful tasks to help the project's growth. The public perception looked a lot like
this. The dialogue between the groups made it clear that externalizing the tools and processes were key to community growth.
2.4.3. Invite different levels of participation
Often, the hard tasks at the center of a domain can only be tackled by the insiders -- but if only the hardest tasks get focus, and only by experts, then those new to the domain do not have opportunities to gain expertise.
One of the important concepts espoused by Wenger is legitimate peripheral participation. It is, essentially, the idea of apprenticeship; the key difference is that, rather than being apprenticed to an individual, a new practitioner can be apprenticed to the entire community of practice.
In a volunteer community especially, people who join are going to be invested in learning more and doing more, and it's important to identify work that matches the newbie's skills, invites them to stretch those skills, and provides people who can help them develop those skills as required.
As an example, learning to package software is not easy -- but some software is easier to package than others. Newbie Fedora packagers are invited to learn how to package fonts, since they are simple and very uniform in how they are packaged. There are also lots and lots of fonts out there that need to be packaged. It's a perfect "on-ramp" for newbie packagers, and because there are so many fonts to be packaged, there are plenty of opportunities for newbies to be immediately useful.
Experts are great, but they're hard to find.
Experts are great, but they're hard to find. The way to find more experts is to invest in a process that continually creates more experts.
2.4.4. Develop both public and private community spaces
Avoiding the cabal mentality does not mean having every single conversation in public, ever. Transparency is great, but it is unreasonable to expect everyone to be comfortable with full transparency, all the time.
Also, one-to-one communication builds intimacy and trust that multiway communication cannot. Especially as new participants are building confidence, it's vitally important to build private relationships between individuals. Certainly it is appropriate to encourage important conversations to be moved into public forums, especially conversations about actions that will affect others. But private chats are important too, and often useful for eliciting insights that help move the more public conversations forward.
In particular, private conversations can be critical to resolving conflicts within communities, and community leaders who are seen as responsible for the community's health should be comfortable taking the parties aside. There have been many examples in the Fedora community of conflicts that were better resolved in private, and there will be more in the future.
No volunteer wants to spend time on work that nobody values. Therefore, encourage community members to express the value that they receive from the community, and to reflect on the value that they provide.
Also understand that not everyone's notion of value needs to agree; so long as participants do not actually detract by participating, they should feel free to add value in whatever way they see fit. Core participants frequently do not value a set of contributions initially, and only come to understand and appreciate that value later. Even contributions that are wildly experimental and far from the mainstream, and may not seem at all valuable, should be respected and encouraged.
Example: There was a time, not so long ago, when many central members of the Fedora community saw a Live CD as a waste of effort. The Live CD is now one the most important deliverables of the entire Fedora community. But it was clear to the initial contributors that a good Live CD was critically valuable, and the community's embrace of that work led to a critical mass of contributors to focus on, and solve, the problem.
2.4.6. Combine familiarity and excitement
Stable and familiar working processes are vital, because people need tasks to focus their day-to-day work.
Still, people can not thrive on heads-down tasks alone. Exciting new challenges create opportunities to energize old friends and attract new ones, and give volunteers an important sense that they are all wrapped up in a great and important challenge. This excitement is crucially important to keep volunteers motivated on the daily work.
Example needed.
The pace of engagement is crucially important in a community of doers.
Moving too quickly and demanding too much, too soon, can leave volunteers frantic and feeling like they can't keep up. Moving too slowly can lose volunteers who do not see enough activity to hold their own interest.
The weekly IRC meeting has been a hallmark of most successful Fedora projects. For some projects, a weekly meeting may be too much, and for other projects, a weekly meeting may only be a way to checkpoint activity that is going on constantly. Either way, building and maintaining a sense of rhythm is crucial for a healthy community.
