Marktplatz zur Koordinierung und Finanzierung von Open Source Software

Open Source ist zu einem populären und bewährten Kollaborationsmechanismus in der Software Entwicklung erwachsen (Germonprez et al. 2018). Auch deutsche Unternehmen verwenden und entwickeln Open Source Software, wie zum Beispiel Continental, Daimler, Deutsche Bank, Deutsche Börse, Deutsche Telekom, SAP und Suse – alle Mitglieder der Linux Foundation. Dies ist kein Zufall, da Open Source Software die digitale Infrastruktur unserer modernen Gesellschaft bildet (Eghbal 2016). Insbesondere für Infrastruktur und nicht differenzierende Software bildet Open Source Software die Grundlage auf der auch proprietäre Software entwickelt wird (Lerner und Schankerman 2010). Jeder, der das Internet nutzt, greift auf Router, Webserver und Browser zu, die oft mit Open Source Software laufen.

Die weit verbreitete Nutzung von Open Source Software birgt jedoch auch Gefahren für Privatpersonen, Unternehmen und die Gesellschaft. Die 2014 gefundene Sicherheitslücke Heartbleed brachte diesen Umstand in das allgemeine Bewusstsein (Eghbal 2016). Heartbleed existierte in der kryptographischen Open Source Library OpenSSL, die von einer Mehrheit an Webservern verwendet wird, um Internetverkehr abzusichern (Durumeric et al. 2014). Die Sicherheitslücke erlaubt es, ohne Zugangsbeschränkung, Arbeitsspeicherinhalte von Servern abzurufen, unter anderem schützenswerte Informationen. Es wurde bekannt, dass OpenSSL von wenigen Entwicklern unterhalten wird, die aber kaum Spendengelder erhielten und darüber hinaus nicht für ihre Arbeit an OpenSSL bezahlt wurden.

Als Antwort auf Heartbleed haben die Industrie und die Linux Foundation die Core Infrastructure Initiative gegründet, die mit finanziellen Mitteln Entwickler bezahlt, um wichtige Software wie OpenSSL zu unterhalten. Das Problem ist, Open Source Software zu identifizieren, die weit verbreitet aber nicht ausreichend finanziert ist. TideLift adressiert dieses Problem, indem es die Benutzung von Open Source Software ihrer Mitglieder analysiert und quantifiziert, um entsprechend Gelder an die Open Source Projekte auszubezahlen. Andere Finanzierungsmöglichkeiten können von Open Source Projekten selbst initiiert werden. Sie können durch Crowdfunding auf Open Collective finanzielle Unterstützung einfordern. Dies erfordert gezieltes Marketing und Fähigkeiten, die nicht typischerweise von einem Softwareentwickler erwartet werden. Wenn es darum geht, gezielt neue Funktionen oder das Fixen von Bugs zu bezahlen, können Open Source Bounties ausgeschrieben werden, die an einen Entwickler ausbezahlt werden, der eine Lösung entwickelt und einreicht. Bei Entwicklungswettbewerben können mehrere Lösungen eingereicht werden. Der Entwickler mit dem beste Ergebnis wird belohnt, während andere Entwickler leer ausgehen. Entwickler können auch direkt bezahlt werden. Arbeitsverhältnisse oder Vertragsarbeiten sind jedoch nicht öffentlich.

Insgesamt gibt es mehrere Möglichkeiten, die Entwicklung von Open Source Software zu finanzieren. Diese schaffen zum Teil Anreize, die gegen die kollaborativen Grundprinzipien von Open Source gehen. Beispielsweise ist ein Entwickler angehalten für ein Open Source Bounty nachzuweisen, dass er die Lösung hat. Wenn er aber die Lösung offen in der Open Source Community programmiert und frühzeitig Feedback einholt, kann auch jemand anderes die Lösung fertigstellen und die Belohnung erhalten. Somit wird ein Entwickler davon abgehalten, die Entwicklung in der Open Source Community bekannt zu geben, bevor er nicht das Open Source Bounty erhalten hat.

Was fehlt ist ein Marktmechanismus für Preissignale. Ein Markt würde die Zahlungsbereitschaft von Anwendern bündelt, um Entwicklern zu zeigen, welche neuen Features und Bugfixes am meisten gewünscht sind und dementsprechend auch entlohnt werden (Germonprez et al. 2018). Wir haben unsere Idee eines Marktplatzes in Bezug auf Sicherheit in Open Source Software vorgestellt (Rao et al. 2018). Gegenstand dieses Beitrags ist die konzeptionelle Beschreibung des Marktplatzes, der die Kollaborationsprinzipien von Open Source bewahrt und verstärkt, während es ebenfalls die Finanzierung von Open Source verbessert.

Open Source Projekte bestehen aus Software und einer Community. Open Source Software hat eine Softwarelizenz, die von der Open Source Initiative offiziell als Open Source Lizenz anerkannt wird.¹ Die Community sind Projektmitglieder, die sich an der Entwicklung der Software beteiligen.

Mitglieder in Open Source Projekten einigen sich intern auf Strukturen und Regeln, die das Kollaborationsverhalten bestimmen (O’Mahony und Ferraro 2007; Kelty 2008). Selbst wenn Open Source Projekte dieselben Kollaborationswerkzeuge nutzen, entwickeln sie eigene Verhaltensweisen, die im Kommunikationsverhalten offensichtlich werden (Crowston und Howison 2005). Dennoch gibt es Gemeinsamkeiten, die von Open Source Projektmitgliedern anerkannt werden (Elliott und Scacchi 2008).

Softwareentwicklung in Open Source Projekten ist oft informell und selbstbestimmt (Mockus et al. 2002; Scacchi 2004). Entwickler arbeiten oft allein. Aufgaben, die zu umfangreich für einen Entwickler sind, bleiben unbearbeitet, bis zugrundeliegende Teilaufgaben gelöst sind (Howison und Crowston 2014). Entwickler loten im Vorfeld einer größeren Änderung aus, wie die Meinungen anderer Entwickler sind und entwickeln eine Lösung die das Ergebnis dieser Gespräche ist. Kommunikation ist häufig asynchron in E‑Mail-Listen, Foren, und Issue-Trackern. Issue-Tracker nehmen dabei eine besondere Rolle ein. Ähnlich eines Forums erlauben Issue-Tracker fokussierte Unterhaltungen, die nach Issues strukturiert sind. Ein Issue enthält eine Beschreibung eines Bugs oder Features und erlaubt Entwicklern sich gezielt darüber zu unterhalten. In Issues werden Ideen, Probleme, Workarounds, Lösungsstrategien, und Alternativlösungen ausgetauscht und darüber abgestimmt. Die Diskussion in einem Issue wird offiziell als beendet erklärt, indem der Status des Issues von offen auf geschlossen geändert wird.

Projektmitglieder beteiligen sich aus eigenem Interesse, weil sie lernen wollen, das Ideal von Free Software unterstützen wollen oder die Gemeinschaft in Open Source Communities genießen wollen (von Krogh et al. 2012). Sie beteiligen sich auch, weil sie von ihrem Arbeitgeber dafür bezahlt werden oder weil die Mitarbeit in Open Source Projekten die Karrierechancen verbessert (von Krogh et al. 2012). Einige Open Source Projekte werden von Entwicklern dominiert, die sich im Rahmen ihrer Erwerbstätigkeit beteiligen (Kelty 2013; Riehle et al. 2014). Dies ist nicht verwunderlich, weil Unternehmen Open Source Software in ihren Wertschöpfungsketten verwenden (Dahlander 2005).

Unternehmen können Open Source Software ohne Einschränkung und ohne Lizenzkosten verwenden. Sie kann günstiger sein als proprietäre Software, ist aber nicht kostenlos nach den Total Cost of Ownership (Wheeler 2015). Unternehmen stellen Entwickler ein, die Open Source Software für sie anpassen, integrieren, konfigurieren und updaten. Unternehmen haben dabei eine Wahl. Entweder sie nutzen nur die Software und geben nichts an die Community zurück oder sie erlauben ihren Entwicklern, sich an den Projekten zu beteiligen (Dahlander und Magnusson 2005). Letzterer Ansatz bringt mehr Vorteile (Bonaccorsi et al. 2006). Entwickler, die sich an Projekten beteiligen, lernen mehr über die Software und können somit ihre Aufgaben im Unternehmen besser erfüllen (Nagle 2018). Außerdem können Entwickler Einfluss auf die Softwareentwicklung nehmen und Bedürfnisse des Unternehmens einfließen lassen (Dahlander und Wallin 2006).

Die zunehmende Beteiligung von Unternehmen beeinflusst die Zusammenarbeit in Open Source Projekten. Freiwillige Entwickler betrachten den Einfluss von Unternehmen skeptisch (Spaeth et al. 2015). Außerdem brauchen Unternehmen Planungs- und Rechtssicherheit. Diese Faktoren haben zur Gründung von Open Source Foundations geführt (Riehle 2010). Foundations stellen Rechtssicherheit her, indem sie die Verwaltung von Rechten und Trademarks an Open Source Software übernehmen. Sie liefern zuverlässig technische und verwaltende Unterstützung für Open Source Projekte. Sie schaffen ein Kollaborationsumfeld, das Projektmitglieder und Unternehmen zu Gleichberechtigten macht. Unternehmen, Foundations und Open Source Projekte haben Open Source Praktiken weiterentwickelt, um besser miteinander Software zu entwickeln (Germonprez et al. 2017). Open Source Projekte sind strategischer geworden, planen langfristiger und bieten längere Supportzeiträume (Fitzgerald 2006).

Trotz zunehmender Investitionen durch Unternehmen und Unterstützung durch Foundations hat Open Source ein Koordinierungs- und Finanzierungsproblem. Das liegt daran, dass Open Source Software häufig eine Zusammensetzung von mehreren Open Source Libraries² ist. Einmal programmierte Funktionen stehen allen zur Verfügung, was zu Abhängigkeiten zwischen Open Source Projekten führt. Zum Beispiel führt das Löschen einer häufig genutzten Open Source Library zu Fehlern in vielen anderen Projekten (Collins 2016). Sicherheitslücken in einer Open Source Library machen auch alle Open Source Software (und proprietäre Software), die diese Library verwenden, unsicher (Durumeric et al. 2014). Diese Abhängigkeiten erfordern Koordination zwischen Open Source Projekten (Eck 2018) und eine stabile Finanzierung der Entwicklungsarbeit (Eghbal 2016). Diese Probleme wurden auch in der Politik erkannt. Beispielsweise hat der U. S.-Kongress bei der Linux Foundation angefragt, wie diese Probleme angegangen werden (Walden und Harper 2018).

Das Bewusstsein ist in der öffentlichen Debatte erst durch Heartbleed aufgekommen (Eghbal 2016). Als Antwort wurde die Core Infrastructure Initiative gegründet, die Entwickler bezahlt damit sie sich um die Weiterentwicklung von kritischer Software kümmern, die jedoch keine koordinierende Rolle übernimmt. Auch bei TideLift wird nur die Finanzierung sichergestellt, es findet aber keine Koordinierung zwischen Open Source Projekten statt. Wo hingegen Geld und Arbeit direkt verknüpft sind, ist bei Bug Bounties oder Open Source Bounties. Bug Bounties loben Geld für das Finden von Bugs aus. Der Finder muss nachweisen, dass ein Bug existiert und ein Angriffsszenario demonstrieren. Das verhindert Koordinierung mit anderen Entwicklern, bis die Belohnung ausbezahlt ist. Open Source Bounties werden auf die Erledigung von festgelegten Arbeiten ausgelobt, wie die Entwicklung von neuen Features. GitCoin (https://​gitcoin.​co/​) ist eine Implementierung eines Open Source Bounty Systems und beschreibt die Arbeitsschritte, die zusätzlich zur normalen Open Source Entwicklung notwendig sind. Auch hier findet keine Koordinierung zwischen Projekten statt. Zusammenfassend lässt sich feststellen, dass es keine Finanzierungsmöglichkeit gibt, die gleichzeitig eine Koordinierungsaufgabe zwischen Open Source Projekten übernimmt.

Finanzierung und Koordination können aus ökonomischer Sicht betrachtet werden. Benkler (2002) ist Vordenker auf diesem Gebiet und hat Open Source³ als neuen Koordinierungsmechanismus neben Märkten und Unternehmen positioniert. Märkte standardisieren die Zusammenarbeit von Marktteilnehmern und vermitteln Angebot und Nachfrage durch Preissignale. Unternehmen erkennen Marktpotentiale und koordinieren Angestellte durch Weisungen von Vorgesetzten. Open Source koordiniert die Entwicklung von Open Source Software, indem Entwickler sich selbst Aufgaben aussuchen und bearbeiten. Open Source weiß die Kreativität von Entwicklern effektiver einzusetzen, als Märkte oder Unternehmen (Benkler 2002).

Als Idealtypen existieren Märkte, Unternehmen und Open Source nicht als ausschließende Alternativen, sondern sie interagieren miteinander (siehe Abb. 1). Unternehmen wägen ab, ob es günstiger ist, selbst zu produzieren oder am Markt einzukaufen (Coase 1937). Ein Manager, der diese Entscheidung fällt, verbindet somit ein Unternehmen mit Märkten und wägt ab, welche Vorgehensweise zu wählen ist. Open Source erfährt zunehmend Beteiligung von Unternehmen (Fitzgerald 2006; Germonprez et al. 2017). Unternehmen verwenden und entwickeln Open Source Software, weil es Entwicklungskosten reduziert, Entwicklungszeiten kürzt, und industrieübergreifende Standards etabliert. Unternehmen konkurrieren und differenzieren ihre Produkte und Dienstleistungen indem sie proprietäre Software-Anpassungen oder Module entwickeln (Lerner und Schankerman 2010). Märkte sind mit Unternehmen und Unternehmen sind mit Open Source direkt verbunden. Unternehmen haben durch diese Verbindungen eine vermittelnde Rolle. Es fehlen jedoch effektive Marktmechanismen für Open Source. Ziel dieser Arbeit ist die dritte Verbindung in Form eines Marktplatzes für Open Source zu beschreiben.

Wir beteiligen uns als „Engaged Researchers“ (Van de Ven 2007) aktiv in Open Source Projekten. Seit 20 Jahren nehmen wir verschiedene Rollen ein, einschließlich Mitglied, Entwickler und Maintainer. Der Erstautor erforscht seit mehr als drei Jahren die Kooperation zwischen Unternehmen und Open Source Projekten, hat über 100 Seiten Fieldnotes gesammelt und 40 Interviews durchgeführt. Er hat sein ökonomisches Verständnis während einer Ausbildung zum Bankkaufmann und im Studium der Betriebswirtschaftslehre ausgebildet. Die zweite Autorin hat ihren Doktor im Bereich der Software Economy erlangt. Der dritte Autor war Technical Editor für das Linux Journal und Editor in Chief für Linux World. Er hat für Zeitschriften und Blogs geschrieben, inklusive LinuxWorld, Linux Today, Linux Journal und opensource.com. Insgesamt haben wir tiefe Einblicke in die Kollaborationsmechanismen um Open Source gewonnen und selbst daran teilgenommen.

Dieses tiefe Verständnis zu Open Source und Marktmechanismen bildet die Grundlage für unsere Forschung. Die Zweitautorin und der Drittautor haben gemeinsam die Idee für einen Marktplatz für Open Source Software Issues entwickelt. Das Projekt wurde von Mozilla finanziert, um einen Prototyp zu entwickeln. Der Prototyp wurde als Lösung für ein praktisches Problem und unter theoretischer Berücksichtigung von Kollaborationsmechanismen in Open Source Projekten entwickelt. Der Prototyp ist unter der Mozilla Public License Version 2.0 lizensiert und auf GitHub verfügbar.⁴ Der vierte Autor ist der Hauptentwickler des Prototypen. Alle Autoren waren an der konzeptionellen Debatte beteiligt. Das Ziel des Prototypen ist, die Idee des Marktplatzes auszugestalten, zu implementieren und zu testen (Peffers et al. 2007). Der Prototyp ist die Verkörperung unserer Ideen und fokussierte als Artefakt die Diskussionen des Autorenteams und deckte unterschiedliche Ansichten auf. Wir hielten wöchentlich Videokonferenzen, um gemeinsam über Entwicklungsfortschritte und Hindernisse zu reflektieren, neue Funktionen zu diskutieren und Szenarien durchzuspielen.

Wir haben 17 Szenarien entwickelt, um die Funktionsweise des Marktplatzes und die Auswirkung auf Open Source Projekte durchzuspielen.⁵ In Gesprächen mit Mitgliedern von Open Source Projekten auf mehr als zehn Konferenzen haben wir die Szenarien immer wieder verwendet, um die Idee des Marktplatzes zu erklären und um Feedback zu erhalten. Das Feedback war überwiegend positiv. Viele sehen einen Nutzen in unserem Marktplatz. Negatives Feedback warnte vor eventuellen negativen Einflüsse auf bestehenden Open Source Kollaborationen. Das Benutzerinterface Design haben wir einer Nutzbarkeitsstudie mit 20 Versuchsteilnehmern im Rahmen des Mozilla Festivals 2017 unterzogen. Anhand von Rückmeldungen haben wir eine neue und vereinfachte Benutzeroberfläche entwickelt. Aktuell sprechen wir mit Open Source Projekten, die Interesse haben unseren Prototypen einzusetzen. Die in diesem Paper entwickelten Designprinzipien sind somit das Ergebnis von theoretischen und praktischen Überlegungen, sowie von Validierung durch potentielle Benutzer (Sein et al. 2011).

Das Ziel unserer Arbeit ist es, Marktmechanismen zu beschreiben, die die Kollaborationsprinzipien von Open Source bewahren und dabei die Finanzierung verbessern. Unsere Kernidee ist ein Kontrakt, der Ähnlichkeiten mit einem Future aus dem Finanzwesen hat. Ein Future ist ein Vertrag zwischen einem Käufer und Verkäufer über die zukünftige Lieferung einer Ware (z. B. Getreide) zu einem vorab festgelegten Preis (Carlton 1984). Als standardisierte Verträge werden Futures an Warenterminbörsen gehandelt, wobei Qualität, Menge, sowie Lieferort (e. g. Getreidesilostandort) für alle gleich festgelegt sind. Futures sind dafür bekannt, Preiserwartungen der Marktteilnehmer abzubilden und neue Informationen frühzeitig in die Preisbildung einzubeziehen (z. B. Getreidepreise steigen, wenn ein Unwetter die Ernte verhagelt) (Carlton 1984).

Wir wandeln das Konzept des Futures dahingehend ab, dass keine Ware geliefert wird, sondern der Status eines Issues (offen oder geschlossen) den Wert und die Auszahlung eines Kontrakts bestimmt. Kontrakte werden, genauso wie Futures, als standardisierte Verträge frei am Markt gehandelt. Wir erweitern durch Kontrakte die Bedeutung von Issues, indem wir zur Koordinierungsfunktion von Issues auch die Koordinierungsfunktion und Finanzierungsfunktion eines Marktplatzes hinzufügen. Die Funktionsweise des Kontrakts wird in den folgenden Ausführungen näher erläutert. Wir beginnen unsere Beschreibung mit dem Beispiel 1 (siehe Abb. 2 für die Ablauffolge und Abb. 3 für eine visuelle Repräsentation des Kontrakts aus dem Beispiel):

Wir haben einen Prototypen eines Marktplatzes entwickelt. Mit dieser Proof-of-Concept Implementierung demonstrieren wir die Umsetzbarkeit unserer Design Features (Hudson und Mankoff 2014). Der Softwareprototyp nutzt das Ruby on Rails Framework, speichert Daten in einer PostgreSQL Datenbank und bietet eine webbasierte Benutzeroberfläche (HTML, CSS und JavaScript). Die event-driven Architektur ist inspiriert von der Blockchain Technologie, um einen dezentralisierten Marktplatz zu ermöglichen. Dazu können Events in einer Blockchain unveränderbar und verteilt gespeichert werden, sodass Manipulationen von Plattformbetreibern aufgedeckt werden können. Weiterhin ist unser Prototyp mit bestehenden Open Source Kollaborationsplattformen, wie zum Beispiel GitHub, integriert. Statusänderungen von GitHub Issues werden in den Markt eingelesen. Angebote im Marktplatz werden in GitHub Issues als SVG-Bilder in Kommentaren angezeigt, die dynamisch mit aktuellen Daten vom Marktplatz geladen werden.

Der wichtigste Teil der Implementierung ist der Kontrakt. Ein Kontrakt regelt die Rechte und Pflichten der Marktteilnehmer. Die Design Features müssen in Kontrakten berücksichtigt werden, da diese das Verhalten von Open Source Projektmitgliedern beeinflussen sollen. Wir beschreiben das Kontrakt Design, indem wir das Leben eines Kontrakts von Erstellung bis Fälligkeit durchlaufen (angelehnt an Beispiel 1) aber komplexere Anwendungsfälle sind möglich. Abb. 3 zeigt die Zusammenhänge der Bestandteile eines Kontrakts.

Ein neuer Kontrakt wird erstellt, wenn zwei passende Kaufangebote zusammentreffen. Die Kaufangebote müssen für unterschiedliche Seiten sein – für FIXED und UNFIXED Positionen – müssen übereinstimmende Preise, Anzahl der Einheiten, Vorhersagen, und Fälligkeitsdaten haben. Einheitspreise der Kaufangebote müssen in der Summe den Einheitswert von 1 € ergeben. Zum Beispiel könnte der Einheitspreis für eine FIXED Position 0,80 € und für eine UNFIXED Position 0,20 € betragen. Beide Kaufangebote hinterlegen gemeinsam den gesamten Auszahlungsbetrag (jeder seinen Anteil). Der Einheitspreis bestimmt, welchen Anteil die Marktteilnehmer als Kaution auf einem Treuhandkonto hinterlegen müssen. Das Treuhandkonto beinhaltet den gesamten Auszahlungsbetrag. Die Anzahl der Einheiten geben an, wieviel ein Marktteilnehmer kaufen möchte. Gekaufte Einheiten werden als Positionen abgebildet.

Ein Kontrakt wird durch die Vorhersage und das Fälligkeitsdatum definiert. Für jeden Kontrakt gibt es eine beliebige Anzahl an Treuhandkonten, Positionen und Angebote. Dieses Design erlaubt es Marktteilnehmern, jede beliebige Anzahl an Kontrakteinheiten (auch Teilpositionen) zu kaufen und zu verkaufen, sofern sie zum selben Kontrakt gehören. Kleinere Angebote von Anwendern können zu größeren Kontrakten für Entwickler gebündelt werden.

Eine Position verkörpert das Recht, am Fälligkeitsdatum eine Auszahlung zu bekommen, falls die Vorhersage entsprechend eingetreten ist. Die Vorhersage „Issue #1337 ist am Fälligkeitsdatum FIXED“ ist ein typisches Beispiel. Der Besitzer der FIXED Position bekommt die Auszahlung, falls Issue #1337 geschlossen wurde, andernfalls erhält der Besitzer der UNFIXED Position die Auszahlung. Die Auszahlung wird vom Treuhandkonto vorgenommen. Ob ein Issue gefixed ist, entscheidet der Projekt Maintainer nach etablierten Praktiken im Open Source Projekt und auf Grundlage technischer Abwägungen.

Kontrakte, die auf den Status von Issues handeln, haben einige Vorteile, können aber auch ungewünschte Nebeneffekte haben. Grundannahme ist, dass Open Source Projektmitglieder den Preissignalen folgen und Positionen kaufen, sofern sie davon profitieren. Projektmitglieder haben einen Informationsvorteil, da sie den zukünftigen Status eines Issues beeinflussen können. Während Insiderhandel auf Kapitalmärkten illegal ist, nutzen wir dies als Anreizinstrument.

Open Source entwickelt sich ständig weiter. Wir stellen in diesem Paper einen Marktplatz vor, der dafür geeignet ist, die Zusammenarbeit in Open Source auch für neue Herausforderungen anzupassen. Wir haben unseren Marktplatz danach entworfen wie Open Source derzeit funktioniert und wo wir Verfehlungen in Koordinierung und Finanzierung beheben können. Als Konzeptstudie haben wir noch keine Einblicke in die tatsächlichen Auswirkungen, die ein solcher Marktplatz haben würde. Im Moment verhandeln wir mit Interessenten darüber, den Marktplatz für ein Open Source Projekt aufzusetzen. Dazu eignet sich ein Projekt, das von einem Unternehmen betreut wird, das bereit ist, Geld über den Marktplatz an Entwickler zu bezahlen. Wir werden das Experiment wissenschaftlich begleiten und beobachten, welches Marktverhalten sich entwickelt. Gleichzeitig arbeiten wir an einem kontrollierten Laborexperiment, in dem wir mit Studenten testen werden, wie sich die Gegenwart von verschiedenen Marktsignalen auf die Zusammenarbeit auswirken.