By Mateusz Kuzak, Maria Cruz, Carsten Thiel, Shoaib Sufi, and Nasir Eisty.

This post is part of the WSSSPE6.1 speed blog posts series.

We argue that research software should be treated as a first-class research output, in equal footing to research data. Research software and research data are both fundamental to contemporary research. However, the recognition of the importance of research software as a valuable research output in its own right is lagging behind that of research data.   

Research funders, scholarly publishers, universities and research institutions across the world increasingly see the value in treating research data as stand-alone research objects that can be cited and archived as independent research outputs. At the policy level, this recognition has translated into policies and requirements for research data management, open data, and FAIR data. At the practical level, these policies have led to institutional provision of support and training for researchers. Many universities and research institutes now offer research data (management) support services, often as part of the services provided by libraries.

Unfortunately, the same cannot be said for research software. There are many interesting initiatives pushing for the recognition of the importance of research software. However, these initiatives are not reinforced through policies from the top – currently, funders focus almost exclusively on research data – and provision of training and support in the area of research software can be patchy, to say the least. Although there are some great examples from the UK, one of which was presented in a poster at the WSSSPE 6.1 in Amsterdam on October 29th.

One of the ways funders and research institutions have promoted the importance of research data and research data management is through the requirement for data management plans. Should this same approach be used for research software? Should funders request software management or sustainability plans? And would that then lead to an increase of training and support provision? More importantly, could it lead to an increase in following best practices in software management and development?

The discussions we had during the WSSSPE 6.1 workshop on October 29th in Amsterdam didn’t lead to clear answers to these questions, as there were different views and ideas among our group. However, we would like to highlight some current examples of software development guidelines and software management  plans and how they are already being used in the field. We would also like to provide some ideas for what the next steps should be and to highlight some of the questions that need to be addressed in this area. This includes both a bottom-up approach by institutions following established software engineering principles and at the same time a top-down approach by funders imposing appropriate requirements.

Some institutions have already begun to create software development guidelines, including the Software Sustainability Institute Guides and the Netherlands eScience Center Guide but also the pan-European Social Sciences and Humanities Infrastructures CESSDA, CLARIN and DARIAH are collaborating on their joint Technical Reference as part of the EURISE Network initiative, that was also presented at the conference. Their purpose is largely to ensure that software development is carried out in a way that will later ensure re-usability of the software created. To this end, they generally start by asking for the source code to be made available, both technically and legally, but extend also into the design and documentation of the software itself. As such, the guidelines and their accompanying checklists can also be used as a quality measure.

To ensure this becomes a common practice, the time needed for this work must be recognised and reflected in projects and grant applications. Therefore, the next step could be that funders actually start requiring researchers to use these research software guidelines and implement software management plans. One possible minimal starting point for conversations with the funders are the 4OSS recommendations, which already have a lot of community support and could help ensure that the minimum availability and reusability of the software will be in place. Software Management Plans could be requested by funding bodies when researchers start software development projects. These plans would need to address both the actual development methods and the handling of the source code, which can be seen as one form of research data, but also the more challenging aspects of re-usability with respect to the ever changing technological environment.

One of the lessons learned from Data Management Plans is the need for a regular evaluation of plans and adherence to them by projects as they progress, as it is the authors’ subjective impression that too often these plans get written but it’s never verified that the work is actually carried out in accordance with the plan. Some of the other questions that need to be addressed in the area of software management plans and their relationship with data management plans include: should there be separate software management plans or would it be better to have research output management plans / open science plans covering all relevant research outputs, such as data, software, methods and workflows? Should the funders provide a single template or recommend that researchers follow community-specific guidelines?

Our discussion showed that the value attached to software is not nearly as high as the participants felt it needs to be. To change this, awareness for the issue has to be increased at all levels and institutions. It starts with the researcher investing time into software development and seeing this as an important research contribution that will eventually be accepted as such in tenure track and other academic evaluation by committees. So ultimately, the culture change around the value given to research software involves researchers, institutions, funders and publishers or anyone who has a stake in research software development and reuse.

Want to discuss this post with us? Send us an email or contact us on Twitter @SoftwareSaved.