There was a lot of talk about “corporate” or “enterprise” wikis at WikiSym 2008 in Porto, Portugal. The unifying aspect for the wikis “competing” for this space seemed to be their feature-richness.

Here’s a challenge to this concept:

Corporate wikis are a waste of time


Corporate Wiki Properties

What are or ought to be the properties of corporate wikis?




I think the main problem is the decision making process: Someone starts with a list of features and goes to collect more items for that list by talking to other “stakeholders” in the company.

You end up with lots of features, but not necessarily with the features that actually promote participation.

That’s why I guess Oddmuse is not “enterprise ready”.

Here’s how I imagine the conversation going:

We need an interface to the product database.
Hm, did you actually write about any product yet?
Then we could have a form to describe products in a structured way.
Yeah, but did you write a product description on the wiki?
We could produce a PDF document containing our product catalog.
Yeah, but have you actually started to write anything?
But we need to ensure “security” using identity management and permissions.
Does anybody ever write anything on the wiki!?

Ha ha, this is awesome!! :)

I agree with you that actual writing evolution has kind of taken a back seat to feature wish lists (that is because these organizations have tough time committing to what it would take to really use wiki for anything more than a web-enabled word processor).

A few things:

This gets me to some ideas that I am thinking about lately, and have some funds to put towards, adn that is:

How to combine inline annotation (as discussed in ContentAnnotation) with light-weight revision control as featured in wiki engine (DandelionWiki? ).

The purpose here is to:

  1. make it easier to edit pages while you read them
  2. make it easier to merge in changes

For example, with DjangoProject? book annotation (InlineComment??) and instead of arbitrarily making each paragraph a “block” ahead of time, it lets the editor highlight the section they are referring to, and comment on it.

My theory is that the comment window could also include the text highlighted, and allow the person to edit that highlighted “block”, and maybe even track revisions of all of these edits on these blocks (or at least revisions of whole pages).

At the same time, on the TransClusion front, I like the way that Wagn ( ) deals with entries, and combining them together.

This makes me think of kind of a huge tome, with lots of notes scribbled on the margins, fold-up maps and plans sticking out of it, lots of loose pieces of paper and patches stuck between the pages. Actually that’s exactly how my mother’s (main) cookbook looks like, the book is three times as thick as it was originally, with all sorts of notes, old calendar pages, loose pieces of paper, ingredient tables and even labels from products. The up side is that it’s definitely organic and contains a lot of accumulated knowledge and experience. The down side is that it’s virtually impossible to read for anyone except for my mother.

Of course it’s completely different from a clean and lean booklet they hand you in corporations, at least in the marketing department :)

I really like the diagram of Alex about the “full featured” wiki that is usually blocking the ease of contribution. Following my various experiments in the corporate world to introduce wikis, here is the list of issue encountered while pushing the use of wikis (I tend to not agree with all those arguments) :

  • Access control, employee are so use to have user/password credentials while using an application in the corporate world. They don’t understand the concept and sometime are afraid to contribute just because there is no user/password.
  • The collateral point with access control is the idea that all information in the company is confidential by default (the reason behind the access control).
  • The wiki application backend is not a “professional” or commercially-supported software.
  • Employee are afraid to show draft or incomplete work before their release.

(There are more arguments against the use of Wiki in the corporate world but those are the commons I often encountered).

Here is some of the counter arguments used to overcome the previous arguments :

  • Access control is not needed as company run often in island mode. This is an advantage for companies to take the benefit the inner transparencies of wikis while not having the classical issue of the spammers (only applicable to Internet). Openness is applicable without having the Internet issues. (a spammer in the corporate network will be intercepted very early ;-)
  • All information in the company is confidential by default. For my perspective, this is the most difficult point to change in companies. If you look carefully a lot of documents are just fine if they are just limited to the corporate users. The argument of confidentiality is often used to not share document or to be transparent on what you are doing with your colleague. When such confidentiality argument is raised, you should ask for some clear examples to assess that.
  • Regarding the “unprofessional” argument (in my perspective the funniest one), have you ever compared “wiki” functionalities from commercially-supported/proprietary software like Lotus Quickr or Microsoft sharepoint with a standard Mediawiki installation? Wiki are well-designed by people regularly using wiki. The killer test : Are RecentChanges supported? Can you watch/monitor pages? and can you easily have an history of the pages? Usually the community-supported is really winning on this because they know how to do it. “professional” software are usually a mix between a Document Management System, a Content Management System, a kind of weak Wiki and some calendar application. They do plenty of things but they are not focusing on the wiki functionnalities (and they can’t due to the nature of the product/software). Can you run Wikipedia or CommunityWiki in Microsoft sharepoint? of course, you can’t without impacting the ease of contribution. A good wiki is a wiki where you don’t see the wiki backend. Running an example wiki with Mediawiki or Oddmuse can help to show the need for a real wiki.
  • Concerning the issue of sharing draft or non validated information in the wiki, you have often to show that’s a lot of documents are “always” updated and this is a never ending process including documents like policies or even laws (they are not fixed into stone). Documents are evolving and wiki are good to support evolving documents. Another way to avoid that issue, it’s to explain that the draft document are only “visible” (meaning referenced) to the contributors. Other technologies (like CMS or DMS) are used to publish a fixed version of a document.

AlexandreDulaunoy: Employee are afraid to show draft or incomplete work before their release.

This seems related to the “unfinished product” problem mentioned at WysiwygIsntLinking.

Is this the same thing as what Ben Collins-Sussman calls “dropping a bomb”? ("The Risks of Distributed Version Control" by Ben Collins-Sussman).


Define external redirect: InlineComment DandelionWiki CapnDan

EditNearLinks: DjangoProject OddMuse


The same page elsewhere: