Open Source bedeutet nicht automatisch eine offene Community
(blog.feld.me)- Open-Source-Software konnte schon vor (D)VCS über HTML-Seiten, txt-Dateien, FTP-Tarballs und nur mit einer E-Mail-Kontaktadresse verteilt werden und war auch ohne öffentliche Community Open Source
- Wenn es eine Mailingliste oder einen IRC-Kanal gab, hatte man Glück, aber pull request, Issues, Wiki, Core Team und Code of Conduct waren keine zwingenden Voraussetzungen für Open Source
- Sourceforge stellte CVS/SVN und Mailinglisten fast kostenlos bereit und erleichterte damit öffentliche Entwicklung; später gewann git den DVCS-Wettbewerb, und die Welt konvergierte auf GitHub
- Seit GitHub hat sich die Pflege von Open Source in eine Art unbezahlte Arbeit verwandelt, bei der man auch Issues, Pull Requests außerhalb des Projektumfangs, Beschwerden, Forderungen und die Verwaltung von Chat-Gruppen schultern muss, was zu Burnout und Kontrollverlust führen kann
- Ein Projekt muss nicht zwingend öffentlich entwickelt werden; man kann den Issue-Tracker und Pull Requests deaktivieren oder einen Bare-Git-Server nutzen und Open Source in einer kleinen vertrauenswürdigen Gruppe oder allein betreiben
Wartungslast nach GitHub
- GitHub lässt Open Source für Maintainer wie unbezahlte Arbeit wirken
- Nachdem man im Job Tickets, Stakeholder-Meetings, Roadmaps, Politik, Ablenkungen, Deadlines, Metriken, KPI, geänderte Anforderungen, Standups, One-on-Ones, Agile und Waterfall bewältigt hat, wartet zu Hause ein Stapel Open-Source-Benachrichtigungen
- Issues häufen sich, es kommen Pull Requests herein, die die Software in Richtungen außerhalb des Projektumfangs neu gestalten wollen, und Beschwerden sowie Forderungen nehmen zu
- Entstehen Chat-Gruppen und eine „Community“, tragen Maintainer zusätzlich die Verantwortung, ungeduldige Menschen zu moderieren und sich einzeln mit ihnen auseinanderzusetzen
- Dadurch wird Open Source zu einem zweiten Job, und Maintainer können ausbrennen und sogar die Kontrolle und Richtung ihres eigenen Projekts verlieren
Wieder einfacher arbeiten
- Manche Projekte sind so groß und komplex, dass Team-Management nötig ist, aber das ist die Ausnahme und nicht der Normalfall
- Wenn es einen wütend macht, dass neue Leute und AI-Bots ständig Aufmerksamkeit beanspruchen, kann man zur früheren Arbeitsweise zurückkehren
- Man kann den Issue-Tracker und Pull Requests deaktivieren oder einen Bare-Git-Server nur zur Veröffentlichung des Codes betreiben
- Man kann mit einer kleinen Gruppe arbeiten, die man wirklich kennt und der man vertraut, oder das Projekt vollständig allein vorantreiben
- Es gibt keinen Grund, fremden Menschen das Eindringen in den eigenen Raum zu erlauben, und auch ein demonstrativer Code of Conduct oder LLM-Richtlinien sind nicht zwingend nötig
- Damit etwas „Open Source“ ist, muss es nicht zwingend öffentlich entwickelt werden
- Man kann die Werkzeuge verwenden, die man möchte, bauen, woran man Freude hat, und sogar um 2 Uhr morgens an Weihnachten einen code drop veröffentlichen, ohne sich in ein Betriebssystem hineinziehen zu lassen, das wie eine Mischung aus technischem Inkubator und Kindertagesstätte wirkt
2 Kommentare
Lobste.rs-Meinungen
Wegen genau dieser Denkweise habe ich https://casuallymaintained.tech/ erstellt, und ich mag es sehr.
Das bekannteste Beispiel ist wohl SQLite, das externe Beiträge ablehnt.
Wenn man bedenkt, dass es sogar in missionskritischen Anwendungen wie Airbus-Flugzeugen eingesetzt wird, ist das eine vernünftige Politik.
SQLite ist Open Source, man kann es also beliebig kopieren und ohne Einschränkungen nutzen, aber es ist kein Open-Contribution-Projekt.
Damit SQLite Public Domain bleibt und keine proprietären oder lizenzierten Codeschnipsel hineingeraten, werden keine Patches von Personen angenommen, die keine Erklärung eingereicht haben, dass ihr Beitrag der Public Domain gewidmet wird.
Das ist ein ziemlich erfrischender Blickwinkel.
Vielleicht hat der Autor recht und wir verlangen von Maintainern zu viel.
Vielleicht ist nicht Open Source insgesamt kaputt, sondern die Inflation der Erwartungen daran, was Open Source leisten soll.
Auch die sozialen Elemente von GitHub könnten eine Rolle spielen. Je mehr Stars und normale Nutzer ein Projekt hat, desto größer wird der Druck, neue Besucher des Projekts zufriedenzustellen.
Besonders riskant wird es, wenn das Interesse und die Anforderungen der Community nicht zur ursprünglichen Vision der Ersteller passen.
Verwandter Text: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
Das ist ein solider Ansatz, und ich wünschte, mehr Menschen würden ihn als Standard betrachten.
Eine Community aufzubauen oder irgendeine Verantwortung zu übernehmen, sollte eine bewusste Ausnahmehandlung sein.
Der Teil, in dem Verhaltenskodizes und LLM-Richtlinien als bloße Zierde bezeichnet werden, wirkt etwas abseitig, aber es ist ein sensibles Thema, also kann ich das nachvollziehen.
Aber wenn man so etwas an ein Ein-Personen-Repository heftet, das weder Nutzer noch Community hat und auch keine bekommen soll, dann ist es reine Zierde.
Für ein Repository, das ich allein nutze, brauche ich keinen Verhaltenskodex für mich selbst.
Es wäre wirklich schön, wenn diese Diskussion an Fahrt gewinnt und zu einem tatsächlich tragfähigen Konsens führt.
Es gibt viele Arten, Software zu entwickeln und gesund dazu beizutragen.
Manche davon sind einfach nicht miteinander vereinbar, erfüllen nicht die hohen Maßstäbe von Open Source, tragen die Kosten von Sichtbarkeit und Popularität oder nutzen unterschiedliche Mechanismen wie Lizenzen, Self-Hosting oder das Nichtannehmen von Codebeiträgen.
Ich hoffe, wir finden gemeinsam einen guten Weg, bei Community-Software Spaß und Fairness in den Vordergrund zu stellen.
Der im Text beschriebene Zustand ist der natürliche Zustand praktisch aller persönlichen Open-Source-Projekte, die von nicht prominenten Personen gerade erst gestartet wurden.
Wir alle haben ziemlich viele Projekte, die auf diese Weise betrieben werden.
Das Problem ist, dass Menschen nicht wissen, was sie aus einem Projekt herausholen wollen, oder denken, es wäre cool, ein populäres Projekt zu betreiben, ohne die Kosten wirklich abzuwägen.
So beginnt dann bewusst oder unbewusst das Jagen nach Aufmerksamkeit.
Die Aussage „GitHub hat aus ganz Open Source unbezahlte Arbeit für Maintainer gemacht“ stimmt nur, wenn man es zulässt.
Nimmt man das vage Versprechen von Ruhm heraus, gibt es in den meisten Situationen nicht viel Hebel, mit dem GitHub einen dazu bringen könnte, Dinge zu tun, die man eigentlich gar nicht tun wollte.
Stimmt schon.
Ich hatte einmal ein etwas populäres Projekt und war gestresst, weil Bugreports und Pull Requests für Funktionen hereinkamen, die ich gar nicht wollte, und ich mich darum kümmern musste.
Ich wünschte, ich hätte damals so einen Text lesen können.
Außerdem ist auch https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 lesenswert.
Für kleine Projekte stimme ich diesem Text stark zu.
Auch bei größeren Projekten sind die erfolgreichsten oft nicht als offene Community gestartet.
Viele meiner Lieblingsprojekte wurden zunächst in großen Organisationen entwickelt, und entscheidend war, dass die Software dort intern tatsächlich aktiv genutzt wurde.
Dadurch wurden auch die Maintainer bereits bezahlt.
Ob persönliches Projekt oder internes Team: Software, die entwickelt wurde, um die alltäglichen Probleme der Entwickler selbst zu lösen, wirkt erfolgreicher und weniger ausbeuterisch als Software, die für Ruhm oder Kommerzialisierung gebaut wurde.
Hacker-News-Kommentare
Selbst in den geschlossensten Communities werden Beiträge oft angenommen, wenn man höflich eine E-Mail schreibt
Ein Open-Source-Entwickler war einmal so erschöpft von Belästigungen, dass er Pull Requests für sein Repository und mehrere Funktionen deaktivierte, und in dieser Zeit bekam er auch den Ruf, sehr schwierig zu sein
Ich kannte die Hintergründe nicht und dachte einfach, das Projekt funktioniere grundsätzlich so, suchte mir dann irgendwie seine E-Mail-Adresse heraus und schickte ihm in einer lockeren, höflichen Mail einen inoffiziellen Patch, mit dem klaren Hinweis, dass er ihn nutzen oder ignorieren könne
Der Entwickler antwortete dankbar, erklärte die Situation, entschuldigte sich sogar dafür, dass es unpraktisch war, sagte, er habe keinen anderen Weg gewusst als alles auf diese Weise abzuriegeln, und übernahm die Änderung natürlich auch
Ich dachte, dieser Beitrag würde das weit verbreitete Problem behandeln, dass freie Softwareprojekte Diskussionen oder Bug-Reports auf Discord erzwingen
Für ein oder zwei Wochen schien es Interesse daran zu geben, wieder auf andere Tools umzuziehen, aber das scheint längst verpufft zu sein, und am Ende haben wohl alle aufgegeben und sind zu Discord zurückgekehrt
Discord ist nicht völlig furchtbar, aber flüchtig und setzt eine riesige, aufgeblähte Web-App voraus
Aus Sicht eines grauen Bartes gefällt mir die Haltung des Autors
Ich bin alt genug, um mich noch an die Zeit zu erinnern, als ich vor ARPANET-Veteranen saß und es nur Einsen gab, von denen man ungefähr die Hälfte von Hand zu Nullen schnitzen musste
In der früheren Art der Softwareentwicklung wurden Projekte meist von ein oder zwei Personen geschrieben oder gepflegt, und das gesamte Internet kannte ihre E-Mail-Adressen und schickte Bug-Reports direkt an sie
Einige Projekte wurden in IRC oder Mailinglisten diskutiert, man verhielt sich im Allgemeinen professionell, und wenn nicht, wurde man aus der Mailingliste geworfen oder landete in den Blockdateien von iirc und pine
Entscheidend ist, dass die aktive Entwicklergruppe zu jedem Zeitpunkt sehr klein war
Ich spreche vor allem von kleinen Utilities wie make, Sendmail, sed und awk, und selbst Perl wirkte bis 1990 größtenteils so, als bestünde es nur aus Larry Wall und tchrist
gcc war das verrückte Gegenbeispiel, bei dem Tausende Leute Patches einsandten und man sich auch noch gut mit RMS abstimmen musste, um etwas upstream zu bekommen
Neue Tools unterstützen größere Teams dabei, dauerhaft miteinander zu interagieren, und es hat große Vorteile, wenn kleine Teams sich nicht um irgendeine Person aus dem Internet kümmern müssen, es sei denn, sie setzt praktisch eine Niere darauf und reicht einen Patch ein
Nur hilft so eine Arbeitsweise nicht dabei, Leute für die Arbeit zu gewinnen, daher kann man zwar auf die alte Art arbeiten, aber das Team bleibt dann klein und es könnte schwerer sein, Nutzer anzuziehen
Andererseits gehen mich Nutzer nichts an; ich nutze Software, um meinen Anwendungsfall zu unterstützen, und veröffentliche sie als Open Source, falls sie vielleicht auch für andere nützlich ist
Genauer gesagt verspricht Open Source nur die vier grundlegenden Freiheiten(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Darüber hinaus verspricht es buchstäblich nichts, und dazu gehört auch nicht kostenlos
Freie/Open-Source-Software kann und sollte Geld kosten; bei „free“ geht es hier nicht um Geld
Ich sehe die Open-Source-„Supply-Chain“-Angriffe, die es in letzter Zeit in mehreren Communities gab, sogar ziemlich positiv, weil ich optimistisch hoffe, dass den Leuten dadurch klar wird, dass Open Source keine Supply Chain ist
Mehr dazu hier: https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Wenn du keinen Anbieter bezahlst oder keinen Vertrag mit zugesicherten Terminen hast, dann hast du keine Supply Chain
Fast alle FOSS-Lizenzen enthalten eine Klausel wie „diese Software wird ohne Gewähr bereitgestellt“, und da eine Supply Chain Gewährleistung impliziert, ist FOSS keine Supply Chain
Ich habe es satt, hierherzukommen und zu sehen, wie „Open Source“ so behandelt wird, als hätte es „moralische Werte“, und wie Konzepte, die aus freier Software gestohlen wurden, vermischt werden, als seien beide identisch
Open Source ist nur das, was große Softwarefirmen sich von zahllosen Freiwilligen nehmen
Die Code-of-Conduct-Leute sind nur da, um Ärger zu machen
Schon die Rot-Knopf/Blau-Knopf-Debatten zeigen das; diese aggressive Gehässigkeit ergibt nur Sinn, wenn die Knöpfe tatsächlich existieren oder Menschen es einfach mögen, sich mies zu verhalten
Gutmeinende Unterstützer von Verhaltenskodizes sprechen von Vereinigungsfreiheit und Meinungsfreiheit
Es geht um Fragen wie: Ist es in Ordnung, jemanden zu bannen, wenn eine Plattform die Person nicht mag, oder sollte man das nur über die praktische Mailinglisten-Norm „seid nett zueinander“ handhaben?
Natürlich hängt es davon ab, wer die Entscheidungsgewalt hat, aber das gilt für jedes Projekt
Man kann nicht verlangen, an fremden Projekten teilnehmen zu dürfen, während man Bedingungen stellt, die den Wünschen der Projektleitung widersprechen, und zugleich auf Vereinigungsfreiheit pocht
Meine Vermutung ist, dass der Autor mit „man braucht keinen demonstrativen Code of Conduct“ meinte, dass ein kleines Projekt, das nur mit der Welt geteilt wird und sich die Option offenhalten will, später externe Beiträge anzunehmen, keinen Verhaltenskodex braucht, bevor überhaupt eine reale Situation eingetreten ist
Man muss sich nicht wegen rein hypothetischer Probleme den Kopf zerbrechen
Der Grund für Verhaltenskodizes ist doch, dass die Alternative entweder willkürliche Strafen für willkürliche Verstöße oder vollständige Spam-Anarchie ist
Ich verstehe nicht, wie Leute, die früher Netiquette gepredigt haben, heute so sehr gegen Klarheit und gesunde Communities sein können
Wenn ich es mir recht überlege, könnte das auch die Goomba fallacy sein, und die Leute, die Verhaltenskodizes verachten, sind vielleicht dieselben, die in den 1990ern auf Usenet ständig Flamewars und Spam verbreitet haben
Open Source ist nicht bloß die Wahl einer Lizenz
Es ist eine Neuverpackung von freier Software, damit sie für Unternehmen attraktiver wirkt, und der Kern von Open Source ist die Idee, dass Softwareentwicklung effektiver ist, wenn Unternehmen gemeinsam mit der Öffentlichkeit entwickeln statt hinter verschlossenen Türen
Daher impliziert Open Source eine offene Community
Wenn du Code unter einer permissiven Lizenz einfach in die Öffentlichkeit wirfst, aber keine kollaborative Entwicklung willst, kannst du das natürlich tun, und der Code ist dann Open-Source-Code
Den Code zu öffnen ist gut, und niemand ist zu mehr verpflichtet, aber es ist nicht das, wofür Open Source konzipiert wurde, und ignoriert einen Teil seines Kerns
Menschen sind nicht irrational, wenn sie bei Open-Source-Code annehmen, dass kollaborativ entwickelt wird
Genau das ist das Ziel der Open-Source-Bewegung
Es ist in Ordnung, wenn diese Annahme bei deiner Software nicht zutrifft, aber dann brichst nicht sie eine soziale Norm, sondern du
Ich denke dabei an Stallman, Druckertreiber und daran, dass Nutzer ihre eigene Arbeit besitzen sollen, deshalb klingt so eine feste Aussage über den Zweck von Open Source für mich nicht richtig
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Dort steht nichts über kollaborative Entwicklung
Menschen werden emotional und kümmern sich oft um neue Nutzer oder Nutzer, die die Grundlagen nicht lernen wollen
Am besten ist eine getrennte, aber strenge, pünktlich antwortende, dabei distanzierte Beziehung abseits von Support-Foren
coreboot oder MrChromebox sind gute Beispiele; er antwortet nur, wenn es nötig ist
Zustimmung, und ich würde noch ergänzen, dass man auch keine Marketing-Seite erstellen muss, um Leute zur Nutzung der Software zu überreden
Stattdessen oder zusätzlich kann man auch einfach alle Gründe erklären, warum man diese Software nicht verwenden sollte
Je mehr Nutzer man hat, desto mehr Probleme hat man
FOSS-Anwendungen müssen nicht zwangsläufig öffentlich verteilt werden; das ist nur eine verbreitete soziale Erwartung
FOSS bedeutet auch nicht, dass der Code Personen zur Verfügung gestellt werden muss, die keine Kunden sind, und wer als Kunde gilt, entscheidet der Entwickler
FOSS soll gegen Geld verkauft werden, und man kann sogar Software verkaufen, die ursprünglich kostenlos von jemand anderem war(siehe https://www.gnu.org/philosophy/selling.en.html)
Open Source mit einer unfreien Lizenz ist immer noch Open Source, aber nicht FOSS, und Entwickler müssen sich nicht schämen, sich für eine unfreie Open-Source-Lizenz zu entscheiden, wenn sie mit ihrer Software mehr Geld verdienen oder zusätzliche, für sie vorteilhafte Einschränkungen setzen wollen
Das kann auch copyleft sein
Kurz gesagt: Wir erstellen LICENSE.md und verlassen uns stark darauf, aber niemand ist auf die Idee gekommen, eine SOCIAL.md zu erstellen
Wenn jemand „Open Source“ sagt, nehmen viele an: „Der Autor baut das für Menschen, für die Gesellschaft und für sein Umfeld und interessiert sich für die Entwicklung des Projekts, für neue Features, besonders für die, die ich brauche, und für Verbesserungen zum Nutzen aller Nutzer. Warum sonst sollte er es veröffentlichen?“
Aber das ist nur die häufigste soziale Erwartung an FOSS und bei weitem nicht der einzige Fall
Dass die Unterscheidung zwischen technischem Open Source und sozialem Open Source fehlt, ist ein Hauptgrund für Meinungsverschiedenheiten, Streit und letztlich Burnout durch verfehlte soziale Erwartungen
Früher musste ich das einer wütenden Menge erklären und den Unterschied darlegen, aber neulich sah ich in einem Beitrag von Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ den Vergleich von Open-Source-Code mit einem Geschenk
Meine Erklärung lief letztlich immer auf Folgendes hinaus: „Wenn dir das Geschenk nicht gefällt oder nicht passt, wirf es weg und vergiss es“
Es gibt nur ein paar wenige Lizenzen, die von der OSI anerkannt werden, aber nicht als freie Software gelten
Siehe die lange Liste freier Softwarelizenzen, die nicht GPL-kompatibel sind, unter https://www.gnu.org/licenses/license-list.html
Außerdem ergibt „nicht-FOSS Open Source“ keinen Sinn, weil FOSS wörtlich Free and Open Source Software bedeutet
Heute landet fast alles direkt auf GitHub, zusammen mit ausführbaren Dateien, die jeder benutzen kann, ohne dubiose Websites oder seltsame Build-Pipelines durchlaufen zu müssen
Keine „Community“, keine Politik, kein Verhaltenskodex, keine Pull Requests oder Issues, kein Wiki, kein Kernteam — das klingt wie ein Paradies
Ich habe inzwischen das Gefühl, dass es zu viele Communities gibt, die dem Projekt selbst schaden
Mehr noch: Ich kann mich kein einziges Mal erinnern, dass eine Community einem Open-Source-Projekt in irgendeiner Weise geholfen hätte
Wenn das Ziel darin besteht, Kontrolle auf Kosten von Qualität zu maximieren, ist das in Ordnung
Nur stellt sich dann die Frage, ob FLOSS wirklich das Richtige ist