 Ymlaen iawn ymlaen, rwy'n rhoi'n bod yn ysgol o'r amser o'r hyn sydd ymlaen yma'r cyflodau, ond rydw i'ch yn ddweud y mysgol o'r llyfr o'r gyflodau rhywbeth sydd, a'r hyn yn ddau'r rhaid, ond rydw i'n ddweud yma'r cyflodau rhoi, ond mae'r cyflodau yn ffwrdd yn ysgol o'r llyfr yn llyfr o'r llyfr yma'r cyflodau, a'r hyn yn ddweud o'r llyfr yma'r cyflodau rywbeth sydd ymlaen, y ffordd y ddechrau, byddwch yn gweithio'r link ar y dyfodol ymlaen, y dyfodol y Llyfrgell Llyfrgell, yn ymlaen. First of all though, why should we care about research software? This is a bit stating the obvious, I think, talking to this audience, but probably still useful to remind ourselves. The key reason why we need to care about research software is because our users do. What you will see here, probably not be able to read in much detail, is a survey that was done by the Software Sustainability Institute almost five years ago, where they surveyed researchers from 15 Russell Group universities about their use of software in research. There are a few interesting numbers in there. I don't want to go into detail, but you can still find this through the SSI website. A key point is that five years ago, 92% of researchers said they were using research software, which even at the time made me wonder what the other 8% are doing. But I guess it partly comes down to do you think of what you're using as research software or not when I used Microsoft Access for my PhD? I probably didn't think about it as a research software, which is just a database management tool that I used to classify and filter some of the early modern resources that I was cataloging and working with. But even five years ago, roughly 70% said they couldn't do their research without research software. A key thing, therefore, for us is, as more and more researchers are working with software, we need to be able to interface with them in many ways. We need to be able to provide our information in such a way that their software can pick it up. But we also need to be able to work with the outputs that they are creating and arguably the best way of doing this is, as much as we can, advising them on how they are using the software, because if we are being served a bunch of giga, peta or terabytes, or even just a few megabytes of data that has been put together with very little or no thought to digital preservation, then the cost and challenges are much bigger. So arguably we need to understand what they are doing if you want to be able to serve them. But I would also argue if we engage actively, particularly in the field where it's possible to actually get funding for joint activities, we can build up skills and expertise. If we can't hire really expensive data scientists, we can maybe help train RDM and research support staff to get a few steps closer to this and have some skills in our libraries. One of the reasons why we should do this really is because we are dependent on software ourselves. We have a lot of data. We use an increasingly large amount of software. As I explained a bit more detail a couple of days ago, we are increasingly dependent on software that we don't fully understand. That's rather in the cloud. We are looking at machine learning and artificial intelligence. If we don't have the skills to assess these properly, we'll arguably, as Tim Hitchcock reminded us, maybe not serve our users in the most transparent way because we have no clue what our software does with our own data. Arguably, working in the RDM space will help us do this. We are looking at a few ways of how we can improve skills at the British Library. We've just very recently been lucky to have a collaborative doctoral partnership approved with Kings College and Imperial College London about safe and trusted artificial intelligence. I think there are other training activities in the area that are somewhere between software and research data where libraries could and should engage more. We're also making this increasingly a part of our service strategy. Last year we worked on a service strategy for how we plan to deliver our role as a national research library over the next few years. The key element of this, I think in the way how many libraries are transitioning, is moving from a model that's mostly collections-based to a model that's increasingly service-based, where collections are part, but not necessarily the only answer. Arguably, if you move in that direction, this doesn't work without software because we need to be able to understand, as I just said, our own software and think about the infrastructure and think about how we can open up the infrastructure so interfaces with software from researchers. We also need to be able to curate research software because there's otherwise no way how we can make use of the data that we have. I'll hand over to Jasw who will say a bit more detail about how we can approach this as libraries. Thank you, Torsten, for that wonderful introduction. Right, so I'm going to unpick a little bit of what Torsten's just given you in a little bit more detail. First, a definition. What do we mean by research software? Kind of what it says on the tin. Any software used to conduct research we're talking about here, there is often also a more tight focus on software developed for or by researchers. So just bear those definitions in mind as we go through. So why is this important? People are asking increasingly difficult questions of the scholarly record. How can I trust this analysis? Works, how can I trust that these researchers actually have done the thing that they said they could do? 100, 200 years ago, methods of research were less developed. It was actually possible to describe everything that you did quite precisely in a communication to your peers. That's as research now relies much more heavily on algorithms and quite detailed statistical analysis. We're not able to present that in prose so well. So the idea of bringing software into the scholarly record becomes quite important. One of the reasons for this is that reproducibility, there's a word that gets bandied around quite a lot. One of the examples that I like to use to illustrate this is has anyone heard of the Reinhart and Rogoff controversy? If you've heard me talk you might already have heard of it because I'm too dead to bang on about it a bit. Reinhart and Rogoff were economists. They have done various bits of research. In particular they published a paper a while back that demonstrated that there was a negative correlation between national debt and economic success in GDP. This result was quite popular amongst governments at the time and was used as a major piece of academic evidence as the basis for austerity in a lot of countries. Some years later a student was given the task of reproducing this analysis. Went back, read through the paper in detail, took the data, tried to reproduce it. Wasn't really guessing the same results as were presented in the paper. Did what any sensible person would do and contacted the lead author and said I'm a student, I think I'm doing this wrong because I'm trying to reproduce your results and I'm just not getting there. Can you help me understand what it is that I'm doing wrong? They got sent to the Excel spreadsheet that was originally used. It turned out that actually what had happened was that someone when performing that analysis had not selected all the way to the bottom of a column in the Excel spreadsheet when they were performing a sum. If you do this, the effect that they found in the paper completely disappears. Take from that what you will, but importantly it's expressing these methods in the form of software that is open source and can be shared is a much better way than the kind of pointy clicky way that we're used to in Excel of actually expressing what it is that you've done and ensuring that what you've done, what you say you've done is what you've actually done. There are also some other interesting things around this. Things like we're trying to keep data around as libraries for as long as possible. How do we make sure that we can still access that in 10, 15, 20 years? There are already documents that can't be read with any current software. But software is a cultural artefact as well. There are interesting questions around how software has helped shape culture and society and research and all of this. Software is an important object. First up, software is an important object as part of the scholarly record. We're increasingly thinking of data and methods and sources and samples and software all as important information that orbits around the publication which is still the first class output of research. Software is also necessary for access. Preservation is pointless without access. If you're keeping stuff that no one can look at, you're really wasting your time and your money. Digital preservation requires that you have software to mediate between those bits on the disk and the person who wants to interpret that information. So if the software that is required to access that information becomes obsolete and you don't have access to a copy of it, you've lost access to the content as well. Thirdly, software is interesting as an object in itself as cultural heritage. Software has had a massive impact on the entire development of the 21st century and the recent 20th century. It's worth preserving even if those other things weren't there, it's worth preserving and looking after in its own right. This gives us some opportunities in libraries to whiz through quite quickly. Licensing. We have expertise in licensing and intellectual property and copyright and things like that. A lot of researchers know about those things in general and know that they should understand them, but don't always have the detailed knowledge to understand what they should do. Understand how they can use this piece of software, how they ought to release that piece of software and a lot of the knowledge that we have around the content that we're more familiar with does translate into helping researchers with software licensing as well. Obsolescence, I've touched on a little bit already. The research that we're doing is very digital. It's built upon this entire very deep stack of different bits of technology, all of which to a certain extent needs to be working correctly in order for that research to be reproducible. It's not just about the software. It's about the bits of code that the software uses. It's about the programming languages that you use. It's about the operating system. It's about the hardware. There are various approaches to this that, again, libraries are quite well placed to take advantage of. On the one end of the spectrum, you can actually keep that old hardware around. Not everyone can do this, not everyone has storage space to do this, but it's certainly something worth considering. I do love the classic look of a BBC Micro. Then one layer down, there is more software that allows you to emulate at various different levels the behaviour of obsolete hardware in current hardware. You can see a nice image here of one computer running various different old operating systems. Then another layer below that. If you've got access to the source code, the original source code of the software in question, often you can recompile that to run on modern hardware, or if it doesn't work, just a starting point for updating it. Relationships. We are all about metadata in libraries. I don't know about you, I quite get excited about metadata. A lot of the importance of metadata here is around representing the relationships between different objects, people, funders, publications. Software, again, as a key part of the scholarly record, has to be linked into that. My colleague Francis Madden is working from the Bail's perspective on the Freya project, which is an EU-wide project, which is looking at how identifiers for all of these different kinds of objects tie in together and how we can encourage them to be used better, and software is a part of that. In libraries, we spend quite a lot of our time working with particularly students, actually, but also staff on things like information literacy. And it's not a huge step to go from there to literacies around understanding software use. So it's similar skills around understanding provenance, understanding what makes good and bad quality software, not as different as you might think from the skills around evaluating the provenance and the quality of a scholarly source. We're increasingly, as colleagues over there mentioned, helping researchers with data management plans. Software management plans are an interesting development there. Generally, we have a lot of skilled teachers in libraries, and those teaching skills are really valuable. I don't know if you've ever been taught an IT or a technical course by someone who is a very strong technical expert, but not really had any instruction in how to teach people. It can be quite a painful experience. We can bring that in libraries. We can bring that skill set to our more technical colleagues. I would be neglecting my duties here if I didn't mention library carpentry as well here, which is a really interesting student's effort to bring not just the data and software skills to library staff, but also thinking about the pedagogy of how you deliver that. Which brings me on to developing staff skills. There are lots of ways this can be approached, and I think it's already been apparent just from the talks we've had this morning that this is very much an unsolved problem. But little things like supporting your staff to attend conferences like this is always very helpful. Particularly giving them opportunities to attend conferences that might be a little bit further outside the classic library scope. Give them more opportunities to talk to colleagues with more data science, more software development expertise, and go out into those communities and evangelise for the role of libraries as well. University of Pittsburgh have done some really good work on shadowing research that I really like. That's another thing that can work really well and can work very well within your institution to build relationships between departments and libraries as well as developing the staff skills. Library carpentry, again, I mentioned it. Merions is another similar initiative. At the British Library colleagues in the digital research team are doing a brilliant job around peer learning. They have regular hack and yak sessions where they'll bring someone in or a colleague will present on a particular subject and everyone can get their laptops out and get hands on. And that fits nicely into their wider programme of skills training for our own staff. And finally we need allies in this. We can't do this alone. And that's an opportunity as well. Some of you will be part of a converged service. This kind of thing will help you to integrate much more the kind of classical library and the more technical IT side of those services. If you have a separate library and IT service it will help you build bridges between the two services. One of the things that I find really useful is simply having some of the language that IT colleagues speak at the tip of my tongue in order to kind of talk to them in their terms and explain my terms to them. Research software engineering groups in my previous job at the University of Sheffield we built up a really productive relationship with a research software engineering group. Research software engineers if you've not come across them are people often in research focused roles but who don't do who are more focused on developing the software. The Software Sustainability Institute has done some really good work in the research software engineering community in the UK around defining what those career pathways are defining how you can give people credit for contributing to the software that was used in research rather than simply having to write the paper or do the lab experiments or go and do the field work and that kind of thing. Archivists, digital preservation experts these are all people who are very happy to engage with us on this. There are plenty of external organisations in this field in the UK we have, as I mentioned the Software Sustainability Institute they recently announced that they've got a fresh round of funding from EPSRC to support their activities for the next three years. The Digital Preservation Coalition the Software Preservation Network the British Library of course we're looking into this, we're looking at how we can support the community. So some of the ways that we're supporting this right now we are the hub in the UK for data science services, if you do not have the ability to create DOIs please drop us a line, we can sort you out with that. We're also involved in a number of international collaborations such as the EU Freya project as I mentioned around understanding how this problem affects us all globally and finding solutions that work for everyone. As an RLUK community we've got plenty of opportunities to share ideas and practices and explore models for software preservation at a national level and figure out how this works to take someone else's words in vain from yesterday a lot of this stuff we don't need to do separately for all of us we only need to do it once and do it right and I think we've got an opportunity here with the community of people in this room to do that.