Geoffrey Huntley betoogt dat het traditionele 'bazaar-model' van open-source ontwikkeling, zoals gehanteerd door GitHub, niet langer houdbaar is. De komst van AI heeft geleid tot een vloedgolf aan gegenereerde code in pull requests, wat de druk op maintainers onhoudbaar maakt.
Als oplossing stelt hij het Remix-model voor. De kernpunten hiervan zijn:
- Gedecentraliseerde structuur: Ideeën verspreiden zich via onafhankelijke overlays in plaats van één centrale repository.
- Gebruik van Nix: Dankzij Nix-overlays kunnen gebruikers wijzigingen in gedrag of architectuur eenvoudig implementeren en hergebruiken in hun eigen omgevingen zonder een fork te maken.
- Ideeën boven patches: De focus ligt op de functionele wijziging. De auteur publiceert de code 'as-is' en bepaalt zelf of een succesvolle remix uiteindelijk wordt geïntegreerd in de hoofdversie.
- Nieuw sociaal contract: Het remixen van software creëert geen automatische onderhoudsplicht voor de oorspronkelijke maker.
Door pull requests uit te schakelen en remixing te stimuleren, hoopt Huntley de cognitieve last voor ontwikkelaars te verlagen, wat uiteindelijk zou leiden tot meer gepubliceerde software.
Een nieuw model voor open source: gesloten voor pull requests, open voor remixing
Ik ga een geschiedenisles geven, want er zijn inmiddels een paar generaties software engineers voorbijgegaan sinds dat essay, en ik moet ervan uitgaan dat niet iedereen weet wat een 'kathedraal' is. Iedereen kent de 'bazaar' wel, omdat ze die dagelijks gebruiken via GitHub.
GitHub nam de ideeën van de bazaar — een gedecentraliseerd, open en zelfsturend open-source project — en bood een workflow waarmee iedereen de broncode kan inspecteren of eraan kan bijdragen via een pull request.
Ik ben van mening dat er een nieuw model voor softwareontwikkeling nodig is. We gaan niet terug naar de kathedraal, waarbij een kleine, private en exclusieve groep de broncode bouwt met releases die zwaar gepland, infrequent en gepolijst zijn.
Maar het is duidelijk dat we nu, nu AI er is, iets anders nodig hebben. Het bazaar-model van GitHub vertoonde zelfs vóór de komst van AI al scheuren, omdat het consumentgerichte aanspraken creëerde waarbij iedereen maintainers lastigviel om iets te mergen. Het creëerde vreemde verwachtingen in de sociale structuur: het idee dat iemand die code publiceert, de verplichting heeft om deze te onderhouden zonder daarvoor betaald te krijgen.
Nu AI er is, is de vlam echt in de pan geslagen.
Want wat is het nut van het lezen van een pull request die door code is gegenereerd? Ik wil alleen het kernidee lezen en begrijpen. Als het een goed idee is, incorporeer ik het wellicht terug in de hoofdversie (upstream), maar er zou geen verwachting mogen zijn dat ik dat doe.
Open source-software is per definitie open source omdat de licentie stelt dat het "as is" is, en dat "as is" toestaat dat je software remixt.
Het probleem is geweest dat het remixen van software als te moeilijk werd beschouwd, maar dat is niet het geval. Het was simpelweg een kwestie van een kennisgat, dat nu niet meer bestaat dankzij de komst van AI-agents. Nix bestaat al lange tijd. (Wie mijn artikel over Nix-overlays van een paar dagen geleden nog niet heeft gezien, zou dat moeten lezen: de wereld heeft nog niet door dat je letterlijk alles kunt oplossen met een Nix-overlay).
Er zijn veel onzekerheden in onze industrie op dit moment, maar één ding ben ik me al bijna 13 jaar zeker van: Nix is een verschrikkelijke programmeertaal. Ik herinner me dat het voelde alsof ik stront tegen de heuvel op moest duwen toen ik het leerde. De leercurve is een absolute afgrond.
Daarom stel ik iets voor waarvan ik hoop dat het andere open-source maintainers helpt. Dit is hoe ik nu denk over de software die ik onder open-source licenties publiceer.
Het Remix-model
Structuur: Gedecentraliseerd en compositioneel. Ideeën verspreiden zich via onafhankelijke overlays in plaats van te convergeren naar één enkel repository en één enkele maintainer.
Workflow: Publiceer broncode en intentie onder een 'as-is' licentie. Anderen remixen dit door een kleine Nix-overlay te schrijven die de gewenste wijziging één keer definieert. Deze derivatie wordt vervolgens hergebruikt in devenv shells, Docker-images, NixOS-systemen en tests, CI en agent-sandboxes — zonder dat er een fork nodig is of dat er een afwijkend artefact onderhouden hoeft te worden.
Kernprincipe: Ideeën boven patches. De waardevolle eenheid is een wijziging in gedrag of architectuur. Maintainers beslissen zelf of ze dit incorporeren, opnieuw implementeren of negeren. De oorspronkelijke auteur heeft geen blijvende verplichting om de wijziging te beoordelen, te integreren of te onderhouden.
Sociaal contract: De licentie staat remixen al toe. Het remixen creëert geen claim op de toekomstige tijd van anderen. Erkenning en zichtbaarheid kunnen blijven bestaan, maar er is geen voortdurende onderhoudsplicht. Incorporatie in de hoofdversie blijft optioneel en weloverwogen.
Ontdekking: Nuttige adaptaties verschijnen als een proliferatie van overlays in het wild. Maintainers kunnen uit die verspreiding putten als ze dat willen; iedereen anders kan ideeën simpelweg oppakken en samenvoegen door hun eigen overlays via een agent bij te werken.
Voorbeeld: Een gebruiker van een project wil de mogelijkheid van Git om een force push uit te voeren in dat specifieke project uitschakelen. In plaats van een pull request in te dienen bij het hoofdproject, maakt de gebruiker een overlay die Git патched om force pushes te weigeren. Dit wordt één keer gedefinieerd en verschijnt vervolgens consistent in ontwikkelaarsomgevingen, container-images en systeemtests — zonder een pull request tegen het hoofdproject.
In de praktijk zal ik vanaf nu voor elke code die ik op GitHub publiceer, pull requests uitschakelen, discussies openhouden en richtlijnen publiceren en onderhouden over hoe je mijn software kunt remixen.
Oneindig aanpasbare software die gemakkelijk te consumeren is: dat is wat ik hoop dat een standaardpraktijk wordt. Als je de cognitieve last van het uitbrengen van open source en het beheren van een groot project wegneemt, zullen we meer mensen zien die software publiceren. En als ze dat op de juiste manier doen, zullen we veel meer software in de wereld zien.
De netwerkgrafiek van GitHub biedt een fantastische manier om de remixes in het ecosysteem te verkennen. Je kunt zelfs agents erop loslaten om samen te vatten wat mensen doen. Je kunt het ook gebruiken in een agent-loop om remix-ideeën te verkennen en deze vervolgens terug te voeden naar het hoofdproject.
Een nieuw model voor open source: gesloten voor pull requests, open voor remixing
Ik ga een geschiedenisles geven, want er zijn inmiddels een paar generaties software engineers voorbijgegaan sinds dat essay, en ik moet ervan uitgaan dat niet iedereen weet wat een 'kathedraal' is. Iedereen kent de 'bazaar' wel, omdat ze die dagelijks gebruiken via GitHub.
GitHub nam de ideeën van de bazaar — een gedecentraliseerd, open en zelfsturend open-source project — en bood een workflow waarmee iedereen de broncode kan inspecteren of eraan kan bijdragen via een pull request.
Ik ben van mening dat er een nieuw model voor softwareontwikkeling nodig is. We gaan niet terug naar de kathedraal, waarbij een kleine, private en exclusieve groep de broncode bouwt met releases die zwaar gepland, infrequent en gepolijst zijn.
Maar het is duidelijk dat we nu, nu AI er is, iets anders nodig hebben. Het bazaar-model van GitHub vertoonde zelfs vóór de komst van AI al scheuren, omdat het consumentgerichte aanspraken creëerde waarbij iedereen maintainers lastigviel om iets te mergen. Het creëerde vreemde verwachtingen in de sociale structuur: het idee dat iemand die code publiceert, de verplichting heeft om deze te onderhouden zonder daarvoor betaald te krijgen.
Nu AI er is, is de vlam echt in de pan geslagen.
Want wat is het nut van het lezen van een pull request die door code is gegenereerd? Ik wil alleen het kernidee lezen en begrijpen. Als het een goed idee is, incorporeer ik het wellicht terug in de hoofdversie (upstream), maar er zou geen verwachting mogen zijn dat ik dat doe.
Open source-software is per definitie open source omdat de licentie stelt dat het "as is" is, en dat "as is" toestaat dat je software remixt.
Het probleem is geweest dat het remixen van software als te moeilijk werd beschouwd, maar dat is niet het geval. Het was simpelweg een kwestie van een kennisgat, dat nu niet meer bestaat dankzij de komst van AI-agents. Nix bestaat al lange tijd. (Wie mijn artikel over Nix-overlays van een paar dagen geleden nog niet heeft gezien, zou dat moeten lezen: de wereld heeft nog niet door dat je letterlijk alles kunt oplossen met een Nix-overlay).
Er zijn veel onzekerheden in onze industrie op dit moment, maar één ding ben ik me al bijna 13 jaar zeker van: Nix is een verschrikkelijke programmeertaal. Ik herinner me dat het voelde alsof ik stront tegen de heuvel op moest duwen toen ik het leerde. De leercurve is een absolute afgrond.
Daarom stel ik iets voor waarvan ik hoop dat het andere open-source maintainers helpt. Dit is hoe ik nu denk over de software die ik onder open-source licenties publiceer.
Het Remix-model
Structuur: Gedecentraliseerd en compositioneel. Ideeën verspreiden zich via onafhankelijke overlays in plaats van te convergeren naar één enkel repository en één enkele maintainer.
Workflow: Publiceer broncode en intentie onder een 'as-is' licentie. Anderen remixen dit door een kleine Nix-overlay te schrijven die de gewenste wijziging één keer definieert. Deze derivatie wordt vervolgens hergebruikt in devenv shells, Docker-images, NixOS-systemen en tests, CI en agent-sandboxes — zonder dat er een fork nodig is of dat er een afwijkend artefact onderhouden hoeft te worden.
Kernprincipe: Ideeën boven patches. De waardevolle eenheid is een wijziging in gedrag of architectuur. Maintainers beslissen zelf of ze dit incorporeren, opnieuw implementeren of negeren. De oorspronkelijke auteur heeft geen blijvende verplichting om de wijziging te beoordelen, te integreren of te onderhouden.
Sociaal contract: De licentie staat remixen al toe. Het remixen creëert geen claim op de toekomstige tijd van anderen. Erkenning en zichtbaarheid kunnen blijven bestaan, maar er is geen voortdurende onderhoudsplicht. Incorporatie in de hoofdversie blijft optioneel en weloverwogen.
Ontdekking: Nuttige adaptaties verschijnen als een proliferatie van overlays in het wild. Maintainers kunnen uit die verspreiding putten als ze dat willen; iedereen anders kan ideeën simpelweg oppakken en samenvoegen door hun eigen overlays via een agent bij te werken.
Voorbeeld: Een gebruiker van een project wil de mogelijkheid van Git om een force push uit te voeren in dat specifieke project uitschakelen. In plaats van een pull request in te dienen bij het hoofdproject, maakt de gebruiker een overlay die Git патched om force pushes te weigeren. Dit wordt één keer gedefinieerd en verschijnt vervolgens consistent in ontwikkelaarsomgevingen, container-images en systeemtests — zonder een pull request tegen het hoofdproject.
In de praktijk zal ik vanaf nu voor elke code die ik op GitHub publiceer, pull requests uitschakelen, discussies openhouden en richtlijnen publiceren en onderhouden over hoe je mijn software kunt remixen.
Oneindig aanpasbare software die gemakkelijk te consumeren is: dat is wat ik hoop dat een standaardpraktijk wordt. Als je de cognitieve last van het uitbrengen van open source en het beheren van een groot project wegneemt, zullen we meer mensen zien die software publiceren. En als ze dat op de juiste manier doen, zullen we veel meer software in de wereld zien.
De netwerkgrafiek van GitHub biedt een fantastische manier om de remixes in het ecosysteem te verkennen. Je kunt zelfs agents erop loslaten om samen te vatten wat mensen doen. Je kunt het ook gebruiken in een agent-loop om remix-ideeën te verkennen en deze vervolgens terug te voeden naar het hoofdproject.
Groetjes,