5. Expert:innenforum „Nachhaltige Softwareentwicklung in NFDI4Culture”: Institutionelle Professionalisierung – Herausforderungen und Perspektiven

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.