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
- Migrating software towards standards (data, programming language, environments) makes preservation easier
- Deprecation is a strategy and should be planned for
- 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…
Pingback: Workshop for digital curators at Software Preservation