In February of this year an article was published by Steven Andrew Mathieson in Guardian Unlimited on public sector wikis . Mathieson proclaimed the rise in creation and use of wikis by UK state sector organisations. This article will look objectively at this apparent rise and will consider whether wikimania has truly hit the public sector.
In the Web 2.0 world those of us working with the Web now live, there is an increasing awareness of changing audiences and expectations. The digital natives are growing up, packing up their winter woollies, laptops and iPods and heading on down to University. Some have even stepped onto the career ladder. The Web 2.0 attitude of scalability, remixing, participation and collective intelligence has already hit the mainstream. It seems the public sector needs to move with the times. With the Web 2.0 label comes a range of 'new' technologies to be exploited. Few can fail to have heard mention of RSS, blogs, podcasts and wikis. However the public sector still has limited resources, existing expectations to manage, funders to keep happy and users to support. The question is can the public sector find the balance between adopting these new technologies and offering the quality service it is required to provide? Is it already walking this tricky tightrope?
So what is a wiki? Ward Cunningham (the originator of the wiki way back in 1994 ) originally described them as "the simplest online database that could possibly work". For those less interested in their technical architecture, a wiki is, quite simply, a Web site that allows users to add and edit content as a group.
The key characteristics of a wiki are actually few in number. They function in two complementary states. Firstly a read state, where they play the role of a normal Web site and can be read by any user; and secondly an edit state which consists of Web space that can be freely and easily written to or edited by anybody (allowing for collaborative writing). They use a simple markup language (wikitext or wikisyntax) for the editing of these pages. Many offer a choice between user logins or an open site and most wikis now provide users with the ability to compare previous versions of a page and revert back and track who has edited a page. Some wikis also allow users to discuss issues prior to making changes. Wikis are both organic, in that they evolve naturally over time, and incremental, in that they can grow bigger, fast. For a more in-depth definition, refer to Emma Tonkin's January 2005 Ariadne article Making the Case for a Wiki .
The popularity of wikis has increased in the last few years with the rise of social software and building of communities. Right now we are experiencing an exciting time in wiki history with wiki software being available by the dozen (e.g. Mediawiki, Twiki, Kwiki, Moin Moin, Instiki, Confluence, SeedWiki) and a new wiki community being created every day. We have even seen a rise in wiki indexes and search engines (wiki Index , Switch wiki, wikisearch, Qwika) and sites comparing wiki functionality (wikimatrix). This new culture of collaboration alongside the creation of successful wikis like wikipedia , wikitravel  and more recently Ganfyd , a medical wiki, has started talk of 'wikimania'.
But what of the public sector wiki? Is it thriving, as Mathieson's article suggests, or is there still a way to go?
A quick search on Google for public sector wikis brings back a lot of hits but very little actual activity. Although the US is currently much further ahead of the UK when it comes to use of wikis, it does not take long to realise that interesting and notable collaboratively created wikis are still few and far between on either side of the Atlantic. Admittedly there may be much more wiki action buried down the Internet haystack in access-restricted sites, but the idea that every man and his dog has a wiki just does not seem to ring true. A few examples of the more worthy public sector wikis openly available are given below.
Dowire.org , is a wiki tied in with the DoWire Web site, a primary source for important developments concerning the convergence of democracy and the Internet around the world. The wiki is essentially a one-man shop run by Steven Clift, a researcher based in Minneapolis. Bristol wireless  on the other hand is a co-operative set up to develop a free-to-access broadband intranet using radio to communities around Bristol, UK, that find themselves on the wrong side of the digital divide. The project is supported by the NHS and charitable organisations but is primarily led by volunteers. Flu wiki , is a national online resource created to help local communities prepare for and perhaps cope with a possible influenza pandemic; once again it is not government-led but was set up by local citizens.
The e-innovations  wiki, originally cited in Mathieson's aforementioned article, was created to house discussion and debate around innovation in local government in areas such as improving the quality of services, delivering efficiency, joined-up working and community engagement. The site is government-led but not particularly well used and low on edits. There is as yet no sign of a number of the other government wikis mentioned by Mathieson, unless they are being used internally only. For example, the wiki proposed for fire authority staff by the local government partnership IdeA (Improvement and Development Agency)  has not yet surfaced. Recently the plug was pulled on the Department for Environment, Food and Rural Affairs (Defra) wiki, David Miliband's project. The suspension of postings was attributed to malicious editing problems. Other government departments also seem reluctant to put a toe in the wiki water. The NHS has still to establish an external wiki, despite many rumours.
It seems necessary to reiterate that it is difficult to know what is going on behind closed doors and wikis may be being used internally or are currently 'under development', but at the moment the 'out there' number seems low.
Library and Information Science has been one of the first public sector areas to adopt wikis for a range of uses including staff development. In the United States libraries are slowly beginning to experiment with wikis and use them in different practical and interesting ways. In time the UK could easily follow suit (more on this later); however there are few UK libraries currently using wikis externally. Some examples of well-used sites in the States include Ohio University Libraries Biz wiki , State University of New York Library wiki  and St. Joseph County Subject Guides . Another valuable resource is Library Success , a best practice wiki for librarians, created by Meredith Farkas, Distance Learning Librarian at Norwich University, Vermont. It is a one-stop-shop for ideas and information for librarians, whether public, academic or specialist. LIS wiki  is a similar resource and was established to give the library community a chance to explore the usefulness of wikis. It is not intended to replace or detract from the wikipedia library and information science articles but to exist as a 'niche encyclopedia' covering library-related issues.
In the UK, a fledgling site set up by Kara Jones, a librarian at the University of Bath Library and Learning Centre, is the library podcast group . The wiki is being used as the collective memory for the library's podcasting experiences. Kara explains that the wiki is being trialled as a way to move on from using emails. "We do send emails but it's easy to forget how you got from decision A to decision B with emails, they don't give an overall picture in one place whereas the wiki allows you to follow a train of thought all on one page...whenever I browse the site I realise how far we've come with our tasks. It's also easy to set up, and looks quite professional."
Although there are examples of wikis being used as part of learning and teaching courses, once again education sector wikis are few on the ground. The OSS Watch wiki  has now been running for almost a year and is for everyone interested in open source in Higher and Further education in the UK. The Moin Moin wiki they use works well as an area for discussion among the core OSSwatch team but although well read it has only a few external contributors, but has still been an important community building tool. The DigiRepwiki  is intended for all those working on the JISC Digital Repositories Programme and other experts in the field of Digital Repositories. The wiki is maintained by the Digital Repositories Support team at UKOLN and CETIS and again although it is well used it has not had a huge amount of input from the community.
A number of universities have begun looking at wiki software for use as an information source and for e-learning. One useful idea tried out by Manchester University is the wikispectus , an alternative prospectus. A wikia (a collection of freely-hosted wiki communities using the same MediaWiki software) of known university wikis  is also worth visiting, but currently covers some countries, such as Germany, much better than others. Other useful wikis aimed at the education sector include Meatballwiki , a community of active practitioners striving to teach each other how to organise people using online tools, and Wikiversity , a community for the creation and use of free learning materials and activities. Wikiversity is a multi-dimensional social organisation dedicated to learning, teaching, research and service. Both services have built up an established community of users.
One example of a truly successful public service wiki is the BBC's h2g2  (an acronym of Hitchhikers Guide to the Galaxy , a radio series and novel by Douglas Adams). The site, like wikipedia, covers many general topics and has enjoyed considerable take-up by the BBC Web site users. No doubt it is h2g2's very general nature that grants it such a large audience.
This brief look at the relatively small number of public sector wikis that are easily accessible raises two questions:
Success, like impact, is a very difficult entity to measure. Does a wiki have to have many contributors to make it a success or does having a group of interested readers count? One could argue that success should be measured by an object's ability to do the job it was intended for (hints of Quality Assurance here?). If this is the case, then collaboration is at times only a by-product.
As part of a recent dialogue held on the Web4Lib list  (a US mailing list for library-based World-Wide Web managers) attempting to establish if practices are emerging in terms of the use of wikis in libraries, Tom Keays, Science and Technology Librarian at Syracuse University, made the following comment: "Something that has been bothering me about this discussion is a sort of creeping assumption that for a wiki to considered successful, then everybody who uses it has to also be an author. Where is this actually the case? On regular websites? On user-contributed product review sections of shopping sites? On this listserv or any other listserv? The actual case seems to be that the majority of people read the content of all of these examples and benefit (or not) from reading them, but few of them are authors. So why insist that wikis are unsuccessful if only a small percentage of people learn the syntax and write content?" Discussion lists themselves offer a good example of a service that centres on participation but equally has benefits for those who read but never post, and even for those who stumble upon the archives by accident.
Discussion aside, the potential uses of wikis are many. They can be easy to use, great for collaborative work and have many useful features such as versioning control. Yet, if it is the case that only a few public sector organisations are using them, what is the underlying explanation?
The actual physical setting up of a wiki is fairly straightforward. Once a decision is made to use a wiki for a particular task, the first step would be to think about what software to use and whether to go for an open source or commercial solution. Given the number of good-quality free and open source products out on the market, it would seem a shame to take another approach. The software would then need to be loaded locally on to the organisation's Web server. At this point it would be useful to agree on details (such as permission levels, licences, URL etc.) Once the basics have been decided, a core group would need to take on the responsibility of creating the basic structure. This would include customising areas, setting up templates, adding extensions and features. When the site is 'established' it would need to be populated with some core documentation (such as help and editing information), and content. It always makes sense to have some copy on your site already before you release it to the Web. There is nothing so discouraging to potential contributors as an empty wiki. Once the site is ready publicise it (initially to a small group), train and coach users and let it evolve. Hey presto!
It all sounds so easy. However there are underlying issues that are more complex than the physical establishment of a wiki. Firstly there still remains the danger of never-ending experimentation or the 'perpetual beta'. The war of wiki software has yet to be won and although your organisation may be currently committed to a system, it is quite possible that at some point it will find itself migrating from this system to another. Though doing so is not necessarily as much trouble as it sounds; in the future it is likely that there will be greater consensus and wider interoperability between systems. However pledging allegiance to a particular software product, especially when the dust has yet to settle, is always difficult with new technologies. Any potential instigators will need to balance the challenges of improving functionality through new software against the benefits to users from its adoption.
Another obstacle to use is that non-technical users who want to take the initiative on creation of a wiki will usually need to do so through their systems team. Sometimes pushing a new technology that has yet to demonstrate its worth conclusively can be difficult. Without the systems team on side, would-be users may find themselves side-tracked and never make the leap. Then there remains the fact that many people are not completely technically savvy and are still daunted by the prospect of using a tool that they are not even sure if they are pronouncing correctly! Although some wikis offer WYSIWYG capabilities, most will require creators to learn, at the very least, the rudiments of a particular wikitext. The wiki concept has still a way to go before it reaches the consciousness of the 'not so technical'.
When creating a wiki within an organisation there are likely to be a number of organisational concerns that may need to be taken into account. Wikis give users the freedom to move away from the usual design, protocols and habits that a standard Web site imposes. The leaders in some organisations may feel threatened by this freedom and some aspects of wiki usage may go against the organisation's acceptable use policy. Wikis, by their very nature, provide a collective view and this may not always represent an unbiased perspective. External users may ask whose opinion is it anyway? And an organisation may need to say 'not ours'. Such issues may have more prominence in larger hierarchical organisations with more 'chiefs and indians' rather than those with a flatter structure, or a virtual community. There is definite value in an agreed policy on usage, as is probably the case for any outward-facing technology. Organisations may also worry about accountability and liability regarding copyright and IPR issues. Most wikis tackle copyright by using liberal licences such as public domain, copyleft and community copyright. Many also explain where they stand regarding copyright explicitly on the wiki in a policy section. As with any new organisational tool there are also the usual resource issues, where will the staff training time come from? What about the extra technical support time required? What about the time taken for content moderation? What about organisational buy-in? If internal staff are not on-side then how can a wiki even progress beyond the idea stage?
One barrier to operation currently producing considerable debate is possible vandalism. Established wikis, like Wikipedia, have suffered severely at the hands of vandals; the most prominent case to date being journalist John Seigenthaler's entry in Wikipedia. One user edited the entry to claim Seigenthaler was connected with the Kennedy assassination , an allegation that Seigenthaler obviously took very seriously . Those responsible for setting up a wiki will need to consider how they will deal with mischief-makers, be they human or electronic (sent by spambots). Possible solutions are having moderators on hand and community policing or 'soft security' (allowing the community to weed out trouble-makers). It also makes sense to set up guidelines for usage or allow users to alert moderators to inappropriate posts. By using the roll back functionality most wikis could trace comments back to people and revert back to a previous state, but by this time the damage may already be done. But as the Educause introductory leaflet on wikis points out: "while the potential for mischief exists, wikis can be surprisingly robust, open-ended, collaborative group sites."  The element of community works well and also assists in the establishment of wiki etiquette: encouraging users to remain civil, credit work, keep on topic and edit rather than delete.
Other possible hindrances to the creation and take-up of a wiki include hesitations over consideration of preservation issues (how do we archive constantly changing ephemera?), worries about sustainability and the lack of metadata for pages, poor mark-up standardisation and issues with the quality of information on the wiki (is it out of date, are the wrong words being used, does it translate, is it readable?). These are all matters for another article but all need to be weighed up alongside the go ahead on a new technology.
However the biggest barrier of all is getting people to use a wiki. In her Ariadne article Emma Tonkin quoted a colleague as saying 'there's nothing sadder than tumbleweed blowing through an abandoned messageboard'. This tumbleweed syndrome is a valid fear for those establishing a wiki; and will be the reality of many. The notion of ownership remains so deeply embedded in our society that many users still find it difficult to change things on another person's Web site. We are so used to the idea of Web sites as entities that are controlled by their creators that challenging this control is unnatural. Neither is contributing online a common habit for most. The 1% rule suggests that for every 100 people online, one will create content, 10 will 'interact' with it (commenting or offering improvements) and the other 89 will just view it . Many will want to contribute but feel too self-conscious or are unsure of exactly how they can contribute. It was also suggested in the aforementioned Ariadne article that correcting a wiki page requires aggression. Does your community have that aggression? People may be looking at your wiki, but stopping it from becoming an unmaintained storehouse of out-of-date information will remain the biggest challenge. How can you encourage participation, be it internal or external? This said a wiki still goes a long way to breaking down the 'us' and 'them' mentality that authored Web sites create. Although participation levels on wikis remain low, any wiki lowers the barriers to participation because you can edit the site if you want to with relative ease. An option not offered by any traditional Web site.
At this point it might be useful to consider two case studies:
In May 2006 UKOLN set up the Interoperability Focus Community wiki using Mediawiki, UKOLN's current wiki of choice, as an experimental service. A content management system (CMS) wiki was requested as part of the feedback from the Institutional Web Management Workshop 2005  (an annual event for institutional Web managers) and it was acknowledged that a knowledge base and discussion place would be useful. Prior to the creation of the site a wiki peer group was established for feedback on areas like licence, registration details, basic structure etc. After much deliberation a dual licence was decided on (CC and GNU FDL) and the pilot site was rolled out for use at the Institutional Web Management Workshop 2006 and used as an event tool. 
The wiki remains very much a pilot site and it is hoped that lessons learnt from the use of the site will support the creation of a more permanent resource intended for Institutional Web Management Community in 2007. So what have been the main successes of the wiki? At this year's Institutional Web Management Workshop the wiki was used extensively for small group working (parallel session groups) as a collaboration tool. This worked well because the site was open access and all changes to text were immediate and visible. The Intranet discussion area of the site has also seen considerable interest. However, possibly due to lack of promotion, and having no stated champion, the CMS discussion attracted relatively little interest.
Use of the pilot wiki has been helpful in considering a specification for a long-term site. One of the key changes to be made will be a branding change and name change to tie the wiki in more closely with the Institutional Web Management Community (and related events). There also needs to be more space given to discussion, further promotion and adding in some Web 2.0 ideas, such as syndication, tagging, etc. There have been many useful lessons learnt from the Interoperability Focus Community Wiki experience. These include ensuring you choose the right features and thinking about access/version control and the ease of use in advance. Also make sure you and your community are ready to try out a new way of thinking. The most useful lesson has been that wikis need three people to give them a long and healthy life: a midwife, a champion and a minder! Hard work if you have only a small amount of one person's time available.
One internal wiki that is used locally here at the University of Bath is the WebDevWiki. Installed in December 2005 by the Bath University Computing Service the project has been a great success. Phil Wilson, Web Developer, who worked on the establishment of the wiki explains:
"I was new to the team and there were a lot of different discussions going on about a lot of different projects, and the team was spread throughout a number of rooms so it was very easy to miss part of the conversation or lose track of what was going on and none of it was ever documented. Every now and again someone would create a Word document and put it in a shared network drive, but this only happened on exceedingly rare occasions and as a result, no one ever checked it, and it was impossible to find out automatically when changes were made. I'd rolled out a wiki at my last place of work and so I knew what kind of improvements it could make to knowledge sharing and collaboration, and so set up a team wiki to see if it would be useful here. It was, and we now have hundreds of pages detailing everything we've done, how we did it and what we're planning to do.
The wiki's main aim is to make sure that everyone in the team is aware of everything that is going on, and provide a degree of transparency to the rest of the department, anyone in the department can read and edit our team wiki. We get questions left about certain policies and directions, which we're then able to consider and answer. It's being used exactly as intended, which is really great. As well as documenting official team activity we also have several pages which just document things that might be interesting to others, code snippets and project wishlists. We had no way of easily sharing this information before.
Apart from the meeting its main aim of better documentation and knowledge sharing, the biggest success has been that other teams in the department have seen how the wiki works and how we use it, and we have since rolled out four other team wikis, which are used with varying degrees of success.
The biggest failure is based on the success, which has caused users to make requests for other wikis to be rolled out. We have rolled out separate wikis with separate authentication procedures and have thus created ourselves a maintenance and scalability problem. We hope to address this in the near future by rolling out a wiki-farm system, which can host any number of wikis with minimal administrative overhead.
In particular I have learned two lessons:
1) The success of a team wiki is dependent on someone within that team really championing its cause and ensuring that the information on it is valuable to the rest of the team. Without at least one person making sure it gets used then no one will ever look at it.
2) Do it! There was a little scepticism when we started out, about pages getting out of date, becoming unmaintained and so on, but it turns out that there's very little data we use which really needs updating all that often and we've really benefitted by getting everything else in a central location. Unless you try, you'll never know!"
This article has intimated that take up of wikis in the public sector is still slow. However this does not mean that things will not change, and fairly rapidly at that! There are two key areas worth watching: e-learning and libraries.
Meredith Farkas, the founder of Library Success , has written extensively on the use of wikis by the LIS community and has said, "The possibilities for what libraries can do with wikis are endless. At their least, they are spaces for quick and easy collaborative work. At their best, they can become true community resources that can position the library as a an online hub of their local community." A number of ways in which libraries are starting to use wikis have already been mentioned, but the true potential for library wikis lies in getting the community on board. A library wiki could have an area for book reviews, comments and a suggestion box. It could try out community-led frequently asked questions (FAQs) or commonly asked questions in either reference or general library, or community-driven subject guides. Users could create their own local history repositories or personal story stores. Wikis could also be used for library project work, input for research work, course collaboration and e-portfolios. There is also great scope for tying together the catalogue and the wiki and supporting annotation of the catalogue. OCLC is currently working on putting wiki functionality into Open WorldCat , so that people can add reviews to book entries. More has been written on how the LIS community can take things further in Jane Klobas' recent book Wikis: Tools for Information Work and Collaboration. 
With the take-off of collaborative learning, the second area that holds great potential for wikis is e-learning. Much of the current pedagogical thinking advocates active learning and asserts that learning itself is inherently social. With this in mind, much more use could be made of wikis in the education arena; because they support sharing and collaboration, wikis are great for group project work and peer-to-peer activities. They can allow students to create conference style presentations, work on specific activities and are good for reflection on written work (critical assessment and peer review), contextualising, etc. The discussion page functionality can encourage debate of topics. They also allow the creation of shared repositories of resources and shared reading lists. One important aspect of wikis is that they allot ownership by handing it to the user. This said, there can be tensions when using wikis; for example between the individual and the group, between the people creating the wiki and those using it and between the teachers and the learners, partly due to the loss of control mentioned earlier. Many of these tensions have already been looked into in more detail in the wider e-learning world and by various learning environment providers. The open source course management system Moodle hosts a number of colloquiums dedicated to discussing technology and pedagogy. 
One interesting article that reports on a teacher's attempt to use a wiki in the classroom is My Brilliant Failure: Wikis In Classrooms  by Heather James. James realises that to really get a wiki to work as a learning tool, "the participants need to be in control of the content - you have to give it over fully." She concludes that when using a new technology like a wiki, time and access are important factors and that it is important to reconstruct our concept of schools. Ultimately she felt that for her experiment to have worked, it would have been better for students to "identify the blanks themselves" and for her to have let go of the reins. It seems that the old e-learning problem of changing social norms and practices applies just as much to wikis. Another institution that has trialled wikis in the classroom is Deakin University , Australia, where a wiki was used in the form of icebreaker exercise for students to complete. Their positive experience shows the potential of truly involving students.
Matt Barton , assistant professor of English at St. Cloud State University in Minnesota, consistently uses wikis on his courses. He feels that the wiki ideology is in line with creative writing teaching ideology: "I believe that writing should be approached with the same sort of playful creativity with which hackers approach programming. After all, language is a sort of "code" made up of various parts and routines that we assemble together to speak, write, or even think."
Wikis have great applicability to the e-learning environment but there are serious pedagogical implications and many hurdles to jump. For a start, many teachers and lecturers need to become more comfortable with the actual wiki technology, many might feel that it is just another obstruction to letting them do some 'real teaching' rather than seeing it as a tool to be used. A recent book entitled Using Wikis in Education  considers these issues further. It was actually written in a wiki and is available online for users to edit.
This article has surmised that there is still little use of wikis among public sector organisations and suggested some barriers as to why this is the case. However there is little doubt that wikis hold great promise for the public sector and if registrations to the UKOLN Wiki Workshop  (which was fully subscribed nearly a month in advance of the event) are any indication, then it is clear that general interest in wikis is continuing to grow. However global adoption at present remains the other side of a chasm. Geoffrey Moore, in his 1991 book of the same name, talked of how Crossing the Chasm needed to be the primary focus for those pushing any new technology. Most new technologies initially get taken on board by a few visionary people, later on they move to the mainstream market dominated by a large group of people who are predominantly pragmatists in orientation. The chasm marks the gap between these two points. For wikis to make this leap, in the public sector, there needs to be a significant number of success stories.
So what is the key to a successful wiki? We've established that success is not written in stone, but one factor that significantly influences adoption is community. As Clay Shirky puts it "A wiki in the hands of a healthy community works. A wiki in the hands of an indifferent community fails."  Before you even begin to develop a wiki you need to know your audience and think about whether this is what they want. Are they a group who can and will converse? The likelihood is that if they cannot converse offline then they probably will not online. As the guiding force behind a wiki you need to support the group and encourage accountability and group cohesion, you need to expand your community's involvement. You should have strategies for encouraging contributors, such as offering a service to check contributions from newbies and supporting those unsure of etiquette. Building a community takes time. It is important to make sure people understand why it makes sense to share, and to provide them with an environment that makes it easy for them to do so. Nonetheless, remember that just because a wiki allows anyone the ability to take part in the creation and editing of Web content it does not mean everyone will.
While community is a significant contributor, a wiki also needs flexibility to fulfil its promise. A successful wiki needs to be dynamic and reactive, changing appropriately to fit users' needs. It may well take an implementation (or two) to get it right but you need to be patient. At this relatively early stage in the game for wikis it probably makes sense for us to avoid 'pigeon-holing' the wikis that are emerging ("it's for collaboration", "it's to get people involved") and just allowing them to develop organically. In the aforementioned Web4Lib discussion  KG Schneider suggests that there is "room for employing a technology when you aren't entirely sure what the benefits are... Every deployment has its elements of a gamble. You can be confident something will be a big hit, and it fizzles. Something that seems like a fad turns out to become central to your services. Or you install a product to do X but it turns out to be only OK for X but surprisingly fabulous for Y and Z, which you had not at all considered in advance." While we may not all have the time or money to experiment, it is important to recognise that the line between 'fad' and 'something we can no longer do without' is relatively indistinct and highly dependent on the culture in which we work.
Given the current level of development and innovation in this area, it would be fair to conclude that a flexible and pragmatic approach is most likely to inform effectively any strategy for adoption of a wiki; and that flexibility must also comprehend the uses to which its intended community puts it, uses which it may take a little time to identify.