Question:  Has anyone implemented a Wiki? If yes, please answer the following:

The following sections answer these questions. There is a list of Wiki resources at the end of the summary, and an appendix with a press release from a content engineering organization that offers a Wiki-based web site.

What is Wiki?

[Editor’s Note: The following information was copied from]

Wiki is, in Ward’s original description, “the simplest online database that could possibly work.”

Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, “open editing” has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that it encourages democratic use of the Web and promotes content composition by nontechnical users.

What System Requirements Does Wiki Have?

All respondents said that they’re using “old” computers to host the Wiki. Examples included:

    • Pentium III 650MHz, 512MB RAM, 16GB disk (the new server)


  • Pentium II 350MHz, 128MB RAM, 3GB disk (the old server)
  • 386
  • A discarded developer system (probably a low-speed P4 system)


On the software side, you generally need a basic Web server that can handle CGI scripts. The rest depends on the Wiki that you choose. Some Wikis might need to be installed on a web server that has PHP, MySQL, etc. One respondent is using Linux, Apache and TWiki. The system requirements seem to be more about the database underlying the Wiki than the Wiki itself. The best (and possibly only) place to reliably find out what you need is the installation instructions page for any given Wiki. For example, for instructions on installing MediaWiki, see One person said they run a nightly backup of the pages in each Wiki as a cron job.

For the Wiki users, they simply need a Web browser.

What’s the Best Wiki?

General Information:  It really depends on what you’re using the Wiki for, how technical your audience/community is, and how “ugly-tolerant” they are towards presentation. Some software is quite excellent technically, but not that pretty. Others make it technically difficult to add material, but look great.

Each Wiki seems to have it’s own quirky markup for formatting and links. It’s usually pretty simple but some non-technical users might have problems.

Wikis may or may not have memory of changes, and may authenticate people or not, with different degrees of authentication. Different choices will be suited for different kinds of collaboration:

  • The very first and “pure” Wikis offer neither memory nor authentication. Anyone can go to a page and change it or even delete its contents. In practice people tend to behave nicely ( explains why) but you still do not know the history of a page or who wrote what. This is probably enough for small teams.
  • The common public Wikis offer “weak” authentication. Typically you may read pages at will, but you will have to “register” to edit pages. However, the process of registering typically amounts to filling in a form with your name, so you could easily have impostors and rogue users. These Wikis may or may not offer memory for pages: does not, does. This seems to work well for public Wikis, and may work well in a large company.
  • The intranet Wikis provide both memory and strong authentication. They may also provide private pages for a person or a small group of persons. This is important where politics and information control are the norm.

A respondent thinks that there are a few emerging standards: the term “TEXTILE” and a few others have been thrown around.

TWiki:  TWiki can be configured to provide all three modes of collaboration listed above, and even others. One supporter of TWiki believes that having both memory and strong authentication was very important for Wikis to succeed at his place of employment. People are authenticated against the official LDAP database. People gain and lose access to the Wiki as soon as IT creates or destroys the same record that gives access to other company servers. As a consequence, there are neither anonymous changes nor rogue users.

TWiki also provides revision control for pages using RCS. Anyone can contribute to a page, but anyone else can determine who wrote what. This was important to ease the fears of senior SMEs with strong control of information. If they add something to a page, it will carry their authority in a way that anyone can see, separated from the contributions of “mere mortals.” Of course, they don’t contribute that much, but they will ignore the Wiki until it is too late for them to regain all the control.

Revision control is also an amazing bonus for teams. The team (all three of them!) has been using Wikis to track daily work since January 2004. On December 31st, they were finishing the year by recalling all their strategic decisions for the year, and trying to figure out how much progress they did in each. And suddenly they realized that their daily logs (obtained almost automatically just by tracking the status) provided precise information about the concrete achievements that they were just recognizing at the meeting.

Another person chose TWiki because there are lots of plugins and add-ons being developed by the community. And of course the whole system is free but you do “pay” with your time investment. Overall, it’s a good tool. Folks who are interested in Wikis might want to check out

MediaWiki:  One respondent said that they used MediaWiki, but from other friends in the content management industry, this person has heard a preference for DokuWiki. MediaWiki doesn’t do import-export too well yet.

Another respondent spent a great deal of time editing articles on Wikipedia which runs on MediaWiki. This has one of the cleanest, most comprehensive and easiest Wiki interfaces that this person has encountered.

DokuWiki:  One respondent has heard that DokuWiki is much superior to MediaWiki for documentation, since it keeps its database in flat XML files.

How do I Host a Wiki Using My Domain Name?

There are web hosting servers out there that will host a Wiki and use a person’s domain name. has a hosting page for Wiki friendly hosts:

A Google search will also turn up more. If you see a Wiki you like, you can always use to find out who their host is and then contact the host.

One respondent’s web host has phpWiki and tikiWiki installs available. If you have Linux hosting for your domain name, they may have similar options.

What Are the Wiki Implementation Pitfalls?

None of the respondents felt there were any major pitfalls concerning the hardware and software. Wikis themselves are very basic tools. The respondents felt the biggest hurdle was the human factors: gaining acceptance, proper guidelines and use, not getting caught up in the “cool factor”. The main points were:

  • It’s a bit “geeky” and people who are not comfortable in geekdom may push back. The hardest part of dealing with one is getting everyone to sign on to using it. Some people prefer email, some people prefer bulletin boards or public messaging forums. Getting everyone to use the Wiki, which is the only way it will be successful, can be a major hurdle. (There are still people around here saying “I hate Wiki’s” without actually using it, in spite of the fact that our VP is really pushing its use!)
  • A Wiki is only as good as the people who use it. If it truly is to be used as a collaborative mechanism, people need to use it. Write to it. Edit topics. Subscribe to pages. Most of the interesting stuff happens when you get the right people using those basic tools in interesting ways.
  • It is important to remember that Wiki is NOT about technology. Wiki’s allow people to collaborate in new ways. Wiki’s excel at capturing consensus (as opposed to discussion). Therefore, don’t build a Wiki for the “cool factor”. Wikis are a neat bit of software technology, and have a certain coolness to them because they are relatively new to most people. However, there’s nothing like the right tool for the job, and if you have static information that does not change, then a Wiki is nothing like the right tool for the job. On the other hand, if you have what I like to call “fast-moving information,” the type of material that is subject to quick and frequent change or open discussion, then Wiki is a great way to go.
  • Many Wikis simply provide you with a collaboration platform. It’s very open. You have to create a structure by having some agreed upon processes in the team. So, if there’s no plan to your Wiki, it can quickly get messy, out of control, and disorganized.
  • Free support may be hard to use. With TWiki for example, a community support knowledge base is there but not always easy to search. You can post new questions but there’s no guarantee that anyone will actually answer your question.

Would You Use Wiki Again?

Everyone said “yes!” Here are more specific replies:

  • Since the one here at work is still running, I’d say I’d definitely do it again.
  • I am still doing it and reaping the benefits. No doubt about it!
  • I absolutely would do it again, because even though we’re using the Wiki “wrong,” it still is a great vehicle for the type and breadth of information our Wiki distributes.
  • It’s surprising how widespread the adoption has been in our case: support engineers, program managers, even programmers that I thought would be put off by a Web-based tool are actually using the thing! And the way we rolled out was from the bottom up–support engineer got his boss and peers going, and then showed engineering a page where he was collecting numbers on our product’s performance, and engineers just jumped in and added/edited them and so on.

How Do You Use Wiki?

The specific uses of Wiki vary widely, but they can be summarized in these general points:

  • They are all used internally (although some have plans to go external).
  • They are used to collaborate on issues
  • They are for collections of information that change frequently.

Respondents provided the specific usage examples below. After the examples, some responses fell into the categories of using a Wiki for requirements gathering, and using a Wiki for documentation.

Case 1:  We are using TWiki in a collaborative environment of about 50 people. We use it track product requirements, tasks and assignment, test status, meeting notes, and marketing information. This is not our Bug database or our source repository. We use it as a way to put down all the bits and pieces of information that other internal people might need.

It has worked much better than the original rigid database we tried to set up, because it is so easy for anyone to add content and topics and it does not need to fit a rigid database structure.

It is working well in a technical environment where people are OK with using some pseudo code and setting up links etc. Some people use it as a reference point without adding content. We implemented it with one small group, and then let people find it and realize what they could do with it. That worked best in our culture of people who like to explore things. I don’t know how well it would work with people who would be intimidated by the content creation rules.

Case 2:  We use it as the “Apps Engineering” (pre- and post-sales support and marketing) intranet. It has become the place to go for everything, such as:

  • Product updates (from “Whole Product Meeting” minutes to document status and links to drafts)
  • Lists of Open Issues
  • “Who the heck is the support engineer on X product?!

The dream is to make a controlled part of the Wiki available on our external support site as a support database–not much thinking and planning has been done yet.

One support engineer claims to be working a Wiki-based trouble ticketing system, but I haven’t seen anything other than a specification to give me any confidence that it can actually be done.

Case 3:  Internal use only. Currently, our biggest use of one has to do with engineering communications and updates.

Case 4:  Several basic ways:

  • Collaborating on maintaining “difficult” information that keeps changing, that is hard to get, or that you cannot write in a document, typically for political reasons. For example, all the BAD spots in 3rd-party products, with workarounds 🙂 This information nicely complements the official documentation.
  • Replacing email. Altitude had this global email list for technical questions where technical people asked questions related to ongoing projects, such as “has anyone done this before?” With downsizing, many people left, and Altitude was left with lots of personal list archives saying “yes, I did that; I will send you the answer directly,” where BOTH people had left the company (!)
  • Team coordination. I currently run my 3-person team over a Wiki (with RELEVANT CONVENTIONS, of course!). Most of the teams at Altitude have adopted or are considering adopting Wikis for the same purpose.
  • A Wiki area has also helped the official product coordination meetings, replacing the Word-based meeting minutes (always late, rarely read) with up-to-date information (often updated during the meetings themselves).

Case 5:  We have three or four Wikis running, each of which serves as a bulletin board for a particular team or workgroup. The traffic isn’t high (in hits per hour), and there isn’t lots of data (a few MB at most).

We’ve tried out other, more feature-rich Wiki tools. Not worth the hassle, for what we want to do.

To my mind, knowledge management is at the opposite end of the complexity spectrum from the original (and still vital) conception behind Wiki.

Case 6:  We built a Wiki as a “golden path tour” of the available information about a particular project initiative on our internal LAN. It’s strictly internal, and walks developers through the most salient documentation available.

Using a Wiki for Requirements Gathering:  You might institute a Wiki and make it available to the analysts. That way, everyone could contribute and avoid needless duplication. DokuWiki seems designed for this kind of situation.

Using a Wiki for Documentation: There were a few enthusiastic supporters of using a Wiki for documentation:

  • Wikis are great real-time documentation tools. I started using intranet Wikis for contract documentation development projects in 1999. Software engineers take to them eagerly, and even managers chimed in with suggestions. The projects were multi-national, which used to create review, revision, and translation bottlenecks. But the Wikis allowed us to get instant review and approval for milestones and changes, no matter where the reviewers were. They are definitely the bee’s knees for collaborative documentation efforts.Disclaimer: I am so enamored of Wikis that I developed an editing and documentation production tool, WikiWriter at , to bring internet-compatible Wiki production methods to standalone (no server required) and offline projects.
  • I use a Wiki to develop all my technical documentation. I happen to use TWiki, which is quite popular in collaborative business environments. Here are some strong points and benefits to using a Wiki:
    • I access my documentation pages in the Wiki via my web browser. Depending on the day and my appointments, I may be working in my office on my PC, or in a random location on campus, documenting with my laptop. It doesn’t matter where I am because most of the university buildings here have wireless access. (I’m at the University of Illinois Urbana-Champaign). Coffee shops here also have free wireless access.
    • I have a revision history. I can go back and view the first version or any version in between.
    • Since I develop requirements definitions, our Wiki is great because my peers can review the requirements documentation at any time, and comment on it. I work with a small team of four software developers, one project lead / business analyst, and a project manager.
  • One respondent who hasn’t actually used a Wiki for documentation, passed along this information:
  • DokuWiki is at
  • Since the Wiki includes the ability to restrict those who can add, edit or delete to specified users and since it recognizes XHTML, CSS, and various other standards, I think it might be an interesting approach for those activities that want to have their documentation on the Web. Further, it supports printing, and therefore, it should support fairly simple .pdf creation as well. I thought this might be worth looking into, especially for smaller groups and for Web-based products.

Have You Integrated Wiki into Other Applications?

Respondents who have integrated their Wikis with other systems have done the following:

  • Besides Wiki areas (for collaboration) I offer plain file areas (for publishing) and recently a blog area for announcements.
  • Some of our servlet-based web applications access information in the Wiki (treating the content as XHTML after passing it through htmltidy), but the access is by simple HTTP request.
  • We leverage the linking features to integrate the Wiki with all kinds of other materials, repositories, even knowledge management systems.

Before Implementing:  Respondents ranged from “you don’t need to know anything before implementing a Wiki” to the following advice:

  • Voice of Experience #1:  The original Wiki ( has LOTS of information on Wiki deployment (don’t let the 80’s appearance stop you from reading). This respondent started using a Wiki for the team in June 2002, and it was not before January 2004 that it was redeployed experimentally in the company as a solution to the email archive issue.
  • Voice of Experience #2:  Start using a Wiki (any Wiki will do to start). Understand the strong and weak points of the tool. Learn when to use it and when NOT to use it. Choose your tool carefully. Wiki syntax is NOT PORTABLE. If you later need to migrate to a “better” Wiki, you will have to migrate all the contents. Also, you must choose between:
    • Simple (trivial to install and understand, but limited)
    • Complex (not so trivial to install; it is difficult compare complex Wikis to each other and understand their limitations).

    KISS (keep it simple and stupid). Avoid the need to create beautiful pages. It’s about keeping the information organized and EASY TO EDIT. Beautiful HTML pages are IMPOSSIBLE to edit by most people, including very technical people that somehow never found the time to learn HTML. Wiki syntax rules!

    However, make some effort to organize the raw information (which just happens to be a strong point for technical writers).

    THE REAL WORK IS ABOUT PEOPLE. You (the Wiki designer/evangelist/champion/whatever) are not advocating a tool. You are advocating a new way to work. Keep that in mind when people start resisting Wikis; often their resistance is not about Wikis at all.

  • Voice of Experience 3:  It helps to have someone on hand who can tweak the (relatively simple) Wiki CGI scripts to tailor them to your needs.
  • Voice of Experience 4:  This person would have liked to know how to do a lot of things like links, bookmarks, anchors, and categories, and just how bad the search function is.

Wiki Resources