Für mehr offene Software in der Forschung!

ResearchBlogging.org

Wer als Wissenschaftler jemals eine Publikation reproduzieren wollte, um dann auf den reproduzierten Ergebnissen neu aufzubauen, kennt das vielleicht: die Programme, mit denen die Ergebnisse produziert wurden, sind nirgends erhältlich. Vielmehr frustrieren Formulierungen wie “Die Ergebnisse dieser Studie wurden mit hausinternen Programmen produziert” – wie soll man da reproduzieren?

Vor kurzem erschien in Nature dazu ein längeres Essay: The case for open computer programs, grob übersetzt:”Argumentation für offene Computerprogramme”. Wie in der Einleitung schon beschrieben, ist das Hauptargument für offen erhältliche Programme das Problem der Reproduzierbarkeit – kann ich mit Hilfe eines Computers die Hauptergebnisse dieser Studie wiederholen?

Ohne Reproduzierbarkeit ist die beste Wissenschaft nutzlos, denn wie kann ich als Wissenschaftler so sicher sein, dass die Ergebnisse stimmen? Vielleicht sind die Programme, die in der Studie benutzt wurden, fehlerhaft? Eventuell werden korrekte Ergebnisse von einem Programm falsch ausgelesen, und so kommt es zu falschen Ergebnissen. Ohne das Programm (und dessen Code) kann ich als nicht-beteiligter Wissenschaftler nicht unabhängig überprüfen, ob das Wissen, auf dem ich meine Forschung aufbaue, nicht fehlerhaft ist; stattdessen muss ich blind den Wissenschaftlern und den Editorn des jeweiligen Fachzeitschriften vertrauen!

Die Autoren des Essays fassen den Standpunkt einiger Fachzeitschriften zusammen – Nature selbst z.B. verlangt von Autoren keine Programme, sondern vielmehr eine Beschreibung des Ablaufs der benutzten Programme in normalem Englisch. Die Idee dahinter ist, dass sich interessierte Wissenschaftler ihre eigenen Programme schreiben können. Biostatistics dagegen hat sogar einen Editor, der nur für Reproduzierbarkeit von Studien zuständig ist – also einen Großteil des Codes braucht.

Persönlich kann ich Gründe sehen, warum man seinen Code nicht veröffentlichen will – wenn ich ein wenig an einem Projekt (momentan an SNP-Daten) arbeite, fliegen schnell 10-20 kurze Skripte in einem Ordner rum, kaum kommentiert, und wenn’s nur für mich ist, ohne jede begleitende Dokumentation. Dazu kommt, dass die Programme oft einfach nur hässlich sind, nach dem Motto: “Was funktioniert, reicht” – sowas kann man keinem zeigen!

Sollte man aber. Denn, wie schon oben ausgeführt, ohne Code können andere kaum die Ergebnisse reproduzieren. Ohne Reproduzierbarkeit steht die Wissenschaft, die auf den Ergebnissen aufbaut, nur auf wackligen Beinen.

Der Wissenschafts-Betrieb ist sehr konkurrenzbetont, deswegen liegt es auf der Hand, dass viele Wissenschaftler weniger von ihrer Arbeit preisgeben möchten, als möglich wäre. Es könnte ja schließlich sein, dass eine konkurriende Gruppe sich mithilfe der offenen Software einen Vorteil verschafft, und so die eigene Gruppe überholt. Dagegen kann man einwenden, dass offene Software von vielen verschiedenen Gruppen verbessert werden kann, was im Endeffekt zu besseren Ergebnissen für alle beteiligten Parteien führt.

Die Autoren des Essays erwähnen mehrere Schritte für Fachzeitschriften und Universitäten, mit der “code availability” erreicht werden kann – unter anderem sollen Universitäten Reproduzierbarkeit in ihre Lehre einbinden, was mir persönlich auch am Herzen liegt. In meiner gesamten Bachelor/Master-“Karriere” habe ich nichts über Reproduzierbarkeit beim Publizieren gelernt, obwohl sie mehr als wichtig ist!

Auch wissenschaftliche Fachzeitschriften stehen unter Zugzwang, die “Englische-Beschreibung-reicht”-Vorschrift ist veraltet, Doppeldeutigkeiten kommen zu oft vor. Stattdessen sollten Fachzeitschriften Standards für Code-Veröffentlichung einführen – zum Beispiel in dem sie zumindest teilweise Code-Veröffentlichung (idealerweise unter einer freien Lizenz wie der MIT- oder GNU-Lizenz) einfordern.


Ince, D., Hatton, L., & Graham-Cumming, J. (2012). The case for open computer programs Nature, 482 (7386), 485-488 DOI: 10.1038/nature10836

Veröffentlicht von

Philipp hat einen Bachelor in Biologie, ein Graduate Certificate in IT und studiert momentan für seinen Master in IT in einem übertrieben großen Land voller Spinnen und Schafe. Für die Bierologie schreibt er zumeist über Biologie, Evolution und allem was an den Rändern der Gebiete noch so angeschwemmt wird.

5 Kommentare Schreibe einen Kommentar

  1. Schlechte Doku ist sicherlich ein Grund wieso Leute ihre Programme lieber nicht veröffentlichen. Ich hatte vor kurzem so einen Fall wo die Software einzig aus dem Grund nicht mit publiziert wurde. Die Autoren haben sie dann halt auf Anfrage rausgegeben mit dem Hinweis wie hässlich sie ist.

    Und klar: Wenn man mit seinen Daten anfängt zu arbeiten dann sammeln sich schnell mal so kleine Scripte an die man in 20-30 Minuten runtergeschrieben hat die dann undokumentiert und hässlich sind, weil reicht ja wenn es funktioniert. Allerdings könnte man das ja trotzdem publizieren. Die openSNP-codebase ist genauso hässlich und undokumentiert und trotzdem open source.

    Ich glaub das ist oft auch einfach ein kulturelles Problem, gerade in den Biowissenschaften kommt es mir oft so vor: “Wir haben doch sowieso nur die üblichen Programme benutzt und die paar Skripte zum aufbereiten und filtern, auch so wichtig ist das nicht. Spannender sind doch sowieso die Ergebnisse.” Und dann bekommt man halt “Wir haben xyz mit Standardeinstellungen verwendet und haben die Daten vorher nach Kriterium abc mit eigenen Programmen bearbeitet”.

  2. Black Box und White Box. Beides sinnvoll

    Oft genügt es schon, wenn man die Software, welche etwas belegen soll ausführen kann. Eine Black Box erlaubt immer noch das Füttern mit ganz unterschiedlichem Input. Ein Experte auf einem bestimmten Gebiet weiss z.B. was für Resultate für bestimmte Inputs zu erwarten sind. Er kann dann eine Software mit komplizierter Funktionaliätt daraufhin überprüfen, ob sie mindestens für Standardfälle und Extremfälle die richtige Antwort liefert.

    Erhält man auch noch den Source Code hat man noch mehr Überprüfungsmöglichkeiten, was aber auch mehr Arbeit macht.

    Sogar das Black Box – Modell erfordert aber eine Portabilität der Software. Die verwendete Hardware sollte deshalb möglichst weit verbreitet sein oder gut emulierbar sein.

    Man kann sich sogar vorstellen, das Forschungssoftware für das breite Publikum geöffnet wird. Jeder Klimatologe könnte seine Modelle zur allgemeinen Verfügung stellen. Skeptiker und Interessierte könnten dann mit Testläufen Vertrauen gewinnen (oder auch nicht) und besser zwischen echten Schwächen und behaupteten Schwächen solcher Modelle unterscheiden.

  3. Ist das Bereitstellen zum Zwecke der Reproduktion nicht Bedingung der/einiger Zeitschriften bei Publikation?

    Zumindest war mir so, bin aber nicht mehr ganz so sicher…

  4. @Knackbock

    Kommt auf die Fachzeitschrift an, wie im Text angeschnitten wollen manche gar nichts, manche nur eine Beschreibung der Arbeitsschritte des Programmes in Englisch, manche den gesamten Code! Da gibts noch nichts einheitliches.

Schreibe einen Kommentar