TAG presentation

This presentation accompanied the talk given during the session. The script was less formal and detailed than the paper below.

Perpetual beta and other production models: Are changes in perspective necessary for successful open, online archaeology?

The transition to digital production models in archaeology (the use of computers during data gathering, processing and dissemination) is as inevitable and unpredictable as any other technological shift. Unusually, archaeologists are attempting to understand the effects of such a shift without the benefit of a broad chronological context or separation from the shift's effects. Further, web technology now appears to be developing so rapidly that it appears unlikely that a new, stable paradigm for communication will ever be reached - perpetual revolution is now the norm. A colleague once remarked that expecting to develop and maintain stable solutions for digital archaeology is like attempting to build a house in a hurricane (Ash Scheder Black, pers. comm. 2011). Despite this, it is clear that a reflexive, sensitive and proactive approach to these developments is more useful than merely following on the coat-tails of the web's development. With this in mind, I would like to suggest that one of the most useful theoretical concepts included in O'Reilly's original definition of Web 2.0 has received insufficient attention: Perpetual beta.

Perpetual beta is now a common way of producing computer software. At it’s most fundamental it is a philosophy of working that admits that very little is ever truly complete or fixable as a ‘finished product’. It also breaks down the barriers between producers and consumers and makes production a far more social process. This philosophy (in combination with web-based tools) provides a number of potential advantages and challenges for archaeological workflows and modes of production. Using the archetypal archaeological product – the excavation monograph – as an example, I explore whether an attitude of perpetual beta is a crucial stepping-stone to open access production, open data and stronger collaborations in archaeology.

Perpetual beta: the basics

At its most fundamental, perpetual beta is the idea that since no product is ever perfect, one designs it with constant updating and improvement in mind. In essence:
  • constant improvement through feedback
  • increased openness and documentation throughout the production process
  • a collapse of the barriers between producers and users
  • better, multi-directional communication amongst the producers/users

Perpetual beta began as an alternative way of producing computer software. Instead of mimicking the production of physical objects going through design, testing and eventually being released lots of software is now released at a 'beta' stage meaning that the original producers recognise that imperfections remain. The most radical models of this 'perpetual beta' method have no hard line between the creators and consumers of the software: anyone can contribute an update, bug-fix or add-on and the user-community uses collective quality-control to vet these changes. Open-source software is, perhaps, best exemplified by Linux - a family of operating systems used to run everything from commercial PC's to military hardware and major internet servers.
The social aspects of the internet are crucial to this model: those with relevant knowledge are often keenest to use the product and become the first users, forming a spontaneous community. These users then feedback on bugs, generate ideas for new features and other improvements to the software. Subsequent users form a 'long tail' of those less engaged with the product's creation but still reaping the benefits of software that is constantly improving.

Parallels can be seen between this model and the ways in which modern news/information websites work: in terms of both content and infrastructure. Rather than a regulated, periodical output of content (the digital equivalent of a magazine or newspaper) content is uploaded as it becomes ready and can be retro-actively corrected or updated. The most radical departure from print-style production of content is in wiki environments such as Wikipedia.

What might it look like for archaeology?

Imagine the proposal for a new academic fieldwork project was submitted not only to the funding body but made available to anyone interested (it is seeking public money after all). In a wiki environment, for example, not only the invited specialists and stakeholders could comment on the proposal but other experts might contribute and those merely interested could witness that the process was properly conducted.
Those at the heart of the process could edit the proposal in one place without losing track of versions (the standard benefits of collaborative environments) and add live links to relevant documents and references (the standard benefits of online workflows). Once it was approved the funding process could take place in the open.
Next as research begins (perhaps with geophysics or fieldworking) the results of this can be uploaded swiftly for appraisal by the funders and external reviewers, who will easily be able to give feedback.
The perpetual beta concept really comes into its own during and after the excavation itself. Specialists can be kept informed on discoveries and can feed their reports straight back into the same framework as the core team are using. This can be used both for communication amongst the team and presentation to stakeholders and a wider audience.
Essentially, perpetual beta makes boundaries permeable: the producers, stakeholders and audience all work within one framework and excavation, post-excavation and publication all become a continuum: No more waiting for that one last artefact report before going public with the results of the rest of the dig!

Checkpoints can still be desirable however, and these are easy to build in. It is easy to separate content that has been authored by the core team from outside suggestions (using discussion features for example) or the team and stakeholders can agree to freeze the wiki at a 1.0 stage that would equate to a monograph.
This could then be built on by new researchers that might do primary or secondary reanalysis.

This simplistic example

Failing for free

What obstacles are there?

Having stable, contained pieces of research output (eg, journal articles) has many strengths, such as well-established quality-control mechanisms and author attribution systems. But the static, periodical output of researchers work does not smoothly reflect the research process.
Digital tools enable new forms of quality-control and author identification: more radically, a conceptual shift to perpetual beta project output might be particularly beneficial to archaeology.

People just don’t have time

Loudest voices will overwhelm expertise

Data formats

Why is this a theoretical shift?

The classic model is for solo workers or small teams to work on projects in relative private and release material in sequence as some combination of grey literature reports, journal articles or (for major projects) books. In academic archaeology this model reflects fundamental ideas about meritocratic individual production best exemplified by the ways students are assessed. In developer-led archaeology commercial concerns and issues of copyright are more relevant.

What else is happening in e-science?



PUNS is 10 years old!