 Well thank you and welcome everybody. I'd like to again acknowledge and celebrate the first Australians whose traditional lands we live and work and power respects to elders past, present and emerging. I just like to say welcome, welcome, welcome to making research software fair, which is a brown bag brunch for both the ARDC and CSIRO. So you're in for a tasty brunch time treat today. So CSIRO's and Stevenson team lead for CSIRO's research data support team. And also Keith Russell, our Acting Director of Outreach at ARDC will be introducing our brown bag brunches. So it's an alliterative title that's hard to say if you say it too quickly so I'll slow down a bit. And then after that we're going to hear from our amazing guest speaker Paula Martinez, Software Project Coordinator at ARDC on the value of making research software fair. So following Paula's talk, you're encouraged to get involved in interactive mentee chat to discuss the challenges and advantages of making research software fair with your peers in both ARDC and CSIRO. So just a little bit of housekeeping for the chat because we are recording just going to ask you just to keep your mics muted when we've got our speakers speaking. And if you have questions, please keep them for the end. And if we're running short on time and can't address them in the question and answer session, we'll be able to reply post event. And without further ado, I have the great pleasure of introducing and many of you will already know it doesn't require any introducing really, but I'm going to do it anyway. So I'd like to introduce you to Anne Stevenson who will pick up our first CSIRO and ARDC brown bag brunch. So take it away Anne. Thank you, Mary. I'm Anne Stevenson. I have the very great privilege to lead the research data services team in CSIRO, and I'm talking to you from one of my country today on the north shore of the Hunter River in lovely Newcastle. Our goal is to improve data management practice across the organization. I'm currently acting executive manager for the science engagement group, while John Zick is on leave, and I'm introducing this series of brown bag brunches on John's behalf. Some of you will know that the Australian Research Data Commons or the ARDC and yes this is going to be acronym heavy is a development evolving from the Australian National Data Service or ANS. The relationship between CSIRO and ANS goes back to ANS inception in 2008 with CSIRO staff like Ross Wilkinson and Cynthia Love and several others joining ANS in leadership and development roles either directly or on secondment. There are several staff now on contract with ARDC that are managed through John Zick. Did you know, for example, that ANS funding was behind the creation of CSIRO's data access portal? First released in 2011, the DAP now has over 7200 publicly available collections with a further 900 entries available to a more restricted audience. Metadata of those publicly available collections flows automatically to multiple systems including ARDC's Research Data Australia and data.gov.au. So yes, there's a plug there. CSIRO's management of research data principles defines data very broadly. And in the research data services team, we talk about data using that broadest possible definition including software encode and we actually articulate that. However, I was party to a conversation with some research project leaders recently where I heard that when we say data management, those involved in creating and maintaining software encode don't always hear that software management is part of that big picture. So I wanted to say that this valuable brown bag brunch initiative realized largely due to Mary's drive provides additional opportunities for engagement between ARDC and CSIRO to encourage the data and software management conversations to share knowledge, experience and ideas. I welcome and encourage your participation and I'll hand over to ARDC's Keith Russell. Thanks, Anne. That was that was great. And you've stolen stolen some of the stuff I wanted to say. It's great. Yeah, so my role is acting director outreach within the Australian Research Data Commons. As Anne mentioned, it's wonderful to have ARDC staff embedded in CSIRO and based on a number of locations CSIRO locations around the country. And what we just noticed is that it's really helpful to have staff close to CSIRO and the cutting edge work that's happening there. So we thought it was a good opportunity to get actually get ARDC and CSIRO staff together and just do a bit of an exchange on what's happening in the landscape and what's happening in the ARDC project and what we are doing, but also what what's happening in CSIRO and how those two how we can get those experiences closer together and learn from each other. As Anne mentioned, ARDC is an increased facility came came out of Anne's but also came out of Nectar and RDS. And especially Nectar did a lot of groundbreaking work around research software and research platforms. And that work has also been carried forwards in ARDC. And now Tom Honeyman and Paula are leading this working on the software program and really thinking about research software as a first class first class output of research to and recognizing that. So for us, it's a really interesting voyage and we're in a really exciting time. The fair principles I'm guessing everybody already knows I won't spend a lot of time on those. I think it's been really interesting to see how the fair data principles that were back back from 2015 have now been adopted and changed and were adopted for other research outputs, including research software. So I hope this this brown bag is going to be helpful to have a bit of a discussion about well, what is fair in the context of research software actually look like and how can you make research software more reusable. So that that's probably my my bit. Thank you all great to have you here and looking forward to having this as a brown bag and seeing if there's appetite for more of these on other topics down the track. So I'd like to hand over to Paula, because I think Paula is going to be doing the presentation. Thank you kids for the nice introduction you send me a lot of words as well. I hope everyone can see my screen. Mary, can you give me a hand up. Yeah, awesome. Thank you. Okay. We are here today to talk about the value of making research software findable accessible interoperable and reusable. My name is Paula Martinez. I work for the software program. I am the software project coordinator. You have my email available if you have questions and I am happy to keep on going with this conversation. So I'd like to acknowledge the country, the land of the Jaguar and tribal people in which I live and work around the Brisbane River. I pay my respects to the elders past and present and emerging leaders that have a connection with the land. I also like to acknowledge the organizers for inviting me to present about work that I've been doing since 2018 before joining ARDC. So, yes, kids said that most of you already know about the five principles with a little bit of background, the five principles for research data management were published in 2016 in scientific data by working so little. This acronym stands for making digital assets findable accessible interoperable and reusable. For ARDC, we support five principles and we ask all our partners and collaborators to have data and code to be as open as possible. We support the five principles with a lot of resources that I welcome you to have a look. If you haven't found this resources before you can go to the ARDC website and the resources for data. So I am going to reinforce the value and I don't want to specifically talk about one digital output or asset. So I'm going to talk in general about what's the value of the inputs and for outputs. Research inputs and outputs drive research impact data translation and innovation. And these are all great because research and society benefits from it. So now talking in more detail about software and why don't we just take software as a type of data, because that's how initially the five principles were promoted. From a position that software is not a type of data, we have to identify very unique characteristics. For example, software has a specific nature. Software is the result of a creative work rather than a collection of information in a data set. For example, software can be expressed in different forms. One of those is source code. It can be human and machine readable, but it can also be an executable. So this difference is need to be taken into account while data might have different formats, but it's just in one form. Another important feature of software is that it continues to evolve over time and it changes functionality and it can become something different from what it's starting point. And for it to be functional, it needs to be continuously maintained. So there we see the complex dependencies in software. There's almost no software that stands alone. All of them will need different libraries and concepts and data sets to run in a smooth way. I will also put some resources for you. So listing first the ARDC resource hub. You can go to working with research software. You'll find a lot of guidance there. And also just starting the conversation, because I'm going to talk about Fair4RS. This is a group. It's a community on Sonodo where we have made publicly available a lot of our outputs. So you're free to search that. So I'm going to go through a timeline that is being particularly selected by me, but there is some highlights and milestones that I wanted to share with you. I would like to start with 2016, the software citation principles. This publication has given the emphasis that research software is scholarly output and it's critical as part of modern research and it needs to be cited. There are encourage approaches for software publishing and it also has collected a lot of information from existing community practices. It has an analysis and a reflection. Another milestone is the 2018 that you might be aware of. So these are short guides called the top 10 fair data and software things. There is an international collaboration between the AGU, the library carpentry and different entities that are supporting fair. And the idea was that everyone involved agrees that the applicability of the fair principles, it's really dependent on community standards, community formats and community ontologies. They are integrated together in their own communities and provided examples for them. And that's when we started writing kind of a draft of what will be fair for research software. That was really a starting point. I will call it kind of like a preprint of what came to be in 2019. The paper called Towers First Principles for Research Software. I was involved in the writing of this paper and we had very clear intentions from the very beginning to have a discussion based on the fair principles for research data management and translate them to software and then have that as a base for further discussions. We were completely aware that a group of people cannot define a set of principles that it's going to be globally applied. I'm happy to let you know that by 2020, this paper was the most viewed article in data science. So it really called the attention of a lot of people in 2020 is when we also got together and form this international collaborative group between three international organizations. The fair for research software group was formed by the Research Data Alliance, 411 and the Research Software Alliance. During three years we led conversations, more than 60 community events, and we looked at defining research software, examining what are other efforts that have been applying the fair data principles to other digital assets. And we also had a recollection of literature review of before 2019, the Towers Fair Principles for Research Software and after that paper. What resulted it is in the completion of this working group output and it's the definition of the fair principles. We call this version one. It's been reviewed by more than 500 people. Some of you are in this talk, so I'm really happy that you see this moving forward. With this, I want to exemplify that there's been a lot of different types of inputs into the fair for us principles. Now, I'll just move on. Since 2020, the Fair Principles for Research Software, I stepped forward on the path to recognizing software outputs in academia and improving the curation of workflows that produces better research. This is a quote from Dan Katz. And now, instead of going through each of the principles which you can access via the DOI on the screen and also it's been a background reading listed in the event registration form. There are 17 principles. I just want to summarize some of the considerations in defining the fair for research software principles and highlight what it's new and relevant to software. So, I'll list four points. The first one is the intent and the methods of the fair guiding principles. We're taking as a starting point. So that's our base. The fair were presented to the community to ensure transparency, reproducibility and reusability, which support research impact quality, translation and innovation. So that ethos we wanted to maintain with the fair for us principles. What we want to do is that the fair principles are aspirational and fair is not binary. It's not that you are fair or not fair that your output is or not fair. And we want to encourage that any fair metrics should show progress towards increasing fairness. Then, and we accept evolving outputs and we accept that at some point they might be fair and at some other point they might need some readjustments as well. The second point is that software encompasses many forms and that's from the definition of why we just don't take software as data. And out of those many forms we have agreed in the group that software source code is the most useful form. And that is to apply fair for research software principles. So if you are a developer, think about this form and that which one you are presenting to to make fair or to go through the fairness transition. And number four is that best practices coming from software engineering practices for developing software are very relevant and have informed the fair for us principles, but they are not included. So they are better addressed separately. Okay. And this is just the part where I can highlight some parts of the document. So the, the DOI that I just mentioned before and it's listed at the bottom of this slide, starting on page, page five, you can see all the 17 principles. You'll see that if you're very aware of the first principles for data, you'll see, there's not that many differences because of the ethos, but some that I want to highlight are for findable for example, one, it's the complexity and granularity. So those things are different in software and they need to be validated by having their own identifiers and also versions because, like I said before software continues to evolve. Over time. In accessibility, if we talk from a software perspective, ensuring accessibility means that there are no barriers for the use of the software and this definition is there incorporated into the reusability principles. Here we have taken the accessibility definition as in the data principles that it means to be able to retrieve the software. And what we have done here is just exemplify that we have, we recommend the use of standardized communication protocols that enable software to be retrievable, not only by humans, but also by machines. In interoperability, interoperability of data is mostly around the formats and the standards that enable this connection between different systems. In software, it includes that, but also we want to make sure that the way this information is exchanged is standardized and how it happens in software is via applications. So there are things called APIs, application programming interfaces that allows these channels of communications to make software interoperable. In the reusable, there were many more differences with the data principles because of the overall reusability concept. Reusable in software can be both. One, it's usable so it can be executable. If you are a researcher, you want to go into a service that produces an output, you are using software research software. If you want this software to be reusable, it also needs to be understood. It needs to be available for modification for constructing upon it and also incorporating other software. So for that we need source code. There's also a highlight in giving appropriate licensing for software. And these are not the same as the data recommended licenses. And the R2 is that it includes references to other software, which is a slight difference with the principle and interoperability that says includes references to all the components. In all the components you can add data sets, you can add services and all the things that are not just software, but in the software one we want to see what dependencies this specific version of the software has. Just to finalize, when you go through the details, if you haven't yet and you read this document, there is an appendix. It's a appendix B, it's a comparison of how the third principles were taken from the original to the next iteration to what's the three different iterations based on commentary from the community and feedback that we received. So to finalize my presentation, where to from here. I want to encourage you all of you to be advocates of the adoption of research software because we need all of you the third principles are relevant to the larger ecosystem and to various stakeholders. And secondly, the, the responsibility relies on the software owners, but they need the support from all of us so they will need incentives to make this rewarding policy to make it require infrastructure such as repositories and registries that have been mentioned during this talk by and Stevenson and also training and tools to make it easier. And I just want to acknowledge this is a diagram produced by Neil Chiu Horn based on Brian, also a diagram for change. And just because this is one of my last slides, there's also an article around adoption, where, where we have guiding contact with international organizations that are willing to support the third principles for research software and some examples of how they plan to do it. And that paper is listed there as well as Michelle Parker at all. And that's 22. Last two slides, following the third principles for research software. I like to let you know that it's not a simple to do process is not check, check, check, I'm gone. Instead, this principle should be used as a guide. This is what we can do. And they need to be faced with our day to day realities, the challenges of our projects and the support that we have from our communities. Three values that I want to finalize with is that supporting fair for research software is, is going beyond fair. It increases interdisciplinary expertise. It also can incentivize evaluation, maintenance, scalability and agility of developing software for better research, and just encouraging you, if you are one of the developers of research software, that this initial challenges, if you remove them and you're making more accessible, more findable, more interoperable and more reusable, you are boosting the uptake of your software. That's all from me. Thank you so much. That's, that's fantastic. Thanks, Paula. That was absolutely fabulous talk. I really enjoyed it. I'm sure everyone here enjoyed it as well, which is, which is brilliant. Thank you so much. And it's so great to just see the importance of like metadata and source code and community like those, those are three things that appeal to me very much all together. So, yeah, so that's, that's fantastic.