Sustaining Research Software: an SC18 Panel

Many science advances have been possible thanks to the use of research software, which has become essential to advancing virtually every Science, Technology, Engineering and Mathematics (STEM) discipline and many non-STEM disciplines including social sciences and humanities. And while much of it is made available under open source licenses, work is needed to develop, support, and sustain it, as underlying systems and software as well as user needs evolve. In addition, the changing landscape of high-performance computing (HPC) platforms, where performance and scaling advances are ever more reliant on software and algorithm improvements as we hit hardware scaling barriers, is causing renewed tension between sustainability of software and its performance. We must do more to highlight the trade-off between performance and sustainability, and to emphasize the need for sustainability given the fact that complex software stacks don’t survive without frequent maintenance; made more difficult as a generation of developers of established and heavily-used research software retire. Several HPC forums are doing this, and it has become an active area of funding as well. In response, the authors organized and ran a panel at the SC18 conference. The objectives of the panel were to highlight the importance of sustainability, to illuminate the tension between pure performance and sustainability, and to steer SC community discussion toward understanding and addressing this issue and this tension. The outcome of the discussions, as presented in this paper, can inform choices of advance compute and data infrastructures to positively impact future research software and future research.

💡 Research Summary

The paper reports on a panel held at the 2018 Supercomputing Conference (SC18) that examined the growing challenge of sustaining research software in the era of rapidly evolving high‑performance computing (HPC) platforms. The authors begin by noting that modern scientific discovery across STEM and the social sciences increasingly depends on complex software stacks, many of which are openly licensed but suffer from a lack of systematic maintenance and long‑term support. As Moore’s law slows and hardware scaling reaches physical limits, performance gains now rely heavily on algorithmic innovation and software engineering. This shift creates a tension between the pursuit of peak performance—often achieved through low‑level, hardware‑specific optimizations—and the need for code that is readable, modular, and maintainable over many years.

The panel featured three invited speakers representing academia, national laboratories, and funding agencies, followed by an interactive discussion with the audience. Three major themes emerged.

1. Performance‑Sustainability Trade‑off – Speakers illustrated how aggressive optimizations for GPUs, FPGAs, or emerging heterogeneous architectures can lock code into a particular generation of hardware, making future migration costly. They advocated for design principles that balance speed with longevity: clear modular boundaries, well‑defined APIs, automated testing, and continuous integration pipelines. Such practices enable incremental performance improvements without rewriting large code sections.

2. Generational Knowledge Transfer – The majority of core developers of widely used research packages are senior scientists approaching retirement. Their tacit expertise is rarely captured in documentation, leading to “orphaned” software when they leave. The panel recommended formal mentorship programs, inclusion of software engineering curricula in graduate training, and the establishment of dedicated software engineers or “research software engineers” (RSEs) within research groups to act as knowledge custodians. Open‑source community engagement was also highlighted as a mechanism to distribute expertise beyond a single institution.

3. Funding and Policy Structures – Traditional grant mechanisms focus on short‑term, novelty‑driven projects, leaving little room for dedicated maintenance budgets. Recent initiatives by agencies such as the NSF, DOE, and the European Horizon programmes are beginning to fund software sustainability, but these efforts are still fragmented. Panelists proposed a suite of policy actions: (a) recognize research software as a research infrastructure asset eligible for long‑term funding, (b) create maintenance contracts or service‑level agreements that can be attached to larger research grants, (c) foster public‑private partnerships that share the cost of sustaining critical tools, and (d) adopt metadata standards and governance models that facilitate reuse and provenance tracking across institutions.

In the concluding remarks, the authors synthesize the discussion into actionable recommendations. First, embed sustainability criteria into the software design lifecycle from the outset, rather than treating it as an afterthought. Second, institutionalize RSE positions and community management roles to ensure continuous development, testing, and user support. Third, reshape funding models to include explicit maintenance lines, performance‑sustainability balancing metrics, and incentives for open‑source contributions. By implementing these strategies, the research community can transform software from a fragile, project‑specific artifact into a robust, reusable infrastructure that keeps pace with the accelerating evolution of HPC hardware and scientific inquiry.

Overall, the paper argues that addressing the performance‑sustainability tension is not merely a technical issue but a systemic one that requires coordinated action from developers, institutions, and funding bodies. The insights from the SC18 panel provide a roadmap for building a resilient research‑software ecosystem capable of supporting future scientific breakthroughs.