Verschiedene Veröffentlichungen in den letzten Monaten haben darauf hingewiesen, dass wissenschaftlicher Fortschritt zunehmend auf Software und auf der Verkettung von Softwarekomponenten beruht. Gleichzeitig sind sowohl die Software, als auch die darunterliegenden Hardware-Plattformen noch immer in einer raschen Entwicklung begriffen. Dies führt dazu, dass die Prozessierung komplexer Daten mit unterschiedlichen Software- und Betriebssystemversionen zu signifikant unterschiedlichen Ergebnissen führen kann. Dies läuft dem Prinzip der Reproduzierbarkeit in den Naturwissenschaften zuwider. Durch persistente Identifikatoren könnten Softwarekomponenten und Code eindeutig identifizierbar gemacht werden.

Auf Veranstaltungen zum Thema Softwareentwicklung in den Geowissenschaften (EGU General Assembly 2012, GFZ-PIK-AWI Software-Workshop 2012, American Geophysical Union Fall Meeting 2012, und in Vorbereitung EGU General Assembly 2013) wurde deutlich, dass es eine starke Nachfrage nach einer Plattform für die Veröffentlichung von wissenschaftlichem Code gibt, die den Prinzipien einer wissenschaftlichen Veröffentlichung gerecht wird (Reproduzierbarkeit, Qualität, Persistenz). Die existierenden Plattformen (z.B. Sourceforge, Github, usw.) erfüllen diese Kriterien nur in Teilen.

Eine Lücke in der wissenschaftlichen Kommunikation über wissenschaftliche Software und Code ist die fehlende Fachzeitschrift. Ergänzend zu den beiden etablierten Zeitschriften, zum Beispiel Computers & Geosciences (Elsevier) und Earth Science Informatics in den Geowissenschaften, fehlt eine Zeitschrift wie etwa Earth System Science Data (Copernicus), in der die Anwendbarkeit der Software und deren Dokumentation im Vordergrund steht. Keine der beiden etablierten Zeitschriften ist mit einem Code Repository assoziiert. Zudem ist weder Computers & Geosciences noch Earth Science Informatics eine Open Access Zeitschrift, was die Verbreitung gerade bei interdisziplinären Themen einschränkt. In den meisten anderen Disziplinen sieht es ähnlich aus.

Die Kombination von Zeitschrift und Code Repository hat das Potenzial für eine deutliche Verbesserung der Kommunikation von Softwarelösungen und Verbreitung von nachnutzbaren Lösungen. Es ist zu erwarten, dass durch die Verfügbarkeit von Qualitätsgesichertem Code die Zitatrate der dazugehörigen Artikel, ähnlich wie bei Artikeln mit verfügbaren Daten, deutlich gegenüber herkömmlichen Veröffentlichungsformen gesteigert sein wird. Zudem würde die Verfügbarmachung von Software damit in den Rang einer wissenschaftlichen Veröffentlichung gehoben.

In einem Vorgespräch mit der DFG wurden wir ermutigt, die Idee zu einem Antrag weiter auszuarbeiten und den disziplinären Fokus über die Geowissenschaften hinaus auszuweiten. Zusätzlich wurden wir aufgefordert, uns Gedanken zur Qualitätssicherung zu machen, die über den traditionellen Peer-Review hinaus gehen.

Martin Fenner:

30% ORCID EU: EU Projekt zu DataCite / ORCID Interoperabilty
65% PLOS: Softwareentwickler für einen Open Access Publisher
5%: Medizinische Hochschule Hannover: Arzt

Tomás Zerolo:

Tomás Zerolo, lange frei schwebender Software-Entwickler (seit ungefähr 1980, ja auch COBOL war dabei ), grosse Affinität zu freier Software (oder Open Source, wobei ich die “erste” Erscheinungsform vorziehe).

Kristian Rother:

Dr. Kristian Rother: Von 1999-2011 Softwareentwickler in der Bioinformatik. Seit 2012 freiberuflicher Trainer fuer effiziente Wissenschaft. Professional Scrum Master.

Matthias Lendholt:

MSc Software System Engineering (HPI/Uni Potsdam). Mehrere Jahre Entwickler bei Siemens. Seit 2008 am GFZ. Softwareentwicklung Tsunami-Frühwarnsysteme, EU Projekte DEWS und TRIDEC.

Heinz Pampel:

Helmholtz Open Access Koordinationsbüro, re3data.org, et al.

Wieso hat sich dieses Thema noch nicht erledigt? Warum sollte wissenschaftlicher Code veröffentlicht werden? Wie wird Code Teil der wissenschaftlichen Überlieferung?

Martin Fenner:

Momentan kann man als Softwareentwickler in der Wissenschaft eigentlich keine Karriere machen. Auch wenn Software eigentlich ständig gebraucht wird.

Tomás Zerolo:

Baupläne experimenteller Apparaturen gehören auch zur Veröffentlichung.

Kristian Rother:

Weil es viel zu einfach ist ein Paper ueber eine Software durchzubringen, die nicht einmal minimale Qualitaetskriterien erfuellt. Um dem Primat der Reproduzierbarkeit gerecht zu werden [sollte wiss. code auch veröffentlicht werden]. Die Zeiten wo es reichte einen Algorithmus zu beschreiben, dessen Implementation dann trivial ist, sind wohl vorbei. [Code wird teil der wiss. Überlieferung] Wenn er 1) verfuegbar 2) ausfuehrbar 3) validierbar, 4) dokumentiert und 5) rezensiert ist. Wir haben bestimmt verschiedene Lieblingstools fuer 1)-4), aber ehrlich, ich glaube die sind alle geeignet.

Matthias Lendholt:

Da kann ich mich nur Martin Fenner anschließen: “Momentan kann man als Softwareentwickler in der Wissenschaft eigentlich keine Karriere machen. Auch wenn Software eigentlich ständig gebraucht wird.”

Heinz Pampel:

Wissenschaftliche Leistung sollte nicht mehr länger alleine an der Anzahl der Paper gemessen werden. Wissenschaftlicher Output sollte umfassender betrachtet werden. Die National Science Foundation (NSF) zeigt wohin die Reise geht: Seit Anfang des Jahres kann auch Software bei der Antragstellung - als wissenschaftlicher Output - gelistet werden.
Darüber hinaus sollten alle Ergebnisse wissenschaftlicher Arbeit dauerhaft zugänglich gemacht werden. Also auch Software und ihre Dokumentation. Nachnutzung und Nachprüfbarkeit sollen auch nach Ende eines Projektes oder Weggang eines Programmierers möglich sein.
Ziel sollt es sein Strategien der Software-Publikation zu identifizieren, die Anerkennung, Nachnutzung und Nachprüfbarkeit ermöglichen.

Martin Fenner:

Für mich persönlich lief Softwareentwicklung völlig parallel zur Wissenschaft, keine Anerkennung als wissenschaftliche Leistung. Ich habe mich aber auch immer mehr für Infrastruktur interessiert, nicht Auswertung konkreter Forschungsdaten.

Tomás Zerolo:

Leider wenig: nach meinem Physikstudium kein Akademiker, nur Sympathisant.

Kristian Rother:

Code, Veröffentlichung, Anerkennung als wissenschaftliche Leistung? Weit verbreitete Unkenntnis was Code Repositories, Tests und Releases sind. Die Vorstellung ein Programm sei irgendwann fuer immer 'fertig'. Aber auch gute Beispiele fuer lebendige Entwicklung und sauberes Software Craftmanship.

Matthias Lendholt:

Software bzw -entwicklung wird nicht allzu sehr anerkannt, sondern ist ein notwendiges übel, was nebenbei abfallen muss. Aber das ist meine persönliche Erfahrung und kann ich anderen Disziplinen ganz anders gelagert sein.

Heinz Pampel:

Die Bedeutung von Software steigt in allen Disziplinen (siehe z.B. die Diskussionen um die Digital Humanities). Damit gewinnt die Professionalisierung der Entwickler an Bedeutung. (In den Biowissenschaften gibt es z.B. Konferenzen und Berufsverbände, die die Interessen dieser Akteure vertreten.) Eine solche Professionalisierung scheint auch in anderen Disziplinen nötig. Diese Professionalisierung könnte helfen die Anerkennung der Arbeit und auch die Praxis der Entwickler (z.B. mit Blick auf Publikationsstrategien) zu verbessern.

Martin Fenner:

Konkrete Ideen, was als nächstes zu tun ist. Am liebsten auch jenseits von Geosciences.

Tomás Zerolo:

Das Potenzial der Open Source/Free Software so weit wie möglich in der akademischen Welt realisiert zu sehen. ¹⁾

Kristian Rother:

Lebendiger Austausch mit anderen Entwicklern.

Heinz Pampel

Ideensammlung. Multidisziplinärer Diskurs. Blick in die Zukunft.

Tomás Zerolo:

Code ist einerseits ein Mittel den Computer dazu zu bringen, einen Teil des Jobs zu erledigen. Auf der anderen Seite soll er meinen Gegenüber davon überzeugen, dass es auch das tut, was es tun soll ²⁾ – und dieser Aspekt ist der interessantere (und auch der, der dem Wissenschaftsbetrieb mehr am Herzen liegen sollte).

Kristian Rother:

Meine Kernthemen fuer Workshops zum Thema “Softwareentwicklung fuer Biowissenschaftler” zu verfeinern.

Martin Fenner:

Für einen Zeitraum von 1-5 Jahren (Github wurde Februar 2008 gestartet). Ich erwarte nicht, meine Github-Daten in 20 Jahren noch zu finden.

Tomás Zerolo:

Meines Erachtens wird zu viel Wert auf das Produkt (GitHub) und nicht so viel auf das Prinzip (Git) gelegt. Der Reiz der verteilten Verionskontrollsysteme liegt ja daran, dass ein Repository nur als Austauschplattform fungiert und durch jedes andere ohne Verluste ersetzt werden kann (sofern die alle synchron gehalten werden). Die Hashes sind invariant!
Dennoch: Github ist (wenn auch proprietär) gut gemacht und nützlich.

Matthias Lendholt:

Der hohe Bekanntheitsgrad ermöglicht schnelleres Auffinden von thematisch ähnlich gelagerten Projekten. Doch gerade bei Verwendung von verteilter Versionskontrolle (z.B. git) spricht nichts dagegen den Code auf Github sowie auf anderen/eigenen Repositories zu hosten.

Martin Fenner:

Die Software muß laufen, z.B. mit einem Beispiel-Datensatz. Oder “5 Stars of Scientific Software”: Existence, Availability, Openness, Linked, Assured: https://indico.cern.ch/getFile.py/access?contribId=4&resId=1&materialId=slides&confId=218386

Tomás Zerolo:

Unit tests. Natürlich muss Anfwand abgewogen werden.

Martin Fenner:

Proprietäre Bibliotheken vermeide ich, ebenso Bibliotheken, die nur eine nichtkommerzielle Nutzung zulassen.

Tomás Zerolo:

Da empfehle ich einen Blick auf grosse Distributionen. Eine wie Debian nimmt die Lizenzverwaltung sehr ernst und hat da gute Pionierarbeit geleistet.

Matthias Lendholt:

Bei komplexen Systemen basierend auf diversen Fremdbilbiotheken mit unterschiedlichsten Lizenzen wird es schnell unübersichtlich. Wir verwenden LGPL bzw GPL.

Tomás Zerolo:

Gemischt. Grundsätzlich sind alle relevanten FOSS-Lizenzen so, dass sie den Endnutzer/innen erlauben, beliebig mit proprietärer Software zu mischen; soll das Ergebnis verteilt werden, muss man aufpassen.
Natürlich neige ich dazu zu sagen, freie Software passe besser zum Wissenschaftsbetrieb (bessere Kontrolle darüber, was “drin” ist, mein Gegenüber kann auch besser Review machen), aber ich bin da nicht impartiell.

Martin Fenner:

Als virtuelle Images, z.B. http://scofield.bx.psu.edu/~dannon/encodevm/

Tomás Zerolo:

Das dürfte eine der schwierigeren und interessanteren Themen sein. Wieder turnen uns da die Distributionen vor, was es für Möglichkeiten und Konflikte gibt.

Matthias Lendholt:

Sobald Fremdbibliotheken, Versionierung und komplexere Abhängigkeiten berücksichtigt werden müssen, sollte ein Build-System vorhanden sein.
Build-Strategien, Repositories und Lizenzfragen werden in wissenschaftlichen Projekten häufig gar nicht oder zu spät angegangen. Oftmals werden auch keine Ressourcen dafür eingeplant und/oder Expertenwissen fehlt.

Martin Fenner:

DOIs für Major releases, Handles für nightly builds. DataCite hat eine ähnliche Philosophie für Daten.

Tomás Zerolo:

Nightly builds sind ja nur eine spezielle Strategie, die nicht immer so umgesetzt wird. Was aber feststeht sind Releases (vgl. die Antwort von Martin Fenner, der ich nur zustimmen kann). Ein (major oder minor) release signalisiert: in diesem Zustand ist die Software benutzbar. Es bietet sich also an, ein Release mit einem DOI zu “taggen” (ich würde auch eher minor releases mit öffentlichen Identifikatiorn “taggen”, aber das ist wirklich ein minor detail).

Martin Fenner:

Jedes Code Repository sollte Regeln haben, welche Software es hostet. Es geht nicht nur um Schadsoftware, vielleicht auch Content der aus anderen Gründen nicht passt.

Tomás Zerolo:

Schwieriges Thema. Bei Software “aus der Quelle” (d.h. vom Versionskontrollsystem) kann bei moderneren Systemen das Release signiert werden. Darüber kann ein “Web of trust” aufgebaut werden, das sich in einem ständigen Feedback befindet. Bei “binärer” Distribution (Debian, rpm, etc.) haben die Distributionen mittlerweile eine gute Infrastruktur, die man nachahmen kann. Virtual images, am anderen Ende der Skala gehören signiert.

Martin Fenner:

Nein, ähnlich wie bei Open Access.

Tomás Zerolo:

Man darf nicht aus den Augen verlieren, dass die wissenschaftliche Arbeit Priorität hat: Software verteilfähig zu machen ist mit nicht geringem Aufwand verbunden. Andererseits kann die Korrektheit der Software durch Öffentlichkeit profitieren. Um ständige Abwägung kommt man, fürchte ich, nicht herum.

Martin Fenner:

Eine langfristige Strategie ist nötig. Nicht jedes Commit und jede Software muß aufgehoben werden, Major Releases und Software, die für Datenpublikation verwendet wurde, reicht wahrscheinlich. Ein anderes Problem ist die Infrastruktur / Platform. Der Code nutzt wenig, wenn es das Betriebssystem und benötigte Softwarebibliotheken nicht mehr in der richtigen Version gibt. Wahrscheinlich benötigen wir eine spezielle Infrastruktur und diese Aufgaben werden nicht von traditionellen Code Repositories übernommen. Alles, was eine DOI hat, braucht Langzeitarchivierung, für alles andere reicht ein Code Repository.

Tomás Zerolo:

Wie gesagt: mit modernen VCSen ist die “nackte” Überlebensfähigkeit des Quellcodes relativ gut gesichert: mache ich ein “git clone” eines Repositories, so bekomme ich alles, mitsamt tags (=identifiers), Hashes und ggf. Signaturen. Ich kann also recht sicher davon ausgehen, dass ich “denselben Code” bekomme, der dazumal unter diesem Identifier veröffentlicht wurde.
Ob ich diesen Code auch zum Laufen bringe? Libraries? Plattform? Hardware? Das ist der interessantere Teil.

Martin Fenner:

Traditionelle Zitate funktionieren wahrscheinlich nicht. Wir brauchen Nutzungsstatistiken und altmetrics.

Tomás Zerolo:

Wenn ich hier etwas von mir gebe lehne ich mich zu sehr aus dem Fenster. Ich versuche es trotzdem: ja, auch Veröffentlichung von Code ist Veröffentlichung: Code muss dazu aufbereitet werden, dass es veröffentlichbar ist (also lesbar, womöglich portabel, gar anderweitig nutzbar). Andererseits dient das auch dazu, die Korrektheit des Codes (“es tut auch das, was es behauptet zu tun”) überprüfbar zu machen, und macht somit erst Peer Review möglich.

Martin Fenner:

Die Abgrenzung Software / Data / Text ist manchmal sehr schwierig.

Tomás Zerolo:

Ja. Ob digitale Hardware oder Arbeitsteams “programmiert” werden scheint aus struktureller Sicht nur ein Detail zu sein …

Materialien

Literatur

Zurück zur Übersicht