expressed herein are those of the author and do not necessarily
reflect those of HP.
First of all, I'm going to assume that you are already familiar with
what a wiki is and how they are used. If not, and you have any
involvement in IT decision-making, then you must learn more about them. For
starters, read about wiki benefits,
see Wikipedia and try
Some nice features of a wiki (asuming any good wiki engine):
- Very easy to create/edit web pages -- no training or special
- Anyone can do it -- encourages collaboration (though controls can
also be enforced)
- Works with any browser & OS -- need I say more?
- Versioning is handled automatically -- you can easily roll back
changes if needed
- Edit locking is handled automatically -- no need to manually
check in/out documents
Wikis are about increasing productivity
[See also BusinessWeek article: Corporate
Wikis Go Viral]
Remember when companies were first adopting email, and IT departments
were debating whether it should be a standard part of the corporate
infrastructure? A common objection was:
"Why do people need that? Telephones and faxes work fine."
Remember when companies were first adopting instant messaging, and IT
were debating whether it should be a standard part of the corporate
infrastructure? Again, a common objection was:
"Why do people need that? Email and telephones work fine."
The same objection has been made about every major communication or
information sharing technology. But each one serves its own sweet
spot that allows us to improve our productivity by selecting the most
appropriate mechanism for the circumstance. Yes, people can and
with other tools when the most appropriate tool is not available.
result is lost productivity.
Wikis, therefore, are about increasing our productivity, just as email,
instant messaging, telephone and fax are. Each one fills a
communication and information sharing niche. When the most
mechanism for that niche is unavailable, we use others to
compensate. Every week we delay on providing corporate-wide,
standard wiki software translates directly into lost opportunity for
improved productivity. Thus the key questions are:
- How much lost opportunity are we willing to bear while we dither
about whether to support wikis?
- Which wiki software should we adopt?
Wikis versus web sites
Wikis are essentially a low cost, low barrier tool for information
sharing. All teams do information sharing internally, and most
need to share information with other teams. How do they compare
with web sites?
Conventional web sites have tighter control over content, but this is
also a substantial bottleneck that inhibits progress. For
example, due to cost cutting, in HP Software we now have the absurd
situation that to make a simple change to a team web site, the
Compare that with instant updating on a wiki.
- figure out who owns the site (not always obivous);
- ask the owner for the change, whereupon the owner must:
a request to a web developer 12 timezones away;
- wait 48
hours for the change to appear;
- look at the change and notice that it isn't quite right; and
- go back to step 3 and try again.
Wikis also encourage web thinking -- giving documents URLs and linking
information rather than copying and sending information -- which
much broader organizational benefit. A very common means of
information sharing currently is email. But when documents are
emailed around -- MS Word, PowerPoint slides, etc. -- there is enormous
hidden cost. The information sharing is fractured and
inconsistent. Only the email recipients get it, though of course
it can be forwarded, in which case you have no idea who got it.
Good luck trying to find the latest version of the document, or even
knowing whether a document that you still have in your saved mail is
even applicable any more. The email model of information exchange
forces you to guess. Compare this with wikis, which use the web
model and URLs. As a simple example, if you look at the top of
this document you will see that it is trivial to know where you can
find the latest version of it.
Wiki Versus SharePoint
That's a bit extreme, but it does illustrate that Wikis and SharePoint
are different, and hence best at different things. SharePoints
are better as shared file systems; wikis are better at aggregating and
sharing information. A wiki is like a free-form, common
whiteboard, while a SharePoint lke a big pre-configured structure, that
fragments the information into particular structures (lists, calendars,
documents, etc.). Wikis are much simpler to use -- a single
interaction style. Also, wikis
work on any browser, any operating system.
between wikis and sharepoint is that sharepoint sucks.
Wednesday, January 26, 2005
at MSFT. Our intranet is a sharepoint site. Search on it is
perpetually broken. I can't find a damn thing; everything is
haphazardly catalogued in a dozens of folders. The documents are
every format under the sun -- but mostly powerpoints, which are
invariable written in a fragmented, verbless style incomprehensible to
mere mortals. No one goes around updating old or out of date
information. Each page takes at least three seconds to load,
The main point is not that wikis should replace anything else, but that
wikis do what they do better than anything else, and productivity
increases when people can use the most appropriate tool for the job.
Which wiki engine should you adopt?
Short answer: MediaWiki
(the wiki engine behind Wikipedia)
or another engine with the same user experience.
Why? Everybody knows it. Research anything and Wikipedia is
likely to show up in the top 10 search results, and its
prevalence is steadily increasing. According to
WikiCreole, in rankings of wiki engine popularity, MediaWiki is 94
popular as the runner-up (as of February 2007) and
This does not mean
that MediaWiki is the best wiki engine by every criterion. There
are many good wiki
engines available, and you may consider some better than MediaWiki
depending on the criteria
you choose. But questions of feature comparisons miss the
point that MediaWiki is fast becoming a de facto standard, by virtue of
user base. Thus, even though other wiki engines
may gain popularity, because of Wikipedia's use of MediaWiki it is
unlikely that MediaWiki will be displaced. Far more likely is
that MediaWiki will absorb the popular features of other
engines. MediaWiki is open source, highly proven, highly
tested. If there are any features it doesn't have today that you
absolutely must have, then you can add
However, I should qualify this recommendation to note that from the
user's perspective, it doesn't much matter whether the wiki engine you
choose really is the MediaWiki engine or some other look-alike engine,
as long as it presents the same user experience, i.e., the same
rendering conventions and usage pattern. So if another wiki
engine presents a similar user
experience but has additional features that you need, and it seems
scalable, proven and robust enough, then I see nothing wrong with using
19-May-2009: Updated my email address.
20-Apr-2007: Added link to
Business Week article
explanation of wiki engine recommendation