DataWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Workshop 2013-02-06 ======


===== Tagesordnung =====

|  10.00  | Begrüßung  |
|  10.10  | Vorstellungsrunde und ggf. kurze Präsentationen durch die Teilnehmer  |
|  11.30  | Erfahrungen im Umgang mit wissenschaftlicher Software, Erwartungen an Softwareveröffentlichung, Identifikation weiterer Themen  |
|  12.00  | Gemeinsames Mittagessen  |
|  13.00  | Komponenten einer Softwareveröffentlichung, Plattform (Versionierung, Persistenz, Packaging, Identifikatoren, Qualitätssicherung), Zeitschrift/Dokumentation (Format, Qualitätssicherung)  |
|  14.30  | Kaffee  |
|  14.45  | Projektskizze "Softwareveröffentlichung", Vorarbeiten und Marktanalyse, erwartete Ergebnisse, Betrieb und Nachhaltigkeit, Antrag und Zeitplan  |
|  16.00  | Ende des Workshops  |

===== Motivation =====

[[software:start#literature|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, [[software:ws20120507|GFZ-PIK-AWI
Software-Workshop 2012]], American Geophysical Union
Fall Meeting 2012, und in Vorbereitung [[http://meetingorganizer.copernicus.org/EGU2013/session/12088|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. [[http://sourceforge.net/|Sourceforge]], [[https://github.com/|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 [[http://www.earth-system-science-data.net/|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.

===== Fragen an die Teilnehmer =====

==== Zur Person und zum Hintergrund ====

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? ====

//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) [[http://datapub.cdlib.org/data-to-receive-recognition-from-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. 
 



==== Was sind euer Erfahrungen mit wissenschaftlichem Code, Zugang zu Code, Veröffentlichung, Anerkennung als wissenschaftliche Leistung? ====

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. 


====  Was sind eure Erwartungen an die Veranstaltung? ====

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. ((Der grosse Reiz der freien Software liegt für mich primär nicht darin, dass sie "kostenlos" ist (ist sie nicht!), sondern darin, dass ich sie lesen, und daraus lernen kann; dass ich damit experimentieren kann und die Ergebnisse meiner Experimente auch anderen zur Verfügung stellen kann.))

Kristian Rother:

> Lebendiger Austausch mit anderen Entwicklern.

Heinz Pampel

> Ideensammlung. Multidisziplinärer Diskurs. Blick in die Zukunft. 
==== Was sind eure Wünsche oder Ziele im Umgang mit wissenschaftlichem Code? ====

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 (("The computer programs that are truly beautiful, useful, and profitable must be readable by people. So we ought to address them to people, not to machines" -- Donald Knuth "Why I Must Write Readable Programs" z.B. <http://www.desy.de/user/projects/LitProg/Philosophy.html>)) -- 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.

==== Wie persistent sind GitHub, Sourceforge, et al.? ====

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.

Heinz Pampel:

> Funktionalität steht im Vordergrund (usability). Eine dauerhafte Speicherung wird nicht garantiert. Grundsätzlich stellt sich die Frage ob privat-wirtschaftliche Akteure die optimalen Player für persistente Lösungen sind. 
==== Wie könnte ein Qualitäts-Check jenseits des klassischen Peer-Review aussehen? ====

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.

Heinz Pampel:

> Das Verfahren der Qualitätssicherung schient abhängig von der Publikationsstrategie zu sein. Wir ein Paper veröffentlicht, dass die Software dokumentiert, sind klare inhaltliche Anforderungen an den Review-Prozess notwendig. Sollte darüber hinaus auch die Software geprüft werden, so müssen auch hier klare Anforderungen (technische und inhaltliche) formuliert werden. Wichtig wäre es den Gutachter beim Review zu unterstützen. Je komplexer die Software-Produkte desto aufwändiger wird der Review-Prozess sei. Ggf. müsste das Journal auch eine Server für Testinstallationen bereitstellen. 
==== Welche Erfahrungen habt ihr mit der Wahl von Lizenzen und mit Lizenzkonflikten? ====

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.

==== Wie verhält sich FOSS zu proprietären Bibliotheken (MS, MATLAB, Apps, ...)? ====

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.


==== Wie können komplexe Softwarestacks veröffentlicht werden? ====

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.

==== Wie verhalten sich Versionierung und Identifier zueinander? DOI für nightly builds? ====

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).

==== Wie soll mit Schadsoftware umgegangen werden? ====

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.

==== Soll es unter Umständen Embargo-Fristen geben, in denen Code noch nicht zugänglich ist, um z.B. einem Doktoranden noch Zeit zu geben, die Doktorarbeit abzuschließen? ====

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.

Heinz Pampel:

> Ein Paper, dass Software beschreibt, scheint nur dann sinnig, wenn der Code zum Zeitpunkt der Veröffentlichung zugänglich ist. Anderfalls müsste auch überlegt werden, wie die Software begutachtet werden kann. 
==== Wie soll die langfristige Strategie eines Code Repository sein (t > 5 Jahre) ====

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.


====  Wie passen Beiträge zu FOSS und die Veröffentlichung von Code zu den Metriken der Bibliometrie und des Wissenschafts-Controlling? ====

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.

==== Welche Rolle spielen Workflows? Sind sie auch Code? ====

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 ...


Heinz Pampel:

> Mit Blick auf die Nachnutzung ist jegliche Dokumention wertvoll und sinvoll. Längerfristig müssen die einzelnen Disziplinen Stratgien entwickeln. 



===== Materialien =====

[[software:start#resources|Materialien]]

[[software:ws20130206:softwaretravel|Strategies in software travel]]


[[software:start#literature|Literatur]]


======  ======


----


Zurück zur [[software:start|Übersicht]]
DataWiki

User Tools

Site Tools

Page Tools
