Ein Katalog der DLR-Forschungssoftware für gute wissenschaftliche Praxis und mehr Open-Source
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45605 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
EnergieSoftwareOpen sourceEnergieNumberSoftware engineeringXMLUMLComputer animationLecture/Conference
00:58
Open sourceSoftware engineeringComputer programmingSoftwareSoftware engineeringOpen sourceComputer animationLecture/ConferenceMeeting/Interview
01:48
Open sourceSoftware engineeringSoftwareSoftware engineeringWissenschaftlich-technische SoftwareSoftwareComputer animation
02:23
SoftwareSoftwareLink (knot theory)Interior (topology)Computer animation
03:18
PAPSoftwareComputer animationLecture/Conference
04:21
Focus (optics)SoftwareGrand Unified TheoryAtomic nucleusFocus (optics)SoftwareSoftware developerComplete metric spaceComputer animationXMLLecture/Conference
05:22
SoftwareJavaScriptDesktopSupercomputerComputational fluid dynamicsSoftwareSAP <Marke>FORTRANProgramming languageSoftware developerNumberComputing platformComputer animation
08:00
SoftwareJavaScriptDesktopSupercomputerSoftwareSatelliteEXCELRow (database)Computer animationLecture/Conference
08:42
SoftwarePriorityRow (database)SoftwarePriorityRobust statisticsSoftware developer
09:41
CodeService (economics)SoftwareParameter (computer programming)Computer programKommunikationWeb serviceExplosionswelleEmailCodeChainingDiagram
11:10
SoftwareSoftware engineeringSoftwareLebensdauer
11:55
SoftwareSoftware developerSoftwareRoute of administrationComputer programmingLINUXSound effectWINDOWS <Programm>FactorizationVAX/VMSComputer animation
14:16
SoftwareSoftware engineeringOpen sourceSoftware developerComputer programmingComputer animation
15:14
SoftwareRoute of administrationKennzahlDDR SDRAMWissenschaftlich-technische SoftwareMusical ensembleComputer programmingALT <Programm>KennzahlMoment (mathematics)SoftwareFirmwareBackupVaporComputer animation
17:56
Software engineeringSoftware developerXML
18:32
AdditionRoute of administrationSoftware repositoryChecklistSatellite
19:07
Software engineeringSoftwareEducational softwareXML
19:57
Open sourceSoftwareCodeParameter (computer programming)
20:40
Open sourceSoftwareCodeSoftwareScalar potentialBuildingOpen sourceXML
21:18
Open sourceSoftwareCodeExplosionSoftwareOpen sourceLecture/ConferenceXML
22:16
CodeSoftwareOpen sourceRoute of administrationOpen sourceSoftware repositorySoftwareXML
23:11
SoftwareOpen sourceCodeRoute of administrationSoftwareoutputComputer animationXMLLecture/Conference
24:14
SoftwareDemo (music)SignalKommunikationOperating systemPasswordVersion <Informatik>Gateway (telecommunications)Route of administrationProxy serverService (economics)ZugriffServer (computing)Apache <Programm>Computational fluid dynamicsMathematical analysisPrototypeVersion <Informatik>Computer animationXML
25:10
SoftwareRoute of administrationInformationWeb-AnwendungWEBSoftwareComputer animationLecture/Conference
26:04
Processing <Programmiersprache>InformationRSS <Informatik>TwitterFacebookData modelSignalSoftware engineeringComponent-based software engineeringCoin <Programmiersprache>Concurrency (computer science)Line (geometry)WikiUniform resource locatorConcurrency (computer science)Computer animationLecture/Conference
27:51
SoftwareAdaptive behaviorUpdateLecture/Conference
28:53
HTMLSoftwareSoftware repositoryOpen sourceSingle-precision floating-point formatMetadataEditorArchitectureMetadataHTMLCodeSoftwareOpen sourceData storage deviceSoftware engineeringSingle-precision floating-point formatStandard deviationSoftware repositoryEditorMoment (mathematics)Computer animation
32:04
Project <Programm>InformationTexture mappingComputer animationLecture/Conference
32:43
SoftwareInformationAttribute grammarTemplate (C++)Computer animationXML
33:17
DataflowERNA <Programm>InformationSoftwareComputer animation
33:51
DatabaseSoftware repositorySoftwareMoment (mathematics)SynchronizationSoftwareOpen sourceSoftware repositoryDDR SDRAMXMLComputer animation
36:05
Enterprise architectureComputer animationLecture/Conference
36:45
Open sourceWEBMobile appOpen sourceForm (programming)SoftwareLINUXCodeZugriffMoment (mathematics)Operating systemBIBTEXDirection (geometry)Probability distributionSubversion <Programm>Kooperatives InformationssystemRoute of administrationSoftware developerComputer animation
42:36
openSUSEXMLComputer animation
Transcript: German(auto-generated)
00:07
Genau, also wie schon angekündigt geht es darum, Software zu katalogisieren und irgendwie ein Katalogsystem aufzubauen. Für die wissenschaftliche Software, die am DLR entwickelt wird, ist es nicht nur Open Source Software, es ist auch Open Source Software, aber auch die Entwicklung von Open Source im DLR,
00:23
weil wir damit ein bisschen unterstützen, wie das Ganze aussieht und was das alles miteinander zu tun hat, erzähle ich jetzt. Kurz aber erstmal die Standardfüllen zum DLR. Wir sind ein sehr großes deutsches Forschungszentrum. Forschungsgebiete sind Luftfahrt, Raumfahrt, Verkehr, Energie und Sicherheit.
00:40
Und da auf diesen Themen forschen 8.700 Mitarbeiter inzwischen etwa. Wir haben 26 Standorte neuerdings und 39 Institute und Einrichtungen. Soll jetzt aber auch erstmal stopp sein mit weiteren Instituten und Einrichtungen, das heißt, die Zahlen sollten stabil bleiben. Und in diesem DLR arbeite ich in der Software Engineering Gruppe. Das heißt, es gibt diese Einrichtung Simulations- und Softwaretechnik, die sich auf Softwareentwicklung und Softwareforschung beschränkt.
01:07
In der Einrichtung gibt es die Abteilung intelligente und verteilte Systeme, die verteilt auf vier Standorte sitzen. Und darin gibt es dann zehn Leute, die sich diese Software Engineering Gruppe nennen. Das heißt, wir beschäftigen uns mit Forschung über Software Engineering, Software Engineering Prozesse, Nachvollziehbarkeit.
01:22
Aber wir unterstützen die Leute auch aktiv bei der Softwareentwicklung in den einzelnen Forschungsprojekten, die wir so haben. Genau, unsere Themen sind Software Analytics, Software Engineering, Open Source und Community Building. Haben wir auch ein, zwei Leute inzwischen, die sich damit intensiv beschäftigen. Und seit zwei, drei Jahren sind wir auch relativ aktiv im Bereich des Research Software Engineering, die Netzwerke, die es gibt.
01:46
Aber die Liste können wir jetzt noch fortsetzen. Und derzeit sind wir konzentriert in Braunschweig, Berlin und Köln. Dann haben wir eine Person in Oberpfaffenhofen und in Bremen und haben aber auch noch einige offene Stellen. Gerade im Software Engineering erzähle ich gleich noch, wo das herkommt.
02:02
Aber damit wir jetzt mal wirklich einstellen können, habe ich mir ein paar Leitfragen ausgedacht. Die erste Frage, was hat Wissenschaft überhaupt mit Software zu tun, um diese Verbindung herzustellen? Dann ist die Frage, wie wir im DLR wissenschaftliche Software entwickeln. Und dann ist natürlich die spannende Frage, was gibt es denn für eine Software? Und da kommt genau der Katalog dann ins Spiel.
02:23
Aber erst mal zu der Frage, was überhaupt Wissenschaft mit Software zu tun hat. Viel. Denn, ach nee, jetzt habe ich erst mal kurz Definition von Wissenschaft und Forschung. Wissenschaft bezeichnet auch den methodischen Prozess intersubjektiv nachvollziehbaren Forschens und erkennt es in einem bestimmten Bereich, der nach herkömmlichen Verständnis ein begründetes, geordnetes und gesichertes Wissen hervorgibt.
02:46
Etwas sperrig, weswegen ich die rausgenommen habe, ist nur, damit ich den Link zu forschen habe. Jetzt kommt die Definition von Forschen. Und zwar unter Forschung versteht man, im Gegensatz zum zufälligen Entdecken, die systematische Suche nach neuen Erkenntnissen sowie deren Dokumentation und Veröffentlichung.
03:02
Und was hier spannend ist, ist, dass es eine systematische Suche ist. Das heißt, wir stolpern nicht über Erkenntnisse, sondern wir versuchen wirklich zu provozieren, dass wir über Erkenntnisse stolpern. Und müssen dabei aber auch dokumentieren und veröffentlichen, was wir gemacht haben, wie wir zu diesen Erkenntnissen gekommen sind. Und das lässt sich dann in der sogenannten guten wissenschaftlichen Praxis zusammenfassen.
03:23
Das ist eigentlich ein relativ fester Begriff. Und das sind so diese Leitprinzipien der Wissenschaft. Wie muss Wissenschaft sein, damit sie glaubhaft ist, nachvollziehbar ist und auch wirklich als Wissenschaft gesehen werden kann? Und ganz wichtig ist dabei natürlich das Veröffentlichen von Ergebnissen. Paper schreiben, Software veröffentlichen, auch immer.
03:41
Und wichtig dabei ist aber nicht nur einfach zu sagen, okay, ich habe das rausgefunden, sondern es muss nachvollziehbar und vollständig sein. Das heißt, jemand, der jetzt mal eine Veröffentlichung liest, muss eigentlich eins zu eins in der Lage sein, meinen Erkenntnisprozess nachzuvollziehen und zum gleichen Ergebnis zu kommen. Sonst ist es eigentlich keine gute wissenschaftliche Praxis. Was dann dazu kommt, ist auch noch, dass die Daten und Ergebnisse für lange Zeit aufbewahrt werden sollten.
04:03
So je nach Daten 10 bis 30 Jahre. Und da zählt aber nicht nur dazu irgendwie die Ergebnisse, sondern auch die Eingabedaten, auch die Experimentalaufbauten, wenn es sowas gab, oder halt eigentlich alles, was in diesen Prozess reinführt. Das ist schon ganz wichtig, dass das aufgehoben wird und halt auch in 30 Jahren noch nachvollziehbar ist.
04:21
Genau, und dann gibt es seit diesem Jahr auch eine Neufassung. Die DFG hat so eine Schrift, Sicherung guter wissenschaftlicher Praxis, rausgegeben. Gar nicht so dickes Pamphlet, was man in der Wissenschaft auf jeden Fall mal durchgelesen haben sollte. Und da sind diese Prinzipien erläutert, wie man die umsetzen kann. Und spannend ist halt, in der Neufassung von diesem Jahr ist sogar ein expliziter Fokus auf Software gelegt.
04:43
Das heißt, Software ist nicht nur ein Randthema, sondern im Kern und wird halt auch als wissenschaftliches Artefakt angesehen. Das heißt, auch auf die Software gelten die Leitprinzipien. Das heißt, auch diese Nachvollziehbarkeit und Vollständigkeit muss für Software gewährleistet sein. Und auch die Aufbewahrungsfristen gelten dann entsprechend für Software. Es ist ein großer Erfolg, dass das jetzt drinsteht.
05:01
Denn dadurch wird auch halt dieses Forschungsleben hoffentlich in Zukunft für uns Softwareentwickler ein bisschen einfacher, weil wir halt wirklich diese Software nachvollziehbar machen müssen. Genau. So, wie sieht denn Software in der Wissenschaft jetzt eigentlich aus? Oder warum brauchen wir überhaupt Software in der Wissenschaft? Moderne Wissenschaft ist im Allgemeinen eigentlich datengetrieben. Das heißt, wir haben viele, viele Daten. Experimentaldaten, Messdaten, Simulationsdaten, statistische Daten.
05:25
Die müssen alle erzeugt, ausgewertet, verglichen werden. Und das Besondere daran sind hochspezifische Daten. Das sind hochspezialisierte Formate, in denen die Daten vorliegen. Und das erfordert eigentlich schon immer individuelle Software zur Auswertung, um
05:41
diese hochspezifischen Daten verarbeiten zu können und daraus Erkenntnisse zu gewinnen. Wissenschaftler sehen natürlich keine individuelle Software zur Auswertung. Wissenschaftler schreiben einfach ihre Skripte, um ihre Daten auszuwerten. Die machen da keine Software im Eigenverständnis. Ich komme noch ein bisschen genauer zu.
06:00
Wie sieht es im DLR aus in Zahlen? Wir haben über 25 Prozent, also ich weiß nicht, wie aktuell diese Zahlen sind, aber es waren mal so über 25 Prozent des Personalbudgets, wurde auf Software-Engineering-Tätigkeiten oder auf Software-Entwicklungstätigkeiten ausgegeben. Das heißt, es gibt ganz viele Leute von den 8.700, also über 2.000 Leute im DLR, die die meiste Zeit Software entwickeln und ausgewöhnete Softwareentwickler sind darunter ganz, ganz wenige.
06:26
Das sind meistens Physiker, Chemiker, Mathematiker, die ganzen Domänenwissenschaftler, die ihre Software schreiben, um ihre Daten auszuwerten. Und dann kommt ein ganzer Zoo an Programmiersprachen zum Einsatz. Eine Studie hat man gesagt, über 70 Programmiersprachen. Ich wusste auch erst gar nicht, dass es so viele gibt, aber hatte mal angefangen zu zählen,
06:43
okay, so die Klassiker C, C++, Fortran, Python, das sind natürlich bei uns auch im Einsatz. Fortran wahrscheinlich ein bisschen mehr als in anderen Bereichen. Aber damit habe ich mich angefunden. Da gibt es noch ein paar speziellere Sachen. Also IDL, GAMS, Faro, das sind wahrscheinlich Programmiersprachen, da haben noch nicht so viele von gehört, habe ich vorher auch noch nicht.
07:01
Aber auch da gibt es verschiedene Institute, die das anwenden. Und dann haben wir natürlich auch einen Nicht-Forschungsanteil, so ein unternehmerisches Teil, und die machen dann natürlich auch mit SAP. Aber Programmierung, PHP, JavaScript, auch das ist im DLR notwendig oder komfort. Genau. Und dann ist auch das Spannende, dass wir halt für die unterschiedlichsten Plattformen
07:22
diese Software entwickeln müssen. Das heißt, wir haben nicht alles nur einen Windows-Rechner oder einen Linux-Rechner, sondern wir haben auch HPC-Systeme, wo wirklich massiv parallelisiertes Software schreiben muss. Das ist dann auch so etwas wie CFD ist, wo sehr komplizierte Software zum Synchronisieren der einzelnen Knoten, damit das schnell läuft und so etwas zum Einsatz kommt. Und dann geht es aber auch bis runter zum Embedded-Bereich.
07:42
Und Embedded klingt jetzt hier erstmal so, ja, mein Controller, aber Embedded heißt auch, wir haben Ampelsteuerungen, auf denen Software läuft, die auch den Verkehr tatsächlich regeln, da sind besondere Anforderungen. Dann haben wir auch Embedded-Software, zum Beispiel Flugkontrollsystem oder Flugsteuerungsrechner. Das heißt, Flugzeuge, die autonom fliegen, das ist natürlich auch noch ein ganz anderer Anspruch.
08:02
Oder wir haben sogar auch Embedded-Software, die im Weltraum rumfliegt. Das ist wirklich ein ganz breites Spektrum und unglaublich divers, was dann eher an Software produziert wird. Und entsprechend haben wir auch sehr unterschiedliche Ansprüche, was die Software leisten muss. Das heißt, ein Skript, das einmal so einen Datensatz von der Internetseite runterladen und Excel konvertieren soll, ist was anderes als ein Programm,
08:23
das den Bootloader von einem Satelliten darstellt, der in 30 Jahren noch ansprechbar sein muss. Genau. Und jetzt habe ich so ein bisschen mal überlegt, wie sehen denn die Wissenschaftler die Software und das da vielleicht richtig oder falsch? Also die Wissenschaftler sehen Software eigentlich im Allgemeinen als Weckwerfssoftware. Ich klammer jetzt mal explizit diese Bereiche aus, wo es um Sicherheitskritische Software gibt.
08:42
Da sind dann auch häufig schon Softwareentwickler am Gange. Aber so der große Teil der Datenauswertung ist das Weckwerfssoftware. Das heißt, das habe ich ja eh nur für einmal auch geschrieben. Die Sicherheit oder Robustheit hat entsprechend überhaupt keine Priorität. Das heißt, wenn ein zweiter Datensatz, naja, da muss ich den Skript halt anpassen, falls es abstürzt. Die Entwicklung passiert durch Domainexperten,
09:01
nicht Softwareentwickler, sondern Physiker, Aerodynamiker, Psychologen, was auch immer. Und entsprechend ist auch, wenn jemand anderes mal die Software verwenden will, ist so die Standardroutine nicht RTFM, sondern Ask the Developer. Wenn der Developer weg ist, Pech gehabt, aber meistens sind ja die Developer nicht weg. Die sind höchstens in Rente, aber die haben ja immer noch ihre private E-Mail-Adresse.
09:23
Und wir haben auch entsprechend, also ich sitze im Betriebsrat, ich sehe dann auch immer mal, was wir an Rentnerverträgen haben. Wir haben einige Rentner, die halt weiterhin beschäftigt werden, weil sie die Software übergeben sollen. Genau, also das ist so diese Mentalität, die da tatsächlich vorherrscht. Zum Glück nicht mehr ganz so doll, aber noch genug.
09:42
Aber eigentlich ist ja, wie wir schon gesehen haben, das Teil des Erkennungsprozesses. Das heißt, auch hier müssen diese Prinzipien der guten wissenschaftlichen Praxis angewandt werden. Das heißt, der Einsatz muss nachvollziehbar sein. Die Ergebnisse müssen reproduzierbar sein. Das heißt, ich brauche auch die Software und die Eingangsdaten und Parameter. Und die Daten müssen halt auch entsprechend lange aufbewahrt werden, damit in 30 Jahren auch jemand noch das nachrechnen kann.
10:04
Dann ist das andere Jahr, aber die Software ist ja sowieso nur Evolutionen. Das heißt, das hat mal ein Doktorand geschrieben und der nächste Jahr hat das weiterentwickelt. Und dass es dann so eine Verkette von Doktoranden ist, das war ja nur mal ein Prototyp. Das soll ja gar nicht weiter benutzt werden. Und 20 Jahre später hört man dann das Gleiche über die nächste Evolutionsstufe.
10:23
Oder dann halt auch so ein altes Skript. Ja, ich habe da ein Skript, das kannst du benutzen. Ich passe es dir mal schnell an und schicke es dir per E-Mail. So entsteht bei uns auch Code. Ja, entsprechend gibt es dann auch undurchsichtige Code-Migration, habe ich das mal genannt. Wenn man dann auf einmal irgendwie von einem Kollegen ein Stückchen Programm kriegt oder ein Skript kriegt und da reinguckt und dann sieht,
10:41
oh, das Stückchen da drinne habe ich mal geschrieben. Wie ist das denn da gelandet? So, das kommt auch durchaus vor. Und der Knaller ist natürlich, wenn dann jemand sagt, ja, wir benutzen hier dieses Skript. Unsere Kollegen in Brasilien oder in Uruguay sollen das jetzt auch benutzen. Ich baue mal schnell einen Web-Service außen drum. Auch das passiert leider.
11:01
Und da hat man natürlich dann auf einmal eine, das ist evolutionierte Software. Die ist dann halt da. Aber irgendwie über Gedanken, über Fehlersicherheit hat sich nie jemand gemacht, weil es ja so entstanden ist. Genau, aber was es eigentlich heißt, ist, wir haben hier eine Software mit einem sehr komplexen Lebenszyklus. Wir haben wirklich eine komplizierte Software. Und eigentlich ist das was, was man mit einem agilen Prozess gut einfangen kann.
11:22
Das heißt, ich entwickle ja Schritt für Schritt weiter, habe am Anfang noch gar kein klares Ziel. Ich weiß auch gar nicht, ob ich ein Ziel habe. So, und kann dann natürlich diese agile Methoden, ich habe zwar nicht unbedingt einen Kunden, mit dem ich Feedback haben kann, aber halt schrittweise es entwickeln, funktioniert ganz gut. Und wenn man sich diese Methoden wirklich zu Herzen nimmt, dann hat man da natürlich nicht nur den Prozess,
11:40
sondern auch das Tooling außen drum. Und er stellt dadurch, wenn man Repositories nutzt, dann hat man auf einmal auch eine viel bessere Nachvollziehbarkeit in der Software. Genau, das ist das, was wir so seit sechs, sieben Jahren unseren Mitarbeitern predigen und ist inzwischen zum Glück auch angekommen. Genau, wie können wir Software wissenschaftlich machen?
12:00
Das A und O dabei ist halt, Software muss nachhaltig gedacht werden. Das heißt, auch wenn ich nur ein Skript mal schnell haben will, sollte ich trotzdem überlegen, wie kann ich, ich kann gucken, wann das nachhaltig ist. Und Nachhaltigkeit heißt, zumindest für mich in meiner Definition, dass Nachhaltigkeit bedeutet, dass die heute eingesetzte Software auch in Zukunft noch genutzt werden kann und weiter verbessert wird. So, das ist auch wichtig, dass die weiter verbessert wird,
12:22
denn das bringt es mir, wenn die Software für den 386er noch da im Schrank liegt, aber keiner mehr eine Intel-Plattform zur Verfügung stellen kann, weil gibt es nicht mehr. Genau, das ist jetzt frei nach dem Software Sustainability Institute. Das ist eine englische Vereinigung. Die sind schon relativ lange an diesem Gedanken, dass Software nachhaltig gemacht werden muss dran
12:40
und mit denen sind wir auch inzwischen recht gut vernetzt und versuchen auch, deren Gedanken hier nach Deutschland rüberzubringen und in die deutsche Community zu verbreiten. Schließt sich da nicht Windows auf?
13:01
Ja, ist richtig. Deswegen freuen wir uns, dass es VMS gibt. Aber es ist tatsächlich so ein Faktor für gewisse... Ach so, die Frage war, ob Windows da sich nicht ausschließt. Genau, und es ist aber natürlich auch so eine Sache, die in einigen Bereichen schon Effekte erzielt hat. Also gerade die HPC-Entwicklung und sowas passiert alles auf Linux heutzutage.
13:21
Wir haben viel Linux im Einsatz, gerade bei den Softwareentwicklern. Dann gibt es die sogenannten Fair Data Principles. Das sind eigentlich Prinzipien, die für Forschungsdaten gelten, aber Software ist ja in gewisser Weise auch Forschungsdaten. Deswegen kann man die auch anwenden und die sagen einfach nur, Software soll auffindbar sein oder Daten sollen auffindbar sein.
13:42
Die müssen zugreifbar sein. Die müssen interoperabel sein. Das heißt, sie müssen damit auch arbeiten können. Und die sollten re-usable sein. Das heißt, sie sollten eine Struktur haben, dass die nicht nur zur AM-Einsatzwege sind, sondern dass sich da auch neue Forschung mit betreiben kann. Das kann man auch sehr gut auf Software anwenden. Das ist allerdings so, das Gap zwischen Software und Daten ist noch nicht ganz geklärt.
14:03
Da gibt es verschiedene Gruppen, die gerade noch ausdiskutieren, wo Daten enden, wo Software aufhört, wo aber alles das Gleiche ist. Aber trotzdem gut als Inputgeber. Und dann gibt es eine Open Science Bewegung, die nimmt gerade Fahrt auf, die sich auch darum bemüht, Forschung offener zu machen, Forschung offener zu gestalten. Open Access zählt da rein, also verpflichtungfrei zugänglich zu machen,
14:24
aber auch Software, Open Source und so weiter. Und dann gibt es noch die Research Software Engineering. Die habe ich schon mal kurz erwähnt vorhin. Das ist eigentlich auch so eine Community, die ursprünglich aus England kommt. Wir haben aber letztes Jahr den deutschen RSE-Verein gegründet, hatten auch dieses Jahr unsere erste RSE-Konferenz.
14:42
War eine sehr schöne Veranstaltung, wird es nächstes Jahr wieder geben. Und bei den RSEs geht es eigentlich darum, den Wissenschaftlern, Softwareentwicklern an die Seite zu stellen. Das heißt, ein Modus zu finden, wie kann man Wissenschaft und Softwareentwicklung besser miteinander vernetzen, sodass die Wissenschaftler sich nicht zu viel Software Engineering aneignen müssen, aber die Softwareentwickler trotzdem den Wissenschaftlern in ihrem Domainbereich, in ihrem Fachbereich helfen können.
15:04
Und wie gesagt, da ist gerade ganz viel in Bewegung. Da gibt es auch von HGF inzwischen Fördergelder für und so. Die Konferenz nächstes Jahr wieder, wie gesagt, da kann ich euch nur empfehlen, wer sich dafür interessiert, dahin zu fahren. Gut, so viel zu wissenschaftliches Software im Allgemeinen. Wie sieht es denn jetzt konkret im DLR aus?
15:21
Gute wissenschaftliche Praxis im DLR-Alltag heißt eigentlich, also wir sind in die Helmholtz-Gesellschaft Deutscher Forschungszentren eingebunden. Das heißt, für uns gelten die Helmholtz-Richtlinien. Da gibt es auch so ähnlich wie von der DFG dann entsprechende Pamplete, wo drin steht, wie Forschung zu betrieben werden hat. Und im Moment sind da sicherlich ganz groß die Kennzahlen noch im Vordergrund.
15:44
Das heißt, Helmholtz bewertet unsere Forschungseffektivität darin, wie viele Patente wir haben, wie viele Veröffentlichungen wir im Jahr machen, wie viele Trittmittel wir einwerben und so. Aber auch da ist gerade so ein gewisser Umschwung, man hat eingesehen, diese Prinzipien oder diese Kriterien sind nicht alle so unbedingt die besten,
16:00
unbedingt die vielseitigsten. Und da gibt es jetzt so zum Beispiel das HIFIS-Projekt und in dem Bereich auch noch andere Projekte auf Helmholtz-Ebene, wo gerade wirklich überlegt wird, wie können wir diese Kennzahlen besser machen, wie können wir unsere Forschungsprinzipien neu aufstellen. Und da sind wir auch dran beteiligt und versuchen da auch gut mitzuwirken.
16:20
Genau. Dann die Datenaufbewahrung im DLR hat auch ein sehr unterschiedliches Niveau. Das eine wirklich tolle Beispiel ist das Fernekundungsdatenarchiv in Oberpfaffenhofen, wo man auch heute noch 60 Jahre alte Satellitendaten abfragen kann. Die haben da wirklich sehr komplexe Mechanismen, kennen auch das Problem, dass man seine Daten alle fünf Jahre restaurieren muss.
16:40
Das heißt also spätestens dann einmal von einem Band aufs andere überspielen, damit das in fünf Jahren auch wieder funktioniert. Weil das Problem sind nicht die Medien, die kaputtgehen, sondern die Laufwerke, die nicht mehr hergestellt werden. Aber so eine Sache sind durchaus bekannt. Es gibt aber auch viele, viele Institute, die vertrauen einfach auf das Backup vom IT-Dienstleister, was gut gehen kann, was aber auch schon mal richtig schief gegangen ist.
17:03
Und da gibt es auch noch so Sachen, wo dann, das ist eigentlich schon fast Parizia jetzt hier, wo gesagt wird, wir haben ja diese Ampel da stehen, da läuft die Firmware drauf, da können wir uns ja einen Firmwaredump ziehen. Was in gewisser Weise auch, aber ist eigentlich nicht das, was mit Aufbewahrung von Software gemeint ist.
17:21
Aber auch das ist den Leuten inzwischen klar, dass das keine gute Idee ist, spätestens nachdem mal so eine Ampel ausgefallen ist und die Software weg war. Genau, aber das Schöne ist, im DLR ist da wirklich eine aktive Verbesserung zu sehen. Die Softwareentwicklungskultur wird stark unterstützt. Software wird als wissenschaftliche Daten gesehen und auch es ist bekannt, dass Softwareentwicklung einen großer Teil von dem Budget aufzehrt.
17:43
Wir haben sogar so etwas wie einen offiziellen Softwareengineering-Beauftragten vom DLR und auch hier das Institut hat seinen offiziellen Softwareengineering-Ansprechpartner, sodass wir da schon relativ gut aufgestellt sind. Also auch vom Management her, dass das eingesehen wird, dass das wichtig ist. Genau, und das Ganze ist dann in so einer DLR-Softwareengineering-Initiative zusammengefasst,
18:01
die auf vier Säulen steht. Das erste ist Networking and Collaboration. Das heißt also, wir beziehen wirklich unsere Mitarbeiter und die Institute in das, was wir als Softwareengineeringgruppen machen, ein. Dieses Softwareansprechpartner und die Softwareengineeringbeauftragte, die sitzen regelmäßig in Meetings zusammen, gucken, was ist der Bedarf im DLR, wie können wir die unterstützen und wo müssen wir unsere Personalplanung vielleicht anpassen,
18:22
damit wir unterstützen können. Auch so Networking-Events anstalten, wo dann Softwareentwickler sich austauschen können. Dann stellen wir Richtlinien und Werkzeuge bereit. Unsere Richtlinie, die wurde, glaube ich, auch schon mal vorgestellt. Deswegen hier nur kurz. Wir haben so eine schöne Checkliste ausgearbeitet, wo je nach Reifegrad der Software, sage ich mal,
18:41
es gibt Software, die ist halt wirklich nur ein Skript, und es gibt Software, die fliegt auf den Satelliten und dazwischen gibt es dann noch andere Stufen. Und je nach Stufe haben wir halt verschiedene Checklisten, wo dann drinne steht, was zu erledigen ist, welche Anforderungen zu erfüllen sind. Und dazu gibt es dann auch noch eine ausführliche Erläuterung. Die sind auch inzwischen veröffentlicht. Bei RSE-DLR.de kann man sich die angucken.
19:02
Die gibt es in Englisch und Deutsch. Schönes Ding, hilft unheimlich bei unserer Arbeit. Und das andere sind die Werkzeuge. Wir stellen supermoderne Werkzeuge bereit. Wir haben einen Mantis-Bug-Checker, der kostenlos für jeden benutzbar ist. Wir haben eine Subversion, wo Leute kostenlos ihre Projekte, aber zum Glück, wir haben inzwischen auch fast ein GitLab, wo die Leute moderne Software für ihre Repositories,
19:22
ihr Issue-Tracking benutzen können. Und das ist wie gesagt zentral bereitgestellt. Das heißt, die Projekte müssen oder die Institute müssen dafür nichts bezahlen. Die können einfach sagen, ich brauche jetzt ein Projekt und kriegen dann die Infrastruktur gestellt. Entsprechend zu den Werkzeugen und zu den Guidelines geben wir dann auch noch unterstützend Schulungen. Das heißt, wir haben inzwischen drei Schulungen im Regel deren DLR-Programm
19:44
und geben dann aber auch noch Spezialschulungen auf Anfrage, sodass die Leute mit den Tools auch umgehen können, sodass die halt auch wissen, was sie machen. Und letztlich gucken wir auch, dass wir so einen Wissens- und Erfahrungsaustausch etablieren können und stehen da als Ansprechpartner da. Genau, und jetzt endlich.
20:01
Wie sieht es denn mit Open Source im DLR aus? Open Source, also in der Wissenschaft im DLR, ich habe mal überlegt, was bei uns so für und gegen Argumente für Open Source sind. Das eine ist natürlich, Open Source ist schon nachhaltig per Sie. Das heißt, die Software ist draußen. Es gibt meistens eine Community, die sich drum kümmert. Und bevor man eine Software veröffentlicht,
20:21
hat sich auch gezeigt, meistens zieht man die Dokumentation gerade, räumt ein bisschen den Code auf, und dann hat man auch eine relativ saubere Software, wenn man die veröffentlicht. Manchmal ist es leider auch ein Hindernis, dass die Software gar nicht veröffentlicht wird. Aber wir haben auch zum Glück schon einige Beispiele, wo das sehr erfolgreich geklappt hat und einfach durch diese Open Source-Stellung die Software deutlich besser geworden ist. Und dann hat man natürlich die Community, die einspringt.
20:42
Das andere ist natürlich so aufwendig. Also man muss halt einen Open Source-Software-Entwicklungsprozess irgendwie etablieren. Das heißt, man muss auch bereit sein, mit Pull-Requests und Änderungen von außen klarzukommen. Die Software muss gepflegt werden. Und nicht nur die Software muss gepflegt werden, auch die Community muss gepflegt werden. Wir haben zwei, drei gute Beispiele, wo das sehr gut läuft. Hoffen, daraus zu lernen.
21:03
Genau. Dann ist natürlich Build Open Source ein riesiges Potential. Wenn man das erstmal veröffentlicht hat, kann man sofort einen erweiterten Nutzerkreis ansprechen. Man kriegt mit Glück Code Contributions. Das passiert zugegebenermaßen leider selten. Aber auch schon der erweiterte Nutzerkreis ist eine sehr, sehr wertvolle Quelle für Issue Reports und Requests,
21:23
wo man nachgucken muss bei meiner Software. Jetzt sehe ich nachher noch was drüber. War das super toll, als dann zwei Leute mich anriefen, ich habe deine Software mit drin gefunden. Das geht nicht. Okay, so habe ich das noch nie benutzt. Und das ist schon ein sehr, sehr wertvolles Feedback. Genau. Aber es birgt auch Risiken. Gerade im wissenschaftlichen Bereich
21:40
darf man das nicht unterschätzen. Thema Exportkontrolle. Wir arbeiten mit Raketen. Alles, was irgendwie mit Raketen zu tun hat, ist fast immer do-use und unterlegt entsprechend dann Exportkontrollen. Die kann man nicht einfach so Open Source. Da muss man gucken, wie man das vielleicht zurechtneidet oder so. Das andere ist Lizenzprobleme. Also Software, die von Anfang an als Open Source konzipiert wurde, da kann man das natürlich tracken und überlegen und nachvollziehen.
22:02
Ja, ist diese Software jetzt, kann ich die benutzen oder nicht? Aber häufig ist es ja so, dass da ein Schnipsel aus Numerical Recipes reinkopiert wurde. Da hat man jemand von irgendjemandem eine Library gekriegt und dann wird das zusammengestückt. Dann heißt das, jetzt wird das Open Source. Dann muss erst mal durchgegangen werden. Was muss ich alles rausschmeißen? Genau. Um diese ganzen Sachen, also auf der Open Source Initiative zu unterstützen,
22:22
haben wir auch im DLR so eine Open Source Initiative, wo wir Ausschulungen und Workshops anbieten, auch ein bisschen Unterstützung bieten. Zum Beispiel durch Rechtsberatung auch. Da haben wir Anwälte im Boot. Wir machen Lobbyarbeit bei Führungskräften. Auch gerne, wenn man uns anspricht. Und dann haben wir auch noch die Idee gehabt, was wir gerade ein bisschen versuchen zu etablieren,
22:42
Inner Source. Inner Source ist wie Open Source nur nicht open. Aber man kann eigentlich die ganzen Open Source Praktiken im Unternehmen weit einsetzen. Das heißt, nicht ein Institut entwickelt die Software, sondern alle Mitarbeiter dürfen in der Software mitarbeiten. Da kann man diesen Open Source Prozess kennenlernen. Man kann seine Software auf Open Source vorbereiten und hat dann nur noch einen kleinen Schritt,
23:01
dass man nur noch das Repository auf public stellen und dann ist es Open Source. Das wird auch relativ gut angenommen. Diese Idee des Inner Source ist erst mal deutlich populärer als Open Source. Das ist die ganze Software, die jetzt entsteht. Das müssen wir auch irgendwie kennen. Deswegen ist auch ein Teil der Nachhaltigkeit
23:20
diese Auffindbarkeit. Das ist tatsächlich ein großes Problem, weil jedes Institut entwickelt seine eigene Software. Die Institute sind teilweise über uns verlinkt, teilweise direkt verlinkt, aber teilweise auch gar nicht verlinkt. Auch wenn zum Beispiel Gewässerferienerkundung auf den ersten Blick nicht viel mit solathermischen Kraftwerken zu tun hat, gibt es da doch unter Überschneidung,
23:40
wo man sagt, okay, aber ihr wickelt doch eigentlich die gleiche Software wie die. Ach, mit denen hat man ja noch nie was zu tun. So eine Sache. Das ist natürlich wichtig, so einen Katalog zu haben. Ziel ist natürlich dann einen möglichst vollständigen Überblick über die DLR-Software zu kriegen, die Software auffindbar zu machen, intern erst mal, aber auch gegebenenfalls extern, weil GitLab ist kein Software-Katalog.
24:01
GitLab kann man nicht vernünftig suchen. Anderes Ding ist, Software, wenn das als wissenschaftliche Input gilt, soll ja auch referenziert und zitiert werden. Und das wollen wir mit dem Katalog auch versuchen zu erreichen, dass das besser geht. Und letztendlich natürlich dann auch zu sagen, okay, jetzt habt ihr das eh schon veröffentlicht, ihr benutzt ein In-The-Source-Projekt, das macht es doch eigentlich für Open Source, diese Motivation ein bisschen zu stärken.
24:22
So, und jetzt kommt eine, nein, es kommt keine Live-Demo. Das ist zum einen viel zu riskant. Zum anderen arbeiten wir noch mit einem Prototypen. Aber ich stelle jetzt mal ein bisschen die Evolution dar. Die erste, ich bin jetzt sehr froh, auch einen der Originalentwickler mit Ihnen im Saal begrüßen zu dürfen. Das ist die erste Version von unserem Software-Katalog.
24:41
Das war damals eine Intranet-Anwendung, für jeden verpflichtend zu benutzen. Das heißt, jeder, ich glaube, von wann wurde die entwickelt? 2000 rum oder so. Schon damals war verpflichtend für alle DLR-Software-Entwicklungen, dass die in diesem Katalog erfasst werden. Und das hat sogar überraschend gut funktioniert. Also der war ziemlich umfangreich gefüllt, aber sehr schlecht gepflegt leider.
25:01
Also einmal eingetragen, ja, aktualisiert fast nie und noch seltener benutzt zum Suchen. So, leider ein bisschen schade. Aber wir haben draus gelernt, also was echt gut gelaufen war, dass der Eintrag verpflichtend war. Und dass es eine Web-Anwendung war, ist natürlich auch eigentlich heutzutage notwendig,
25:20
um das allen zugänglich zu machen. Das Interface war halt ein bisschen umständlich. Man musste wirklich viele Informationen eingeben, ablegen. Die mussten wir dann auch an zwei Stellen mit unterpflegen oder mehreren Stellen. Deswegen waren Einträge häufig nicht aktuell, wie gesagt, schon kaum zum Nutzen gesucht. War auch echt schwierig, die Suche da, weil man hatte dann sehr spezielle Suchfelder, wo man dann sehr spezielle Suchbegriffe eingeben konnte.
25:40
Und die kann man eigentlich nur kennen, wenn man weiß, dass die Software existiert. Genau, und hat auch nach außen keine Sichtbarkeit erzeugt. War auch damals nicht das Ziel davon, aber das ist jetzt eins unserer Ziele auf jeden Fall. Dann gab es vor 10 Jahren, glaube ich, inzwischen auch schon fast den zweiten Ansatz.
26:00
Da haben wir Software-DLR. Das war eigentlich so, wo es fing an. Mein Chef hat die Domain-Software-DLR registriert. Da hieß es, was packen wir jetzt da hin? Schnell klar, ja, so ein Software-Katalogsystem wäre schon gut. Und dann hat er auf einer Konferenz die Leute von Allura kennengelernt und hat gesagt, hey, Allura ist toll. Die benutzen wir für unseren Software-Katalog. Wir haben uns angesetzt und dann Allura angepasst, dass es dieses schöne DLR Corporate Identity hat,
26:22
schön ansprechend aussieht. Schön, wie an dem Beispiel ist auch, zufällig steht da Bacardi gerade. Da ist nachher noch ein Vortrag zu, hier im Raum. Kurze Werbung, lohnt sich ihn anzugucken. Aber was war denn in der zweiten Generation? Das Gute, wie gesagt, dieses ansprechende Design war schon sehr schön. Das hat auch einige Leute dazu gebracht,
26:41
die Software-DLR-Seite als ihre primäre Einstiegsseite für ihr Projekt zu haben. Und es gab auch eine schöne Wende hier, also die Software-DLR.de slash P slash und dann der Projektname, ist schon leicht zu merken, ist schön, kann man nach außen gehen, muss man sich nicht für schämen, wie wenn man eine DLR Internetseite oder DLR.de Web-ID, zack, und dann eine 20-zeichenlange UUID.
27:01
Und auch das Anlegen und Bearbeiten der Einträge war sehr einfach. Das war im Prinzip ein Wiki mit zwei, drei zusätzlichen Kategorisierungsfeldern. Wurde trotzdem leider kaum genutzt, weil wir das auch nicht publizieren oder zu breit treten wollten durften, weil das war halt nichts Offizielles von BDR. Das war so ein Schnellschuss von uns.
27:22
Und dann war es eine richtige Spatzenkanone. Also wir haben, wie gesagt, Alura. Alura ist die Software, auf der SourceForge läuft. Und SourceForge ist natürlich ein mächtig featurereiches Ding, was eigentlich sogar noch mehr kann als GitLab. Aber wir haben unser eigenes Software, es hat Virtual Mantis bzw. GitLab jetzt zum Glück. Dazu durfte es keine Konkurrenz sein.
27:41
Das heißt, Repository Hosting Issue war schon mal gestrichen. Und die anderen Features bringen dann auch nicht mehr viel. Und dann war es letztendlich ein aufgeblasenes Wiki auf Alura-Basis, was einfach den Wartungsaufwand und die Zeitintensivität da nicht gerechtfertigt hat. Weswegen wir es dann glücklicherweise dank DSGVO abschalten durften.
28:01
Ich habe dann meinen Chef gesagt, hier, pass mal auf, also entweder muss ich jetzt zwei Wochen DSGVO hier machen oder wir schalten die ab. Ich habe gesagt, na gut, dann schalten wir sie ab. Genau. Aber die Idee dahinter ist trotzdem geblieben, wir wollen immer noch einen Software-Katalog, aber jetzt sind wir in der dritten Generation so. Und ich finde, drei Generationen darf man sich erlauben, aber jetzt sollten wir schon einiges richtig machen.
28:21
Deswegen haben wir unsere Lessons learned gezogen, wir haben unsere Lehren gezogen. Das heißt also, wichtig ist, es muss ein erkennbarer Mehrwert für die Nutzer da sein. Sonst wird er nicht benutzt. Und wenn er nicht benutzt wird, dann kann man sich den ganzen Aufwand völlig sparen. Wichtig ist halt auch, dass geringer Eingabeaufwand ist. Das heißt, man muss einfach einen Eintrag anlegen können.
28:40
Es muss einfach sein, den zu bearbeiten. Es muss kein großer Pflegeaufwand geben. Auch der Wartungsaufwand für die Software selber sollte so gering wie möglich sein. Das heißt, Updates installieren sollte nicht irgendwie noch einen Rattenschwanz an Anpassungen in der Nachsicht ziehen. Entsprechend wollten wir auch möglichst wenig selbst entwickeln. Und damit auch versuchen, die Wiederverwendbarkeit zu erhöhen.
29:03
Daraufhin haben wir angefangen, verschiedene Techniken zu erproben. Zum einen versuchen wir, gerade einen Ansatz, wo wir startendes HTML mit Jekyll ausliefern, ist am einfachsten. Da hat man eigentlich gar keine Skripte, muss auf sich um Sicherheit eigentlich keine Gedanken machen und hat ein relativ robustes Framework, das weit in der Entwicklung ist.
29:20
Aber an der Stelle muss man natürlich auch sagen, Jekyll ist kein Softwarekatalog, Jekyll ist eine Blogsoftware. Das heißt, ein bisschen tricksen muss man da schon. Dann gibt es auch ein Research Software Directory. Das sind Kollegen aus Holland, die haben da eine Software entwickelt, die wir uns auch gerade angucken. Die sieht auch sehr spannend aus, aber ist natürlich jetzt auch wieder ein recht umfangreiches Softwarepaket, wo man dann auch gucken muss, wie man das installiert kriegt,
29:41
wie man das wartet. Das ist nicht mehr einfach nur so ein, ich starte ein Jekyll-RB und dann läuft alles durch. Genau. Und dann ist es halt auch ganz wichtig, Grundlage soll auf jeden Fall Repository Mining sein. Das heißt, wir haben jetzt schon eine zentrale Infrastruktur, auf der die Software entwickelt wird. Das heißt, wir wollen auch möglichst viel Daten da rausziehen, dass wir halt nicht alles doppelt pflegen müssen, dass da kein doppelter Wartungsaufwand entsteht
30:01
und die Daten nicht auseinander fließen. Und wir wollen halt auch entsprechend einen Single Source idealerweise haben und haben da zwei ganz spannende, moderne Standards rausgesucht. Einmal Citation-CFF. Das ist eine Möglichkeit, um ZITI-Informationen an Software ranzuhängen. Und dann Code MetaJSON. Das geht über die Zielbarkeit noch hinaus. Da kann man wirklich Meta-Informationen zum Code
30:21
in einem Repository in einem JSON-Format speichern. Genau. Und ich will jetzt mal dieses Tool, das wir mit Jekyll, das ist der Prototyp, der im Moment am weitesten ist. Der ist auch inzwischen weiter als was ich hier auf dem Folien habe, weil mein Student eine Woche weiterentwickelt hat. Genau. Das sieht im Prinzip so aus. Wir haben einen Metadaten-Editor. Das ist eine eigenentwickelte Flask-App.
30:43
Und diese Flask-App holt sich aus einem GitLab die Information, die es kriegt, generiert daraus eine CodeJSON-Meta, die man auch über den Editor wieder editieren kann. CodeJSON, damit das, so haben wir uns ausgesucht, weil das eine gut analysierbare, computerlesbare Quelle ist. Hohe Transparenz.
31:01
Das Format ist offen dokumentiert. Es steht auch im Kunstkreis von Open Science, Research Software Engineering und so. Er ermöglicht auch Zitierungen. Das heißt, da steht explizit drin, bitte zitiere mich so. Und viele Third-Party-Tools fangen auch gerade an, diese zu unterstützen. Also sowas wie Zenodo zum Beispiel kann inzwischen CodeJSON, Meta.
31:22
Und ich glaube GitLab kann das auch inzwischen. Aber auf jeden Fall so Trittanbieter sind da immer mehr dabei, das auch zu adaptieren. Die wird natürlich dann auch, wenn sie noch nicht existiert, ins Repository zurückgespielt, damit die Daten wirklich an einer zentralen Stelle liegen. Das heißt, man kann das dann von Hand editieren, kann trotzdem weiter auch diesen Metadaten-Editor benutzen. Und daraus haben wir dann einen kleinen Page Generator,
31:41
der nimmt das JSON und schreibt es in eine Project-MD-Datei, also so eine Markdown-Datei, die dann durch Jekyll ausgeliefert wird. Relativ einfaches, überblickliches System. Wir haben zwei kleine Komponenten, die selbst entwickelt wurden. Aber das eine ist halt wirklich ein standardisiertes Schnittstellenformat, was wir benutzen. Und das ist natürlich ganz gut, dass wir hier einen eigenen Adapter haben, weil da kann man dann das hinten auch nochmal relativ einfach austauschen.
32:05
Genau, wie sieht das jetzt aus? Ich habe noch ein paar Screenshots. Man fängt an, man kommt auf so eine Seite. Und hier muss man seine GitLab-ID von dem Projekt eingeben. Und dann legt der Crawler los und sucht erstmal alles an Information raus, was er findet. Dann kommt man auf die nächste Maske,
32:20
wo man dann tatsächlich den Projekteintrag anlegen muss. Da gibt es ein paar Daten, ein paar Pflichtdaten. Dann gibt es so ein paar Daten, die wurden gemeint und kann man aber hinterher noch editieren. Und dann gibt es auch Daten, die sind halt als nicht erinnerbar angezeigt. Zum Beispiel den Projektnamen, der wird aus dem Projekt geholt. Der sollte nicht geändert werden, damit dieses Mapping klar ist.
32:41
Was auch ganz spannend ist, wir haben ja gewisse Dokumentationspflichten gegenüber unseren Aufwendungsgebern. Das heißt, wir müssen für Software dokumentieren, aus welchen Geldtöpfen was wo irgendwie geflossen ist. Und so eine Attribute können wir natürlich dann hier auch direkt mit einbauen, mit erfassen. Und dann haben wir auch diese Informationen gleich mit. Ich glaube, es gab sogar mal eine Richtlinie, dass es auf den Softwareseiten mit angezeigt wird,
33:01
aus welchem Programm, Luftfahrt, Raumfahrt, die Gelder kamen, ist dann damit auf jeden Fall möglich. Und dann gibt es auch eine Liste, die sieht sehr ähnlich aus, wie die, die wir vorgesehen haben, liegt daran, dass das gleiche Template verwendet wurde. Aber jetzt hat man also tatsächlich diese Liste, die ist auch ein bisschen voller.
33:24
Man kann dann raufklicken und hat dann halt hier zu den einzelnen Projekten wirklich schöne Informationen. Das heißt, das Projekt, es gibt die Links zu den einzelnen Repositories und so weiter. Man kann da auch einen kleinen Text reinschreiben, der das beschreibt. Das heißt, man hat jetzt wieder eine Seite, die man auch tatsächlich rausgeben kann als Projektseite, die dann auch ein bisschen repräsentativ ist, ansprechendes Layout und so weiter.
33:44
Was noch nicht klappt, aber was wir bestimmt auch noch hinkriegen, sind Vanity URLs, damit das dann wirklich unser zentraler Punkt für die Software wird. Genau, dritte Generation, jetzt auch wieder Pro und Contra. Was läuft gut? Ja, fertiges Softwareverbinden hat sich alles gut rausgestellt. Wenig Aufwand bei der Entwicklung, trotzdem mehr, als wir das ursprünglich gehofft hatten.
34:05
Das einfache Anlegen und Bearbeiten von den Einträgen ist super gut. Auch das Repository halten wir nach wie vor als genau die richtige Stelle, um diese Daten abzulegen, damit keine notwendige Synchronisierung stattfinden muss. Das Design ist jetzt ansprechend und ist nach außen sichtbar. Also noch nicht, aber wird es dann sein, sobald es fertig ist. Das Problem dabei ist, im Moment haben wir noch keine Finanzierung dafür,
34:24
obwohl wir hoffentlich welche kriegen, aber wir haben tolle Studentenprojekte, also wer als Student im DLR arbeiten will. Und das andere ist dann leider noch nicht fertig, sonst hätte ich das jetzt hier auch mal im fertigen Zustand gezeigt. Aber es ist auf jeden Fall ein ganz spannender Ansatz, den wir weiter verfolgen. Genau, jetzt bin ich soweit auch schon durch.
34:42
Zusammenfassend vielleicht noch kurz zu sagen, wir haben gesehen, Wissenschaft braucht Software. Die Software ist halt essenzieller Teil des Erkennungsprozesses. Man muss deswegen nach guter wissenschaftlicher Praxis entwickelt und gepflegt und aufbewahrt werden. Open Source Ansätze fördern Nachhaltigkeit von Software, sind deswegen eigentlich gut für wissenschaftliche Software, wenn man die Probleme, die ich vorhin aufgezählt habe, umschliffen kann.
35:04
Wichtig ist aber auch, dass Software auffindbar sein muss. Das heißt, wir brauchen Kataloge, aber diese Kataloge sind auch kein Selbstzweck, sondern die müssen auch für den Nutzer einen Mehrwert erstellen. Das heißt, einerseits haben wir die, die die Software suchen wollen, andererseits haben wir die, die die Software anbieten und die die Software anbieten, machen das nicht aus,
35:21
stellen die nicht aus reiner Menschenliebe ins Repository oder in einen Katalog ein, sondern die müssen da einen Mehrwert draus sehen. Oder zumindest eine möglichst geringe Schwelle haben. Wichtig ist aber auch, dass man nicht unterschätzen darf, dass so eine Entwicklung und Pflege von einem Softwarekatalog doch aufwendig ist. Auch wenn man das mit bestehender Technik macht, darf man das nicht unterschätzen.
35:41
Wir kriegen eigentlich täglich neue Issues und welche neuen Vulnerabilities werden veröffentlicht. Und da guckt man immer, die Bibliothek, die sitzt doch irgendwo bei uns mit drin und dann fängt man an zu warten, so eine Sache oder halt auch alles Mögliche, andere. Irgendwer stellt ein Bug fest. Dann habe ich kurz nochmal gezeigt, wie die Software-DLR-Kataloge im Manöver der Zeit aussahen,
36:02
wie sich das entwickelt hat, wo da unsere Schwerpunkte waren. Jetzt bin ich bereit für Fragen und lade auch alle ein, uns an unserem Stand zu besuchen.
36:22
Hallo? Perfekt. Habt ihr mal überlegt, euren Software-Katalog tatsächlich zu versuchen zu öffnen? Mir ist mit sehr hoher Sicherheit bekannt, dass dieses klassische Discovery-and-Selection-Problem, was ihr da letztendlich liegen habt, absolut bekannt bei großen Enterprises ist
36:41
und da regelmäßig Dinge gebaut werden wollen. Wenn du mehr Details wissen willst, das kann ich unter vier Augen erzählen. Das und die auch sehr, sehr ähnlich aussehen teilweise. Und ich denke, wenn man sich anschaut, was Linux letztendlich gewesen ist, das ist mittlerweile letztendlich die fette Shared-Commodity, auf die alle draufgehen, weil Betriebssysteme selber bauen, nein.
37:04
Das wäre nicht sinnvoll. Das kann ich mir vorstellen, dass ihr da mit Firmen, die da wirklich mit sehr harten Ressourcen reingehen, vielleicht auch noch ein bisschen was gewinnen könntest. Habt ihr das versucht, das mal zu machen? Wir sind gerade dabei. Wir machen ja gerade hier eine Präsentation.
37:21
Es ist eine Veröffentlichung. Wir sind im Moment nur unter Studenten, aber durch dieses heifeste Projekt hoffen wir, dass wir da ein bisschen Ressourcen drauf kriegen können und dann auch damit wissenschaftliche Arbeit natürlich. Hatten jetzt andere Probleme, zum Beispiel das GitLab im DLR zu etablieren und auszurollen. Und ja, auch wenn zehn Leute viel klingt, so viel ist es nicht.
37:42
Die zweite Frage, die ich hätte, du hast in der Source erwähnt, an der Stelle, da geht es ja letztendlich unter anderem auch darum, Communities innerhalb von Firmen, um solche Software zu erzeugen. Und ich glaube, ich hatte von deiner Kollegin schon gehört, dass es da ein relativ populäres, geschertes Projekt gibt und auch andere.
38:00
Habt ihr irgendwelche Formen von Messwerten über die Gesundheit oder Größe von Communities? Weil letztendlich ist das ja interessant zu schauen, was als Projekt besonders interessant sein könnte, dass man da eventuell mehr Unterstützung reinsetzen kann, damit es dem Projekt noch besser geht? Da sind wir auch noch am Anfang. Aber es gibt diesen Wissensaustausch-Workshop im DLR.
38:21
Das ist so ein Workshop, den wir immer im Jahr veranstalten, wo alle Softwareentwickler aus dem DLR eingeladen sind, zusammenzukommen. Und den machen wir jetzt seit fünf Jahren. Da haben wir jetzt so eine erste Community-Auswertung mal gemacht. Wir haben daraus einiges gelernt. Aber es ist auf jeden Fall etwas, was auch im Rahmen des Repository-Minings und der Softwareanalytik-Tätigkeiten auf dem Plan steht.
38:41
Da gibt es tatsächlich, kann ich dir später gerne erzählen, zum Beispiel die Chaos-2 Suite. Die würde dich sehr interessieren. Ja, erstmal vielen Dank, Michael, für den Vortrag. Meine Frage geht in die Richtung dann, wenn ich ja Software entwickle,
39:00
dann habe ich einmal vielleicht Entwicklungs-Repositories, aber ich habe natürlich auch Release-Repositories. Zum Beispiel der Ansatz der CondaForge-Community, die ja dann, wo ich ja quasi ein ganz kleines Metabeschreibungsformat als Anwender ablege und dann dadurch CIs nutzen kann, die mir die Software bauen,
39:24
wo ich quasi einen direkten Mehrwert habe. Das ist ja eigentlich eine unglaubliche Anziehungskraft, wenn man das in dieser Weise halt umsetzt. Also das wäre für mich ein großer Mehrwert, warum ich dann in so einem System meine Software hineintransportieren würde.
39:42
Ich nehme an, bei euch ist das ähnlich wie bei uns, dass die bekannten Projekte eigentlich auf eigenen GitLab-Instanzen oder in größeren Repositories eigentlich schon beheimatet sind. Wie geht ihr damit um? Nicht nur. Also wir haben auch große Projekte,
40:01
die bei uns im zentralen Subversion oder dann im GitLab liegen. Aber ja, wir haben auch viele Tritt-Repositories, aber wir wollen eigentlich gucken, dass wir auch andere Propositorios als nur unser GitLab crawlen können. Die Idee ist, dass wir die dann direkt mitcrawlen. Und das Gute ist, wenn es im DLR ist, wir sind ein DLR, das heißt, wir kriegen eigentlich schon Zugriff auf den gesamten Datenschatz.
40:21
Das andere Problem ist natürlich, nicht alle Software darf nach draußen veröffentlicht werden. Da müssen wir auch aufpassen, dass wir da nicht zu viel einsammeln bzw. auch entsprechende Rechte verteilen. Aber in dem Moment, wo es open source ist, darf es ja überall liegen? Wenn es open source ist, ja, aber wir wollen ja nicht nur unsere open source Software erfassen.
40:46
Was habt ihr vor, um die Nützlichkeit des Katalogs zu messen? Gute Frage, da haben wir uns noch keine Gedanken darüber gemacht. Also sicherlich ist die Nutzerzahl oder die Anzahl der eingetragenen Projekte schon ein erster Richtwert.
41:01
Also die Frage war nach der Nützlichkeitmessung von der Software, ein erster Richtwert natürlich zu gucken, wie viele Nutzer haben wir in der Software, wie viele andere Fragen haben wir auch. Und wie gesagt, bei einigen Projekten haben wir auch schon direkt das Feedback, dass ihre Software über Software.de überhaupt erst mal gefunden wurde. Aber systematisch haben wir da noch keine Ideen.
41:26
Hallo, interessanter Vortrag. Eine Frage, wenn ich jetzt als Wissenschaftler irgendein Software von diesem Katalog verwenden möchte, typischerweise will ich die ja dann zitieren. Ist das möglichst einfach dargestellt? Wie habt ihr das so dargestellt? Oder wie habt ihr das vor darzustellen?
41:41
Also wir haben vorgesehen, also die Frage ist, wie die Zitierbarkeit in dem Softwarekatalog dargestellt wird. Wir haben ein DOI-Feld vorgesehen, wenn es so etwas gibt. Und durch dieses Code Meta einfachen wir natürlich auch die Veröffentlichung auf irgendwelche Repositories. Es ist auch gerade in der Diskussion, ob das TNR nicht ein eigenes DOI-Repository bekommen will, soll, darf.
42:04
Aber wir gehen da auf jeden Fall ganz klar Richtung DOIs. Und ansonsten gibt es dann sicherlich auch einen Link, hier Citation generieren, damit das funktioniert, wenn die Daten da sind. Das kann man ja dann aussuchen aus dem Code Meta. Also da haben wir auf jeden Fall schon Konvertierungstools, die Code Meta
42:23
in verschiedene Formate, Bibtex haben wir, Text haben wir und noch zwei andere. Gibt es eine Frage? Das scheint nicht der Fall zu sein. Dann danke ich nochmal sehr schön für den Vortrag.