Open Development of Scientific Software

 

Revolutionierung der Forschung mit kollaborativer Software-Infrastruktur

Geschrieben von Max Schulz

Die Revolution von Open Source

Bild erstellt mit Stable Diffusion(öffnet sich in einem neuen Tab): „Ein Programmierer, der auf den Schultern von Giganten ruht“ (Meine Prompt-Erstellung ist eindeutig verbesserungswürdig)

Haben Sie schon einmal darüber nachgedacht, dass die Technologie, die wir täglich nutzen, zu einem großen Teil auf der Arbeit von Freiwilligen basiert? Die Open-Source-Bewegung hat die Technologiebranche revolutioniert, indem sie Einzelpersonen und Unternehmen den freien Zugriff auf Quellcode sowie dessen Änderung und Verbreitung ermöglicht hat. Dabei geht es jedoch nicht nur darum, ein paar Dollar bei 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 der Branche geführt hat.

Alles begann in den Anfängen der Informatik, als Software unter Wissenschaftlern und Forschern frei ausgetauscht wurde. Ende der 1980er und Anfang der 1990er Jahre wurde der Begriff „Open Source“ geprägt, und die Bewegung gewann zunehmend an Dynamik. Zu den prägenden Persönlichkeiten dieser Zeit zählt Richard Stallman, der Gründer der Free Software Foundation(öffnet in neuem Tab) und des GNU-Projekts (zu dem auch der beliebte GCC-Compiler(öffnet in neuem Tab) gehört). Er setzte sich für eine strenge Definition der Bewegung ein, die es jedem erlaubte, Open-Source-Code zu nutzen und zu verkaufen, von den Entwicklern jedoch verlangte, ihre Software ebenfalls als Open Source zu veröffentlichen (er verfasste die als äußerst „restriktiv“ geltende GPL-Lizenz(öffnet in neuem Tab)).

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 Perspektive eines Software- und Dienstleistungsanbieters in der Life-Sciences-Branche beleuchten. Zwar gibt es zahlreiche Artikel über die allgemeine Einführung von Open-Source-Software (sowie Bücher(öffnet in neuem Tab) zur Bewertung von Projekten im Hinblick auf deren Einsatz) und relativ positive Marktprognosen für den Markt für Open-Source-Dienstleistungen (z. B. diesen Bericht(öffnet in neuem Tab)), doch gibt es kaum Inhalte über konkrete Beiträge in anderen Branchen außerhalb der Softwarebranche (z. B. Biotechnologie oder Fertigung).

Meiner Erfahrung nach hinkt die Übernahme von Open-Source-Prinzipien in anderen Branchen im Vergleich zur „Tech-Branche“ (die irgendwie dazu übergegangen ist, nur noch Elektronik und Softwaretechnologie zu berücksichtigen) immer noch hinterher. Zwar ist es auch in der Tech-Branche schwierig, Finanzmittel zu sichern (guter Artikel(öffnet in neuem Tab) von James Turner), doch gibt es dort große Stiftungen wie die Apache Software Foundation(öffnet in neuem Tab) oder die Linux Foundation(öffnet in neuem Tab). Die Anzahl der Nutzer, die beispielsweise ein Webserver-Programm verwenden, könnte eine nachhaltige Finanzierung durch Spenden (z. B. über GitHub Sponsors(öffnet in neuem Tab) oder Open Collective(öffnet in neuem Tab)) zumindest denkbar machen.

In Nischenbereichen wie dem Einsatz von Open-Source-Software in der wissenschaftlichen Arbeit ist die Lage eher schlecht. Obwohl klar ist, dass die jüngsten Durchbrüche ohne sie nicht möglich gewesen wären (siehe diese Analyse(öffnet in neuem Tab) 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(wird in einem neuen Tab geöffnet)

Erst seit Kurzem werden Stimmen laut, die sich mit dem Problem der Finanzierung von Software-Infrastrukturen für die Wissenschaft befassen. Wie Adam Siepel(öffnet in neuem Tab) oder Anna Nowogrodzki(öffnet in neuem Tab) beschreiben, müssen Forscher im Rahmen ihrer Arbeit in der Regel neue Tools programmieren, ohne dafür Anerkennung zu erhalten oder entsprechend geschult zu sein. Wenn der Wartungsaufwand eines Open-Source-Projekts steigt – insbesondere, wenn es erfolgreich wird –, bleibt Wissenschaftlern möglicherweise nichts anderes übrig, 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“(öffnet in neuem Tab) der Chan Zuckerberg Initiative. Darüber hinaus hat die National Science Foundation (NSF) ein passendes Programm namens „Pathways to Enable Open-Source Ecosystems (POSE)“(öffnet in neuem Tab) ins Leben gerufen (erste Anträ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.

Fokus auf Softwareentwicklung: Bislang wurden Software und IT-Infrastruktur eher als reine Kostenfaktoren betrachtet und nicht als Fachkompetenz, die einen Wettbewerbsvorteil schafft. Neue Unternehmen in diesem Bereich verändern diese Dynamik allmählich durch eine neue Generation von„Techbio(öffnet in neuem Tab)“-Start-ups, die Softwareentwicklung ausdrücklich als Kernaktivität definieren.

Fehlende Kultur des Teilens: Nirgendwo ist der Schutz geistigen Eigentums stärker als im Biotech-Sektor, insbesondere in der Arzneimittelentwicklung. Im Vergleich zu Patenten in der Softwarebranche, die relativ wertlos sind, ist ihr Wert für Pharmaunternehmen enorm, und ihre Schaffung könnte als deren „Daseinsberechtigung“ angesehen werden. Es gibt vorwettbewerbliche Initiativen wie die Pistoia Alliance(öffnet in neuem Tab). Dennoch glaube ich, dass noch viel mehr getan werden muss, um das Bewusstsein zu fördern, dass der Austausch von Werkzeugen und Infrastruktur allen zugutekommt.

Die „Stimmung“ in der Branche verändert sich allmählich, da jüngere Unternehmen wie Colossal(öffnet in neuem Tab) Software-Spin-offs wie Form Bio(öffnet in neuem Tab) aufbauen und Mitarbeiter großer Pharmaunternehmen wie Roche den Einsatz von Open-Source-Tools wie Arvados(öffnet in neuem Tab) oder Camunda(öffnet in neuem Tab) befürworten.

Strategien für den Erfolg

Ein Projekt wird in der Regel von einer oder mehreren einzelnen Personen ins Leben gerufen. Beispiele aus der Biotech-Branche sind MultiQC(öffnet in einem neuen Tab) von Phil Ewels, PyLabRobot(öffnet in einem neuen Tab) von Stefan Golas oder Poly(öffnet in einem neuen Tab) von Timothy Stiles. Der Anstoß für ein neues Projekt geht meist von einem Bedarf aus, der in verschiedenen Kontexten 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(öffnet in neuem Tab) (ein offener Konnektivitätsstandard und Tooling für wissenschaftliche Instrumente und Software) ins Leben gerufen und gepflegt sowie den Bereich „Open Source in den Lebenswissenschaften“ beobachtet habe, kann ichAaron Stannard(öffnet in neuem Tab)nur zustimmen, dass man sich für eine nachhaltige Fortführung seines Projekts nicht auf Spenden verlassen kann, sondern ein kommerzielles Angebot daneben benötigen – entweder als unabhängiger Berater oder als Unternehmen. In Aarons Artikel stellt er die verschiedenen Finanzierungsmodelle vor, die ich hier zusammenfasse:

• • Dienstleistungen: Schulungen, Beratung und Vertrieb von Supportleistungen für Nutzer Ihrer Software. The Hyve(wird in einem neuen Tab geöffnet) ist ein gutes Beispiel für ein Beratungsunternehmen, das sich mit Open-Source-Tools für die Biologie befasst.

 

• • Open-Core-Modell: Ein kostenloses und offenes Kernangebot mit proprietären „Enterprise“-Funktionen für zahlende Kunden. Zu den beliebten Funktionen zählen Zugriffskontrolle und Audit-Bereitschaft. GitLab(öffnet in einem neuen Tab), eine Software-Management-Plattform (Git), ist ein gutes Beispiel hierfür.

 

• • Lizenzierung: Festlegung einer freien Lizenz für die nichtkommerzielle Open-Source-Nutzung und einer proprietären Lizenz für die kommerzielle Nutzung der Software. Ein bekanntes Beispiel ist das Qt-Tool(öffnet sich in einem neuen Tab) für grafische Benutzeroberflächen.

 

• • Managed Services: Erstellung eines Managed Services unter Verwendung von Open-Source-Software, der als Plattform oder als Software as a Service (PaaS oder SaaS) verkauft werden kann. Dieses Modell wird häufig mit bestimmten proprietären Funktionen kombiniert, um die Verwaltung zu vereinfachen. Ein gutes Beispiel aus der Bioinformatik ist Netflow Tower(wird in einem neuen Tab geöffnet).

 

• • Reputation: Anstatt etwas direkt zu verkaufen, kann ein Unternehmen oder eine Einzelperson das Ansehen nutzen, das mit dem Beitrag zu einem Gemeinschaftsprojekt einhergeht, um Kunden oder Talente für das eigene Unternehmen zu gewinnen. Dies ist derzeit das Geschäftsmodell des Unternehmens, für das ich arbeite: Wega(öffnet in neuem Tab), wo das SiLA-Projekt(öffnet in neuem Tab) zu neuen Kunden und Neueinstellungen geführt hat (mehr dazu weiter unten).

 

Viele Entwickler (mich eingeschlossen) würden annehmen, dass ein Unternehmen, wenn ein Teil des Codes entscheidend für seinen Erfolg ist, dessen Abhängigkeiten analysieren und sicherstellen würde, dass diese nachhaltig gepflegt werden. Leider hat sich schon 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“(öffnet in neuem Tab)). Das Sicherheits-Toolkit OpenSSL(öffnet in neuem Tab) ist ein typisches Beispiel hierfür: Erst nach der Veröffentlichung der berühmten„Heartbleed“-Sicherheitslücke(die auf 500 Millionen US-Dollar geschätzt wurde) stiegen die Spenden von 2.000 auf 9.000 US-Dollar pro Jahr – was offensichtlich bei weitem nicht ausreicht, um auch nur einen einzigen Entwickler zu ernähren, geschweige denn die Ressourcen bereitzustellen, die ein solches Projekt benötigen würde (Quelle(öffnet in neuem Tab)). Wie immer veranschaulicht XKCD die Situation perfekt:

Die prekäre Finanzierung moderner Infrastruktur (XKCD(öffnet in einem neuen Tab))

Vor kurzem sorgte eine Sicherheitslücke in der beliebten Java-Logging-Bibliothek log4j für weltweites Aufsehen(öffnet in neuem Tab), da sie nahezu jedes System betrifft und der Betreuer drei GitHub-Sponsoren hatte. Infolgedessen schrieb Filippo Valsorda über die Notwendigkeit, Betreuer direkt und vertraglich für ihre Arbeit zu bezahlen (Artikel(öffnet in neuem Tab)) – und ich stimme ihm zu. Dennoch befürchte ich, dass viele Beschaffungsabteilungen dieses Argument noch eine ganze Weile nicht verstehen werden.

Es gibt zwar Gegenbeispiele, bei denen sich rund um Projekte Gemeinschaften gebildet haben, die so tief in der Wertschöpfungskette der sie nutzenden Unternehmen verankert waren, dass sie eine nachhaltige Finanzierung erhielten, doch ist dies in der Regel ein langer und einsamer Weg. Abgesehen von den bekannten Projekten Linux und Apache scheint sich Jupyter(öffnet in neuem Tab) recht gut zu entwickeln, mit erheblichen Spenden von Microsoft für seinen Vorgänger IPython und später von öffentlichen Einrichtungen(öffnet in neuem Tab). Ein weiteres interessantes Beispiel ist das Robot Operating System (ROS)(öffnet in neuem Tab), das als Forschungsprojekt begann, dann Teil eines privaten Unternehmens wurde und nun zur Open Source Robotics Foundation(öffnet in neuem Tab) gehört, die erhebliche Finanzmittel von Unternehmen wie Amazon, Bosch und Nvidia erhält.

 

Open Source und Standardisierung

Viele Branchen haben von der Standardisierung von Formaten profitiert, sodass dieselbe Lösung in unterschiedlichen Kontexten angewendet werden kann. Häufig genannte Beispiele sind Versandcontainer(öffnet in neuem Tab), USB(öffnet in neuem Tab) oder im Labor die SBS-Spezifikation für Mikrotiterplatten(öffnet in neuem Tab). Diese Beispiele motivieren zur Schaffung neuer Standards in noch unerforschten Bereichen, was zu Beginn oft zu mehreren konkurrierenden Definitionen führt. Diese Situation wird oft in einem anderen XKCD-Comic auf die Schippe genommen:

Ein weiteres XKCD(wird in einem neuen Tab geöffnet)

Als ich darüber nachdachte, was ein Standard eigentlich ist, wurde mir klar, dass das, was wir gemeinhin als Standard bezeichnen, eine versionierte Dokumentation ist, die von einem „unabhängigen“ Gremium wie der ISO(öffnet in neuem Tab) genehmigt wurde. Im Gegensatz dazu würde ich argumentieren, dass ein Standard eigentlich nur eine Sammlung von Definitionen ist, die in einem bestimmten Kontext oder Anwendungsfall am häufigsten verwendet werden. Beispiele hierfür sind die Amazon S3-API(öffnet in neuem Tab), die von konkurrierenden Diensten genutzt wird, Docker-Image-Beschreibungen, die mit anderen Containerdiensten kompatibel sind (z. B. Singularity(öffnet in neuem Tab)), oder das bereits erwähnte ROS und seine Messaging-Schnittstellen(öffnet in neuem Tab).

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.

Vor diesem Hintergrund könnte jede Software als Standard gelten, sobald eine ausreichende Verbreitung erreicht ist. Um die dauerhafte Zugänglichkeit und Wartung dieser Standardinfrastrukturen zu gewährleisten, wird in der Regel eine unabhängige, gemeinnützige Organisation gegründet, die sich aus Mitgliedsbeiträgen und Spenden finanziert. Beispiele aus der Life-Sciences-Branche sind Open Microscopy Environment(öffnet in neuem Tab), SiLA(öffnet in neuem Tab) oder LADS(öffnet in neuem Tab).

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.

 

• • Eine Community aufbauen: Für Interessierte muss es einfach sein, die aktuellen Diskussionen zu verfolgen und sich daran zu beteiligen – einfach im Sinne von nur wenigen Klicks, ohne Vorstellungsgespräche oder Anmeldeformulare! Es müssen Plattformen wie Präsenzveranstaltungen und Online-Foren geschaffen werden, die einen regelmäßigen Austausch zwischen den Mitgliedern ermöglichen.

 

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 sei es eine Selbstverständlichkeit, dass es vorteilhaft ist – und ich bin davon ausgegangen, dass die Auswirkungen früherer Projekte für sich sprechen. Allerdings hat die geschlossene Entwicklung durchaus 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“(öffnet in neuem Tab) gut beschrieben ]] und eine einfachere Monetarisierung. Was sind also die konkreten Vorteile, wenn man einen Teil seines geistigen Eigentums offenlegt?

Was Statistiken angeht, gibt es zahlreiche Artikel, beispielsweise von führenden Beratungsunternehmen wie diesen hier(öffnet in einem neuen Tab) von McKinsey, die belegen, dass Unternehmen, die Open Source einsetzen, innovativer sind. Konkret sehe ich folgende wesentliche Vorteile:

• • Beiträge der Community: Die Nutzer Ihrer Software werden eine Vielzahl von Funktionen und Erweiterungen beisteuern, mit denen ein einzelnes Unternehmen nicht mithalten kann. Ein gutes Beispiel hierfür ist der Unterschied zwischen den Beiträgen zum Open-Source-Projekt „Stable Diffusion“ (öffnet in neuem Tab) und der geschlossenen Alternative „DALL-E“(öffnet in neuem Tab) – wie Yannic Kilcher(öffnet in neuem Tab) aufzeigt.

 

• • Besseres Feedback: Wenn Nutzer den Code selbst analysieren und an seinen inneren Abläufen herumprobieren können, profitieren Sie von fundierterem und schnellerem Feedback zur Qualität – dies kann zu erheblichen Verbesserungen führen, insbesondere in Bezug auf Sicherheitsaspekte. Eine Alternative zur Veröffentlichung wichtiger Komponenten als Open Source könnte auch darin bestehen, zumindest den offenen Zugang zu gewähren (wie beispielsweise das aktuelle Phänomen ChatGPT(öffnet in neuem Tab); siehe auch den Artikel von Eric von Hippel über nutzerzentrierte Innovation).

 

• • 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(wird in einem neuen Tab geöffnet) gut zusammengefasst: „Wenn wir unsere Ressourcen, unsere Arbeit und unser Know-how im Open-Source-Bereich teilen, profitieren alle davon. Am meisten profitieren jedoch jene Unternehmen, 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.