Our first group discussion was around who should be responsible for software preservation. Should it be the developer of the software, or should be there be a dedicated software curator? Or should it be someone else, or a team effort?!
Some of the points relayed back from these group discussions were:
- You can’t do software preservation alone
- People have different responsibilities for software preservation and this can depend on the institution.
- Ultimately everyone has some responsibility for software preservation. The main problem is the lack of understanding, ie some people may know the technical information but not the reasons behind why the preservation’s important and vice versa.
- Both IT technicians and researchers need to know the “whats and whys” for preservation to work.
- Engaging current users is essential. They can tell you what’s important now and in the future. Users need to put a preservation strategy in place before things fall apart. Users must question the sustainability of their preservation techniques: will the technology and file formats become obsolete too quickly?
- What data should be preserved? Raw or processed? Or both? Are there time and cost constraints on this?
- What are the different reasons behind preserving your data? So you can interact with data? For prior art in patents – legal liability? It is recommended to have a strong business cases to justify preservation process.
- It is recommended that an advocacy strategy is developed for software preservation.
- It is recommended that certification approaches be developed for software (like with data) so that users can quickly understand whether a preservation technique is trustworthy.