Sustainability and preservation framework

By Neil Chue Hong, Steve Crouch, Simon Hettrick, Tim Parkinson and Matt Shreeve.

An investigation of software preservation has been carried out by Curtis & Cartwright Consulting Limited, in partnership with the Software Sustainability Institute, on behalf of the JISC. The aim of the study was to raise awareness and build capacity throughout the Further and Higher Education sector to engage with preservation issues as part of the process of software development.

Based on this work, a benefits framework document was written to assist developer groups and their sponsoring bodies to understand and gauge the benefits or drawbacks of allocating effort to:

1. Ensuring that preservation measures are built into software development processes
2. Actively preserving legacy software

Part of this study involved examining the purpose and benefits of employing preservation measures in relation to software, both at the development stage and retrospectively to legacy software. The study built on the JISC-funded Significant Properties of Software study that produced an excellent introduction and framework to software preservation.

Purposes, benefits and scenarios

A key challenge in digital preservation is being able to articulate, and ideally prove, the need for preservation. A clear framework of purposes and benefits facilitates making the case for preservation. The table below shows a range of scenarios for each purpose to give some illustrative examples of where the purpose and accompanying benefits might be relevant.

We recommend that these purposes and benefits be combined with preservation plans regarding data and hardware: digital preservation should be considered in an integrated manner. For example, media obsolescence and recovery is often as much a part of a software preservation project as a data preservation project.

Note that if at all possible, especially where the software is an enabler, it’s advisable to turn a software-preservation problem into a data-preservation problem. These problems are invariably easier to handle.

Do we need to preserve our software

We do not believe that there is a simple and universally applicable formula for determining if your software needs to be preserved, and how to go about preserving it. Instead, we present thought provoking questions and a range of factors which should be taken into account.

Questions you need to answer

• Is the software covered by a preservation policy / strategy?
• Is there a clear purpose in preserving the software?
• Is there a clear time period for preservation?
• Do the predicted benefit(s) exceed the predicted cost(s)?
• Is there motivation for preserving the software?
• Is the necessary capability available?
• Is the necessary capacity available?

How should your software be preserved?

Seven different options for preservation and sustainability are presented.

• Technical preservation (techno-centric) - Preserve original hardware and software in same state
• Emulation (data-centric) - Emulate original hardware and operating environment, keeping software in same state
• Migration (functionality-centric) - Update software as required to maintain same functionality, porting/transferring before platform obsolescence
• Cultivation (process-centric) - Keep software ‘alive’ by moving to more open development model bringing on board additional contributors and spreading knowledge of process
• Hibernation (knowledge-centric) - Preserve the knowledge of how to resuscitate/recreate the exact functionality of the software at a later date
• Deprecation - Formally retire the software without leaving the option of resuscitation/recreation
• Procrastination - Do nothing

Purposes, benefits and scenarios

The table below shows a range of scenarios for each purpose to give some illustrative examples of where the purpose and accompanying benefits might be relevant.

Questions on how to preserve software

• How much access do you have? (Owner, developer, access to source code, access to hardware, user)
• Do you have the necessary Intellectual Property Rights (IPR)?
• What are you needing to preserve? (A few major pieces of functionality, Most of the functionality, but tolerant of minor deviations, All functionality, but fixing errors when found, Must perform exactly as original)
• What is your likely effort profile? (Something or nothing now, something or nothing in the future)
• What is the maintainability of underlying hardware?
• Is maintaining integrity and/or authenticity an important requirement?
• How long do you want to preserve it for?
• Can you afford it?
• Are you also interested in further development or maintenance?
• What development effort has been invested into the softwareso far?
• Is the software open source? Could it be made open source?
• Are there any barriers to making it open source?
• Is the proposed approach appropriate to every purpose?
• What are the relative advantages and disadvantages of each approach under consideration?

Further information and useful resources

• A pdf copy of this overview of the benefits framework
• The benefits framework document
• The Significant Properties of Software project - a JISC funded study into what properties are needed to allow software to be systematically preserved