Die Zukunft von Open Source

 (blog.gitbutler.com)
19 Punkte von xguru 2024-08-12 | 5 Kommentare | Auf WhatsApp teilen
  • Unsere COO und Mitgründerin Anne wurde verklagt, als sie CEO des deutschen Lebensmittelunternehmens Delinero war. Ein Lieferant hatte bereitgestellte Himbeermarmelade als "Himbeermarmelade" gekennzeichnet, obwohl in Deutschland die Konfitürenverordnung galt, nach der etwas nur dann als „Marmelade“ bezeichnet werden darf, wenn es mindestens 20 % Zitrusfrüchte enthält
  • Das war eine Vorschrift, die der allgemein verwendeten Bedeutung des Wortes widersprach, aber weil es ein Gesetz war, das vor langer Zeit von wenigen Interessengruppen geschaffen wurde, musste man sich daran halten
  • Auch das heutige "Open Source" kann man als in einem ähnlichen Zustand betrachten. Die OSI reguliert einen Begriff weiterhin streng, der sich – ähnlich wie die Konfitürenverordnung – anders als der allgemeine Sprachgebrauch entwickelt hat
  • Aber wie können wir uns konstruktiv in eine bessere Richtung bewegen?

Wie man nicht "Open Source" macht

  • Als GitButler den Client-Code unter "Fair Sourcing" veröffentlichte, also mit einer nicht von der OSI genehmigten Lizenz, überlegten wir, wie wir das ankündigen sollten
  • Die meisten Menschen setzen "Open Source" mit "öffentlich auf GitHub verfügbar" gleich, und wegen der etwas riskanten Implikationen von GPL/Copyleft-Lizenzen sind die Leute außerdem sehr daran gewöhnt, nachzusehen, welche Lizenz gilt
  • Gleichzeitig wollten wir keine vagen Formulierungen wie "Source Available'd" verwenden, und um Verwirrung zu vermeiden, benutzten wir das Wort "offen" – woraufhin wir angegriffen wurden
  • Dabei wurde klar, dass eine kleine Zahl lauter Stimmen versucht, diesen Begriff zu schützen und eng zu definieren
  • "Open Source" ist nicht die logische Negation von "Closed Source". Zwischen dem öffentlichen Verständnis von „auf GitHub veröffentlicht und offen für Beteiligung“ und den 10 technischen Definitionen von „Open Source“, die die OSI selbst reguliert, klafft eine Lücke

Eine kurze Geschichte von Open Source

  • In der frühen Computerära der 1950er- und 1960er-Jahre war Software an Hardware gebunden, sodass es keinen Bedarf gab, sie gesondert zu unterscheiden, und Hardwareunternehmen verteilten sie frei
  • In den 1970er- und 1980er-Jahren wurde Hardware zur Commodity, Software bekam dadurch eigenen Wert, und Großunternehmen wie IBM und AT&T begannen, den Zugang zu Quellcode einzuschränken, der mit hohem Aufwand entwickelt worden war
  • Daraufhin begannen Richard Stallman und andere, ein eigenes Betriebssystem und eigene Werkzeuge zu schaffen, die vor Unternehmensinteressen geschützt waren, und mit reziproken Lizenzen wie der GPL zwangen sie IBM, AT&T und andere dazu, alles ebenfalls als freie Software zu veröffentlichen, wenn sie deren Arbeit verwendeten

    "Wenn wir nicht mit euren Spielsachen spielen dürfen, dürft ihr auch nicht mit unseren spielen."

    • Sie nannten diese Bewegung "freie Software" und schufen viele beeindruckende Werkzeuge wie Emacs und das GNU-Compilersystem. Diese sind bis heute grundlegende Werkzeuge eines Großteils des modernen Computings
    • Der grundlegende Fokus der Freie-Software-Bewegung war es, den Nutzern die Freiheit zu garantieren, Software auszuführen, zu kopieren, zu verbreiten, zu untersuchen, zu verändern und zu verbessern – Freiheiten, die ihnen damals durch die umgebenden Unternehmensinteressen genommen wurden
  • Anfang der 1990er-Jahre entstand mit dem Linux-Kernel von Linus Torvalds ein vollständiges Betriebssystem, und das Ökosystem freier Software – etwa der LAMP-Stack – wuchs so stark, dass auch Unternehmen es einsetzten und von ihm abhängig wurden
  • 1997 veröffentlichte Eric Raymond den Essay "Die Kathedrale und der Basar", in dem er argumentierte, dass das Entwicklungsmodell freier Software dem geschlossenen überlegen sei; der Text wurde herangezogen, um die Freigabe des Quellcodes der Navigator Suite durch Netscape zu rechtfertigen
    • Als Netscape sich entschied, den Quellcode freizugeben, einigten sich Raymond und einige prominente Linux- und Freie-Software-Entwickler bei einer Strategiesitzung in Palo Alto darauf, dafür den neuen Begriff "Open Source" zu prägen und zu verwenden

    "Die Teilnehmer des Treffens glaubten, dass die praktischen und geschäftlichen Gründe, die Netscape dazu motiviert hatten, seinen Code freizugeben, eine wertvolle Möglichkeit seien, mit potenziellen Softwarenutzern und -entwicklern zu kommunizieren und sie dazu zu bewegen, sich an der Community zu beteiligen sowie den Quellcode zu erstellen und zu verbessern. Die Teilnehmer hielten es außerdem für nützlich, ein einheitliches Label zu haben, das diesen Ansatz kennzeichnet und ihn vom philosophisch und politisch ausgerichteten Label ‚freie Software‘ unterscheidet."

  • Wichtig ist, dass es zwischen "freier Software" und "Open Source" keinen wesentlichen rechtlichen oder praktischen Unterschied gibt
    • Die meisten Lizenzen sind mit beiden Definitionen kompatibel und in beiden anerkannt
    • "Open Source" war lediglich ein businessfreundliches Rebranding, das die politischen Ziele von Stallman und seiner Bewegung von der praktischen Nützlichkeit offener Software trennen sollte, um mehr Unternehmen wie Netscape dazu zu bewegen, die Öffnung professionellen Quellcodes zu akzeptieren
  • Oder, wie Leute aus dem Lager der freien Software es formulierten:

    "Open Source ist eine Entwicklungsmethodik, freie Software ist eine soziale Bewegung."

Open Source und das GitHub-Zeitalter

  • Die Definition und Vermarktung des Begriffs "Open Source" stammt aus dem Jahr 1998, also von vor mehr als 25 Jahren. Was ist also in den vergangenen 25 Jahren im Bereich Open Source und Softwareentwicklung passiert?
  • Besonders in den letzten 10 Jahren hatten GitHub und GitHub-artige Softwareentwicklung enorme Auswirkungen auf Open Source
  • 1998 versuchte man noch, Unternehmen davon zu überzeugen, offene Software anzunehmen; heute wird fast jede Open-Source-Software von Unternehmen geschrieben oder gesponsert
  • Eine der größten Veränderungen ist die "Standardisierung des Entwicklungs-Workflows", insbesondere vorangetrieben durch GitHub
  • Früher gab es große Unterschiede zwischen Open-Source-Projekten und Unternehmensprojekten, heute gibt es fast keine mehr
    • Alle verwenden Git
    • Fast alle verwenden Pull Requests (oder Merge Requests oder eine andere nachgebildete Form dieser Funktion)
    • Die meisten Teams nutzen irgendeine Form von GitHub Flow (Trunk-based Development, GitLab Flow usw.)
  • Jetzt ist die einzige wirkliche Differenz noch, ob ein Repository öffentlich ist oder nicht. Vor 25 Jahren gab es in den Prozessen viel Reibung, heute braucht es fast keine Prozessänderung mehr, um etwas als Open Source zu veröffentlichen

Was ist der nächste Schritt für Open Source?

  • Ist die Open-Source- bzw. Freie-Software-Bewegung erfolgreich gewesen, jetzt, da fast jedes Unternehmen Open-Source-Software nutzt und produziert?
  • In der Open-Source-Welt gibt es derzeit zwei große Probleme: "Nachhaltigkeit für Entwickler" und "Ist kommerzielles Open Source tragfähig?"

Das Problem der Nachhaltigkeit für Entwickler

  • Mit der starken Abhängigkeit von Open Source entstehen Nachhaltigkeits- und Wartungsprobleme. Der Missbrauch des XZ-Utils-Backdoors ist ein jüngst bekannt gewordenes Beispiel
  • Fast alle Maintainer kämpfen mit Burnout und Belästigung. Mit dem Schreiben und Pflegen von Open-Source-Software Geld zu verdienen, ist nahezu unmöglich
  • Die meisten Open-Source-Entwickler und Maintainer werden inzwischen von Großunternehmen unterstützt
    • Wenn man sich Linux, Git, Ruby, React usw. ansieht, sind die meisten Beitragenden zu wichtigen Open-Source-Projekten professionell bei Unternehmenssponsoren wie GitHub, Microsoft oder Red Hat angestellt
  • Es ist schwierig, ein ordentliches Auskommen zu haben, wenn man ein Projekt wie XZ Utils betreut
    • Ideal wäre es, wenn nicht ein einzelnes Unternehmen einen Entwickler bezahlt, sondern Tausende Unternehmen kleinen Beiträge an professionelle Maintainer leisten würden
  • Das Kernproblem ist, dass es derzeit keinen guten Weg gibt, das umzusetzen
    • Es gibt vielversprechende Initiativen wie GitHub Sponsors, Thanks.dev, Liberapay und Tidelift, aber das Problem passender Anreize für Unternehmensspenden ist noch nicht gelöst
  • Sentry treibt derzeit eine neue Initiative namens OSS Pledge voran, und GitButler plant, sich nach dem Launch im Oktober daran zu beteiligen
  • Ob ein solcher Ansatz das große und weiter wachsende Problem der Nachhaltigkeit für Entwickler im Open-Source-Ökosystem lösen kann, ist jedoch noch unklar

Das Problem mit kommerziellem Open Source

  • Entwickler sind lange Zeit mit der Liebe zu Open Source und offenen Communities aufgewachsen und wollen deshalb, wenn sie ein Unternehmen oder Projekt gründen, standardmäßig offen sein
    • Doch genauso wie einzelne Maintainer hat auch Open Source ein Problem der unternehmerischen Nachhaltigkeit
  • Wie die Fälle Elasticsearch und Redis zeigen, besteht bei professioneller Softwareentwicklung mit erheblichem Zeit- und Geldeinsatz das Risiko, dass Großunternehmen wie Amazon diese Arbeit nutzen und direkt damit konkurrieren
  • Viele professionelle Hersteller möchten in Software investieren und später verhindern, dass diese gegen sie verwendet wird
    • Das bedeutet, bei der Lizenzierung kreativ zu werden oder den Quellcode zu schließen
  • Ich glaube, dass die Fair-Source-Bewegung eine hervorragende und notwendige Lösung für dieses wachsende Problem ist und die Lücke im Open-Source-Ökosystem schließt, die in den letzten Jahren zunehmend Probleme und Verwirrung verursacht hat
    • Gemeint ist ein neuer Begriff für professionelle Projekte, die größtenteils permissiv, mit verfügbarem Quellcode und unter Beteiligung der GitHub-Community entwickelt werden; ich halte das für eine dringend benötigte Lösung, um mehr Projekte, die früher privat geblieben wären, an die Öffentlichkeit zu bringen

Die Zukunft der Zusammenarbeit

  • Die Zukunft von Open Source ist nicht einfach nur "Open Source" und die 10 Konfitürenverordnungen der OSI
  • Sie ist eine Kombination aus Open Source, das für alle möglich und wertvoll ist, Fair Source, das für sichere Investitionen nötig ist, und umfangreicher gemeinschaftlicher Finanzierung wichtiger offener Basisbibliotheken und Projekte
  • Wir müssen die Pflege wichtiger Open-Source-Bibliotheken nachhaltig machen und eine nachhaltige Klasse kommerzieller, quelloffener Lizenzen akzeptieren und normalisieren
  • Wir sollten alles, was möglich ist, unter OSI-Lizenzen als Open Source veröffentlichen, die so viel wie möglich erlauben, und vor allem Closed Source zu etwas aus der Vergangenheit machen
  • Was du jetzt tun kannst:
    • Mache Closed-Source-Software zu Fair Source
    • Wenn du von Open Source abhängig bist, schließe dich OSS Pledge an

Verwandte Beiträge

5 Kommentare

 
bus710 2024-08-13

In einer kapitalistischen Welt zu leben und sich ausschließlich auf Open Source zu konzentrieren, ist in der Realität kaum möglich. Andererseits denke ich, dass wirklich wichtige Bibliotheken oder Utilities mehr Sponsoring durch Unternehmen erhalten sollten.

Vor allem Desktop-/Terminal-Utilities im User Space haben es schwer, solche Unterstützung zu bekommen. Beim Kernel unterstützen große Unternehmen viel, im mobilen Bereich ist die Kommerzialisierung über App Stores gut etabliert, und bei Web oder Firmware gibt es durch eine gewisse Marktanalyse vor der Entwicklung weniger Anlass zur Sorge. Aber bei Software und Bibliotheken, die normale Nutzer unbemerkt verwenden, ist es oft schon schwierig, überhaupt Hürden zu definieren, sodass es wirklich schwer zu sein scheint, damit Geld zu verdienen. Open Source ist zwar ziemlich lebendig, aber den nächsten Schritt darüber hinaus zu machen, ist nicht leicht.
 
bus710 2024-08-13

So sehr ich Open Source liebe und gern nutze, hoffe ich auch, dass die Menschen, die im Verborgenen mit großem Einsatz für viele entwickeln, durch die richtige Wahl der Lizenz angemessen davon profitieren können.
 
chabulhwi 2024-08-13

In dem von Drew Devault verfassten Beitrag „So you want to compete with or replace open source (Sie möchten also mit Open Source konkurrieren oder Open Source ersetzen?)“ findet sich die folgende Passage.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

Bei freier und Open-Source-Software entsteht ein gemeinsamer Nutzen, wenn Beitragende aus unterschiedlichen Organisationen zusammenarbeiten. Bei Fair-Source-Software hingegen gibt es für andere Beitragende wenig oder gar keinen Grund, gratis für Einzelpersonen oder Organisationen zu kooperieren, die eine Monopolstellung genießen.

Wie dem auch sei, ich halte Fair Source ebenfalls für besser als Closed Source, und ich möchte auch nicht, dass Maintainer von Open-Source-Software für ihre Arbeit gern entlohnt werden möchten, dies aber nicht können.

Ich bezweifle allerdings, dass Fair Source wie Open Source in den Genuss kostenloser Entwicklungsbeiträge kommen kann. Und wenn jemand seine Software als Open Source veröffentlicht, sollte diese Person sich darüber im Klaren sein, dass sie von keinem Nutzer eine finanzielle Vergütung erhalten könnte und dass diese Software zum „free lunch“ der großen Cloud-Konzerne werden kann.