Wiki tools are not all the same

Spam prevention

Another approach is to monitor the content of changes programmatically; typically you do that for spam prevention. Spam prevention is critical on public wikis, especially those that don’t require a login to edit, though almost never an issue on enterprise wikis behind the firewall.

Depending on the service, it could monitor wiki edits based on the content itself (including banned words or disallowed links), or patterns of user behavior, such as excessive activity.

Effectively controlling spam requires the wiki provider to stay up to speed on all the latest anti-spam techniques and algorithms. Few do.

Different scenarios

Enterprises use wikis to accomplish different things, and some tools will "fit" different scenarios better than others.

Some enterprises employ wikis to create an authoritative, "gold-standard" knowledgebase—e.g. for call center use. It is sometimes called a "structured wiki." In this case, you would want to see a richer set of administrative and management services, including potentially the ability to set a controlled vocabulary and easily move pages around. You will also like the ability to output entire sections of a wiki into a print-friendly format like PDF. That is actually a common complaint about certain wiki tools—that they don’t natively generate print-friendly renditions.

Alternatively, you may employ a wiki as a more fluid community of practice. Here, the emphasis becomes less about structure and more about flexibility, ease of contribution and search. Contributors will likely want to attach documents, tag entries and incorporate bookmarks. Surfacing the newest and most active items becomes more important.

Looking at suppliers

CMS Watch divides the wiki supplier community into three broad camps: platform vendors, social software suites and pure-play wiki products (see WIKI sidebar below).

Platform vendors

Those vendors tend to embed wiki services into existing portal or collaboration platforms. It seems they do that as a bit of an afterthought, because customers tell us those wiki services tend to be poorly thought through and not conducive to enterprisewide adoption. Major enterprises commonly plug in a separate wiki service instead.

Social software suitesThose vendors bundle wiki services as part of a broader set of social applications. In theory, that means you can more easily integrate wikis, blogs, tag clouds, profiles and other social computing services. That has real value in a large enterprise. At the same time, most wiki services you’ll find among those tools tend to pale once again in comparison with the best-of-breed offerings we’ll examine next. We get the sense that social software suite vendors include wiki services because they feel compelled to check a box, rather than out of passion for "the wiki way."

Pure-play wiki products

Those are vendors and products that focus intently on providing broad wiki functionality. In most cases, you can find an open-source and/or SaaS version of a particular wiki offering there, although they may be circumscribed in one way or another.

Most of those tools can boast a particular niche. For example, MediaWiki provides a very Wikipedia-like experience, mimicking the platform (for better and worse) from whence it came. Socialtext and Atlassian have ambitions about expanding out to become more full-fledged collaboration offerings, to the delight of some customers and the dismay of others.

Wiki choices and the enterprise

From a platform perspective, many enterprises today do not suffer from owning too few wiki tools, but rather, too many. It’s not unusual in a large organization to see successful (or not) wikis running on as many as five different platforms.

Inevitably, senior leadership comes to see a need for at least some degree of consolidation. But on which one or two platforms do you standardize? That is never a simple answer, especially when you need to address several different scenarios, like software documentation vs. marketing community of practice vs. sales collateral repository.

Some IT leaders try to short-cut the process and simply default to a solution like SharePoint because they already license the platform enterprisewide and assume it will stretch for a variety of different needs. Their colleagues are likely to be sorely disappointed.