I’m going to let you into a secret. Well, it’s not a secret really but whilst I have been gamely (trying to) take on the challenges of tackling various technical aspects of digital preservation, my approach to software preservation has been decidedly that of an ostrich. I have been firmly sticking my head in the sand over this! It’s partly because I really don’t feel like I know enough about software writing in the first place and partly because someone else is doing something about it aren’t they…?
However databases, websites, video and so on are complex digital assets which I am only too happy* to tackle but somehow software seems a step further
However a couple of things made me rethink my position.
The first was a recent talk from Neil Chue-Hong of the Software Sustainability Institute at one of our Lancaster Data Conversations. He discouraged me and encouraged me in equal measure. Discouraged me because when addressing a room full of coder writers he asked them to consider how they might access their code in three months time. Three months! What about three years or even three decades? If people are not even considering a lifetime beyond three months I’m starting to wonder if it’s worth getting involved at all.
However on a more positive note Neil was keen to promote good practice in software writing and management and recognised the barriers to maintaining and sharing code. As with most preservation work the key is getting the creators to adopt good practice early on in the process – the upstream approach which I’ve alluded to before and has been around a very long time and indeed is what makes Digital Preservation a human project. However in order to support good practice and to build the right processes for managing software a better understanding is what is required.
The second thing was the realisation that I was already responsible for code in our data repository – for example this dataset here which supports a recent Lancaster PhD thesis.
We don’t have a huge uptake from our PhD students for depositing data in the repository and we are especially keen to encourage this because we want our researchers to get into good habits early. Neil explained in his session that there were particular barriers to certain researchers sharing data – early career researchers amongst them – as there is a fear of sharing “bad” code. But as he pointed out – everyone writes bad code and part of the advocacy around sharing is getting over the fear of “being found out”. From my perspective – if people are willing (or even brave enough) to share their code I want to make sure that as someone charged with digital preservation I can try and create the optimal environment for software preservation into the long term.
At the moment I think we have some way to go on this, but thankfully help is at hand with the Jisc/SSI workshop Software Deposit and Preservation Policy and Planning Workshop. The workshop aim is to “first workshop will present the results of work done by the SSI to examine the current workflows used to preserve software as a research object as part of research data management procedures.”
Sounds good to me.
What do I hope to get out of this?
- I’m really interested in getting the right metadata to support the preservation of software
- I’m keen to hear what other people are doing!
- I want to know where I can best direct my efforts and the areas I need to concentrate on first to get up to speed with providing excellent support
I’ll be reporting back soon on what my next steps are…
*or is that grimly determined?