Raising awareness of preservation issues within software development

7 Feb outputs: key points from the participants

I asked all attendees what they top learning point was, and the facilitators what their top lessons/observations/factoids were. The results are in, and make for a good record of the learning and consensus at the event:

Untended software is like an empty house in the jungle: it soon falls apart

Preserving software is hard even when you know what you’re doing

Software preservation is truly complex: there are so many things to take in to account in addition to just the technical aspects

Because there are so many things to consider, there are inevitably multiple people and perspectives involved, which makes collaboration essential

We must beware of preserving it for the sake of it – remind ourselves of why we need to do it (or not do it) so as to do it right

Preservation of software and preservation of data are two sides of the same coin

Rather than just formulating more theories, greater efforts are needed in terms of case studies and building test software preservation archives, tools, etc

Developing significant properties of software is valuable

Preserving software as part of the representation information of data objects is more justifiable in practice than preserving it as a digital object in its own right

Keep the code (and documentation): its where the semantics lie

There should be a practical example of how to apply the OAIS model to software preservation. You could think of it as a “software preservation profile” of the OAIS model

You can merge preservation approaches in order to work towards an ideal approach you may not have enough lead-in time for initially (eg emulation/migration initially, and in parallel working towards cultivation of community-based support)

Funding bodies should be involved in supporting preservation, eg in mandating this aspect in funding proposals

Modular design – where we can separate display from processing, for instance – is good engineering now, and good for future reuse, as not all components necessarily warrant preservation.

Good software engineering leads to good software preservation

People whose primary purpose is to develop software are more likely to follow good software engineering practices than people who develop as a means to an end. For example, researchers are motivated to do good research rather than produce good software; this may explain why a lot of research code is seen as poor quality.

The best way to curate and preserve software is to make sure that it has a good user community ensuring that it is maintained and kept “fit for purpose”; users keep software alive as much as companies do, their needs will determine what significant properties must be saved and building a community with a stake in what happens can help you not have to do everything yourself.

Preservation in a web service / cloud / distributed architecture world is hard! There is research to be done here…