Open Source bedeutet nicht automatisch eine offene Community

 (blog.feld.me)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • 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

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
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 lehnt externe Beiträge nicht ab. Das steht auch auf der Copyright-Seite ausdrücklich so.
      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.

    • Das heißt nicht, dass jeder Verhaltenskodex oder jede LLM-Richtlinie bloß dekorativ ist.
      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.