Essentials of Building a Community

Companies and technologists working in isolation often forget this, but by starting an open source software project, you take a big step toward lining up the people you need to ensure that what you're making meets a demonstrated need, has features users want, and is easy to use. Working in open source helps remind technologists that community is critical to producing good technology and getting it accepted.

Because open source projects rely on healthy communities to get things done, their members must consciously carry out the challenging work of community building, which often includes practices like:

• Setting collective goals and strategy

• Participating in community governance and preparing for leadership changes

• Recruiting, training, and mentoring members, including diverse roles and demographic groups

• Guiding decisions and resolving conflicts

• Upholding positive norms

• Recognizing and rewarding community members

• Bringing the community together for meetings and other events

• Managing the community's growth and ensuring its sustainability

This chapter summarizes the tasks that project leaders and members should carry out for a successful community, and lists some best practices for carrying out the tasks. Consider it a kind of "community quick-start" guide—an overview of several key topics we'll explore in more detail throughout this book. We present this truncated explanation at the start because we believe community leaders should establish best practices as soon as possible; trying to catch problems and define norms in a rearguard action is confusing for participants and may drive many away. But we recognize that reading the entire Open Source Way guidebook before getting to work building a community might be untenable for many.

Given the significant investments—of time, energy, materials resources, labor, and emotion—required to create and sustain communities, we recommend giving serious consideration to the question of whether you can or should attempt to create one in the first place. We'll begin there.

Considering forming a community

Not every open source software project needs its own community. It is possible (and not uncommon) to have open source software maintained by people with no demonstrated interest in forming a community beyond themselves. Conversely, any codebase may suddenly find itself at the center of a community that arises around it without any community-building action from maintainers whatsoever.

In short, simply being an open source project does not guarantee the project will have a community. But it does mean that if it has one, it can reap certain benefits particular to open source software.

When forming an open source software community, you will face many of the same ethical and organizational considerations you would when forming any other community of practice. A community of practice is a group of people who share a common interest, who also get together to learn and practice within the common domain. An example of a community of practice might be hammer dulcimer players who have an annual gathering to share knowledge about the art and practice of being a hammer dulcimer player. Or it might be skateboarders gathering every week at the park to learn and practice new tricks.

When you (and possibly your organization) are considering forming an open source software community, you must first ask yourselves some critical questions: Are you willing to form and be the caretakers for any other sort of community? Does doing so match your vision? Does it match your style of getting things done?

Questions like these will help you determine whether forming a community is the appropriate approach for you and your team. For example, organizations like a university and a branch of the armed forces would have two very different approaches to getting things done. Their reasons for forming any kind of community may be vastly different (or unexpectedly aligned).

Open source software communities, like all communities of practice, can truly draw people together from wildly different worlds. In open source communities, people with common interests (shared practices) band together to learn and grow collaboratively (community).

Other considerations you may face when forming an open source community include:

• You are interested in the benefits of open collaboration and innovation. You might already have or are planning a new technology, and open source is a way to find like-minded collaborators. Or you may just have a feeling that this is the right approach for your plans.

• Attracting enthusiasts to your project is a key part of your growth strategy, and you've identified that open source contributors of all types are good enthusiasts for you.

• The scientific method is core to your mission, purpose, and/or practices, and you see the benefit of positioning your software toolchain, infrastructure, and other resources as something your users should be able to contribute to and become maintainers of.

• Your organization is one that is open, collaborative, and communal by nature. You may create right-sized open source projects, where the users and contributors are closely aligned in some way. For example, collaborators at a university: If there is no legal barrier to starting a project, why not start one? You never know who might find it and benefit from it in the future.

Building any community is not without its challenges. Take into account the following aspects of communities when defining best practices for an open source project:

• Many people joining are novices. Some need training in the technology being developed, some in tools, and most in how to interact effectively in the group.

• People like to be recognized for their contributions, especially if they are volunteers.

• Non-technical contributions in advocacy and community-building are often unnoticed or undervalued.

• Diversity in gender, race, and ability make a big difference in how useful the product is to broad groups of users, but achieving this diversity is difficult.

If you or your organization find these opportunities appealing—and you're willing to face the challenges that come with them—then building a community may be the right choice for you. Next, we'll examine more closely the work involved with making that choice.

Setting goals and strategy

When you decide to initiate a community-driven project, some of your first considerations will be the mission, vision, goals, and strategic direction of that project. Articulating these things—and writing them down somewhere the entire community can review and comment on them—will likely occupy most of your attention in the project's early days.

Setting effective strategic goals for your project involves asking key questions like:

1. What is the project?

2. Who are the project's users?

3. How do you engage with your user base today?

4. What alternatives to your project already exist?

5. Can you work closely with adjacent projects?

6. What are your goals for the project?

7. Who are your key stakeholders?

The more thoroughly you can answer these questions at the project's outset, the more likely you are to experience success.

Recruiting project members

An effective community requires more than simply opening the door and waiting for people to join. Leaders must look at the skills and knowledge the project needs, research who might provide these, and work to ensure these participants both find the project and consider it appealing enough to join.

To make sure a useful product results from your efforts, consider inviting representatives from any groups who are potentially affected by the project. Affected groups who may benefit from representation include potential users, other technical projects affected by your work (such as projects that depend on yours, or build on it), and people who are currently under-represented in your project's leadership. Project leaders must take explicit action to determine who stakeholders are and to engage representatives of those stakeholders.

The principle behind such engagement is that users, and other groups who may be affected indirectly by a project, have needs that are often hidden from outsiders. Bringing in representatives of all affected groups helps the project produce a more useful product that all can enjoy, and that is fair to all. There is a practical motivation for early engagement too: you avoid the risk that someone will denounce your project at a late stage and prevent its adoption.

Onboarding new members

Leading an open source community often involves taking some responsibility for the project's onboarding experience: the experience new members have when they arrive at the project and seek to get involved.

Onboarding project members often includes the work of:

• Offering some history of the project

• Explaining current project needs and any important debates over project direction

• Helping people locate project communication channels

• Motivating members by explaining the benefits of contributing to the project

• Clarifying meeting times and other time commitments

Building an inclusive project with diverse membership

Leaders and team members of most technical projects lack diversity in race and nationality, in gender (a category that covers men, women, and people who identify as LGBTQ+), and in ability (for instance, blindness, dexterity, or ability to process abstract information). Even if the dominant group tries to be sensitive to the needs of other demographics, they probably don't entirely understand the physical and cultural situations of other demographics enough to represent their needs adequately. Results of the project may turn out implicitly discriminatory unless members of excluded communities are brought into the design.

Building a diverse community can also lead to a more innovative and resilient project. As DeLisa Alexander, former Chief People Officer of Red Hat, writes:

A diverse, inclusive organization is an organization that's more innovative: It can see more angles on potential problems, speak more readily to the complexity of those problems, imagine more intelligent and multi-faceted solutions, and spot the biases in what they're creating. It's also an organization that's harder to disrupt: Enlisting diverse perspectives means focusing additional sets of uniquely-trained eyes on the horizon, scanning for what may lie ahead. While it's impossible to predict all the changes that will impact your organization in a month, a year, or five years, tapping a broader spectrum of insights means you'll be more nimble and resilient when encountering change. And a general spirit of inclusivity throughout the organization ensures that everyone feels both capable of and comfortable with speaking up when they spot potential threats.

That "general spirit of inclusivity" is critical for building open source communities with diverse memberships. Although a code of conduct is critical to welcoming diverse groups, it is insufficient for building a diverse community, because it addresses only negative behavior; it does not necessarily speak to ways leaders and other project members should actively seek out representatives of excluded groups. Some steps include:

• Inviting potentially affected members of under-represented groups onto leadership. People identified as "minorities" tend to get many such requests, and often feel frustrated because their recommendations haven't been followed in other projects. So the person inviting them has to be able to explain the impact of the project and show evidence that their recommendations will be taken seriously.

• Asking project members to identify members of the excluded groups and invite them to the project, or connect them with project leaders.

Although a diversity committee may help to promote the importance of diversity on a project, diversity is the responsibility of every project member and should be considered in every project decision.

Nurturing contributors

Project leaders should watch for ways they can invite members to play larger volunteer roles in the project, hopefully turning the project's users into contributors. When a member shows interest or initiative, the leader should encourage it through a conversation. Invitations to do more might sound like:

• "I see that you took a strong interest in the proposed shutdown feature. Would you join the team working on it? We expect it to require an hourly weekly meeting for four weeks, plus some time for development."

• "You mentioned when you joined our group that you had deployed our product at your company. Could you meet with our marketing team for half an hour to explain how you presented the product and won approval?"

• "I know that in the past you've had success implementing a similar solution with a different group. Would you consider acting as a subject matter expert for our team working on the same issues? They meet next week for an hour."

Note that each request includes an estimate of the time involved. Not every invitation to contribute must include this sense of time commitment, because it might be substantial enough to deter participation. Better to hook them on the important of the task they're being asked to perform. Then their excitement—and hopefully a positive experience working with others—will carry them along.

As with recruitment and other aspects of managing members, development must be done with special and conscious attention to encouraging women and members of other historically excluded groups to flex their muscles in new responsibilities. Never assume that a certain type of person is suited (or not suited) to a particular task. When in doubt, ask.

Guiding decisions and resolving conflicts

Every open source project operates according to a governance model. That model is rarely unchanged throughout the project's history; instead, it evolves as the community grows and its participants determine the best ways to divide work and allocate decision-making responsibility.

Most open source project governance models aim to secure community consensus on key decisions, because open source projects tend to operate best through consensus. "Even when open source governance focuses on membership and voting, consensus is always there, like oxygen in the air," writes long-time community manager Karsten Wade. "People participate by consent—they can walk away if they don't like a decision. Votes usually follow socialization, not directives from leadership. Most decisions are already in agreement before a vote is even called." While achieving consensus isn't possible in all cases, it remains a goal that motivates inclusive behavior from project participants.

Every project operates with different governance practices and mechanisms. For instance, voting can be useful to gauge the mood of the community, but may not be definitive in the way it might be for, say, a parliamentary vote. Other projects relegate decision-making power to a single authority (usually the founder of the project, and sometimes called a benevolent dictator), but this model doesn't always work well over time. That is why many projects form technical and community steering committees to distribute decision-making responsibility.

Community leaders should therefore understand—and work to deliberately architect and refine—the project's governance model so project participants have a genuine sense of agency when working to impact the project's direction.

Recognizing and rewarding community members

Volunteers come to an open source project for many reasons. Experts want to create standards around their practices, students come to hone their skills, and everyone wants to make better technology for the world. But at all levels, people appreciate being rewarded for their work and will contribute more if they feel rewarded.

Leading an open source project often involves developing a system for those rewards. A community's reward system should reflect the project's mission and vision and connect with contributors' motivations for joining. For exmaple, a badging system might help reward contributors seeking public recognition for their good work and help you identify community members who might be able to contribute at higher levels—even become project leaders themselves.

Building project leadership

Getting volunteers to rise into leadership roles is difficult work. Most joined the project to contribute their technical skills or play some other specific role as an individual contributor. They may afraid of the time commitment involved with taking on a leadership role, or see the tasks as boring distractions from what they really love to do. On top of this, leaders are busy dealing with the needs of the project and have trouble finding time to recruit and mentor new leaders. Yet these tasks are critical to long-term projects.

Recruiting leaders is a critical aspect of open source community building. As a project leader, your success depends largely on your ability to cultivate and empower additional project leaders (who then do the same in turn, creating a culture of mentorship in the project). When identifying candidates for these roles, look for members who are asking deep questions, proposing new directions for the project or new ways of marketing it, or other informal aspects of leadership. You can engage them in two ways: you can describe an open leadership role and ask directly whether they would be willing to step into it, or start a dialog where you find out what they want from the project and then encourage them to take on leadership in order to achieve these goals.

Serving in a leadership position is both a time commitment and a serious responsibility, but it's a wonderful chance for growth that everyone should do. Here are some possible incentives you can offer people whom you invite to play a leadership role in your project:

• They have a far vaster scope for implementing the changes they want in the project.

• They can see deeper into the purpose and impact of the project.

• They interact intimately with project leaders, whom they presumably respect and even would like to emulate.

• They learn new skills for project management and dealing with communities.

• Their expertise and contributions are recognized by the community and by outsiders, providing more networking opportunities and personal career growth.

Often, the first question a volunteer asks is, "How much time must I spend?" When responding, don't necessarily stress the time required for the role. Try to help the volunteer think of the benefits to the project if they become leaders, or of the enhanced position they'll have and the benefits it will bring them (and possibly their organization). Don't be afraid to flatter members by explaining how important they are—it's all true!

Many open source software projects tend to focus on cultivating technical leadership, which people usually take on after making technical contributions (e.g., committing code to the project). But there are many leadership roles, including:

• Recruiting project members

• Mentoring project members

• Resolving conflicts according to the project's governance model

• Managing key project resources and assisting others who wish to use them

Upholding community values and norms

When people with shared values work together for any duration, they develop norms that implicitly govern how they collaborate. These norms are the bedrock of any durable community, including open source software communities. Leading such a community will involve upholding community values and demonstrating those norms.

Abuse of community norms should be addressed right away. Ideally, if someone violates norms for good behavior, other members will politely mention that and the violator will change his or her behavior. But in case no one speaks up, or the violator starts a flame war over the behavior (which could exhaust the group and cause even more damage than the original offense), a moderator is needed. And this moderator must have the authority to enforce the norms, even by banning someone if necessary. (That should be very rare.)

It's tempting to divide this moderator role among many people, but there are dangers to doing so. They may react differently to an ambiguous violation of the code of conduct, and might even get into a flame war of their own, which is extremely destructive. It's better to have one moderator at a time (alternating moderators if the job is big), but have the community steering committee review decisions without burdening the membership with the debate.

When the code of conduct is violated in a way that threatens the participation of a community member, or that threatens to degrade the level of discussion, the top priority of the community—and a moderator monitoring the discussion—is to uphold norms and make sure the threat is removed. This usually requires an unambiguous criticism of the offensive statement. However, there are different ways to do this, and an approach that is empathetic to all sides may produce happier outcomes.

Remember that volunteers almost invariably join a project with good intentions, and that many have excellent skills to offer. Offensive statements usually emerge either from strong feelings or from ignorance. While stating that the offensive statement cannot be tolerated, a moderator or mentor can talk directly to the person who made the statement to figure out what triggered it. Usually, the person can be kept in the community and guided toward a better form of interaction.

To repair the damage of the offensive statement, leaders—and hopefully other community members—must declare it out of bounds. But the person who made the statement should—after a personal discussion with a leader—apologize and promise to avoid future behavior of that sort. If such an apology is not forthcoming, the person who made the statement may have to be banned at least temporarily.

A statement that violates the code of conduct should therefore be handled in two stages. First, a leader or moderator must declare that the statement violates the code of conduct and is not permitted. Then a leader should privately contact the person who made the statement and elicit why it was made. Was the person in the heat of a strong opinion? Did they deliberately want to provoke or discourage other members of the group? Did they honestly not realize that the statement was offensive? After determining the reason for the statement, the leader should engage with the person who made it and help them learn how to be in the community productively. The person may have to be banned, though, if they refuse intervention or insist on their "right" to violate the code of conduct.

Managing progress and measuring growth

Hopefully, your investments in an open source software community will lead that community to grow and thrive. As a community grows, leaders must consciously (and conscientiously) manage that growth to ensure the community remains healthy and sustainable.

Measuring community growth and be tricky, but the benefits of doing so are worth the effort required. Metrics play several valuable roles, including:

• Revealing who has contributed, and thus contributing to members' morale and their desire to contribute

• Gauging the effectiveness of the project (e.g., new product features, the rate of addressing bug reports)

• Gauging the health of the project and identifying aspects that need work

Healthy communities highlight people's contributions, because most of them are not being paid to do and have no personal benefit except recognition of their effort. Furthermore, when you know who has contributed the most, you can help people take on new leadership roles and responsibilities. Luckily, software and other text-based projects provide tools that automatically measure certain types of contributions. Use source control, the bug tracker, and other tools to track a few metrics you think are key.

Some of these key metrics might include:

• The number of bugs fixed and the number of changes accepted over a specific time period (it's not bad for a project to have a lot of bug reports. every project has bugs, so a steady stream of bug reports shows that people are using the product—but the bugs should get fixed!)

• Numbers of project downloads (many people download a product to try it out and then discard it, so use other measures if possible to gauge the real growth of the user base—for instance, the number of people participating on forums and the number of questions asked)

• Your community's mix of contributor experience (have the right mix of project members, some who have been on the project for a long time and can provide institutional memory, along with more recent recruits who provide new energy)

Conclusion

This chapter offered an overview of essential considerations one should make when determining whether to start an open source software community and deciding how best to architect that community.