In the following article, we report on a discussion session at the Software Sustainability Institute (SSI) Collaborations Workshop 2022, on a theme of the visibility of Research Software Engineers (RSEs) in research funding.
On the 10th anniversary of Research Software Engineering being recognised as a role within the research sphere, we pose the question: is there enough awareness of this role when granting applications are developed and costed?
The current landscape
We know who we are but does anyone else? RSEs can make significant contributions to the delivery of science programmes but this is not always recognised amongst others in the research community, including funders. Our discussion generated more questions than answers about dealing with this invisibility, and how we go about making ourselves visible more widely.
Firstly, it is useful to define what types of research funding and projects can involve RSEs.
Any projects that generate, simulate or gather very large datasets are likely to need the use of high performance computing and a wide variety of other specialised computational tools to develop analysis pipelines. These pipelines require a deep understanding of both the research domain and of software engineering. This is exactly the rare combination of skills the RSEs possess. Regardless of the quantity of data, any project that requires software to be developed or maintained will also benefit from having an RSE on the team. Software and related infrastructure are not always linked with a specific research question and the development goal may be to provide benefits and increased research capacity to a whole research community.
Additionally, RSEs have the capacity to recognise opportunities for the creation of innovation products from these research outputs, and to implement the best practice in software engineering required to commercialise them.
A number of funding schemes are available for research-related projects such as training programmes for researchers. These too, can be facilitated by RSEs who can ensure training materials are findable, accessible, interoperable and reusable (FAIR).
In short, RSEs are essential for many projects and there are few research projects that would not benefit from having an RSE on the team.
In recent years, funders have begun to recognise the importance of research software, and accordingly, there are already a number of funding streams that specifically target research software development:
SSI funding, e.g. the Fellowship Programme. Similar initiatives from other RSE societies, such as Netherlands eScience Center Fellowship Programme.
Whilst these examples of funding specifically target RSEs and therefore are likely to have review processes that are well-tailored to projects that include research software, these are exceptions to the rule. Research software is an integral part of a majority of research projects, from a wide range of funding streams, but often the application and review processes for these funding streams do not adequately take into account research software development.
Here, we suggest some open questions that we believe need to be addressed to help improve the review process for research funding:
Is there a need for greater awareness of the role and purpose of Research Software Engineers?
Do we need interdisciplinary review boards and better guidance about which is the right research council for RSE applications?
How can we ensure the value of technical development activities that support research activities is acknowledged during review?
How much detail is needed for the RSE aspect of the grant? – it seems that the science aspect of the grant can take most of the limited space in a proposal.
Is there scope to standardise the approach when describing RSE components to applications?
How has RSE time been costed into research proposals in the past using overheads?
How does an emphasis on open science and/or open source software have an impact on how RSE inclusion is perceived?
What should go into the Methods/Methodology section of an RSE research proposal?
In the case of innovation funding, how can one resolve the potential conflict between open source and commercialisation?
These questions led on to broader considerations and challenges around the employment of RSEs using grant funds in general.
Many of these challenges arise from the competition with industry where salaries are typically higher, contracts are longer term and career paths are better defined. PI’s can have difficulty determining the amount of domain knowledge required as well as specifying job roles that will be attractive to RSEs with highly desirable skills. This is made more difficult by the lack of uniformity amongst universities – an RSE may be based entirely within a research group on a specific project or with a central research computing support team. Similarly, they may be viewed as professional services staff or as research staff, and these factors may determine the attractiveness of a specific job to an individual RSE.
We have identified the lack of clarity regarding the path to both acquiring and employing RSEs as part of grant funded research projects. In turn, this highlights that organisations, in some cases, have been slow to recognise the importance of software and the role of RSEs in supporting and increasing research capacity, and funders slow to recognise their value.
What has also been recognised is that there is increasing, peripheral support available for championing the RSEs role when applying for grants: whether through external funding or provision of resources to support their adoption. So too there is recognition through the SSI, Society of RSEs, other RSE communities and domain specific communities. This paints a promising picture for future positive change.