Rant: Microsoft kauft GitHub, na und?

Microsoft kauft GitHub für 7,5 Milliarden US-Dollar und die Entwicklergemeinde macht sich ins Höschen. Behauptet jedenfalls Tante Heise. Was ist denn passiert? Ein Quasi-Monopolist (GitHub) wurde von einem anderen Quasi-Monopolisten (Micro$oft) aufgekauft. Das ist nichts ungewöhnliches, sondern stinknormaler Kapitalismus. Wer das nicht will, hätte sich von Anfang ein ein selbstgehostetes GitLab oder ein eigenes GitHub Enterprise auf seinem eigenen Server hochziehen müssen.

Aber da die Installation von GitLab ziemlich haarig ist und auf meinem gemieteten Webspace beim Spielzeugprovider sowieso nicht läuft, werde ich bei GitHub bleiben. Das ist genau die gleiche Überlegung, aus der dieses Blog Kritzelheft auch auf Amazons S3 liegt oder ich die Tropfenschachtel nutze: Die Daten gehören trotz alledem mir (sie liegen ja auf meinen Rechnern zu Hause), aber ich habe keine Wartungsprobleme und -verpflichtungen, die ich bei einem eigenen Server hätte. Wer es – wie ich – bequem haben will, muß dafür bezahlen (entweder mit Geld oder mit Daten).

Wo ist denn der GitLab-Service, der es mir erlaubt, meine Daten kostenlos zu versionieren und synchronisieren? Den gibt es nicht? Das wäre aber der einzige Weg gewesen, das Quasi-Monopol von GitHub zu verhindern. Also jammert jetzt nicht rum, wenn Menschen wie ich, denen es keinen Spaß macht, Sysadmin zu spielen und die Zeit damit zu vergeuden, Sicherheits-Updates einzuspielen, trotz Micro$oft bei GitHub bleiben werden.

Das ist wie mit Facebook: Solange Alternativen wie Diaspora oder Mastodon nur etwas für technikverliebte Menschen sind, solange werden und müssen weniger technikaffine Menschen bei den Datenkraken verharren.

---

8 (Email-) Kommentare

---

Ich stimme dir in allen Punkten zu. Nicht jeder Mensch ist gewillt, oder hat die Fähigkeiten um einen Server aufzusetzen und darüber sich zu ärgern ist der falsche Weg. Ich habe das schon in einem anderen Blog erwähnt, dass das Konzept von fancy-technik-shit nur für die passende Zielgruppe funktioniert. Ich bin ausgebildeter Informatiker und mal eben einen Server aufsetzen (wie ich es ja gerade mache) ist nicht. Das ist wirkliche Arbeit, weil man hunderte von Dingen falsch machen kann. Man muss Seiten von Manuals lesen, die mehr als trocken geschrieben sind usw. ich habe kein Problem mit Menschen die bei Github bleiben, ich habe nur für mich persönlich entschieden, dass das nicht mehr meine Hood ist. Das hatte aber auch noch verschiedene andere Gründe.
P.s. Ich hätte kein Interesse (und auch keine Zeit) mir jetzt mein eigenes GitLab aufzusetzen.

– Robert T. (Kommentieren) (#)

---

Seh ich exakt genau so. Nüchtern betrachtet haben Github, Facebook, WhatsApp und all diese anderen Dienste eines erfolgreich getan: Sie haben für Endnutzer, die sich für Infrastruktur nicht wirklich interessieren, die Schwelle extrem heruntergesetzt und Leute an einen Punkt gebracht, an dem sie solche Werkzeuge für ihre eigenen fachlichen Themen einfach so nutzen können. Davon werden die Nutzer nicht mehr weg wollen und keine Lösung akzeptieren, die komplizierter ist - weil sie gelernt haben, daß es eben auch einfach geht. "Wir" (bin selbst Informatiker und eigentlich seit Jahren im FLOSS-Umfeld zu Hause) tun uns in der Mehrzahl leider extrem schwer damit, das zu verstehen und darauf zu reagieren. Ansonsten hätten wir längst in der Breite verstanden, daß die Antwort auf Cloud Computing nicht in einer weiteren dezentral ausgelegten FLOSS-Server-Anwendung zum Selbsthosting besteht, sondern in einem sinnvoll und fair betriebenen Dienst mit Verfügbarkeit, Stabilität und Performance auf Facebook/Github/WhatsApp- Niveau und den Vorteilen, die wir uns technisch und moralisch wünschen - Eigentum an den Daten, Wahrung der Privatsphäre, Sicherheit vor allzu monopolistischen Zugriffen, … .
PS: Wie kommen bei Dir die Mail-Kommentare ins Blog? Manuell?

– Kristian R. (Kommentieren) (#)

---

Ja, manuell (mit ein paar Hilfs-Skripten für die Formatierung), bei der überschaubaren Menge von Kommentaren hier ist das noch zu verkraften. 😎

– Jörg Kantel (Kommentieren) (#)

---

Danke, gut auf den Punkt gebracht!

– Benjamin W. (Kommentieren) (#)

---

Ich stimme mit dem Rest vom Chor hier überein. Natürlich wäre die Schaffung und kontinuierliche Bereitstellung eines solchen „fairen Dienstes“ wünschenswert. Aber hier greifen eben auch marktwirtschaftliche Kräfte. Aus meiner Sicht bin ich bereit diesen „Preis“ für den Github-Dienst – derzeit mental - zu „zahlen“. Bitbucket stellt eine Alternative dar, aber da ich ebenfalls mit dem R/RStudio/RMarkdown ecosystem herumexperimentiere ist die – wiederum – niedrige technische Integrationsschwelle (z.B. bookdown) traumhaft.
Mein Augenmerk als „Ottonormalverbraucher“ und nicht exzessiv „Technologieverliebterselberserveradmin“ liegt auf der content-Erstellung/Erprobung, und nicht im technischen Kleinkram. Solange also das Preis-Leistungsverhältnis (er)tragbar ist, werde ich auch nicht in letzteres investieren (und doch ggfs. verzweifeln und/oder scheitern).

– Rainer K. (Kommentieren) (#)

---

Öffentliche Projekte kannst Du wie bei github.com auch bei gitlab.com verwalten 1. Für private Projekte musst Du wie bei github.com auch bezahlen.

– Paul M. (Kommentieren) (#)

---

Dem Rant kann ich nur bedingt zustimmen. Zunächst einmal ist ja Git als Programm etwas, das sich primär an Programmierer richtete, und damit an ein technikaffines Publikum. Diesem kann man durchaus zumuten, auch selbst einen eigenen Git-Stack zu installieren.
Das machten aber viele nicht, warum? Weil sie Github mehr als eine Art soziales Netzwerk für Programmierer begriffen hatten, darum, es also einfach war, mit einem Zugang in sehr vielen unterschiedlichen Projekten mitarbeiten zu können, wenn man wollte. Und weil fast alle Projekte dort waren, funktionierte das eben auch sehr gut.
Gitlab selber ist bei der Installation von mittlerer Komplexität, und wem das zu viel ist, für den gibt es einfache Docker-Images (https://docs.gitlab.com/omnibus/docker/). Wer mit Docker kein Problem hat, für den ist dies das Mittel der Wahl.
Abgesehen davon gibt es für den "Hausgebrauch" auch schon seit langem deutlich einfachere Git-Stacks (ohne Kommerz dahinter), die man sehr schnell installieren kann. Sie haben dann nicht den Feature-Overkill von Gitlab/Github, funktionieren aber und reichen dafür allemal aus.
Diese sind vor allem:
* Gitblit (http://gitblit.com/), das setzt Java voraus, und
* Gitea (https://gitea.io/en-us/), dies ist in Go geschrieben.
Beide sind sehr schnell und einfach installiert, und dann einsatzbereit.

– Marc S. (Kommentieren) (#)

---

Kein prinzipieller Widerspruch, bis auf einen Punkt: Bei vielen dieser Tools sollte man unterscheiden zwischen Installation und laufendem Betrieb. Setup ist in den meisten Fällen mehr oder weniger straightforward bzw. trivial. Interessant wird es in zwei Situationen: (a) In der Infrastruktur treten irgendwelche Probleme im Zusammenspiel einzelner Komponenten auf, die die offizielle Dokumentation nicht kennt. (b) Die Anwendung erreicht ein größeres Update, bei dem etwa Datenbanken oder dergleichen aktualisiert werden müssen. Das ist dasselbe Problem wie bei manchen Server-Appliances für privaten und semiprivaten Einsatz und auch in kleineren Unternehmen: Die ist einmal aufgesetzt, dann müsste sie eigentlich irgendwann aktualisiert werden, weil sie plötzlich zentrale Wichtigkeit bekommen haben, genügend relevante Daten drin sind, genügend Nutzer darauf arbeiten und keiner die Nerven hat, die Verfügbarkeit des Dienstes oder gar der Daten zu riskieren. Dort halte ich auch die Annahme für gefährlich, daß Programmierer per se auch imstande sind, Infrastruktur störungsfrei zu betreiben. Das ist nicht zwingend gegeben. Und schließlich und endlich: Viele wollen es möglicherweise auch nicht. Wenn ich meine Freizeit damit verbringen möchte, Code in einem interessanten Open Source - Projekt zu schreiben und eine Lösung an den Start zu bringen, dann ist Hosting der Infrastruktur dafür unter Umständen eine nervige Nebenbaustelle, die Zeit und Kraft kostet und mich von dem ablenkt, was ich eigentlich tun möchte. ;)

– Kristian R. (Kommentieren) (#)

---

(Kommentieren)