GitHub Developer Exodus 2026: moet je echt vertrekken?
Ik was halverwege het beoordelen van een pull-verzoek toen de X-melding binnenkwam. Mitchell Hashimoto – de man die Vagrant, Terraform en Ghostty heeft gebouwd – was bezig zijn terminalproject met 50.000 sterren van GitHub te halen. Hij was sinds februari 2008 GitHub-gebruiker 1299. Hij had de site, naar eigen zeggen, ruim achttien jaar lang vrijwel elke dag geopend.
Ik heb zijn bericht twee keer gelezen. Vervolgens sloot ik de PR die ik aan het beoordelen was, opende een nieuw tabblad en begon "GitHub alternatives 2026" te typen in een zoekbalk waarvan ik nooit had gedacht dat ik die zin zou typen.
Het punt is dat ik Mitchell Hashimoto niet ben. Ik heb geen project met 50.000 sterren. Ik heb geen invloed op meerdere "commerciële en FOSS-providers" die mij willen hosten. Ik ben een werkende ingenieur met misschien veertig actieve repos op mejba.me, Ramlit Limited en een handvol klantprojecten. De berekening of I GitHub moet verlaten is niet dezelfde berekening als de zijne.
Maar de vraag werd deze week zo luid dat ik hem niet kon negeren. Dus ik heb vier dagen besteed aan het doornemen van de cijfers - ik heb GitLab, Codeberg en SourceHut feitelijk getest tegen de workflows die ik dagelijks gebruik - en wat ik ontdekte verraste me. Niet omdat een van hen duidelijk beter is. Dat zijn ze niet. De verrassing is wat de vergelijking onthult over wat GitHub feitelijk is geworden in 2026, en het specifieke soort ontwikkelaar dat nu stappen zou moeten maken versus het specifieke soort dat absoluut moet blijven zitten en zich gewoon moet aanpassen.
Dit is het bericht waarvan ik wou dat iemand het had geschreven voordat ik er een zondag aan verloor.
De week die de veronderstelling "GitHub is voor altijd" doorbrak
Je kent de krantenkoppen al. Laat me de tijdlijn strak stellen, omdat de volgorde belangrijker is dan de individuele incidenten.
23 april 2026. Tussen 16:05 UTC en 20:43 UTC zorgde een regressie in de merge-wachtrij van GitHub stilletjes voor onjuiste merge-commits wanneer een wachtrijgroep meer dan één PR bevatte met behulp van de squash merge-methode. Volgens GitHub's eigen incident report werden 2.092 pull-aanvragen in 230 repositories getroffen. De bug was geen beschikbaarheidsfout: Git-bewerkingen bleven werken, de API bleef gegevens retourneren, de statuspagina bleef grotendeels groen. De bug was dat commit correctness kapot ging. Code waarvan teams dachten dat ze waren samengevoegd, werd teruggedraaid bij daaropvolgende samenvoegingen in dezelfde wachtrij. Het kostte GitHub drie uur en drieëndertig minuten om zelfs maar op te merken, omdat er geen geautomatiseerde monitor keek naar "deed de samenvoeging daadwerkelijk wat de samenvoeging zei dat het deed."
Lees die paragraaf nog eens als dat nodig is. Een versiebeheerplatform stopte kortstondig met het betrouwbaar bijhouden van versies.
27 april 2026. Het Elasticsearch-cluster van GitHub – het subsysteem dat PR-lijstweergaven, probleemzoekopdrachten, projectbordfilters en het grootste deel van de gebruikersinterface waarop u daadwerkelijk klikt aanstuurt – raakte overweldigd. De CTO van GitHub beschreef het publiekelijk als een botnetaanval bovenop het organische verkeer waar het cluster al mee worstelde. Urenlang waren de onderliggende gegevens prima, maar de interface die de gegevens vindt loog tegen ontwikkelaars. Mensen beschuldigden teamgenoten ervan werk te verwijderen dat niet was verwijderd. Teams organiseerden vergaderingen in de veronderstelling dat PR's waarvan ze niet konden zien dat ze niet meer bestonden.
28 april 2026. Er gebeurden drie dingen in dezelfde nieuwscyclus. GitHub publiceerde een openbare verontschuldiging voor de betrouwbaarheid, waardoor het bedrijf een 'Beschikbaarheid eerst'-standpunt kreeg. Wiz Research heeft CVE-2026-3854 onthuld: een CVSS 8.7 kritische RCE waarmee elke geverifieerde gebruiker externe code kan uitvoeren op de backend van GitHub met een enkele git push, door niet-opgeschoonde gegevens in de interne X-Stat-header te injecteren. En Mitchell Hashimoto publiceerde "Ghostty verlaat GitHub."
Drie mislukkingen, drie verschillende lagen van de stapel, één week. Dat zijn de gegevens.
Maar dit is het deel dat niet op de voorpagina van Hacker News paste: De door derden gecontroleerde uptime van GitHub daalde in 2025 tot onder de 90% en daalde verder in april 2026, tot ongeveer 86% voor de maand. AWS S3, voor de context, draait op een ontwerpdoel van "elf negens": 99,999999999%. De openbare statuspagina van GitHub bleef de hele tijd boven de 99% claimen. Die kloof, tussen wat de statuspagina reports en wat ontwikkelaars daadwerkelijk hebben ervaren, is hetgeen dat het vertrouwen sneller aantast dan welke enkele storing dan ook zou kunnen.
Als de meest gerespecteerde solo-ontwikkelaar in de open source-wereld zegt dat een platform 'niet langer een plek is voor serieus werk', moet de rest van ons op zijn minst de wiskunde doen.
Wat ik feitelijk heb getest (en het eerlijke oordeel)
Voordat ik met de vergelijking begin, is dit de regel die ik mezelf heb opgelegd: ik ging geen enkel platform beoordelen vanaf de marketingpagina ervan. Ik zou naar elk een echt project migreren, mijn huidige workflow er een dag mee laten draaien en opschrijven wat er kapot ging.
Het project dat ik koos was een privé Laravel-zijproject met ongeveer 240 commits, GitHub Actions for CI, twee open PR's, drie mijlpalen, twaalf problemen en een CODEOWNERS-bestand. Geen speelgoed. Ook geen monster met 50.000 sterren. Ongeveer de vorm van het werk dat de meeste lezers van deze site daadwerkelijk doen.
Dit is wat er gebeurde.
GitLab: de veilige migratie die niet helemaal veilig is
GitLab is de voor de hand liggende eerste stop. Het is het platform waar elke "GitHub alternatives 2026"-lijst mee leidt, en de reden is simpel: het is de enige concurrent met een vergelijkbaar functieoppervlak. CI/CD, probleemtracering, containerregister, pakketregister, beveiligingsscans, allemaal gebundeld in één product in plaats van samengevoegd met GitHub-acties, pakketten, Dependabot en geavanceerde beveiliging.
Ik heb het Laravel-project gemigreerd naar GitLab.com (de SaaS, niet zelf-gehost) met behulp van hun ingebouwde GitHub-importeur. Totale tijd vanaf het klikken op "importeren" tot het zien van mijn repo met alle PR's, problemen en mijlpalen intact: ongeveer elf minuten. De importeur kwam tegen:
- Volledige Git-geschiedenis (uiteraard)
- Problemen met labels en mijlpalen
- Pull-aanvragen als samenvoegverzoeken
- CI/CD-configuratie (met herschrijvingen -
.github/workflows/*.ymldraait niet op GitLab; je hebt een.gitlab-ci.ymlnodig) - Takbeschermingsregels (handmatig opnieuw toegepast)
- Webhooks (moest opnieuw creëren)
Het herschrijven van het CI was de werkelijke kosten. Mijn GitHub-acties workflow draaide PHPUnit, draaide Pint voor opmaak, voerde een statische analyse uit via Larastan en implementeerde een preview-omgeving op een Hetzner VPS. Het vertalen ervan naar GitLab CI kostte me ongeveer negentig minuten, vooral omdat het services:-blok van GitLab voor het opstarten van een MySQL-container echt mooier is dan dat van GitHub, maar de rules:-syntaxis voor voorwaardelijke taken is uitgebreider. Je hoeft niet te kopiëren en plakken; je moet nadenken.
Wat GitLab op dit moment beter doet dan GitHub, punt uit, is first-party DevOps-integratie. Als je een startup bent die één platform wil voor code, CI, containerregister, pakketregister en beveiligingsscans, en je dat anders zou samenstellen van GitHub plus drie andere leveranciers, dan is GitLab de schonere gok. Het alles-in-één-verhaal is echt.
Het addertje onder het gras – en dit is het addertje onder het gras dat niemand luid genoeg signaleert – is dat GitLab.com zijn eigen aanzienlijke storing had in 2025 en op dezelfde fundamentele schaaldruk draait als GitHub. Migreren van de ene grote SaaS Git-host naar een andere grote SaaS Git-host omdat u zich zorgen maakt over de betrouwbaarheid is, liefdadig, een onvolledige strategie. Je hebt je enige punt van falen veranderd, niet verwijderd.
De versie van GitLab die het betrouwbaarheidsprobleem feitelijk oplost, is zelf-gehoste GitLab – de gratis Community Edition of de betaalde Premium-laag. Dat is een ander gesprek. Dat is een systeembeheerderstaak. Dat is een server die patches, back-ups, een SSL-certificaat, een SMTP-relay en een runbook nodig heeft voor de dag dat deze om 02.00 uur uitvalt. Als u alleen of met een klein team werkt, weegt de operationele belasting doorgaans zwaarder dan de betrouwbaarheidswinst.
GitLab-oordeel: Een echte GitHub-concurrent op het gebied van functies. Een twijfelachtige GitHub-concurrent op het gebied van betrouwbaarheid als u op GitLab.com blijft. Een echt betrouwbaarheidsspel is alleen mogelijk als u zelf host – en zelfhosting is een baan, geen selectievakje.
Codeberg: degene die mij verraste
Codeberg is het platform waarvan ik verwachtte dat het binnen twintig minuten zou verdwijnen. Ik kwam uit de test en nam het serieuzer dan al het andere dat ik evalueerde.
Snelle context: Codeberg is een Duitse non-profitorganisatie die een exemplaar van Forgejo beheert, een door de gemeenschap beheerde soft fork van Gitea. Er zijn geen investeerders, geen advertenties, geen zakelijke roadmap, geen AI-functies die er bovenop zijn geschroefd, geen "agentische workflow"-golf die de last kunstmatig opblaast. Het wordt gefinancierd door donaties. De filosofie is expliciet: wees een veilig thuis voor gratis en open source software. Het wordt gehost in de EU onder een stichting, wat er stilletjes maar enorm toe doet als je blootstelling aan GDPR hebt.
Ik heb het Laravel-project geïmporteerd – nou ja, een publieksvriendelijke afsplitsing ervan. De eigen voorwaarden van Codeberg vragen u om voornamelijk gratis /open-bronwerk te hosten, wat de juiste grens is voor een door donaties gefinancierde non-profitorganisatie. Het importeren duurde ongeveer zeven minuten. De interface is onmiskenbaar "GitHub circa 2018" - en dat bedoel ik als een compliment. PR-weergave, uitgifteweergave, mijlpaalweergave, code zoeken, allemaal direct leesbaar. Geen AI-suggesties. Geen Copilot-upsell. Geen 'verkennen'-feed die is ontworpen om u op de site te houden.
Forgejo's CI-systeem, Forgejo Actions, is API-compatibel met GitHub Actions. Mijn .github/workflows/ci.yml draaide met twee kleine aanpassingen: een hernoemd runnerlabel, en een actie die ik van de GitHub-marktplaats had gehaald, moest worden vervangen door een equivalent gepubliceerd in Codeberg's eigen actieregister. Ongeveer vijfenveertig minuten werk om groen te worden.
Dit is het deel waardoor ik rechtop ging zitten. In de week van 23-28 april, terwijl GitHub het zichtbaar moeilijk had, liet de statuspagina van Codeberg normale werking zien voor elk onderdeel. Dat is geen kraai-claim; het is een structureel voordeel. Codeberg is geen doelwit voor dezelfde botnets op dezelfde schaal, wordt niet gehamerd door dezelfde agentische AI workflow-belasting, probeert zijn infrastructuur niet 30x te schalen om het synthetische verkeer bij te houden. Het platform is klein genoeg om betrouwbaar te blijven op een manier die de reuzen momenteel niet zijn.
De eerlijke limieten: Codeberg is opzettelijk niet bedoeld voor bedrijfseigen closed-source werk. De beschikbare CI-minuten zijn conservatief omdat iemand doneert om ze aan te houden. Er is geen sociale grafiek in LinkedIn-stijl die ontdekking stimuleert. Als de groeistrategie van uw project afhangt van de pagina 'Trending' van GitHub, kunt u dat hier niet repliceren.
Codeberg-oordeel: Als je open source-software levert, vooral in de EU, vooral als individu of als klein team, is dit het meest onderschatte migratiedoel in 2026. Het is geen GitHub-vervanger. Het is iets beters in de specifieke dimensies waar GitHub niet meer goed in is: stil, betrouwbaar, eigendom van de gemeenschap die het bedient.
SourceHut: Degene die is gebouwd voor de ingenieur die u waarschijnlijk niet bent
SourceHut is het meest eigenzinnige platform dat ik heb getest. Drew DeVault bouwde het op een duidelijke stelling: het meeste van wat moderne Git-hosting "krachtig" maakt, is eigenlijk ruis, en een e-mailgestuurde, JavaScript-vrije workflow is sneller voor serieuze softwareontwikkeling dan welk UI-zwaar alternatief dan ook. Prijzen beginnen gratis; betaalde niveaus zijn ongeveer $ 20- $ 50/year, afhankelijk van het gebruik.
Ik zal eerlijk tegen je zijn. Ik importeerde het Laravel-project, liet workflow een dag draaien en gaf het rond uur zes op.
Niet omdat SourceHut slecht is. Omdat SourceHut is gebouwd voor een workflow die ik eigenlijk niet gebruik. Codebeoordeling op SourceHut gebeurt via mailinglijsten en git send-email. Het volgen van bugs gebeurt via een tracker die opzettelijk spartaans is. CI loopt via builds.sr.ht en is echt snel en schoon. Maar de culturele delta – de overstap van een op PR gebaseerde beoordeling naar een beoordeling per e-mail – is enorm. Linux-kernelbeheerders zijn er dol op. De meesten van ons, inclusief ikzelf, hebben een decennium aan spiergeheugen opgebouwd rond het klikken op "Goedkeuren" in een webinterface.
Het platform zelf is onberispelijk ontworpen. Elke pagina wordt binnen een seconde weergegeven. Er is nergens JavaScript. De transparantie van de beheerder over infrastructuurkosten en beslissingen is iets wat niemand anders in deze ruimte kan evenaren. Als u het soort ontwikkelaar bent dat mutt voor e-mail gebruikt en een UI-knop als een persoonlijke belediging beschouwt, dan is SourceHut het platform dat uw esthetiek eindelijk beloont.
SourceHut oordeel: Geen GitHub alternatief voor de meeste teams. Een ander paradigma voor de specifieke subset van ontwikkelaars die echt patch-via-e-mail workflows willen. Respecteer de filosofie, maar wees eerlijk over de vraag of jij daadwerkelijk die ingenieur bent.
De migratiewiskunde die niemand u laat zien
Hier wil ik breken met elke lijst met "top GitHub-alternatieven" die je deze week hebt gelezen.
De meeste van hen stoppen bij de functievergelijking. De functievergelijking is het eenvoudige gedeelte. De functievergelijking geeft niet de werkelijke kosten weer van het verlaten van GitHub, en als je die kosten niet eerlijk berekent, zul je ofwel migreren wanneer dat niet zou moeten, of blijven wanneer dat niet zou moeten.
Hier is de echte wiskunde.
Wat GitHub u feitelijk biedt naast hosting
Wanneer u host op GitHub, betaalt u niet voor de werking van git push. git push werkt op een VPS van $ 5 met een kale repo en een SSH-sleutel. U betaalt – expliciet met abonnementsgeld, impliciet met uw gegevens – voor een onderling verbonden stapel diensten waarvan de meeste geen vervanging hebben op Codeberg, SourceHut of zelfs GitLab.
Ontdekkings- en inkomende bijdragers. De pagina 'Trending', de verkenningsgrafiek, het sociale bewijs van sterren en vorken, de GitHub-native zoekopdracht waarmee een vreemde op uw project terechtkomt: dit zijn enorme bedrijfsmiddelen voor elke open source-onderhouder, en ze migreren niet. Mitchell Hashimoto kan Ghostty van GitHub verplaatsen omdat Ghostty al beroemd is. Een nieuw project dat probeert een publiek op te bouwen, kan dat niet.
CI/CD alomtegenwoordigheid. GitHub Actions is het de facto implementatie-integratiedoel geworden voor elke cloudprovider, elk pakketregister en elke releasetool. AWS publiceert Acties. Cloudflare publiceert Acties. Vercel publiceert Acties. Het is niet onmogelijk om dat integratieoppervlak elders te repliceren, maar het gebeurt zelden kant-en-klaar.
Het markt-ecosysteem. Acties van derden, GitHub-apps, de integratielaag: dit alles bestaat nergens anders met dezelfde dichtheid. Als uw workflow afhankelijk is van vijf marktplaatsacties, betekent migreren het opnieuw opbouwen of vervangen van vijf integraties.
Rekrutering en identiteit. Uw GitHub-profiel is voor veel bedrijven uw cv. Uw bijdragegrafiek is een referentie. Uw gebruikersnaam is een merk. Niets daarvan wordt netjes overgedragen naar een nieuw platform – en het netwerkeffect stroomt maar één kant op.
Het werkblad migratiekosten
Hier is het werkblad dat ik zondagochtend graag had gehad. Voer uw project er doorheen voordat u een beslissing neemt.
1. Repo-migratietijd. Voor een project met minder dan 500 commits en standaardproblemen/PRs: ~30 minuten per repo alleen voor de import. Vermenigvuldig met uw repo-telling.
2. CI-herschrijftijd. GitHub Acties voor GitLab CI: budget 1-3 uur per niet-triviale workflow. GitHub Acties naar Forgejo Acties op Codeberg: budget 30-90 minuten per workflow. GitHub Acties voor SourceHut-builds: budget een halve dag per workflow als je er nog nooit een hebt geschreven.
3. Webhook en nieuwe bedrading. Elke externe service die berichten plaatst op uw repo (Slack, Discord, implementatie hooks, statuscontroles) moet opnieuw worden geconfigureerd. Budget 15 minuten per integratie, meer als het webhookformaat van het nieuwe platform verschilt.
4. Branchebescherming en teammachtigingen. Niets hiervan wordt automatisch gemigreerd. Controleer en maak opnieuw. Budget ~2 uur voor een typische teamopstelling.
5. Documentatie-updates. Elke README-badge, elke wikilink, elk extern document met de tekst "vind ons op GitHub." Dit is het niet-glamoureuze werk dat langer duurt dan je denkt.
6. De bijdragekosten. Als u externe bijdragers heeft, moeten zij ook migreren. Sommigen niet. U verliest in ieder geval het eerste kwartaal na de migratie enige snelheid van bijdragers. Neem dat mee in uw beslissing.
7. De wervings- en zichtbaarheidskosten. Als uw project bijdragers krijgt via ontdekking, maakt het netwerkeffect van GitHub deel uit van uw groeistrategie. Weggaan betekent dat die pijplijn ergens opnieuw moet worden opgebouwd met zwakkere netwerkeffecten.
Voor mijn veertig repo persoonlijke /work-configuratie kwam mijn eerlijke schatting om GitHub volledig te verlaten uit op ongeveer 60 uur gericht technisch werk plus een reeks kleine reparaties van meerdere maanden. Dat is een reëel getal. Een betekenisvol deel van de productiviteit van een kwart, ingeruild voor een onbekende hoeveelheid toekomstige betrouwbaarheid.
Voor een startup met twintig ingenieurs vermenigvuldig je dat met het aantal repos en integraties en je kijkt naar een maandenlang project met reële opportuniteitskosten. Voor een publiek project met 50.000 sterren als Ghostty is het nog groter, behalve dat Hashimoto de macht heeft om met leveranciers en het merk te onderhandelen om ervoor te zorgen dat bijdragers tijdens de transitie aandacht blijven besteden.
Voor de meeste lezers van dit bericht: de migratiekosten zijn groter dan de betrouwbaarheidskosten van het doorstaan van het herstel van GitHub, tenzij een van de drie specifieke voorwaarden waar is.
Wanneer u daadwerkelijk zou moeten migreren (en wanneer niet)
Nadat ik de berekeningen heb uitgevoerd op echte workflows, is hier het raamwerk dat ik persoonlijk gebruik en aanbeveel aan klanten.
Migreer nu als:
Je werk is afhankelijk van de correctheid van de merge-wachtrijen voor monorepos met hoge snelheid. Het incident van 23 april heeft specifiek de commit-correctheid in wachtrijen verbroken. Als uw team tientallen PR's per dag samenvoegt via geautomatiseerde wachtrijen en u zelfs maar een kleine kans op stille terugkeer niet kunt tolereren, is de vertrouwenskloof te groot om te wachten. De samenvoegtreinen van GitLab of een zelfgehost alternatief zijn redelijke risico's.
U voldoet aan GDPR-blootstellings- of EU-gegevenssoevereiniteitsvereisten en u behandelt "GitHub is hier prima voor" als een werkaanname die u niet daadwerkelijk hebt onderzocht. Codeberg of zelf-gehoste Forgejo op EU-infrastructuur verduidelijkt uw compliance-verhaal op een manier waarop GitHub het nu actief ingewikkelder maakt.
U voert GitHub Enterprise Server uit. Dit is het probleem waarbij ik oprecht denk dat u vandaag actie moet ondernemen, en niet volgend kwartaal. CVE-2026-3854 trof naar schatting 88% van de GHES-gevallen op het moment van openbaarmaking. Als u nog niet naar GHES 3.19.3 of hoger heeft geüpgraded, is dit uw eerste stap, ongeacht eventuele migratievragen. De RCE-keten – injecteer een nep-rails_env, stuur de hook-directory om, plant een pre-receive hook, zorg dat de code wordt uitgevoerd als de git-gebruiker – is zo eenvoudig dat exploitatie in het wild een kwestie is van wanneer, niet of.
Blijf (met aanpassingen) als:
Je bent een solo-ontwikkelaar of een klein team dat standaard PR-gebaseerde workflows draait op openbare repos voor zichtbaarheid. De migratiekosten zijn reëel, de ontdekkingskosten zijn hoog, en de meeste recente mislukkingen van GitHub hebben Git zelf niet echt kapot gemaakt. Ze hebben de UI-laag verbroken die jouw werk vindt. De juiste zet is om je te wapenen tegen fouten in de UI-laag (gebruik gh CLI, script je een weg door de web-UI, spiegel kritieke repos elders als koude back-up) in plaats van volledige migratie.
Uw bedrijf is afhankelijk van GitHub-native integraties zoals Copilot, Advanced Security of specifieke marktplaatsacties die u niet gemakkelijk kunt vervangen. Door het integratieverlies eerlijk te beprijzen, wordt 'migreren' vaak omgezet in 'nog niet'.
U voert een project uit waarvan de groei afhangt van de ontdekking van inkomende bijdragers. U gebruikt het netwerkeffect van GitHub, zelfs als u er niet zo over denkt. Onderschat het niet.
Het hybride toneelstuk dat ik eigenlijk doe
Voor mijn eigen werk migreer ik niet. Ik ben aan het spiegelen. Elke repo van mij die er toe doet, heeft nu een geautomatiseerde nachtelijke spiegel voor een privé Codeberg-account. Als GitHub weer een slechte week heeft, heb ik een werkend tweede exemplaar. Als GitHub nooit meer een slechte week heeft, heb ik ongeveer drie uur aan spiegelautomatisering besteed en een back-up buiten het platform gemaakt, wat sowieso een goede gewoonte is.
De opzet bestaat uit ongeveer dertig regels bash plus een cronjob. Codeberg accepteert pushes van elke standaard Git-client, dus de mirror-configuratie is identiek aan die van elke andere afstandsbediening. Ik gebruik git push --mirror volgens een schema, met inloggegevens in een aparte kluis naast mijn GitHub-inloggegevens. Het geheel is het soort redundantie met lage inzet dat je graag had willen creëren voordat je het nodig had. (Als u al hebt geïnvesteerd in een Claude Code workflow voor terminalgestuurde ontwikkeling, is het aansluiten hiervan als een geplande achtergrondtaak een taak van 20 minuten.)
Wat dit zegt over waar de ontwikkelaarsinfrastructuur naartoe gaat
Ik wil afsluiten met het deel dat groter is dan welk individueel platform dan ook.
De CTO van GitHub beschreef de belastingcurve die het platform bereikte als "agentische ontwikkeling workflows" die arriveerde "als een gratis buffet." Die zin is me de hele week bijgebleven. Hij heeft geen ongelijk. Elke Claude Code-agent, elke Codex-run, elke Cursor-achtergrondtaak, elke autonome pipeline die jij en ik in 2026 uitvoeren, treft de API van GitHub meer dan een mens ooit zou doen. Wij zijn, collectief en per ongeluk, de last die het kapot heeft gemaakt.
De architectuur die GitHub in 2024 draaide, was op maat gemaakt voor menselijke ontwikkelaars. De architectuur die het in 2026 nodig heeft, is op maat gemaakt voor agenten en mensen, en de kloof tussen deze twee getallen blijkt grofweg 30x te bedragen. Dat is het schaaldoel waartoe het bedrijf zich nu publiekelijk heeft gecommitteerd. Het is een enorm technisch project. Of het nu binnen twaalf maanden of zesendertig maanden gebeurt, is de feitelijke vraag die bepaalt of de incidenten van april 2026 een overgangspijnpunt waren of het begin van een langere achteruitgang.
Wat ook waar is, is dat dezelfde agentische workflow-golf die de belastingscurve van GitHub verandert, verandert wat ontwikkelaars waarderen in een Git-host. We geven meer om de betrouwbaarheid van API dan om het verbeteren van de gebruikersinterface, meer om programmatische toegang dan om sociale functies, meer om voorspelbare kosten dan om lijsten met zakelijke functies. Codeberg en SourceHut werden, per ongeluk of door ontwerp, voor dat publiek gebouwd jaren voordat het publiek op grote schaal bestond. Hun moment is nu. Als je AI-agents bouwt die continu versiebeheer API's gebruiken, is de host die je kiest een dragende beslissing op een manier die twee jaar geleden nog niet bestond.
Waar ik na deze week het meest zeker van ben: het tijdperk waarin "GitHub" synoniem was voor "waar code leeft" loopt ten einde. Niet omdat GitHub aan het instorten is; Microsoft heeft het kapitaal, de technici en de strategische redenen om dit op te lossen. Maar omdat de veronderstelling van onvermijdelijkheid verdwenen is. We hebben de meest zichtbare solo-ontwikkelaar in open source zien inpakken en vertrekken. We hebben gezien hoe het bedrijf zelf publiekelijk toegaf dat de uptime onder de 86% lag. De standaard is gebarsten, en een gebarsten standaard is een ander soort standaard.
Je hoeft niet weg te gaan. Ik ga niet weg. Maar terug slaapwandelen naar de veronderstelling dat GitHub de enige serieuze optie is voor het hosten van code in 2026, is iets dat niemand van ons meer kan doen. De vraag ligt eindelijk weer op tafel – en dat is, meer dan alle individuele incidenten, wat er deze maand is veranderd.
Dus hier is het huiswerk. Stel ergens in de komende zeven dagen een timer van één uur in. Kies het werkblad van eerder in dit bericht. Voer het uit tegen één project van u dat er echt toe doet. Slechts één. Ontdek wat de werkelijke migratiekosten zouden zijn voor u, op uw code, met uw integraties.
Je zult waarschijnlijk niet bewegen. Maar je zult nooit meer in de positie verkeren dat je deze beslissing onder paniekomstandigheden moet nemen, zoals de helft van de technische managers met wie ik deze week heb gesproken, uiteindelijk deed. Dat is de echte overwinning. Niet de migratie. De duidelijkheid.
Veelgestelde vragen
Is GitHub momenteel offline?
GitHub is algemeen beschikbaar, maar presteert onder de historische betrouwbaarheidsdoelstellingen: monitoring door derden bracht de uptime in april 2026 op ongeveer 86%, ruim onder het verhaal op de statuspagina van het platform. Specifieke incidenten op 23 april (corruptie van de samenvoegwachtrij) en 27 april (onderbreking van zoekacties in Elasticsearch) veroorzaakten verstoringen van meerdere uren. Voor realtime status controleert u monitoren van derden in plaats van de officiële statuspagina.
Is GitLab eigenlijk betrouwbaarder dan GitHub?
Niet categorisch. GitLab.com draait op dezelfde SaaS-schaaldruk als GitHub en kende zijn eigen aanzienlijke storingen in 2025. GitLab is alleen betrouwbaarder dan GitHub als u zelf host, waardoor betrouwbaarheidswinst wordt ingeruild voor de operationele kosten van het runnen van uw eigen server. Voor de meeste teams lost het wisselen van SaaS-provider de onderliggende betrouwbaarheidsvraag niet op.
Wat is Codeberg en is het een echt GitHub alternatief?
Codeberg is een Duitse non-profitorganisatie die Forgejo beheert, een door de gemeenschap beheerd Git-platform. Het is een echt alternatief voor gratis en open source-projecten, vooral als het gaat om de behoeften van de EU op het gebied van datasoevereiniteit. Het is met opzet niet geschikt voor propriëtair closed-sourcewerk. CI is API-compatibel met GitHub-acties, en het platform bleef volledig operationeel tijdens de incidenten van GitHub in april 2026.
Moet ik mijn privé-repos nu meteen migreren van GitHub?
Waarschijnlijk niet tenzij u in een van de volgende drie categorieën valt: monorepos met hoge snelheid, afhankelijk van de correctheid van de samenvoegwachtrij, GDPR/EU soevereiniteitsvereisten, of GitHub Enterprise Server-instanties waarvoor CVE-2026-3854 nog niet is gepatcht. Voor de meeste solo-ontwikkelaars en kleine teams zijn de migratiekosten groter dan de huidige betrouwbaarheidskosten. Een slimmere tussenstap is het spiegelen van kritische repos naar een tweede host als koude back-up.
Wat is CVE-2026-3854 en heeft dit invloed op mij?
CVE-2026-3854 is een CVSS 8.7-kwetsbaarheid voor het uitvoeren van externe code, onthuld door Wiz Research op 28 april 2026, en kan worden misbruikt door elke geverifieerde gebruiker via een enkele git push met vervaardigde push-opties. GitHub.com werd in maart 2026 gepatcht - er was geen actie nodig voor cloudgebruikers. GitHub Enterprise Server-gebruikers moeten upgraden naar GHES 3.19.3 of hoger; naar schatting 88% van de GHES-gevallen was bij openbaarmaking nog steeds kwetsbaar.
Laten we samenwerken
Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (ondernemingsoplossingen): ramlit.com
- ColorPark (ontwerp en branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
