'OpenAI vindt dat GitHub er te vaak uit ligt en werkt daarom aan eigen versie'

OpenAI zou een eigen coderepository willen uitbrengen voor klanten. Daarmee zou OpenAI concurreren met GitHub van Microsoft. Dat laatste bedrijf is een van de grootste investeerders in OpenAI.

OpenAI werkt aan een eigen coderepository omdat de werknemers het zat waren dat GitHub de afgelopen maanden regelmatig onbereikbaar was door storingen. Dat schrijft Reuters op basis van een artikel van The Information. Het bedrijf zou zijn GitHub-concurrent beschikbaar willen maken voor klanten, maar de site deelt verder weinig details. De ontwikkeling is naar verluidt nog maar net begonnen, waardoor het vermoedelijk nog maanden duurt voordat het platform klaar is.

Reacties (70)

[2Keys]

https://www.githubstatus.com/

Github heeft zeker wel eens problemen, maar om daar nou een alternatief om te bouwen is wel heel overdreven.

[P1nGu1n]

De betrouwbaarheid is de laatste tijd wel echt dramatisch. Er wordt gespeculeerd dat GitHub om die reden uptime statistieken heeft weggehaald.

Om die reden is dit project gelanceerd om die terug te brengen: https://mrshu.github.io/github-statuses/

Uptime statistieken over de laatste 90 dagen:

• GitHub platform: 91.86% (aggregatie van het onderstaande, oftewel het percentage van de tijd dat alle onderstaande componenten beschikbaar waren en er dus helemaal geen storing was)
• Git Operations: 99.43%
• Webhooks: 99.44%
• API Requests: 99.62%
• Issues: 98.98%
• Pull Requests: 99.07%
• Actions: 97.93%
• Packages: 99.85%
• Pages: 99.42%
• Codespaces:99.18%
• Copilot: 96.30%

Echt schandalig lage cijfers voor een product op deze schaal. Geen enkel component zit boven de 99.9%! Ik kan de ervaring van OpenAI dus alleen maar onderschrijven. De stabiliteit is drastisch omlaag gegaan de afgelopen tijd.

Edit: er is onduidelijkheid over de betekenis van de 91.86% platform uptime. Het zijn niet mijn cijfers (ik het ze alleen overgenomen van de genoemde website). Dit is het percentage dat alle individuele componenten beschikbaar waren, en er dus geen storing was. Omgekeerd, betekend het dus dat 8.14% van de tijd minimaal één component een storing had.

[Reactie gewijzigd door P1nGu1n op 4 maart 2026 14:38]

[Kenhas]

Ik zal wel weer iets ongelooflijk over het hoofd zien. Maar hoe kan 91% de samenvatting zijn van cijfers die bijna allemaal boven de 99% zitten

[P1nGu1n]

Je moet het interpreteren als dat 91% van de tijd alle componenten beschikbaar waren. 9% van de tijd had dus minimaal één component een storing.

Een versimpeld, fictief voorbeeld:

• 1 feb lag onderdeel A eruit
• 2 feb lag onderdeel B eruit
• 2 feb lag ook onderdeel C eruit
• 3 feb lag onderdeel D eruit

Uptime:

• Onderdeel A: 27/28 = 96%
• Onderdeel B: 27/28 = 96%
• Onderdeel C: 27/28 = 96%
• Onderdeel D: 27/28 = 96%
• Platform uptime: 25/28 = 89%
  • 1, 2 en 3 feb waren de hele dag storingen, dus 25 dagen zonder storing
  • 2 feb waren 2 storingen, maar die tellen niet dubbel mee in deze cijfers

@Wim Cossement @TomONeill zie bovenstaande uitleg

[Reactie gewijzigd door P1nGu1n op 4 maart 2026 14:30]

[phex]

Door elk onderdeel zijn eigen uptime te geven lijkt de uptime heel goed, maar als je het als 1 geheel ziet, ziet het er een stuk minder rooskleurig uit.

Er is zeker wat voor te zeggen om elk onderdeel los te tonen, maar uptime over het platform als 1 waarde geeft een beter beeld van of er überhaupt een probleem is.

[fastedje]

Dit is de vereenvoudigde rekensom:

Als er op elk moment een onderdeel down is van github en er zijn bv 10 onderdelen die 99% uptime hebben (dus 1% downtime), dan is de downtime dus 100-(10*1)= 90%

[tw_gotcha]

91% van de tijd doen alle componenten het tegelijk, 9% valt er een of meer uit. Maar aangezien niemand al die componenten tegelijk gebruikt is het een beetje flauwekul

[Wim Cossement]

Misschien ben ik niet zo slim maar als de laagste waarde van een set waar je het gemiddelde van berekend lager is dan die waarde, vind ik het maar bizar. Of wat bedoelt men anders met aggregatie in dit geval, zonder er gewicht aan te geven?

Het gemiddelde van die 10 waarden is 98,9...

[ikt]

Als je auto elke dag een andere lekke band heeft en daarna elke dag één cylinder die niet werkt, ga je niet zeggen dat je auto het consistent 87,5% doet. Dan zeg je gewoon dat het rotding elke dag stuk is.

Gaat om het product. Als jouw project de hele integratiereutemeteut van GitHub gebruikt, en de ene dag issues niet werken, de andere dag je pages offline is, dan weer je CI pijp kapot is, dan is het product gewoon slecht, en beoordeel je GitHub niet per onderdeel.

[Reactie gewijzigd door ikt op 4 maart 2026 14:57]

[sjaakwortel]

Maar je weegt een kapotte radio of raam wat niet lekker open gaat niet net zo zwaar als een lekke band, mijn auto heeft al jaren allemaal kleine issues, maar ik zou niet zeggen dat die 0% van de tijd werkt.

[tw_gotcha]

Nee, want offline is niet stuk. Als ik 20 sec moet wachten op een repository omdat iets even hapert dat boeit toch helemaal niet? Wat is 2%? 1728sec op de 86400 in een dag, als dat verspreid is merk je er niks van, als dat achter elkaar is merk je het wel

[amigob2]

Maar 91% van de tijd werkt alles 100%, En dat is een hele lage score

[Gropah]

Hoe groter en complexer je IT landschap word, hoe moeilijk het word om alles draaiende te houden. Daar kun je bijna geen capaciteit tegenaan gooien. Bijna iedere IT'er die bij een groot bedrijf heeft gewerkt kan je dit vertellen. Dit is 1 van die problemen die heel hard schaalt wanneer je groeit.

[closefuture]

Even los van de 91% score van het platform als geheel, is het wel dramatisch dat ze op hun core diensten, zoals GIT, ook een dramatisch scoren: "Git Operations: 99.43%". Dat is minder dan 99.5%. Dat betekent dat GIT ansich (i.e. je "git clone" e.d.) er iedere maand bijna 4 uur uit ligt. "Pull requests" nog lager, met 99,07%.

Dus zelfs al zou je enkel de core services pakken die je gewoon nodig hebt om te kunnen werken met Github zoals GIT, pull requests, etc. ga je nog steeds waarschijnlijk op een dramatisch iets zoals 98% uitkomen. 98% betekent dat je iedere maand meer dan 14 en een half uur eruit ligt.

[Mellow Jack]

2 dagen in het jaar offline kan natuurlijk ook

[tw_gotcha]

Nee dus, want niemand gebruikt alle services precies tegelijkertijd. Dat kan niet eens en je bent ook niet 100% van de tijd in github. Dus de kans dat je als gebruiker iets ervaart van een storing is veel lager dan 10% en dat weet je alleen maar door van gebruikers de statistiek te verzamelen. Als ik een repository push en het lukt pas even later boeit me dat werkelijk niks. Het is ook maar de vraag of ze het beter gaan doen.

[Reactie gewijzigd door tw_gotcha op 4 maart 2026 16:40]

[Schafio]

Vergelijk een auto: Als je in 1 week eerst 1u een lekke band had, toen deed je startmotor het 1u niet en toen was de accu 1 u leeg, kon je die week in totaal 3 uur niet rijden. Je kunt bij downtime dus niet zonder meer middelen.

[Hans1990]

Ik denk vergelijkbaar met een bitwise OR voor elk tijdslot nemen. Als er ergens 1 storing is, dan geldt er op dat tijdstip storing, ongeacht of het copilot of pull requests. Dan blijft er 91.86% over. Maar is er op 1 tijdslot meerdere storingen, dan tellen ze niet dubbel.

Zodoende heb je wel de "piek" waarde van het aantal storingen over meerdere groepen, zonder zaken dubbel af te straffen (anders zou je in theorie uptimes onder de 0% kunnen krijgen). Als je dit wel doet kom je op een uptime uit van maar 89.22% (dat er "maar" 2% extra af gaat wilt zeggen dat er weinig overlap is).

Nu zal in die statistiek dus notabene Copilot (een AI tool) flink aantikken, want die staat veruit onderaan. Echter zou je Copilot en Actions (wat geen AI is) weglaten dan stijgt de uptime al (met de pessismistische berekening) naar 95%. Nog niet heel erg geweldig, maar al de helft beter.

[Reactie gewijzigd door Hans1990 op 4 maart 2026 16:42]

[TomONeill]

Ik weet niet in welke utopie jij leeft, maar 99,9% uptime is meer een droom dan realiteit over het algemeen.

Waar haal je dat percentage van 91,86 ook vandaan? Het gemiddelde van de percentages die jij noemt is 98,922%. Dat is veel realistischer.

Het gaat hier ook om losse diensten waarvan men over het algemeen niet alles tegelijkertijd gebruikt en dus ook niet zo ervaart.

Ik weet ook niet of de percentages die jij noemt over alle nodes gaan in alle regio's, want dat is ook nog van belang.

[amigob2]

Maar 91% van de tijd werkt Alles, En dat is een hele lage score

[Technerd]

Nu ben ik niet tech savy genoeg om het te doorgronden maar, de tweede mayor outage zegt "Incident with Copilot Grok Code Fast 1" en "Copilot Code Review is degraded, and not returning responses to users" en zo zijn meerdere mayors of partials gerelateerd aan een AI dienst. Mogelijk zijn het de scrapers waar Github niet tegen kan?

[tszcheetah]

Een uptime van 99% voor alles behalve Copilot betekent ongeveer 21 uur downtime over 90 dagen tijd. Vervelend, maar ook niet verschrikkelijk of schandalig, lijkt me.

Ook staan er veel storingen tussen waar lang niet iedereen last van zal te hebben (bijvoorbeeld 11 december: "We are investigating a rise in request failures on several services"). Dat als "downtime" rekenen is niet helemaal fair: waarschijnlijk hebben de meeste gebruikers na een keer opnieuw proberen alweer nergens last van.

Daarnaast zal ook bij OpenAI niet al het werk ineens stilliggen als Github een storing heeft. Code kan gewoon geschreven worden, commits kunnen gewoon (offline) gemaakt worden, enzovoorts. Storingen raken ook niet per se functionaliteiten die iedereen gebruikt. Neem dan ook nog mee dat storingen niet per se onder werktijd van het OpenAI personeel vallen, en de overlast is nog minder dan geschetst wordt.

Is het dat echt waard om een alternatief met alle nodige functionaliteit uit de grond te gaan stampen? En halen ze zelf dan echt betere uptime? Dit lijkt me niet de echte reden van OpenAI om dit te gaan doen.

[GertMenkel]

Vanuit het oogpunt van een AI-scrape-bot zal Github er vaker uitliggen dan vanuit het oogpunt van een normaal persoon. Iedere website met nuttige informatie moet zich wapenen tegen een leger van AI-scrapers die zich voordoen als normale consumenten (en ook via botnets vanuit consumenten-IP's scrapen), en Github zal daar geen uitzondering op zijn.

Het zou OpenAI een hoop moeite schelen als ze niet om de anti-DDoS-bescherming van Github heen hoeven te werken en mensen hun code gewoon direct naar ze uploaden om in het LLM-model gestopt te worden.

[depeje]

Het verschil tussen een AI scrape en een ddos aanval is soms moeilijk te zien tegenwoordig.

[Pep7777]

Ja dus is het misschien wel OpenAI zelf dat de downtime veroorzaakt.

[Carino]

Ze noemen de bereikbaarheid van GitHub als reden, maar ik heb een zeer sterk vermoeden dat het ze eigenlijk gewoon gaat om toegang tot broncode van hun klanten om de AI modellen op te kunnen trainen.

Je kan er natuurlijk vergif op innemen dat bij de gratis variant je verplicht moet toestaan dat je code gebruikt wordt voor training.

[CrazyBernie]

Ik ook als ik dit lees is dat een veel belangrijker reden dat ze GitHub niet meer kunnen geruilken om te trainen.

[Harmsen]

Vibecoden ipv bouwen

[comatoast]

https://status.openai.com/

Gaan ze hier ook een alternatief voor bouwen?

[arjankoole]

Ja, 404.html

[Frikandel]

Ik ben het wel met openai eens dat Github erg vaak storingen heeft. Als je ze allemaal op een rijtje zet is het bijna elke dag wel raak: https://www.githubstatus.com/history

Ook als Github gebruiker loop je zo nu en dan wel eens tegen een storing aan.

[Luchtbakker]

https://www.githubstatus.com/

Github heeft zeker wel eens problemen, maar om daar nou een alternatief om te bouwen is wel heel overdreven.

Vind ik niet. Ik ben voor github nog redelijk nieuw, maar de laatste 6 maanden waarbij ik bijna dagelijks github nodig ben, heb ik zeker een keer of 20 diverse api storingen gehad. Dus dit nieuws verbaast mij ook weinig.

[cyble]

Ik vermoed eerder dat het te maken heeft dat codex (die moet connecten met github) issues heeft met de manier van communiceren met github. Github is daar niet op gebouwd. En dan is het minder complex om een git server op te zetten die voldoet aan hun verwachtingen dan codex om te gooien en met de beperkingen te blijven zitten. En de aanpassingen kunnen ze dan weer terug pushen naar microsoft wanneer ze klaar zijn, die het weer kan integreren. Ik denk dat dit het echte verhaal is.

[SgtElPotato]

Het zou Tweakers sieren om niet alleen een standaard nieuwsbericht de deur uit te gooien maar ook alternatieven uit de EU te posten. Met alles wat er nu speelt zit niemand te wachten op een GitHub alternatief uit de US, al helemaal niet van OpenAI lijkt me.

[Noxious]

De grootste in de EU is denk ik Codeberg. Gebaseerd op het open-source Forgejo.

[skimine]

Je kant natuurlijk ook zelf zoeken

Maar goed, een paar Europese alternatieven zijn hier te vinden: https://european-alternatives.eu/alternative-to/github

[SgtElPotato]

Uiteraard, het was gewoon een sneer naar Tweakers...

[skimine]

Daarvoor kan je beter een topic openen in Geachte redactie

[Scribe]

Nou dat gaat een stabiel platform worden aangezien we weten dat OpenAI tegenwoordig al hun code met AI schrijft

[wiseger]

Stabiliteit is niet zo van belang. Toegang tot source code is erg belangrijk omdat je daar je code generatoren op kan trainen. Code generatie tools zijn momenteel een van de successen in AI land waarmee wel geld verdiend wordt.

[Kenhas]

Ik dacht dat, door de samenwerking tussen OpenAI en Microsoft, er sowieso wordt getraind op alle github repo's. Als het gaat over code generatie, is github natuurlijk wel een goudmijn

[Marve79]

Misschien krijgt deze wel IPv6.

[iqcgubon]

Een eigen platform voor alle vibe coded projecten die na 2 weken verlaten worden? Sure, kom maar op. Makkelijker om te ontlopen dan.

[Scribe]

Dat is eigenlijk een positievere kijk ja, ze stelen toch alle data die daar op staat dus beter maar dat ze vibecoded projecten aantrekken. Krijgen ze alleen maar vergiftigde trainingsdata

[Anonymousy]

sinds github gemigreerd is van eigen datacenter naar azure hebben ze inderdaad vaak problemen..

[ZeRoC00L]

Is dat al voltooid dan ?

Ik dacht dat het tot 2 jaar kon duren, pas recentelijk gestart, dus wellicht komen de vele downtime momenten nu wel juist door de migratie.

[michelr]

Die Altman liegt wel vaker de boel bij elkaar, dus dit kan in diezelfde reeks worden opgenomen. Benieuwd welke voorwaarden gesteld kunnen worden aan code die je bij OpenAI parkeert - "all your code belong to us". Groetjes, het vriendje van ome Don.

[Wim Cossement]

All your code are belong to us!

[bdevriendt]

Volgens de missing status page haalt geen enkele GIthub service triple 9 SLA. Geeft wel impact voor EMU klanten zoals mijn werkgever

[DrPoncho]

edit:
This represents the sum of downtime across all services, not the total time when any service was down (which would be less due to overlapping incidents).

Dit is nogal relevant he, als 't platform down is ben je de downtimes aan het optellen.

[Snippo]

En zonder het aantal services te weten heb je dus inderdaad helemaal niets aan dat getal.

[djmuggs]

In de standaard voorwaarden zal vast staan dat OpenAI toegang krijgt tot alle code binnen het platform, OpenAI kennende die het niet zo nauw neemt alle privacy wetten.

[bzzzt]

Dat heeft toch niks met privacy te maken? Github projecten zijn standaard ook open voor iedereen.

[The Zep Man]

Dat heeft toch niks met privacy te maken?

Klopt.

Github projecten zijn standaard ook open voor iedereen.

Maar de licentievoorwaarden van code op GitHub hoeft training door AI niet toe te staan. Maar ja, wie houdt grootschalige auteursrechten- en licentieschendingen door grote bedrijven tegen?

[Reactie gewijzigd door The Zep Man op 4 maart 2026 14:21]

[Loller1]

Ik ben zeker dat veel open source projecten ernaar uit kijken om te migreren naar een OpenAI platform voor hun code. /s

[Neverwinterx]

Nou zeg, het is bijna alsof als je iets bewust op de cloud zet ipv onprem, dat je dan afhankelijk bent van de uptime van die cloud service. Wie had dat kunnen denken.