Pondering the wiki trough of death

Christopher Allen led an interesting discussion this past week at the Online Community Unconference on The Numbers of Trust (or something like that). He covered many of the topics, Dunbar's number, effective group size, research from WoW gilds, etc. that he used to discuss on his blog Life with Alacrity.

The discussion turned to the observed problem that wikis go through as they begin to scale. When they are just starting, and there are small numbers of people, wikis go through a rapid growth phase. The wiki-way of working is comfortable because the group is small and everyone knows and trusts each other. Ideas just explode. As more people come into the wiki, however, the level of trust begins to diminish and the growth begins to slow or stop. If the wiki doesn't completely fail at this point, if you can manage to keep it going long enough to make it through the "trough-of-death," then they bloom like nobody's business. Think Wikipedia, think Reed's Law.

So what happens to kill wikis as they transition through the trough-of-death? As the wiki grows and more people come, things start to get messy. This is where people want to try to "engineer" solutions. Often people want to control the new comers-- they don't trust them mostly because they don't know them. In our conversation at the Online Community conference we were calling this a "wiki-hole", but as I thought about it I think it is better described as a "wiki-trough". The trough is a dangerous place. Many (most?) enterprise wikis fail at this point.

These are some of the things that well meaning people try to do to get a handle on the messiness. They think they are doing things to help their wiki succeed when in reality they are accelerating its demise. These are all bad:

• introduce a hierarchy-- bring over the old organizational structures
• credentialism-- declare that only people with a certain expertise can contribute
  
• authority-- put people "in charge" of sanctioning things as worthy
• access control-- create permissions to view, edit, work flows...

All of these things work to diminish trust and enforce the old organizational ways of working. It's that definition of insanity at play, doing the same thing over and over and expecting different results... These old things conflict with the very values "baked-in" to the wiki: transparency, trust, flatness, inclusiveness... When you mess with these things you'll never make it out of the "trough-of-death." These things send people away at the very time you're needing many more people to join your effort. This is why I don't buy into the concept of an "enterprise class" wiki-- different values and different "features" for organizational use versus what people might use in a public setting. People are people whether they're working in an organization or doing it as part of a public project. People's motivations, desires, wishes, dreams don't change when they go to their workplace. We are not schizophrenic. There is not a work psychology and then something else for the rest of our life. Our work and personal lives are not separate. Motivation is motivation.

So the bottom-line... if you don't screw-it-up and try to over-engineer your wiki upon entering the "trough-of-death," you just might come out the other side and create some real organizational magic. You just have to have the guts to leave it alone when everyone starts clamoring for more control. If you try to fix it you will break it for certain.

Another wiki: McCainpedia

An interesting use of wiki technology: McCainpedia Yep, yet another MediaWiki-based site. I tell you, the MediaWiki network effect cannot be ignored.

It also sports an attractive design-- took me a while to realize that it was indeed a MediaWiki site. The site does have one fatal flaw:

While its name is partly inspired by Wikipedia, the community-written encyclopedia, the McCainpedia is read-only for members of the public, prompting technologists to criticize the site for violating the community-driven ethos of Web 2.0. Given the polarizing nature of elections, the DNC says it is keeping editing in-house to "fully validate all of the information that appears, ensuring accuracy and reliability."

Oops, someone doesn't understand what social software is all about. Once you break the conditions you're toast. No scale... I'm thinking a wiki might have been the wrong technological choice for this site.

Google Maps gets wikified

Google has opened Google Maps to the world to annotate: It's your world. Map it.

Now in the U.S., Australia, and New Zealand, you can log into your Google account to edit a place on the map. You can even mark that a business has closed to save someone an extra trip. Of course, we've taken steps to help protect accuracy -- for example, you'll still be able to see the original listing information along with the history of changes made.

That is so impressive. Google has taken a very successful product and turned it over to the people as a wiki. That takes guts. My hat is off to Google!

Above the flow

I found a new blog through Andrew McAfee that I am rather liking: Transparent Office. The blogger, Michael Idinopulos, works at Socialtext, and the blog is focused on the use of social software in the enterprise. One of his very first posts addressed the concept of in-the flow versus above-the-flow kind of work.

In the old world of emails and knowledge management systems, our tools and processes force a rigid distinction between "doing your job" (i.e., in-the-flow activities, usually in email) and "giving back to the organization" (above-the-flow contributions to a knowledge management system). That framing of the issue ensures that people will spend almost all their time in email and very little time contributing knowledge--hence the "culture and incentives" problem that has bedeviled Knowledge Management since the very start.

Too often we approach knowledge management tasks from a naive perspective. We approach it as a Field of Dreams type of problem, if we build it they will come... The problem is, it doesn't matter what you build (i.e. what tools you use), because it's a far more complex problem than just providing the means to manage knowledge. You have to first address the will, the incentives, the really big questions.

Reading Michael reminded me of the Dave Snowden interview that I had posted about previously: The Impact of Web 2.0 on Knowledge Work and "Knowledge Management"

One of the things I've always argued very strongly is that you shouldn't provide any incentives to knowledge work because, for example, to reward people for contributing to a knowledge management database fails to understand the basic trust implications of the knowledge interaction. If you ask me for something that I need in the context of genuine need, very few people if anybody other than the obdurant is going to refuse to give it to you... but if you ask me to share my knowledge in anticipation of possible need in the future by somebody I don't know, then you're never going to get it. It's the immediacy of the context that matters.

Here we have three people (McAfee, Idinopulos, Snowden) with expertise in enterprise knowledge management telling us it's an almost impossible task to accomplish. It's a very complex issue that defies overly simplistic attempts to try to explain away failure. What makes it more difficult is trying to find some places where it has worked in order to try to replicate success. It's almost impossible to find above-the-flow success stories beyond the large scale open example of Wikipedia.

A new medical wiki from Elsevier

Elsevier has started a new medical wiki called WiserWiki. Where it can be read by anyone it can only be edited by board certified physicians. The site was seeded from the Textbook of Primary Care Medicine.

WiserWiki is provided as a free service by Elsevier. As the leading global publisher of science and health information and tools, Elsevier serves more than 30 million scientists, students, and health and information professionals around the world. We are proud to play an essential role in the global science and health communities and to contribute to the advancement of these critical fields. We continuously make substantial investments that serve the needs of the global science and health communities. To find out more about Elsevier, please go to Elsevier.com.

This is another major wiki project based on Mediawiki which has become the software of choice for managing the world's content. The network effect is in full bloom.

It'll be interesting to see how physicians take to this effort. I see two potential problems. First, the copyright of the site is very different than you see in most wiki projects. Elsevier is not releasing the content to the commons. Will that be enough to tip the trust equation so that others won't contribute? Second, I wonder how they are going to authenticate the physicians who decide to participate? How are they going to determine that someone is indeed a board certified physician? Will the vetting process alone be enough to deter people from jumping in to contribute?

Regardless, I think this is a cool project. Where I think they could have done some things differently, I'm most definitely hoping they succeed. It would be nice to see many more efforts such as this.

Google wiki coming soon?

Read/WriteWeb: Coming Soon to a Google Apps Near You: Wikis

A Google wiki would be awesome. Can Google do for the wiki what they did for the feed reader? Move wikis from geekdome to mainstream?

In spite of the massive success of Wikipedia, wikis still have a reputation as a geek tool. We've known since last October that Google had something coming in the wiki arena. When Google finally rolls their wiki out it could change that perception big time.

Wiki raids

I saw this on the Green Chameleon this morning: Thinking About Wikis - and Wiki Raids. The problem of getting people exposed to wikis for the first time is not insignificant. Obviously, their power comes from a group working together to pound out something new. When used correctly they are nothing short of phenomenal. If you haven't experienced this magic first hand then you really can't understand the power. This is all about being the ball. If you haven't been there I don't think you can understand it.

So, when I saw this piece on wiki raids it definitely got my attention. This is a nice prescriptive approach to a quick and meaningful wiki experience. We'd talked about having hackfest types of events to get people exposed to working in wikis, but this is so much simpler and better. The recipe:

And here’s a recipe for an activity we tried some months back for a group that wanted to start using a wiki to draft a new set of policies collaboratively, but (a) weren’t too familiar with wiki technology and (b) weren’t too familiar with the new policy template they were using.

1. Invite the drafting group to a half day “wiki raid” in a meeting room with intranet connections and one PC/laptop for every two people (or they can bring their own).
2. Have the policy template set up on a wiki, with each section on a separate page.
3. Working in pairs, the participants each take one section of the policy paper and start drafting.
4. After 20 minutes, get them to save their wiki page and move to another section drafted by another pair, which they refine. (Be consistent about which direction they are rotating in).
5. Repeat.
6. Repeat.
7. Do a spot review and identify the sections that have most work left to do.
8. Repeat the cycle, working on those sections.

Result? By the end of an afternoon you’ll have 90% of a policy paper that might have taken endless committee meetings and draft-bouncing over several months. Oh, and they’ll have figured out how to use the tools.

That sounds very cool. I so want to try this...

Innovative uses for a wiki

The Web Worker Daily has a good article on innovative uses of a wiki: 15 Productive Uses for a Wiki. I know I use our wiki for almost all of these except those that are more "business" specific.

But online organization doesn’t have to be complicated. There are many tools for organizing all our stuff, of course, but one of the simplest is the wiki.

What do these medical wikis have in common?

Science Roll has a good article on Medical wikis: the future of medicine? It details twenty-four wikis in the medical field and makes for some interesting reading. What struck me as significant, however, is the software being used to drive these sites. Twenty-two of the twenty-four sites are powered by MediaWiki.

Wikipedia continues to get all of the attention by the media, but the importance of MediaWiki to that story is being missed. I've mentioned the network effect occuring around MediaWiki in the past, and it looks to me like the trend is accelerating. The growing role of MediaWiki in managing a good portion of the world's knowledge is a significant story that is going untold.

Send2Wiki

Check this out, Send2Wiki. Basically you install the bookmarklet in your toolbar. When you find a page on the Web you like you just click the bookmarklet, and it will convert it from HTML to Mediawiki markup, and then creates a new wiki page. I tried a couple of pages and it worked very slick. It also had some language translation which I have not tried yet.

Wiki Rule #1

Wiki Rule #1: If you have never worked in a wiki before-- do not start by making rules.

More wikipatterns goodness

I mentioned this wikipatterns site in my last post but wanted to return to it for some discussion. If you have a wiki in your organization this is a must read site.
A few items caught my immediate attention. The empty pages problem:

Talk to the person who first created the page, and see if s/he knows that it's sitting empty. If the person has forgotten about it, this will probably be enough to jog their memory and get them to add some content. You might suggest posting a scaffold at minimum, so that others know what to add to the page.

I'm happy to see that most of the solutions suggested at wikipatterns involve having a conversation with the contributors. I'm convinced that this conversation piece is the most important aspect to creating wiki magic. When people know that others are watching and that they are there to help, it can make all the difference in building a thriving community. You just can't let people struggle. You need to be there to coach them every step of the way. You really know you are starting to succeed when the people you've coached begin to coach others.

There there's this thing about sandboxes:

The sandbox pattern involves creating a page, often called a sandbox, and encouraging others to practice wiki editing on this page. The problem with this is:

• It distracts people from editing pages containing real content
• It makes people afraid to edit the 'real' content.
• it gives the impression that a wiki is complicated and has a steep learning curve.

Now that's interesting. I'm thinking they may be right. People mostly want a sandbox so they don't expose their learning in the history of a real article. So what difference does that make? Who cares if the history is cluttered? What's wrong with showing others in a public place that you are trying to advance your skills? What do you think - does having a sandbox hurt more than help?

Finally, there's this concept of a BarnRaising:

A wiki BarnRaising is a planned event in which a community meets at a designated time to build content on the wiki together. One person alone can't build all the content in a wiki, and a community of people needs to understand how to use the wiki, and feel a sense of buy-in for it to become successful. A BarnRaising achieves this because people come expecting to learn how to use the wiki, and they are able to interact with each other as they work, thus strengthening community bonds and creating a support network that keeps people using the wiki.

When we started our wiki we talked a lot about having something like a hackfest. Of course, we knew we couldn't call it a hackfest, and we spent a lot of time trying to come up with something better. BarnRaising is perfect. Now we need to follow through.

Embracing wiki chaos

I came across this quote by Ken Tyler while reading the post about wiki patterns :

It's best to start with as little structure as possible and only add more structure when it proves to be needed.

The quote wasn't sourced with a link so I went searching for Ken Tyler and came upon Seedwiki. I'd looked at this before, but it'd been some time ago. Seedwiki allows anyone to create a wiki on any topic they want. It's basically anything goes. What blew me away though was the homepage. Now, y'all know that I love a good tag cloud, but this is pure nirvana.


After navigating Seedwiki a while I soon realized that structure is never needed. This is the future of knowledge management. Linear thinkers need not apply.