verfasst von: Aleksander Marcic (ORCID), Daniel Jettka (ORCID), Anne Ferger (ORCID)

Einführung

Am 01. Dezember 2023 kam das Expert:innenforum „Nachhaltige Softwareentwicklung in NFDI4Culture“ zu seinem mittlerweile sechsten halbjährlichen Treffen zusammen. Anlässlich der fortgeschrittenen Anzahl bereits absolvierter Forumstreffen war es an der Zeit, ein Resümee zum bisherigen Verlauf des Forums zu ziehen, aber auch einen Blick in die Zukunft zu richten mit dem für diesen Termin ausgewählten Fokusthema „Ökologische Nachhaltigkeit von Softwareentwicklung und -gebrauch“ .

In der kurzen Feedbackrunde zu Beginn des Forums zeigten sich die Expert:innen im Wesentlichen einig darüber, dass das Forum thematisch und organisatorisch sehr gut aufgestellt ist und lediglich geringer Anpassungsbedarf hinsichtlich der eingesetzten Kommunikationsmittel für die Organisation und den Austausch zwischen den Forumsterminen besteht. Entsprechend wird die Kommunikation via E-Mail wieder eine stärkere Rolle einnehmen, und der eigens für das Forum eingerichtete Chat-Kanal voraussichtlich sehr viel weniger bis gar nicht mehr genutzt werden.

Etwas weniger eindeutig als das Feedback zum Gesamtverlauf des Forums sind jedoch, wie zu erwarten, die Antworten bzw. Überlegungen auf die Fragen ausgefallen, die sich im Zusammenhang mit ökologischer Nachhaltigkeit in der Softwareentwicklung stellen, wie etwa: Welches Wissen ist notwendig, um Softwareentwicklung möglichst ökologisch nachhaltig zu gestalten? Wo finden sich ökologische Einspar- und/oder Optimierungspotentiale? Was sind konkrete Maßnahmen, um im Bereich der Softwareentwicklung ökologisch nachhaltig(er) zu handeln?

Zur Einführung in das Schwerpunktthema hatten sich Torsten Roeder und Anne Baillot als Vertreter:innen der DHd-AG Greening DH im Vorfeld bereit erklärt, eine Einführung und Einordnung in den aktuellen Stand von Initiativen und Bemühungen zu geben. Für die guten Hintergründe und Denkanstöße aus ihrer Präsentation Von der Initiative bis zur Praxis: Die DHd-AG Greening DH und das DHCC Toolkit ist ihnen das Forum überaus dankbar.

Die Ergebnisse der anschließenden Diskussion der Expert:innenrunde, die sich aus Vertreter:innen von Rechenzentren, Forschungsförderern, Forschungsinstitutionen und -projekten zusammensetzt, werden in den folgenden thematisch gegliederten Abschnitten wiedergegeben.

Diskussion zu ökologischer Nachhaltigkeit

Nach der Diskussion von Möglichkeiten zur Verbesserung der ökologischen Nachhaltigkeit bei Forschungsprojekten und -software in der Vorstellung der Aktivitäten in der AG Greening DH wurde besonders die Rolle von Forschungsförderern betont. Die DFG-Empfehlungen sehen ab 2024 zunehmend vor, dass Antragstellende Überlegungen zur ökologischen Nachhaltigkeit im Forschungsprozess in den Zusatzinformationen zum Projektantrag darlegen. Und auch im konkreten Bereich Forschungssoftware wird Nachhaltigkeit zukünftig Teil einer Leitlinie sein. Die Auswirkung dieser Empfehlungen auf die Forschungsförderung hängt – wie schon bei den Empfehlungen zur Gleichstellung und zum Forschungsdatenmanagement – vom Stellenwert ab, den Gutachter:innen dem Thema beimessen. Die bisherigen Erfahrungen mit diesem Vorgehen haben gezeigt, dass auf diesem Weg Veränderungen relativ schnell in den wissenschaftlichen Betrieb Eingang finden. Über die allgemeinen Empfehlungen und einen Leitfragenkatalog hinaus sind von Seiten der DFG allerdings keine konkrete Vorgaben geplant, wie die ökologische Nachhaltigkeit von Projekten und Software durch die Gutachter:innen zu beurteilen wäre. Zum einen könnte das daran liegen, dass sich für die Breite der Fachbereiche gemeinsame verbindliche Kriterien nicht ermitteln lassen, zum anderen aber insofern im Sinne der Wissenschaftsfreiheit die Beurteilung von Forschung eben durch die Wissenschaftscommunity selbst, d.h. durch die jeweiligen Gutachter:innen, erfolgt.

Über die Hoffnung und Annahme hinaus, dass in absehbarer Zeit die ökologische Nachhaltigkeit Gegenstand des Beantragungs- und Begutachtungsprozesses wird, kann aber auch gezielt die Sichtbarkeit von Projekten und Software verbessert werden, welche bereits jetzt in ökologische Nachhaltigkeit investieren. Diesbezüglich wurde vorgeschlagen kurzfristig spezielle Auszeichnungen (z. B. durch Zertifikate) für nachhaltigkeitsorientierte Projekte und Software zu entwickeln und zu etablieren. Auch hier wurde zu bedenken gegeben, dass die Einigung auf konkrete Kriterien sehr komplex wird, sobald man eine Breite von Fällen abdecken will. Das führt dann oft dazu, dass Vorgaben und Kriterien, wenn sie festgelegt werden, vage und abstrakt wirken und wenig konkrete Orientierung bieten.

Eine wichtige Dimension ist das Messen von konkreten ökologischen Auswirkungen bestimmter Maßnahmen oder Softwareinstanzen, getreu dem Motto: You cannot improve what you cannot measure. Problematisch ist es auch hier sich auf verbindliche Messkriterien zu einigen. Eine Zusammenstellung von Empfehlungen für die Messung wird vom DH CC Toolkit bereitgestellt.

Ein weiteres wichtiges Einflusskriterium ist die ökologische Nachhaltigkeit von Rechenzentren, an denen Forschungssoftware betrieben wird. Dabei lassen sich unter anderem durch Entscheidungen zu der zugrundeliegenden Hardware (Server, Kühlung, etc.) starke Verbesserungen der Energieeffizienz erzielen. Mit dem Blauen Engel für Rechenzentren gibt es eine Möglichkeit die Nachhaltigkeit von Rechenzentren zertifizieren zu lassen. Dass Investitionen in die Nachhaltigkeit durch dieses Zertifikat sichtbar werden, kann allerdings von Maßnahmen abhängen, die über längere Zeiträume umgesetzt werden müssen (z. B. größere Baumaßnahmen) und Effekte können sich entsprechend verzögern.

Es wurde aber auch darauf hingewiesen, dass die Optimierung von Software hinsichtlich ökologischer Nachhaltigkeit selbst Kosten verursacht, die teilweise höher sein können, als die Optimierungsgewinne. Hier gilt es maßvoll vorzugehen, was wiederum eine durch Erfahrung und grundlegende Kenntnisse gut fundierte Orientierung voraussetzt.

Deshalb muss vorhandenes und noch zu erarbeitendes Wissen um die ökologische Dimension der Softwareentwicklung in Beratungsprozesse (z. B. zu Projektplanung und -beantragung), Lehre und Ausbildung von Research Software Engineers integriert werden.

Als eine konkrete Maßnahme wurde die Möglichkeit genannt, Inhalte von statischen Websites als reines HTML zu archivieren und damit im technischen Sinne nachhaltiger zu machen. Hieraus ergeben sich gleichzeitig Potentiale für die ökologische Nachhaltigkeit durch die Verwendung statischer Inhalte. Weniger Javascript bedeutet weniger Speicher- und Energiebedarf auf Endnutzergeräten. Außerdem laden statisch konzipierte Seiten auch nicht permanent Daten von verschiedenen Schnittstellen/Datenbanken nach, um für jeden Nutzer eine individuelle Ansicht zu generieren.

Fazit und Ausblick

Mit der Auswahl des Schwerpunktthemas “Ökologische Nachhaltigkeit von Softwareentwicklung und -gebrauch” hat sich das Expert:innenforum der Herausforderung gestellt, ein sowohl technisch als auch teils emotional sehr komplexes Thema zu behandeln. In der guten und offenen Diskussion wurde deutlich, dass eindeutig Handlungsbedarf besteht, jedoch konnte erwartungsgemäß nicht abschließend beantwortet werden, in welchen Bereichen und wie genau sinnvolle Handlungen und Veränderungen herbeigeführt werden können, da Softwareentwicklung nur einen kleinen Teil eines überaus komplexen Systems ausmacht, das mehr ökologischer Nachhaltigkeit bedarf.

Dennoch konnten neben der Bewusstmachung einiger Problembereiche und Zusammenhänge, die für sich genommen bereits als Fortschritt angesehen kann, auch ein paar Anhaltspunkte gefunden werden, wie das Thema ökologische Nachhaltigkeit vorangebracht werden kann. Hierzu gehört ganz allgemein die Einbeziehung des Themenkomplexes in Beratungsprozesse und in die Lehre. Des Weiteren wurde das Ziel formuliert weitergehend mit der DHd-AG Greening DH zu kooperieren und die Reflexion ökologischer Nachhaltigkeit in die nächste Version des Leitfaden für die nachhaltige Entwicklung und Nutzung von Forschungssoftware aufzunehmen.

verfasst von: Aleksander Marcic (ORCID), Daniel Jettka (ORCID), Lisa Dieckmann (ORCID), Daniel Röwenstrunk (ORCID), Anne Ferger (ORCID), Franziska Fritzsche (ORCID)

Einführung

Im Fokus des fünften Treffens des Expert:innenforums „Nachhaltige Softwareentwicklung in NFDI4Culture” am 25. April 2023 standen institutionelle Aspekte der Professionalisierung von Softwareentwicklung in der Wissenschaft. Die Diskussuion wurde angeregt durch Impulse von Vertreter:innen von Rechen-, Daten- und DH-Kompetenzzentren, von Förderern und aus der Lehre.

Die Professionalisierung der Softwareentwicklung in der Wissenschaft steht vor der besonderen Herausforderung, dass Software größtenteils im Rahmen von Forschungsprojekten entwickelt wird, deren Finanzierung mit dem Projektende ausläuft. Auch wenn diese Problematik nicht unmittelbar auflösbar ist, lassen sich Schlüsse und Lehren daraus ziehen, wie die verschiedenen institutionellen Akteure, z. B. Rechenzentren, Institute, DH-Kompezenzzentren, Förderer und Infrastrukturprojekte mit dieser prekären Situation umgehen können.

Die Rolle von Zentren (Rechenzentren, Daten- und DH-Kompetenzzentren)

Da Softwareentwicklung in der Wissenschaft größtenteils in Projektkontexten stattfindet und für Mitarbeiter:innen nicht immer eine Anschlussfinanzierung möglich ist, geht in Projektlaufzeiten aufgebaute Expertise immer wieder verloren. Die Sicherstellung von adäquatem Wissenstransfer durch stabilisierende Elemente ist daher eine zentrale Herausforderung. Aus diesem Grund werden Institutionen benötigt, die für die Softwareentwicklung über Projektlaufzeiten hinaus Wissen transferieren und Infrastruktur kontinuieren. In der Praxis bedeutet dies:

• Verschiedene Institutionen (z. B. Rechenzentren, Bibliotheken, Daten- und DH-Kompetenzzentren, Institute aus Fachdisziplinen) sollten zielgerichtet zusammenarbeiten.
• Wenn diese Aufgabe auf verschiedene kleinere Institutionen verteilt ist, können Vorteile genutzt werden, etwa eine höhere Flexibilität und Spezialisierung. Gleichzeitig besteht die Gefahr der Zersplitterung von Wissen durch verteilte Strukturen.
• Für sehr kleine Teams kann es schwer sein, gleichzeitig alte Infrastruktur in Stand zu halten (z. B. um alte Projekte weiter zu betreiben) und neue Technologien zu evaluieren und damit zu experimentieren.

Ohne feste Mittel für langfristige Entwickler:innenstellen besteht eine weitere besondere Herausforderung in der Aus- und Weiterbildung von RSEs an DH-Kompetenz- und Rechenzentren mit dem Ziel eines langfristigen Aufbaus von domänenspezifischer und technischer Expertise. Aus diesem Grund sind im Rahmen des Forums verschiedene Beispiele aus der Praxis vorgestellt worden, wie mit dieser Herausforderung umgegangen werden kann:

• An Zentren kann RSEs ermöglicht werden, sich weiterzubilden und erworbene Kenntnisse ins Team zurückzuspielen.
• Für Systemadministration und -integration können Ausbildungstellen angeboten und Auszubildende in Projektarbeit einbezogen werden.

Auch wenn sehr häufig noch keine direkte Finanzierung fester Entwickler:innenstellen von übergeordneten Institutionen zur Verfügung gestellt wird, können u.U. verschiedene Mittel gebündelt oder (im besten Fall längerfristige) Kooperationen eingegangen werden. Konkret genannt wurden:

• (Aushandlung der konkreten Verwendung von) Overhead-Mitteln, d .h. flexiblen Mitteln, die bei Projektförderung von Mittelgeber:innen zur Verfügung gestellt werden
• Pooling von Mittelanteilen aus verschiedenen Projekten für zentrale Stellen (nur mit vielen Projekten machbar)
• Langzeitkooperationen (z. B. mit Akademien) ermöglichen wenigstens mit einem kleinen Teil der Mittel längerfristig planen zu können

Die Rolle von Software in Forschung und wissenschaftlicher Ausbildung

Eine weitere Herausforderung für die Professionalisierung der wissenschaftlichen Softwareentwicklung ist, dass Software in den meisten Wissenschaften zwar ein fester Bestandteil der Forschung, zugleich in vielen Fächern aber kein fester Bestandteil der wissenschaftlichen Ausbildung ist.

Vorbehalte gegenüber Softwareentwicklung als genuinem Bestandteil eines Faches, scheint in vielen Fächern der Geisteswissenschaften vorhanden zu sein. Das hat Konsequenzen für Ausbildungsangebote im Rahmen der jeweiligen Studiengänge sowie für die Anerkennung von Softwareentwicklung als wissenschaftlichem Beitrag. Problematisch ist hierbei z. B. insbesondere:

• Studierende können ihre erworbenen Kompetenzen nicht ohne Weiteres als Studienleistung anerkennen lassen, was dazu führen kann, dass Angebote trotz bestehendem Interesse seltener wahrgenommen werden.
• Es herrscht Ungewissheit, ob Kompetenzen und Code-Beiträge für die weitere wissenschaftliche Qualifikation in den Fächern angerechnet werden.

Der Gruppe gut vernetzter Wissenschaftler:innen im Bereich der Digital Humanities und RSEs stehen zahlreiche Fachwissenschaftler:innen gegenüber, die zwar digitale Methoden und Werkzeuge anwenden, Scripts schreiben usw., aber am Austausch (und z. B. auch an Standardisierungsprozessen) der Community nicht direkt beteiligt sind. Hieraus ergibt sich:

• Probleme der Nachhaltigkeit von Softwarelösungen, etc. werden häufig v. a. im Kreis sachkundiger Expert:innen diskutiert, so dass die Problemhorizonte jeneits dieser Kreise (z.B. in den einzelnen Fächern) weitgehend unbekannt sind und gegebenenfalls erst vermittelt werden müssen.
• Interessierte, aber nicht bereits technisch sachkundige Wissenschaftler:innen können durch diese Diskrepanz von anspruchsvollen Lösungsansätzen abgeschreckt und überfordert werden.
• Ob einzelne Lösungsansätze auch im Arbeitsalltag der Fachwissenschaftler:innen plausibel sind und akzeptiert werden, muss zusätzlich ermittelt [bzw. berücksichtigt] werden.
• Zudem ergibt sich weiterhin die Frage, wie weiter und besser mit dieser Kluft umzugehen ist.

Nicht selten fallen Defizite bei der Planung und Umsetzung digitaler Komponenten in Forschungsprojekten erst auf, wenn zum Ende und mit Blick auf die Nachhaltung von Ergebnissen Kontakt z. B. mit Datenzentren aufgenommen wird. Datenzentren (u. a.) haben derzeit in der Regel nicht die Kapazitäten eine enge Begleitung in der Softwareentwicklung zu leisten oder im Nachhinein nicht nachhaltig entwickelte Software in nachhaltige zu verwandeln. In diesem Zusammenhang ist zu beachten:

• Es ist manchmal nicht vermeidbar Software im Nachhinein anzupassen, bspw. wegen Versäumnissen am Projektanfang – etwa (a) Umgang mit personenbezogenen Daten, (b) rechtlichen Beschränkungen externer Partner.
• Die Erwartung einer Standardisierung von technischen Stacks ist zwar nachvollziehbar, wird jedoch als wenig aussichtsreich erachtet.
• In Beratungsangeboten und Leitfäden, etc. können Best Practices und Standards für die Softwareentwicklung kommuniziert und diskutiert werden
• Register (wie die NFDI4Culture Software Registry u. ä.) etc. können indirekt zu einer gewissen Vereinheitlichung beitragen

In Bezug auf bestehende Förderstrukturen und -angebote ist festzustellen, dass viele der Probleme im Kontext der wissenschaftlichen Softwareentwicklung den Projektförderern zwar bekannt sind, eine notwendige Anpassung der Förderung aktuell dennoch vor einer Reihe von zentralen Herausforderungen steht:

• Es braucht eine Definition von Forschungssoftware, die vom Code Block im Jupyter Notebook bis zur gerätespezifischen medizinischen Software alles umfasst.
• Eine Erhöhung der Fördergelder kann den ungewollten Effekt nach sich ziehen, dass die Kosten für Entwicklung steigen.
• Es müssen Förderprogramme entwickelt werden, in denen die Bedarfe der Geisteswissenschaften ebensosehr Entsprechung finden, wie die in Natur- und Ingenieurswissenschaften, Medizin, etc.
• Eine Übersicht über vorhandene Software ist nötig, um Förderbedarfe besser beurteilen zu können (in diesem und anderen Zusammenhängen ist die Bedeutung von Softwarekatalogen und -registern für Förderung und Studiengangsaufbau mehrfach hervorgehoben worden).

Die Rolle von Software in der Forschung ist vielfältig und für die Förderung, die Ansprüche an Nachhaltigkeit (z. B. hinsichtlich Entwicklungsprozess, Dokumentation usw.) stellt, ist es hilfreich, verschiedene Rollen zu unterscheiden. Generell kann Software einerseits als Mittel zur Beantwortung von Forschungsfragen eingesetzt werden, andererseits aber auch selber Gegenstand von Forschung sein. Und während Software häufig im Hinblick auf ganz spezifische Forschungsfragen (im Rahmen von Forschungsprojekten) entwickelt wird, muss auch die Entwicklung allgemeinerer Software bei Finanzierung, Förderung, Nachhaltigkeitsüberlegungen etc.  berücksichtigt werden.

• Für experimentelle Software muss der Betrieb meist nicht Jahre über Projektende hinaus gesichert werden
• Für sehr spezielle Software müssen Nachhaltigkeitsstrategien, Dokumentation etc. auf Nachvollziehbarkeit, für Software mit erkanntem Verallgemeinerungspotenzial auf Nachnutzbarkeit und Weiterentwicklung ausgerichtet sein.
• Aufbau und Management von Communities sind inhärente Aufgaben bei der Entwicklung von (allgemeinerer) Software.
• Förderprogramme zur Verallgemeinerung projektspezifischer Software werden bereits entwickelt und getestet, sind aber noch nicht fest etablierter Bestandteil der Förderlandschaft.
• Bedarfe sowohl der Fach- als auch der Entwickler:innen-Communities müssen sichtbar gemacht werden.