Open Development of Scientific Software

Revolutionierung der Forschung mit kollaborativer Software-Infrastruktur

Geschrieben von Max Schulz

Die Revolution von Open Source

Bild generiert von Stable Diffusion: "Ein Programmierer, der sich auf den Schultern von Riesen ausruht" (Meine Souffleurtechnik ist eindeutig verbesserungswürdig)

Haben Sie jemals darüber nachgedacht, dass die Technologie, die wir täglich nutzen, größtenteils auf der Arbeit von Freiwilligen basiert? Die Open-Source-Bewegung hat die Technologiebranche revolutioniert, indem sie Einzelpersonen und Unternehmen den freien Zugriff, die Änderung und die Verbreitung von Quellcode ermöglicht hat. Dabei geht es jedoch nicht nur darum, ein paar Dollar für Softwarelizenzen zu sparen. Die Open-Source-Bewegung hat ein Gefühl der Gemeinschaft und Zusammenarbeit gefördert, was zu einigen der am weitesten verbreiteten Projekte in der Branche geführt hat.

Angefangen hat alles in den Anfängen der Informatik, als Software unter Akademikern und Forschern frei ausgetauscht wurde. In den späten 1980er- und frühen 1990er-Jahren wurde der Begriff "Open Source" geprägt und die Bewegung begann, an Fahrt zu gewinnen. Zu den prominenten Persönlichkeiten dieser Zeit gehört Richard Stallman, der Gründer der Free Software Foundation und des GNU-Projekts (zu dem auch der beliebte Compiler GCC gehört). Er plädierte für eine recht strenge Definition der Bewegung, die es jedem gestattete, Open-Source-Code zu verwenden und zu verkaufen, aber die Entwickler dazu verpflichtete, ihre Software ebenfalls als Open-Source zu veröffentlichen (er verfasste die meist als "restriktiv" bezeichnete GPL Lizenz).

Erst Ende der 1990er und Anfang der 2000er Jahre begann Open Source wirklich für Aufsehen zu sorgen. Die Veröffentlichung des Linux-Betriebssystems und des Apache-Webservers bewies, dass Open Source nicht nur rentabel, sondern auch äußerst erfolgreich sein kann. Große Unternehmen wie IBM und Red Hat erkannten das Potenzial und begannen, in Open-Source-Projekte zu investieren und diese zu unterstützen.

Open Source ist heute allgegenwärtig. Es ist schwer, eine Technologie zu finden, die nicht in irgendeiner Weise von Open Source beeinflusst wurde. Von mobilen Betriebssystemen und Cloud-Infrastrukturen bis hin zu maschinellem Lernen und Datenanalyse – Open Source ist zu einem festen Bestandteil der Technologiebranche geworden.

Einführung in der biowissenschaftlichen Industrie

In diesem Artikel möchte ich die Open-Source-Entwicklung aus der Sicht eines Software- und Dienstleistungsanbieters in der Life-Science-Branche beleuchten. Es gibt zwar viele Artikel über die allgemeine Akzeptanz von Open-Source-Software (und Bücher zur Bewertung von Projekten für den Einsatz) und relativ gesunde Marktprognosen für den Open-Source-Dienstleistungsmarkt (z. B. dieser Bericht), aber es gibt nicht so viel Inhalt über die tatsächlichen Beiträge zu anderen vertikalen Branchen ausser der Software (z. B. Biotechnologie oder Produktion).

Meiner Erfahrung nach ist die Übernahme von Open-Source-Prinzipien in anderen Branchen im Vergleich zur "Tech-Industrie" (die irgendwie anfing, nur Elektronik und Softwaretechnologie zu berücksichtigen) immer noch rückständig. Zwar ist es auch in der Tech-Branche schwierig, Finanzmittel zu bekommen (guter Artikel von James Turner), aber es gibt große Stiftungen wie die Apache Software Foundation oder die Linux Foundation. Die Zahl der Menschen, die z. B. ein Webserverprogramm nutzen, könnte eine nachhaltige Finanzierung durch Spenden (z. B. durch GitHub-Sponsoren oder Open Collective) zumindest denkbar machen.

In Nischenbereichen wie der Verwendung von Open-Source-Software in der wissenschaftlichen Arbeit ist die Situation eher schlecht. Obwohl klar ist, dass die jüngsten Durchbrüche ohne sie nicht möglich gewesen wären (siehe diese Analyse der Chan Zuckerberg Initiative), erkennen die meisten öffentlichen Förderorganisationen ihre Bedeutung nicht an.

„Sie finanzieren 50 verschiedene Gruppen, die 50 verschiedene Algorithmen entwickeln, aber sie bezahlen keinen einzigen Softwareentwickler.“ – Anne Carpenter

Erst seit kurzem werden Stimmen laut, die sich mit dem Problem der Finanzierung von Software-Infrastrukturen für die Wissenschaft befassen. Wie Adam Siepel oder Anna Nowogrodzki beschreiben, müssen Forscher im Rahmen ihrer Forschung in der Regel neue Tools programmieren, ohne dafür Anerkennung oder eine entsprechende Ausbildung zu erhalten. Wenn der Wartungsaufwand für ein Open-Source-Projekt steigt – insbesondere wenn es erfolgreich wird –, haben Wissenschaftler möglicherweise keine andere Wahl, als ihre Bemühungen aufzugeben, da nur „reine wissenschaftliche Arbeit” anerkannt und finanziert wird.
Glücklicherweise ändert sich dies langsam, zumindest im wissenschaftlichen Bereich. Große private US-Stiftungen richten spezielle Förderprogramme ein, wie beispielsweise das Förderprogramm „Essential Open Source Software for Science” der Chan Zuckerberg Initiative. Darüber hinaus hat die National Science Foundation (NSF) ein passendes Programm namens „Pathways to Enable Open-Source Ecosystems (POSE)” ins Leben gerufen (erste Vorschläge im Jahr 2022).

Im Gegensatz dazu gibt es im kommerziellen Biotechnologiesektor nur sehr wenige Aktivitäten bei der Finanzierung und den Beiträgen zu gemeinsamen Open-Source-Bemühungen. Dies hat seine Ursache in zwei Hauptfaktoren: Der fehlende Fokus auf die Softwareentwicklung und die fehlende Kultur der gemeinsamen Nutzung.

Schwerpunkt Software-Entwicklung: Traditionell wurden Software und IT-Infrastruktur als reine Kostenstellen betrachtet und nicht als Expertisen, die einen Wettbewerbsvorteil schaffen. Neue Unternehmen in diesem Bereich ändern diese Dynamik langsam mit einer neuen Generation von "Techbio"-Startups, die Softwareentwicklung als explizite Kerntätigkeit definieren.

Fehlende Kultur der gemeinsamen Nutzung: Nirgendwo ist der Schutz des geistigen Eigentums so stark wie im Biotech-Sektor, insbesondere bei der Arzneimittelentwicklung. Verglichen mit Patenten in der Softwarebranche, die relativ wertlos sind, ist ihr Wert für Pharmaunternehmen enorm, und ihre Schaffung könnte als ihre "Daseinsberechtigung" angesehen werden. Es gibt vorwettbewerbliche Bemühungen wie die Pistoia Alliance. Dennoch bin ich der Meinung, dass noch viel mehr getan werden muss, um das Gefühl zu fördern, dass die gemeinsame Nutzung von Werkzeugen und Infrastrukturen allen zugute kommt.

Die "Stimmung" in der Branche ändert sich langsam, da jüngere Unternehmen wie Colossal Software-Ausgründungen wie Form Bio aufbauen und Mitglieder großer Pharmaunternehmen wie Roche ihre Verwendung von Open-Source-Tools wie Arvados oder Camunda befürworten.

Strategien für den Erfolg

Ein Projekt wird in der Regel von einem oder einer kleinen Anzahl einzelner Mitwirkender gestartet. Beispiele aus der Biotech-Branche sind MultiQC von Phil Ewels, PyLabRobot von Stefan Golas oder Poly von Timothy Stiles. Die Initialzündung für ein neues Projekt kommt in der Regel von einem Bedarf, der in verschiedenen Zusammenhängen entsteht:

• Kontext der wissenschaftlichen Arbeit (indirekt durch ein Forschungsstipendium finanziert)
• Kontext eines Projekts für einen Kunden (möglicherweise direkt finanziert)
• Kontext der Produktentwicklung (in der Regel vom Arbeitgeber finanziert)

Die anfängliche Arbeit ist in der Regel inspirierend, und man muss sich nicht viele Gedanken über die langfristige Nachhaltigkeit des Vorhabens machen. Leider endet nach einer Weile die „Süßes-Welpen“-Phase, wie Jacob Thornton es in seinem Vortrag so schön beschrieben hat, und das Projekt muss ordnungsgemäß gepflegt werden – umso mehr, wenn es erfolgreich ist und immer mehr Nutzer davon Gebrauch machen. Irgendwann werden Sie für Ihre Bemühungen bezahlt werden wollen, insbesondere wenn Sie mehr Mitarbeiter einstellen müssen, um die Nachfrage zu befriedigen.

Nachdem ich einige Jahre langSiLA 2(einen offenen Konnektivitätsstandard und Tools für wissenschaftliche Instrumente und Software) ins Leben gerufen und gepflegt sowie den Bereich „Open Source in den Biowissenschaften” beobachtet habe, kann ichAaron Stannardnur zustimmen, dass man sich für eine nachhaltige Fortführung seines Projekts nicht auf Spenden verlassen kann, sondern ein kommerzielles Angebot rund um das Projekt haben muss – entweder als unabhängiger Berater oder als Unternehmen. In seinem Artikel stellt Aaron verschiedene Finanzierungsmodelle vor, die ich hier wiedergebe:

• Dienstleistungen: Schulung, Beratung und Verkauf von Support für die Nutzer Ihrer Software. The Hyve ist ein gutes Beispiel für ein Beratungsunternehmen, das sich mit Open-Source-Tools für die Biologie beschäftigt.
  
• Offenes Kernangebot: Ein kostenloses und offenes Kernangebot mit proprietären "Unternehmens"-Funktionen für zahlende Kunden. Beliebte Funktionen sind z. B. Zugriffskontrolle und Audit-Bereitschaft. GitLab, eine Plattform zur Softwareverwaltung (Git), ist ein gutes Beispiel.
• Lizenzierung: Festlegung einer freien Lizenz für die nicht-kommerzielle Open-Source-Nutzung und einer proprietären Lizenz für die kommerzielle Nutzung der Software. Ein bekanntes Beispiel ist das Tool Qt für grafische Benutzeroberflächen.
• Verwaltete Dienste: Aufbau eines verwalteten Dienstes unter Verwendung von Open-Source-Software, die als Plattform oder Software as a Service (PaaS oder SaaS) verkauft werden kann. Dieses Modell wird oft mit bestimmten proprietären Funktionen kombiniert, um die Verwaltung zu vereinfachen. Ein gutes Beispiel aus dem Bereich der Bioinformatik ist Netflow Tower.
• Reputation: Wie bereits als Finanzierungsmechanismus erwähnt, kann die Mitwirkung an Open-Source-Projekten dazu beitragen, den Ruf eines Vordenkers in einem bestimmten Bereich zu erhalten oder zu schaffen - für Wega haben seine SiLA-Beiträge beispielsweise das Image als Experte für die Digitalisierung von Laboren gestärkt. Außerdem macht es das Unternehmen für angehende Ingenieure als Arbeitgeber viel attraktiver.

Viele Entwickler (mich eingeschlossen) würden denken, dass ein Unternehmen, wenn ein Teil des Codes für seinen Erfolg von entscheidender Bedeutung ist, seine Abhängigkeiten analysiert und dafür sorgt, dass er nachhaltig gepflegt wird. Leider hat sich unzählige Male gezeigt, dass diese Vorstellung nicht weiter von der Wahrheit entfernt sein könnte [Fußnote: Die Dynamik erinnert mich an die Tragödie der Allmende]. Das Sicherheits-Toolkit OpenSSL ist ein typisches Beispiel dafür: Erst nach der Veröffentlichung der berühmten "Heartbleed"-Schwachstelle (deren Kosten auf 500 Mio. USD geschätzt werden) sind die Spenden von 2000 USD pro Jahr auf 9000 USD gestiegen, was offensichtlich bei weitem nicht ausreicht, um auch nur einen Entwickler zu ernähren, geschweige denn die Ressourcen, die ein solches Projekt benötigen würde (Quelle). Wie immer veranschaulicht XCKD die Situation perfekt:

Die brüchige, moderne Infrastrukturfinanzierung(XKCD)

Kürzlich sorgte eine Sicherheitslücke in der beliebten Java-Logging-Bibliothek log4j für weltweites Aufsehen, da sie fast jedes System betrifft und einen Maintainer mit drei Github-Sponsoren hatte. Daraufhin schrieb Filippo Valsorda über die Notwendigkeit, Maintainer direkt und vertraglich für ihre Arbeit zu bezahlen (Artikel) – und ich stimme ihm zu. Ich befürchte jedoch, dass viele Beschaffungsabteilungen diesen Fall noch einige Zeit lang nicht verstehen werden.

Es gibt Gegenbeispiele, bei denen Gemeinschaften um Projekte herum entstanden sind, die sich so tief in der Wertschöpfungskette der sie nutzenden Unternehmen verankert haben, dass sie eine nachhaltige Finanzierung erhalten haben, aber das ist normalerweise ein langer und einsamer Weg. Abgesehen von den berühmten Linux- und Apache-Projekten scheint es Jupyter einigermaßen gut zu gehen, mit bedeutenden Spenden von Microsoft für seinen Vorgänger IPython und später von öffentlichen Organisationen. Ein weiteres interessantes Beispiel ist das Robot Operating System (ROS), das als Forschungsprojekt begann, dann Teil eines Privatunternehmens wurde und nun Teil der Open Source Robotics Foundation ist, die von Unternehmen wie Amazon, Bosch oder Nvidia erhebliche Mittel erhält.

 

Open Source und Standardisierung

Viele Industriezweige haben von der Standardisierung von Formaten profitiert, damit dieselbe Lösung in verschiedenen Kontexten angewendet werden kann. Oft zitierte Beispiele sind Versandbehälter, USB oder im Labor die SBS-Spezifikation für Mikropaletten. Diese Geschichten motivieren die Schaffung neuer Standards in unerforschten Bereichen, was oft zu mehreren konkurrierenden Definitionen am Anfang führt. Diese Situation wird häufig mit einem anderen XKCD-Comic verspottet:

Eine andere XKCD

Als ich darüber nachdachte, was eine Norm ist, wurde mir klar, dass das, was wir gemeinhin als Norm bezeichnen, eine versionierte Dokumentation ist, die von einem "unabhängigen" Ausschuss wie der ISO genehmigt wurde. Im Gegensatz dazu würde ich behaupten, dass ein Standard in Wirklichkeit nur eine Reihe von Definitionen ist, die in einem bestimmten Kontext/Anwendungsfall am häufigsten verwendet werden. Beispiele hierfür sind die von konkurrierenden Diensten verwendete Amazon S3 API, Docker-Image-Beschreibungen, die mit anderen Container-Diensten (z. B. Singularity) kompatibel sind oder das bereits erwähnte ROS und seine Nachrichtenschnittstellen.

Die "siegreichen Standards" sind einfach diejenigen, die am häufigsten verwendet werden - und obwohl es für einen Benutzer schöner wäre, immer eine Definition zu haben, die für alle gilt, ist in der Realität zumindest eine Handvoll Definitionen erforderlich, um einen gesunden Wettbewerb zu gewährleisten, welcher Anreize für eine kontinuierliche Verbesserung bietet.

Angesichts dieser Einsicht könnte jede Software als Standard angesehen werden, wenn eine ausreichende Akzeptanz erreicht wird. Um die kontinuierliche Zugänglichkeit und Wartung dieser Standardinfrastrukturen zu gewährleisten, wird in der Regel eine unabhängige, gemeinnützige Organisation gegründet, die sich durch Mitgliedsbeiträge und Spenden finanziert. Beispiele aus der Life-Science-Branche sind Open Microscopy Environment, SiLA oder LADS.

Viele Standardisierungsbemühungen scheitern aus verschiedenen Gründen. Einige davon lassen sich mit einer offenen Kultur und Open-Source-Software als Rückgrat leicht abmildern. Einige Regeln in dieser Hinsicht:

• Die Mitgliedschaft dient nur der Entscheidungsfindung, nicht dem Zugang: Einige Stiftungen konzentrieren sich zu sehr darauf, Anreize für eine Mitgliedschaft zu schaffen, indem sie (zahlenden) Mitgliedern nur Zugang zu den Definitionen und Quelldateien gewähren. Dies behindert die Adoption drastisch.
• Implementierungscode von Anfang an: Noch bevor eine erste Definition veröffentlicht wird, muss es (zumindest) frei zugängliche (besser quelloffene) Anwendungen geben, die die Definitionen in branchenrelevanten Szenarien verwenden, um die Konzepte zu testen.
• Aufbau einer Community: Interessierte müssen die Möglichkeit haben, die aktuellen Diskussionen leicht einzusehen und sich daran zu beteiligen – leicht im Sinne von wenigen Klicks, ohne Interviews oder Anmeldeformulare! Es müssen Plattformen wie Präsenzveranstaltungen und Online-Foren für den regelmäßigen Austausch zwischen den Mitgliedern geschaffen werden.

Derartige Regeln sollten so früh wie möglich festgelegt werden, da gewinnorientierte Unternehmen (ohne Open-Source-Prinzipien) unweigerlich versuchen werden, sich durch den Ausschluss von Neueinsteigern einen Vorteil von einem kommenden Standard zu verschaffen.

 

Vorteile der offenen Entwicklung

Ich habe über Open Source gesprochen, als wäre es selbstverständlich, dass es vorteilhaft ist – und ich bin davon ausgegangen, dass die Auswirkungen früherer Projekte für sich sprechen. Allerdings hat die geschlossene Entwicklung sicherlich auch ihre Vorteile, wie beispielsweise eine strengere Kontrolle [Fußnote: Das etwas lockerere Entwicklungsmodell von Open Source wird in diesem bahnbrechenden Artikel „The Cathedral and the Bazaar” gut beschrieben] und eine einfachere Monetarisierung. Was sind also die konkreten Vorteile einer Öffnung eines Teils Ihres geistigen Eigentums?

Was die Statistik betrifft, so finden Sie viele Artikel, z. B. von führenden Beratungsunternehmen, wie diesen von McKinsey, die zeigen, dass Unternehmen, die Open Source einsetzen, innovativer sind. Konkret denke ich, dass dies die wichtigsten Vorteile sind:

• Beiträge der Community: Die Nutzer Ihrer Software werden eine Vielzahl von Funktionen und Erweiterungen einbringen, mit denen ein einzelnes Unternehmen nicht mithalten kann. Ein gutes Beispiel dafür ist der Unterschied zwischen den Beiträgen zum Open-Source-Projekt Stable Diffusion und der geschlossenen Alternative DALL-E – wie Yannic Kilcher gezeigt hat.
• Besseres Feedback: Wenn Nutzer den Code selbst analysieren und an seinen inneren Abläufen herumtüfteln können, profitieren Sie von einem tieferen und schnelleren Feedback zur Qualität – dies kann zu dramatischen Verbesserungen führen, insbesondere in Bezug auf Sicherheitsaspekte. Eine Alternative zur Open-Source-Veröffentlichung wichtiger Komponenten könnte auch ein zumindest offener Zugang sein (wie das aktuelle Phänomen ChatGPT, siehe auch den Artikel über nutzerzentrierte Innovation von Eric von Hippel).
• Reputation: Wie bereits als Finanzierungsmechanismus erwähnt, kann die Mitwirkung an Open-Source-Projekten dazu beitragen, den Ruf als Vordenker in einem bestimmten Bereich zu festigen oder aufzubauen – für Wega beispielsweise haben seine SiLA-Beiträge das Image als Experte für die Digitalisierung von Labors gestärkt. Darüber hinaus macht es das Unternehmen für angehende Ingenieure als Arbeitgeber viel attraktiver.

Viele Führungskräfte scheuen sich davor, etwas als Open Source zu veröffentlichen, weil sie glauben, dass sie damit ihre Arbeit einfach kostenlos verschenken. Diese Denkweise ignoriert jedoch das wertvollste Kapital, über das Sie verfügen – Ihr Fachwissen. Natürlich kann dieses Kapital auch gestohlen werden (z. B. durch „Talentabwerbung“), aber wenn es um Talente geht, müssen Sie ohnehin mit diesem Risiko leben.

Der wichtigste Aspekt wird jedoch in diesem Artikel gut zusammengefasst: "Wenn wir unsere Ressourcen, unsere Arbeit und unser Know-how in Open Source teilen, profitieren alle davon. Aber die Unternehmen, die das Beste daraus machen, sind die, die sich aktiv an Open-Source-Projekten beteiligen."

Es ist am besten, sich auf eine Open-Source-Reise zu begeben, ohne dabei einen direkten Gewinn im Sinn zu haben, aber man sollte sich bewusst sein, dass dies langfristig auch dem Unternehmensergebnis zugute kommt. Ich empfehle Ihnen, darüber nachzudenken, wo Open-Source-Initiativen in Ihrem Unternehmen sinnvoll sein könnten.