why wiki

Over the years I have used various Wiki packages at work and for personal use/freelance. Currently I am using Trac for the freelance stuff, and at work I have tried a number of things, from JSPWiki and Daisy to Confluence. Currently I have been using SnipSnap at work for almost three years, and recently I have installed and configured Trac for our team.

I believe that the biggest benefit of the Wiki is its grass-roots nature, especially when it is being used by a small team on regular basis. I doubt it might ever grow to be “enterprise” in our company for various reasons (even with something like Confluence), but it is indispensable for department- and team-sized work.

Below is a small blog-like post justifying the Wiki for our team.

why wiki

wiki is the simplest possible content management system, collaboratively edited. it works best for creating and evolving documentation. it is not a document storage, but a website where each page is a document.

personally, as i work (do research, jot down ideas, document something), i take notes and evolve these notes using the wiki. i continuously refactor and connect these ideas, thus building content.

most people still do it on their own machines - they edit documents locally, and then they share with others through email and attachments. everyone knows how flawed this is - there are numerous versions floating around, no one knows which one is the latest, keeping track of edits is a nightmare if you have more than two people, finding these documents is hard, etc.

next logical step (which sharepoint took) is to store these documents in a central place. this seems like a good solution on the surface, but it is terribly inconvenient, since these documents are opaque, not being cross-linked together they lack context; in order to view them one must launch an office application, removing the context even further.

with wikis the approach is simpler - my documents are web pages; i edit them in place with simple syntax; i cross-link them easily, thus creating context; they are immediately published and available for others to see and edit. in other words, i build on the foundation that made internet happen using tools that make publishing trivial.

• immediate tangible benefits are live documents - when i pass around the link to the wiki article, it is often self-describing, pointing to the latest version of the article, so i do not have to worry about people looking at the obsolete version of some word document in some email. as an example, when someone asks me a question, instead of putting the answer into an email, i put it in the wiki, then send them a link to it
• i can easily see the difference between documents, since they are just text
• it allows multiple people to easily edit documents simultaneously
• it also allows me to easily build context - cross-link documents and, in this particular tool (Trac), supply them with tags

the idea is to keep content as open as possible, and its editing as simple as possible, lowering the barrier for entry for participants that can help evolve the content.

to summarize, i will quote ray ozzie once again (from his acm interview on social computing):

I think one of the big promises of all of this technology is to make it easy for people to leave trails of artifacts that can be used later when you don’t really expect it.

trac

Trac is a Wiki engine tightly integrated with source control browser and ticketing/issues system that provides a very lightweight (in terms of process) and flexible software project management system. Its main benefit is the ability to put all software project artifacts in context, tying together source code view, changesets, tickets/issues, and documentation.

Trac instance is best scoped per project, thus somewhat limiting its use. With other wiki engines like Confluence, this is not an issue.

Trac architecture allows for a multitude of extensions; it has a vibrant user community, and it has been around for quite a while with a number of high-profile deployments. It is free.

why not sharepoint

sharepoint is a content management system (CMS). for simple “live” documentation described above sharepoint is an overkill - all i want is the simplest possible way to create ad-hoc documents, version them, and pass around simple self-describing references to them (not gargantuan sharepoint urls). i want a simple and easy way to build documentation (or artifacts, in a more general sense) as i work.

in case of documentation sharepoint is somewhat of an inversion of a problem. instead of keeping my existing word documents, what i want to do is create simple documents in place, evolve them, and version them as i work. thus when i browse the site, i want to see content, not opaque document containers. this approach bypasses the office suite, and i can see why microsoft has to be careful not to kill its cash cow by introducing wiki features into sharepoint.

if my needs go beyond simple documentation, sharepoint (especially with infopath) is a tool worth looking into. it makes it very easy to create applications on top of documents, provide workflow, complex user interfaces, etc without any need for coding.

the question really becomes how far you can go with the wiki before you need all the features of sharepoint (or other full-blown CMS). the answer is that for most people a wiki would be perfectly enough; start with the wiki and grow into CMS.