 Welcome. My name is Mateusz Kuzak. I will be talking about how can we get to the research software sustainability. I think there's still far away in front of us, but I think we're making a lot of progress. There's a lot of activities happening now. Already, the fact that you all know about the reproducibility crisis is the progress. Like we first have to know what we're addressing and then we can try to solve this. Briefly who I am, my name is Mateusz Kuzak. I'm a Community Manager at the Netherlands eScience Center. I'm also co-leading the group on software development practices in Elixir. You can contact or follow me on Twitter or GitHub. Although on GitHub, I only write markdown files right now, not code anymore. What is Elixir? Elixir is a large consortium of European countries working on life science and it's about life science infrastructure and software is part of this infrastructure. That's why the open software is so many important in this project because we don't want to re-implement things, we want to reuse things, we want to share things, and we want to collaborate on things. Otherwise, this whole consortium doesn't make any sense. So we have 23 countries in there, distributed around Europe and even outside Europe actually. The work is divided into different platforms and in this platform, all the work in this platform, like data tools compute, they also all have to do with software. So how do we make sure that the software is developed in a way that we can reuse it and that we can collaborate on it? So we started this working group and we said, okay, let's start with opening up. So make sure that all the software that is developed from the day one is not somewhere on the PI or the PhD students laptop, it's actually there open accessible with the open source license. So we started this group and then so let's write down like the guidelines, like the 10 recommendations or 10 metrics for good quality open research software. So we summarized it with the top 10 metrics. You can access the paper there. I uploaded the slide so we can access it later. But in short, those 10 metrics touch upon the version control, discoverability, continuous integration, testing standards, code review, documentation and more. And then, but that's a lot, especially like if we're talking about researchers who just started programming, often this is that tool that they're using, but it's not like they've never been trained in doing it. So we said, okay, let's start like a little bit slower, like start with the basics. Because in fact, like the first thing that we want from them is the most scary part, like put their code out there. And everyone's like, okay, someone like will look at my code and they will think it's crappy. They will find my bugs. They will start writing to me on GitHub. Like what do I do? So we say, okay, first start, put it on GitHub and start with empty readme file. Like no one will tell anything about your empty readme file because there's nothing to criticize. And then you can slowly add things to it and build up. But then there's a lot of things that are around open source practices, research software development practices or open source software development practices that we as researchers are not trained in. So we developed this like a four simple recommendations, four things that you should know about. You should learn and start practicing if you're developing open source software. So we call this four simple recommendations to encourage best practices in research software. And they are open source your code from day one. That's what I already said. It's very important that it's from day one because the longer you wait, the harder it is to do. If you have 10 year project and you want to put it on GitHub, it's like the scariest thing that can ever happen. And then make your software discoverable. If people can't find your software, it's still not useful to anyone except for you. So there are software registries. I will mention it about it in a second. Use the software registries, register it. Usually you have domain specific software registries where people can find. If it's an astronomy software, they know where to go. Add the license. If there's no license, people still can't use your software. Or like maybe they can't use even there's a license. But if you choose the open source license, they should be able to. You have to do it. Define the responsibilities, the governance model so that people know what to expect from your project. So then, so we develop those recommendations and then we thought like, yeah, still no one will do it because people don't know how to do it. So we teamed up with the carpentries. The carpentries is the foundation that teaches researchers basic programming and data skills. And we developed those lessons. So we now can teach one day workshop where we teach researchers about how to implement the four simple things that they can learn and start developing in the open. I mentioned already the registries. In the East Science Center where I work, we developed like a list of, we called it also list of research software registries. And you can find it on GitHub if you are wondering like, okay, so I work in climate modeling. Yeah, in climate modeling, where do I find registry so that I can put my software then so that other climate researchers can find me. You can find the probably there. If it's not there, you can add your make a pull request. The other thing is there's a lot of ways to learn about how to develop research software. I think, so in the science center, we used to develop our own guide. Actually now we're joining the Turing way. So this is a handbook developed by Turing Institute. This is amazing resource if you want to learn about things how to do things reproducibly in science. And the last thing, so I don't know how many of you are familiar with third data. Okay, so first stage for fundable, accessible, interoperable and reusable. It's a very, yeah, very popular buzzword in life sciences and beyond life sciences now around data. So we thought, okay, how can we use this to also increase the awareness of the making software more accessible, findable and so on. So we developed this website for software you where you can find five simple recommendations to make your software more fair. Like use the version control and put it somewhere in the registry, use the license, register in the registry as I only mentioned, and then use a checklist because there are a lot of already good checklists around good practices in research software. We usually don't use it. People very often are very like, they will focus on the details which checklists to choose. I actually think it doesn't matter which actually is to use as well as long as you choose something that is, looks good and stick to it, okay. And that's it, thank you. Very quick question. I'd like the next speaker to show up, please. We're not at this time. The biggest issue in data I think is licensing. Which license to choose? For software. How do I advise to choose the license for software? Okay, so the question is, yeah. So the question is, what kind of solution do we advise for choosing the license for data? That's not my expertise. And I think, yes, I agree it's more complex than software, probably. Yeah, all right. Okay, thank you. Thank you. Thank you.