Software in der Bioinformatik (3) — Die “beliebtesten Artikel” in BMC-Bioinformatics

Dieser Tage erreichte mich eine Mail – siehe Bild. So so, also die beliebtesten Artikel in “BMC Bioinformatics“. Nein, die Artikel, welche die meiste online-Aufmerksamkeit erregten. Das ist in der Tat etwas anderes. Was genau? Der Link zur Metric von Magic-Blast gibt Auskunft:

Aufmerksamkeit gemessen in Tweets, Aufnahmen in das Bibliographieprogramm Mendeley, Blogposts wie diesen und erwähnende Facebook-Seiten. Womit auch die Farben erklärt sind.

Vielleicht bin ich ja ein zu alter Wissenschaftler, aber ich finde, liebe BMC-Macher, die Qualität einer Veröffentlichung viel, viel entscheidender als die Onlineaufmerksamkeit. Andererseits muss ich zugeben, dass eine Software über die niemand gackert, kaum jemand kennt und Software, die in keiner Bibliographie auftaucht, auch nicht zitiert werden wird. Insofern hat die online-Aufmerksamkeit heute wohl eine Vorhersagekraft für die Zitierungen morgen.

Doch irgendwie wünsche ich mir schon länger, dass die Qualität von wissenschaftlicher Software stimmt und insb. bei BMC Bioinformatics habe ich auch schon vor einiger Zeit die Software-Gretchenfrage gestellt: “Sagt, wie haltet ihr es mit der Qualität?” Denn zusammen mit Anderen im Feld ist mir aufgefallen, dass Softwareveröffentlichungen in diesem Journal häufiger wesentliche Qualitätsmerkmale vermissen lassen. Und dann habe ich auf der Webseite des Journals von der CodeOcean-Initiative erfahren: Das Journal bietet interessierten Autoren einen professionellen CodeReview an, mit dem expliziten Ziel die Qualität zu verbessern. Oder mit anderen Worten: Den Editoren muss aufgefallen sein, dass da etwas im Argen liegt. Ich habe also das Journal angeschrieben und am 1. März 2020 gefragt:

Dear Sir or Madam,

With great interest I read about the Code Ocean initiative to improve the code / software articles submitted to BMC Bioinformatics.

Currently, the code quality frequently does not meet modest criteria: most repositories lack releases, are clearly not maintained (last update sometimes >> 1 year ago when the article is published), software lacks installers (and is hence “works on my system”-software), most of the software violates basic coding standards.

It is great that there is an opt-in initiative for code review. Earlier this month I inquired at Mrs. Cuff, the journal editor who was named as a contact. Particularly I would like to know:

• Who will be conducting the code review? What is the aim of a particular review?
• Authors submitting software articles to the journal “will be invited to take part” (according to  https://bmcbioinformatics.biomedcentral.com/code-ocean-pilot ). Is there any plan to make code review a mandatory part of the review process?
• How has the code review been handled in the past?
• Are there any criteria (e.g. a maintained software repository, semantic release management, release notes, changelogs, code style, performance, etc.)? How about the past: Have there been similar criteria in place?
• What is the pricing for code review for authors in the context of this initiative?
• The web page states, that — once published — authors can share their code. Isn’t this already a requirement?
• https://bmcbioinformatics.biomedcentral.com/reviewer-acknowledgements list reviewer acknowledgments up to 2016. Is there currently a pool of reviewers?
• Which are the IT-knowledge requirements of reviewers?
• How frequently do reviewers reject articles due to code issues? A rough estimate would suffice.

I intend to write a blog article including your answer – if there is no objection.

Best regards,

Bis zum heutigen Tag habe ich keine Antwort erhalten, dafür wiederholt

With kind regards,

In diesen Zeiten haben auch Editoren andere, womöglich familiäre Sorgen. Da kann man verstehen, dass es länger dauert. Auch sonst ist die Beantworten der Fragen eines nervigen Bloggers sicher nicht auf der Prioritätenliste weit oben – wäre es bei mir auch nicht. Doch nach drei Monaten warten, habe ich denn noch mal nachgefragt … und erst jetzt erhalten, dass mein “Ticket” eskaliert wurde.

Schauen wir uns doch mal die Qualität dieser beliebten Softwareveröffentlichungen an – wobei ich mich bewusst auf eine sehr oberflächliche Erfassung der Qualität bemühe:

• AMON^{[Schaffer et al., 2019]} – eine Software, die Anwender auf der Kommandozeile nutzen sollen.
  • Wie kann man die Software installieren? Erst conda und dann pip ist die Empfehlung — da könnte ich einen eigenen Artikel schreiben, aber das lenkt ab. Direkt mit pip geht ja auch. Also ein Haken hinter die Frage ob eine Installationsroutine vorhanden ist: Ja.
  • Ist die Software noch gewartet? Der letzte update im repository liegt beim Schreiben dieses Artikels 6 Monate zurück. Also: Hm, na ja, wahrscheinlich nicht, weil die meisten Updates sehr viel weiter zurückliegen, aber im Zweifel für den Angeklagten.
  • Ist die Verwendung dokumentiert? Ja, siehe obiger Link.
  • Wie sieht der Code aus? Es gibt einen Logger – also kann ein Logfile geschrieben werden und man kann Dinge nachvollziehen: Gut. Der Code sieht sehr kompakt aus und ist großteils monolitisch: Also ein gemischtes Fazit.
• Magic-BLAST^{[Boratyn et al., 2019]} – ebenfalls eine Kommandozeilensoftware vom NCBI.
  • Wie kann man die Software installieren? Es gibt Installer für die gängigen Betriebssysteme, die man mit ein wenig Suchen findet. Wer etwas Anderes, z. B. die Einbettung in HPC-konforme Installationsroutinen oder Ähnliches sucht, dem wünsche ich viel Erfolg. Fazit: Vorhandene Routinen, wenig nutzerfreundlich.
  • Ist die Software noch gewartet? Kaum.
  • Ist die Verwendung dokumentiert? Ja.
  • Wie sieht der Code aus? Da steht tatsächlich so etwas wie: “Willst Du liebe(r) NutzerIn einen anderen Parameter, ändere den Code!” Es gibt Scripte für ihre Magic-Farm – Portierbarkeit ist etwas Anderes. Es wird das Rad neu erfunden (bestehende Bibliotheken nicht genutzt) und Parameter sind wieder hard-coded. Weiter habe ich mich nicht durch den Code geklickt – so richtig schlau bin ich aus der Struktur erst gar nicht geworden, habe auch nur wenig Zeit rein gesteckt. Fazit: Bei dem Renommee der Institution hätte ich mehr erwartet.
• pcaExplorer^{[Marini & Binder, 2019]} ist eine shiny R-Applikation zur Auswertung von RNA-seq Daten mit Fokus auf Eigenwertanalyse. Bei dieser Veröffentlichung muss ich anmerken nicht neutral zu sein, weil Sie von meinem lieben Kollegen Federico Marini stammt.
  • Wie kann man die Software installieren? Sie ist Teil des Bioconductor-Projektes geworden und kann in dem Kontext installiert werden.
  • Ist die Software noch gewartet? Ja. Obwohl mich stört, dass der obige Bioconductor-Link 184 Abhängigkeiten listet. Gut und schön, so lange ein Projekt lebt, aber wenn nur eines der 184 nicht mehr gewartet wird …
  • Ist die Verwendung dokumentiert? Sehr gut.
  • Wie sieht der Code aus? Gut strukturiert und professionell geschrieben und dokumentiert – aber ich sagte, dass ich voreingenommen bin …

DAS ist also die Crème de la Crème der Veröffentlichungen in BMC-Bioinformatics?

Eine vergleichende Einordnung …

Vergleichen wir dazu mal die 10 (willkürliche Zahl, eigentlich wollte ich das Dutzend vollmachen, aber es ist zu frustrierend) aktuellen Veröffentlichungen (ab dem 29. Juni 2020 – für zukünftige Leser) mit dem Label “Software” – die keine Web-Applikationen sind (weil sich dort die Frage der Installierbarkeit anders stellt und die Skalierbarkeit ohnehin nicht gegeben ist – ein Graus der Bioinformatik, das einen gesonderten Beitrag verdient). Wem der folgende Teil, das Kleinklein, zu langweilig ist, kann direkt zum Fazit springen:

• CoreSimul^{[Bobay 2020]} – eine Pythonskriptsammung
  • Wie kann man die Software installieren? Gar nicht, die Skripte sind “as is”.
  • Ist die Software gewartet? Nein, siehe obiger Link.
  • Ist die Verwendung dokumentiert? Nicht auf der Repo-Seite, siehe obiger Link, aber es gibt ein grottiges PDF.
  • Wie sieht der Code aus? Eine Mischung aus Französisch und Englisch – das geht gar nicht in wissenschaftlichem Code. Schließlich könnte sonst ja jeder ihre/seine Lieblingssprache verwenden und eine babylonische Verwirrung wäre garantiert. Eigenbauparsing. Insgesamt: Anfängercode, den mal jemand hätte anschauen sollen.
• ATLAS^{[Kieser et al., 2020]} – weicht vom bisherigen Schema, ab, weil es ein snakemake-workflow ist — ist dort aber leider nicht aufgeführt.
  • Wie kann man die Software installieren? Via Conda. Was ok ist, aber nicht auf allen Systemen erlaubt ist, da Conda einen eigenen Abhängigkeitsbaum mit sich bringt und außerdem portierbar sein soll, so dass die Abhängigkeiten cross-platform kompiliert sind und somit häufig langsamer als plattformoptimierte Pendants.
  • Ist die Software gewartet? Z. Zt. schon, wenn man sich das Softwarerepo anschaut, aber muss es dass langfristig? Es geht schließlich um einen rel. kleinen portierbaren Workflow, der ist irgendwann reif und kann so lange genutzt werden, sie die Abhängigkeiten bereitzustellen sind.
  • Ist die Verwendung dokumentiert? Ein klares Ja. Wobei die Ausführung auf dem Cluster bald veraltet sein wird – ich arbeite daran.
  • Wie sieht der Code aus? In meinen Augen ein gut strukturierter snakemake-workflow.

• pyMeSHSim^{[Luo et al.; 2020]} – eine Software zur Arbeit mit MeSH-Terms (MeSH = Medical Subject Headings).

  • Alle Weiteren Fragen sind beantwortet mit folgender Passage aus der Veröffentlichung unter “Availability”

All data generated or analysed during this study are included in this published article and its supplementary information files.

DAS geht gar nicht: Keine verlinkten Quellen in der Veröffentlichung? Was soll das? Wie soll da Nachvollziebarkeit, geschweige denn Reproduzierbarkeit gegeben sein? Soo kann man viel behaupten – der Artikel hat die Markierung “Software” nicht verdient.

• j2s^{[Laville et al.; 2020]} – soll Stratifizierungseffekte von Gen-Umgebungsuntersuchungen ableiten können.
  • Wie kann man die Software installieren? Gar nicht. Es handelt sich um ein Skript, dass man einfach laufen lassen kann.
  • Ist die Software gewartet? Nein, siehe obiger Link.
  • Ist die Verwendung dokumentiert und wie sieht der Code aus? Die Frage vereine ich hier, weil es sich um ein Skript handelt mit ganzen 61 Zeilen, inkl. Leerzeilen. Wie bitte? Das rechtfertigt eine Publikation des Pasteur-Institutes? Eigenbau Kommandozeilenparsing das eine Tabellenverarbeitung ermöglichen soll, die nur einen Tabellentyp verarbeiten kann und wehe jemand ändert den Tabellenkopf. So was kann man in einem Programmierkurs an einem Nachmittag zusammen stöpseln und DatenanalystInnen machen das häufig – auf besserem Niveau. Weitere Kommentare verkneife ich mir.

• RWRMTN^{[Le & Tran; 2020]} – ein Vorhersagetool zu Krankheitsverbindungen auf microRNA-Basis

  • Wie kann man die Software installieren? Sie ist erhältlich als Cytoscape App (was ich damit auch zum ersten mal gelesen habe), man erhält ein ‘.jar’-File. Das ist alles.
  • Ist die Software gewartet? Keine Ahnung, wo ist der Code? Wo die Entwicklungsgeschichte?
  • Ist die Verwendung dokumentiert? Ja.
  • Wie sieht der Code aus? Tja, wenn man das wüsste … ich analysiere nicht das .jar-File und wenn mir jemand sagt: “Da ist der Link: “, denke ich mir, dass ich den nicht lange suchen möchte.

• PhyteByte[Westerman et al.; 2020] – soll Essenbestandteile mit pharmakologischer Wirkung identifizieren helfen

  • Wie kann man die Software installieren? Es gibt eine Anleitung – ein Durcheinander, um die Abhängigkeiten zu erfüllen. Grausig.
  • Ist die Software gewartet? Kaum, siehe obiger Link.
  • Ist die Verwendung dokumentiert? Mies, siehe obiger Link.
  • Wie sieht der Code aus? Sieht gut strukturiert aus, aber man soll ein Skript ‘run.py’ starten, dass einige Parameter fest verdrahtet enthält und ansonsten auf eine Konfiguration zurückfällt, die es manuell zu ändert gilt. Nun ja, verbesserungswürdiges Design.
• DryMass^{[Müller et al.; 2020]} – eine Software zum Umgang mit Mikroskopiedaten aus der Phasenkontrastmikroskopie.
  • Wie kann man die Software installieren? Via pip.
  • Ist die Software gewartet? Keine Ahnung, wo ist der Link zur Software? Versionsnummer auf PyPi ist 0.10.4. Wenn das die letzte Veröffentlichung ist, warum publizieren die Autoren: Gemäß Selbsteinschätzung durch die Versionsnummer ist die Software überhaupt nicht reif.
  • Ist die Verwendung dokumentiert? Ja.
  • Wie sieht der Code aus? Den Code gibt es nur im Download (oder? Ich mag nicht ewig suchen), also ist seine Geschichte nicht dokumentiert. Er sieht gut strukturiert aus, aber irgendwie undurchdringlich. Müsste man sich näher anschauen, auf einen Blick vermag ich kein Urteil zu fällen.
• BEAVR^{[Perampalan & Dick; 2020]} – ein browserbasiertes Tool zur Visualisierung von RNA-seq Daten. Allein browserbasiert geht dabei – finde ich – gar nicht: Browserbasiert heißt, dass die Daten irgendwo analysiert werden und besondere Vorkehrungen zum Patientenschutz getroffen werden müssen. Mal schauen, ob das irgendwo steht.
  • Wie kann man die Software installieren? Via docker. Das Verwenden von docker-images beantwortet bereits einen Teil der Frage zur Datensicherheit: Wenn der Server nicht sehr geschützt ist, würde ich mich bei docker-Images nicht darauf verlassen, dass mein Download nicht manipuliert ist oder noch schlimmer bei einem Serverhack nicht still und heimlich dauerhaft Information gesaugt wird …
  • Ist die Software gewartet? Ja. (bisher)
  • Ist die Verwendung dokumentiert? Ja.
  • Wie sieht der Code aus? Viele Abhängigkeiten, viele Dinge hardcoded, insgesamt eher unübersichtlich. Sie obiger Link auf die Software.
• SCSIM^{[Giguere et al., 2020]} – ein Tool zur Simulation von Sequenzierungsdaten.
  • Wie kann man die Software installieren? Via docker. Nun, ich will im Zweifel keinen Container installieren, sondern eine Software laufen lassen. Für Container muss es einen Grund geben. “Container sind toll und gerade in” ist keiner.
  • Ist die Software gewartet? Kaum.
  • Ist die Verwendung dokumentiert? Mau.
  • Wie sieht der Code aus? Ein paar kleine Skripte, ein Mix aus shell und Python. Wiederholte Lookups in Schleifen werden die Skripte bremsen, die Shellscripte lassen erkennen, dass die Autoren noch nicht mal bash-Parameterexpansion kennen.
• ARTDeco^{[Roth et al.; 2020]} – automatisierte Erkennung von Mutationen, die einen fehlenden Transskriptionsabbruch in RNA-seq Daten erkennen soll
  • Wie kann man die Software installieren? Die Abhängigkeiten kann man mit Conda auflösen. Und dann direkt händisch installieren. Dazu sage ich nichts mehr.
  • Ist die Software gewartet? Vielleicht, sie obiger Link.
  • Ist die Verwendung dokumentiert? Ja, aber Übersichtlichkeit geht anders. Siehe obiger Link.
  • Wie sieht der Code aus? Wie guter Anfängercode: Etwas Modularisierung, kein Logging, ein paar kleine Skripte. Wehe dem, der einen Fehler in der Datenpräparation macht.

Fazit: von 10 analysierten Softwarepaketen ist eines gar nicht dokumentiert. 3 haben keine Installationsroutine, 1 braucht keine und ein paar haben fragliche Installationsroutinen (ein wenig Geschmackssache). Der Wartungszustand ist zumindest bei allen irgendwie fraglich oder gar nicht nachvollziehbar. Softwarereleases sind überwiegend Fehlanzeige. Codestruktur nicht selten unheimlich – dabei bin ich kaum darauf eingegangen. Auch die Dokumentation lässt oft zu wünschen übrig.

Warum das Gewese?

Meine kleine Liste belegt: Mindestens dieses Journal hat ein Problem mit den Veröffentlichungen, die Software zum Thema haben. Die Software ist an sich problematisch. Und das ist erkennbar bei sehr oberflächlicher Betrachtung (und nicht mehr habe ich für diesen Beitrag nicht durchgeführt!).

Gute Software ist wichtig! Sie dient den ExperimentatorInnen zur Analyse von Daten, zur Simulation von Modellen – als Hilfsmittel zur wissenschaftlichen Arbeit. Bioinformatik ist auch eine Wissenschaft, aber die findet auch Widerhall in Veröffentlichungen, die Methoden oder Algorithmen beschreiben, proof-of-concept-Veröffentlichungen und vergleichbaren Veröffentlichungen. Wer eine Software veröffentlich, erweckt den Anschein Produktivsoftware anzubieten. Und wer das macht, soll auch dafür gerade stehen!

Schlechte Software — Software, die lahm ist, unzureichend dokumentiert, nicht oder schlecht zu installieren ist, nicht gewartet ist — hilft nicht weiter – oder führt zu falschen wissenschaftlichen Annahmen. Es ist aber auch im Interesse der wissenschaftlichen Zeitschriften, die *Informatics oder Ähnliches im Titel tragen, für Qualität einzustehen. Das könnte sich in Form von Impact / Zitaten für die Zeitschriften auszahlen, nicht wahr? Umgekehrt leidet ihr Renommee.

Ich hoffe sehr bald auf meine Fragen Antworten zu erhalten, denn ich habe auch ein professionelles Interesse. Nicht selten kommt es vor, dass ich Schrott (und das ist manchmal ein Euphemismus) installieren soll – und enttäuschte Anwender habe. Denn diese verstehen nicht, warum ich ablehnen muss oder die Software schlecht läuft. Denn sie können die Software häufig nicht evaluieren und wissen nicht um deren Zustand. Schlimmer ist dann, wenn die Software läuft, aber subtile Bugs enthält – und dann die Entwickler nicht oder nicht zufriedenstellend reagieren. Oftmals reagieren Entwickler überhaupt nicht mehr: Ist Euch aufgefallen, dass die Softwarerepos, die hier verlinkt sind i.d.R. persönliche Repos nicht fest angestellter Entwickler sind? Wenn eine Software im Rahmen einer Dissertation oder Masterarbeit erstellt wird, sollte es Aufgabe der BetreuerInnen sein, für die Persistenz zu sorgen: Ehemalige Mitarbeiter mit Jobs außerhalb der Wissenschaft kümmern sich nicht mehr um ihre “Machwerke”. Klar. Wenn dann aber gar niemand mehr antwortet, leidet auch das Renommee der Institution.

Dislaimer

Auch ich habe schon in BMC Bioinformatics veröffentlich^{[Meesters et al.; 2012]} – eine Software zur Metaanalyse genomweiter Assoziationsstudien. Auch diese Software habe ich nicht mehr weiterentwickelt – auch weil die Arbeitsgruppe aufgelöst wurde, war kein Interesse mehr gegeben und die Software hat zu wenig Nutzer gefunden (damals habe ich nicht gebloggt!). Immerhin habe ich den Code erneut veröffentlicht, denn er war auf dem Server der aufgelösten Arbeitsgruppe. Auch ich habe Fehler gemacht (heute würde ich schöneren Code schreiben), aber wer weiß, vielleicht gibt es mal irgendwann Interesse und ich kann das Projekt wieder aufleben lassen …