3.1 Technical and social features that foster community

Our study of the Everything2 and Perlmonks sites revealed a number of technical and social features that appeared to play an important role in fostering community.

Technical features include:

  • The chatterbox - a feature that was added to the original site. In both the developer interviews and the editors and gods survey, the chatterbox was mentioned as a feature that changed the feel of the site from a collaborative database into more of a community. Research on MUDs has also found that the ability to seamlessly move between synchronous and asynchronous modes can play an important role in building community.
  • Presence awareness - Similarly, the ability to see what other users are logged on is essential for using the /msg feature, another synchronous-asynchronous link.
  • Homenodes - help users create an online identity. Homenodes were originally resisted by the developers. The ability to decorate a homenode with a picture is a privilege granted to those who have obtained a certain level in the status hierarchy.
  • Internal linking - keeps users from wandering off the Everything2 and Perlmonks sites. Internal linking is also seen as "good form" in developing write-ups, which encourages users to reference other users material.
  • Voting/XP system - plays a number of roles. The system creates interest in the community and helps to socialize new users. It also provides a private incentive for both reviewing the works of others and contributing new content that helps mitigate the free-rider problem.

Social features include:

  • Barriers to entry - While in theory anyone with an Internet connection can join either of these communities, social barriers exist. For Perlmonks, the barrier is knowledge of the Perl programming language. For Everything2, the barrier is the cost of learning community norms, vividly illustrated in our user test by the high number of negative comments the naïve users received on their write-ups. Barriers to entry help increase the signal to noise-ratio of content posted to a community site.
  • Active community management - The voting/XP system alone is not enough to establish the community as a self-regulating system. The community depends on the active involvement of the editors and gods, who put in an average of more than 17 hours a week each, according to our survey.
  • A balance between centralized and decentralized control - While the voting/XP system offers a democratic element, the developers exercise centralized control by deciding what features to introduce and hand-picking editors and gods who fit their conception of what the community should be like.
  • Affective/emotional involvement - Our evidence on this point is largely anecdotal, gathered from our surveys of users and editors and gods. However, the number of times that friendships were mentioned as a key benefit of participation and the existence of "Everything parties" where members meet face-to-face indicates that many members do feel an affective connection with others they meet on the site.
  • Mutual obligation - feelings that broadly resemble mutual obligation were reported by users in our survey. Due to the limitations of space on our survey and the scope of our initial exploratory work, we are not able to speculate more specifically on the types and degree of motivation in this area (e.g., specialized vs. generalized reciprocity, distinguishing between different types of motivations that may bear a superficial resemblance to mutual obligation).
  • A sense of common identity - While our surveys indicated a split between Everything2 and Perlmonks users who thought of their site as a community with specific values and those that didn't, a large proportion apparently do. Site write-ups on what it means to be a "noder" represent an expression and exploration of this sense of identity.
  • Clear benefits to participation - Based on the amount of time users report spending on these sites (averaging more than 8.5 hours a week), becoming an active member of a virtual community entails a fairly significant commitment with high opportunity costs. Participants must perceive benefits that outweigh these costs.
  • Opportunities for the exchange of complementary information - giving and receiving feedback on writing, exchanging programming problems and answers and supplying trivia and answers are all examples of complementary information exchanges - the value of the two pieces of information together is greater than the sum of the parts. Since we are unable to come up with a good counter-example, we suggest that the presence of these complementary relationships may be a necessary condition for a successful community site.

While we are able to identify specific social and technical features that help make these sites work as virtual communities, it is hard to speculate on the interactions between these features and on whether individual features are necessary. It seems unlikely that any one feature alone would be sufficient to develop a successful community. The richness of interactions we observed suggests why "slapping up a Web Board and waiting for them to come" is unlikely to produce a successful virtual community site.

The diffuse nature of topics found on the Everything2 site may also challenge beliefs that successful community sites need a tight focus. Our evidence does not directly refute this point, but suggests that focus may be somewhat loose or at least complex and somewhat ambiguous.

In our introduction we asked two questions that involve generalizing our findings:

  1. "How can community sites contribute to work?" and
  2. "What lessons learned from Everything2 and Perlmonks could be transferred to other community sites?"

The results of our surveys and our discussion in section 2.4 "How Community Relates to Work" suggest that Perlmonks especially and Everything2 more loosely, could be considered communities of practice. The link between online communities and work appears to hinge on the support online communities can provide for the social networks that constitute communities of practice, which in turn enhance the ability of individuals to perform work.

Unfortunately, our selection of comparative sites did not focus specifically on online support for communities of practice and the role such sites can play in supporting work. A comparison with sites such as the Xerox Eureka! Database (intranet) and the Apache Usenet forum might provide a first step towards developing necessary and sufficient conditions for a community site to support work. Ideally, one might also include community sites that failed to support work in the sample as a way of getting at further lessons learned.

The second question about transferable lessons is also problematic. In our developer interviews, they had difficulty offering pithy summaries of what makes their own sites work, citing the complexity of the interactions between features and social dynamics. The success of Everything2 and Perlmonks is also related to certain site-specific conditions, such as the popularity of Slashdot, through which 50 percent of the users first heard about Everything2 and Perlmonks. No recipe for creating a successful online community emerged from our study. Rather, we identified a long list of specific ingredients, which if combined under the right conditions may produce a successful community site. This list of ingredients provides a starting point that might potentially be useful for the developers of future community sites.

3.3 The Future of Everything

As of this writing, the developers of Everything are gearing up for Release 1.0 of the Everything Engine, tentatively scheduled for January 2001. Their attention is focused on documenting, optimizing and benchmarking the code and supporting Perl programmers interested in developing online communities that use the Everything Engine.

The developer's vision for two years in the future is to have a series of sites based on the Everything Engine, demonstrating proof of concept and providing the beginnings of a network for sharing open source enhancements. Their original business plan was based on the idea of developing community sites. Their revised plan is based on supporting the Everything Engine as a toolkit for multi-user site developers. Under this plan, consultants who develop community sites would be their target customers.

Following the Release of 1.0, the developers will focus on marketing the Everything Engine to others. In doing so, we expect they will be asking questions similar to those we have raised: "How can online communities support work?" and "How can the lessons learned from Everything2 and Perlmonks be transferred to other sites?" Their experiences will undoubtedly increase our knowledge of the answers.

We have enjoyed working on this project and look forward to seeing how the future of Everything evolves.

School of Information Analysis of Everything

Log in or register to write something here or to contact authors.