HomeNews and blogs hub

Software Sustainability in Computational Science and Engineering at PASC22 (part 2)

Bookmark this page Bookmarked

Software Sustainability in Computational Science and Engineering at PASC22 (part 2)

Author(s)
Matthew Bluteau

Matthew Bluteau

SSI fellow

Posted on 28 October 2022

Estimated read time: 4 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

Software Sustainability in Computational Science and Engineering at PASC22 (part 2)

Posted by j.laird on 28 October 2022 - 10:00am

By SSI Fellow Matthew Bluteau.

This is the part two of a two-part blog post. The first part is available here.

Improving Support and Recognition for Research Software Personnel - the International Landscape

Expanding further the scope of consideration, it is necessary to acknowledge that even central and embedded RSE teams cannot solve all of the problems of software sustainability because they operate in a global research culture that still does not adequately value research software as an output. This means these teams are constantly fighting an up-hill battle and unable to operate at their full potential. The international action and culture change needed to improve this situation is what Anna-Lena’s talk addressed.

She succinctly gave the roadmap for culture change in the slide below:

Roadmap for culture change by Anna-Lena LemprechtLamprecht, Anna-Lena; Barker, Michelle (2022): Improving Support and Recognition for Research Software Personnel - the International Landscape. figshare. Presentation. https://doi.org/10.6084/m9.figshare.20492739.v1

What I particularly liked was her comment that this is meant to be simultaneously a bottom-up and top-down approach, something I have long believed in. At the bottom of the pyramid are the categories of infrastructure and skills (substitute for “User Interface / Experience” in the figure), which are slightly different from the infrastructure and training that were mentioned in my talk above, which was focussed on RSEs providing the services for researchers. Rather, the infrastructure and skills Anna-Lena is talking about are specifically to support RSEs. An example of infrastructure she gave was something like the Citation File Format (CFF) that easily facilitates the citation of a code repository, helping RSEs get cited and therefore closer to proper recognition. This is also something that was produced directly by a few RSEs. Bottom up approach FTW!

On the skills side, Anna-Lena identified a new group called INTERSECT that is looking at what skills RSEs specifically need to develop their career. Again, this is different from more general research software skills that both researchers and RSEs require, like the foundational common ground the Carpentries has built. I have not had much contact with this group yet, but I am very interested in getting involved. It strikes me as a nice mix of both bottom up and top down approaches. It is supported by the NSF (top-down) but was presumably first submitted by a group of researchers (bottom-up).

Next in the pyramid is communities, a theme that arose in all three presentations. This highlights that communities are needed at many different levels in order to support software sustainability. As RSEs, we are quite lucky that an extensive international network of national RSE societies has developed with the movement. Wherever you are in the world, there will be a society you can join as an RSE to get support and network with other RSEs. These national and international communities are essential because not every institutions or research area will have an appropriate community for an RSE to join.

Moving one more level up the pyramid, we come to incentives. I think incentives are closely linked with recognition, and this is confirmed by the fact that Anna-Lena mentioned things like the Hidden REF and progress in the Netherlands towards considering all outputs (including software) when making decisions about hiring and promotion. Ultimately, software sustainability depends in large part on RSEs being widespread in research, and that can only happen when they are properly recognised and rewarded for their contributions to research.

Finally, at the top of the pyramid for creating culture change is policy, which encapsulates most of the “top-down” aspects of this framework. It is the policies of funding bodies, universities, and publishers that create the environment in which research culture forms, meaning there is only so much that research culture can deviate from the limits enforced by this policy environment. Concerted advocacy and lobbying over many years will be needed, and Anna-Lena pointed out organisations doing this work like the Research Software Alliance (ReSA), Software Sustainability Institute (SSI), and the FORCE11 Software Citation Working Group. I would add that many national RSE societies are also engaged in policy advocacy, a specific example being the discussions that SocRSE have had with funding bodies in the UK.

Share on blog/article:
Twitter LinkedIn