Unser Panel auf dem GI-Festival 2025, moderiert von Florian Mannseicher, machte eindrucksvoll deutlich, dass Deutschland an einem Wendepunkt in der Weiterentwicklung seines Forschungssoftwareökosystems steht.

Es gibt viel Expertise, Energie und Motivation – doch gleichzeitig fehlen Struktur, Kompetenzen und eine nationale Koordination. Damit Forschungssoftware künftig denselben Stellenwert einnimmt wie Forschungsdaten, braucht es gemeinsame Rahmenbedingungen und langfristige Strategien.

1. Open ist Konsens – aber noch kein Standard

In der Diskussion herrschte große Einigkeit: Offenheit („so offen wie möglich“) gilt als richtiger Weg. Trotzdem ist Open Source Software im Forschungsalltag noch kein etablierter Standard. Ein Grund dafür ist Unsicherheit im Umgang mit Lizenzen – viele Forschende befürchten Fehler oder rechtliche Risiken. Auch lässt sich Software nicht immer bedenkenlos offen bereitstellen, etwa bei Sicherheitsbedenken oder zur Verhinderung missbräuchlicher Nutzung. Zudem führt die häufige Gleichsetzung von FAIR und Open Source zu Missverständnissen: FAIR bedeutet nicht automatisch offen, sondern beschreibt Mindestanforderungen an Auffindbarkeit, Zugänglichkeit und Wiederverwendbarkeit.

Kurz gesagt: Offenheit bleibt das Ziel, FAIR der Mindeststandard – doch ohne institutionelle Unterstützung und klare Vorgaben ist eine breite Umsetzung schwierig.

2. Nachhaltigkeit als blinder Fleck

Ein weiterer zentraler Punkt: Forschungssoftware entsteht überwiegend in zeitlich befristeten Projekten – und verschwindet danach häufig in der Wartungslücke. Die Folgen sind bekannt: Ergebnisse werden schlechter nachvollziehbar, Software altert schnell, Forschende investieren viel Zeit ohne Anerkennung und Einrichtungen sind nicht für eine dauerhafte Wartung aufgestellt.

Das Panel sprach sich daher für langfristige Maßnahmen aus – etwa Software-Lifetime-Pläne analog zu Forschungsdaten, dauerhafte RSE-Stellen oder klar definierte Kriterien, die Software als wissenschaftliche Leistung sichtbar und bewertbar machen. Software braucht Pflege – und Pflege braucht langfristig gedachte Strukturen.

3. Infrastruktur – mehr als GitHub

Deutlich wurde auch, dass GitHub zwar praktisch, aber als US-Konzern keine nachhaltige Heimstatt für nationale Forschungsgüter ist. Stattdessen braucht es eigenständige, langfristig sichere Infrastrukturen, beispielsweise institutionelle oder nationale GitLab-Instanzen sowie europäische Repositories. Eine Anbindung an Software Heritage könnte helfen, Software als Teil des wissenschaftlichen Kulturerbes langfristig zu archivieren. Ebenso wurde eine stärkere Verzahnung mit bestehenden Initiativen in NFDI und EOSC gefordert.

4. Wissenschaftler*innen in frühen Karrierephasen tragen die Last

Besonders junge Forschende entwickeln und pflegen heute einen Großteil wissenschaftlicher Software. Neben Forschung müssen sie sich jedoch auch um Dokumentation, Lizenzen, Reviews und langfristige Wartung kümmern – Aufgaben, die eigentlich institutionell abgesichert sein könnten.

Das Panel war sich einig: Die Verantwortung liegt an der falschen Stelle. Ohne Beratung, technische Unterstützung und klare Zuständigkeiten bleibt Nachhaltigkeit mitunter Glückssache – und individuelle Motivation ersetzt kein System.

5. Momentum in der Politik – jetzt braucht es Struktur

Die politische Seite nimmt das Thema zunehmend wahr. Das BMFTR signalisierte klar, dass Forschungssoftware auf der Agenda steht, und die jüngst veröffentlichte ORT-Studie hat wichtigen Schwung ausgelöst. Jetzt gilt es, dieses Momentum strategisch zu nutzen.

Notwendig ist ein Zusammenspiel von Bottom-up-Initiativen aus der Community und Top-down-Rahmensetzung durch Politik. Deutschland kann dabei von Open Access und Open Data lernen: Frühe Strukturen beschleunigen Wandel.

A. Aufbau einer nationalen Forschungssoftwareinstitution – was jetzt passieren sollte

1. Eine bundesweite „Richtlinie Forschungssoftware“

Eine gemeinsame Richtlinie könnte Standardlizenzen empfehlen, die Rolle von GitHub und GitLab klären und Vorlagen für Software-Lifetime-Pläne erstellen. Universitäten und Forschungseinrichtungen müssten dann nicht bei Null beginnen, sondern könnten auf erprobte Standards zurückgreifen.

2. Forschungssoftware-Office als zentraler Hub

Statt alle Leistungen selbst aufzubauen, sollte ein Forschungssoftware-Office vor allem bestehende Initiativen sichtbar machen, vernetzen und zugänglich bündeln. Gemeinsam statt parallel, koordinierend statt duplizierend. Es fungiert als nationale Anlaufstelle – für Lizenz- und FAIR-Fragen, Code Reviews, Infrastrukturwahl, Trainings sowie für Vorlagen und Good Practices. Durch die Vernetzung lokaler RSE-Teams entsteht ein Ökosystem, das nicht fragmentiert, sondern gestärkt wird. Ziel ist eine zentrale Orientierung für Forschende – ein Hub, kein Ersatz bestehender Angebote.

3. Infrastruktur: nachhaltige Alternativen zu GitHub stärken

Empfohlen wurde eine Prüfung einer nationalen GitLab-Instanz sowie die verpflichtende Archivierung geförderter Software in Software Heritage. Die Zusammenarbeit mit NFDI und europäischen Plattformen wie EOSC könnte langfristige digitale Souveränität sichern.

4. Dauerstellen und Rollenprofile schaffen

Projektbefristungen gelten als eines der größten Hindernisse für nachhaltige Softwarepflege. Forschung braucht Kontinuität – und Software erst recht. Rollen wie RSE, Maintainer oder Software Librarian müssen klar definiert und institutionell verankert werden. Beispiele aus der Helmholtz Gemeinschaft, dem Vereinigten Königreich und den Niederlanden zeigen, dass Verstetigung möglich ist – und Wirkung zeigt.

5. Forschungspolitischen Prozess anstoßen

Als nächste Schritte könnte eine Roadmap 2025–2035 entwickelt, eine nationale Stakeholderkonferenz organisiert und ein Policy Paper zur Notwendigkeit einer Forschungssoftwareinstitution formuliert werden.

B. Welche Strukturen bräuchte eine solche Institution?

Denkbar wäre ein hybrides Modell aus Community-Engagement und staatlicher Unterstützung – ähnlich zur NFDI, jedoch mit stärkerer operativer Komponente. Eine solche Institution könnte auf drei Säulen aufbauen: Beratung & Kompetenzaufbau, Infrastruktur & Dienste sowie Qualitätssicherung & Nachhaltigkeit durch Reviews, Archivierung und Lifetime-Pläne.

Wichtig wäre zudem die aktive Integration bestehender Akteure wie de-RSE, GI, Helmholtz, NFDI-Konsortien sowie internationaler Partner wie SSI und NL eScience Center. Zentral bleibt die Frage der dauerhaften Finanzierung, sowie eine direkte Schnittstelle zum BMFTR oder anderen relevanten Ministerien, um politische Prozesse langfristig zu gestalten.

Fazit

Das Panel zeigt: Deutschland ist bereit für eine nationale Struktur für Forschungssoftware.
FutuRSI kann ein Motor dieses Prozesses sein – indem Standards etabliert, Infrastrukturkonzepte entwickelt, die Community mit politischen Akteur*innen verbunden und langfristige Strategien formuliert werden.

Die Community ist motiviert, die Politik zeigt Offenheit, und der Bedarf ist groß.
Jetzt ist der richtige Moment, die Grundlagen für eine Forschungssoftwareinstitution zu legen – modern, wirkungsorientiert und nah an den Bedürfnissen der Forschenden.