Despite the many glaringly trivial uses to which the
Internet has been put, it has also opened up a number of notably
revolutionary new possibilities. Chief among these is its capacity
to remove the barriers hindering the formation of communities among
people separated in time or space. This capacity, if properly developed,
could conceivably change the world. Consider:
East Cambridge is filled with brick industrial buildings dating from around 1900. Each is large enough to hold a company of 50 to 100 people. I was walking around with a friend, pointing to these buildings, and said "isn't it interesting that there were a lot of small companies in East Cambridge even a century ago?" "Those weren't small companies," he replied. "In 1900, a company with 100 employees would have been considered large. Without the telephone, it wasn't really practical to manage a larger organization."If telephones can enable companies who were formerly limited by communication difficulties to sizes of no more than 100 employees, to expand to sizes of 10,000 or 100,000 people, what can the internet do?
Though the internet offers the promise to enable
all the revolutionary applications discussed above, there is a big gap
between the potential and the realization of this promise.
The difficulty is that for an online community to function well,
it needs considerable technological support. Since the members of the
community cannot communicate face-to-face, they need software to record
their interactions and display their conversations in a manner
best suited to illuminating the task at hand. In addition, since
few interactions are so perfect that they do not require occasional
editing, an online community needs to have support for
moderation by a trusted administrator. Since this person's time
is valuable, these moderation functions need to be streamlined
and efficient. With all these requirements,
the task of building software to support the activities
of even one type of on-line community is large, expensive and risky.
The task of building all of these types of communities
borders on the Herculean.
However, the observation I made earlier -- that all these applications
share a common core of requirements -- suggests a way to render this task
tractable: these common functions need not be programmed over and over
again. They can be implemented once and then reused, with suitable
extensions, to form all the varieties of communities discussed
above. There are tremendous advantages to relying on a core system
that is built once and reused. The system can be thoroughly debugged
and user-tested, and if necessary redesigned and retested. Once it is
perfected, it can be quickly deployed in the core of a wide variety of
systems, all of which can be built in fraction of the time it would
take to build each from scratch. The final users of
such a system enjoy tremendous benefits from this strategy.
A common toolkit
will have have a much higher level of support and documentation
than would a program built from scratch for a specific application,
and it will be more robust and error-free.
This translates into higher productivity and fewer hassles for the people
who eventually deploy and manage the system.
Having long experience with the advantages of this strategy, ArsDigita, a web development and hosting company, has developed such a toolkit and undertaken to distribute, maintain and support it. Remarkably, they have also chosen to release the source code, so developers outside of the company can learn from the code and make improvements or additions. Since ArsDigita is growing rapidly -- it has been doubling every six months -- the toolkit's abilities are likely to expand at a similar pace.
The toolkit has a long history. It grew out of code that was written to support photo.net, a site built by Philip Greenspun (who we see in the photo above) to share his photographs and photographic knowledge. Photo.net has grown, with the support of Philip's programming expertise, into an active community of photographers: it currently has over 36,000 registered users. Above you can see the section of the front page of photo.net that links to the database-backed services available to photo.net users. All of Philip's ideas for the design of collaborative communities have been tested and refined during their five years of active use in the photo.net community. More recently, ArsDigita's programmers have incorporated the toolkit into over twenty commercial projects. In the process they have tested and updated the toolkit's capabilities to accommodate the needs of a commercial web site. Therefore the software you see now contains all the best ideas that have survived many years of use and abuse by thousands of enthusiastic photo.net users and some picky corporate customers.
The toolkit has been built as a set of modules so the publisher of a web site can pick and choose those of most use to him for his particular application. The modules that make up the core of the system can be roughly divided into four categories by the functions that they provide within the complete community system. The categories are:
Organizing Static Content and Gathering Community Reactions A web site publisher may have a large body of static content for which he wishes to gather comments and responses from his community of readers. The toolkit allows the publisher to register the entire static content of the site in the database and then gather comments and related links on any page the publisher chooses. In addition comments can be gathered on any reader-contributed items. Set up is simple and the administration pages streamline moderation tasks. In addition, the publisher can protect himself from the embarrasment of dead links with the help of handy link checker scripts. He can also learn about user's interest in his static content by monitoring the search strings with which users have found his pages. Finally, the publisher can assign pages to categories and send mail to all the users who have expressed an interest in any category.
Enabling Community Member Interactions The toolkit provides a large array of modules that allow community members to interact with each other in various ways. For standard discussions, there is a versatile bulletin board system that supports numerous interfaces appropriate to the particular form of discussion. For real-time interactions there is chat module. For contributions that are announcements rather than items for discussion, there is a news module and a calendar module. For users who want to sell items to each other, there is a classified system that can be configured for many kinds of marketplaces and will even support auctions. When users want to check on the reliability of a seller or buyer, they can check out other user's reviews of merchants in the Neighbor to Neighbor service. Finally, if an item gets stolen, the user can enter a report into the Stolen Equiptment Registry. All these modules contain sophisticated administration pages that streamline moderation. In addition administrators can access a New Stuff module that collects all the new contributions requiring moderation together in one place
Monitoring and Encouraging Connections to The Rest of the Web It is part of the nature of the Internet that a web community system will also become part of a larger internet community of related web sites. This category of modules is dedicated to helping the administrator track and manage the flow of users into and out of his site. The referrals module keeps track of all the users coming to the site, and generates reports for the administrator showing their origins and distribution. The administrator can register link in his site with the clickthrough module if he wants similar reports on the distribution and destination of users leaving the site. Finally, if the administrator wants to entice users to visit a different page or site, he can set up an ad server. If banner ads are too ordinary and crass for his tastes, he could instead try out the banner ideas module. Banner ideas are just like banner ads except they present ideas -- excerpts from the destination page -- rather than images to catch the user's attention and induce him to check out the new page.
Managing a Community As anyone who has tried to work with someone distant probably knows, one loses a lot when one cannot meet the other person face-to-face. One of the elements missing in a long-distance conversation is the chance to learn about the history of the other person's interactions and attitudes. Even if not all of that history is directly relevant to the issue at hand, it may help one understand how the other person will react. The community system tries to remedy this deficiency with the Communuty Member History pages. These pages summarize all of a community member's interactions in the community system. Above you can see the version of this page available to a administrator; an ordinary user sees an appropriate fraction of this information. Using this page, the user has a chance to learn what kind of person he is interacting with. Notice that only a fully integrated community system like this one could offer this service, for it draws on information gathered throughout the rest of the system.
The community member tracking abilities of the toolkit also provide a
useful tool to the administrator of the system. This is an important
point: if you are community system administrator and you are
the kind of person who hates to read manuals, then feel free to skip
the rest of this document, but read this section.
The other functions of the community
system are fairly intuitive: you can figure them out if you are
willing to play around a bit. However, the use of the community
tracking functions involves a slightly deep issue of strategy.
Let's say you are a smart
cookie, and so without any guidance you figure out how to set up all
the interactive modules, you register your static content to gather
comments and links, you get the referral and clickthrough modules
chugging away gathering data for you, and you figure out the
moderation functions so you con ensure that contributions are
polite, relevant and informative. You're all set, right? Your
community system will be the envy of all your neighbors, and
you will start raking in the internet profits? Unfortunately, probably not.
For a while everything will work well, but after your community
system starts to grow beyond a certain size, you will find yourself
in trouble. Philip describes the problem (with which he
is well acquainted from personal experience) in the
chapter of his book entitled Scalable Systems for Online Communities:
Site growth can outstrip the capacity of any person, no matter how
dedicated or efficient.
One typical reaction on the part of the publisher is to turn the
formerly non-commercial site into a showcase for whoredom. Users
return to find six banner ads on the home page and links to kickback-paying
referral partners obscuring content that had formerly been highlighted
in relation to its utility. With all of the money flowing in, at least
the publisher's scaling problems are history. More users means more
page loads means more banner ads served means more revenue. The
publisher can hire a discussion forum moderator and a customer service
staff. Money can be used to hire writers and a webmaster to organize
their contributions. The content may be bland and tainted by commercial
interests, but at least the publisher is making a fat profit.... Oops! In
practice, nearly all commercial community site publishers are losing
money because the cost per user to maintain the site is too high.
Corporate intranet communities also need to scale. It really would be
sad to have to hire a new moderator, webadmin, or sysadmin for every new
employee. Yet the intranet community should be as vital as any public
community site. If an employee sends another employee private e-mail
asking a how-to question, that should be regarded as a failure of the
intranet community software. Why wasn't it more efficient for these
folks to collaborate using a Web service that would then archive the
discussion?
The Big Problem
Thousands of people are operating public community-style Web services.
Virtually all of them are using simple standalone software packages to
handle things like discussion forums or classified ads. When one of
these sites becomes popular, the publisher begins to devote 80 hours a
week of free labor to moderating discussions, weeding out redundant
classified ads, deleting alerts for users whose e-mail addresses have
evaporated, answering questions from the confused, keeping content
up-to-date, developing new content in response to user questions, etc.
The beautiful thing about this is that so many people are willing to
devote 80 unpaid hours a week toward helping their fellow human being.
The ugly thing about this is that 80 hours a week turns out not to be
enough.
So here is the Big Problem. What is the Big Solution? The key idea behind the solution Philip has in mind this: the administrator needs to stop thinking about merely managing the interactions between users, and start thinking about managing a community. What does this mean? Since this is an important and subtle idea, I will illustrate it first using a simple example from the physical world. Suppose (hypothetically) one has the job of keeping up a public park. This job might involve spending a lot of time planting flowers and scrubbing graffiti, and these tasks might get tedious and onerous after a while. So alternately, one could start paying attention to the visitors who came to the park, and try to identify from among their ranks the nice old grandmothers who would like nothing so much as flower bed of their own to plant, and the wild hooligans who would like nothing better than a park bench to cover with graphitti. A small amount of effort spent promoting grandmothers to fellow flower planters, and encouraging hooligans to find other canvases for their artistic endeavors, can save one a lot of flower-planting and graphiti-scrubbing effort. This example encapsulates the basic idea of managing a community: you can save yourself a lot of work by learning about your fellow community members, and granting the most helpful of them authority to help maintain the community, while effectively protecting yourself from the harmful effects of the most destructive of them. The power to learn about the other members of the community and to use that knowledge to ensure that the site remains managable as it grows is the Big Solution which Philip has in mind.
Naturally the community system toolkit provides a number of functions to support this solution; the Community Member History pages are only the beginning. Philip has built a Member Value system, which the administrator can use to "charge" (with imaginary or real money) any user whose actions cause him trouble. Helpful users can get negative "charges" too, so by tallying up the user's totals, the administrator can see at a glance how helpful or difficult a user has been. In a publishing site like photo.net, helpful users can be promoted to co-administrators, while difficult users can be charged (with real money) or banned from the site.
In addition, the toolkit has a User Group system. In photo.net, the administrator uses this system when he assigns a user co-administrative authority. However, the capabilities of the user group system are much more extensive than the simple use to which it is put in photo.net would indicate. It stands to reason that a community toolkit needs a fairly elaborate User Group system. Communities tend to form groups: groups with similar interests, groups with similar privileges, and groups with similar responsibilities. Any system which attempts to recreate communities in a virtual world needs to support the grouping of users. In a later section we will discuss how the User Groups system can be used by the administrator to implement the philosophy of managing a community.
Though the toolkit was built for photo.net, this philosophy of administration is relevant to many other kinds of sites. In fact, when I talk about a common core of functions that every collaborative system needs, it is these user-tracking functions that I am thinking about above all. (However, remember that these functions depend on the integrated working of the rest of the system.) A system may or may not run a classifieds service, but it will always need a user model. In addition, the administrator's user-tracking tools are useful in almost all sites. For example, the original member value system was built by Philip to save himself from a moderation nightmare in his photography on-line publishing site, but it is equally useful to an ecommerce site to save themselves from a customer-service nightmare. In the chapter on ecommerce , Philip describes the incarnation of his member value system that applies to an ecommerce site:
So the basic philosophy of community administration that Philip developed for his publishing site is well known (under a different name) in the ecommerce world, and it applies equally well in this context. The same member value code Philip developed to manage users in photo.net can be equally useful in the context of an ecommerce site.
I have discussed how this administrative philosophy is useful for publishing sites and ecommerce, but I still have yet to explain how it might be adapted to company intranets and, in general, to sites devoted to helping people work together. From Philip's comments above, it is clear that he considers the problems of administering corporate internets scalably closely akin to the issues encountered by photo.net. It is all part of the same Big Problem, and the basic philosophy of the solution is the same. The specific strategy, however, is slightly different. In these cases the problem of controlling the damage done by malicious users is probably less of an issue, because the community members are already chosen to be at least slightly trustworthy (hopefully!). In addition, employees would probably be insulted if they heard that their bosses were measuring their "member value" and tabulating the monetary value of their sins. However, the problem of granting community members varying levels of access and authority may be much more of an issue in a work environment. Photo.net can make do with the two levels of access allowed by each module -- ordinary user and administrator. An internal company project may call for many more levels of permissions and authority. Therefore the sophisticated features of User Group system come into play. The User Group module allows for many levels of permission associated with various roles within a group. One can use the User Groups module to build a system which allows users to be promoted up a long scale of increasing authority as they proved their worth and competence in a project. Using this system, one can manage the community by increasing the access level and authority of the most expert workers, while denying the less careful workers the opportunity to do any damage. To see an example of the full power of the User Group module, see the description of the iMedix project in the next chapter.
