Open Source Is Not One Thing: A Typology of Open-Source Software Sub-Genres
Dieses Paper argumentiert, dass Open-Source-Software kein homogenes Gebilde ist, sondern vielmehr aus vierzehn unterschiedlichen Subgenres mit variierenden Treibern, Governance-Strukturen und Finanzierungsmodellen besteht, und schlägt eine Typologie sowie eine Forschungsagenda vor, um die begrenzte Verallgemeinerbarkeit empirischer Befunde über diese vielfältigen Kategorien hinweg zu adressieren.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie betreten eine riesige Bibliothek und jemand sagt Ihnen: „Alle Bücher hier sind einfach nur ‚Bücher‘. Sie funktionieren alle auf die gleiche Weise.“ Sie würden vielleicht nicken, aber wenn Sie tatsächlich genau hinsehen würden, sähen Sie einen gewaltigen Unterschied zwischen einem Comic, einem medizinischen Lehrbuch, einem Tagebuch und einem juristischen Vertrag. Sie haben unterschiedliche Autoren, unterschiedliche Gründe für ihre Existenz und unterschiedliche Regeln dafür, wie man sie nutzen kann.
Dieses Paper argumentiert, dass Open-Source-Software (OSS) genau wie diese Bibliothek ist. Forscher behandeln Open-Source-Code oft wie eine einzige, einheitliche Gruppe, aber die Autoren sagen: „Nein, das ist nicht eine Sache.“ Es ist tatsächlich eine Sammlung von 14 verschiedenen „Sub-Genres“, von denen jedes seine eigene Persönlichkeit, seine eigenen Regeln und seine eigene Art des Überlebens hat.
Hier ist eine einfache Aufschlüsselung ihrer Ergebnisse unter Verwendung alltäglicher Analogien:
1. Das große Problem: Der „Einheitsmaß“-Fehler
Stellen Sie sich einen Arzt vor, der untersucht, wie Menschen die Heilung eines gebrochenen Arms vollziehen. Er untersucht einen Profisportler, ein Kleinkind und eine ältere Person. Wenn er die Ergebnisse mittelt und sagt: „So heilt jeder“, dann liegt er falsch. Der Sportler braucht einen anderen Plan als das Kleinkind.
Das Paper sagt, dass Forscher denselben Fehler bei Software machen. Sie untersuchen ein populäres Projekt (wie ein Linux-Betriebssystem) und nehmen an, dass ihre Erkenntnisse für alle Software gelten. Aber ein Projekt, das von einem einzelnen Unternehmen für Profit betrieben wird, ist völlig anders als ein Projekt, das von Freiwilligen geleitet wird, um einem Dorf in einem Entwicklungsland zu helfen. Wenn man versucht, die „Unternehmens-Regeln“ auf das „Freiwilligen-Projekt“ anzuwenden, könnte es scheitern.
2. Die Lösung: Ein „Menü“ aus 14 Software-Typen
Die Autoren haben ein „Menü“ (eine Typologie) erstellt, um Software in 14 verschiedene Kategorien einzuteilen, basierend darauf, wer sie antreibt, wer das Sagen hat und wer die Rechnungen bezahlt.
Betrachten Sie diese Kategorien wie verschiedene Arten von Restaurants:
- Die Restaurantkette (Unternehmensgestützt): Wird von einem großen Konzern geführt (wie Red Hat oder GitLab). Sie wollen Geld verdienen, also kontrollieren sie das Menü und die Richtung.
- Das Food-Truck-Kollektiv (Stiftungsverwaltet): Eine Gruppe konkurrierender Unternehmen (wie Google und IBM) schließt sich einer neutralen Non-Profit-Organisation (wie der Linux Foundation) an, um eine gemeinsame Küche zu bauen. Sie einigen sich auf Regeln, damit sie sich nicht über den Herd streiten.
- Der Gemeinschaftsgarten (Community-getrieben): Kein Chef. Freiwillige bauen Gemüse an, weil sie das Gärtnern lieben. Der beste Gärtner entscheidet darüber, was als Nächstes gepflanzt wird, nicht die Person, der das Land gehört.
- Die Charity-Küche (OSS für soziale Zwecke): Wird speziell gebaut, um Hungernde zu speisen oder bei Katastrophen zu helfen. Das Ziel ist nicht Profit, sondern Leben zu retten. Die Menschen, die hier arbeiten, bleiben länger, weil sie leidenschaftlich für die Mission sind.
- Die Schulkantine (Bildungswesen): Schüler kochen Mahlzeiten, um zu lernen, wie man eine Küche führt. Sie sind dort für eine Note, nicht für eine Karriere.
- Der Solo-Hobbyist (Hobbyist/Einzelperson): Eine Person, die in ihrer Garage aus Spaß ein cooles Gadget baut. Wenn diese Person krank wird, stoppt das Projekt (dies wird als „niedriger Truck-Faktor“ bezeichnet).
- Das Protestschild (Protestware): Ein Entwickler ändert heimlich seinen Code, um eine politische Botschaft zu senden oder ein System zu sabotieren. Das Ziel ist nicht, einen Bug zu beheben, sondern ein Statement zu setzen.
- Die unsichtbare Rohrleitung (Kritische digitale Infrastruktur): Dies sind die winzigen, langweiligen Teile des Codes (wie
curloderOpenSSL), auf die das gesamte Internet angewiesen ist. Sie werden oft von nur ein oder zwei erschöpften Freiwilligen gepflegt, die nicht genug bezahlt werden. Wenn sie kaputtgehen, leckt das gesamte Internet.
3. Warum das wichtig ist (Die „Forschungsagenda“)
Die Autoren listen diese Typen nicht nur auf; sie sagen den Forschern, dass sie aufhören sollen, sie zu vermischen.
- Das „Transfer“-Problem: Wenn Sie herausfinden, wie man Freiwillige bei einem „Gemeinschaftsgarten“-Projekt bei Laune hält, hilft dieser Rat vielleicht nicht bei einem „Restaurantketten“-Projekt. Das Paper fragt: Funktioniert eine Regel, die für einen Software-Typ funktioniert, auch für die anderen? Die Antwort ist wahrscheinlich „nein“.
- Die blinden Flecken: Einige Software-Typen sind gut untersucht (wie die großen Community-Projekte), aber andere werden ignoriert. Das Paper weist darauf hin, dass wir sehr wenig über „Protestware“ (Software, die für politische Sabotage genutzt wird) oder „Open Source Appropriate Technology“ (Werkzeuge für Grundbedürfnisse in armen Gebieten) wissen. Dies sind die „dunklen Ecken“ der Bibliothek, die mehr Licht benötigen.
4. Das Fazit
Das Paper kommt zu dem Schluss, dass Open Source plural ist, nicht singular. Es ist nicht nur „Code“; es ist eine Mischung aus Unternehmen, Wohltätigkeitsorganisationen, Schulen, Hobbyisten und politischen Aktivisten.
Indem wir diese 14 verschiedenen „Sub-Genres“ erkennen, können wir:
- Besser verstehen: Aufhören, falsche Verallgemeinerungen darüber zu machen, wie Software funktioniert.
- Besser helfen: Wenn Sie ein Projekt unterstützen wollen, müssen Sie wissen, um welche Art von Projekt es sich handelt, um die richtige Art der Hilfe zu leisten.
- Besser studieren: Forscher müssen angeben, welchen „Typ“ Software sie untersuchen, damit ihre Ergebnisse Sinn ergeben.
Kurz gesagt: Nicht alles Open Source ist gleich geschaffen, und sie so zu behandeln, verbirgt die wahre Geschichte.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.