- Das WiX Toolset-Projekt führt die Richtlinie Open Source Maintenance Fee ein, um die langfristige Wartbarkeit des Projekts zu sichern
- Der Quellcode wird gemäß Lizenz kostenlos bereitgestellt, aber für die meisten Aktivitäten wie das Erstellen von Issues, das Schreiben von Kommentaren oder das Herunterladen neuer Releases gilt die Wartungskosten-Richtlinie
- Insbesondere wenn mit der Nutzung dieses Projekts Umsatz erzielt wird, ist die Zahlung dieser Wartungskosten zwingend erforderlich
- Die Zahlung kann unterstützt werden, indem man GitHub Sponsor wird
- Kleine Organisationen (unter 20 Personen): $10/mo
- Mittelgroße Organisationen (20–100 Personen): $40/mo
- Große Organisationen (über 100 Personen): $60/mo
- Weitere Details zur Richtlinie finden sich auf der offiziellen Website zur Open Source Maintenance Fee
2 Kommentare
Im Grunde ist das praktisch dasselbe wie bei RHEL.
Hacker-News-Kommentare
Mir gefällt diese Neuerung. Die Grundidee ist, dass niemand will, dass daraus Closed Source wird, der Code für alle frei offengelegt ist und jeder ihn frei nutzen kann. Denn die zusätzlichen Kosten für die Verteilung des Codes sind faktisch null. Die Maintainer wollen Unternehmen aber nicht wie in einer Wohltätigkeitsveranstaltung unbezahlt bedienen. Ihre Zeit ist begrenzt, daher ist es nur natürlich, bei Beiträgen zu gewinnorientierten Aktivitäten auch einen gewissen Ertrag zu wollen. Es ist auch in Ordnung, wenn das nicht perfekt durchsetzbar ist. Maintainer haben nun die Freiheit, auf Forderungen mit „Wenn ihr wollt, dass es uns interessiert, dann bezahlt dafür“ zu antworten. Unternehmen, die zahlen, erhalten ein gewisses Maß an Support, und normale Nutzer haben weiterhin dieselbe Erfahrung. Nur Firmen, die diese Warnung ignorieren, tragen die Konsequenzen, besonders wenn sie mit Appellen wie „viele wichtige Nutzer sind betroffen“ kommen. Wenn es wirklich wichtig ist, sollten sie eben zahlen. Jetzt, wo AI-generierter Code, Reports usw. zunehmen, scheint mir das eine ziemlich saubere Lösung für ein häufiges Problem im Open-Source-Bereich zu sein.
Ich habe dazu gemischte Gefühle. Ich nutze Wix nicht, und das ist eine allgemeine Meinung zu diesem Fall an sich. Niemand kann gezwungen werden, ein Open-Source-Projekt zu warten. Alle Fixes erfolgen freiwillig. Kein Unternehmen kann erzwingen, dass ein PR angenommen oder daran gearbeitet wird. FOSS-Entwickler stehen oft unter Stress, aber wenn es keinen finanziellen Anreiz gibt, können sie einfach ablehnen. Es mag Beschwerden geben, aber es besteht keine Pflicht, das Problem unbedingt zu beheben. Ein Sponsoring-Modell fühlt sich letztlich so an, als würde FOSS zu einem Geschäftsmodell gemacht. Dann ist es kein FOSS mehr. Das Wesen von FOSS ist, dass jeder es kopieren, verändern und zu einem Geschäft weiterentwickeln kann. Den meisten Lizenzen hat man damit zugestimmt. Vielleicht ist meine Meinung unpopulär, aber ich finde nicht, dass man in dieser Sache in Wut ausbrechen muss.
Ich möchte zwei negative Seiten dieser Richtlinie ansprechen. Erstens könnte es schwieriger werden, mehr Mitwirkende zu gewinnen. Es könnte eine Zweiklassenstruktur aus bezahlten und unbezahlten Beitragenden entstehen. Dann kommen Beschwerden wie: „Ich behebe Bugs unbezahlt, während andere Geld damit verdienen.“ Zweitens bekommt die Sache in dem Moment, in dem Geld fließt, stärker den Charakter einer Transaktion. Wenn gezahlt wurde, entstehen daraus Erwartungen und Arbeit. Natürlich hat auch das freiwillige Modell Probleme mit der Nachhaltigkeit.
So innovativ finde ich das nicht. Man hat ein Produkt kostenlos abgegeben und ist nun auf ein kostenpflichtiges Modell umgestiegen. Das wirkt auf mich einfach wie ein normales Business.
Ich fände es besser, wenn jeder für gewünschte Features oder Support zahlen könnte und der Code bis zu einem gewissen Schwellenwert Closed Source bliebe. Dieser Schwellenwert könnte je nach Interesse und Einnahmen Monate oder Jahre dauern. Am Ende würde es dann Open Source werden. Andernfalls warten alle nur darauf, dass jemand anderes bezahlt. Natürlich müsste man die Struktur so gestalten, dass nicht zu viele Forks entstehen, aber das wäre durchaus machbar.
Ich dachte, mehrere Open-Source-Projekte würden bereits so arbeiten. Ich meinte, der Fall von Beratenden, die Busybox warten, gehöre dazu, aber vielleicht habe ich die Lage missverstanden.
Das hat überhaupt nichts mit dem Website-Builder Wix zu tun, sondern hier geht es um WiX Toolset.
„Das Toolset zum Erstellen der leistungsfähigsten Windows-Installer-Erfahrung. Open Source seit 2004!“
Danke. Ich hatte es anfangs auch mit Wix verwechselt. Wix baut wirklich viele hochwertige React-Native-Bibliotheken.
Vor ein paar Monaten habe ich einen Installer für mein Open-Source-Projekt geprüft und dabei zufällig diese Richtlinie entdeckt. Solange der Source Code unter einer OSI-Lizenz steht, habe ich kein Problem mit dem Verkauf von Binärdateien. Aber an folgendem Satz im README bin ich hängen geblieben: „Für die langfristige Nachhaltigkeit dieses Projekts ist für die Nutzung von WiX Toolset eine Open-Source-Wartungsgebühr erforderlich. Der Source Code wird frei unter der Lizenz bereitgestellt, aber alle anderen Funktionen wie das Erstellen und Kommentieren von Issues, die Teilnahme an Diskussionen und das Herunterladen von Releases unterliegen ebenfalls der Wartungsgebühr. Das bedeutet, dass bei einer Nutzung zu Erwerbszwecken die Wartungsgebühr erforderlich ist.“ Ich kann das gutwillig auslegen, weil es ein Konzept ist, das sich schwer in einem kurzen Satz erklären lässt. Aber die Zusammenfassung „bei gewerblicher Nutzung zahlen“ kann gerade dadurch Missverständnisse erzeugen. Nach der MS-RL-Lizenz gibt es keine Einschränkung für kommerzielle Zwecke, wenn man selbst baut und nutzt; deshalb wirkt es auf mich wie eine Art Einschüchterungstaktik, um kommerzielle Nutzer zu Sponsoren zu machen. Ich verstehe die Schwierigkeiten von Open-Source-Maintainern, aber dieser Ansatz hat sich für mich ethisch nicht richtig angefühlt. Deshalb habe ich WiX letztlich nicht verwendet, obwohl ich kein kommerzieller Nutzer bin.
Das ist eine klare Aussage, dass kommerzielle Nutzer keinen kostenlosen Support bekommen. Du sagst, die Formulierung sei unklar, aber in dem zitierten Satz steht doch eindeutig, dass der Source Code nach den Bedingungen der Lizenz frei nutzbar ist.
Startups oder kleine Firmen mit wenig Geld nehmen ein Open-Source-Projekt, bauen es selbst, machen daraus ein Auslieferungsartefakt und verwalten es intern. Ab einer gewissen Größe ist es mehr wert, für offiziellen Support zu zahlen, der den ganzen Prozess übernimmt. Diese Richtlinie soll Unternehmen dazu bewegen, für offiziellen Support zu zahlen, wenn sie das Risiko vermeiden wollen, sich allein auf Open-Source-Binärdateien ohne direkte Unterstützung zu verlassen.
Diese Idee in einem einzigen kurzen Satz zu erklären, ist wirklich nicht leicht. Die Erwartungen an Open-Source-Projekte sind einfach zu unterschiedlich. Wenn jemand Vorschläge hat, wie man den Text verbessern kann, höre ich sie gern.
So wie ich es sehe, muss man zahlen, wenn man im Namen einer gewinnorientierten Organisation etwas fordert und darüber sprechen will. Wer Kommunikation mit dem Ziel wirtschaftlichen Nutzens führt, muss zahlen.
Wenn man die Kommentare im GitHub-Issue liest, wirkt das Team ziemlich vernünftig. Meinem Verständnis nach wollen sie nur dann wirklich Geld, wenn tatsächlich Einnahmen erzielt werden. Wenn man wirklich nur ein Solo-Entwickler ist oder ein sehr frühes Produkt baut, dürfte es sie wohl nicht allzu sehr interessieren. Es gibt auch eine Sponsoring-Seite.
Es geht um die Website selbst, https://opensourcemaintenancefee.org/. Sie ist praktisch nur im Dark Mode lesbar, im Light Mode fast gar nicht. Außerdem kann man im Repository keine Issues eröffnen. Vielleicht liest der Autor hier ja Kommentare dazu, auch wenn das unwahrscheinlich ist.
Um ein Issue zu erstellen, muss man wohl erst die Wartungsgebühr zahlen! War ein Scherz.
Oh, das war wirklich ein ernstes Problem. Inzwischen wurde es dank eines zufälligen Contributors behoben!
Wenn es nach der Rechtsabteilung meiner Firma ginge, würde sie bei einer solchen EULA nicht sagen „Bezahlt das“, sondern „Hört sofort auf, dieses Tool zu verwenden“. Ich denke, die meisten Unternehmen würden ähnlich reagieren. Vielleicht ist das für die Maintainer sogar in Ordnung, aber ich habe immer vertreten, dass man, wenn man Open Source erhalten und zugleich kommerzielle Nutzung einschränken will, lieber die AGPL verwenden sollte. Für Enterprises ist die AGPL fast Gift. Keine Firma, bei der ich gearbeitet habe, hätte AGPL-Code in einem kommerziellen Produkt erlaubt. Danach kann man dann kostenpflichtige kommerzielle Lizenzen verkaufen.
Open-Source-Projekte funktionieren oft wie ein Wohltätigkeits- und Ehrensystem. Mitwirkende gewinnen Ansehen, Unternehmen, die den Code nutzen, verdienen Geld. So profitieren beide Seiten und indirekt auch die Menschheit. Ich persönlich – vielleicht naiv – denke, dass diese Wohltätigkeit noch direkter und klarer der gesamten Menschheit zugutekommen könnte. Zum Beispiel könnte ein Projekt bei Veröffentlichung unter einer öffentlichen Lizenz vorsehen, dass Unternehmen, die damit Umsatz machen, etwa 1 % ihres Umsatzes an einen globalen Fonds spenden: „Decentralized Universal Kindness Income“ (DUKI). Unternehmen, die die Hauptarbeit beitragen, könnten teilweise oder vollständig von dieser Spende befreit werden und dadurch einen gewissen Vorteil behalten, selbst wenn andere Großunternehmen ihre Arbeit im Wettbewerb nutzen – aus ähnlichen Gründen hat Redis ja auch die Lizenz geändert. Beitragende würden weltweit mehr Anerkennung und Prestige erhalten, und spendende Unternehmen könnten Open-Source-Ressourcen nicht nur breit einsetzen, sondern auch reputationsseitig im Marketing davon profitieren. Das könnte wettbewerbsfähiger sein als reine Profitunternehmen. Ich nenne das die „DUKI-Lizenz“. Im Kern ist es die MIT-Lizenz mit einer zusätzlichen Bedingung zur Gewinnbeteiligung. Leider habe ich nicht genug Einfluss, um das zu vermarkten, und es ist unklar, ob zentrale Maintainer und Gründer des Open-Source-Ökosystems so etwas annehmen würden.
Dort steht: „Der Source Code wird frei unter der Lizenz veröffentlicht, aber alle anderen Aktivitäten wie das Erstellen und Kommentieren von Issues, die Teilnahme an Diskussionen und das Herunterladen von Releases erfordern die Einhaltung der Wartungsgebühr.“ Mich hat überrascht, dass sogar das Herunterladen von Releases eingeschlossen ist. Ich bin kein Anwalt, aber für mich scheint das mit der Lizenz selbst zu kollidieren. Konkret mit der Klausel, wonach „jeder Beitragende eine nicht exklusive, weltweite, lizenzgebührenfreie Copyright-Lizenz erhält, um das Werk und abgeleitete Werke zu verbreiten, zu nutzen und zu verändern“. So erzeugt man am Ende nur noch mehr Verwirrung und zwingt praktisch dazu, die Erstellung von Forks zu automatisieren, die Releases einfach spiegeln. Die entsprechenden GitHub Actions liegen im Repo bereits bei.
Die von dir zitierte Lizenzklausel bedeutet nur, dass man das Recht erhält, den betreffenden Code zu kopieren, zu verändern (oder zu kompilieren) und zu verbreiten. Es gibt aber keine Pflicht, auch Binärdateien bereitzustellen. Eigentlich ist so etwas ziemlich üblich. Open-Source-Lizenzen gelten meist nur für den Source Code. Der Hinweis auf „automatisiertes Spiegeln und Forken“ ist nachvollziehbar, aber für Softwareentwickler ist direktes Klonen und Bauen ohnehin leicht und natürlich. Früher war es ganz normal, den Source Code direkt zu kopieren und zu verwenden, und genau deshalb wurde FOSS populär. Das ist weniger ein „Workaround“ als vielmehr das eigentliche Wesen von FOSS.
Dem stimme ich völlig zu. In der Praxis war es aber anders. Die meisten Unternehmen fanden unsere Wartungsgebühr ausreichend vernünftig und zogen offiziellen Support ohne Projekt- oder Fork-Risiko klar vor.
Vielleicht verstehe ich den Hype um diese Sache einfach nicht. Die Lizenz ändert sich nicht, aber ohne Wartungsgebühr bekommt man keinen Support? Wenn jemand eine Schwachstelle meldet, patcht WiX sie dann erst, nachdem der Meldende die Gebühr gezahlt hat? Oder wenn ein Unternehmenskunde eine gute Feature-Idee einbringt, wird sie ignoriert, bis die Gebühr bezahlt wurde? Das klingt alles sehr selbstverständlich. Open-Source-Autoren entscheiden doch ohnehin selbst, welche PRs sie annehmen und für welche Issues sie sich interessieren. Sie konnten schon immer Geld für Support verlangen. Ich frage mich daher, was an einer Wartungsgebühr innovativ sein soll. Das ist nicht als Kritik gemeint. Ein Tool unter einer Open-Source-Lizenz zu bauen, ist großartig, und Spenden anzunehmen ebenso selbstverständlich. Wenn sich Beitragende ausgeschlossen fühlen, können sie jederzeit forken. Das ist kein neues Konzept. Natürlich ist ein Fork eine Entscheidung, die einiges an Geld und Personal kosten kann. Selbst ein Konzern von der Größe Amazons fährt wahrscheinlich effizienter damit, den ursprünglichen Autoren Geld zu geben und so Aufmerksamkeit zu bekommen. Beispiele wie LibreOffice, io.js, OpenTofu und neovim gibt es natürlich. Wenn man es wie LibreCAD richtig aufspaltet, ist auch das eine Leistung. io.js hat nodejs gesünder gemacht, also hatte es seinen Wert. Die Stärke der Community ist einer der großen Vorteile von Open Source. Jeder kann mit Code, Dokumentation, Geld, Ideen usw. beitragen. Danke an WiX, dass sie auf diese Weise an der Community teilnehmen, und ich hoffe, es läuft auch künftig gut.
Der WiX-Installer ist ein komplexes und schwer verständliches Werkzeug. Ich habe ihn nur wegen des Vorteils genutzt, dass er kostenlos war. Wenn er kostenpflichtig wäre, würde ich eher ein kommerzielles Produkt wählen, das einfacher ist und besseren Support hat. Rob Mensching hatte versucht, das über Beratungs- und Supportleistungen für 5.000 Dollar pro Jahr zu monetarisieren, aber anscheinend reicht das nicht aus.
Die Aussage „Der einzige Vorteil war, dass es kostenlos war“ trifft für Leute zu, die einfach nur ohne Geld ein Installationswerkzeug nutzen wollten. Aber der größte Wert von WiX liegt nicht nur darin, kostenlos zu sein. WiX Toolset ermöglicht es, das Potenzial von Windows Installer auf eine Weise auszuschöpfen, wie es kein anderes Installer-Werkzeug kann. Wenn man einfache Anforderungen hatte, war es sicher umständlich und in vieler Hinsicht unzulänglich. Aber bei schwierigen Installationsproblemen waren gerade diese scharfen Funktionen oft unverzichtbar. Zu den „5.000 Dollar pro Jahr Beratungsmonetarisierung“: Ich verdiene nicht einfach 5.000 Dollar im Jahr nur mit WiX an sich. Über das Programm „WiX Developer Direct“ biete ich hochwertige individuelle Dienstleistungen an, die auf dem Installations-Know-how basieren, das mein Team und ich über Jahrzehnte aufgebaut haben, sowie auf fortgeschrittenen Tools von FireGiant. Dazu gehören monatliche Office Hours, garantierte SLAs, jährliche Code Reviews, fortgeschrittene Werkzeuge und weitere High-End-Services, die Kunden sehr schätzen. Es geht also nicht darum, dass das nicht genug wäre; aber nach dem jüngsten Vorfall mit XZ Utils habe ich deutlich gespürt, wie ernst das Nachhaltigkeitsproblem in Open Source wirklich ist. Deshalb wollte ich einen Weg finden, etwas dagegen zu tun, und die Open Source Maintenance Fee scheint für Projekte wie meines eine ziemlich gute Lösung zu sein. WiX Toolset ist derzeit das erste Projekt, das dieses Modell eingeführt hat, und dient damit auch als Experimentierfeld, um durch Versuch und Irrtum zu sehen, wie es in der Praxis funktioniert. Bisher läuft es sehr gut.
WiX ist im Grunde ein Werkzeug, mit dem man die interne Datenbankstruktur des Windows Installers direkt in XML schreiben kann. Das MSI-Format und Windows Installer sind so komplex, dass dieser Ruf entstanden ist; weniger WiX selbst als vielmehr das MSI-Format ist von Hause aus schon ein „kompliziertes Labyrinth“.
Ich dachte, die Lizenz läge bei MS, aber wenn man den vollständigen Lizenztext liest, steht dort: „Für auf GitHub und NuGet.org veröffentlichte Binär-Releases gilt eine EULA, die die Zahlung der Wartungsgebühr verlangt.“ Ich bin auch kein Anwalt, aber wäre es in diesem Fall nicht möglich, die Wartungsgebühr zu umgehen, indem man selbst baut und verteilt? Und könnte man diese Builds dann nicht sogar kostenlos weitergeben?
Der Code gehört nicht Microsoft, sondern der .NET Foundation (die Geschichte dahinter ist lang). Das Umgehen der Wartungsgebühr durch eigenes Bauen ist tatsächlich vollständig erlaubt. Dann bist du jetzt nur selbst für 500.000 Zeilen Code verantwortlich. Viel Spaß mit dem echten Fork!
Laut README des Repos ist der Source Code Open Source, aber die Issue- und Release-Funktionen des Repos erfordern die Zahlung der Wartungsgebühr.