The idea that an organization is a constellation of "communities of practice" is a genuine breakthrough, and that overused word "breakthrough" is merited. It is an idea that had profound implications for what it takes to run a successful organization in our frenetic, chaotic times. In this book, Wenger lays the groundwork for the kind of thinking that will be necessary for any surviving organization in the 21st century. Wenger and the Institute for Research on Learning are defining the cutting edge. And they are right! Pay attention! Please!
about Etienne Wenger’s book, Communities of Practice
It seems to be a commonly held opinion that principles of the open source way are limited to the practice of software development.
In fact, the open source way is an instance of a community of practice, which exist in varying forms all around us. Etienne Wenger, the leading theorist of communities of practice, [defines](http://www.ewenger.com/theory/) the term as follows:
"Communities of practice are formed by people who engage in a process of collective learning in a shared domain of human endeavor: a tribe learning to survive, a band of artists seeking new forms of expression, a group of engineers working on similar problems, a clique of pupils defining their identity in the school, a network of surgeons exploring novel techniques, a gathering of first-time managers helping each other cope. In a nutshell: Communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly."
Every community of practice consists of three structural elements:
- Domain
-
The domain is the area of knowledge that interests the community. In free software, the domain is usually a particular technical problem that needs to be solved.
- Community
-
The community is the set of people who care enough about the domain to give their own time to participate. In free software, even though the domain may be very specific, interested community members can come from anywhere that’s connected to the Internet — which is one of the factors that makes the community software development model so powerful.
- Practice
-
The practice is the way that work is done, by the community, to further their goals in regard to the domain. All frameworks, tools, ideas, stories, documents, legal entities, code, and so forth, are all part of the practice. It’s the work, and all the tools used to get the work done.
An important aspect of these elements is that the community is self-documenting. In the process of practicing in the domain, community members capture content about the practice - its history, processes, and so forth.
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.
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 if someone were 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 [http://teachingopensource.org 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.
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 [http://lwn.net/Articles/83360/ this]. The dialogue between the groups made it clear that externalizing the tools and processes were key to community growth.
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. The way to find more experts is to invest in a process that continually creates more experts.'
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.
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.
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.
To learn more about how to cultivate communities of practice, read Etienne Wenger’s book on the subject:
A follow-on book about technologies to support communities of practice written by Etienne Wenger, Nancy White, and John D. Smith:
-
http://technologyforcommunities.com/excerpts/ (contains various downloadable resources)
There’s nothing like an example that instantiates the theory: * Andreas Lloyd: A system that Works for Me - an anthropological analysis of computer hackers’ shared use and development of the Ubuntu Linux system. http://eskar.dk/andreas/lloyd_thesis.pdf.