Die 6. Konferenz für Forschungssoftwareentwicklung in Deutschland, deRSE26, ist an der Universität Stuttgart erfolgreich zu Ende gegangen. Die dreitägige Konferenz brachte mehr als 280 Teilnehmende aus Universitäten und Forschungseinrichtungen aus ganz Deutschland und darüber hinaus zusammen. Ihr ging der erste Stuttgarter Tag der Forschungssoftware voraus.

Die deRSE26 fand vom 3. bis 5. März 2026 auf dem Vaihinger Campus der Universität Stuttgart statt. Die Veranstaltung diente als Forum für Personen, die Forschungssoftware in allen wissenschaftlichen Disziplinen entwickeln, pflegen und nutzen.

Das Programm umfasste rund 90 Poster sowie 100 Vorträge, Workshops und andere interaktive Formate in bis zu fünf parallelen Programmsträngen. Die Beiträge behandelten Themen wie Software Craftsmanship, Emerging Computing & Infrastructure, Open Science & Collaboration, Data Analysis & AI, und Community, Policy & Career Development.

Die Teilnehmenden deckten ein breites Spektrum an Fachgebieten ab, darunter Ingenieurswissenschaften, Natur- und Lebenswissenschaften, Geisteswissenschaften sowie Sozialwissenschaften. Im Mittelpunkt der Konferenz standen Community Building und Zusammenarbeit über Fachgrenzen, Institutionen, Geschlechter und Karrierestufen hinweg.

Zu den Höhepunkten des Konferenzprogramms gehörten zwei Plenarvorträge und eine Podiumsdiskussion. In seinem Plenarvortrag sprach Wolfgang Bangerth von der Colorado State University über die Herausforderungen bei der Entwicklung zuverlässiger, skalierbarer Simulationssoftware in komplexen Anwendungsbereichen. Er hob hervor, wie systematisches Software-Engineering, langfristige Community-Entwicklung und offene Zusammenarbeit es ermöglichen, dass fortschrittliche numerische Methoden in der Praxis eingesetzt werden. Der Vortrag veranschaulichte, wie sich Forschungssoftware über Jahrzehnte hinweg weiterentwickeln kann, ohne dabei an Wartbarkeit und Überprüfbarkeit einzubüßen.

Morane Gruenpeters Plenarvortrag konzentrierte sich auf die Nachhaltigkeit und Governance von Forschungssoftware im weiteren Ökosystem der Open Science. Sie erörterte, wie Praktiken wie klare Lizenzierung, persistente Identifikatoren und strukturierte Metadaten dazu beitragen, Software auffindbar, zugänglich, interoperabel und wiederverwendbar zu machen. In ihrem Vortrag betonte sie, dass verlässliche Rahmenbedingungen und Community-Standards unerlässlich sind, um die langfristige Aufbewahrung und Anerkennung von Forschungssoftware-Ergebnissen zu gewährleisten.

Die Podiumsdiskussion befasste sich mit der zukünftigen Strukturierung des Forschungssoftware-Ökosystems in Deutschland. Die Podiumsrunde brachte Perspektiven aus Forschung, Infrastruktur und Politik zusammen, um über Anerkennung, Finanzierungsmodelle und Karrierewege für Forschungssoftwareentwickelnde zu diskutieren. Die Diskussion beleuchtete, wie Institutionen und Förderorganisationen Software besser als primäres Forschungsergebnis anerkennen können, und löste während der gesamten Konferenz intensive Folgegespräche unter den Teilnehmenden aus.

„Die hohe Teilnehmendenzahl bei der deRSE26 zeigt, dass Forschungssoftwareentwicklung fest als Kernkomponente der modernen Wissenschaft etabliert ist“, sagt Bernd Flemisch, der Konferenz-Chair. „Wir beobachten eine wachsende Anerkennung für die Menschen, Prozesse und Infrastrukturen, die zuverlässige, wiederverwendbare wissenschaftliche Software ermöglichen.“

Die Veranstaltenden kündigten zudem an, einen Tagungsband zu veröffentlichen. Autor*innen sind eingeladen, erweiterte Versionen ihrer Beiträge für einen speziellen Open-Access-Band in der Zeitschrift ECEASST einzureichen.

Die deRSE26 setzte die Reihe der Konferenzen zur Forschungssoftwareentwicklung in Deutschland fort, die von de-RSE e.V. - Gesellschaft für Forschungssoftware ins Leben gerufen wurde. Die Veranstaltung unterstrich die Bedeutung nationaler und internationaler Vernetzung für die Förderung der beruflichen Anerkennung, der Karrierewege und der Ausbildungsmöglichkeiten für Research Software Engineers (RSEs).

Das Organisationskomitee dankt allen Mitwirkenden, Volunteers und lokalen Helfenden, deren Einsatz die Konferenz ermöglicht und zu einem Erfolg gemacht hat. Die finanzielle Unterstützung durch das NFDI-Konsortium NFDI4ING, die Exzellenzcluster SimTech, IntCDC und [ctd.qmat] (https://www.ctdqmat.de/), sowie die Sonderforschungsbereiche ATLAS und SFB 1313 wird dankbar anerkannt.

Die Planungen für die nächste Ausgabe der Konferenz für Forschungssoftwareentwicklung in Deutschland sind bereits im Gange; weitere Einzelheiten werden auf der de-RSE-Webseite bekannt gegeben. Diese Konferenzen werden größtenteils von der Community organisiert, und alle Unterstützenden sind herzlich willkommen!

The 6th Conference for Research Software Engineering in Germany, deRSE26,has successfully concluded at the University of Stuttgart. The three-day conference brought together more than 280 participants from universities and research institutions across Germany and beyond. It was preceded by the first Stuttgart Research Software Day.

deRSE26 took place from March 3 to 5, 2026, on the Vaihingen campus of the University of Stuttgart. The event served as a national forum for people who develop, maintain, and use research software in all scientific disciplines.

The program featured around 90 posters and 100 talks, workshops, and interactive sessions in up to five parallel tracks. Contributions covered topics such as research software craftsmanship, emerging computing & infrastructure, Open Science & collaboration, data analysis & AI, community, policy & career development, as well as cross-disciplinary advancements.

Speakers and attendees represented a broad spectrum of domains, including engineering, natural and life sciences, humanities, and social sciences. The conference emphasized openness, community building, and collaboration across disciplines, institutions, genders, and career stages.

Highlights of the conference program included two plenary talks and a podium discussion. In his plenary, Wolfgang Bangerth from Colorado State University addressed the challenges of building reliable, scalable simulation software in complex application domains. He highlighted how systematic software engineering, long-term community development, and open collaboration enable advanced numerical methods to be used and trusted in practice. The talk illustrated how research software can evolve over decades while remaining maintainable and verifiable.

Morane Gruenpeter’s plenary focused on the sustainability and governance of research software in the broader open science ecosystem. She discussed how practices such as clear licensing, persistent identifiers, and structured metadata help make software findable, accessible, interoperable, and reusable. Her talk emphasized that robust policy frameworks and community standards are essential to secure long-term preservation and recognition of research software outputs.

The podium discussion targeted the future structuring of the research software ecosystem in Germany. The panel brought together perspectives from research, infrastructure, and policy to debate recognition, funding models, and career paths for research software engineers. The discussion explored how institutions and funding bodies can better acknowledge software as a primary research result and sparked intensive follow-up conversations among participants throughout the conference.

“The strong attendance at deRSE26 shows that research software engineering has firmly arrived as a core component of modern science,” says Bernd Flemisch, the conference chair. “We see growing recognition for the people, practices, and infrastructures that make reliable, reusable scientific software possible.”

The organizers also announced plans to publish post-conference proceedings. Authors are invited to submit extended versions of their contributions to a dedicated open-access volume in the journal ECEASST after peer review.

deRSE26 continued the series of German research software engineering conferences established by the community-led de-RSE association. The event underlined the importance of national and international networking to advance professional recognition, career paths, and training opportunities for research software engineers.

The organizing committee thanks all contributors, volunteers and local helpers whose efforts made the conference possible and successful. The financial support by the NFDI Consortium NFDI4ING, the Clusters of Excellence SimTech, IntCDC and ctd.qmat, as well as the Collaborative Research Centres ATLAS and SFB 1313 is gratefully acknowledged.

Planning for the next edition of the Conference for Research Software Engineering in Germany is already under way, with details to be announced on the de-RSE website. These conferences are largely organized by the community, and any contributions are very welcome!

For the last two days of the work year 2025, the teaching RSE working group of the deRSE society met in Dresden for the Symposium on Teaching Research Software Engineering in Germany. The journey to Dresden was fairly straight-forward for those coming from Berlin. Others were not so lucky and arrived a few hours late. The people who arrived on time used the opportunity to drink coffee and catch up with various research software engineering topics.

One of the discussions was about why it is so difficult to recruit helpers and instructors for Carpentries workshops. It seems like the usual candidates, PhD students, are too busy working in the labs of their supervisors to be able to do any teaching. In the UK, PhD students work on their projects which are part of the lab. However, they are not expected to take on any extra responsibilities in running a lab. This role is usually fulfilled by post-docs. This might explain why it appears to be more difficult to establish the carpentries in Germany.

Guido Juckeland gave the first presentation on teaching RSE at the TU Dresden. The course comprises typical RSE topics: shell, working in teams, licensing, testing and CI/CD, build systems and software publications. Teaching is done in lectures and practicals. The students first work on individual project during the first half and then on group projects during the second half. They use the flake8 python linter for marking. It was not surprising that genAI popped up. Fredo Erxleben was wondering how to ensure that the students do not overly rely on genAI for code generation. They did find that using genAI for test-driven development worked pretty well since the students have to carefully think about the tests so that they can prompt the LLM. We came to the conclusion that you cannot stop people from using genAI. However, they should be made aware of the various issues and be transparent about their use of the technology by, for example, making a declaration of AI use. One way to check that they understand what they did is to ask the students to give a presentation of their project. The team at the TU Dresden hoped that the students would produce reproducible jupyter notebooks. In practise, they stuck to the scaffolding and did not add much documentation. Students probably need to be guided more explicitly.

Next, Magnus Hagdorn gave a brief overview of the history of the Carpentries and his new role in the Software Carpentry Governance Committee. Magnus then gave an outlook of what is brewing in the world of the Carpentries. The HPC Carpentry course has moved into the incubator and is becoming part of the official curriculum. The course includes an intro to HPC, workflows with snakemake and HPC python. The course can be easily modified to suit local HPC clusters. The scientific computing team at the Charité, has used the HPC course during their last HPC training event. The other big news is that the Carpentries are working on a two day AI course. In fact, the plan is to have two courses: one for beginners and one for proficient programmers. Both courses will include an introduction to the technology of LLMs and how they work, implications of using them and how to use them at levels appropriate to the target audience. Magnus also reported on the ideas to work on the git courses, offering github and gitlab specific material, VSCode and the plan to look into transitioning courses (in particular intermediate courses) from the incubator in the Software Carpentry Programme. During the discussion the Code Refinery git course was mentioned and that they use twitch live streaming for watch parties.

Given the late start, we proceeded to the evening programme: a trip to the Christmas Market. We passed the big and famous one (the Striezelmarkt) and went for the one at the Frauenkirche which was a little bit less crowded. We tried egg glogg which tastes essentially like alcoholic custard sauce and had something to eat. Some of us found their way to an inside place with some beer. RSE discussions continued. We resumed the conversations in the morning at breakfast in the guest house.

The first talk of the morning was given by Katrin Schöning-Stierand from the University of Hamburg. Katrin offers various RSE courses that are open to members of all faculties. During the winter semester she runs an introduction to python course and in the summer semester an RSE course. The RSE course assumes some python knowledge and also includes both individual and group projects. One problem she struggles with is that her courses are hard to find because they do not appear in the faculty course handbooks. At the end of the RSE course the students present their projects during an RSE day. This helps the students with their presentation skills and is good advertisement for the courses.

The second talk was given by Jan Philipp Thiele from the digital science support lab of the TU Braunschweig. The support services are shared by the various lower saxony universities. Hannover focuses on AI while Braunschweig focuses on RSE. They use the live code extension of VSCode with some success. We had an interesting discussion on where central RSE units could be placed: central IT departments or libraries. Both deal with information so they are both good candidates. Although some central IT departments seem to be reluctant to take on extra services. Other new central RSE units are being established in Marburg and Frankfurt/Main.

Next was Nicholas Del Grosso from the university hospital Bonn, who runs the iBOTS open neuroscience training platform which is part of the ibehave network. They are a team of four people that develop and teach neuroscience courses. As part of their course development pipeline, they evolve their courses through three stages:

1. tool-based courses, which are essentially howtos,
2. courses that teach methods and workflows across an ecosystem of tools, and
3. domain specific application courses that address scientific questions, using an ecosystem of tools.

The courses take the form of summer schools (2-3 weeks), online workshops (1-3 days), on-demand help and self-study materials. Their materials and web site is constructed using a custom pipeline that converts files into a format ready for the static website generator Hugo. They did try quarto but found it too slow for such a large project, taking around 30 minutes to generate the entire website, and using a popular static site generator like Hugo makes customizing the website with modern features much more straight-forward. Their new pipeline takes seconds to build the full site. In his talk, Nicholas described RSE services as another part of scientific support infrastructure, similar to RDM, animal welfare, library service, peer-reviewed journals, etc. Teaching these courses is difficult because the trainers are neither domain experts (they support many scientific domains and technical workflows) nor are they necessarily educators (they tend to have a research background, with no formal education).

There is also a high turnover of staff since either their contracts run out or they find employment elsewhere. This pressurises course didactics. Without a scaling strategy, most single teachers addressing a group of students can handle a group of 10 to 14 students without trouble. To scale up to larger groups, a course needs to increase the student-student or student-computer interactions. The iBOTS team does this by having regular three people break-out rooms. Participants get randomly shuffled which helps to ensure that preferences to work with either a proficient or novice practitioner can be satisfied. They also ask that at least one person shares their screen. This encourages participation and communication. During the introduction round they ask participants to tell the others why they are taking part in the course and what they are excited about which turns out to be much more effective than the teacher giving a motivational introduction and what to expect and get out of the course. This way they can handle courses with 80 participants and a single teacher. Feedback is gathered using following a “4L Retroscpective” session using Miro boards. Miro features like Private mode (allows participants to add their own feedback without seeing what the others are writing) and timers (to keep everyone on-task) are very helpful for this. In a second round the participants are asked to group the feedback.

Julian Dehne, then, gave an update of the development of an RSE Master’s Program. Maja Toebs has looked at available scientific computing/RSE course descriptions and is extracting and clustering topics. There is a plan to pilot various courses during the next year. We had a discussion on whether generic RSEs are employable and what you can expect from them. We expect that a RSE can help break silos and build bridges between the various strands of research endeavours.

Finally, Florian Goth introduced the DiscoRSE project which aims to make RSE related open educational resources more findable. In order to be able to do so they are looking into a metadata schema for standardised annotation of RSE-OERs.

All participants agreed, that it was good to catch up in person after meeting every week virtually in the online meetings of the teachingRSE project. The next opportunity to catch up in person is the deRSE26 conference in Stuttgart. Presentations of the event will be shared on the zenodo community. We are thankful to the cluster of excellence ctd.qmat for travel support.

This blog post is adapted with friendly permission from Magnus Hagdorn’s blog.

The call for contributions will open on September 22. We encourage you to submit an abstract, whether you are from academia or industry, a student or an employee, a first-time presenter or a seasoned RSE. If your contribution addresses a topic that you think is of interest to the community of people concerned with research software, we would love to see it submitted!

We use the Indico platform to manage conference registration and abstract submission. These operations are decoupled from each other, i.e. abstract submission doesn’t automatically register you. You can use Helmholtz AAI to create an account through your institution, GitHub, Google, or ORCID.

We plan to publish a post-conference proceedings volume on the deRSE26 conference. Contributors to deRSE26 will be invited to submit a journal-length version of their contribution to this volume after the conference. Submissions will be peer-reviewed and, if accepted, published in the open-access journal ECEASST (https://eceasst.org/index.php/eceasst) at no cost to the authors.

Please don’t hesitate to contact the orga team, derse26@listserv.dfn.de, if you have any questions.

We are looking forward to welcoming you in Stuttgart next March!

Dazu zählt das Projekt „FutuRSI: Konzeption und Anlaufphase eines deutschen Forschungssoftware-Instituts“. Es hat zum Ziel, eine prototypische Service-Organisation für Research Software Engineering mit verteilten Teams für ein bundesweites, föderales Angebot zu entwickeln. Dabei werden die gewonnenen Erfahrungen genutzt, um ein Konzept für die einzelnen Arbeitsschritte zu erstellen, die für den prototypischen Aufbau einer deutschlandweiten Organisation notwendig sind. Um dieses Ziel zu erreichen, werden die Entwicklung der Struktur bottom-up und iterativ gestaltet und Stakeholder aus Wissenschaft und Politik frühzeitig und kontinuierlich eingebunden. Teil des Konzepts ist auch eine Machbarkeitsstudie und ein Vorschlag für eine Organisationsstruktur. Das FutuRSI-Projekt wird von einem Konsortium aus sechs Institutionen in Deutschland durchgeführt und startet im April 2025. Neben dem de-RSE Verein sind auch das Forschungszentrum Jülich (FZJ), die Gesellschaft für Informatik (GI), das Helmholtzzentrum Dresden Rossendorf (HZDR), das Kompetenzzentrum Digitale Forschung (zedif) der Universität Jena und die SUB Göttingen an dem Projekt beteiligt.

In Kooperation des de-RSE Vereins mit der Fachgruppe RSE der GI sind zudem zwei weitere erfolgreiche Projektanträge entstanden. Eines der Projekte zielt darauf ab, ein RSE Master-Programm zu entwickeln, während das andere dem Thema “Award” im RSE Kontext gewidmet ist. Der Antrag “Ausgezeichnete Forschungssoftware (RSE-Award)” verfolgt das Ziel, die Qualität und Sichtbarkeit von Forschungssoftware durch einen RSE-Award zu fördern. Die Auszeichnung soll Anreize für qualitativ hochwertige Softwareentwicklung schaffen, Best Practices hervorheben und die RSE-Community stärken. Das Projekt “Research Software Engineering Master” zielt wiederum darauf ab, einen spezialisierten Masterstudiengang für Research Software Engineering (RSE) zu entwickeln. Es soll ein Referenz-Curriculum erstellt, in bestehenden Studiengängen erprobt und langfristig zur Etablierung offizieller RSE-Abschlüsse genutzt werden. Das Projekt wird u.a. in enger Kooperation mit dem gemeinsamen Arbeitskreis “Teaching RSE” von de-RSE und GI durchgeführt.

Wir freuen uns auf die Zusammenarbeit mit allen Beteiligten.

Unter dem Dach der Themenwoche “Digitale Kompetenzen in der Wissenschaft” förderte die VW-Stiftung
vom 02.-04.12.2024 vier Symposien mit Raum für den gegenseitigen Austausch. Die Teilnehmer:innen unseres Symposiums “Code for Science, oder: Bessere Forschungssoftware durch bessere Forschungssoftwarekompetenzen” kamen nicht nur aus dem RSE-Umfeld, sondern auch von Bibliotheken, Rechenzentren und aus dem Forschungsdatenmanagement. In drei intensiven Tagen konnten wir Ideen zusammentragen, wie die Kompetenzen im Bereich Forschungssoftware verbessert werden können, und welche guten Initiativen es in diesem Feld bereits gibt. Wir haben ein Dokument mit Handlungsempfehlungen für verschiedene Akteure begonnen zu entwickeln. Demnächst werden wir an dieser Stelle mehr davon berichten - bleibt dran!

Was definiert einen RSE?

Was oder wer genau ist ein RSE? Bittet man drei Personen um eine Definition von RSE, und abgesehen von den gebräuchlichen Wörtern „Software“ und „Forschung“ wird man wahrscheinlich drei verschiedene Antworten erhalten. Das liegt daran, dass der Bereich, in dem RSEs arbeiten, und die Arbeit, die sie möglicherweise verrichten, nicht immer einfach zu definieren sind, ebenso wie ihre grundlegenden Kompetenzen.

RSEs besetzen einen bisher „verborgenen Bereich“ – die große Lücke zwischen der Arbeit von Forschenden in einer akademischen Einrichtung und der Arbeit von professionellem Servicepersonal, dessen Rollen alles von Finanzen und Studentenverwaltung bis hin zum Managen von Unternehmenscomputerinfrastrukturen umfassen können. Während die Arbeit eines RSE natürlich auch Softwareentwicklung umfasst, haben RSEs am einen Ende des Spektrums Rollen, die denen von Forschenden sehr ähnlich sind. Am anderen Ende des Spektrums ähnelt die Rolle eines RSE sehr stark der von professionellen Softwareentwicklenden, der in einem Industrieumfeld arbeiten. Obwohl ein RSE zweifellos Software schreibt, wird diese Rolle durch ein viel breiteres Spektrum an Fähigkeiten, Kompetenzen und Erfahrungen definiert.

Allgemeine Definitionen eines RSE können hilfreich sein – eine gängige Definition dieser Art hebt im Allgemeinen hervor, dass „ein RSE jemand ist, der spezielle Softwareentwicklungsfähigkeiten anwendet, um Forschungsaufgaben zu unterstützen und durchzuführen“. Obwohl diese Definition nicht falsch ist, verdeckt sie dennoch eine enorme Komplexität, die einer ausführlicheren Diskussion bedarf.

Die grundlegenden Kompetenzen eines RSE

Angesichts dieses komplizierten und sich rasch entwickelnden Bereichs haben sich die Autoren von arXiv:2311.11457 (Update: nun unter offenem Peer-Review bei F1000Research), der „TeachingRSE Kollaboration“, vorgenommen, die grundlegenden Kompetenzen eines Research Software Engineers besser zu verstehen und zu identifizieren.

Das ursprüngliche Team aus Heidi Seibold, Jeremy Cohen, Florian Goth, Philipp Schäfer und Samantha Wittke veranstaltete auf der deutschen RSE-Konferenz im Februar 2023 in Paderborn (deRSE23) einen Workshop mit dem Titel „Teaching and Learning Research Software Engineering“, der zur Diskussionen anregte, was genau die Kompetenzen eines RSE sind. Die Community wurde frühzeitig durch mehrere Workshops integriert (auf der deRSE23 in Paderborn, der un-deRSE23 in Jena und der deRSE24 in Würzburg). Obwohl die Zusammenarbeit größtenteils auf einer Kerngruppe von Mitgliedern der deutschen RSE-Community – de-RSE – basierte, gab es auch internationale Beiträge, um sicherzustellen, dass die breitere internationale Perspektive in den resultierenden Ergebnissen repräsentiert ist.

Der Zeitaufwand für diese Arbeit und die große Bandbreite an Beiträgen und Perspektiven verdeutlichen die grundlegende Komplexität, die mit der Ermittlung der grundlegenden Kompetenzen und Verantwortlichkeiten eines Research Software Engineers verbunden ist.

Das Papier

„Foundational Competencies and Responsibilities of a Research Software Engineer (Grundlegende Kompetenzen und Verantwortlichkeiten eines Research Software Engineers)“ arbeitet sich durch den Prozess des Verständnisses dessen, was die Rolle eines RSE ausmacht. Es beginnt mit einigen allgemeinen Hintergründen und Begriffen, bevor es die in der Zusammenarbeit herausgearbeiteten Schlüsselwerte eines RSE hervorhebt - was RSEs in ihrer Rolle erreichen wollen und die Werte, die dieser Arbeit zugrunde liegen. Die Autoren betrachten dann die Kompetenzen selbst, die durch ausführliche Diskussionen und Debatten darüber identifiziert wurden, was RSEs tun und wie sie es tun. Diese Fähigkeiten werden in solche unterteilt, die sich direkt auf Software beziehen, solche, die eher forschungsbezogen sind, und solche, die auf Kommunikation ausgerichtet sind. Die TeachingRSE Kollaboration identifiziert diese drei Bereiche als Kern dessen, was ein RSE bietet: Fachkenntnisse in der Softwareentwicklung von hoher Qualität, ein Verständnis der Forschungsumgebung (möglicherweise als direkter Beitrag zur Forschung selbst) und die Fähigkeit, gut zu kommunizieren und hocheffektiv mit Forschenden zusammenzuarbeiten, die möglicherweise keinen Computerhintergrund haben, mit IT-versiertem Personal, das möglicherweise keinen Forschungshintergrund hat, und mit einer Führungsriege, die möglicherweise weder das eine noch das andere hat.

Nach der Definition der grundlegenden Kompetenzen betrachtet die TeachingRSE Kollaboration die Karrierestufen: Was sollten RSEs wissen und in welchem Detailgrad in welchen Karrierestufen? In Anbetracht der Tatsache, dass Forschende zunehmend erwarten, bestimmte technische Fähigkeiten selbst anwenden zu können, listet die TeachingRSE Kollaboration die RSE-Fähigkeiten auf, die Forschende erlernen sollten, um dies zu unterstützen.

Abschließend konzentriert sich die TeachingRSE Kollaboration auf die Tatsache, dass RSEs eine Reihe sehr unterschiedlicher Rollen haben können, die die Anwendung von Fachwissen in verwandten Bereichen beinhalten. Dazu gehören domänenspezifische RSEs, die neben technischen Fähigkeiten auch über Fachwissen im Forschungsbereich verfügen und dieses nutzen. Die Autoren beschreiben auch eine Reihe anderer technischer Spezialisierungen, darunter RSEs mit Fokus auf Daten, Infrastruktur, Hochleistungsrechnen und maschinellem Lernen.

Erfahre mehr, beteilige dich an der Diskussion

Ein Preprint wurde als zweites offizielles Positionspapier von de-RSE angenommen. Um die Diskussion über diese Arbeit weiterzuentwickeln, die Ergebnisse einem breiteren Publikum zugänglich zu machen und weitere Forschung in diesem Bereich zu durchzuführen, prüfen die Autoren Möglichkeiten zur Veröffentlichung in Fachzeitschriften für die endgültige Version des Papiers. Wenn Du TeachingRSE beitreten und an den Diskussionen und zukünftigen Arbeiten teilnehmen möchtest, nimm Kontakt mit uns auf. Unsere Kontaktdaten findest Du in unserem Github-Repository.

Update (2024-12-02)

Das Papier wurde inzwischen auf F1000 unter dem doi 10.12688/f1000research.157778.1 veröffentlicht und wartet dort auf Peer Reviews.

Dieser Blogbeitrag wurde unter der CC BY 4.0-Lizenz veröffentlicht. Die Weiterverbreitung ist erwünscht und sollte auf das Original (en) verweisen.

What defines an RSE?

So what, or who, exactly is an RSE? Ask three people for a definition of RSE, and aside from the common words “software” and “research”, you’re likely to get three different answers! This is because the space in which RSEs work, and the work that they might do, is not always straightforward to define, and so are their foundational competencies.

RSEs inhabit a previously “hidden space” - the wide gap between the work of researchers in an academic institution and the work of professional service staff whose roles can include everything from finance and student administration to managers of enterprise computing infrastructure. While the work of an RSE, of course, includes software development, RSEs at one end of the spectrum representing this hidden space will have roles that look very much like that of a researcher or academic. At the other end of the spectrum, the role of an RSE will look very much like that of a professional software engineer working in an industry environment. While an RSE undoubtedly writes software, their role is defined by a much wider range of skills, competencies and experience.

Generic definitions of an RSE can be helpful - a common such definition generally highlights that “an RSE is someone who applies specialist software development skills to support and undertake research tasks”. Nonetheless, while not incorrect, this definition masks a vast amount of complexity that warrants a greater discussion.

The foundational competencies of an RSE

Given this complicated and rapidly developing space, the authors of arXiv:2311.11457 (update: now for open peer-review at F1000Research), the teachingRSE collaboration, set out to better understand and to identify the foundational competencies of a Research Software Engineer.

The initial team of Heidi Seibold, Jeremy Cohen, Florian Goth, Philipp Schäfer and Samantha Wittke ran a workshop session, “Teaching and Learning Research Software Engineering”, at the German RSE conference in Paderborn, Germany in February 2023 (deRSE23) which initiated the discussions to understand what exactly the competencies of an RSE are. The community was integrated early-on through multiple workshops (at deRSE23 in Paderborn, un-deRSE23 in Jena, and deRSE24 in Würzburg). While largely based around a core group of members of the German RSE community - de-RSE - the collaboration also had international input to ensure representation of the wider international perspective in resulting outputs.

The length of time spent on this work and the very wide range of inputs and perspectives provided serves to highlight the inherent complexity in identifying the foundational competencies and responsibilities of a Research Software Engineer.

The paper

“Foundational Competencies and Responsibilities of a Research Software Engineer” works through the process of understanding what makes up the role of an RSE. It starts with some general background and terminology before highlighting what the collaboration worked out as the key values of an RSE - what RSEs are trying to achieve in their role and the values that underpin that work. The authors then look at the competencies themselves, identified through extensive discussion and debate about what RSEs do and how they do it. These skills are grouped into those that relate directly to software, those that are more research related and those that are communication focused. The collaboration identifies these three areas as the core of what an RSE provides - specialist, high-quality software engineering knowledge, an understanding of the research environment (potentially working as a direct contributor to research itself), and the ability to communicate well and work highly effectively with researchers who may not have a computational background, IT savvy personnel who may not have a research background, and managers who may have neither.

After defining the foundational competencies, the authors consider career levels - what should RSEs be expected to know and at what level of detail at different career stages? Recognising that researchers and academics increasingly expect to be able to apply some technical skills themselves the collaboration pins down the RSE skills that researchers and academics might want to learn to support this.

Finally, focusing on the fact that RSEs can have a range of very different roles, the authors look at RSE specialisations, highlighting a number of different roles that RSEs might hold that involve the application of specialist knowledge in related areas. This includes domain-specific RSEs, who have, and use, specialist research domain knowledge, in addition to technical skills. The authors also describe a number of other technical specialisations including data, infrastructure, High Performance Computing and Machine Learning-focused RSEs.

Find out more, join the discussion

A pre-print has been adopted as the second official position paper of de-RSE. As part of the goal to further develop the discussion on this work, to take the findings to a wider audience, and develop further research in this area, the authors are also exploring journal publication options for the final version of the paper. If you’d like to join the teachingRSE collaboration and participate in the discussions and future work, get in touch with find our contact details in our github repository.

Update (2024-12-02)

The paper is now published at F1000 under the doi 10.12688/f1000research.157778.1 veröffentlicht and is awaiting peer review.

This blog post is published under the CC BY 4.0 license. Re-posts are encouraged and should link back to the original.

Der Base4NFDI Antrag „nfdi.software“ wurde für die Initialisierungsphase bewilligt.

In der Initialisierungsphase wird innerhalb eines Jahres ab Herbst 2024 prototypisch ein dynamischer Marktplatz für Forschungssoftware konzipiert, implementiert und getestet. Mit diesem zentralen Einstiegsportal sollen die in der NFDI verfügbaren Forschungsdaten und ihre Erschließung durch Research Software zugänglich gemacht werden. Die beteiligten Projektpartner bringen hierfür existierende Lösungen aus verschiedenen Bereichen ein, z.B. das Research Software Directory, bio.tools, Betty´s Research Software Engine und physics.tools. Diese werden durch die gemeinsame Arbeit in nfdi.software in einer föderierten Dateninfrastruktur verknüpft und aufeinander abgestimmt. nfdi.software adressiert damit nicht nur die Ziele der NFDI sondern auch viele der Ziele der deutschen und internationalen RSE Community. In der Initialisierungsphase wird auf Basis iterativer Prototypversionen ein gemeinsames Vorgehen und ein intensiver Austausch in der NFDI gefördert, um Standards zu etablieren und weiterzuentwickeln. Aufeinander abgestimmte Metadaten zu Forschungssoftware und Forschungsdaten und eine daran anknüpfende Vernetzung verschiedener Dienste werden im Kontext des angestrebten Basisdienstes gemeinschaftlich weiter vorangebracht

Mehr Informationen finden sich auf der Base4NFDI Homepage.