E-MailThe Wiki Phenomenon
Domain
Innovation
Assertion 151
The application of wikis will increasingly infiltrate forward-thinking, mainstream enterprises in the form of applications that will save these companies money and enable them to collaborate, and therefore innovate, in new ways.
Contents
- Opinion by Ed Yourdon
- Concurrence by Tom DeMarco
- Concurrence by Tim Lister
- Concurrence by Christine Davis
- (Grudging) Concurrence by Lou Mazzucchelli
- Concurrence by Lynne Ellyn
- Partial Dissent by Ken Orr
- Partial Concurrence by John Tibbets
OPINION BY ED YOURDON
Just over a decade ago, software engineering author/guru Ward Cunningham created the first "wiki" -- a special kind of Web site that allows users to quickly add, remove, or edit content without time-consuming approvals or bureaucratic "moderation" protocols. Cunningham has observed that his interest in wiki technology dates back to the late 1980s, when he distributed materials to friends and colleagues using Apple's HyperCard (a forerunner of the Web's paradigm of URL-connected pages).
While wikis have been around for more than a decade, and the largest of all wikis -- the online encyclopedia Wikipedia -- was launched in January 2001 [1], it has been only in the past couple of years that research groups, professional organizations, and even mainstream business organizations have begun to recognize the potential of wikis to support collaborative research and open source innovation of products and services.
Of particular interest are the wikis that represent true collaboration: individual contributions to a joint product, such as Wikipedia, or synergistic interactions between individuals that allow for a "2+2=5" creation of an idea or a product that could not have been developed by any of the individuals on their own. Many of these wikis -- including Wikipedia itself -- are "community" efforts, or collaborations between academic researchers, hobbyists, or individuals who simply share a common interest in some subject (e.g., football, antique cars, the Beatles).
Some of these collaborative efforts -- especially the large-scale community efforts that can attract thousands of visitors and members -- may represent successful commercial ventures for large-scale players in the computer industry, such as Yahoo!, Google, or Microsoft. Indeed, it may represent a component of a larger trend associated with the next wave of Internet and dot-com businesses.
But that is not what we are focusing on in this Opinion; instead, we are more interested in the collaborative wiki-style environments being created by Fortune 2000 companies to create new products, tackle research issues, and solve problems that customers are having with the company's products in the field.
The most obvious form of such collaborative environments involve existing employees -- for example, the company's R&D group, its product development group, and cross-functional teams of people from marketing, sales, engineering, and technical support. But this kind of collaboration has been going on, in one form or another, for several years. Wikis may provide an improved technology for conducting such collaborative efforts, but they're not fundamentally different from e-mail, intranets, or Lotus Notes mechanisms that we've had since the early 1990s, if not earlier.
What's more interesting is the collaborative wiki-style mechanism that connects an organization's employees with its former employees (retirees and "alumni" who have moved on to other jobs), as well as its customers and various other people outside the organization.
In her keynote presentation at the 2006 Cutter Summit, Harvard Business School professor Siobhán O'Mahony gave two examples of these "outbound" collaborations. One was Eli Lilly's "InnoCentive" program, which matches 30 companies who post problems in chemistry and biology (these are "seekers") with 90,000 scientists who are registered as "solvers." The seekers are anonymous; the solvers don't know which of the seeker companies have the problems. InnoCentive helps post the challenges and offers rewards of up to $100,000 to those who solve the problems.
Another example is Procter & Gamble's "Connect + Develop" program, which plans to have 50% of the company's innovations sourced externally by 2008. It is accomplishing this by tapping into an army of 8,000 researchers (including alumni and retired employees), 600 partners, and five business units. According to O'Mahony, P&G's R&D productivity is up 60%, and 35% of its innovations now come from outside the company. Meanwhile, P&G's percentage of sales invested in R&D is down from 4.8% to 3.4%.
The ultimate form of such outbound collaboration has recently been labeled "crowdsourcing" by Wired magazine [2]. Indeed, why limit one's source of inventors, problem solvers, and innovative collaborators to a relatively small circle of ex-employees and customers? Why not open it up to the entire Internet community?
As an example, Wired tells the story of Ed Melcarek, one of the 90,000 problem solvers in Eli Lilly's InnoCentive program:
The future of corporate R&D can be found above Kelly's Auto Body on Shanty Bay Road in Barrie, Ontario. This is where Ed Melcarek, 57, keeps his "weekend crash pad," a one-bedroom apartment littered with amplifiers, a guitar, electrical transducers, two desktop computers, a trumpet, half of a pontoon boat, and enough electric gizmos to stock a RadioShack. On most Saturdays, Melcarek comes in, pours himself a St. Remy, lights a Player cigarette, and attacks problems that have stumped some of the best corporate scientists at Fortune 100 companies. [2]
The point is not that people like Mr. Melcarek are not former Eli Lilly employees, but rather that they would probably never be considered sufficiently "qualified" to be hired by the company for a traditional job. As Wired points out, "Many are hobbyists working from their proverbial garage, like the University of Dallas undergrad who came up with a chemical to use in art restoration, or the Cary, North Carolina, patent lawyer who devised a novel way to mix large batches of chemical compounds."
Eli Lilly would not be considered by most business professionals to be a wild, crazy, radical company; in many ways, it's a pretty traditional, conservative company. And the companies participating in Eli Lilly's InnoCentive program include the likes of Boeing and DuPont. These are classic examples of Fortune 500 companies. If companies like these are pursuing wiki-style outbound collaboration, don't we already have a trend?
Still, we're talking about only a few dozen companies here. Collaborative wiki-ing is not yet a mainstream concept like outsourcing. And one can easily conjure up a list of risks and problems that might prevent it from working in this company or that company. Perhaps it will never work for some companies or even some industries; and perhaps it will never be a "core" part of the R&D, or product development, activity of other companies. 1
But whether you call it crowdsourcing or collaborative wikis, it certainly seems like the beginning of a trend -- an emerging trend that is already being explored by the innovators and early adopters (to use the terms popularized by Geoffrey Moore). And it looks like a new battleground for such major-league innovators as Yahoo! and Google.
Yahoo!, for example, has created a community-style collaborative environment called Yahoo! Answers (http://answers.yahoo.com). In mid-May, Yahoo! Answers announced that its participants had already answered 10 million questions (some as trivial as "Who's the best punk rock band?" but some fairly serious and profound). Google has taken a different approach with Google Answers (http://answers.google.com/answers). Its Web site claims that "More than 500 carefully screened Researchers are ready to answer your question for as little as $2.50 -- usually within 24 hours. Your satisfaction is completely guaranteed" ("completely guaranteed" is a hyperlink to a separate Web page explaining the terms and conditions of refunds).
Even if crowdsourcing and collaborative wikis don't turn today's business model completely upside down, they will put some people out of work; indeed, that's already happening, albeit on a fairly small scale. But if we're worried about large numbers of skilled knowledge workers in North America and Western Europe being displaced by equally skilled but lower-priced knowledge workers in China and India, then it stands to reason that some of us should start worrying about being displaced by hobbyists, students, retirees, and other part-time knowledge workers whose creative talents are being tapped by these new infrastructures. There is a new labor supply out there, and those companies that learn how to tap into it stand to profit at the expense of traditional companies with traditional labor supplies.
An important characteristic of this new labor supply is that its members often don't expect to be paid the hourly wage or salary that would be expected of "normal" jobs. While initiatives such as Eli Lilly's InnoCentive may pay problem solvers substantial sums of money, many other collaborative communities pay members as little as a dollar -- and sometimes nothing at all -- for their contributions. Some contribute simply because they want to share their passion for a particular topic; others enjoy the tiny bit of popularity it brings them. As one young Wikipedia contributor explained, "I wrote a paragraph of text and there it was.... You write all these pages for college and no one ever sees it, and you write for Wikipedia and the whole world sees it, instantly" [1]. It's pretty difficult for a traditional company with salaried employees to compete against a collection of people who are happy to contribute their efforts for free.
And even if wikis/crowdsourcing don't directly put existing workers out of a job, it could still create a huge competitive shift in some companies. As Wired notes in its crowdsourcing article, "Jill Panetta, InnoCentive's chief scientific officer, says more than 30 percent of the problems posted on the site have been cracked, 'which is 30 percent more than would have been solved using a traditional, in-house approach'" [2].
Other companies as well are going to find that they can solve such problems more quickly and at a lower cost. All of this will create a competitive advantage that will indirectly displace the workers in the more traditional companies.
While the technology of wikis is certainly important for R&D and problem-solving activities that require interaction between individuals, there are other cases where "wiki" is used to describe a cultural or philosophical approach that encourages widespread, low-cost (sometimes free) distribution of products and services. For example, the Web site iStockphoto offers royalty-free photographic images for as little as $1 each; it currently has 22,000 contributors (including students, engineers, and dancers) who pay no subscription fee and who are delighted to earn even a tiny payment for sales of their amateur photos. As a result, iStockphoto and other "microstock" sites like ShutterStock and Dreamstime have created serious competition for traditional photo sites, where professional photographers expect to charge $100-$150 or more for their photographs. (And if $1 is too much for your budget, there's always Flickr, which has over five million images, of which more than 80% are public! 2 )
Photographs are, of course, an individual creation; the only possible collaboration that one finds on these sites is the string of comments and opinions posted by visitors who view the images. Much the same can be said of the 40 million blogs that now populate the Internet: the overwhelming majority have a single author, but they may also contain the collaborative contributions of visitors and observers.
What Should You Do?
Fortunately, wikis and crowdsourcing don't require an all-or-nothing bet on a new business model. Nor do they require a billion-dollar investment in a new manufacturing facility. Nor is it likely to take years of effort before you discover whether it's a good idea for your company. You can start small; you can try a pilot project; and you can evaluate results within a matter of months.
The first thing to do is investigate and evaluate the concepts discussed in this Council Opinion. Ironically, this can (and should!) be a collaborative effort in itself. You may or may not want to involve outsiders in your early investigation, but you can certainly use the technology and concepts of wikis and inhouse collaborative forums to gain a deeper understanding. Indeed, you may already have the technological infrastructure for setting up such a focused collaboration effort.
Assuming that your investigation concludes that "outbound" wiki-style collaboration does make sense, then you'll need to decide whether you want to be a risk-taking early adopter or a more cautious "mainstream" practitioner. In the former case, you'd better get started quickly: as noted in the examples above, there are already some very aggressive companies out there trying to take advantage of this new concept before everyone else gets on the bandwagon.
But if your corporate culture is more cautious and conservative, you can still try a modest pilot project. Start with a smaller, more controlled (and better-known) community of users, such as recent retirees. Focus on one or two small areas of R&D or problem solving. Bring in some consultants to help you avoid making fundamental mistakes that will doom any senior-level support for the concept, and monitor the process so that you can improve it when you're ready to roll it out on a larger scale.
And get ready to read some impressive case studies about wikis/crowdsourcing in the Harvard Business Review and the Wall Street Journal. We may not see such articles and stories for another few years -- but in our collective opinion, it's just a matter of time.
1A small example: members of the Cutter Trends Council briefly considered creating this Opinion as a wiki-based collaborative effort. But our objective is not to create a single, homogenized "consensus document" about a topic, but rather to emphasize the individuality and personality of concurrences and dissents from the opinion being discussed. But within the broader boundaries of the Cutter Consortium, there are other intellectual products (reports, journals, etc.) where a wiki approach -- perhaps involving customers, retirees, and members of the general public -- might make sense.
2I recently had a Flickr-related experience that also illustrates the earlier point of a radically different business model created by the wiki-oriented experience: I received an e-mail from a total stranger, who explained that she was the marketing manager for an "adventure tour" company in northwestern Montana. She was creating a marketing brochure for her company and needed some photos of the Kerr Dam, located a few miles south of Polson, Montana. A few years ago, she would have spent a moderate amount of money for a high-quality photograph taken by a professional photographer; but now she merely did a search for "Kerr Dam" on the Flickr Web site and found a dozen images. She decided that a recent photo of mine, which I had taken while driving through the area, was the best of the bunch, and she e-mailed me to ask for permission to use the photo, with the "payment" consisting merely of a credit that said "Courtesy of Ed Yourdon." I was delighted that someone had actually noticed the picture and flattered that someone (anyone!) thought it was the best picture they had ever seen of the dam. I happily gave my permission. Chances are that a professional photographer somewhere lost a day's wages as a result, but c'est la vie.
References
1. Hafner, Katie. "Growing Wikipedia Revises Its 'Anyone Can Edit' Policy." New York Times, 17 June 2006.
2. Howe, Jeff. "The Rise of Crowdsourcing." Wired, June 2006 (www.wired.com/wired/archive/14.06/crowds.html).
CONCURRENCE BY TOM DEMARCO
I've gone back and forth on Ed's basic thesis that wiki approaches will be increasingly relevant for the companies at which our readers are employed. It's hard to look at Wikipedia, for example, without being charmed by the surprising way that legions of unpaid, uncoordinated volunteers have combined to make something not just useful but extraordinarily elegant: a self-updating encyclopedia in a few hundred languages that is bigger than the Encyclopedia Britannica and nearly as reliable. Part of me wants to argue, how could such an amazing result not be broadly relevant? But it's more complicated than that ...
Just for starters, for its magic, the wiki phenomenon depends on a truly huge community of participants. Don't be seduced into thinking that the something-for-nothing payback of Wikipedia could be replicated by setting up a wiki for a workgroup of a dozen or even a few hundred people. Wiki methods depend on thousands to tens of thousands of participants; anything smaller and what masquerades as a wiki is really little more than an open bulletin board. And nothing very earthshaking ever resulted from a bulletin board.
Second, a wiki, as it's initially set, is almost totally useless. To make it work, you have to add a culture and a protocol and an ethic of participation: that's where the magic comes from. And these additions have to be specifically germane to the domain of interest, not something you can simply borrow and adapt from some other successful wiki. As an occasional contributor to Wikipedia (Congress of Vienna and early 19th-century German history), for example, I had to learn how to participate, how to make myself part of the growing community. I had to learn that the standard for inclusion in Wikipedia was "verifiability, not truth." I might come up with a fascinating theory about great power interaction in the 1820s, something with a smack of truth about it, but I couldn't include it in the wiki, since it was not verifiable. Note that the standard of "verifiability, not truth" has nothing to do with wikis in general, only with Wikipedia. It is part of Wikipedia's unique protocol. If you were to build your own wiki dedicated to some other purpose, it would be up to you to hit upon the right protocol, to build the right culture around the enterprise, and to find the proper ethic for participation. Doing any of these things less than well will make your wiki less than successful. Don't expect the software to bail you out.
Wiki technology is at best a minor component of any crowdsourcing approach you may consider. All the hard stuff is up to you.
Having said that, I do believe that there is an important and exploitable opportunity in crowdsourcing. Reaching out to your ex-employees and customers, as Ed suggests, is likely to be a fruitful exercise. Not easy, but fruitful.
CONCURRENCE BY TIM LISTER
After reading Ed's opinion and discussing it with my fellow Trends Council members, I decided to see what I could find out about using wikis from some of my regular clients. In a completely unscientific poll, I e-mailed 12 friendly contacts at 12 different organizations and simply asked, "Does your company make use of wikis? If so, what are they used for?"
Seven of the 12 organizations have wikis up for some use. Interestingly, of the five that don't, three reported that they don't know whether anyone in their organization has even looked at the possible use of wikis. I followed up with the seven wiki-using companies. Right now, these wikis are all for internal use. One of the most common uses is sharing "any nontrivial document" between groups that are physically separated. The two most interesting wiki cases, detailed below, are from very different companies.
The first is a Fortune 500 company, which started using wikis several years ago with good success. IT decided it would roll out worldwide wiki support for everyone in the company. It put together announcements and short talks to get things going, but the most interesting moment came when an (enlightened) executive told IT not to offer possible uses for wikis, but rather to just show some real wikis and let the company employees figure out what they could be used for. My contact said, "There are now many wikis we would never have come up with. Wikis are sprouting everywhere -- it's great!"
The second company is a small firm based in New York City, utilizing Web technology to deliver its product line. My contact there said that the development of the product (basically software) has a wiki "Bible":
Over time, developers and QAers have built a wiki of all our product designs and tests and all our processes we have agreed to stick to when we deliver new Web-based content. The key to our wiki is that it fits the way we work. We are open with our work and informal in our manner. The wiki lets anyone jot down his insights fast with little fuss. I think almost all of our developers and QAers have been writing in the wiki.
See Tom's concurrence above regarding the right culture and behavior for wikis. Clearly, this company's culture is a great fit with wikis.
Takeaways
-
At least experiment with wikis. There must be information out in your organization that is a fit.
-
The key to wiki use seems to be that people perceive the wiki as something useful yet easy and informal.
CONCURRENCE BY CHRISTINE DAVIS
Using wikis is another instance in the macro business trend to exploit openness and minimize labor cost. Corporate isolation and protectionism are not in vogue anymore. These philosophies do not seem to work in business any better than they have worked in government. Corporations are realizing they have to tap into a much larger pool of talents and resources, exposing themselves to some extent, but gaining a tremendous amount of knowledge and resources in the process. A wiki is an excellent tool to use within this strategy; however, a wiki environment is not going to be easily managed.
Businesses have sought to minimize their labor costs through outsourcing, offshoring, consolidation, and "operational excellence." Now with wiki technology, there is a relatively new way to increase knowledge and capability in many domains using free labor or, at least, leveraged labor. (Free labor is when people not on your payroll contribute to your cause, while internal labor is leveraged through exploiting the knowledge of those on the payroll more effectively.) Wikis are a viable tool to capture and build upon the knowledge of employees, retirees, colleagues, students, and others while providing a venue for collaboration within cohesive domains or problem sets. Companies are going to try to make this technology work for themselves.
One of the biggest business challenges in using this technology is finding ways to effectively capture the attention and interest of the potential contributors, both internally and externally. Unless they are a nonprofit organization, businesses are not accustomed to being dependent on the altruistic spirit of their labor pool. Volunteers serve and give their time unselfishly for nonprofit organizations because they believe in the mission. If wikis are to be successful, the contributors must have a similar kind of loyalty and passion. If there is no broad-based excitement or interest in the subject, it will not make a great wiki application.
Today's concept of open and free development was born with the open source movement. Many of the same principles used to make open source a successful venture are necessary for wikis to be successful, such as meritocracy and transparency. In addition, some of the open source organizational and legal frameworks could be applied to wikis to reduce risk and protect the various stakeholders. Lessons learned from working with open source should help one shape a more viable wiki environment.
The technology is an excellent choice for enabling collaboration where there is a natural and passionate interest in the subject matter and an altruistic spirit among a large set of potential contributors. Wikis will not be successfully used everywhere, but they are becoming a corporate tactic for solving some challenging problems.
(GRUDGING) CONCURRENCE BY LOU MAZZUCCHELLI
Something Wiki This Way Comes
A certain segment of the population -- typically young, but sometimes not-so-young -- has a tendency to propose "simple" solutions that are a reaction to perceived or actual existing restrictions in existing systems or technology. Invariably, the proposed solution is hailed as novel, groundbreaking, lightweight, free-form, and liberating. Ultimately, the solution matures into a real-world system with all of the complexities, constraints, and inconsistencies that motivated the initial work. This is yet another manifestation of the Wheel of Reincarnation.
And so to wikis. Wikis leverage the best of the Web's noble intentions and continue the quest for easy-to-use, geographically distributed collaboration systems. And, because of our insatiable nature, they are being adopted for all sorts of applications. But how many of these applications are not subject to the encroachment of the real world?
Wikipedia is a prime example. Those of you who have studied any Utopian social experiment will recognize the current developments within its community. As more structure is imposed, disaffected groups will leave, perhaps to begin new, competing Wikipedia-like entities.
Profit-making ventures too have sprung up to take advantage of Wikipedia's success (see, for example, www.digg.com).
We can all speculate on neat ways to leverage wikis; in our Trends Council conversations, I have suggested that corporations might use wikis to collect and maintain information about products, services, and customers that might otherwise be lost as employees retire. But as I think about this with a "corporate VP hat" on, I wonder: How do I allow only benign employees into the wiki? How do I make sure the information is accurate? What are the liability issues involved with disseminating this kind of information? And on and on, until my head explodes and I just say, "Don't bother."
That is why I believe that most corporate wiki use will be behind the firewall, in homogeneous small groups in "nonhostile" environments.
I won't bother with refuting novelty claims -- economics tends to trump history, as far as technology is concerned.
And the fact that Lotus Notes implements much of what is in current wiki technology, and what will be in future wiki technology, is only relevant if IBM decides to give Notes away.
So should you explore wikis? Sure. But don't expect miracles, and keep the wikis inside your company.
CONCURRENCE BY LYNNE ELLYN
I can think of numerous reasons why Ed is correct about the coming use of wikis inside corporations to enable collaboration and innovation. To begin with, the social phenomena of wikis is spreading across multiple domains, and users of wiki technology are coming to view wikis as a convenient, even preferred, mechanism for collective projects or collective knowledge gathering and dissemination. Many familiar technologies have originated outside corporate walls but soon became pervasive inside the company with the advocacy of employees who were using the technology in their personal life (e.g., the PC, the BlackBerry, and Internet browsers). Wikis are already traipsing into the corporate front door in just this way. The trend will gain speed as more people discover the usefulness of wikis for staying informed and connected to important interests such as hobbies, travel, and parenting. I, for example, have recently been exploring a wiki site that provides information on natural ways of handling food allergies. Contributors include doctors, nurses, nutritionists, and many sufferers of food sensitivities. This wiki has been the source of incredibly helpful information and, admittedly, some rather curious trivia and minutia. Even with the dross, this has been an effective way of gathering and disseminating information. Obviously, there are many opportunities to gather and disseminate information within the corporate environment as well, so wikis will likely jump to the corporate network for this purpose.
Wikis are also a technology that fits the current structure of companies. The distributed company needs mechanisms for collaboration. No longer can we rely on the time-consuming hierarchical information cascades for educating our employees and creating the proper alignment. Companies will use wikis to help employees engage in dialog aimed at creating a deep understanding and shared purpose. Wikis will allow employees, managers, and policy makers to share what is working, what isn't, and innovative ideas across the globe. People who would never meet in real life will be able to compare experiences, exchange stories, and ask for help. The power and value of enterprise dialog is obvious. Wikis will be one of the ways companies will enable enterprise-level conversations.
Wikis for cross-company or extra-company collaboration is also an intriguing idea that will find a home in a variety of industries. Ed gave examples of companies extending design processes to non-employees; the early successes with this approach will surely spawn other adapters. Getting broader participation in product development is the goal of many companies.
Wikis are gaining a foothold in corporate America. It won't be long before they become an expected part of the IT landscape.
PARTIAL DISSENT BY KEN ORR
Like most people who spend a lot of time on the Internet, I have been using Wikipedia more and more often. Each day it gets better, and I find myself more comfortable using it as a source of definitions in my research. That said, I'm not sure I'm ready to put it down as the template for organizing creative work within, or without, an enterprise.
The theory is that Wikipedia is the perfect paradigm for Internet-based collaboration, a place where, like an oyster, any irritation (read mission) will cause the Internet organism to create its version of a cultured pearl. The idea behind this is that collectively all of us are smarter than any of us individually. It is, supports claim, an endeavor in which thousands of independent people have created, without pay or reward, something that organizations such as Encyclopedia Britannica have struggled -- at high cost over long periods of time -- to pull off. As wiki-ites have pointed out repeatedly, it is truly something new under the sun.
Actually, however, the idea of creating a compendium of human knowledge through the independent efforts of lots of low-paid, or unpaid, volunteers is not unprecedented or even new. In the 19th and early 20th century, the gold standard of dictionaries, the Oxford English Dictionary, was created in a somewhat similar way as Wikipedia -- by hundreds of people dutifully filling out individual index cards with their definitions of individual words or phrases. 1
One of the striking parallels between then and now is that while a large number of people participated in contributing words, a small number of people contributed a very large percentage of the entries. Then, like now with Wikipedia, the OED was created by a small number of interested people with a great deal of time on their hands. Indeed, one of the most productive contributors turned out to be an especially erudite individual in prison for murder. 2
So perhaps dictionaries or encyclopedias are the perfect application for this kind of independent collaborative work. As Lou pointed out in the conference call for this Council Opinion, a dictionary has a perfect architecture for hundreds or thousands of people to toil selflessly to produce something truly useful. Not every activity, however, is so architected.
Clearly, the Internet makes it possible to do something important without individual reward -- something that runs counter to what one would expect in this "me, me, me" world. People -- all people, I suspect -- have a need to be part of something greater than themselves. When I was in graduate school, there was a fellow down the hall in my apartment building who was working on a PhD in a very obscure area. His goal, he told me, was "to add one grain to the mountain of knowledge in the world." There are a lot of people like him; the great cathedrals bear witness to that desire.
But, unfortunately, as Jaron Lanier points out in a brilliant piece called "Digital Maoism3," it is just as possible to be collectively stupid as it is to be collectively brilliant [1]. Wikipedia may be just the model for much future collaborative work -- but it may also have another side. Just as the Internet (and talk radio) lets millions of isolated, creative people express themselves, it also provides a new channel for millions of opinioned, biased folks to inflict their ideas on others. As my old friend Aristotle was fond of pointing out, it's all about that golden mean.
1The goal of OED was much, much more expansive than that of Wikipedia. The goal was to read all of the major works in English from 1250, identify keywords, and write down phrases illustrating word usage.
2See Simon Winchester, The Professor and the Madman: A Tale of Murder, Insanity, and the Making of the Oxford English Dictionary (Harper Perennial, 1999); and Simon Winchester, The Meaning of Everything: The Story of the Oxford English Dictionary (Oxford University Press, 2003).
Reference
1. Lanier, Jaron. " Digital Maoism: The Hazards of the New Online Collectivism." Edge Web site, 30 May 2006 (www.edge.org/3rd_culture/lanier06/lanier06_index.html).
PARTIAL CONCURRENCE BY JOHN TIBBETTS, SENIOR CONSULTANT, CUTTER CONSORTIUM
I join this discussion as someone who has recently had a wiki-related revelation.
Until a few months ago, I would have found Ed's assertion hard to accept. Despite being involved in many attempts, I had rarely seen an enterprise wiki take off. As Tom points out, without a large population of ready users, some aggressive bootstrapping, and a carefully nurtured culture of participation, wikis can turn into cyber ghost towns. By itself, a wiki may be too free-form for an enterprise environment where people have other, more structured, less "out there" ways of exchanging thoughts.
But I can now testify for the defense. I am part of a software development community with a flourishing wiki at its center. This wiki has been busy since the day it opened, an active hub of conversation and information. It is successful, I believe, because of something that Ed puts his finger on when he foresees "wikis ... in the form of applications ... enabl[ing companies] to collaborate, and therefore innovate, in new ways." The insight here is that when it comes to enterprise use, there is more potential in wikis that are built into applications than in free-standing wikis alone.
I'd like to report briefly on my experience using just such an application -- an open source product that provides a central wiki, embeds a wiki editor inside of various application modules, and uses the wiki engine to link these modules together. The result is an environment where the wiki's responsiveness and ease of use works hand-in-hand with core functionality. The application functions are enriched, and the wiki thrives.
The wiki-enabled application in this case is a freely available project management environment called Trac (http://projects.edgewall.com/trac). Trac is designed for software development, but its approach would work for any sort of collaborative undertaking where resources need to be stored, scheduled, tracked, versioned, and discussed -- protocol designs, short-story anthologies, grant proposals, engineering projects, plant expansion plans, etc.
Trac offers a rather nice wiki engine that supports a user interface where, as with all wikis, participants can view and/or modify the content. What is interesting is that a number of application modules are built into or sit adjacent to the engine and take advantage of its capabilities.
The primary module is an issue-tracking system. Issue-tracking systems (also called bug-tracking systems, but I prefer "issue" because it encompasses enhancements, tasks, and investigations as well as defects) are profoundly collaborative applications that allow developers or users to post structured comments and allow others to respond. In the Trac system, the description of each issue and the back-and-forth around it are conducted using a wiki editor built right into the page. This is great because there is no new syntax to learn. (In contrast, the Bugzilla issue-tracking system requires leaving messages in an idiosyncratic way that takes a while to master. Furthermore, the wiki editor allows more text formatting than Bugzilla.) Even more important is Trac's hyperlink syntax that lets the issue tracker reference the central wiki. An issue "ticket" about a certain enhancement can have a glowing hyperlink to the place in the wiki where this enhancement was suggested and refined before it was promoted to an official "issue."
In addition to its issue-tracking capabilities, Trac offers a repository browser that lets users view project artifacts. A person can dip into the repository and look at, for example, some Java source code. While there is no wiki editor here (repositories aren't really a site for active discussion), there is a hyperlink capability. A comment in the source code may indicate, for instance, that the current method implements issue #234. This comment is in fact a link to the page in the issue-tracking system where #234 is discussed (which can in turn link to the wiki conversation that launched the issue).
Another module is a timeline. It shows changes not just to wiki content but to the repository and issue database as well, providing a comprehensive history of project activity. Each entry is a hyperlink that jumps to the change itself.
There is also a roadmap module that summarizes project milestones. Here too there is a wiki editor/viewer for in-context commentary. Furthermore, a milestone can be defined in terms of the issues that it addresses (with a link back to that issue in the tracking system) and can also reference the pages in the central wiki where that milestone's objectives are discussed.
So Trac provides for informal discussion, more formal issue tracking, a repository, a timeline, and a roadmap -- all linked together. The result is a system that is far greater than the sum of its parts. A whole constellation of project activities are cross-referenced, searchable, and able to be commented upon. Those modules that accept comments all use the wiki interface, so users do not have to learn a different syntax for each one.
It will be obvious how this makes for an efficient and thoroughly integrated environment. Every piece can inform and be informed by the others. Hopping around among modules is effortless. Background and context are a click away.
And the problem of getting the wiki established disappears. There is real motivation to jump in: report that bug, weigh in on that issue, review that method, adjust that roadmap. A new user can begin by using components like issue tracking that provide a structure for input (raising a new issue involves filling out a structured online form, for example). Once he or she is comfortable, it's easy to start typing comments into the wiki editor. Joining the community is gradual and painless.
Although my example here is software-related, I repeat that this integration of wiki and application (I call it a WikiApp, pronounced like the Native American dwelling) would work for an extremely wide range of enterprise functions. Ed mentioned that wikis as collaborative tools are not all that different from the Lotus Notes experience of the 1990s. This may be true. But the WikiApp is astronomically easier to use, free, and drop-dead simple to install.
So I'm with Ed: the full value of wikis for the enterprise will come when they are closely coupled with an application suite. I have found this combination a knockout.
ABOUT THE CUTTER BUSINESS TECHNOLOGY COUNCIL
ABOUT CONTRIBUTING AUTHOR JOHN TIBBETTS
The application of wikis will increasingly infiltrate forward-thinking, mainstream enterprises in the form of applications that will save these companies money and enable them to collaborate, and therefore innovate, in new ways.