 cover today. So welcome to today's event for recommendations to make your research code visible. Your wonderful speaker for today is going to be Paula Martinez, who is our software coordinator at the ARDC. But first let's quickly roll through some of that standard housekeeping stuff that we have while we're on Zoom in an online event. So firstly just acknowledgement of country and we acknowledge and celebrate the first Australians whose traditional lands we are meeting on here and we must pay our respect to their elders past present and emerging. So the ARDC, who are the key hosts of today's event, who are we? So our purpose is to provide Australian researchers with a competitive advantage through data. So what does that mean? We do try to provide various services, activities and initiatives to in bottom line is give you a competitive advantage through data and in your research. And today this event is just one example of that. You can also find out more via our website, which I will pop in the chat after I finish this introduction. So today of course Paula is your key presenter but we do have some co-hosts here which is myself. I'm Sonia. I am part of the Nectar Cloud team as a cloud skill specialist providing user support and training and other user support initiatives. I also have Sarah King from Arnett who will introduce herself and what Arnett does very shortly. But while I'm here just a quick plug for the Nectar Cloud. So this is a service that ARDC provides. It's a purpose built cloud for research. We have computing, storage applications and virtual desktop services for you to use. Great if you need to have some extra storage for your research that you may not have available to you locally on your computer. So I do have a website link there which you can check out for help materials, how to get started and to learn more. Now I'm going to hand over to our other co-host Sarah to introduce herself and give a brief overview of what Arnett is. Hi everyone, I'm Sarah. I'm the training and engagement leader. Arnett is Australia's advanced research network and we're the ones who interconnect Australian research and education institutions with our superfast internet. We connect everyone to each other and across that global research network to help people leverage the network. We offer cloud store as a file sync share and storage service that includes Swan which may be of interest to all of you today. It's a Jupiter notebooks hosting environment so you can code in the cloud. We also help with big data transfers so that you can access data from the world's most powerful telescopes if you like or supercomputing facilities. We also now offer cybersecurity to help the Australian Unis manage any incidents and we also offer training and I'll add a link in a sec and that's focused on demonstrating the services that we provide such as cloud store and Swan and understanding networks and data movements so if you're interested any of that please get in touch. Thank you Sarah and last but not least before we hand over to Paul just a few quick reminders. Standard sort of event structures so we are running this event via a code of conduct. I will also put a link to that in the chat basically we just want to have a safe happy environment everyone at this event. Again more details in that link in the chat. If you have any questions please just ask them in the chat and we will alert Paul to them as we go along and she can answer them and also please keep your mics muted just so we can continue running the presentation without any sort of noisy interruptions and of course last but not least this session is being recorded you may have seen that pop up when you first joined but only the speakers will be in focus so you shouldn't be featured on the recording and of course there will be some polls through the event as well so please do fill them out and Paul will just jump to them as they become relevant. Okay so last but not least the best part of the day we're handing over to Paul and she's our course as I said our software project coordinator and she's going to give you an overview into those four recommendations to make research code visible. I'll hand over to you Paul. Thank you very much thank you all for being here and for answering the poll. I'm going to share the results now to see who is in the room so we have a spread between students, PhD candidates, research assistants, early in middle career researchers, group leaders, librarians and other professional staff. I welcome you all here today for this topic. The ARDC software program initiated in 2021 and it came together in the form of a draft software research software agenda and it has the description of activities that will move to a cultural shift. This agenda has three layers which are C-shaped unsustain research software and the overall goal is to make research software, research software output as a main research digital object in the scholarly communications environment. This activity pertains to the layer C in the core course is sharing and availability. The target audience are the researchers and the primary driver is research integrity. Now I'd like to start the second poll. Okay so this other poll has only two questions and I'd like to see a little bit more in detail who is in the room, whether you write for or do you support researchers. I'll go to the next slide where you answer the poll and this is a quote that I would like to frame this presentation with. Research is now fundamentally connected to software. It permits every aspect of the conduct of research. This quote is from a recent article, the 10 software quotes that have revolutionized the history of science and you can read it with this DOI and the person who quoted that I quoted is Neil Truehorn the director of the Software Sustainability Institute. Thanks for answering the poll. Now I'll share the results. Most of you are writing code currently or soon to start writing code. This is excellent because I have in the recommendations some tips for you in various degrees of advancement, whether you are starting or whether you are already doing this and we will have time for questions at the end. The second quote that I'd like to frame this presentation in is a quote from the OECD, a recommendation that consents access to research data from public funding. It's been amended in 2021 to include not only data but also relevant metadata algorithms, code and software together with information on workflows and the computational environment used to generate published findings. We should be able to make available all of these components when we publish our research. Also to frame this discussion, you might hear me saying research software and I'd like you to understand the definition of research software that we are using for this presentation. Research software refers to source code files, algorithms, scripts, computational workflows and executables that were created in either of these two categories. A, we think a research project as a by-product to do the research. Or B, through intentional development of a software product for general use in research by one or more projects. So now those of you who are writing code might find yourself in one of those categories. This definition has been adapted from Gruppente at all from the FAIR4IS working group. The goals of this webinar are two, to offer you practical suggestions that can contribute to making research software and its source code more discoverable, reusable and transparent. And I'm going to explain why. I also want to discuss the alignment of these recommendations within the FAIR principles for research software. I'm going to cite them one by one along with the recommendations. I also like to note that I'm not going to be covering software development as practices, but I recommend anyone who's writing code to have a look at what are those. And also that these recommendations are to be taken as technology independent as possible. So I am going to cite some examples, but you as the author or the person who support the authors are the ones who are deciding, sorry, which technology to use. Now, because I'm going to mention the FAIR principles from research software, I don't want to assume that all of you already know what they are. So I'm going to summarize them here. The FAIR principles for data have been published in 2016, but then have been repurposed for the digital output research software. The main acronym is the same, stands for Findable Accessible Interoperable and Reusable, but has been modified to be adapted to the case. The FAIR principles for research software, I'm going to summarize them in these four points. For Findable, it refers to all the associated metadata. And the key part is that it's easy to find not only for humans, but also for machines. So any metadata should be readable and be exchangeable by machines. The accessibility principle relates to software and also its metadata to be retrievable by standardized protocols. And one of the recommendations touches upon this accessibility principle. Interoperability is the ability of software to interoperate with other software by exchanging data through APIs described through standards. The reusability principle is divided into two. And the first one is to be usable by providing an executable form of the software to the users. And the second one is to be reusable by providing the source code that can be understood, modified, built upon, or incorporated into all the software. You can read more about the FAIR principles for research software in the Research Data Alliance Output page. Now, going to the recommendations. This is for people who are supporting other researchers and for the researchers themselves. These four recommendations are based not exactly the same as this peer review article from 2017 by Jimenez et al. I should notice there are four authors that represent the Australian country and they have put their views because they have the influence to be able to make compliance about these recommendations. And that's why we intend with people in positions of decision making to represent these recommendations. And for all of those who want to dig more into their recommendations, because this is a short webinar, I also like to point to you the lesson that has been developed in 2018, has been delivered many times already in Europe and now in Australia. It has not only examples, but it has also the context for each of the recommendations and different cases where you might apply different options for the recommendations. The DOI for these four recommendations is listed here and is listed in all of the slides that are mentioning them. Now, let's go through the recommendations one by one. I have a few examples and how they align to the FAIR principles as well. The first recommendation is develop source code in a version control repository from the beginning of the project. And there are many dimensions to discuss about this recommendation. Initially, some people might ask, what is a repository? Well, a software repository, also named repo, is a storage location for your software. And you might decide where this storage location is. Ideally, this location and all your software project is in a version control system. A version control system is a software tool that enables management of your software and it tracks changes over time and it also tracks who the collaborators are. And it's mainly built for teams. And that's when I want to highlight point number three, the building software is not a task for a single individual. If you want your software to succeed, you will involve more people and we'll build it together. The next point of reflection is whether you want this control repository to be private or public. And I want to let that decision to the authors. You might decide to start privately and then make it public when you are ready. In the choices of version control systems, there are those that are self-hosted, which might be in your computer or in your cluster. And there are others more frequently used that are web-based. Being web-based enables platform independence. So that means that your collaborators might be working in a different platform than yours and you'll all be able to share your code independently of this. The next point of consideration is time is key. As I said, you decide when to start doing this, but I will recommend to start as early as possible because the longer it takes for you to bring your source code into a control repository, the more effort and time it will take you. And a motivation for those writing code is to increase transparency through community screening. You will realize that once you share your code and all those are able to see, it will push you to write better code, to write better documentation and to give more instructions to your users and collaborators. There are many things that we can discuss in this recommendation and in a normal lesson program this will take about two hours. I would like just to mention a few of the resources that you can use to implement this recommendation. Develop source code in a version control repository from the beginning of the project. So there are four version control systems that are web-based, that are free to use, are efficient, they have issue trackers, discussions and they have project management. Those are the most used are GitHub, GitLab, Bitbucket and GitT. These are not the only ones and I really encourage you to have a look before you decide. And I put this URL here, alternative to .NET in the category of developer tools version control systems. And here you will see all the features of different software tools and also recommendations from the community. So you are going to decide based on your needs and your community suggestions as well. Now, because this is a beginning webinar, I'll start from zero. If you have never put anything in a version control repository and now you decided that it's time to make it public, the first thing apart from your code lines is your readme. The readme information is everything people who are going to access your code need to understand it. For example, who developed it, who are the collaborators and also the licensing and how to site this software. This recommendation aligns to the fair principles mainly in the reusable principle. Reusable, as I said before and I'm going to repeat it, is both usable, can be executed and reusable, can be understood, modified, built upon and incorporated into all the software. The R1.2 in software is detailed with, is associated with detailed provenance. Using a version control system allows you to have this provenance and you don't have to track it yourself, you will use the system for that. Recommendation number two, adopt the license and comply with the license of third-party dependencies. As an author, you have all the rights to determine what are the terms of use, the terms of change, the terms of contributions and redistributions of your software. This has to be in your license. If you haven't done any licensing before, I recommend that your first point of questions should be the copyright officer in your institution. They know about licensing, they know about data licensing and all the digital outputs and their specific licenses for software. The second point of reference that I'll give you is go to this website, choose the license.com. It describes briefly some of the most used open source licenses and what their characteristics are. It asks you a few questions based on your needs and it describes what the best choice for you will be. The choice of license is a difficult one, but I might add that it depends. It depends on your circumstances, your project circumstances, your privacy and also your community standards. I also encourage you to rely on what the community has to say about licenses. Ask them, where do they put them, what other software are being used that might be needed to review the license when you add your own. For those of you in supporting roles, it is necessary for you to see what is the variety of licenses available before you advise the authors. I'd like you please to have a look at the SBDX license index list. It not only has the descriptions of the licenses, but it also has IDs. If you are a repository manager, you might be needing this list to be able to list them from your repository or your registry. What's the motivation of this licensing is to build trust and transparency and how software is created, distributed and consumed. It will respect your rights and respect the rights of reuse. Also for both, for authors and support staff, I recommend the ARDC research software rights management guide, which DOI is listed here. It's a short report of seven pages. It doesn't describe all of the licenses available, but it describes the families of licenses. So it's easier to understand what a family of license might do and what restrictions and liabilities does it have. To continue with a quote that I will rephrase, always license your code because unlicensed code is closed code. And also I'd like you to read this blog post. It's from someone who has been writing code for many years and it encourages you to put it out there. And from the previous website that I've already mentioned, the chooselicense.com, it has a tab that says no permission. And I'd like you to read that when you are considering not having a license. It means that no one can use your code. How does this recommendation aligns to the principles for research software? So it aligns with accessibility because if you have restrictions in your license, it might affect the accessibility of your software. It also clearly aligns with the reusability because in the terms and conditions of your license, you are either enabling or restricting how people might modify or be able to point into this software that you're putting out there. The R1.1 software is given a clear and accessible license. So it's one of the principles. And once you add that, you comply with this one. And the last one is software meets the main relevant community standards. As I said before, depending on your community, there might be some licenses that you are encouraged to use and all those not to use. Going back to the quote, finishing recommendation number two and introducing recommendation number three. Generally, when scientists make their code public, they do so because they want it to be free to use and as useful as possible for as many people as possible. So this is the mindset that I would like the most researchers will have. And that's why the recommendations align to this mindset. The recommendation number three and going back to the team building effort of software development. Define clear and transparent contribution, governance and communication processes. Your communication channels are the ways that will enable people to get involved. And then you have to think of three different target audience when you define these guidelines. First, think about your end uses. How are they going to interact with your software? Do they have every instruction they need to be able to download it, install it, and use it directly? Do they have test data sets, for example? Do they have instructions of what dependencies are needed? All of those are the guidelines that they might need and they should be clear. There is a different time of instructions that your collaborators might need that defines along with the license what their rights are and defines what they might do with your software. They might incorporate it into their own or they might add to yours to improve it and it should be defined clearly. Your evaluators or your software reviewers might need all the kinds of instructions and they might be more interested into the governance of your software. I know that at the beginning this might be too far away to think about, but the early you think about the governance, the better it is. In the second link, there are some other examples that are my side that are from very small projects to very large projects. One of the largest projects that is Community Build is the Galaxy project and it defines all of the sites in this recommendation. They have contribution guidelines, they have a governance map and they also have clear communication process for the different audiences. In the lesson, there is also a table that I encourage you to look about the governance and the levels of importance that they might have for your project. Because this importance will vary in your live project from the beginning to the middle or to the release or improvements of your project, you might have different things to look at in the governance. Going back to the previous citation, I might add from the same author, generally when scientists make their code public, they want others not only to use it but also to extend it, fix bugs, incorporate it into their own research code and thereby make it even more useful to more people. So that is the motivation for recommendation number three and how it aligns to the five principles for research. Software it aligns to two of the principles. The interoperable one, software reads, writes, and exchange data in a way that means the main relevant community standards. That might be in your communication processes, in your governance, if you allow for this to be built up in other software, etc., all the descriptions that are needed to interoperate with all the software. It also goes to reusable and the principle R3, software means the main community, domain relevant community standards. And that reinforces the principle that fair principles are domain specific and independent. So your domain might have standards that you might need to apply in order to write these communication processes and governance processes. Recommendation number four, we are almost there. It makes software easy to discover by providing software metadata by a community registry and this one is the one that wraps up most of the fair principles and that's why I consider it most important. First we need to describe what a registry is. So a registry stores information about the software. If you remember the previous definition of a repository is the location of your software project. So that's why sometimes a registry and a repository are in confusing terms because they might comply with both of the definitions. What a registry does to authors especially is facilitate discoverability of the research software. It will increase the visibility of the project and it increases the chances of collaboration, reuse and improvement. If you want to see what kind of metadata or information about your software it's needed to be public you can see the code meta project and you'll find lots of those things. Some of those might include the source code location, the authors and contributors, the license that you are using, the version of your software, the persistent identifier for your software and the references to all the outputs that your software is using or interacting with and also importantly how to cite the software. All of this it will be a landing page on your registry and it should expose metadata not only for humans to be able to read but also for machines to read and interact with others so they can gather information from one registry to another and expose it to a larger audience. The first recommendation here is go to your domain specific registry and I have a list here for you from the Netherlands East Science Center. It has a list of registries that are categorized by a domain or by a programming language and you are welcome to to choose from there or even add if you haven't found the one that you're looking for and then you know all those that might be looking for the same registry. The next topic of discussion about registries is that once you've decided to make it public and it's all with this metadata and people can find it you might also consider publishing your software not only as part of your data research paper but as a standard long research software article and here is a list of which journals you can have a look to where you can publish your software from the Software Sustainability Institute and do not forget the citation file is something that now you can add it to your repository and it might link directly to your registry so saving you a bit of time and enabling citation of your software. Now as I mentioned before this recommendation is the one that aligns to most of the principles so I have two slides for this. All of the findable principles aligned with this recommendation to make your software findable for example software is designed a globally unique and persistent identifier that should come from the registry. Authors don't need to think about this idea the registry should give one to you. Software is described with rich metadata you shouldn't be thinking of one metadata to add the registry should list all the metadata in the principles that are enabling findability of your software. Metadata clearly and explicitly includes the identifier of the software that they describe so once you have this ID it's included in the information of the software and this metadata are fair, surgical and indexable. To continue with the alignment of the fair principles accessibility software is retrievable by its identifier using a standardized communications protocol so the registry should enable the accessibility of this. Metadata are accessible even when the software is no longer available and that is an important point to have this separation between the registry and the repository. The repository might stop to exist in the future but the registry should contain the information about the software even if the software is not available. The I2 software includes qualified references to other objects that something the registry also should enable other objects such as data sets or their libraries and environments that the software needs to be able to operate and run. The R1 and R2 are for reusability software is described with a plurality of accurate and relevant attributes and those attributes you can see for example in code meta project. The R2 is very similar to the I1 where the software includes qualified references to other software so we are making a distinction between digital objects that are needed to run the software and other software that are specific referenced by your software and with that let me summarize the four recommendations which are developed software developed source code innovation control repository from the beginning of the project adopt the license and comply with the license of third party dependencies. Number three define clear and transparent contribution governance and communication processes and number four make software easy to discover by providing software metadata via community registry. Finalizing this presentation before I open up for questions I'd like to go back to the OACD recommendation amendment 2021 and and read this recommendation so if you are a person an author who develops software who writes code or those of you who are supporting the authors of research software take the steps to make research data and all the relevant digital objects from reusable and in the long term including the provision of high quality human readable machine actionable and open metadata and maintain and supported bespoke algorithms called software and workflows that are essential for their reuse of data for the publishing of your results. For authors my message to you and to keep you motivated is if you do these four recommendations it will increase the discoverability and visibility of your research software it will engage you as an author with the user communities it will provide recognition for you as an author and those who spend time contributing to your software and also it will be a trust among the users and those who are verifying and reviewing your software and my last slide for today is targeted to those in positions of decision making and how what are the next steps and how can you enable this recommendation so the paper also cites these three steps you can endorse them without any formal process you can support their recommendations number two the one that i'm doing now is actively publicizing and incentivizing their recommendations within my institution and beyond my institution and number three is compliance which is the formally implementation of these recommendations within the organization but not only that but also enabling monitoring and public reporting if possible with that i'd like to finish and open up for questions i think we have more than 15 minutes for questions this is my email and i'm very active on twitter you can find things that i share that are pertaining to the software program with these hashtags the research software au the fair for is and the visible research software and you can find the slides you are there as well and i'd also like to thank ardc for giving me the time to present to you today and answering your questions and you can contact ardc via their website subscribe to the newsletter and also find them on twitter and on youtube and and LinkedIn as well thank you thank you paula that was a wonderful presentation as paula said now we have plenty of time for questions so feel free to ask away and paul will answer as they they come through i would also invite people to comment if they are using the recommendations you i'm sure there's people who are new to this and i'm sure there those that have been doing this for years paula do you want to talk to some of the follow-up events that were mentioned in the event brought i can do that so as i mentioned before this webinar is time limited it's just one hour and i want to have the opportunity to answer questions but i know that the implementation of this recommendation goes directly to the users so i encourage communities to have their own events to answer questions to go into consultation or to have workshops um some of the people who have been in contact with us for follow-up events are the data task group in Tasmania and they are going to do a workshop about github passion control and so they will go through some of the steps including a readme and a license and how to use passion control for your software and there's also an event that the uq library is organizing at the moment i don't have the details yet but if someone wants to add them in the chat please do and our net is very supportive as you see is one of the co-hosts they also involve researchers at the early stages and you can also publish your notebook so if you use swan for example you can make your notebook available by the recommendations i mentioned we do have one question in the chat from susan so she said at what stage slash version would you attach a doi i will think that when the author thinks this is reusable then that's the version that they should publish while they are working towards that reusable version they they might have the version control of it but the dois we don't want proliferation of dois we want things that people are ready to find and reuse so the doi should be of that reusable version we've done all the tests where you where you know the software is useful when maybe you're ready to publish a paper along with that or you are preparing for that publication and we've also got another question and susan's just said thank you uh oh hold on sorry the chat is um jumping so one participant has asked can they request a session on a recommendation to make your research data visible i will say that most of the recommendations align to research data as well especially if you are bashing in your data you might be taking the first recommendation but making available publicly as soon as possible is one of the recommendations that are also needs a license in order to be of use and data might not be modified as frequently as software but putting some recommendations of of the usage of this data as internal conditions might be useful too um i addressed some comments in the chat discussing about sonodo and for those of you who don't know sonodo is a generic registry and it links directly to the version control system called github so yes you can use that combination to to provide your software with a persistent identifier and it also contains metadata for it um as i mentioned before and during the presentation i'll first recommend you to go into domain specific registry because if you are from a closed community let's say uh environmental sciences people will go through those registries before they go into a generic one can we have any any other further questions or we do um hey hello aula thanks for the presentation can you hear me yes i was wondering what what is your view you know a lot of people in research when they are developing their analysis uh there is like this trend to develop their analysis and maintain like a version control system like gith but then when they open their their code to everyone they delete the history of the commits right it's like a way it's like you know sometimes the intention that i see of some people is trying to show a clean uh you know it's like but do you have any view on that or but would be like the utility of seeing the history of commits and changes that you know any code has in the past thank you thanks for the question i should show my chockness um i don't think it's a good practice to delete the history of your commits because then you are deleting all the provenance of your software and the whole idea of using a version control system is to be able to track what has happened in during the development of this software is for when you want to recognize who made a specific change in the process there should be a commit for that and if that history is erased it's it's not showing a clean output i will say it's showing an incomplete output so i do recommend you keep all your history and it's it will be even more important that people see how long this has been evolving and how many changes and improvements this software has it's there another question uh richard um you've got your hand up uh feel free to unmute and ask away yeah i'll just um so one thing i often sort of struggle with because there's lots of different ways you can publicize and share your your tool and some of them are kind of pseudo citable or directly citable in their own right and i was wondering if you had any good resources out there for effectively sort of collecting all of the different citations you get and it's particularly pertinent when your tool is published or as otherwise associated with a journal article either in its own right or as part of a a study where you're also publishing the software tool and you want that to be the citation but people are possibly just citing it via the doi because it also has a doi and then obviously you're not getting that as your citation metrics which in an ideal world wouldn't matter but obviously in the real world um it does matter because you want to try and show people who are going to be employing you and things like that that you're actually um making an impact so i was wondering if you had any sort of comments or advice as to how to bring all of those things together or good ways of sort of keeping track of it or making sure that everything is funneled into the the same place if you see what i mean thank you i do have some comments and from different perspectives i think as a researcher the thing that will bring together all of your digital outputs will be your research id which is more generally your orchid so if you attach every single research output to your orchid then there will be fundable or in one place now about the citations i think you as an author in your readme file you are the one who defines what citation is best to use for the users because users are going to find the information that you buy first so if you put this is how you sign my software this is what they're going to do and then from the other perspective from those that are managers of different repositories there is already work and it's a challenging work to connect these research outputs some of those will link your paper to your software some of those will link dependencies of your software and i know this is working programs that they will link all the softwares that are related so that's also why one of the principles mentions explicitly references to other software and also to other digital objects to enable this compatibility and interaction between different systems and that's why it also needs to be machine readable because if we don't enable this machines will never find what we want them to find thanks for that question Richard do we have any other final questions sorry i've kept my video off because my internet is not stable that's right we have 10 minutes and please use this time also i'd like to shout out Leslie Weinborn has put recommendations from AGU guidelines for citation of software for publications specifically for authors and they have all the guidelines about that as well and which repositories to use they have a myriad of resources and i recommend you to have a look at the AGU page of resources well we just also had another question in the chat how do we know if our software is machine readable mainly we want the metadata to be machine readable so as long as you have added the description to your software into a registry they should enable the the machine readability by converting it to a format that all the registries can read understand and use so is it sure question that it's mentioned in the chat i haven't mentioned specifically in the presentation what is cff is the citation file format is a specific format that enables you to add what citation you want and goes directly to Richard's question when you have different identifiers that belong to the same object which one do you prioritize and you can do that with the cff and it has an integration with one of the most used version control systems and all those are trying to implement it too yeah i'm glad some people are already using it so they can describe the the experience as well final questions don't be shy you don't have to speak up if you don't want i can also answer in the chat and i am open for questions later on via email if you need to this is going to be recorded so the idea is to disseminate this information to all the institutions but i really recommend and please reach out to me if you want to do a specific workshop or follow-up event about these topics i will bring to you information that you can reuse and and also will help spreading the news by our newsletter while i wait for all the questions in the remaining minutes and i also add that the ARDC software program is enabling these activities via community work so we just started our community which is called the visible research software interest group and it's specific for people in supporting roles to be able to learn what is the policy around what is the current recommendation and how they might incentivize the users to promote visibility of research software so we will start another community that's more specific for researchers who quote and invite you all to contact me if you want to be part of this because i'm looking for co-hosts okay we have the chat maybe i'll put the link there so you can continue the discussion within a second i was still here paula we've got one more um question so it says are there any grants available specifically to fund this kind of essential work in biochem at least this kind of thing doesn't seem to have an obvious funding model thanks for that question just to continue once we finish this webinar i recommend you go to those discussion forum you add your questions i'll be monitoring about funding so funding is an issue and we have to admit that it needs to be changed there's a recent blog post from the research software alliance about funding and it details that funding is mostly for innovation but not as much for maintenance so we we as researchers who quote we need to demonstrate the need of maintaining it by demonstrating the number of uses that we have and the impact it's doing in science and some of those that i my side are international organizations but i i think it's better if i put the link there in the last panel that we have i know that some of them were funded by czi the chance i can be initiative and that is a funding scheme for sustainability of software but there might be others and i will put the link in the discussion so you can have a look there and discuss more in detail there are all the examples that are my side don't come right at this moment but i would recommend the more visible your software is the more it will incentivize order to maintain because of the need it's of its uses and its community with two minutes to go um unless there's more questions uh let's say thank you to everyone for coming today and being inactive and engaged group and of course thank you to our presenter paula did a fantastic job i'm giving us coverage of those four principles as well as our other co-host sara king as well as paul mentioned she did put a link to a github which has like a discussion page you can continue asking questions um there and i've just put it back at the bottom of the chat um and of course stay engaged uh with what we do we have more events coming down the pipe one in the future as well not only for uh you know software as well as things like uh vector cloud training um and of course you know shameless plug for what i'm doing as well uh so keep in touch on our event bright page check our website and whatnot um and thank you again paula and thank you again everyone uh for coming today thank you