7 Feb outputs: key points from the participants

Taken from http://univ3rsal.blogspot.com/2009/02/objects-devoured-by-jungle.html

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…

One thought on “7 Feb outputs: key points from the participants

  1. Pingback: Workshop for digital curators at Software Preservation

Comments are closed.