Digital resources in the Social Sciences and Humanities OpenEdition Our platforms OpenEdition Books OpenEdition Journals Hypotheses Calenda Libraries OpenEdition Freemium Follow us

Zweiter Research Software Engineer Workshop an der TU Darmstadt – eine erfolgreiche Fortsetzung

Wie gelingt gutes Projektmanagement in der Forschungssoftwareentwicklung – insbesondere in kleinen, interdisziplinären Teams? Vom 04. bis 05. Dezember waren wir – Patrick Jentsch (Technischer Koordinator der Fakultät für Geschichtswissenschaft, Philosophie und Theologie und Research Software Engineer im Arbeitsbereich Digital History) und ich, Inga Kirschnick (wissenschaftliche Mitarbeiterin an der Universität Bielefeld: Research Software Engineer im Teilprojekt INF des SFB 1288 und dem Arbeitsbereich Digital History) – zu Gast beim zweiten Research Software Engineer Workshop an der TU Darmstadt und haben Ansätze in der Softwareentwicklung in den Digital Humanities verglichen und gemeinsame Herausforderungen sichtbar gemacht. Der Titel <rse-workshop version=”2″/> verdeutlicht unser Vorhaben: eine nahtlose Fortsetzung unseres produktiven Treffens im April 2025.

Der Workshop wurde vom Fachgebiet Digital Philology, Neuere deutsche Literaturwissenschaft an der Technischen Universität Darmstadt (Prof. Dr. Evelyn Gius) ausgerichtet und von Malte Meister (Technischer Mitarbeiter an der Technischen Universität Darmstadt: Research Software Engineer bei Prof. Dr. Evelyn Gius) organisiert. Vielen Dank für euer Engagement! Wir haben uns sehr wohl gefühlt.

Malte Meister, Patrick Jentsch, Inga Kirschnick und Jonas Widmer (v. l. n. r.), Foto: Mari Akazawa

Insgesamt haben vier Research Software Engineers (RSEs) aus Darmstadt, Bern und Bielefeld teilgenommen: Malte Meister, Jonas Widmer, Patrick Jentsch und ich, Inga Kirschnick.

Auch dieses Mal hat der Workshop Raum für inhaltlichen Austausch und technische Diskussionen, für Erfahrungsberichte aus der täglichen Arbeit sowie bereichernde persönliche Gespräche bei einem Getränk auf dem Darmstädter Weihnachtsmarkt geboten. Überraschend war vor allem, wie ähnlich die Probleme in ganz unterschiedlichen Projekten sind – und wie verwandt unsere Umgangsstrategien und Wünsche.

Projektmanagement im (Research) Software Engineering

Unsere ersten Workshop-Panels standen ganz im Zeichen unseres Hauptthemas: Projektmanagement als (Research) Software Engineer.

Als Research Software Engineer in den Digital Humanities zu arbeiten, bedeutet, sich vielschichtigen Aufgaben zu stellen. Wir sind oft gleichzeitig Entwickler*innen, Administrator*innen, (technische) Projektmanager*innen, Datenexpert*innen und Vermittler*innen. Gerade dieser Rollenmix macht die Arbeit spannend, aber auch anspruchsvoll. Unsere Panels griffen diese Komplexität auf und machten sichtbar, wie unterschiedlich Projektmanagement-Methoden in verschiedenen Arbeitskontexten eingesetzt werden.

Einflussmöglichkeiten von Research Software Engineers (RSEs) – zwischen Verantwortung und Realität

Den Auftakt des zweiten rse-Workshops hat Jonas Widmer (Wissenschaftlicher Mitarbeiter an der Universität Bern: Research Software Engineer im Fachgebiet Digital Humanities bei Prof. Dr. Tobias Hodel) gemacht, der die strukturellen Probleme des Projektmanagements in den Digital Humanities in seiner Präsentation adressiert hat. In vielen DH-Projekten arbeiten kleine Teams oder Einzelpersonen, häufig ohne dedizierte Projektmanager*innen. Daraus ergeben sich, so Jonas Widmer, verschiedene Herausforderungen:

  • Wissen sei oft an einzelne Personen gebunden – der klassische Bus-Faktor.
  • Qualitätsstandards können nur eingehalten werden, wenn Daten konsistent strukturiert seien.
  • Research Software Engineers (RSEs) tragen häufig zu viel Verantwortung bei gleichzeitig begrenzten Stellen und Mitteln.
  • Im akademischen Alltag werden mit Blick auf RSEs Fortbildung, Vernetzung und technische Expertise manchmal unterschätzt.

Besonders deutlich wurde: RSEs sollten bereits in der Antragsphase beteiligt werden, um realistische Zeitpläne, technische Risiken und versteckte Aufgaben – wie Softwareupdates, Infrastrukturpflege oder Dokumentation – früh sichtbar zu machen.

Gemeinsam haben wir anschließend Strategien diskutiert, mit denen RSEs ihren Einfluss sinnvoll nutzen können. Darunter beispielsweise:

  • Templates zur Vereinheitlichung der Codebasis und Arbeitsabläufe.
  • Delegation statt Konzentration: Technisches Projektmanagement nicht einem einzelnen RSE überlassen, sondern den Umgang mit beispielsweise Git und Software-Planung mit mindestens einer weiteren Person besprechen können.
  • Realistische Planung durch transparente Kommunikation von Risiken (Zeit, Geld, Qualität).
  • Regelmäßige Überprüfung des Projektplans statt einer starren Anfangsplanung.
  • Austausch über Institutionsgrenzen hinweg, um voneinander zu lernen.

Diese Einsichten sind relevant für die Digital Humanities, in denen in vielen Projekten geisteswissenschaftliches Fachwissen mit technischen Workflows verbunden wird. Nur wenn beide Perspektiven zusammengeführt werden, können nachhaltig nutzbare Forschungsinfrastrukturen entstehen.

Praktiken im Vergleich – kurze Wege, klare Strukturen, kleine Tools

Im zweiten Panel haben alle Teilnehmenden ihre etablierten Team- und Projektmanagement-Praktiken vorgestellt. Dabei hat sich gezeigt, dass in unterschiedlichen Institutionen sehr verschiedene Methoden genutzt, aber ähnliche Ziele verfolgt werden, so etwa Strukturen schaffen, Wissensverlust vermeiden und kontinuierliche Kommunikation sicherstellen. Eine große Herausforderung dabei sei, dass es nicht das eine „perfekte“ Tool gibt und die bestehenden Tools zum einen meistens von uns RSEs administriert werden müssen – neben unseren eigentlichen Hauptaufgaben – und sich die Nutzung zum anderen meist verläuft.

In allen Teams gibt es regelmäßige Meetings und einen regelmäßigen Austausch über aktuelle Aufgaben und Projekte. Malte Meister stellte exemplarisch das Konzept der Weekly Standups vor, bei dem er und sein Team sich gegenseitig innerhalb von drei Minuten ein kurzes Update zu ihrer Arbeitswoche geben. In diesem gegenseitigen Update werden die folgenden Fragen beantwortet:

  • Was wurde geschafft?
  • Was steht an? Was blockiert?
  • Wie hoch ist das Stresslevel?

Dieses Konzept wurde von allen Teilnehmenden als sehr interessant und sinnvoll wahrgenommen.

Außerdem stellte Patrick Jentsch das selbst gehostete Tool „Open Project“ als zentrale Knowledge Base für den Arbeitsbereich Digital History an der Universität Bielefeld vor, das vor allem für die allgemeine Dokumentation als hilfreich erachtet wird.

Das gemeinsame Fazit des Panels war letztendlich, dass es nicht das eine „perfekte“ Tool und die eine Methode gibt: Vielmehr sollten so wenig Tools wie möglich, aber so viele wie nötig genutzt werden. Auch physische Medien, zum Beispiel ein Notizenboard vor Ort, um Projekte und Ideen zu ordnen und anzupinnen, sollten nicht unterschätzt werden und können häufig produktiver als digitale Tools sein.

Aber vor allem haben die Diskussionen gezeigt: der persönliche Austausch ist unverzichtbar. Dieser hilft sowohl dabei, unsichtbaren Stress und versteckte Aufgaben aufzudecken, als auch ein Bewusstsein füreinander zu schaffen. Wenn es der Rahmen zulässt und es erwünscht ist, gerne mit einer privaten Note, um beispielsweise von außen entstehende Blockaden besser nachvollziehen zu können.

Informationssicherheit und Datenschutz – eine wachsende Verantwortung

Der Schwerpunkt der Diskussionen im Rahmen des dritten Panels hat auf einem Thema gelegen, das für Software-Projekte immer wichtiger wird: Datensicherheit. Wir haben Fragen diskutiert wie beispielsweise:

  • Welche Daten fallen im Rahmen der Forschung und der Softwareentwicklungen an – und welcher Schutzbedarf geht mit ihnen einher?
  • Welche Anforderungen werden aus Perspektive der Universitäten an Infrastruktur, Verschlüsselung und Aufbewahrung gestellt?
  • Wie sollten wir mit „teilbaren Daten“ umgehen, die besonders sensibel sind, weil sie über Institutionen hinweg weitergegeben werden?
  • Wie können AGBs für Services im Forschungsbereich verfasst werden?

RSEs stehen bei der Beantwortung dieser Fragen oft zwischen technischen Anforderungen und rechtlichen Rahmenbedingungen. Wichtig war daher die Empfehlung, Expertise einzuholen (z. B. über Datenschutzbeauftragte oder Jurist*innen) und regelmäßige Schwachstellenscans durchzuführen. Veraltete Infrastruktur sollte nach Möglichkeit vermieden werden – eine Herausforderung, die besonders in historisch gewachsenen DH-Projekten sichtbar wird, bei denen die Verantwortung der Instandhaltung und Wartung mit den Jahren verschwimmt und deren Nutzbarkeit nicht immer gewährleistet bleibt.

CI/CD, Codequalität und Tools – wie wir Projekte technisch aufsetzen

Im vierten Panel haben wir uns über technische Standards ausgetauscht: Versionskontrolle, Tests, Dokumentation und Automatisierung. Interessant war dabei, wie unterschiedlich CI/CD-Pipelines eingesetzt werden – manche minimalistisch, andere stark automatisiert. Wir haben über Tools wie Dependabot, vorgestellt von Patrick Jentsch, aber auch Workflows rund um GitHub Actions oder GitKraken als Git-GUI für weniger erfahrene Nutzer*innen gesprochen.

Deutlich wurde, dass uns allen oftmals die Zeit fehlt, sich mit diesen Themen ausreichend zu befassen. Wir wünschen uns daher mehr zeitliche Ressourcen, um unsere Workflows zu verbessern und Tests und Dokumentationen zu schreiben. Im Austausch haben wir festgestellt, dass vor allem Tests und Dokumentation häufig in der Prioritätenliste hinten angestellt werden. Das greift unsere Problematik aus Panel 1 sehr gut wieder auf: Meistens sind Research Software Engineers einzelne Personen in einem interdisziplinären Team, die mit vielfältigen Aufgaben betraut werden. Um das Arbeitspensum stemmen zu können, rücken weniger dringende Aufgaben häufig in den Hintergrund. Das gibt jedoch spätestens dann einen Backlash, wenn ein RSE das Team verlässt und der Bus-Faktor eintritt, das heißt, dass das an die einzelne Person gebundene Wissen „verloren“ geht, oder eine neue Person ins Team kommt und sich eine Einarbeitung in die bestehende Software schwierig gestaltet.

Einblicke in den Entwicklungsalltag und Praxisbeispiele

In zwei weiteren Sessions haben wir uns unsere aktuellen Arbeitsprojekte vorgestellt und uns Zeit genommen, uns ausführlich auszutauschen. Hierbei haben wir die Projekte nicht nur oberflächlich besprochen, sondern auch gemeinsam in den Code geschaut und uns gegenseitiges Feedback gegeben bzw. eingeholt.

Malte Meister hat zuletzt daran gearbeitet, die Forschungssoftware CATMA zu einer Standalone-Applikation weiterzuentwickeln, die mit einem einzigen Docker Container lauffähig ist. Dabei sei es vor allem darum gegangen, die Installation zu vereinfachen, um CATMA für Nutzer*innen zugänglicher zu machen. Wir diskutierten verschiedene Ansätze zur Containerisierung und sprachen über Best Practices im Umgang mit Docker und der Bereitstellung von Software in Forschungsumgebungen.

Jonas Widmer erzählte vom aktuellen Umstieg von GitHub Actions zu n8n, einem Workflow-Automatisierungstool, das mehr Flexibilität biete. n8n ermögliche komplexe Workflows zu erstellen und zu verwalten, was besonders in Projekten mit vielfältigen Datenquellen und Verarbeitungsschritten von Vorteil sei.

Patrick Jentsch gab einen realistischen Einblick in die Herausforderungen gewachsener Systeme am Beispiel von nopaque, einer Software zur Analyse historischer Daten. Er berichtete über stark veraltete Komponenten (z. B. alte Python-Bibliotheken), unklare Dokumentation, fehlende Tests und enge Zeitplanung bei gleichzeitig hohen Anforderungen. Trotz dieser Herausforderungen habe sich gezeigt, dass gute Containerisierung die Software skalierbar und robust gemacht habe. Der geplante Modernisierungsfahrplan umfasse die Vereinheitlichung des Codes, das Auflösen problematischer Paketabhängigkeiten und mehr Automatisierung.

Ich selbst stellte meine aktuelle Arbeit am Projekt rund um das Familienarchiv Ermelinghoff vor. Im Rahmen des ersten Treffens zeigte ich bereits einen ersten Entwurf und die grobe Idee rund um das Projekt. Nun konnte ich eine funktionierende Alpha-Version präsentieren und mit den anderen Research Software Engineers über meinen Code und Herausforderungen und Möglichkeiten sprechen.

Vernetzungs-Talk: Wohin geht die Reise?

Zum Abschluss des Workshops diskutierten wir zukünftige Formate. Geplant ist ein Hackathon im kommenden Jahr – möglicherweise mit gemeinsamer Arbeit an einem GitHub-Template für DH-Projekte. Ziel ist es, die entstehende RSE-Community weiter auszubauen und neue Kolleg*innen einzubinden, ohne den Umfang zu sehr auszureizen. So waren wir uns einig, dass sich eine kleine Runde wie diese als sehr fruchtbar und effektiv herausgestellt hat.

Gestaltung: Jil Dirschauer

Fazit und Ausblick

Der <rse-workshop version=”2″/> hat erneut gezeigt, wie wertvoll der Austausch über Institutionsgrenzen hinweg für die Forschungssoftwareentwicklung ist. Projektmanagement ist für Research Software Engineers nicht nur eine organisatorische Aufgabe, sondern ein zentraler Bestandteil der täglichen Arbeit – vor allem in den Digital Humanities, wo technische Innovation und geisteswissenschaftliche Expertise eng miteinander verflochten sind.

Deutlich wurde unter anderem, dass viele Herausforderungen strukturell sind und kleine Teams ebenso wie große Arbeitsbereiche betreffen, dass Austausch ein entscheidender Faktor ist, um Probleme sichtbar zu machen und Lösungen zu entwickeln, und dassTools eine Rolle spielen, aber klare Kommunikation, gemeinsame Verantwortung und realistische Planung entscheidender sind.

Mit dem geplanten Hackathon und weiteren Treffen wächst eine Community, die langfristig dazu beitragen kann, Forschungssoftware nachhaltiger, professioneller und sichtbarer zu gestalten. Aber vor allem hilft die Etablierung eines regelmäßigen Treffens dabei, in einer Gemeinschaft von Personen mit ähnlichen Problemen und Herausforderungen ein Bewusstsein für die eigene Arbeit zu bekommen und eigene Baustellen unter Gleichgesinnten zu besprechen und neue Inspiration zu gewinnen. Am besten zwischen den offiziellen Workshop-Panels in geselliger Runde beim Abendessen, Kaffee trinken und dem bereits erwähnten Getränk auf dem Weihnachtsmarkt. Und das wichtigste Fazit war: Wir alle machen unsere Arbeit enorm gerne und trotz verschiedener Verbesserungsmöglichkeiten bietet die Arbeit als Research Software Engineer die einzigartige Möglichkeit, sowohl logisch-technisches als auch kreatives Denken mit kritischer, wissenschaftlicher Reflexion zu verbinden. Wir freuen uns auf die nächste Ausgabe – vielleicht <rse-workshop version=”3″/>?


OpenEdition schlägt Ihnen vor, diesen Beitrag wie folgt zu zitieren:
Inga Kirschnick (6. Februar 2026). Zweiter Research Software Engineer Workshop an der TU Darmstadt – eine erfolgreiche Fortsetzung. Digital History Bielefeld. Abgerufen am 6. März 2026 von https://doi.org/10.58079/15n1t


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

This site uses Akismet to reduce spam. Learn how your comment data is processed.