Die Chronologie eines Wortbruchs – oder warum GitLab besser ist als GitHub

Vertrauensbruch im Herzen der Open-Source-Welt

2018 war ein Schockmoment für viele Entwickler: Microsoft kaufte GitHub für 7,5 Milliarden US-Dollar (also knapp die Hälfte von ihrem OpenAI-Invest oder weniger als 10% ihres Bilanzgewinns 2024). Die Plattform, bis dahin in der Entwickler-Community DAS Symbol der Offenheit und Neutralität, wurde Teil eines Konzerns, der in den Jahren zuvor nicht gerade als Vorkämpfer für Open Source galt. Um die Skepsis zu zerstreuen, gab es große Versprechen: GitHub bleibe unabhängig. GitHub bleibe offen. GitHub bleibe neutral. Und vor allem: „Die Entwickler stehen im Mittelpunkt.“

Schnitt. Sieben Jahre später. Heute ist GitHub kein unabhängiges Unternehmen mehr, sondern ein Werkzeugkasten für Microsofts KI-Strategien. Die Versprechen? Geschichte. Und die Open-Source-Welt? Steht vor der Frage, ob GitLab nicht längst die bessere – und ehrlichere – Wahl ist.

1. Die gebrochenen Versprechen

Als Satya Nadella und Nat Friedman 2018 die Open-Source-Welt beschwichtigten, schien es fast zu schön, um wahr zu sein:

• Unabhängigkeit: GitHub sollte autonom bleiben, mit eigener Führung und Strategie. Heute ist GitHub vollständig in Microsofts CoreAI-Division integriert. Das CEO-Amt? Lapidar abeschafft.
• Neutralität: „Any cloud, any device.“ GitHub sollte allen Technologien offenstehen. Realität: Die Priorisierung von Microsoft-Produkten (Azure, Copilot, Visual Studio) ist unübersehbar.
• Developer-First: Entwicklerinteressen sollten Vorrang haben. Realität: Die Community hat weder Einfluss noch Mitspracherecht bei zentralen Entscheidungen.

Die Chronologie eines Wortbruchs: Von „offen, neutral, unabhängig“ zu „Teil einer Konzernstrategie“.

2. Wie Microsoft GitHub umgeformt hat

GitHub ist heute mehr eine unerschöpfliche Datenquelle als denn Community-Plattform. Wer entwickelt, produziert den einen wichtigen Rohstoff. Trainingsmaterial für Microsofts KI. Copilot ist das sichtbarste Beispiel: Trainiert auf Open-Source-Code, auch mit Copyleft-Lizenzen wie GPL oder AGPL, ohne Rücksicht auf Lizenzbedingungen oder Urheber.

Weitere Konsequenzen:

1. Kommerzielle Verwertung von Community-Code – Millionen Entwickler liefern unbezahlten Input, Microsoft verkauft das Ergebnis als KI-Dienst.
2. Sicherheitsrisiken – von fehlerhaften GitHub Actions bis zu zentralisierten Angriffspunkten.
3. Proprietärer Lock-In – Workflows, Schnittstellen und Tools werden an Microsoft gebunden. Neutralität? Ein Relikt aus der Zeit vor der schönen neuen Vibe-Coding-Welt.
4. Transparenzdefizite – Entscheidungen über neue Features oder KI-Funktionen fallen top-down, die Community dient nur noch als Datenlieferant.

Kurz: Aus dem „Herzstück der Open Source“ wurde ein strategisch essentielles Konzernwerkzeug.

3. Die Marketing-Offensive rund um Github Copilot – blanker Hohn

Seit 2025 wirkt es fast, als wolle Microsoft den Wortbruch feiern. Eine globale Marketing-Offensive rollt durchs Entwickler-Ökosystem:

• Microsoft Build 2025 stellte GitHub Copilot mit neuen Features wie dem „Coding Agent“ ins Rampenlicht – als autonomen Partner für die Softwareentwicklung.
• Weltweite Bootcamps und Summits drehen sich ausschließlich um Copilot, begleitet von Microsoft Reactor-Events und Partner-Schulungen.
• Regelmäßige Produkt-Updates positionieren Copilot als „unverzichtbares Werkzeug“ direkt in Visual Studio und Azure.
• Microsoft bindet Copilot tief in Azure, Microsoft 365, SAP und Salesforce ein, während das „Model Context Protocol“ als Industriestandard etabliert werden soll.

Das Ganze wirkt wie eine Machtdemonstration: Wir können uns leisten, unser Wort zu brechen – und am Ende wird es euch egal sein.

Eine Praxis die nicht ganz neu ist, wir erinnern uns an das Projekt WinUI, Microsoft XNA oder die kürzliche Entlassung von 9.000! Mitarbeitern im XBox-Entwicklungsbereich trotz anderslautender Zusagen mit dem "gut gemeinten" Rat von Matt Turnbull man möge doch als Betrofferner CoPilot verwenden "...to reduce the emotional and cognitive load that comes with a job loss ... if you're feeling overwhelmed."

Auch für viele Entwickler fühlt sich das wie Hohn an. Statt die Community zu stärken, wird sie instrumentalisiert. Statt Offenheit dominiert Konzernstrategie. Wer Alternativen sucht, merkt schnell: Dezentral organisierte Open-Source-Dienste wie GitLab zeigen, dass es auch anders geht – ohne Abhängigkeit, ohne Marketing-Kanonaden.

4. Die Reaktion der Open-Source-Community

Die Open-Source-Community ist nicht blind. Organisationen wie die SFC (Software Freedom Conservancy) rufen offen zum Boykott auf. Projekte wie KDE, GNOME oder GIMP nutzen GitHub höchstens noch als Spiegel, ihre aktive Entwicklung läuft auf GitLab. Unternehmen betrachten die Situation kritisch, erste Wechsel sind zu beobachten - wie bei Chef Software. Google, SAP, IBM und Meta nutzen zwar aus historischen Gründen Github, evaluieren aber derzeit Alternativen.

Die Botschaft ist klar: Wer Unabhängigkeit, Datenschutz und Mitspracherecht will, geht zu GitLab – oder zu anderen dezentralen Plattformen, die sich nicht einem einzigen Konzern unterordnen.

5. GitLab als bessere Wahl

Warum also GitLab? Ein Blick auf die Unterschiede:

GitLab ist mit Sicherheit keine perfekte Lösung, aber es ist eine echte Alternative. Selbsthosting, dezentrale Strukturen und Anpassungsfähigkeit sind strategische Vorteile, die Microsofts zentralistische Plattform niemals bieten wird.

6. Datenschutz und Kontrolle – ein strategischer Faktor

Die Frage ist nicht nur „Welche Features bietet die Plattform?“ sondern: „Wem gehören die Daten?“

• Bei GitHub: Microsoft.
• Bei GitLab: dem Betreiber der Instanz.

Für Unternehmen bedeutet das: Compliance, Security und Kontrolle bleiben in der eigenen Hand – nicht im Rechenzentrum eines US-Konzerns. Wer Dezentralität und Selbstbestimmung ernst nimmt, kommt an GitLab (oder ähnlichen Open-Source-Diensten) nicht vorbei.

Und hier sind wir bei DEM zentralen Punkt, der digitalen Souveränität. Und diese steht und fällt mit dem EIgentum und der Lokation unserer Daten.

7. Migration – Aufwand, aber lohnend

Natürlich ist der Umstieg nicht trivial. CI/CD-Pipelines müssen angepasst, Workflows überarbeitet werden, interne Reiberein noch und nöcher. GitLab ist auch nicht kostenlos, wenn es um große private Repos geht. Aber: Die Migration bedeutet strategische Freiheit – statt Abhängigkeit.

8. Bonus-Kapitel: Fanboy-Talk

In den letzten Tagen habe ich dies mit Vielen diskutiert, Entwickler, Partner, Resellern, Microsoft-Mitarbeitern und der doch großem Fan-Basis. Und in den letzten beiden Gruppen hört man immer das selbe:

„Selbsthosting und dezentrale Strukturen mögen auf dem Papier schön klingen, sind aber in Wahrheit ein Sicherheits- und Effizienzrisiko. Nur eine zentralisierte Plattform wie GitHub (unterstützt durch Azure) kann Skalierung, Ausfallsicherheit und Compliance auf Enterprise-Niveau garantieren. Alles andere ist Flickwerk.“

Interessant, nicht wahr? Die selbe Argumentation hört man wieder und wieder - fast schon produktneutral und auswendig gelernt. Schauen wir uns dies im Detail an:

• a. Sicherheitsargument – Schein vs. RealitätArgument: „Nur zentralisierte Cloud-Infrastrukturen können Sicherheit und Skaliuerung auf Weltniveau bieten.“Realität: GitHub selbst war mehrfach Einfallstor für Angriffe (z. B. Supply-Chain-Attacken via GitHub Actions). Eine einzige zentrale Plattform ist ein Single Point of Failure. Dezentralität bedeutet Risikostreuung: Wenn eine Instanz kompromittiert ist, betrifft das nicht die gesamte Entwicklerwelt.
• b. Kostenargument – NebelkerzeArgument: „Self-Hosting ist teuer und aufwendig, Azure ist günstiger und einfacher.“Realität: Public Clouds sind auf lange Sicht immer teurer als souverän betriebene Instanzen – gerade für Organisationen mit stabiler Last (Universitäten, Behörden, mittelständische Unternehmen). Hyperdynaische Skalierung klingt zwar toll, wird aber viel seltener benötigt als uns das Marketing glauben machen möchte. Zudem: GitLab CE ist Open Source, man kann eigene Hosting-Partner wählen. Das schafft Marktvielfalt und Datenhaltung beim vertrauenswürdigen Provider um die Ecke statt Monopolpreise und Lokationsintransparenz.
• Compliance-Argument – Umkehrung der FaktenArgument: „Nur GitHub erfüllt regulatorische Anforderungen (ISO, SOC2, FedRAMP etc.).“Realität: Dezentral gehostete GitLab-Instanzen erlauben maßgeschneiderte Compliance. Man kann DSGVO-konform in Deutschland hosten, in der Schweiz, bei einem lokalen Hoster – oder im eigenen Rechenzentrum. Keine Extraterritorialität, kein US CLOUD Act.
• Effizienzargument – HalbwahrheitArgument: „Zentrale Plattformen sind effizienter, weil alles integriert ist.“Realität: GitHub ist modular und erfordert externe Tools. GitLab bietet dagegen eine echte End-to-End-Integration (Versionskontrolle, CI/CD, Security, Compliance, Projektmanagement). Wer GitLab self-hosted, kann genau die Features nutzen, die benötigt werden – ohne Lock-in.
• Risikoargument – UmdeutungArgument: „Selbsthosting ist riskant, weil interne Teams überfordert sind.“Realität: Das eigentliche Risiko liegt in der Abhängigkeit. Wer alles bei Microsoft hostet, liefert seine IP, seine Daten und seine Prozesse einem einzigen Anbieter aus. Dezentralität bedeutet Wahlfreiheit – und die Möglichkeit, jederzeit den Hoster oder die Instanz zu wechseln.

Fazit: GitLab als neues Zentrum der offenen Entwicklung

Microsoft hat versprochen, GitHub unabhängig, neutral und offen zu lassen. Heute ist klar: Diese Versprechen waren nichts wert. Aus der neutralen Entwicklerplattform ist ein strategisches Vehikel geworden, das Daten sammelt, KI trainiert und Lock-In betreibt.

GitLab dagegen bleibt offen, kontrollierbar und community-nah. Es ist die Plattform, die die Werte von Open Source ernst nimmt – nicht als Marketing-Schlagwort, sondern als gelebte Praxis.

Wer digitale Souveränität, digitale Ethik, Datenschutz und Unabhängigkeit ernst meint, kommt an GitLab nicht vorbei. Dezentral, offen, ehrlich. Die Zeit ist reif, sich vom Wortbruch zu verabschieden – und die eigene Entwicklungszukunft selbst in die Hand zu nehmen.

P.S. Und wer mehr Mut mitbringt sollte sich noch mit Gitea, Gogs, SourceHut BitBucket und Phorge anschauen. Interessant ist auch das Projekt Codeberg, eine vereinsbetriebene Plattform deren Basis Forgejo ist - und ein phänomenales Wachstum von Projekten zeigt.

👉 IMHO: GitHub ist das Stockholm-Syndrom der Entwicklerwelt. GitLab ist der Ausweg – und Open Source die Therapie.