Free and open-source projects are among the most successful ones, and can be uniquely fulfilling for participants. Because these projects rely on healthy communities to get things done, they must consciously carry out community building, including the following practices:
-
Building leadership and preparing for leadership changes.
-
Recruiting, training, and mentoring members, including diverse roles and demographic groups.
-
Decision-making and conflict resolution.
-
Upholding positive norms.
-
Recognition and rewards.
-
Running effective meetings.
Open source helps to remind technologists that community is critical to producing good technology and getting it accepted. This is often forgotten by companies and technologists working in isolation, but if you choose to make technology free and open source, you take a big step toward lining up the people you need to ensure that a product meets a need, has features users want, and is easy to use.
This document 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. We recommend that every project have a community steering committee, which is parallel to the technical steering committee.
Leaders of a community should establish best practices at the start. Trying to catch problems and define norms in a rearguard action is confusing for participants and may drive many away. But while best practices should be made clear, they may also evolve as the community develops.
The following aspects of communities must be taken into account when defining best practices for open source:
-
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 this diversity is hard to achieve.
There are many leadership roles. Many technical projects focus on technical leadership, which people usually take on after making technical contributions. Other types of leadership include:
-
Recruiting project members
-
Mentoring project members
-
Conflict resolution
-
Handling legal and financial issues
The community steering committee can ensure that these activities are done well. In addition, a marketing steering committee can handle the important tasks of public relations, advocacy, and events.
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, and research who can provide these.
To make sure a useful product results from your efforts, representatives of any groups who are potentially affected by the project should be invited to join the project. The affected groups who need representation include potential users, other technical projects that are affected, and people who are under-represented (see the section on Diversity). Leaders of each project 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 a steering committee member should include:
-
Motivating the steering committee member by explaining the benefits of serving.
-
Explaining the meeting times and other time commitments. This should be done within a positive framework, which is provided by the motivation mentioned earlier.
-
Offering some history of the project, which is often not known to new steering committee members.
-
Ensuring that conflicts of interest or other problems will not prevent them from serving.
-
Reminding the member of the project’s legal and fiduciary responsibilities.
-
Explaining current project needs and any important debates over project direction.
Open source projects move along best through consensus, but this can’t always be achieved. The simple solution adopted by many early open source projects, where the final decision is made by a single project leader (usually the founder of the project, and sometimes called a benevolent dictator) doesn’t work well over time. That is why the project should form technical and community steering committees to take responsibility.
Voting can be useful to gauge the mood of the community, but is not definitive the way it is in a parliamentary vote. This is because those who join the project and who vote are self-selected. Therefore, the vote may be biased.
See the section "Enforcing norms" for conflicts involving possible violations of the code of conduct.
Leaders should be on the look-out for ways to get members to take on larger volunteer roles. They should put particular effort into people who identify as members of groups that lack representation (as discussed in the section "Diversity"). When a member shows interest or initiative, the leader should encourage it through a conversation. Possible invitations to do more are:
-
"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?"
Note that each "ask" includes an estimate of the time involved. But sometimes, the invitation shouldn’t mention a time commitment because it might be big enough to scare away the member. 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.
Volunteers come to a 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.
A badging system gives contributors a clear goal to aim for, and marks people who might be able to contribute at higher levels and move into leadership. See [Badges for individuals and projects]() for more about this concept.
Metrics are crucial to determining the contributors to reward. And these must be meaningful metrics that reflect real achievements; otherwise they can offer perverse incentives to do things like make worthless commits. See the section "Who has contributed".
Getting volunteers to rise into leadership roles is hard. Most joined the project to contribute their technical skills, or other roles as an individual contributor. They tend to be afraid of the time commitment of 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 an aspect of member development. 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 join your leadership:
-
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
Don’t stress the time required for the role. Often, the first question a volunteer asks is, "How much time must I spend?" Try to get them to think of the benefits to the project if they become leaders, of the enhanced position they’ll have, and the benefits it will bring them. Don’t be afraid to flatter members by explaining how important they are—it’s all true!
The 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 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.
Although a code of conduct is critical to welcoming diverse groups, it is not enough because it addresses only negative behavior. Leaders 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.
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.
A popular and useful summary of a good community atmosphere is [The Apache Way](https://www.apache.org/theapacheway/), developed by the Apache Software Foundation, which is one of the leading organizations in free and open source software.
Measurements 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.
Luckily, modern tools make it easy to collect many measurements through automated tools.
Healthy projects 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 rise in responsibility in a kind of meritocracy.
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. Lines of code are not a good measure of productivity. But numbers of bugs fixed and numbers of changes accepted could be useful.
Is the project actually contributing to its field? Numbers of downloads are one crude but useful measure. 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, look at the number of people participating on forums and the number of questions asked.
This helps you know whether the project is making progress. It’s also important to 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 blood. The forums should record when people joined and left, so you can develop metrics from that information.
Another important set of metrics concern how many bugs get fixed, and how quickly. 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!
Some resources we drew on to write these summary guidelines include:
-
Overview article: [How To Build An Open Source Community](http://oss-watch.ac.uk/resources/howtobuildcommunity)
-
"[Producing Open Source Software](https://producingoss.com/) is a book about the human side of open source development. It describes how successful projects operate, the expectations of users and developers, and the culture of free software." (From the web site.)
-
"Online communities provide a wide range of opportunities for supporting a cause, marketing a product or service, or building open source software. [The Art of Community](https://www.jonobacon.com/2009/09/18/the-art-of-community-available-for-free-download/) helps you recruit members, motivate them, and manage them as active participants. Discover how your community can become a reliable support network, a valuable source of new ideas, and a powerful marketing force. The expanded second edition shows you how to keep community projects on track, make use of social media, and organize collaborative events." (From the web site.)
-
[The Wisdom of Crowds](https://www.penguinrandomhouse.com/books/175380/the-wisdom-of-crowds-by-james-surowiecki/): A fresh look at how to gather ideas from diverse groups of people, by journalist James Surowiecki. From the website: "James Surowiecki explores a deceptively simple idea: Large groups of people are smarter than an elite few, no matter how brilliant—better at solving problems, fostering innovation, coming to wise decisions, even predicting the future."