Wide Open Spaces: Wikis, Ready or Not

© 2004 Brian Lamb

EDUCAUSE Review, vol. 39, no. 5 (September/October 2004): 36, 48.

The Way It Was Meant To Be

Remember when the Internet was about opening up access to information and breaking down the barriers between content creators and content consumers? Think back to when spam was just a meat-like substance. To those heady days when Timothy Leary was predicting that the PC would be the LSD of the nineties. Before the DMCA. Before eBay. Back when the Web was supposed to be a boundless Borgesian "Library of Babel" and not a global supermarket. Forget that the dot-com era ever happened, if you were an investor or working for stock options back then, maybe you already have.

In 1999, the World Wide Web inventor Sir Tim Berners-Lee looked back on the previous decade and lamented: "I wanted the Web to be what I call an interactive space where everybody can edit. And I started saying interactive, and then I read in the media that the Web was great because it was interactive, meaning you could click. This was not what I meant by interactivity." That vision of a genuinely interactive environment rather than "a glorified television channel" one in which people not only would browse pages but also would edit them as part of the process did not disappear with the rise of the read-only Web browser.¹ It's churning away more actively than ever, in a vivid and chaotic Web-within-the-Web, via an anarchic breed of pages known as "wikis."

The Standard Wiki Overview

It's risky to talk about wikis as if they're all the same. In practice, the term wiki (derived from the Hawaiian word for "quick") is applied to a diverse set of systems, features, approaches, and projects. Even dedicated wikiheads engage in perpetual arguments about what constitutes true wikiness. But some fundamental principles (usually) apply.²

• Anyone can change anything. Wikis are quick because the processes of reading and editing are combined. The signature of a wiki is a link at the bottom of the page reading "Edit text of this page" or something similar. Clicking that link produces the page's hypertext markup, allowing instant revisions. Authoring software, permissions, or passwords are typically not required.
• Wikis use simplified hypertext markup. Wikis have their own markup language that essentially strips HTML down to its simplest elements. New users need to learn a few formatting tags, but only a few. Most wiki tags significantly streamline and simplify their tasks. For instance, the minimum HTML code needed to create a named hyperlink to EDUCAUSE Review online, EDUCAUSE Review, would be rendered in a wiki within square brackets. The result, [http://www.educause.edu/pub/er/EDUCAUSE Review], saves a minimum of twelve keystrokes and is significantly easier to remember. Raw URLs typically require no markup tags at all to be rendered live on a wiki page.
• WikiPageTitlesAreMashedTogether. Wiki page titles often eschew spaces to allow for quick page creation and automatic, markup-free links between pages within (and sometimes across) wiki systems. Linking to related pages is easy, which promotes promiscuous interlinking among wiki pages.
• Content is ego-less, time-less, and never finished. Anonymity is not required but is common. With open editing, a page can have multiple contributors, and notions of page "authorship" and "ownership" can be radically altered. Content "cloning" across wikis, sometimes referred to in non-wiki circles as "plagiarism," is often acceptable. (This attitude toward authorship can make citations for articles such as this one a tricky exercise.) Unlike weblogs, wiki pages are rarely organized by chronology; instead they are organized by context, by links in and links out, and by whatever categories or concepts emerge in the authoring process. And for the most part, wikis are in a constant state of flux. Entries are often unpolished, and creators may deliberately leave gaps open, hoping that somebody else will come along to fill them in.

There are plenty of exceptions to each of these principles. Wiki practices sit on a continuum. At one end is the radical openness and simplicity of the wiki inventor Ward Cunningham's first system: the WikiWikiWeb (http://c2.com/cgi-bin/wiki), which was launched in 1995 and has remained remarkably true to its minimalist vision. But as wiki usage grows in popularity with other online cultures, even being touted in the business world as a knowledge management solution, scores of emerging wiki systems are adding functionalities such as restricted access, private workspaces, hierarchical organization, WYSIWYG Web editing, and even integration with centralized content management systems. On this more structured and feature-rich end of the continuum, it can be difficult to decide whether these are really wiki systems at all or are simply browser-based HTML authoring tools.

Why Wiki?

In many respects, the wide-open ethic of wikis contrasts vividly with the traditional approaches of standard groupware and collaborative systems. Access restrictions, rigidly defined workflows, and structures are anathema to most wiki developers. What's unique about wikis is that users define for themselves how their processes and groups will develop, usually by making things up as they go along.

Newcomers to the medium may find it easiest to start with simple tasks. Wikis work great as shared online sketchpads or as spaces for brainstorming. They are perfect for creating perpetually updated lists or collections of links, and most users can instantly grasp their utility as informal bulletin boards. Because it takes only a couple of seconds to set up a new page, no purpose is too trivial.

One common way to use wikis is to support meeting planning: a provisional agenda is drawn up, and the URL is distributed to the participants, who are then free to comment or to add their own items. Once the meeting is under way, the online agenda serves as a note-taking template, and when the meeting is completed, the notes are instantly available online, allowing the participants or anybody else to review and annotate the proceedings.

With some planning, more complex processes can easily be supported. A number of varied applications have been defined by heterogeneous groups from within my home institution, The University of British Columbia.³

• The Faculty of Applied Science Instructional Support links wikis into its course management system authoring environment so that design teams can quickly and collaboratively build reference lists and outlines, brainstorm instructional strategies, and capture suggestions. Educational Technology Coordinator Jim Sibley reports: "The ability to spawn whole sites or a series of pages astonishes people when they first see it. . . . You can quickly map out pages to cover all aspects of complex processes or projects."⁴
• The Career Services unit uses wiki pages to store and organize content for a major new job posting and career development Web site that it is developing. Discussion and prototyping can get under way immediately rather than waiting for the technical framework to be implemented. Online content creation is able to proceed rapidly, with contributions from every member of the unit rather than a handful of Web authors. Laural Raine, a Web developer, notes: "Using the wiki has allowed us to share and collaborate on the research that we would have otherwise done individually. This allows for easier information management during the project, and will improve the quality of our finished product."⁵
• An academic research unit on campus used a wiki for planning a technoculture conference, to collect supporting resources and to gather contributions from invited participants. They used the wiki during the conference, live, with laptops and wireless access, to record group work. Following the conference, participants subsequently edited their collaborative authorings from a wide variety of locations, resulting in a "conference proceedings" of an altogether different sort. The organizer, Professor Mary Bryson, observes: "[The] wiki functioned in this context as an intellectually appropriate technology, aesthetically and politically in keeping with the theme of the event, which was the significance of ubiquitous media in everyday life and the ways in which accessible tools mediate the construction of popular culture."⁶
• Teresa Dobson, an assistant professor of education, is using the wiki space in both her teaching and her research. Her graduate course on technologies for writing employs the wiki as a support for collaborative experiments in composition and "as a prompt for reflection on the nature of online writing and reading."⁷

What is most remarkable about these diverse outcomes is how they came about. In all instances, the users decided for themselves how the wiki would fulfill their objectives. Technical support and training was minimal: at most, one hour of instruction was needed, and in most cases, orientation was handled by a single e-mail. Even confirmed technophobes have grasped and mastered the system quickly. The structure of wikis is shaped from within‚ not imposed from above. Users do not have to adapt their practice to the dictates of a system but can allow their practice to define the structure.

And as open systems, wikis can extend their reach far beyond departmental or organizational limits, expressing the interests of virtually any community. For example, Wikitravel (http://wikitravel.org/) is striving to develop a free worldwide travel guide. TV Tropes (http://tvtropes.org/pmwiki/pmwiki.php/Main/HomePage) bills itself as "a catalogue of the tricks of the trade for writing television scripts"; it collects frequently found plots and devices and helps its members to find "a clich© to subvert." JuggleWiki (http://www.jugglewiki.org/wiki/Main_Page) offers tips and animated tutorials, allows jugglers to meet one another, and is home to just about anything else conceivably associated with juggling. Rick Heller, an author, has uploaded the manuscript of his novel Smart Genes (http://www.opensourcenovel.net/) and will incorporate the best edits and suggestions into the next draft of his book. Readers can also save alternative chapters and related pages.

It's possible that wikis might simply represent the latest advance in online interaction, a cost-effective and readily adopted knowledge management tool. But as wikis make their mark in higher education, the ultimate implications may prove to be far more profound than mere gains in efficiency.

The Standard Objection

There's a very common reaction that newcomers express when first introduced to wikis: "That looks promising, but it can't work for me." Their objection to wikis is nearly universal: "If anybody can edit my text, then anybody can ruin my text." Human nature being what it is, to allow free access to hard-earned content is to indulge open-source utopianism beyond reason.

This concern is largely misplaced. Think of an open wiki space as a home that leaves its front door unlocked but doesn't get robbed because the neighbors are all out on their front steps gossiping, keeping a friendly eye on the street, and never missing a thing. This ethic is at the heart of "SoftSecurity," which relies on the community, rather than technology, to enforce order. As described on the MeatballWiki: "SoftSecurity is like water. It bends under attack, only to rush in from all directions to fill the gaps. It's strong over time yet adaptable to any shape. It seeks to influence and encourage, not control and enforce."⁸ Whereas "hard security" functions by restricting access or hiding pages, wikis save copies of successively edited versions; thus, work that has been deleted or defaced can be recovered with a couple clicks of the mouse. Changes are readily detected (e-mail or RSS alerts can announce page edits), and deleting flames or unconstructive contributions is usually easier than creating them.

It's undeniably true that determined vandals can make real pests of themselves. But an open environment also encourages participation and a strong sense of common purpose, so the proportion of fixers to breakers tends to be high, and a wiki will generally have little difficulty remaining stable, assuming that people see value in its existence and have a genuine interest in keeping things tidy. As Clay Shirky observes: "A wiki in the hands of a healthy community works. A wiki in the hands of an indifferent community fails. The software makes no attempt to add "process, in order to keep people from doing stupid things."⁹

The open-access encyclopedia Wikipedia (http://wikipedia.org) is, without question, the biggest and best-known wiki project on the Web. It has such a huge and active contributor community (having created more than 290,000 entries in English alone as of June 2004) that a remarkably elaborate governance structure and conflict-resolution process have emerged to handle the often-contentious construction of entries, particularly in the case of hot-button issues such as "abortion" or "Iraq." The Wikipedia Meta-Wiki proudly describes the present power structure as "a mix of anarchic, despotic, democratic, republican, meritocratic, technocratic, and even plutocratic elements," all in constant flux and in perpetual negotiation.¹⁰

In the case of Wikipedia, establishing community policies is complicated by its relatively high profile and the diversity of perspectives and motives. Most contributors sit somewhere on a range of "extreme inclusionists" (who value every article that isn't obviously awful, in the interests of creating an evolving representation of online culture) and "extreme deletionists" (who value "proper" articles, in the interests of building an authoritative reference work). This online Tower of Babel resolves its many differences in varying ways across the system. In most cases, "Darwikinism" holds sway, with sections and sentences "subject to ruthless culling and replacement if they are not considered, fit." In practice, however, "evolution toward stability occur[s] just as much through cooperation as competition."¹¹ This complex, fluid set of mores and norms marks Wikipedia of great interest to researchers at the IBM Collaborative User Experience Research Group, who have used Wikipedia's authoring processes as the raw material for their work "visualizing dynamic, evolving documents and the interactions of multiple collaborating authors" and examining how the community responds to instances of vandalism.¹²

"SoftSecurity" is not the only way to protect contributions to a wiki space. There's nothing about the software that prevents it from being hosted behind a firewall, for instance. Many wiki systems employ more structured architectures than Cunningham's WikiWikiWeb and feature password protection, private spaces, IP banning, and other "hard security" measures. Socialtext (http://www.socialtext.com/), an "enterprise social software" company based in Palo Alto, is pioneering efforts to integrate open-space approaches within corporate IT environments. Socialtext CEO Ross Mayfield notes that Socialtext's "Security and Operations Policies and Procedures meet the demands of most IT organizations."¹³ It's arguable whether such approaches are true to the original vision of Cunningham's WikiWikiWeb, but they do suggest that moderated wiki practices can function effectively within corporate environments. Perhaps the most dramatic harbinger of impending wider adoption in mainstream computing is the recent hiring of none other than Ward Cunningham himself by Microsoft.

Where Is Everything?

Next to the lack of hard security and privacy, the most common objection to wikis is the typical absence of an explicit organizing structure. When visiting a wiki for the first time, users accustomed to hierarchical organization and directed navigation might ask, "Where is everything?" Expecting to be told where to go, they feel lost, "as if falling through a wide expanse of concepts and thoughts represented in nodes of text," as one page describing the principles of wiki navigation puts it.¹⁴

This sense of disorientation is common, but once the initial wave of adverse symptoms passes, recovery is supported by a loose collection of contextual signposts that can be remarkably descriptive. Logical context may be gleaned by checking the list of "recent changes" on the wiki system or by following links in and out of a page. The search box is invaluable. Although there is nothing to stop a wiki administrator from developing templates or prompts to provide scaffolding for new users, most wikiheads suggest that the form works best when users can define their own applications and approaches for working with the system. As Mayfield notes, "Except in rare instances where design creates function, the more you design the more user functionality you sacrifice. Wikis emphasize both reading and writing. Sure they could be a little more readable, but that would come at a cost for writing."¹⁵

Yes, even wiki enthusiasts acknowledge that the pages could be more readable, which brings us to yet another common objection.

Why Are Wikis So Ugly?

"It's very very cool to be able to do ridiculously easy, collaborative document editing," writes Elizabeth Lane Lawley. "But . . . let's face it. They're ugly." She argues that anybody can spot a wiki page from "a mile away," since they "all look exactly like the pages" that her students used "to turn out in basic HTML classes back in 1995. All they're missing are the rainbow-colored bars to replace the ubiquitous horizontal rules."¹⁶

Lawley has a point. Not only does the wide-open, anything-goes spirit of wikis evoke the original spirit of the Internet, but all too often the interface does as well. Yet Cunningham sees the lack of aesthetic appeal in his WikiWikiWeb as a functional advantage. "People look at it and say, hmm, this looks boring, and go away. The quality is deep, not at the surface," he says.¹⁷

It's true that many wikis tend toward plainness, but there's no reason that more pleasing fonts, colors, and layouts can't be accommodated through the judicious application of Cascading Style Sheets (CSS). Matt Haughey, for one, has done an exemplary job of demonstrating the power of CSS to tailor the look-and-feel of his wiki-driven site (http://www.haughey.com/).

Wikis In The Academy

Wikis are already making their mark in higher education and are being applied to just about any task imaginable. They are popping up like mushrooms, as wikis will, at colleges and universities around the world, sometimes in impromptu ways and more often with thoughtful intent.

WikiFish at Auburn University (http://wikifish.org/) is a fine example of how a student-owned site can foster frank communication among its participants. Its stated mission is "to protect the delicate collaborative environment of Design+Construction School culture, and to serve as a protocol and reference guide to keep these balances in check."¹⁸ Students critically examine the school's methods and its underlying ideologies, often by posing provocative queries such as "If Architecture School were an organized religion, what would our core beliefs be? What would constitute a sin?" or "If you had to get rid of dead weight in the curriculum, with which courses would you start?"¹⁹ They argue why students at the school should be allowed to pursue their own research agendas, and they debate what constitutes a healthy educational environment. Characteristic of the wiki's irreverent attitude, the front page announces that those who do not wish to "edit, erase, enhance, beautify, dullify, nullify, derange, arrange, or simply change" the wiki space should "then accept the fact that [they] will always be complacent, and easily controlled."²⁰ Then, presumably, they should just go away.

More scholarly in approach, the Romantic Audience Project at Bowdoin College (http://www.rc.umd.edu/pedagogies/commons/innovations/rap/index.htm) is a collaborative study collecting entries focusing on poems, poets, and topics related to Romantic literature. The students chose the wiki framework because "such collaboration, [by] dynamically and unpredictably highlighting certain terms as representative of communal interest, is of particular interest in a study of Romanticism."²¹ The "interesting ways in which the software itself provides order" from apparent disorder, via linking patterns and other contextualizing elements, prompted insight into the process of the research.²² For instance, "posting tendencies emerged that were worthwhile pondering as a class and could be framed as the expression of this group of students. This discussion attracted elaboration; this poem went unlinked; this author attracted biographical elaboration; this entry was cited often by other entries; etc."²³

Perhaps the most common pedagogical application of wikis in education is to support writing instruction. At Teaching Wiki (http://teachingwiki.org), Joe Moxley, a professor of English at the University of South Florida, lists a number of the medium's strengths for the teaching of writing skills: wikis invigorate writing ("fun" and "wiki" are often associated); wikis provide a low-cost but effective communication and collaboration tool (emphasizing text, not software); wikis promote the close reading, revision, and tracking of drafts; wikis discourage "product oriented writing" while facilitating "writing as a process"; and wikis ease students into writing for public consumption.²⁴

In addition to fostering the development of writing skills as they are already understood, wikis may prove to be invaluable for teaching the rhetoric of emergent technologies. Jill Walker, a hypertext theorist and prominent weblogger, suggests that whereas online technologies are fine for teaching things that can also be done with a paper notebook, a more important ability "to teach our students is network literacy: writing in a distributed, collaborative environment." Walker recognizes that bringing network literacy to the classroom is no simple task, that it "means jolting students out of the conventional individualistic, closed writing of essays only ever seen by [their] professor."²⁵ As wikis enter the academy, students may not be the only ones jolted out of conventional practices.

Pedagogical Challenges

Moving instruction into the chaotic wiki medium presents challenges on a number of fronts. Tracking work created in wiki spaces can become a logistical nightmare, and course management can spin out of control quickly if pages are allowed to spawn without some set of protocols to regulate or index them. Attribution of individual work can be difficult, and an environment in which students (or even nonstudents) are invited to rework content further complicates matters. Seemingly minor contributions to a collaborative document may have major effects, effects that may be near impossible to assess fairly or even to detect.

As with the security issue, most of the pedagogic dilemmas presented by wikis can be addressed by "traditional" management approaches. For instance, students may be required to sign or identify any work that they author. Bowdoin College's Romantic Audience Project asked participating students to avoid making changes to text written by others (poets or fellow students) and to limit themselves to the addition of related links. Instructors may choose to establish categories, topics, and other prompts to direct student participation into more orderly channels.

Indeed, an instructor could structure and regulate interaction to such an extent that the wiki is effectively transformed into a stripped-down course management system. But doing so risks diluting the special qualities that make wikis worth using in the first place, with the result being, in the words of Heather James, "pumped-up PowerPoint." James has described the experience of using wikis in her teaching as her "brilliant failure." She regrets that she "changed the tool, but did not change the practice," and failed to account for the "great potential in this tool to be completely disruptive (in a good way) to the classroom setting." With the benefit of hindsight, she concludes that for wikis to fulfill their promise, "the participants need to be in control of the content you have to give it over fully."²⁶ This process involves not just adjusting the technical configuration and delivery; it involves challenging the social norms and practices of the course as well.

This particular challenge bears resemblance to the one posed by constructivist teaching philosophy. To truly empower students within collaborative or coconstructed activities requires the teacher to relinquish some degree of control over those activities. The instructor's role shifts to that of establishing contexts or setting up problems to engage students. In a wiki, the instructor may set the stage or initiate interactions, but the medium works most effectively when students can assert meaningful autonomy over the process. It's not that authority can't be imposed on a wiki, but doing so undermines the effectiveness of the tool. It's a safe bet that wiki-like writing spaces will be featured in future course management systems, along with other "social software" tools and protocols such as weblogs and RSS, but if practices don't evolve, the effects on student learning will be superficial at best.

The Intellectual Property Impossibility Theorem

Another policy issue that threatens to complicate the widespread adoption of wikis in higher education is the specification of intellectual property (IP) rights by contributors to a wiki page. IP issues can be dauntingly complex under any circumstance, but when contributors may be anonymous, or where the origins of texts are uncertain, copyright questions are significantly complicated. The open-editing function of wikis implies that a work may perpetually be in process, inviting participation from anyone. But what if the author of a page does not accept the implications?

Three common IP schemes presently in use by wiki communities, when they bother to define a policy at all, are CommunityCopyright, PublicDomain, and CopyLeft.²⁷ A CommunityCopyright policy allows individuals to assert rights over their work while allowing their contributions to be modified within the wiki. (Of course, the copyright owner can subsequently reverse those modifications.) A PublicDomain policy dictates that any contributor to the wiki space surrenders all copyright. A modification of this approach is PrimarilyPublicDomain, which assumes a PublicDomain policy unless an individual specifies otherwise. CopyLeft allows anyone to use the content of the wiki for any purpose and to make derivative works, under the condition that all copies and derivative works are released under the same license as the original. The contributor maintains copyright.

Any one of these policies is reasonably straightforward. But things can get nasty in wiki communities in which different users hold divergent visions of what constitutes an appropriate policy. The result is an application of what the CommunityWiki describes as the SecondCopyrightImpossibilityTheorem: "Every copyright policy will be incompatible with at least one other copyright policy in at least one direction. This will occur even where all parties concerned desire the copyright policies to be compatible."²⁸

There are no easy answers to the theorem, it is impossible, after all, though ill-feeling may be lessened by specifying one policy or another, preferably after consulting the user community. Hopefully those who cannot accept the conditions will find some other place to post content.

Technical Considerations
(But Hopefully Not For Geeks Only)

As users apply wikis more commonly in their practice, they increasingly come to depend on them. A gradual increase in user expectations has potentially serious consequences. For instance, a brief Internet server failure (it's been known to happen) may be catastrophic the night before an assignment deadline, or just before a conference presentation, if users have not been prompted to save backups on their personal hard drives. Similarly, project leaders may regret plunging ahead with wiki-based initiatives without considering potential technical pitfalls.

There is no unified set of software characteristics that are shared by all wikis. The dozens of prominent wiki engines freely available for download on the Internet vary in approaches, programming languages, and architectures.²⁹ Technical quirks of wiki systems, indicative of the often anarchic programming communities that have developed them, need to be considered before choosing a system. Different wikis may store content in distinct ways, which may result in significant challenges when migrating content from one system to another. There is no standard mark-up language among the various systems and therefore no guarantee that migrated content will be displayed properly in a new environment. The feature sets of various systems should be compared before making a selection,³⁰ and important pages should periodically be backed up, by encouraging users to save copies on their own hard drives and by conducting any server-side data backup procedures that the installation can support.

Wikis Are Just One Piece

Many of the most notable characteristics of wikis, relative simplicity, empowered users, bottom-up organization, also describe other technologies, such as weblogs, distributed communities linked by RSS, and mobile applications. Each of these tools is seeping into practice across the academy, but the patterns of adoption are erratic and halting. Although emergent practices may be growing in popularity, they still sit outside the mainstream and are typically dismissed as intriguing yet somehow trivial by many practitioners and managers.

It is clear, however, that wikis and other emergent technologies are filling a gaping void in existing practice. Mayfield observes: "When a disruptive technology arises in your enterprise it means that IT isn't fulfilling the needs of users."³¹ The needs met by wikis' easy authoring of Web content, open access, unrestricted collaboration, are simply not being satisfied by present IT strategies and tools. The reaction against this unacceptable state is being expressed in countless, constantly mutating pages across the Internet. The desire is clear; the will is insistent. Change is happening. What remains unknown is whether educators, institutions, and developers will join (or coexist with) the revolutionary forces or whether they'll stand their ground and simply be overrun.

1. Tim Berners-Lee, talk at the MIT Laboratory for Computer Science (LCS) 35th anniversary celebrations, Cambridge, Mass., April 14, 1999, http://www.w3.org/1999/04/13-tbl.html.

2. Various authors, "Elements of Wiki Essence," WikiWikiWeb, http://c2.com/cgi/wiki?ElementsOfWikiEssence.

3. For a short case study about our experience, see Brian Lamb, "Taking a Walk on the Wiki Side," Syllabus Magazine, April 1, 2004, http://campustechnology.com/articles/2004/04/taking-a-walk-on-the-wiki-side.aspx?sc_lang=en.

4. Jim Sibley, e-mail to the author, February 14, 2004.

5. Laural Raine, e-mail to the author, February 17, 2004.

6. Mary Bryson, e-mail to the author, June 24, 2004.

7. Teresa Dobson, e-mail to the author, February 15, 2004.

8. Various authors, "SoftSecurity," MeatballWiki, http://www.usemod.com/cgi-bin/mb.pl?SoftSecurity.

9. Various authors, "Why Wiki Works," WikiWikiWeb, http://c2.com/cgi/wiki?WhyWikiWorks; Clay Shirky, "Wikis, Graffiti, and Process," Many-To-Many: Social Software, August 26, 2003, http://www.corante.com/many/20030801.shtml#50187.

10. Various authors, "Power Structure," Wikimedia Meta-Wiki, http://meta.wikipedia.org/wiki/Power_structure.

11. Various authors, "Darwikinism," Wikimedia Meta-Wiki, http://meta.wikipedia.org/wiki/Darwikinism.

12. IBM Collaborative User Experience Research Group, "History Flow," http://www.research.ibm.com/history/.

13. Ross Mayfield, "Wiki IT," Socialtext, May 24, 2004.

14. Various authors, "AboutWikiNavigation," Wiki Guide, http://wikiguide.coedit.net/AboutWikiNavigation.

15. Ross Mayfield, "Wikis Are Beautiful," Many-to-Many, April 30, 2003, http://www.corante.com/many/archives/2003/04/30/wikis_are_beautiful.php.

16. Elizabeth Lane Lawley, "Why I Don't Like Wikis," Many-To-Many, April 26, 2003, http://www.corante.com/many/20030401.shtml#31542.

17. Giles Turnbull, "Talking to Ward Cunningham about Wiki," luvly, April 6, 2004, http://gorjuss.com/luvly/20040406-wardcunningham.html.

18. Various authors, "Mission Statement," WikiFish, http://wikifish.org/.

19. Various authors, "Twenty Questions," WikiFish.

20. Various authors, "Mission Statement," WikiFish, http://wikifish.org/.

21. Various authors, "What's Romantic about the Romantic Audience Project?" Romantic Audience Project, http://www.rc.umd.edu/pedagogies/commons/innovations/rap/pages/romantic_premise.htm.

22. Various authors, "How Did Wiki Software Shape This Project?" Romantic Audience Project, .

23. Various authors, "In What Way Is RAP a Collective Study?" Romantic Audience Project, http://www.rc.umd.edu/pedagogies/commons/innovations/rap/pages/collective_study.htm.

24. Joe Moxley et al., "Why Use Wikis to Teach Writing?" Teaching Wiki, http://teachingwiki.org/ow.asp?Why%20Use%20Wikis%20to%20Teach%20Writing%3F.

25. Jill Walker, "Talk at Brown," jill/txt, December 5, 2003, http://jilltxt.net/?p=541.

26. Heather James, "My Brilliant Failure: Wikis in Classrooms," Kairosnews, May 21, 2004, http://kairosnews.org/node/3794.

27. Various authors, "WikiCopyright," MeatballWiki, http://www.usemod.com/cgi-bin/mb.pl?WikiCopyright.

28. Various Authors, "CopyrightImpossibilityTheorem," CommunityWiki, http://www.emacswiki.org/cgi-bin/community?CopyrightImpossibilityTheorem.

29. For a comprehensive overview of technical issues related to wikis, see David Mattison, "Quickiwiki, Swiki, Twiki, Zwiki, and the Plone Wars: Wiki as a PIM and Collaborative Content Tool," Searcher: The Magazine for Database Professionals, April 2003, http://www.infotoday.com/searcher/apr03/mattison.shtml.

30. See James Farmer, "The Wide World of Wiki: Choosing a Wiki for an Element of a Fully Online Undergraduate Course," Incorporated Subversion, June 10, 2004; Linda Schwartz et al., "Educational Wikis: Features and Selection Criteria," International Review of Research in Open and Distance Learning, April 2004, http://www.irrodl.org/index.php/irrodl/article/view/163/244.

31. Mayfield, "Wiki IT," Socialtext.