Warum ich GitHub nur noch so viel wie nötig nutze

Seit Jahren habe ich GitHub wirklich geliebt. Es war ein Vorzeigebeispiel für Barrierefreiheit und praktische Nutzung. Außerdem hat es dort SEO-technisch lelativ gut funktioniert, sich durch Qualität und Beständigkeit einen Namen aufzubauen. Das ist auf anderen sozialen Plattformen deutlich schwieriger, wo Quantität und schaumschlägerei regieren. Ernsthaft, meine Open-Source-Projekte sind zehnmal so schnell in die suchmaschinen gelangt wie meine Business-Website.

Der Abstieg kündigt sich an

Es sieht aber derzeit ganz danach aus, als ob GitHub seine besten Tage hinter sich hat.

Schikane

Neuerdings wurden Preismodelle eingeführt, die klassisch wirtschaftlich gesehen überhaupt keinen Sinn ergeben. Bei privaten Repos einen lokalen CI-runner zu nutzen wird kostenpflichtig, Nutzung der Cloud-Runner bleibt kostenlos. Bei den Cloud-Runnern zahlt GitHub doch für die Energie drauf, im Gegensatz zu den lokalen Runnern, für die der Nutzer selbst aufkommt. Das ist eine reine „Weil wir können“-Entscheidung.

Barrierefreiheit degradiert kontinuierlich

Im Vergleich zu GitLab oder Bitbucket war GitHub in diesem Bereich wirklich gut. Es war sicher nicht perfekt, aber an der Spitze. Mit der Übernahme durch Microsoft wurde die Barrierefreiheit sogar deutlich angehoben, ähnlich wie bei YouTube. Aber seit dem Führungswechsel vor ca einem halben Jahr ist ein stetiger Verfall zu beobachten, während der allgemeine KI-Wahnsinn in voller Blüte steht. In diesem Artikel gehe ich genauer auf die Gründe dahinter ein.

• Listen von Repos und Issues lassen den Fokus immer wieder nach oben springen, sodass ein Durchblättern nicht möglich ist.
• Bei der Erstellung eines Repos verhindert eine aufdringliche Live-Region das Vorlesen, weil sie in Sekundenbruchteilen aktualisiert wird. GitHub prüft, ob der Name für das Repo noch frei ist. Dieses Problem ließe sich gut lösen, indem beim Prüfen ein Debounce zwischengeschaltet wäre, also erst wenn der User für 150 ms nicht getippt hat, sollte eine Prüfung durchgeführt werden. Damit wäre allen geholfen.
• Discussions-Kommentare waren von Anfang an unter macOS mit Firefox nicht lesbar, nur mit safari.
• Nach und nach wurden Features wie z.B. Hovercards eingeführt, die eigentlich nicht barrierefrei sind, sich aber in den Nutzereinstellungen abschalten lassen. Das ist besser als nichts, aber ich betrachte es als Notlösung.

Das Beispiel eines Suchfeldes mit Debounce zeigt anschaulich, dass viele Probleme mit der Barrierefreiheit eigentlich ein verborgenes handwerkliches Problem zum Vorschein bringen. Debounce führt zu besserer Usability (weniger Geflacker) und weniger Netzwerkanfragen. Und die Live-Region würde nur reden, wenn man beim Tippen innehält.

Anmerkung: Ich habe in diesem Demonstrationsvideo mit Firefox unter macOS getestet, der zugegebenermaßen ein paar weniger Fehler ausbügelt als Safari.

Meine Konsequenzen

Ich nutze GitHub nur noch so viel wie nötig und so wenig wie möglich.

• Für Projekte, die explizit als Open Source gedacht sind und von anderen „gefunden“ bzw. genutzt werden sollen, werde ich es weiterhin nutzen oder den Code zumindest dort spiegeln.
• Für persönlichere Projekte, aber auch z.B. statische Websites nutze ich es nicht mehr. Der kleine Convenience-Gewinn ist mir die Abhängigkeit inzwischen nicht mehr wert.

Tut mir Leid, aber dort fühle ich mich nicht mehr willkommen.