Die Open-Source-Welt vor GitHub

 (lucumr.pocoo.org)
3 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bevor GitHub sich als soziale Infrastruktur von Open Source etablierte, verwalteten Entwickler ihre Projekte auf selbst betriebenen Infrastrukturen wie eigenem Trac, Subversion-Repositories und Mailinglisten; selbst das Hinzufügen von Abhängigkeiten war mit erheblicher Reibung und Vorsicht verbunden
  • GitHub machte das Erstellen, Entdecken und Beitragen zu Projekten revolutionär einfach, standardisierte Issue-Tracker, Pull Requests, CI und mehr und übernahm sogar die Funktion eines Archivs für Open Source
  • In Kombination mit Paketökosystemen wie npm kam es zu einer Explosion von Mikro-Abhängigkeiten; GitHub wurde zu einem zentralen Pfeiler des Vertrauenssystems, doch heute wird dieses Vertrauen durch Instabilität, unklare Produktrichtung und AI-Lärm untergraben
  • Auch Ghostty geht weg, und mit Strudel, Tenacity und anderen gibt es eine Bewegung zur Migration nach Codeberg; Dezentralisierung erhöht zwar die Autonomie, birgt aber auch das Risiko, sozialen Kontext wie Issues, Reviews und Sicherheitshinweise zu verlieren
  • In einer Zeit, in der sich Anzeichen mehren, dass GitHub seine Zentralität verliert, werden öffentliche Archive, die Erinnerung bewahren und Abhängigkeit verringern, immer wichtiger. Das nächste Zeitalter von Open Source sollte Erinnerung bewahren, aber Abhängigkeiten reduzieren

Die Open-Source-Landschaft vor GitHub

  • Vor GitHub war die Zahl der verlässlich nutzbaren Projekte begrenzt, und Ruf und Beständigkeit eines Projekts waren direkt mit der Wahl von Abhängigkeiten verknüpft
  • Eine Abhängigkeit war nicht bloß ein Paketname, sondern brachte die Geschichte des Projekts, seine Website, Maintainer, Release-Prozesse und den Community-Kontext mit sich
  • Größere Projekte betrieben oft ihre eigene Infrastruktur, kleinere landeten häufig auf Uni-Servern oder bei SourceForge
  • Es gab Reibung, etwa durch Prüfungen von Lizenzen und Copyright-Headern wie im Debian-Paketierungsprozess, und auch diese Reibung war Teil der Vertrauensbildung

Der Betrieb eigener Infrastruktur und das Paradox verteilter Versionsverwaltung

  • In frühen Open-Source-Projekten war es üblich, dass sie auf Servern liefen, auf denen Trac, Subversion, Tarballs und Dokumentation selbst betrieben wurden
  • Es gab auch Modelle wie bei Pocoo, wo mehrere Projekte sich Serverkosten und den Aufwand für den Betrieb von Subversion, Trac und Mailinglisten teilten
  • Subversion war ein zentralisiertes Repository, daher gehörte Serverbetrieb ganz natürlich dazu; das Zuhause eines Projekts war physisch klar erkennbar, etwa als Hostname, Verzeichnis, Trac-Instanz oder Mailinglisten-Archiv
  • Mercurial und Git waren verteilte Systeme, in denen jeder das komplette Repository, Branches und die Historie besitzen konnte, doch in der Praxis sammelte sich das Zentrum wieder bei GitHub
  • Dass sich verteilte Versionsverwaltung durchsetzte und die Welt danach doch auf einen riesigen zentralen Dienst standardisiert wurde, bleibt eine große Ironie des modernen Open-Source-Ökosystems

Die Veränderungen durch GitHub

  • GitHub machte es leicht, Projekte anzulegen und zu entdecken, und half selbst Menschen ohne Erfahrung mit Entwickler-Mailinglisten dabei, den Beitrags-Workflow zu verstehen
  • Mit Issue-Tracker, Pull Requests, Release-Seiten, Wikis, Organizations, API, Webhooks und später CI veränderte GitHub den Default für öffentliche Zusammenarbeit grundlegend
  • Open-Source-Zusammenarbeit wurde breit als Arbeit mit sichtbarer Historie und sichtbaren Diskussionen etabliert
  • Eine Zeit lang war GitHub eine sehr vernünftige Standardwahl, um Open-Source-Projekte zu hosten
  • Wie die Politik, den Zugang zu GitHub auch in von US-Sanktionen betroffenen Ländern zu erhalten, zeigte, war Zentralisierung mehr als bloß Hosting und erfüllte die Rolle einer zugänglichen gemeinsamen Basis

GitHub als Archiv

  • Eine weniger beachtete Funktion von GitHub war seine Rolle als Archiv; selbst verlassene Projekte blieben auffindbar und wirkten wie ein Index des gemeinsamen Software-Bestands
  • Forks, alte Issues und Diskussionsverläufe blieben erhalten, sodass die Zentralisierung auffindbare Erinnerung schuf
  • Umgekehrt war es vor großen Plattformen üblich, dass Projektdateien und Dienste verschwanden, wenn persönliche Domains ausliefen, VPS-Instanzen beendet wurden oder Entwickler nicht mehr da waren
  • Wie bei frühen Projekten auf PyPI, bei denen nur Metadaten blieben, das eigentliche Paket aber verschwand, kam es vor, dass Repository-Adressen auf veraltete private Server zeigten und ins Leere liefen
  • Viele Projekte aus dieser Zeit wurden schließlich stark von externen Erhaltungsmechanismen wie dem Internet Archive abhängig

npm und die Explosion der Abhängigkeiten

  • Das Micro-Dependency-Problem endete nicht bei der bloßen Zunahme kleiner Pakete; es verschärfte sich dadurch, dass GitHub und npm das Erstellen, Verteilen, Suchen, Installieren und die wahrgenommenen Kosten von Abhängigkeiten nahezu verschwinden ließen
  • Vor GitHub waren Vertrauen und Beständigkeit unverzichtbare Faktoren bei der Wahl von Abhängigkeiten, und weil man der Verfügbarkeit anderer Dienste nicht immer trauen konnte, war auch Vendoring – also das direkte Einchecken fremden Codes ins eigene Repository – verbreitet
  • Vor dem Zeitalter moderner APIs war es zudem mühsam, Skripte zum Einbinden externen Codes zu pflegen; auch diese Reibung sorgte dafür, dass man vor einer neuen Abhängigkeit noch einmal nachdachte
  • In einem npm-artigen Ökosystem kann ein Paketgraph schneller wachsen, als Menschen vernünftig darüber nachdenken können
  • Um auf Probleme mit unklaren Lizenzsituationen zu reagieren, versuchte GitHub sogar eine Überarbeitung der Nutzungsbedingungen
  • Es etablierte sich eine Kultur, in der man selbst bei kleinen Paketen auf GitHub prüfte, ob Repository und Maintainer existieren, welche Issues offen sind, ob es jüngste Änderungen gibt, ob andere Projekte es nutzen und ob Code und Paketbeschreibung zusammenpassen
  • GitHub wurde zu einem der wenigen Systeme, die sogar Trusted Publishing für Registries wie npm übernehmen; schwindendes Vertrauen in GitHub betrifft daher nicht nur Source Hosting, sondern die gesamte Kultur der Software-Lieferkette

GitHub verliert an Stärke, erste Migrationssignale entstehen

  • GitHub verliert zuletzt einen Teil seiner früheren Unvermeidlichkeit durch Instabilität, wiederholte Produktänderungen, Copilot-AI-Lärm und unklare Führung
  • Weil GitHub im Zentrum des agentischen Coding-Trends steht, ist auch der interne Druck gestiegen; zugleich wird die aktuelle Lage als stark von fehlender Führung geprägt beschrieben
  • Lange waren Abwanderungen von GitHub eher symbolische Gesten, doch inzwischen prüfen oder vollziehen auch einflussreiche Projekte öffentlich den Umzug
  • Die Ankündigung von Ghosttys GitHub-Abgang gilt als starkes Signal, auch wenn das Ziel noch nicht eindeutig feststeht
  • Strudel moved to Codeberg
  • Tenacity moved to Codeberg
  • Noch mag das nicht für einen grundlegenden Umschwung reichen, doch es zeichnet sich ein Trend ab, Hosting außerhalb von GitHub wieder häufiger zu sehen
  • Da Git selbst ursprünglich für mehrere Heimaten entworfen wurde, kann es für Open Source gesund sein, einen Zustand zu beenden, in dem ein einziges Unternehmen das Standard-Zuhause für alles ist

Die Kosten einer Rückkehr zur Verteilung

  • Eine Rückkehr zu mehreren Forge-Instanzen, mehreren Servern und vielen kleineren Communities könnte Dezentralisierung und Autonomie stärken und die Abhängigkeit von Führungswechseln bei Microsoft verringern
  • Ein weiterer Vorteil wäre, dass jede Community ihren eigenen Workflow wählen kann
  • Die aktuellen Probleme des Issue-Trackers von Pi zeigen, dass GitHubs Produktentscheidungen nicht gut zur heutigen Realität der Open-Source-Wartung passen
  • GitHub zeigt Züge eines Designs, das stärker auf Engagement als auf die psychische Gesundheit von Maintainern ausgerichtet ist
  • Auf der anderen Seite kann beim Wechsel zu selbstgehosteten Forge-Instanzen, eigenen Mercurial-Servern oder cgit-Servern zwar der Code verteilt werden, doch der soziale Kontext zerstreut sich leicht
  • Issues, Reviews, Architektur- und Design-Diskussionen, Release Notes, Sicherheitsmeldungen und alte Tarballs verschwinden viel leichter, als man denkt
  • Mailinglisten, die diesen Kontext früher trugen, halten mit heutigen Anforderungen nicht mehr Schritt und bieten auch keine gute User Experience
  • Dass Software vergessen wird, kann einen gewissen reinigenden Effekt haben; wenn jedoch das Verlustrisiko steigt, muss auch neu überlegt werden, wie verteilte Versionsverwaltung in der Praxis genutzt werden soll

Was gebraucht wird, ist ein öffentliches Archiv

  • Ob GitHub bleibt oder Projekte anderswohin ziehen: Open Source braucht ein öffentliches, langweiliges, aber stabiles Archiv
  • Benötigt wird keine Plattform, die den Markt für Entwicklerproduktivität gewinnen will, sondern eine Struktur, die verhindert, dass wichtige Software verschwindet
  • Sie sollte auf langfristig tragfähigen Grundlagen wie einem Endowment oder öffentlicher Finanzierung beruhen
  • Source-Archive, Release-Artefakte, Metadaten und der Projektkontext sollten an einem Ort erhalten bleiben, der nicht an Geschäftsmodell oder Laune der Führung eines einzelnen Unternehmens gebunden ist
  • GitHub wurde zum Zentrum der Open-Source-Aktivität und übernahm dabei eher zufällig auch die Rolle des Archivs; wenn diese Zentralität schwindet, kann man nicht davon ausgehen, dass diese Funktion automatisch erhalten bleibt
  • Persönliche Server und guter Wille allein reichten für Erhaltung nie aus, und schon bei Google Code und Bitbucket zeigte sich nach den Plattformschließungen die entstandene Lücke
  • Künftige Systeme sollten Erinnerung bewahren und Abhängigkeit verringern; Projektumzüge, Spiegelung sozialen Kontexts und die Bewahrung von Releases müssen leichter werden, und das Abdriften eines einzelnen Unternehmens darf nicht so leicht zur kulturellen Krise für alle werden
  • Es bleibt die Spannung, weder zu kaputten Tarball-Links und verlassenen Trac-Instanzen zurückkehren zu wollen noch die GitHub-zentrierte Struktur der letzten 20 Jahre als dauerhaften Normalzustand hinzunehmen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare
  • Eine der größten Veränderungen durch GitHub war meiner Meinung nach, dass es menschenzentriert statt projektzentriert war.
    Dass man ein Repository direkt unter dem eigenen Namen anlegen und schnell loslegen konnte, fühlte sich viel befreiender an als der schwerfällige Prozess bei SourceForge, bei dem man erst einen Projektnamen festlegen und reservieren musste und dann ein CVS- oder SVN-Repository, eine Website, Mailinglisten und einen Issue-Tracker bekam.
    Das hat die mentale Hürde von „Das ist nur etwas, das ich mal eben kurz baue“ stark gesenkt.
    GitHub brachte anfangs auch nicht all diese Dinge wie Issue-Tracker, PRs, Release-Seiten, Wiki, Organisationsseiten, API, Webhooks und CI auf einmal mit.
    Früher gab es noch keine Organisationsfunktion, also legte man neue Benutzerkonten an, um eine Organisation nachzuahmen, und schob die Einführung eines separaten Bug-Trackers auf mit dem Gedanken „GitHub wird das in ein paar Monaten schon liefern“, nur um es am Ende als Textdatei im Repository zu verwalten.
  • Ich finde es bis heute schade, dass sich in den meisten Projekten Git gegen Fossil durchgesetzt hat.
    Bei extrem großen Codebasen wie dem Linux-Kernel mag Git Performance-Vorteile haben, aber die meisten Projekte stoßen praktisch nie an die Leistungsgrenzen ihres VCS.
    Bei Fossil ist es wirklich nützlich, dass interne Werkzeuge wie Wiki, Forum und Tickets zusammen mit dem Code in einer Datei versioniert werden.
    Bei Freelance-Arbeit macht Fossil es sehr einfach, den Projektkontext, Details und Absprachen mit dem Kunden wieder zu erfassen.
    Man muss weder die Codebasis zumüllen noch E-Mails und Notiz-Tools an zig Stellen durchsuchen, um den Kontext wiederherzustellen.
    Ich mag auch nicht die Haltung, man könne nichts mehr ändern, nur weil Git kulturell schon so tief verankert ist.
    Der Umstieg auf Fossil ist einfach, und selbst wenn man von Git kommt, ist der Workflow eher noch simpler.
    • Ähnliche Werkzeuge hätte man auch auf Basis des Git-Protokolls und von Git-Repositories bauen können, und tatsächlich gab es Dinge wie verteiltes Code-Review.
      Die meisten wollten so etwas aber nicht, deshalb kam es nie richtig in Fahrt.
      Es gibt auch etliche Fälle, in denen es unpraktisch ist, Issues zusammen mit dem Projekt zu speichern.
      Wenn Kunden viele Screenshots oder Videodateien zur Reproduktion von Bugs schicken, bläht sich das Repository schnell auf, und wenn das dann zusammen mit dem Code gebündelt ist, muss jeder lokal ein riesiges Repository herunterladen, nur um Tickets anzusehen, was sehr lästig wird.
      Am Ende läuft es leicht auf „Lasst uns das nicht benutzen, das ist zu komplex und bläht nur das Repository auf“ hinaus.
      Die meisten Fossil-Funktionen ließen sich vermutlich auch auf einem Git-Backend umsetzen, und Wiki oder Issues könnte man als separate parallele Branch-Schicht ablegen.
    • Timing spielte wohl auch eine Rolle.
      Soweit ich mich erinnere, musste Fossil zu einer Zeit, als Git schon stabil und alltagstauglich war, bei Versionsupdates manchmal noch das gesamte Repository neu erzeugen.
      Git hatte die schlechtere UX, und vielleicht ist das bis heute so, aber es funktionierte eben und wirkte klar produktionsreif.
      Außerdem nutzte es eines der größten Open-Source-Projekte der Welt, und für die Wahrnehmung war dieser Unterschied entscheidend.
    • Genau jetzt wäre meiner Meinung nach ein guter Zeitpunkt, dass jemand fossilhub.com kauft und eine neue Community aufbaut.
    • Ich frage mich schon, warum Git bei großen Repositories schneller ist.
      Allerdings erinnere ich mich, dass dieser Vorteil zumindest eine Zeit lang bei großen Blobs nicht so deutlich war.
  • Ich halte es eher für schlecht, dass GitHub die Rolle eines Archivs übernommen hat.
    Wenn es 99 % der Zeit einen praktischen zentralen Dienst gibt, verkümmert die Fähigkeit der gesamten Gemeinschaft zur langfristigen Bewahrung.
    Wenn etwas nur lebendig bliebe, weil jemand es aktiv seeden müsste, würden die Leute wahrscheinlich eher Kopien von dem festhalten, was ihnen wirklich wichtig ist.
    Dass man so leicht annehmen kann „Ich kann es später einfach wieder auschecken“, ist eher Teil des Problems.
    Es sollte keinen einzelnen Ort geben, an dem etwas heruntergenommen werden kann.
    Wenn ein GitHub-Projekt von einer DMCA-Beschwerde getroffen wird, verschwinden auch die Forks mit.
    Als Nintendo 2024 einen beliebten Switch-Emulator entfernen ließ, waren Bewahrung und Weiterentwicklung nur möglich, indem man Leute fand, die die neuesten Revisionen ausgecheckt hatten und wieder zum Laufen bringen konnten.
    Selbst das war nur möglich, weil es ein so populäres Projekt war: https://news.ycombinator.com/item?id=40254602
    Nebenbei: Die Header-/Footer-Animation dieser Seite mit ihrem Splatoon-Flair ist wirklich großartig.
    Sie stört nicht, trägt zur Atmosphäre bei und macht sofort Platz, wenn man scrollt, sodass ich fast Lust bekomme, das direkt zu klauen.
    • Dadurch entsteht auch so eine Stimmung, als existiere etwas nicht, wenn es nicht auf GitHub ist.
      Es scheint erschreckend viele Entwickler zu geben, die nicht einmal wissen, dass Code auch anderswo gehostet werden kann.
    • Das Archivieren selbst ist einfach, aber Urheberrecht und Gesetze zum geistigen Eigentum stehen im Weg.
      Wenn man die Hürden dafür senken würde, Informationen zugänglich zu machen, würde sich Macht auch weniger stark konzentrieren.
    • Dem stimme ich nicht zu.
      Einer der Gründe, warum GitHub über Jahre hinweg Vertrauen gewonnen hat, ist gerade, dass es diese Archivfunktion bislang nicht direkt monetarisiert hat.
      Wobei man das angesichts neuer Funktionen rund um Copilot künftig vielleicht anders sehen muss.
      Wenn die Alternative darin besteht, dass alles auf mehrere Websites zersplittert, hat man am Ende nur unterschiedliche DMCA-Regeln an verschiedenen Orten.
      Dann frage ich mich, was genau die bessere Alternative sein soll.
  • Wenn ich solche Texte lese, denke ich über die Entwicklung der Projekte nach, an denen ich beteiligt war.
    Der Großteil meiner Open-Source-Arbeit lief auf selbst gehosteter Infrastruktur, ein typisches Beispiel ist Xfce.
    Als ich 2004 dazukam, gab es meines Wissens einen SVN-Server und vielleicht eine Weboberfläche mit neuer SVN-Unterstützung für CVSweb.
    Nachdem ich ins Kernteam gekommen war, habe ich wohl Bugzilla eingerichtet, wobei es auch jemand anderes gewesen sein könnte.
    Als Git zum Standard wurde, habe ich die Migration eines großen SVN-Repositories in mehrere Git-Repositories angeführt und auch eine cgit-Weboberfläche hinzugefügt.
    Bugzilla war damals immer noch im Einsatz.
    Um 2009 oder 2010 bin ich zu einem kleinen Startup gewechselt, hatte dadurch weniger Zeit für OSS und habe das Projekt verlassen; als ich 2022 zurückkam, hatte man inzwischen eine GitLab-Instanz und CI-Runner aufgesetzt und Bugzilla in GitLab-Issues überführt.
    Es gibt immer noch nur eine Handvoll aktiver Leute, und die Infrastrukturverwaltung liegt fast komplett bei einer Person, aber selbst für ein kleines Team ist das gut machbar.
    Dass die Infrastruktur über Sponsoring bereitgestellt wird, ist ein großes Glück, und wahrscheinlich könnte man die nötigen Kosten notfalls auch allein durch wiederkehrende Spenden decken.
    Vor allem ist es großartig, nicht von GitHub/Microsoft abhängig zu sein.
    Wenn mir vor 20 Jahren jemand gesagt hätte, Microsoft würde einmal die größte OSS-Code-Forge der Welt besitzen, hätte ich mich fast übergeben, und selbst heute fühlt es sich noch sehr unangenehm an.
  • Wird oft übersehen, aber auch gemeinsame Logins waren wirklich wichtig.
    Rust führt mit einem Tool namens crater Tests über das gesamte bekannte Rust-Projekt-Ökosystem aus, und wenn man Hunderte von Issues manuell anlegt, um Projekte zu finden, die von Cargo-Interna abhängen, hilft ein reibungsarmer Ablauf enorm.
    Wenn man die Zugangsdaten für die Website bereits hat und leere Templates erlaubt sind, wird das Anlegen von 200 Issues deutlich einfacher.
    Trifft man dagegen auf eine selbst gehostete Instanz, hört man meistens genau dort auf.
  • Ich habe schon vor SourceForge Beiträge auf Planet Source Code veröffentlicht.
  • Ich mochte Trac wirklich sehr.
    Beim Start eines neuen Open-Source-Projekts Trac als ersten Schritt einzurichten, war mit kaum glaubhafter Reibung verbunden, aber ich mochte es trotzdem.
    Django läuft auch heute noch seit über 20 Jahren auf Trac: https://code.djangoproject.com/timeline
    Das habe ich zwar nicht selbst eingerichtet, aber ich habe vielleicht geholfen, eine noch frühere private Trac-Instanz aufzusetzen.
    • Trac war wirklich gut.
      Mein erster Issue-Tracker war allerdings Bugzilla, und das Einrichten war ziemlich schmerzhaft, außerdem ließ es sich nicht gut mit anderen Tools integrieren.
      Trotzdem hatte Zarro Boogs einen ganz eigenen Charme.
    • Trac war in vielerlei Hinsicht der Grund, warum ich deploybare Apps lieber in Python statt in PHP gebaut habe.
      Das Plugin-System war wirklich hervorragend.
    • Ich mochte Bitbucket.
      Es erfüllte seinen Zweck gut, ging für mich nie kaputt, und Mercurial lag mir ohnehin mehr.
      Ich bin zu GitHub gewechselt, weil die Firmen es genutzt haben, aber selbst heute verwende ich GitHub im Grunde nur als trägen Git-Endpunkt und erledige Build/Deployment mit Docker und Shell-Skripten, sodass die Wechselkosten sehr niedrig wären.
      Beruflich denke ich: Wenn ich nicht die Entscheidungshoheit habe, kann ich auch einfach bezahlte Werkzeuge benutzen wie früher zu SVN-Zeiten.
    • Seltsamerweise habe ich Trac damals gehasst, erinnere mich heute aber trotzdem gern daran.
      Ich hatte das Gefühl, dass es zu viel auf einmal sein wollte und in nichts davon wirklich herausragte.
      Heute hat wahrscheinlich GitLab diese Rolle übernommen, und später wird man sich womöglich auch daran wohlwollend erinnern.
  • Ich habe aus Neugier nach Code-Archivdiensten gesucht und ein paar gefunden.
    Es gibt auch ein eigenes Programm von GitHub: https://archiveprogram.github.com/
    Und es gibt Software Heritage, eine von der UNESCO unterstützte Non-Profit-Organisation: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/
    Allerdings scheint es dort vor allem um die Bewahrung von Code und Commit-Historie zu gehen, nicht so sehr um begleitende Metadaten wie Issues, PRs, Diskussionen oder Wikis.
  • Ich glaube, ich war einer der Leute, die Flask fast ganz am Anfang verwendet haben.
    Ich habe Python gelernt, um AppEngine zu nutzen, das damals kostenloses und einfaches modernes Hosting bot, und dadurch war ich genau richtig positioniert, als Flask erschien.
    Ich bewundere Armin schon lange und habe die Domain sofort erkannt, noch bevor ich auf den Link geklickt habe.
    Ich kann auch seiner Aussage zustimmen, dass GitHub damals nicht die Standardwahl war.
    Beeindruckend finde ich außerdem, dass dieser Text eine Reaktion auf einen Mitchell-Artikel von vor wenigen Stunden ist und so schnell ein langer, gut strukturierter und hochwertiger Beitrag entstanden ist.
  • Das erinnert mich an code.google.com.
    Ich kann immer noch kaum glauben, dass Google da einen derart großen Ball fallengelassen hat.
    • Was für eine Nostalgie.
      Ich war in dem Team, bevor der Dienst eingestellt wurde.