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…