Het artikel bespreekt de noodzaak voor een nieuwe generatie versiebeheersystemen (VCS). De opkomst van agentic development (AI-agents) zorgt voor een enorme toename in codevolume en complexiteit, waardoor traditionele tools zoals Git — ontworpen in 2005 — tegen hun grenzen aanlopen, vooral bij zeer grote monorepos.
East River Source Control (ERSC) stelt een architectuur voor waarbij de gebruiker nog steeds een Git-client en het Git-protocol gebruikt, maar waarbij de backend is vervangen door een eigen, horizontaal schaalbare Non-Git storage engine. Deze aanpak minimaliseert het risico voor organisaties bij de overstap naar nieuwe technologie.
Daarnaast kijkt ERSC naar de toekomst door ondersteuning te bieden voor alternatieven zoals Jujutsu (jj), waardoor ontwikkelaars stapsgewijs kunnen overstappen op modernere protocollen. De visie van ERSC is modulair: opslag vormt het fundament, maar andere onderdelen van de softwarestack (zoals CI en code review) kunnen flexibel worden geconfigureerd.
Wat komt er na Git?
East River Source Control bestaat nu iets meer dan een jaar, maar we hebben publiekelijk niet veel verteld over waar we aan hebben gewerkt. We kondigen nog niets officieel aan — dat gebeurt binnenkort — maar we wilden graag কিছু van onze visie delen over versiebeheer en de richting waarin dit zich ontwikkelt.
Software maken is nu anders
Het bouwen van software is fundamenteel een collaboratieve taak. Projecten beginnen vaak bescheiden, maar groeien uit tot ongelooflijk grote en complexe systemen. Of het nu gaat om een nieuw klein project of een monorepo met miljarden regels code: de kern is hetzelfde, namelijk broncode. Het veilig en zorgvuldig opslaan van deze code, het beheren van wijzigingen over tijd en het garanderen van de beschikbaarheid voor ontwikkelaars zijn enkele van de meest kritische functies van elke technologieorganisatie.
Vroeger had je wellicht een gedeelde server waar je code op stond. Vervolgens ontwikkelden de academische wereld en de industrie wat we nu kennen als Source Control Management (SCM) en Version Control Systems (VCS). Binnen de VCS-sector zijn er door de jaren heen veel tools verschenen. CVS, SVN en Git hebben de open-source wereld gedomineerd, maar er waren ook anderen: Perforce, ClearCase, Fossil, Mercurial, SCSS, Monotone, BitKeeper en vele anderen. Deze tools werden de standaard manier om code op te slaan en om in teamverband samen te werken aan wijzigingen.
De opkomst van agentic development (ontwikkeling door AI-agents) heeft veel aspecten van softwareontwikkeling veranderd, maar legt vooral een zware druk op het versiebeheersysteem. Teams produceren meer code en doen dit sneller dan ooit tevoren. Dit leidt tot enorme repositories, een toenemend aantal actieve branches en aanzienlijke conflicten bij het samenvoegen (merging) van nieuw werk. Agents werken goed met monorepos, omdat ze gemakkelijker toegang hebben tot meer context, wat de bovengenoemde problemen verder verergert. Bovendien verplaatsen ze ontwikkelomgevingen naar de cloud met geïsoleerde omgevingen, wat betekent dat er zeer korte clone-tijden nodig zijn. Al deze problemen waren voorheen het domein van grote organisaties, maar door AI-agents worden deze "problemen van grote bedrijven" nu voor iedereen relevant.
Wij geloven dat organisaties een VCS-tool van de volgende generatie nodig hebben naarmate hun ambities schalen. Tegelijkertijd zijn ze terecht conservatief bij het adopteren van nieuwe tooling in dit domein. Broncode is een van de kostbaarste bezittingen van een organisatie; verandering brengt risico's met zich mee, naast de voordelen. Wij begrijpen deze zorgen volledig en bouwen daarom een brug van het heden naar de toekomst.
Opslag is het fundament
Er bestaan al veel Git-servers. Wat maakt ons anders?
Op hoog niveau ziet de architectuur van de meeste partijen die Git-repositories hosten er ongeveer zo uit: Git-client → Git-protocol → Git-serving layer → Git-repository opslag
Je Git-client maakt verbinding met hun service via het Git-protocol. Binnen de service worden de repositories op schijf opgeslagen, met een servicelaag die de twee verbindt.
Dit is een versimpeling: in werkelijkheid gaat het om vele servers met een complexe laag aan services voor de repositories. De opslag wordt gerepliceerd en er gebeurt veel op de achtergrond. We focussen hier op de algemene architectuur; verwar de eenvoud van het schema niet met de eenvoud van het systeem.
In diezelfde geest is dit het schema van wat wij doen: Git-client → Git-protocol → Git-bridge → Non-Git storage engine
Het lijkt erg op elkaar en is eveneens versimpeld (bijvoorbeeld is er een GraphQL API-interface die hier niet wordt getoond). Maar het verschil is cruciaal: hoewel je nog steeds verbinding maakt met onze opslag via je reguliere Git-client en het Git-protocol, slaan wij geen Git-repositories op onze servers op. In plaats daarvan maken we gebruik van een eigen, aangepaste storage engine.
Git is niet gebouwd voor de toekomst
Om het simpel te zeggen: wij geloven niet dat Git de toekomst van source control is. Git heeft ontwikkelaars jarenlang goed gediend, maar het is ontworpen vanuit de beperkingen van 2005, niet van 2025, laat staan 2035.
Git is bijvoorbeeld gebouwd voor de Linux-kernel, een open-source project. Open source is ongelooflijk belangrijk voor onze industrie, maar dit betekent dat Git cruciale functies mist die nuttig zijn voor organisaties die hun code niet met iedereen delen. Daarnaast is de Linux-kernel weliswaar geen klein repository (versie 7.2 bevat ongeveer 43 miljoen regels code), maar grote bedrijven in de industrie hadden jaren geleden al monorepos die werden gemeten in miljarden regels code. Op die schaal maken je ontwerpkeuzes echt een verschil.
Tegelijkertijd is het moeilijk om over te stappen op een ander versiebeheersysteem. Git is volledig ingebakken in onze tooling: we spreken niet over SvnOps, maar over GitOps. Zoveel systemen "spreken" Git, wat alternatieven lastig maakt. Toen Git werd gemaakt, startten er verschillende andere projecten in dezelfde periode, zoals Mercurial en Bazaar. Maar door netwerkeffecten is Git door vrijwel iedereen geadopteerd.
Wat is dan de oplossing? Het Git-protocol blijven gebruiken, terwijl de manier waarop de opslaglaag werkt wordt veranderd. Hoewel dit niet alle toekomstige problemen oplost, helpt het wel aanzienlijk. Ons systeem is horizontaal schaalbaar op een manier die systemen die een Git-repository als source of truth gebruiken niet zijn. En omdat dit geen globaal, uniform platform is, heeft het gebruik van andere bedrijven geen invloed op dat van jou; het zijn aparte implementaties. Dit biedt betrouwbaarheid en controle, twee zaken die cruciaal zijn bij infrastructuur.
Ontwikkelen voor adoptie
Hoe zit het met toekomstige mogelijkheden? Wat als je verder moet schalen dan wat het Git-protocol biedt, of functies nodig hebt die Git niet levert? De strategie om het protocol te ondersteunen heeft een voordeel: je kunt meerdere protocollen ondersteunen.
Hier komt Jujutsu (jj) in beeld. Wij zijn bij ERSC grote fans van jj, mede omdat het een voorbeeld is van technologie die stapsgewijs kan worden geadopteerd. Hoewel jj een eigen versiebeheersysteem is, kan het communiceren met verschillende backends. De meeste ontwikkelaars gebruiken jj met de Git-backend om direct met een lokale Git-repository te werken, maar Google heeft ook een backend voor hun Piper-versiebeheersysteem. Dit stelt individuele ontwikkelaars in staat om jj op het werk te gebruiken, zelfs als hun collega's de reguliere Git-client gebruiken: voor de server is het gewoon weer een gebruiker van het Git-protocol.
Wij gaan deze strategie spiegelen, maar dan aan de serverzijde: Git-client → Git-protocol → Git-bridge → Non-Git storage engine jj-client → Native protocol (toekomst) → Native protocol bridge (toekomst) → Non-Git storage engine
Dit creëert een soepel pad naar de toekomst van versiebeheer: je kunt beginnen met het gebruik van regulier Git en genieten van betrouwbaar en schaalbaar source control management. Individuele ontwikkelaars kunnen jj in hun eigen tempo adopteren, en wanneer de organisatie klaar is voor de volgende stap, kan jj een ander protocol gebruiken naar dezelfde onderliggende engine.
Belangrijke opmerking: dit is toekomstig werk en nog niet beschikbaar. Upstream is er momenteel geen "jj native" protocol en we beweren niet dat wij dit momenteel bouwen. Als dit nuttig is als een upstream-functie die de community wil ondersteunen, zullen we hieraan meewerken. Het protocol zal goed gedocumenteerd worden en eventuele client-modificaties om dit te ondersteunen zullen open source zijn. We gaan er niet vanuit dat upstream dit wil gebruiken, enkel omdat wij het bouwen; het Git-protocol voldoet momenteel immers aan de behoeften van de meeste gebruikers. We zetten ons in om goede spelers in het jj-ecosysteem te zijn, ongeacht hoe dat er uiteindelijk uitziet.
Het eerste van vele onderdelen
Een opslagoplossing is slechts een deel van wat een team nodig heeft om samen te werken aan code. Code review, CI, issue tracking, enzovoort. Terwijl traditionele "software forges" alles in één unified pakket aanboden, geloven wij dat we een tijdperk ingaan van meer aanpasbaarheid.
Daarom zijn onze productaanbiedingen meer als bouwstenen dan als één enkele forge. Opslag is het fundament en komt daarom als eerste. Je kunt ervan uitgaan dat we onze opslagoplossing zo maken dat deze samenwerkt met de rest van je softwarestack, niet ertegenin. Hoewel we meerdere producten in de VCS-ruimte zullen aanbieden, kun je prima je eigen software voor de rest van de stack blijven gebruiken. Of je kunt bepaalde onderdelen van onze eigen tools adopteren en andere van jezelf meebrengen.
Hoewel niets hiervan nu al beschikbaar is, zullen we de systemen binnenkort openstellen. In de tussentijd zien we jullie volgende week op JJ Con!
Wat komt er na Git?
East River Source Control bestaat nu iets meer dan een jaar, maar we hebben publiekelijk niet veel verteld over waar we aan hebben gewerkt. We kondigen nog niets officieel aan — dat gebeurt binnenkort — maar we wilden graag কিছু van onze visie delen over versiebeheer en de richting waarin dit zich ontwikkelt.
Software maken is nu anders
Het bouwen van software is fundamenteel een collaboratieve taak. Projecten beginnen vaak bescheiden, maar groeien uit tot ongelooflijk grote en complexe systemen. Of het nu gaat om een nieuw klein project of een monorepo met miljarden regels code: de kern is hetzelfde, namelijk broncode. Het veilig en zorgvuldig opslaan van deze code, het beheren van wijzigingen over tijd en het garanderen van de beschikbaarheid voor ontwikkelaars zijn enkele van de meest kritische functies van elke technologieorganisatie.
Vroeger had je wellicht een gedeelde server waar je code op stond. Vervolgens ontwikkelden de academische wereld en de industrie wat we nu kennen als Source Control Management (SCM) en Version Control Systems (VCS). Binnen de VCS-sector zijn er door de jaren heen veel tools verschenen. CVS, SVN en Git hebben de open-source wereld gedomineerd, maar er waren ook anderen: Perforce, ClearCase, Fossil, Mercurial, SCSS, Monotone, BitKeeper en vele anderen. Deze tools werden de standaard manier om code op te slaan en om in teamverband samen te werken aan wijzigingen.
De opkomst van agentic development (ontwikkeling door AI-agents) heeft veel aspecten van softwareontwikkeling veranderd, maar legt vooral een zware druk op het versiebeheersysteem. Teams produceren meer code en doen dit sneller dan ooit tevoren. Dit leidt tot enorme repositories, een toenemend aantal actieve branches en aanzienlijke conflicten bij het samenvoegen (merging) van nieuw werk. Agents werken goed met monorepos, omdat ze gemakkelijker toegang hebben tot meer context, wat de bovengenoemde problemen verder verergert. Bovendien verplaatsen ze ontwikkelomgevingen naar de cloud met geïsoleerde omgevingen, wat betekent dat er zeer korte clone-tijden nodig zijn. Al deze problemen waren voorheen het domein van grote organisaties, maar door AI-agents worden deze "problemen van grote bedrijven" nu voor iedereen relevant.
Wij geloven dat organisaties een VCS-tool van de volgende generatie nodig hebben naarmate hun ambities schalen. Tegelijkertijd zijn ze terecht conservatief bij het adopteren van nieuwe tooling in dit domein. Broncode is een van de kostbaarste bezittingen van een organisatie; verandering brengt risico's met zich mee, naast de voordelen. Wij begrijpen deze zorgen volledig en bouwen daarom een brug van het heden naar de toekomst.
Opslag is het fundament
Er bestaan al veel Git-servers. Wat maakt ons anders?
Op hoog niveau ziet de architectuur van de meeste partijen die Git-repositories hosten er ongeveer zo uit: Git-client → Git-protocol → Git-serving layer → Git-repository opslag
Je Git-client maakt verbinding met hun service via het Git-protocol. Binnen de service worden de repositories op schijf opgeslagen, met een servicelaag die de twee verbindt.
Dit is een versimpeling: in werkelijkheid gaat het om vele servers met een complexe laag aan services voor de repositories. De opslag wordt gerepliceerd en er gebeurt veel op de achtergrond. We focussen hier op de algemene architectuur; verwar de eenvoud van het schema niet met de eenvoud van het systeem.
In diezelfde geest is dit het schema van wat wij doen: Git-client → Git-protocol → Git-bridge → Non-Git storage engine
Het lijkt erg op elkaar en is eveneens versimpeld (bijvoorbeeld is er een GraphQL API-interface die hier niet wordt getoond). Maar het verschil is cruciaal: hoewel je nog steeds verbinding maakt met onze opslag via je reguliere Git-client en het Git-protocol, slaan wij geen Git-repositories op onze servers op. In plaats daarvan maken we gebruik van een eigen, aangepaste storage engine.
Git is niet gebouwd voor de toekomst
Om het simpel te zeggen: wij geloven niet dat Git de toekomst van source control is. Git heeft ontwikkelaars jarenlang goed gediend, maar het is ontworpen vanuit de beperkingen van 2005, niet van 2025, laat staan 2035.
Git is bijvoorbeeld gebouwd voor de Linux-kernel, een open-source project. Open source is ongelooflijk belangrijk voor onze industrie, maar dit betekent dat Git cruciale functies mist die nuttig zijn voor organisaties die hun code niet met iedereen delen. Daarnaast is de Linux-kernel weliswaar geen klein repository (versie 7.2 bevat ongeveer 43 miljoen regels code), maar grote bedrijven in de industrie hadden jaren geleden al monorepos die werden gemeten in miljarden regels code. Op die schaal maken je ontwerpkeuzes echt een verschil.
Tegelijkertijd is het moeilijk om over te stappen op een ander versiebeheersysteem. Git is volledig ingebakken in onze tooling: we spreken niet over SvnOps, maar over GitOps. Zoveel systemen "spreken" Git, wat alternatieven lastig maakt. Toen Git werd gemaakt, startten er verschillende andere projecten in dezelfde periode, zoals Mercurial en Bazaar. Maar door netwerkeffecten is Git door vrijwel iedereen geadopteerd.
Wat is dan de oplossing? Het Git-protocol blijven gebruiken, terwijl de manier waarop de opslaglaag werkt wordt veranderd. Hoewel dit niet alle toekomstige problemen oplost, helpt het wel aanzienlijk. Ons systeem is horizontaal schaalbaar op een manier die systemen die een Git-repository als source of truth gebruiken niet zijn. En omdat dit geen globaal, uniform platform is, heeft het gebruik van andere bedrijven geen invloed op dat van jou; het zijn aparte implementaties. Dit biedt betrouwbaarheid en controle, twee zaken die cruciaal zijn bij infrastructuur.
Ontwikkelen voor adoptie
Hoe zit het met toekomstige mogelijkheden? Wat als je verder moet schalen dan wat het Git-protocol biedt, of functies nodig hebt die Git niet levert? De strategie om het protocol te ondersteunen heeft een voordeel: je kunt meerdere protocollen ondersteunen.
Hier komt Jujutsu (jj) in beeld. Wij zijn bij ERSC grote fans van jj, mede omdat het een voorbeeld is van technologie die stapsgewijs kan worden geadopteerd. Hoewel jj een eigen versiebeheersysteem is, kan het communiceren met verschillende backends. De meeste ontwikkelaars gebruiken jj met de Git-backend om direct met een lokale Git-repository te werken, maar Google heeft ook een backend voor hun Piper-versiebeheersysteem. Dit stelt individuele ontwikkelaars in staat om jj op het werk te gebruiken, zelfs als hun collega's de reguliere Git-client gebruiken: voor de server is het gewoon weer een gebruiker van het Git-protocol.
Wij gaan deze strategie spiegelen, maar dan aan de serverzijde: Git-client → Git-protocol → Git-bridge → Non-Git storage engine jj-client → Native protocol (toekomst) → Native protocol bridge (toekomst) → Non-Git storage engine
Dit creëert een soepel pad naar de toekomst van versiebeheer: je kunt beginnen met het gebruik van regulier Git en genieten van betrouwbaar en schaalbaar source control management. Individuele ontwikkelaars kunnen jj in hun eigen tempo adopteren, en wanneer de organisatie klaar is voor de volgende stap, kan jj een ander protocol gebruiken naar dezelfde onderliggende engine.
Belangrijke opmerking: dit is toekomstig werk en nog niet beschikbaar. Upstream is er momenteel geen "jj native" protocol en we beweren niet dat wij dit momenteel bouwen. Als dit nuttig is als een upstream-functie die de community wil ondersteunen, zullen we hieraan meewerken. Het protocol zal goed gedocumenteerd worden en eventuele client-modificaties om dit te ondersteunen zullen open source zijn. We gaan er niet vanuit dat upstream dit wil gebruiken, enkel omdat wij het bouwen; het Git-protocol voldoet momenteel immers aan de behoeften van de meeste gebruikers. We zetten ons in om goede spelers in het jj-ecosysteem te zijn, ongeacht hoe dat er uiteindelijk uitziet.
Het eerste van vele onderdelen
Een opslagoplossing is slechts een deel van wat een team nodig heeft om samen te werken aan code. Code review, CI, issue tracking, enzovoort. Terwijl traditionele "software forges" alles in één unified pakket aanboden, geloven wij dat we een tijdperk ingaan van meer aanpasbaarheid.
Daarom zijn onze productaanbiedingen meer als bouwstenen dan als één enkele forge. Opslag is het fundament en komt daarom als eerste. Je kunt ervan uitgaan dat we onze opslagoplossing zo maken dat deze samenwerkt met de rest van je softwarestack, niet ertegenin. Hoewel we meerdere producten in de VCS-ruimte zullen aanbieden, kun je prima je eigen software voor de rest van de stack blijven gebruiken. Of je kunt bepaalde onderdelen van onze eigen tools adopteren en andere van jezelf meebrengen.
Hoewel niets hiervan nu al beschikbaar is, zullen we de systemen binnenkort openstellen. In de tussentijd zien we jullie volgende week op JJ Con!
Groetjes,