JISC Beginner's Guide to Digital Preservation

A while back I mentioned that the Software Preservation Study team were running a free workshop for digital curators and repository managers to understand and discuss the particular challenges of software preservation.

Although I was unable to attend the day two of my colleagues, Alex Ball and Manjula Patel, were there representing UKOLN. Manjula has written a blog post on her thoughts on the day. Alex has kindly allowed me to publish his trip report below:

****

On Monday 7th February I attended a workshop on the preservation and curation of software, put on by Curtis+Cartwright Consulting and the Software Sustainability Institute, the team behind the JISC study ‘Clarifying the Purpose and Benefits of Preserving Software’. It was only a brief event, but it still managed to cover ample ground.

The day started with three mini-keynotes. Kevin Ashley (Edinburgh/DCC) set the scene, illustrating why we should care about software preservation with anecdotes and examples from computing history. Neil Chue Hong (Edinburgh/SSI) reviewed the seven possible approaches to software preservation, and discussed the occasions when one might have to choose one, and what factors influence this decision. Finally, Brian Matthews (STFC) talked about some previous work done on the subject, namely the SigSoft (Significant Properties of Software) and SoftPres (Tools and guidelines for the preservation of software as research outputs) projects.

Following this, we were split into groups of about 5-8 people for two group exercises.

In the first exercise, we each considered who was responsible for software preservation in our organization, who else should be involved, and what practical steps could be taken to improve the status quo. Now, normally when one is asked ‘who is responsible’ in a workshop like this, the correct answer is usually ‘I am’, accompanied by inward groaning on the part of the delegates and waves of smugness coming off the leader who has the thing in question in their job title. There was none of that here, thankfully. There was thoughtful consideration of the parts played by developers, procurers, users, senior managers, funding bodies, IT departments and The Community (i.e. the other users and potential developers). One interesting suggestion was that the DCC should set up a preservation certification scheme, so that procurers and users could know which software they could trust to be preserved (or, at least, preservable).

The second group exercise was to go through a preservation planning exercise for a particular piece of software. The process was, in summary: to establish why the software needed to be preserved, for whose benefit, when and where; to work out the requirements for the preserved software (e.g. is the process important or only the outputs?); to determine the most suitable preservation approaches for the short term and the long term; to enumerate the skills and resources needed, and where the money will come from; and work out what needs to be done to get the ball rolling. Our group deliberated over a fictional piece of software loosely based on the DANS Typological Database System, but one of the other groups considered the collection of console games at the Science Museum and did the exercise for real.

The workshop ended with Neil Grindley going through JISC activity in the area of software, mentioning among other things the Preservation of Complex Objects Symposia, DevCSI, the OpenPlanets Foundation and various rapid innovation projects. Areas of particular interest will be preserving software with a web services/cloud computing component, economic sustainability, and how funders can help ensure the software they fund can be preserved.

The workshop was followed by a surgery session where people could seek expert advice from the project team, but unfortunately I had to dash off to catch my train.

All in all, I found the workshop to be a particularly enjoyable example of the learning-by-doing genre of event. The pacing was good and the main points were repeated enough to be memorable but not enough to be annoying. Looking back I see I’ve learnt more than I thought I had at the time.

Project blog:http://softwarepreservation.jiscinvolve.org/wp

SSI:http://www.software.ac.uk/