Vom 30. Mai - 2. Juni 2019 fand im ZKM und in der Hochschule für Gestaltung (HfG) die GPN19 statt. Dort traf Sebastian auf Carina Haupt, die schon auf der GPN18 von der öffentlich finanzierten Wissenschaft forderte: Publish Your Research!

Carina Haupt studierte Informatik an der Hochschule Bonn-Rhein-Sieg. Aktuell befasst Sie sich wissenschaftlich mit Forschungssoftware, die meist von Wissenschaftlerinnen und Wissenschaftlern nur geringfügiger Kenntnis von Softwaretechnik oder unter Aspekten von Nachhaltigkeit entwickelt wird, da die Software nur als Mittel zum Zweck gesehen wird. Ziel der Wissenschaftlerinnen und Wissenschaftlern ist es schließlich Forschung zu betreiben und nicht Software zu entwickeln.

Dabei zeigt die anhaltende Replication Crisis, die darin besteht, dass etliche publizierte wissenschaftliche Arbeiten nicht reproduzierbar sind, und somit alle abgeleiteten Arbeiten auf unsicheren Füßen stehen und eigentlich unter den geänderten Voraussetzungen wiederholt werden müssten.

Eine Herausforderung ist, dass für viele Forschende, wie beispielsweise in der Mathematik, oft die Software nur zur Verifikation der eigentlichen wissenschaftlichen Aussagen verwendet wird, und daher eine deutlich geringere Wertschätzung erfährt. Auch wird ein Reputationsverlust befürchtet, wenn die Softwarequalität nicht den Ansprüchen im Kernbereich der Forschung entspricht, so dass oft von einer veröffentlichung des Source Codes und der Daten abgesehen wird. Dabei muss die Offenlegung der verwendeten Verfahren und Daten ein Grundanliegen ernsthafter Forschung sein und eine Kennzeichnung von Software beispielsweise als Proof-of-Concept sollte einen angemessenen Anspruch an die Software sicherstellen.

Am Deutschen Zentrum für Luft- und Raumfahrt (DLR), leitet Carina eine Gruppe zum Software Engineering und ist dort mit ihren Kolleginnen und Kollegen für 40 Institute an 20 Standorten Ansprech- und Kooperationspartnerin für Softwareentwicklung unter anderem im wissenschaftlichen Umfeld von Luft- und Raumfahrt, Energie und Verkehr. Inzwischen ist dort ihr Enthusiasmus für Open Source, und Forschenden in der Softwareentwicklung zu unterstützen, zu ihrem eigenen Forschungsgebiet geworden.

Bevor sie zum DLR kam, war sie beim Fraunhofer-Institut für Algorithmen und Wissenschaftliches Rechnen (SCAI) im Bereich der Bioinformatik und dem Semantic Web, sowie in der Industrie und nebenberuflich bei der Froscon tätig, bis sie dem Ruf von Andreas Schreiber in ihre aktuelle Gruppe folgte.

Um Außenstehenden einen schnellen und sehr unterhaltsamen Einstieg in und wichtige Motivation für das Software Engineering bei der DLR zu bieten, hat sie auf der GPN18 einen Vortrag Software-Fehler in der Raumfahrt: Disintegrating Rockets mit großem Anklang gehalten.

Aber kann die Publikation von Forschungsdaten bei Auswirkungen der Replikationskrise wie der Analyse, dass über die Hälfte von Psychologiepapern nicht nachvollzogen werden können, helfen? Auf jeden Fall hätte die Veröffentlichung schon frühere Diskussionen und Verbesserungen der Ergebnisse ermöglicht, da abgeleitete Arbeiten statt der geschriebenen Darstellung auf den echten Daten ihre erweiterten Analysen hätten durchführen können.

Soweit die Theorie, praktisch muss man sich eingehend damit befassen, was genau erforderlich ist, um eine Reproduzierbarkeit schon auf Seiten der Daten und Software zu ermöglichen. Das Befassen mit diesen Themen führt von einer Erstellung einer Publikation zum Begriff der Open Science oder offener Wissenschaft, die unter anderem Open Access, Open Data als auch Open Source betrifft. Hier konzentriert sich Carina in ihrer Forschung besonders auf den letzten Teil, insbesondere wie Erkenntnisse aus der Softwaretechnik dazu beitragen können, dem großen Ziel der Reproduzierbarkeit auch über die Zeit hinweg zumindest näher zu kommen.

Wichtig ist auch den Entstehensprozess von Software zu betrachten. Die Fernseh-Show Bares für Rares demonstriert, wie die Wertigkeit eines Objekts durch eine nachgewiesene Herkunft signifikant beeinflusst wird. Dies erfolgt durch Nachweis der sogenannten Provenience. Der Begriff Provenience bedeutet die Aufzeichnung der Geschichte der Entstehung eines Objektes. Dies läßt sich auf Software übertragen. Die Wertigkeit und Qualität von einer Software-Publikation könnte zum Beispiel dadruch evaluiert werden indem der Build- und Entwicklungsprozess aufgezeichnet, und mit dem PROV W3C-Standards dokumentiert.

Neben der Dokumentation liegt der nächste Schritt für reproduzierbare Software (vgl. E. Heitlinger: Reproduzierbarkeit – Wissenschaftliche Arbeit als Software-Projekt) darin, die erforderlichen zusätzlichen Bestandteile auch zur Verfügung zu stellen. Die nachhaltige Softwareentwicklung befasst sich in besonderem Maße damit, dass die Software von anderen sowohl genutzt als auch in Zukunft weiterentwickelt werden kann. Natürlich sollten wissenschaftliche Veröffentlichungen grundsätzlich die Wissensgewinnung und Validierung genau beschreiben, nur ist dies im gängigen Rahmen und Form normaler Publikationsformen weder in Form noch im Umfang abzubilden. Daher fordern viele Journals und Konferenzen, die Daten und Methoden in der Form von ausführbaren, web-basierten Jupyter Notebooks zur Verfügung zu stellen.

Ein neuer Ansatz ist eine "Software Zitierbarkeit" zu ermöglichen, also sowohl die Form mit Weblinks und Versionierung, also auch mit Infrastruktur wie dem Dienst Zenodo, das einen Digital Object Indentifier (DOI) für Software mit einem Langzeitarchiv bereitstellt. Das ist ein Service, der in etwas weniger spezialisierter Form für unterschiedliche Medien auch von vielen Hochschulbibliotheken angeboten wird.

Am DLR widmet sich die Software Engineering Initiative mit vielen Ansätzen, um Forschenden zu helfen nachhaltige Software zu entwickeln. Ein wichtiger Bestandteil sind hier Trainings, wie beispielsweise Repositories verwendet werden sollten:

Hinweise für sinnvolle Commit-Messages verwenden.
Wie sollten Versionen vergeben werden?
Neben den eigentlichen Sourcen sollte auch der Build-Prozess und Testdaten im Repository sein
Sinnvolle Struktur von Dateibäumen und sprechende Bennenung von Dateien
Jedes Repository sollte eine README-Datei haben, die am Anfang kurz die Funktion der Sourcen beschreibt und in welchem Scope und in welchen Constraints die Ziele erreicht werden sollen, wie sie installiert, ausgeführt und getestet wird und wie sollte die Software zitiert werden?
Unter welcher Lizenz steht die Software?

Unterstützung gibt es auch durch zentrale Infrastruktur, die vom DLR beispielsweise durch eine eigene GitLab bald zur Verfügung stehen wird, und allen Forschenden einen eigenen persönlichen Bereich anbieten, sowie Projekten sofort entsprechende Strukturen bereitstellen.

Die im Gespräch erwähnte SHA1-Kollision Shattered hatte einen Stillstand der für mehrere Browser grundlegende WebKit-Entwicklung zur Folge, da deren Subversion-Rep...