Photo by Marcia Knous
I’ve noticed that the terms “participation” and “community” have become more or less interchangeable in the context of Mozilla. I’ve even had a conversation with a Mozilla executive who said “I thought they were the same.”
It seems that the term “community” has been somewhat deprecated within Mozilla because it is ambiguous, in that it can mean different things to different people, which can lead to miscommunication. For example, some people use “community” as a shorthand for “volunteers” while others very intentionally use it to mean all Mozillians, paid and non-paid.
I see “participation” and “community” as related but distinct concepts, both of which are essential to Mozilla. Let’s start with definitions (sorry, I’m a word nerd). The Participation Team’s wiki page says:
Participation is when people can freely contribute their energies, time and ideas to support Mozilla’s mission.
So far, so good.
Here’s my generic definition of “community”:
A community is a group of people who interact and develop a network of relationships around a common factor.
The “common factor” is the wild card that leads to a wide variety of types of communities. If the common factor is physical location, the community can be a traditional geographic community. Some other types of communities include:
- Communities of interest, for example, about a certain hobby, such as a back-country skiing or a particular video game.
- Communities of circumstance, such as a certain medical condition like Type II diabetes, or a life stage like parenthood.
- Communities of purpose interact around the same individual goal or process, such as physical fitness or buying a car.
- Communities of practice share and discuss a particular craft or profession, such as programming or accountancy.
- Communities of action have shared goals and take action to bring about change.
So, what kind of community is Mozilla? I consider Mozilla to be a community of action united by the Mozilla mission, which is the shared goal. Members of the Mozilla community take action (that is, participate) in order to realize that mission. However, Mozilla is really a constellation of overlapping sub-communities based on geography, interest, or practice. The nature of the sub-community determines the type of action that its members typically do. For example, a localization community shares a particular language, such as French, and its members take action by localizing software, websites, or documentation. A community for a functional area, such as QA, has some characteristics of a community of practice, but members focus on the practice of their skills on behalf of Mozilla.
Other key concepts in my definition of “community” are interaction and relationships. People who share a common factor, but don’t interact about it or have relationships with one another as a result, are not, for the purposes of this discussion, a community. (I know this excludes another widespread use of the word. That’s why I gave my definition.)
So, to bring the concepts together:
Participation is the “what” of the Mozilla community; community is the “how” of Mozilla participation.
Or rather, community, in my opinion, should be the “how” of participation. If people simply participate, but don’t interact and build relationships with others (that is, become part of a community), they are unlikely to sustain interest in participating over a more than, say, a few months. Therefore, when creating opportunities for participation, one needs to build-in opportunities for interaction, in order for the set of participants to develop into a community. When participants have relationships with one another, they are more likely to keep coming back to participate, making the group sustainable, that is, retaining more people than it loses.
Participation and community don’t necessarily go hand in hand; ensuring that they do requires careful design of participation opportunities.
The canonical example of participation in open source software is contributing a code patch. A programmer finds something that needs fixing, gets a copy of the codebase, fixes the bug, submits a patch for review, and ideally has the patch accepted into the main codebase. At the very least, this programmer has to interact with a reviewer. Ideally, she interacts with other members of the project earlier and more extensively than just at review time, through mentorship and discussion of the bug. She might also subscribe and post to a relevant mailing list, and read and comment on other bugs. Through these interactions, repeated over time, she becomes part of the community for the open source project.
However, not all participation opportunities have interaction built-in. For example, Mozilla Developer Network (MDN) is a wiki of developer documentation. Because it uses a pure wiki model, no review is needed for a change to go live on the site. It’s quite possible for someone to create an account and make many edits to the site without ever interacting with another human being. Such contributors are participating, but are not engaged with the MDN community. As community manager for MDN, one of my challenges is to draw contributors like that into communication channels such as mailing lists or IRC, and encourage them to interact with other members of the MDN community.
As your Mozilla team sets goals for 2016, with an eye towards inviting participation, I encourage you to also look for ways to invite and encourage interaction among participants, especially if open participation is new for your team. This could be as simple as creating a category on the Mozilla Community Discourse site, and encouraging participants to post there via welcome emails. Of course, make sure that existing team members initiate and respond to discussions there as well; they are part of the community, too. Communities don’t happen overnight, and they require (repeated, sustained) help in order to grow. The payoff is in sustained participation, as well as in the intangible benefits of relationships with fantastic Mozilla contributors.