Open-Source-Maintainer zu bezahlen ist etwas Positives
(jacobian.org)- Das Open-Source-Ökosystem wird von vielen Menschen und Unternehmen genutzt, doch es gibt den Widerspruch, dass Maintainer schnell kritisiert werden, wenn sie ihren Lebensunterhalt über kommerzielle Funktionen, Anstellungen bei Großunternehmen oder Investitionen sichern
- Open Source wird hier weiter gefasst als die strengen Definitionen von OSI und FSF: Wenn Quellcode gelesen, verändert und modifizierte Versionen verteilt werden können, zählen auch Polyform, JSON license und BSL dazu
- Nachhaltigkeit meint nicht nur Governance oder die Gesundheit einer Community, sondern ob Maintainer ihre Grundbedürfnisse wie Wohnen, Essen und medizinische Versorgung decken und angenehm leben können
- Django wird täglich von Hunderttausenden genutzt, doch es gibt nur eine Vollzeit-Fellow und eine Teilzeit-Fellow der DSF, die bezahlt ausschließlich an Django selbst arbeiten; auch Python wird täglich von Millionen genutzt, hat aber weniger als 12 bezahlte Maintainer
- Patreon, GitHub Sponsors, VC, Open Core und Nicht-OSI-Lizenzen haben alle Schwächen, doch wenn sich die Wut gegen einzelne Maintainer richtet, lässt sich der gesellschaftliche Wert von Open Source nur schwer ausweiten
Warum es gut ist, wenn Maintainer bezahlt werden
- Ausgangspunkt ist die Sichtweise, dass es keine Ausnahme, sondern ein Grund zum Feiern ist, wenn Open-Source-Maintainer bezahlt werden
- Statt Maintainer zu kritisieren, die einen Weg gefunden haben, ihren Lebensunterhalt zu verdienen, sollte man die Strukturen und Systeme kritisieren, die es schwer machen, bezahlt zu werden
- Menschen, die von Open-Source-Arbeit leben wollen, sollten ihre Grundbedürfnisse decken und angenehm leben können
- Dahinter steht die Annahme, dass Open Source eine Zusammenarbeit ist, von der alle profitieren, und dass eine Welt ohne Open Source deutlich schlechter wäre als die heutige
Open Source und Nachhaltigkeit im weiteren Sinn
- Open Source und Free Software werden nicht im engen Sinne der Definitionen von OSI und FSF verwendet, sondern in einem breiteren Sinn
- Gemeint ist Software, deren Quellcode gelesen, verändert und in abgewandelter Form verteilt werden kann
- Dazu zählen nicht nur OSI- und FSF-Lizenzen, sondern auch Polyform licenses, JSON license und BSL
- Enge Definitionen wie „nur OSI-genehmigte Lizenzen sind Open Source“ oder „nur GPL ist echte freie Software“ werden als Teil des Problems gesehen
- Lizenzexperimente und Vielfalt sind nötig; auch wenn es mehr Einschränkungen gibt als „jede Nutzung zu jedem Zweck“, kann etwas in die Kategorie Open Source fallen
- Nachhaltigkeit bedeutet, ob Maintainer beim Schreiben freier Software ein akzeptables oder angenehmes Leben führen können
- Mindestmaßstab ist die Deckung grundlegender Bedürfnisse wie Wohnen, Nahrung und medizinische Versorgung
- Idealerweise sollte allein durch Open-Source-Arbeit auch ein angenehmes oder luxuriöses Leben möglich sein
Open Source ist derzeit nicht nachhaltig
- Die Zahl der Menschen, die allein vom Schreiben freier Software leben, liegt unter allen Software Engineers praktisch nahe bei 0
- Es gibt Unternehmen wie Canonical, Red Hat, Hashicorp und Mozilla, die Open-Source-Arbeitende beschäftigen, doch verglichen mit den Millionen Engineers, die proprietäre Software schreiben, ist der Umfang sehr klein
- Auch schreiben nicht alle Engineers in solchen Organisationen ausschließlich Open Source, und viele Organisationen stützen sich auf Geschäftsmodelle, bei denen Teile des Produkts proprietär sind
-
Zahlen zu Django und Python
- Hunderttausende Engineers nutzen Django jeden Tag
- Für Django selbst arbeiten bezahlt und dediziert nur eine Vollzeit-Fellow und eine Teilzeit-Fellow, die von der DSF angestellt sind — also 1,5 Personen
- Millionen Menschen nutzen Python täglich, aber weniger als 12 Personen werden für Arbeit an Python bezahlt
- Dazu gehören PSF Developers-in-Residence sowie eine kleine Zahl von Maintainern, die bei Unternehmen wie Google und Microsoft beruflich mit Python arbeiten
- In einem nachhaltigen Zustand bräuchte Django etwa 12 Vollzeitkräfte mit einer Vergütung nahe am Branchenmedian, und Python bräuchte Dutzende
- Allein PyPI bräuchte angesichts von Umfang, Größe und Bedeutung mindestens ein Team von 10 bis 15 Personen
- Selbst wenn „irgendeine Person in Nebraska“ eine zentrale Abhängigkeit allein betreut, braucht diese Person Kolleginnen und Kollegen, damit sie gut leben und Urlaub machen kann — nur dann ist es nachhaltig
Das Ideal öffentlicher Förderung und die heutige Lücke
- Ideal wäre, dass freie Software als öffentliches Gut anerkannt und von Gesellschaft und Staat angemessen finanziert wird
- Dahinter steht die Sichtweise, dass auch Probleme wie Gesundheitsversorgung, Zugang zu Wohnraum, öffentlicher Nahverkehr und soziale Sicherungssysteme gelöst werden müssen
- Solche Veränderungen passieren jedoch nicht sofort, und es ist ungewiss, ob sie zu Lebzeiten eintreten werden
- Die Aussage „Der Staat sollte dafür zahlen, also dürfen private Unternehmen Maintainern kein Geld geben“ läuft in der Realität, solange der Staat nicht zahlt, auf die Schlussfolgerung hinaus: „Maintainer sollten nicht bezahlt werden“
- In der heutigen Welt muss anerkannt werden, dass Maintainer Geld brauchen
Jede Art, bezahlt zu werden, ist erst einmal ein Gewinn
- In der Realität bedeutet Nachhaltigkeit von Open Source, dass bei Maintainern tatsächlich Geld ankommt
- Wenn Maintainer einen Weg gefunden haben, Miete zu zahlen und gleichzeitig freie Software zu schreiben, ist das an sich ein positives Beispiel
- Es gibt viele Wege, die als positive Beispiele gelten können
- Bei Microsoft angestellt sein und an Python arbeiten
- Fördermittel erhalten
- Auf Patreon ein nachhaltiges Unterstützungsniveau erreichen
- VC-Investitionen für die Entwicklung freier Software einwerben
- Mit einem Open-Core-Modell ein nachhaltiges Geschäft aufbauen
- Bei einem Unternehmen wie Hashicorp arbeiten
- Ein offenes Projekt durch kostenpflichtige Hosting-Optionen unterstützen
- Erfolgreich eine nicht OSI-genehmigte Lizenz einsetzen, um Ausbeutung nach Amazon-Art zu vermeiden
Wiederkehrende Kritik und ihre Grenzen
- Jedes Mal, wenn Maintainer bezahlt werden, folgt Kritik an der jeweiligen Finanzierungsform
- Kritik, dass nicht OSI-konforme Lizenzen kein Open Source seien
- Kritik, dass bei Microsoft angestellte Personen Unternehmensinteressen unterworfen und nicht vertrauenswürdig seien
- Kritik, Patreon sei Betteln
- Kritik, GitHub Sponsors helfe Microsoft beim Rent-Seeking
- Kritik, VC-Geld werde zu einem Rug Pull oder zu Enshittification führen
- Kritik, Open Core sei Bait and Switch
- Ein Maintainer soll sogar dafür kritisiert worden sein, T-Shirts verkauft zu haben
- Jede dieser Methoden hat reale Probleme
- VC-Investitionen bringen Bedingungen mit sich und können später zu Problemen führen
- Patreon, GitHub und Stripe behalten einen Teil der Unterstützungsbeiträge ein
- Zusätzliche Einschränkungen bei PolyForm oder BSL kollidieren mit dem Ideal von Freedom 0
- Es kann frustrierend sein, wenn die zentrale gewünschte Funktion eines Open-Core-Tools nur unter einer kostenpflichtigen Lizenz verfügbar ist
- Diese Systeme kann man kritisieren, aber einzelne Maintainer, die Geld erhalten, anzugreifen, lenkt die Wut in die falsche Richtung
- Es ist, als würde man jemanden anschreien, weil er in einem Dollar General einkauft, wenn das der einzige erreichbare Laden ist; das Problem liegt nicht beim Individuum, sondern bei Strukturen und Politik
Reinheitsansprüche begrenzen den gesellschaftlichen Wert von Open Source
- Sehr viel mehr Menschen sollten freie Software schreiben und dafür bezahlt werden
- Dafür muss man auch unreine oder unvollkommene Finanzierungsformen akzeptieren
- Finanzierungsmechanismen und gesellschaftliche Ungleichheit müssen weiterhin kritisiert und verändert werden
- Wenn Maintainer einen Weg gefunden haben, bezahlt zu werden, ist es für Open Source insgesamt nützlicher, diese Person zu feiern
1 Kommentare
Hacker-News-Kommentare
Dem Teil, in dem „nicht OSI-genehmigte Lizenzen“ in die Kategorie Open Source aufgenommen werden, kann ich nur schwer zustimmen.
Der Grund, warum sie nicht OSI-genehmigt sind, ist, dass die Community schon vor langer Zeit definiert hat – und es auch heute noch in sinnvoller Weise gilt –, dass sie keine Open Source sind.
Auch die Behauptung, man solle darüber hinaus viele Dinge mit ganz unterschiedlichem Charakter allesamt als Sieg betrachten, überzeugt mich nicht. Zum Beispiel kann auch „bei Microsoft angestellt sein und an Python arbeiten“ je nach konkreten Bedingungen der Stelle eher eine Falle als ein Sieg sein; siehe https://ghuntley.com/fracture/.
Der ganze Artikel erklärt, warum er die OSI-Definition absichtlich ablehnt. Die Gegenargumente scheinen sich lediglich auf genau jene OSI-Definition zu berufen, die er ausdrücklich zurückweist.
Er stellt klar, dass er bewusst „open source“ / „free software“ in Kleinbuchstaben verwendet, nicht Open Source™ der OSI oder Free Software™ der FSF, sondern in einem weiteren Sinn von „Software mit Quellcode, den man lesen, ändern und unter bestimmten Bedingungen abgewandelte Versionen verbreiten kann“.
Deshalb zählt er nach seinem eigenen Verständnis von „open source“ nicht nur OSI-/FSF-Lizenzen dazu, sondern auch Polyform, die JSON license und BSL.
Es wirkt eher so, als wolle er verschiedene Arten bezahlter Arbeit als „Open Source“ gelten lassen.
Wenn RHEL zum Beispiel weiterhin Open Source ist, dann sind Red-Hat-Programmierer bezahlte Open-Source-Entwickler; wenn RHEL inzwischen proprietäre Software ist, sinkt entsprechend die Zahl der Menschen, die für Open-Source-Arbeit bezahlt werden.
Die eigentliche Streitfrage ist aber, ob „diese Definition heute noch die stichhaltigste ist“.
Vielleicht ist sie das, aber die Definition selbst zu hinterfragen, ist ebenfalls eine völlig legitime Frage – und meiner Ansicht nach genau das, was die Leute gerade tun.
Die OSI genehmigt neue Lizenzen inzwischen nur noch, wenn sie ihrer Ansicht nach eine Lücke schließen, die bestehende OSI-genehmigte Lizenzen nicht abdecken. Daher gibt es zahllose mögliche Lizenzen, die alle Kriterien der Definition erfüllen, aber nicht genehmigt werden.
[1] https://opensource.org/osd/
Vor ein paar Wochen habe ich einem Senator in den USA geschrieben, weil es keinerlei staatliche Unterstützung für unabhängige Engineers und kleine FOSS-Projekte gibt.
NLNet in der EU ist großartig, und die USA brauchen wirklich etwas wie NLNet.
Allerdings kenne ich die Umsetzung von Verkehrsprojekten aus erster Hand, und angesichts der enormen Verschwendung darin bin ich unschlüssig, weil solche Förderung die Lage auch verschlimmern könnte.
Ich möchte zustimmen und verstehe die Position, aber mit dem Wort „immer“ geht die Nuance verloren.
Wenn ein Unternehmen jemanden dafür bezahlt, an Open Source zu arbeiten, und das Projekt dabei in eine Richtung lenkt, die den Interessen anderer Nutzer widerspricht – kann das dann gut sein? Ich glaube nicht.
Ich bin dafür, dass Menschen ihren Lebensunterhalt bestreiten können, aber nur weil dadurch „einigermaßen freier“ Quellcode entsteht, kann ich schlechtes Verhalten nicht gutheißen.
Der Kern ist, Perfektion nicht zum Feind des Guten werden zu lassen.
Wir sollten darauf hinarbeiten, dass alle, die an Open-Source-Codebasen arbeiten wollen, angemessene öffentliche Mittel erhalten. Bis dahin müssen wir aber auch die Realität akzeptieren, dass Unternehmen einige FLOSS-Codebasen finanzieren.
Zu sagen, der Staat solle das unterstützen, klingt gut; wenn der Staat es in der Praxis aber nicht tut, kann es am Ende darauf hinauslaufen, dass „Open-Source-Maintainer kein Geld bekommen sollten“.
Wenn Community und Nutzer die Finanzierung nicht übernehmen, tun es private Unternehmen – und dann bekommen sie Mitspracherecht.
Open Source darf nicht zu ausgelagerter „Gratisarbeit“ werden, die Großkonzerne abschöpfen.
Am besten funktioniert hat bisher ein Freemium-Modell wie im WordPress-Ökosystem: eine kostenlose GPL2+-Version beibehalten und Premium-Add-on-Downloads, Update-Lizenzen und Support verkaufen.
Open Source ist der Politik ähnlich: Wer bezahlt, hat das Sagen. Wenn die Community wirtschaftlich nicht eigenständig ist, bestimmt externes Geld die Richtung.
Viele Open-Source-Beiträge sind beeindruckend und lobenswert, aber tagsüber arbeiten die meisten in privaten Unternehmen, die Marktanteile und wirtschaftliche Kontrolle ausbauen wollen.
Mit der einen Hand tragen sie zu Open Source bei, während sie mit der anderen durch ihre Arbeit in privaten Unternehmen einen Teil dieser Wirkung wieder zurückdrehen.
Deshalb muss Open Source sich selbst finanzieren und zu einer eigenen wirtschaftlichen und politischen Kraft werden. Sonst bleibt sie immer auf der Seite, die Regeln akzeptieren muss, und muss weiter gegen Versuche privater Lobbyarbeit kämpfen, Open Source zu beschädigen.
Meist entstehen innerhalb eines bestimmten Zeitraums konkrete Deliverables, und dann wird Open Source von einem Vollzeit-Hobby zu einem Beruf aufgewertet.
Es ist zwar eher unwahrscheinlich, dass die Richtung, in die ein Unternehmen ein Projekt zieht, gut ist, aber man kann auch nicht sagen, dass sie immer schlecht ist.
Man kann sich auch eine Situation vorstellen, in der es für die vom Unternehmen gewünschte Richtung viel mehr potenzielle Nutzer gibt und die wenigen bisherigen Nutzer forken können.
Ein guter Kontext, um sich an die Ursprünge der Open Source Initiative und ihrer Definition zu erinnern.
Die OSI erklärte 2007 in ihrer eigenen Geschichte, man habe die moralistische und konfrontative Haltung abgelegt, die früher mit „free software“ verbunden war, und sich dafür entschieden, Open Source mit den pragmatischen und geschäftlichen Argumenten zu verkaufen, die Netscape bewegt hatten. Außerdem habe man den Begriff „open source“ sowie die von Raymond entwickelte pragmatische und marktfreundliche Rhetorik übernommen.
Ein paar Jahrzehnte später ist es ein wenig komisch, wenn Nutzer von Nicht-OSI-Lizenzen, die die Ausbeutung durch Großkonzerne verhindern wollen, sehr moralistisch dafür kritisiert werden, nicht „echtes Open Source“ zu sein.
http://web.archive.org/web/20071115150105/https://opensource...
Letztere führen häufig dazu, dass man keine Dienste hosten darf, die BUSL-lizenzierten Code verwenden, was geschäftliche Risiken schafft.
Daraus ergeben sich Fragen wie: ob man mit Anwälten klären muss, ob ein bestimmter Use Case erlaubt ist; woher man weiß, wann man eine Grenze überschreitet, selbst wenn es derzeit noch in Ordnung ist; ob es um einen umsatzgenerierenden Dienst geht oder nur dann gilt, wenn er Kunden direkt bereitgestellt wird.
In Unternehmen mit Consulting-Strukturen wie IBM oder Collins, in denen auch Services zwischen internen Teams intern verrechnet werden, kann das selbst dann problematisch sein, wenn kein externer Kunde dafür bezahlt.
Unklar ist auch, ob man Entwickler einstellen kann, um Beiträge zu leisten, wenn Upstream nicht auf Bug- oder Feature-Requests reagiert, ob man den Code in interne Infrastruktur und Tools integrieren kann und ob man ihn frei in größere Projekte einmischen darf.
Unabhängig von der moralischen Seite solcher Lizenzen lässt sich schon rein aus geschäftlicher Sicht erklären, warum sie für die OSI ungeeignet sind und daher wohl auch geistig nicht „Open Source“ sind.
Die Community, in der ich in den letzten Jahren am stärksten involviert war, war R/tidyverse.
Einige Entwickler werden von Organisationen wie RStudio (heute Posit) oder dem R Consortium dafür bezahlt, an Software, Dokumentation und Community-Arbeit zu arbeiten.
Meine Erfahrung als Programmierer in diesem Bereich ist hervorragend. Wenn es hauptberuflich finanzierte OSS-Contributors gibt, arbeitet jemand mit enormer Hebelwirkung sehr viel Zeit an einem Projekt, wovon Tausende R-Enthusiasten profitieren.
Wenn man Libraries wie tidyverse-Pakete, Shiny oder RMarkdown nutzt, ist die Dokumentation sehr gut strukturiert und die Beispiele sind einfach und ausgezeichnet.
Oft stimmt die Vermutung „so ungefähr wird es wohl funktionieren“ sofort, und häufig sind Funktionen oder Pakete von Anfang an genau so entworfen.
Schon eine einzige dedizierte Person scheint die Qualität von OSS deutlich zu verbessern, vielleicht auch, weil sie dabei hilft, Dutzende kleinerer Beiträge zu koordinieren.
Open-Source-Projekte schenken zentralen Bereichen wie Dokumentation und User Experience oft weniger Aufmerksamkeit. Selbst unter meinen Lieblings-OSS-Projekten gibt es welche mit schrecklicher User Experience; vermutlich, weil Contributors gern Features hinzufügen, aber ungern die Rolle übernehmen, daraus ein konsistentes Paket für Nutzer zu machen oder unnötige und verwirrende Beiträge auszusortieren.
Verglichen mit Communities, in denen es kaum oder gar keine hauptberuflich finanzierten OSS-Contributors gibt, finden sich bei Libraries, Interoperabilität und besonders in der Dokumentation deutlich mehr kleine Reibungen und Inkonsistenzen.
Die R-Community war ein erstaunliches Beispiel dafür, wie groß der langfristige Nutzen für eine Community sein kann, wenn Dutzende hauptberufliche OSS-Leute bezahlt werden, und ich bin dankbar, auf den Schultern dieser bescheidenen Riesen stehen zu dürfen.
Ich stimme der Aussage zu: „Jedes Mal, wenn Maintainer einen Weg finden, bezahlt zu werden, ist das ein Sieg.“
Das kommt immer häufiger vor, und es gibt viele Beispiele, die man feiern kann [0].
[0] https://fossfox.com/
Ich spende an mehrere Open-Source-Projekte.
Es gibt Projekte wie den Linux-Kernel, die auch ohne meine Spende gut auszukommen scheinen, aber wenn ich glaube, dass sie sie brauchen, würde ich ohne Zögern spenden.
Bei den übrigen Projekten sähe ich sie lieber scheitern, als dass sie die Open-Source-Definition kompromittieren. Für mich läuft beides auf dasselbe hinaus.
Ich weiß nicht, wann FOSS angefangen hat, nicht mehr als „frei wie in Redefreiheit“, sondern als „gratis wie Freibier“ verstanden zu werden.
Viele Diskussionen über die Bezahlung von Entwicklern scheinen diese beiden Dinge zu vermischen.
Open Source bedeutet, dass der Source offen ist und man die Freiheit hat, ihn anzusehen und zu ändern; es bedeutet nicht, dass die Kosten 0 Euro betragen.
Bei Code ist ein Modell, bei dem man Softwareprodukte verkauft und den Code frei veröffentlicht, vielleicht kein besonders realistisches Geschäftsmodell, aber es entspricht trotzdem der Definition von Open Source.
Die Freiheit, zu hacken und Änderungen vorzunehmen, war immer untrennbar mit 0 Euro Lizenzkosten verbunden.
Hätten frühe freie/offene Lizenzen zwar Source-Zugriff und Änderungen erlaubt, aber Lizenzgebühren verlangt, oder hätte frühe FOSS zwar kostenlose Nutzung erlaubt, aber Änderungen verboten, hätte es den heutigen Erfolg nicht gegeben.
Die zwei Freiheiten von „free software“ waren schon immer miteinander verbunden.
Freiheit interessiert sie nicht, Kosten interessieren alle.
Sogar viele FOSS-Entwickler lehnen es ab, bezahlt zu werden, und grenzen Leute aus, die Geld nehmen. Für sie ist Geld wie Kryptonit.
Ich halte diese Philosophie, die einem sehr grundlegenden Gesetz widerspricht, wonach alles – einschließlich der Zeit von Menschen – vergütet werden muss, für einen der Hauptgründe, warum FOSS hinter kommerzieller und proprietärer/geschlossener Software zurückbleibt.
Weil Nutzer nichts investieren müssen, kann es auf einen viel größeren potenziellen Markt skalieren, als es bei einem kostenpflichtigen Produkt möglich wäre.
Am Gratis-Sein ist irgendetwas, das das Urteilsvermögen von Menschen durcheinanderbringt.
Auch in einer Studie, in der Schokolade kostenlos oder für 0,01 Dollar angeboten wurde, war die kostenlose Option viel beliebter, obwohl die Schokolade für 0,01 Dollar deutlich hochwertiger war und ein besseres Preis-Leistungs-Verhältnis bot.
Viele Nutzer wollen einfach etwas herunterladen, ein paar Minuten ausprobieren und es dann wieder lassen. Oder zumindest testen können und im schlimmsten Fall zur kostenlosen Version zurückkehren, um nicht das Gefühl zu haben, eine schlechte Investition getätigt zu haben.
Dieser Text interpretiert „Aber das ist doch trotzdem kein Open Source“ als Kritik daran, Software unter verschiedenen Source-available-Lizenzen zu vertreiben.
Manche meinen es vielleicht so, aber für mich bedeutet es nur, dass wir einen Begriff mit klarer Bedeutung nicht verwässern sollten.
Manchmal sind Source-available-Lizenzen besser fürs Geschäft, und ich verstehe, warum Unternehmen sich dafür entscheiden.
Es ist eine weniger großzügige Wahl, aber trotzdem etwas Gutes – genauso wie ich verstehen kann, wenn nicht der gesamte Source Code einer Software veröffentlicht wird.
Ich sehe genossenschaftlich organisierte Technologieorganisationen als die Zukunft
Da Menschen nicht kostenlos arbeiten wollen, werden Beiträge zu Open-Source-Software zwangsläufig immer hinter privaten Unternehmen zurückbleiben
Ich frage mich, ob es Open-Source-Projekte gibt, die monetarisiert werden und ihre Beitragenden vergüten
Wenn ich eines Tages ein erfolgreiches Startup aufbaue, möchte ich dieses Modell erkunden