A major criterion for graduation is to have developed an open
and diverse meritocratic
community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed
ones.
As a project grows, it needs to renew itself by accepting new
committers. A project needs to learn how it can recruit new
developers and committers into the community. Accepting new
committers usually increases the diversity of the project. So,
this process is very beneficial. Community building requires energy
which could have been spent on code development but this cost
is an important investment for the future of the project.
The openness of the community is not only measured by the
number of contributors. Open and respectful discussions on the
mailing lists are vital. Ways to resolve technical conflict
without destroying personal relationships must be learned.
Mailing lists are the life blood of Apache communities. They
are the primary mode of discourse and constitute a public and
historic record of the project. Other forms of communication
(P2P, F2F, personal emails and so on) are secondary. There are
well founded fears about use of these media for project
communication. Though many projects successfully blend other
forms of communications, care needs to be taken since
out-of-band communications have led to difficulties in the
past. The reason is that communications on other than the
public mail aliases exclude parts of the community. Even
publicly advertised IRC chats can be exclusionary due to time
zone constraints or conflicting time commitments by community
members who might want to participate.
Apache project mailing lists are public, well indexed and well
archived. This allows anyone to monitor (both in real time and
by browsing the archives) what's happening. Opinions expressed
are public and poor behavior risks a poster's reputation.
Private communications tend to be more candid but also more
likely to be ill-judged. Back channel communication tend to be
divisive, excluding some members of the group. This tends to
have a corrosive effect on the collective spirit of the
community. Mistrust builds when opinions backed by blocks of
developers arise fully formed on list.
Communication through other channels also reduces the chance
of serendipity.
As with most social networks, most subscribers to a mailing
list never post and most posts come from a tiny minority of
subscribers. Some passive subscribers are just interested in
where the project is going but others understand related
fields and have a limited intersection of interest. This
second group will often post when this topic arises on list.
Using public mailing lists to develop designs allows the
chance encounter of ideas which often results in innovation.
If alternative forums are used by a project, it is important
to try to minimize the chances of problems arising. All
matters of substance need to be moved back to the mailing
lists. Public records should be kept and posted back to the
list. Regular reminders should be posted to remind people that
other secondary forms of communication exist.
There are a limited number of topics such as security issues
and discussions about people which are best handled in
private. As much business of the project as possible should
take place on public lists but the private list is available
for those matters of a sensitive nature. Good netiquette
requires that permission from the poster should be sought
before making public, posts made to a private list. Try to
avoid cross-posting between public and private forums. Take
care not to post a reply to a private post to a public forum
without permission.
Learning to use mailing lists effectively is very important.
If this can be achieved, then you have shown to be a lively,
active and successful community. The future looks bright.
Guide to successful community building (DRAFT)