Building Online Communities
Pages: 1, 2
The Bell Curves
You will never please some users. A few will stick around only to see your next mistake. They tend to be vocal. Their pessimism doesn't make them wrong, but it can be grating. Accept that they are a minority, expect them to make concrete suggestions and honest criticisms occasionally, and try not to be surprised that they don't leave. (Most people who leave do so quietly.)
Some people will almost always be happy -- no matter what you do. If their feelings fade, they will withdraw emotionally. They tend not to be as vocal as the pessimists. A sub-group of these people have just discovered online communities or your specific community and still have glory in their eyes. They propose grand ideas and volunteer for great schemes. Harness this energy and exuberance into realistic channels.
Most people participate on the fringes. Most people read and never write. Most writers write only occasionally. Most community members have opinions about the various discussion topics but rarely speak. Don't rely on declarations of undying platonic love. Learn to find esteem in steady growth and repeat users.
Eschew the idea that loud dissent from a few corners automatically condemns an idea. Do rely on the opinions of trusted community members. Don't weigh opinions solely on participation metrics. Some of the best contributors listen and think far more than they speak or type.
Take these as fallible rules of thumb, though. Just be realistic about the actual community.
Barriers Are Mixed Blessings
The number of active community members varies inversely with the amount of work necessary for an initial participation. Requiring e-mail confirmation before registering a username prevents users from creating blank account after blank account. Of course, there are hundreds of accounts on Perl Monks where the user has never even logged in after creating the account.
These rules strongly apply to e-mail lists and Usenet groups. Even on
unmoderated lists, readers dramatically outnumber writers. For a group such as
A Word A Day subscribers, it's helpful to
compare the size of the subgroup that participates in author chats to the
entire subscriber base. Hitting
Reply to address an entire group
can be psychologically daunting.
The First Contribution
The easier it is to join a conversation, the more visitors will become contributors. Communities that allow anonymous participation tend to see greater numbers of initial contributions. This varies with the nature of the community -- it's easier to post to several Usenet groups at once than to subscribe to an opt-in, moderated mailing list.
Adding features to encourage registration (or to discourage anonymous participation) acts as a filtering process. This is a mixed blessing. Several Perl Monks have called for the end of anonymous posting. This might reduce drive-by posters who ask questions, request followups via e-mail, and never return to the site. On the other hand, several regular contributors first tested the waters by posting anonymously.
Address the issue of anonymous participation early in your community's lifecycle. There are no hard and fast rules. Sometimes it may be better to weed out casual or lazy users by requiring e-mail confirmations. This does not always apply. In particular, cypherpunks and anti-spam activists prefer their privacy. Other communities may find that registration adds another welcome level of accountability.
Registration should benefit the users. Slashdot users customize the comment display and write journals. Perl Monks track their replies and send and receive private messages. Use Perl users post comments and receive messages when their friends use the site. Advogato users rate each other on their perceived contributions to the cause of Free Software.
Requiring registration can cull potential mischief makers, too. Even pseudonymous users with a sense of responsibility may be deterred from causing trouble by losing face in the community. (This doesn't always work, as bad is good at Badvogato.)
A strong community can overcome technical limitations. It's possible to write a Wiki or a weblog in under a hundred lines of code. Simplicity may appeal to some users. The lack of sophistication (reply notification, searching, revisions, and access controls) may put off some users, and an ugly or awkward user interface may get in the way sometimes, but a community can grow in spite of the mess.
It's worth making things simpler and more consistent, though, especially for Web-based message boards. While social benefits may persuade people to put up with and to learn to love the quirks of an awkward posting system, too much perceived complexity (or user hostility) caps the rate of new members. Woe be to the perpetrator of any user interface overhaul, though. (See the notion of "ownership" above.)
Like any community, your group will have spats and factions and frictions. These must be handled wisely for the community to survive. Plan for trouble, though you cannot tell when or where it will strike. Set simple rules. Make them explicit. Apply them consistently.
Start with a list of unacceptable behavior. This will probably include harassing or attacking other users, posting copyrighted or plagiarized material, straying from the topic, and abusing the system with multiple accounts or robots. Create a list of consequences, which may range from warnings to suspensions to expulsions. Communities with a ranking or levels system might use demotions and the loss of privileges. You can ignore, obscure, or delete potentially illegal material. Choose your response before it's needed.
Some communities find a community judgment process effective. Editors on Perl Monks find a rough consensus before exercising their authority. Monks in good standing vote as to the best way to handle potentially troublesome content (poorly formatted, posted in the wrong section, a true duplicate, or containing malicious code).
If possible, avoid giving the impression that the rules are a game. People like to push the boundaries, and some users only participate to provoke responses in others. Constantly changing the invisible rules under the hood may, if this leads to visible effects for normal users, lead some users to experiment to find and to exploit the actual rules. Apply the rules consistently and calmly and you will remove many psychological rewards for deliberate infractions.
Whatever you decide, keep the rules simple. Make them readily available, so no one has an excuse not to read them. Enforce them consistently but not harshly.
Discuss the Community Openly
Even if you have a legal or moral right to change the structure of the community, you may not have the necessary social capital. Change is difficult. Sudden or dramatic changes are often threatening. Change is also unavoidable.
Remember the perception of ownership and the bell curves that categorize community members. Any change you make (or don't make) will offend someone, and you'll hear about it. Be honest and open about your plans as early as possible. You may be able to harness the best minds of your community to develop better ideas.
Realize that the community itself will occasionally be a topic unto itself. Perl Monks has a discussion section for debating site suggestions and improvements. The extremely rare Slashdot stories about Slashdot garner hundreds of posts. It's not healthy to navel-gaze, but occasional meta-discussion clears the air.
Don't Stop There!
Even if you have graduate degrees in sociology and psychology, the dynamics of human communities will still surprise you. Be very clear about your goals and the rules. Manage your expectations about user participation and groups wisely. Allow a little chaos. Use your common sense and best judgment. If there's an audience for your conversation, you'll find a community.