Offene Entwicklung von wissenschaftlicher 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 schon einmal darüber nachgedacht, dass die Technologie, die wir tagtäglich nutzen, hauptsächlich auf der Arbeit von Freiwilligen beruht? Die Open-Source-Bewegung hat die Technologiebranche revolutioniert, indem sie es Einzelpersonen und Unternehmen ermöglicht hat, frei auf Quellcode zuzugreifen, ihn zu verändern und zu verbreiten. Aber es geht nicht nur darum, ein paar Dollar bei den Softwarelizenzen zu sparen. Die Open-Source-Bewegung hat den Gemeinschaftssinn und die Zusammenarbeit gefördert, was zu einigen der am meisten genutzten Projekte 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 in den späten 1990er und frühen 2000er Jahren begann Open Source die Dinge wirklich aufzurütteln. Die Veröffentlichung des Linux-Betriebssystems und des Apache-Webservers bewies, dass Open Source nicht nur lebensfähig, sondern auch sehr erfolgreich sein konnte. Große Unternehmen wie IBM und Red Hat erkannten das Potenzial und begannen, in Open-Source-Projekte zu investieren und sie zu unterstützen.

Open Source ist heute allgegenwärtig. Es ist schwer, ein Stück Technologie zu finden, das 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 integralen 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 dem Einsatz von Open-Source-Software in der wissenschaftlichen Arbeit ist die Situation eher schlecht. Obwohl es klar ist, dass die jüngsten Durchbrüche ohne sie nicht möglich 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 zahlen nicht für einen einzigen Software-Ingenieur. - Anne Carpenter

Erst in jüngster Zeit werden die Stimmen lauter, die sich mit dem Problem der Finanzierung von Software-Infrastrukturen für die Wissenschaft befassen. Wie beispielsweise von Adam Siepel oder Anna Nowogrodzki beschrieben, müssen Forscher im Rahmen ihrer Forschung in der Regel neue Tools programmieren, ohne dafür Anerkennung oder Ausbildung zu erhalten, und wenn der Wartungsaufwand eines Open-Source-Projekts zunimmt - erst recht, wenn es erfolgreich wird -, bleibt den Wissenschaftlern möglicherweise keine andere Wahl, als ihre Bemühungen ganz einzustellen, da nur "reine wissenschaftliche Arbeit" anerkannt und finanziert wird.

Glücklicherweise ändert sich dies zumindest im wissenschaftlichen Bereich langsam. Große private US-Stiftungen richten spezielle Zuschüsse ein, wie etwa den Zuschuss “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)” (erste Vorschläge 2022) geschaffen.

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 der Bemühungen machen. Leider geht die "niedliche Welpenphase", wie Jacob Thornton in seinem Vortrag so schön beschrieben hat, nach einer Weile zu Ende und das Projekt muss ordentlich gepflegt werden - umso mehr, wenn es erfolgreich ist und die Zahl der Nutzer stetig wächst. Irgendwann werden Sie für Ihre Bemühungen bezahlt werden wollen, vor allem, wenn Sie mehr Leute einstellen müssen, um die Nachfrage zu befriedigen.

Nach einigen Jahren des Aufbaus und der Pflege von SiLA 2 (ein offener Konnektivitätsstandard und Werkzeug für wissenschaftliche Instrumente und Software) sowie der Beobachtung des Bereichs "Open Source in den Biowissenschaften" kann ich Aaron Stannard nur zustimmen, dass man sich für eine nachhaltige Fortführung seines Projekts nicht auf Spenden verlassen kann, sondern ein kommerzielles Angebot braucht - entweder als unabhängiger Berater oder als Unternehmen. In Aarons Artikel legt er die verschiedenen Finanzierungsmodelle dar, die ich hier zitiere:

• 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.
• Ansehen: Anstatt etwas direkt zu verkaufen, kann ein Unternehmen oder eine Einzelperson das Prestige eines Beitrags zu einem Gemeinschaftsprojekt nutzen, um Kunden oder Talente für Ihr Unternehmen zu gewinnen. Dies ist derzeit das Betriebsmodell für das Unternehmen, für das ich arbeite: Wega, wo das SiLA-Projekt zu neuen Kunden und Neueinstellungen führte (mehr dazu weiter unten).

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 einen weltweiten Aufruhr, da sie fast jedes System betrifft und einen Betreuer mit drei Github-Sponsoren hatte. In der Folge schrieb Filippo Valsorda über die Notwendigkeit, die Betreuer für ihre Arbeit direkt und vertraglich zu bezahlen (Artikel) - und ich stimme ihm zu. Dennoch fürchte ich, dass viele Beschaffungsabteilungen diesen Fall eine 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:

Noch ein XCKD

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 Gemeinschaft: Es muss für Interessierte einfach sein, die neuesten Diskussionen zu sehen und sich ihnen anzuschließen - einfach im Sinne von ein paar Klicks, ohne Vorstellungsgespräch und ohne Anmeldeformulare! Es müssen Plattformen wie persönliche Veranstaltungen 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 ob es eine Selbstverständlichkeit wäre, dass es vorteilhaft ist - und ich bin davon ausgegangen, dass die Auswirkungen früherer Projekte für sich selbst sprechen. Dennoch hat die geschlossene Entwicklung natürlich Vorteile, wie z. B. eine strengere Kontrolle [Fußnote: Das etwas lockere Entwicklungsmodell von Open Source ist in diesem bahnbrechenden Artikel “The Cathedral and the Bazaar” gut beschrieben] und eine einfachere Monetarisierung. Was sind also die konkreten Vorteile der Ö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 Gemeinschaft: Die Benutzer Ihrer Software werden eine Vielzahl von Funktionen und Erweiterungen einbringen, mit denen ein einzelnes Unternehmen nicht konkurrieren kann. Ein großartiges Beispiel ist der Unterschied zwischen den Beiträgen zum quelloffenen Stable Diffusion und der geschlossenen Alternative DALL-E - wie von Yannic Kilcher gezeigt.
• Besseres Feedback: Wenn die Nutzer den Code selbst analysieren und an seinem Innenleben herumbasteln können, profitieren Sie von einem tieferen und schnelleren Feedback zur Qualität - dies kann zu dramatischen Verbesserungen führen, insbesondere bei den Sicherheitsaspekten. Eine Alternative zum Open Sourcing von Schlüsselkomponenten kann auch darin bestehen, zumindest einen offenen Zugang zu haben (wie das jüngste Phänomen ChatGPT, siehe auch der 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 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 Unternehmensleiter fürchten sich davor, irgendetwas quelloffen zu machen, weil sie denken, dass dies nur bedeutet, dass sie ihre Arbeit umsonst abgeben. Diese Denkweise ignoriert das wertvollste Gut, das Sie behalten - das Fachwissen. Natürlich kann dieses Kapital auch gestohlen werden (d. h. "Talentabwerbung"), aber wenn es um Talente geht, muss man mit diesem Risiko ohnehin 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."

Am besten ist es, wenn Sie sich auf eine Open-Source-Reise begeben, ohne einen direkten Gewinn im Sinn zu haben, aber es ist gut, sich darüber im Klaren zu sein, dass dies langfristig auch dem Endergebnis Ihres Unternehmens zugute kommen wird. Ich möchte Sie ermutigen, darüber nachzudenken, wo Open-Source-Initiativen in Ihrem Unternehmen Sinn machen könnten.