Case in point: A contract electronics manufacturer allows engineers in the U.S., Asia, and Europe, plus suppliers, plus customers, to share on-line workspace. It’s that last word, “workspace” that merits even more digerati buzz.

  by Nancy Cohen    
  Enter Michael Schrage, a co-director of the MIT Media Lab, who focuses on shared workspaces as absolute precursors for innovation. If you truly want to collaborate, you need shared space. The shared space, he adds, becomes the medium through which people work and the fundamental source of good ideas.

Schrage often references his Napkin Example. Two people are at a lunch counter. One writes something on a napkin to explain his idea. The other alters the sketch on the napkin to relay that second person’s idea. If a waiter were to come and remove the paper, the conversation would go away.

Schrage argues that you are no longer talking to that other person: You are talking with the other person through a reference point. This reference point becomes the dynamic.

For the hordes of people all over the world who use Wiki, they are apt to argue that Wiki is the best ‘shared space’ going. Wiki is an Open Source tool for collaboration. With Wiki, everyone has edit access to everything. Wiki allows the organization of contributions to be edited in addition to the content itself. “Open editing" means that everyday users create and edit any page in a web site. Anyone can go into a document, make additions, amendments, deletions, edits, and reformats….Scary!

Doesn’t that lead to chaos—or, even worse, garbage? There is a counter-response for those who think Wiki might be an information disaster waiting to happen. Wiki users say, What disaster?

They point out that Wiki has a Darwinian safety valve that makes any Wiki project look less like A Night at the Opera and more like A Day at the Labs. That safety lies in the fact that changes get stored in a log. Another user can come in and review the log and can instantly undo a change deemed as unfit. The argument goes that if ugly graffiti can be corrected in seconds, the third-rate graffiti artist is not motivated to spend hours crafting a badly executed scrawl, only to see it nullified over and over again. The content that survives is the content that everyone has agreed is best.

What's more, instead of having a scenario where one informs an editor of a desired change, and await a series of exchanges, Wiki lets the change-maker do it alone, immediately. This carries with it not only efficiencies but laudable economics, since it pares transaction costs. With Wiki, Brooks’ Law is turned on its ear. The more people looking at something, rather than inviting mischief and errors, leads to a better chance of finding things for improvement.

While it can be argued that only a limited number of core developers lead the way in software design even in collaborative Open Source, Wiki and its clones are proving that a large network of contributors can produce high-quality information in a collaborative environment. “What I find is that people who use Wiki absolutely love it,” says Joseph Cothrel, Vice President of Research at

Not everyone finds it lovable, however (see Desmond Moleski’s commentary). Nor is it something you immediately know what to do with. As the declaration Why Wiki Works explains, “Wiki is an intelligence test of sorts to be able to edit a Wiki page. It’s not rocket science, but it doesn’t appeal to the TV-watchers. If it doesn’t appeal, they don’t participate, which leaves those of us who read and write to get on with rational discourse.”

Wiki: A Vote of Confidence

Kris Buytaert is senior consultant at Stone-IT, a consulting firm in Belgium and The Netherlands.

From my experience, Wiki is an ideal tool for those who want to work together on a document. In its original description, Wiki is described as The simplest online database that could possibly work. At Stone-IT, a consulting firm, we use a Wiki to create a technical knowledge base, where parts of our client documentation are in a Wiki. Our sales force uses the Wiki to collaborate with consultants on proposals. No client ever sees the Wiki, yet lots of information that they are given was actually generated from the Wiki. We find it’s an ideal tool to draft a document and receive feedback.

The term "wiki wiki" means quick in the Hawaiian language and is used to identify either a type of hypertext document or the software used to write it. Often called Wiki for short, the collaborative software application enables web documents to be authored collectively, using a simple markup scheme. The resulting collaborative hypertext document, also called either Wiki or Wiki Wiki Web, is typically produced by a community of users.

What’s its business value? A Wiki isn't intended to be a fully-fledged content management system; it’s a tool to collaborate. Should one even consider it as the way to create a corporate site? Probably not. Neither is it a solution for creating an authoritative support site, since people often don't trust a Wiki. Nonetheless, you can use a Wiki to gather content from contributors and from there create an authoritative document.

For those just getting started, most Wikis have a Sandbox where you can play in, to get accustomed. Many Wikis are immediately identifiable by their use of CamelCase, produced by capitalizing words in a phrase and removing the spaces between them. This turns the phrase into an automatic link.

But backing away from details into fundamentals, what are the actual advantages to be gained in using a Wiki?

It’s the easiest way to edit online: Easy, as in, just go ahead and type your ideas, preview, save, and your page is online, ready for the world to read. If you want to create a new page, just type the name of the page in WikiWord, such as NewPage or DetailedExplanation, into your current text. After you save the page, the Wiki will generate a link for you, follow the link, and edit happily. Can it get any easier ?

It does, if you want to create tables or embed code (C/Perl/...) in the page. There are no extra tools required, just your browser. You don’t need to know anything about HTML or any other W3C standard. There is no problem in uploading your files to the web server using ftp, or secure copy, and no hassle in transferring the files in binary or ASCII mode. You don’t need to remember in which directory you have to put the files.

Or, you can always carry Wiki steps further as a collaboration tool with real Classroom applications, blackboard solutions, where you can work with different people on a “desktop:” Most often a Java applet where your people can follow your mouse pointer.

Yes, there is version control. While some people can destroy the contents of the Wiki without actually intending to, this is not really a problem, since most Wikis support some kind of version control. You can roll back to an older version of a document, before the inattentive user deleted a page. Also, you can lock pages, which means a user can’t edit that page.

While people complain that there is no fine-grained authorization scheme, a Wiki isn't intended to be a fully fledged content management system: It's a tool to collaborate. Next to that, you can protect your pages to some level by obliging your users to log in. You only allow pages to be edited by users that are logged in, and you can even add password protection if desired.

Which Wiki should you use? It isn't easy to migrate from one to another. If you are thinking about setting up an environment where you can easily create documents in Docbook style, check out the Lampadas Project (

Lampadas is a powerful, flexible platform designed to support large documentation projects such as the LDP. It provides an interactive environment for writing, managing, publishing, and reading documentation. They based parts of their environment on the Wiki style of editing but took it even further. The Lampadas project has been adopted by both the Linux Documentation Project and Gnome Documentation project.

As for sites that make use of Wiki, the list is uncountable. There are, however, some interesting ones to mention here as samplings. Their scope and purpose vary.

WikiPedia: As the name suggests, this is a collaborative project for producing a free encyclopedia in every language. They started early last year and already have over 94,000 articles in the English version. Anyone can edit any article without having to log in. A help page carries information on how to use and contribute to Wikipedia. Content is covered by the GNU Free Documentation License.

Reseau Citoyen This is a project designed to create a network for its members.

Linux-Sony Laptop Documentation Site Trying to configure your Sony laptop to run Linux? This Wiki community site is for you.

openMosix The openMosix project has created a Wiki as a place where openMosix users can post additional information to the openMosix HOWTO, the openMosix FAQ, and Add-Ons from the openMosix Community.

The TuxScreen Project The TuxScreen project ( one for running Linux on a StrongArm-based Telephone. It’s using a Wiki for all its project information.

Wiki: A Reality Check

Desmond Moleski is a software engineer at Oregon-based Clarity Visual Systems

Some Wiki users like to talk about a whole new frontier of Darwinian magic taking shape as a result of Wiki collaborations. Software engineer Desmond Moleski thinks not. Earlier this year, he introduced Wiki at his company, Clarity Visual Systems. By year’s end, he's the only one actively using it. With eyes wide open, Moleski explains why Wiki never took off.

Last April, I attended a talk by Ward Cunningham [creator of Wiki] at the regular Portland Linux Unix Group meeting. I'd never heard of a Wiki Wiki Web before that night and I found the idea very exciting.

The malleability of the Wiki is what grabbed me at first. Just smoosh a couple of words together and bingo! A new page, or if you're lucky, an accidental link (Ward's term). As a Wiki author, you can focus on the text you're writing and let the structure emerge as you or others edit and expand the text.

As part of my development projects, I administer an internal Linux test server on which I installed UseMod Wiki in April. For the first few weeks I tried to enlist others in the company to experiment with the Wiki as a collaborative tool, with some success. However, after a month or so I was the only active author of Wiki pages.

What kept Wiki from becoming an important tool for the company? I’m the only application software engineer; a small number of embedded software, hardware, and mechanical engineers round out the technical staff. My goal was (and is) to explore the Wiki concept in action, as well as to enable collaboration.

When I ran around and showed it to people, it was empty. I didn't stop to think and take time to author some clearly useful pages before bothering all the people busy trying to keep the company afloat. I just got excited and assumed a certain cohort would also get excited and then we would all start filling our Wiki with good stuff.

I jumped the gun. An excited geek leaping around spouting abstractions with funny names does not a champion change agent make.

We're a small company. I'm the only deep-geek in it who was fully predisposed to grok Wiki, get excited about it, play with it, and consider that it might be a useful tool.

We're a small company. The bulk of collaborative effort can be handled face to face. If someone misses the conversation, they will get a recap sooner or later. If a document results from collaboration and if it deserves to live, someone just chucks it in the old reliable X: drive, instead of some newfangled web thingy with a funny name.

We’re a small company, struggling in tough times. People are justifiably focused on sticking with what works for them today, with little energy or patience for a new, unproven technology with a funny name like Wiki Wiki Web. (Yes, every possible joke about Dez’s Wiki has been made. Several times.)

You’ll notice that I’ve hammered the phrase "we're a small company." I did that because it's central to why Wiki does not yet work for us. Wiki requires a community of authors to be really successful. As a small company, our pool of potential authors is quite small. They just don't need a tool like the Wiki to get their jobs done.

As for me, I’m going back to do what I should have done in the first place:

Use Wiki to help me get my work done. Find out what works, and what doesn't I could have used a little more step-by-step guidance for the nuts and bolts of operating a new UseMod wiki. But that's trivial, and I should have just spent the time to read the script instead of taking the lazy way out and just firing it up.

Build a repository of useful information, share it whenever called for, but not push it on anyone.

Try encouraging a little “pull" to develop, but not to be disappointed if it doesn't revolutionize the way we work together.