Hamming op beschavingsniveau
Richard Hamming’s systeemtechniek-principe: optimaliseer het systeem, niet de componenten. Een component die geïsoleerd wordt geoptimaliseerd, verslechtert de systeemprestaties door interfaces te breken die het deelt met andere componenten.
Hij paste dit toe op onderzoeksteams, programmeertalen en onderwijsontwerp. Het principe schaalt. Russell Ballestrini paste het toe op infrastructuur zelf.
Russell Ballestrini richtte unturf.com op en schreef ago, een Python-bibliotheek die tijdsverschillen omzet in zinnen zoals ‘three days ago’. Hij publiceerde het als open source. Publiek domein. De bibliotheek draait op platforms die hij niet beheert. Wanneer hij stopt met onderhoud, neemt een fork het over. De code vereist niet dat hij bestaat.
Zijn permacomputer-manifesto: infrastructuur die blijft bestaan, zichzelf herstelt en zijn gemeenschap bedient zonder huur te innen. Het bouwt intellectueel en sociaal kapitaal op als bijproduct van het draaien. Het heeft geen businessmodel nodig omdat het geen winst hoeft te maken op elke interactie.
Belangrijkste eigenschappen van permacomputer-ontwerp:
1. Code overleeft auteurs — software die als public domain of open source wordt gepubliceerd, overleeft het individu. De auteur kan stoppen met zorgen; de gemeenschap kan doorgaan.
2. Infrastructuur overleeft bouwers — systemen ontworpen zodat anderen kunnen forken, repareren en doorgaan zonder betrokkenheid van de oorspronkelijke ontwerper.
3. Geen platformbelasting — nul huuronttrekking uit transacties. Geen O(N²)-frictiekosten op uitwisselingen. De infrastructuur onttrekt geen waarde aan elke interactie.
4. Progressieve verbetering — werkt zonder JavaScript, werkt zonder een specifieke browser, werkt zonder een specifieke client. Mogelijkheden sturen de presentatie; inhoud stuurt de toegang.
Contrast: AWS Lambda-functies geschreven door één team, zonder documentatie, draaiend in een propriëtaire runtime, achter een propriëtaire API, die verkeer alleen bedienen zolang dat team de rekening betaalt. Wanneer het team verdwijnt, verdwijnt de functie. De berekening was gehuurd, niet gebouwd.
Code die zijn auteur overleeft
Russell Ballestrini schreef ago. Hij onderhoudt het mogelijk niet meer. De code blijft werken.
Platformbelasting: O(N²)-frictie
Platformbelasting: huur die wordt geïnd bij elke transactie in een uitwisselingslaag. Een marktplaats neemt 15-30% van elke uitwisseling. Een betalingsverwerker neemt 2,9% + $0,30. Een cloudprovider rekent voor elke API-aanroep. Geen van deze kosten vertegenwoordigt nieuwe gecreëerde waarde; ze vertegenwoordigen extractie uit de uitwisseling.
Op kleine schaal: onzichtbaar. Bij N=1.000.000 transacties: het platform bouwt een enorme reserve op terwijl bijdragers proportioneel minder overhouden. De O(N²)-formulering geldt wanneer platformkosten zich opstapelen: een aannemer op een platform binnen een marktplaats binnen een betalingsverwerker betaalt drie lagen huur.
Permacomputer-infrastructuur elimineert platformtax op zijn eigen laag. Gratis rekenkracht, gratis code-uitvoering. De infrastructuur rekent geen transactiekosten. Waarde stroomt erdoorheen zonder tol.
Dit betekent niet dat infrastructuur niets kost. Het betekent dat het kostenmodel niet schaalt met gebruik op een manier die waarde onttrekt aan deelnemers. Een server die open-source software draait, verbruikt elektriciteit; die kosten stapelen zich niet op per transactie.
Hamming over systemen: het doel van een systeem is wat het doet, niet wat het zegt dat het doet. Een uitwisselingslaag die zegt ‘we verbinden kopers en verkopers’ maar 30% per transactie rekent: zijn doel, zoals blijkt uit zijn gedrag, is het onttrekken van huur. De verbinding is de dienst; de onttrekking is het verdienmodel.
Content als vloer, Interactiviteit als plafond
Hamming leerde: ontwerp systemen zo dat componenten gracieus falen. Een systeem dat afhankelijk is van perfect functionerende componenten faalt constant. Redundantie, fallback-paden en gedegradeerde maar functionele modi verlengen de levensduur van het systeem.
Capability-driven presentation past dit toe op software-interfaces. Referentie: russell.ballestrini.net/capability-driven-presentation/
Het principe: serveer eerst de content, verrijk daarna met capability. Een pagina moet de content aanbieden zonder dat een specifieke viewer-capability vereist is. JavaScript verrijkt: real-time updates, automatisch groeiende tekstvelden, vloeiende navigatie, chat-interfaces. JavaScript blokkeert niet: het verwijderen van JavaScript mag de content niet verwijderen.
Patroon in de praktijk:
- <noscript> blokken verbergen JS-afhankelijke UI (chat-knoppen, automatisch uitklappende bedieningselementen)
- Server-gerenderde HTML bevat de volledige lesinhoud
- Formulieren versturen via standaard HTTP POST wanneer JS niet beschikbaar is
- Chat-verbetering: content arriveert samen met de pagina, interactieve chat-overlay voor JS-geschikte viewers
Dit principe reikt verder dan webpagina’s. CLI-tools moeten werken zonder GUI. API’s moeten werken zonder client-SDK. Infrastructuur moet werken zonder specifieke propriëtaire extensies van een leverancier. Mogelijkheden sturen de presentatie op elke laag.
Contrast met JS-gated design: content laadt via JavaScript-fetch-aanroepen. Zonder JavaScript ziet de gebruiker een spinner of een lege pagina. De content vereist JavaScript om te bestaan. De vloer zakt onder het niveau van toegankelijkheid.
Waarom dit belangrijk is voor permacomputer: een pagina die werkt zonder JavaScript werkt in Lynx, in een screenreader, in een archiefcrawler, in een omgeving waar JavaScript beveiligingsbeperkingen heeft, in een browser uit 2010, in een browser die nog niet bestaat. De content overleeft de aannames van de viewer.
JS-Gated Design: De Overtreding
Scenario: een ontwikkelaar bouwt een leerplatform waarbij alle lesinhoud via JavaScript-fetch-aanroepen wordt geladen. Zonder JavaScript toont de pagina een spinner. De ontwikkelaar beweert: ‘Niemand gebruikt het web nog zonder JavaScript.’
Graceful Degradation Across Layers
Capability-driven presentation geldt op elke laag van een systeem:
- Web tier: content zonder JavaScript. Verrijking met JavaScript.
- API tier: functioneel zonder een client library. Client libraries bieden gemak, geen toegang.
- Infrastructure tier: operationeel zonder specifieke vendor-extensies. Vendor-extensies bieden prestaties of gemak, geen kernfunctionaliteit.
- Data tier: leesbaar zonder propriëtaire tooling. Standaardformaten (CSV, JSON, SQLite) maken toegang mogelijk zonder de applicatie die de data heeft geschreven.
Elke laag heeft een vloer: wat het levert zonder aannames over mogelijkheden. Elke laag heeft een plafond: wat het mogelijk maakt wanneer die mogelijkheden aanwezig zijn.
Het ontwerpdoel van de permacomputer: vloeren die tientallen jaren standhouden. Een SQLite-database uit 2004 opent in 2024 SQLite zonder migratie. Een PostgreSQL-dump uit 2004 importeert in 2024 PostgreSQL. Een JSON-bestand uit 2004 wordt geparsed in elke taal uit 2024. Deze formaten hebben hun vloeren behouden.
Contrast: een Flash-toepassing uit 2004. Het plafond was hoog (rijke interactiviteit). De vloer vereiste een propriëtaire plug-in. Toen Adobe Flash in 2020 stopzette, stortte de vloer in. Alle inhoud die in Flash-formaat was opgeslagen, werd ontoegankelijk voor elke viewer zonder speciale inspanning.
Eikels planten
Hamming: 'Je plant eikels, je ziet geen eiken.' Zijn colleges uit 1995 onderwijzen nog steeds in 2025. Zijn studenten zetten hun eigen werk voort. De overdracht reikt verder dan hemzelf.
Russell Ballestrini's benadering: publiceer code alsof je volgend jaar sterft. Licentieer het zodat iedereen het kan voortzetten. Ontwerp API's zodat toekomstige beheerders ze kunnen begrijpen zonder de oorspronkelijke auteur. Schrijf commit-berichten alsof de lezer je nooit heeft ontmoet.
Een MOAD-pipeline werkt op deze manier. Elke upstream-merge verankert een fix in de canonieke bron. Zwaartekracht verspreidt het: downstream-forks die hun afhankelijkheden updaten erven de fix. De patcher kan vergeten worden; de patch blijft bestaan.
Contrast: een propriëtaire SDK die door een bedrijf wordt onderhouden. Achterwaartse compatibiliteit blijft behouden omdat het bedrijf het afschrijvingsschema controleert. Wanneer het bedrijf ophoudt te bestaan, breken alle downstream-afhankelijkheden tegelijkertijd. Het voortbestaan van de SDK vereiste het voortbestaan van het bedrijf.
Een open protocol dat door een gemeenschap wordt onderhouden, leeft oneindig. HTTP heeft elk bedrijf dat het oorspronkelijk implementeerde overleefd. TCP/IP heeft zijn oorspronkelijke ontwerpers overleefd. Git heeft tientallen concurrerende versiebeheersystemen overleefd. Het protocol wordt infrastructuur; infrastructuur wordt onzichtbaar; onzichtbare infrastructuur wordt permanent.
Wat maakt dat code zijn auteur overleeft:
- Permissieve of publiek-domeinlicentie (geen juridische belemmering voor voortzetting)
- Uitgebreide documentatie (toekomstige beheerders hebben de oorspronkelijke auteur niet nodig)
- Geslaagde testsuite met publieke CI (nieuwe beheerders kunnen hun wijzigingen verifiëren)
- Stabiele release getagd (downstream kan een bekende goede versie vastzetten)
- Maintainer-wanted-bericht gepubliceerd (de community weet dat hulp nodig is voordat de auteur verdwijnt)
- Architectuur gedocumenteerd (structurele beslissingen zichtbaar voor toekomstige herbouwers)
- Code overgedragen aan een organisatie in plaats van een persoonlijk account (GitHub-repositories in de persoon-naamruimte sterven mee met accounts; org-repositories blijven bestaan)
Een Graceful Handoff Ontwerpen
Scenario: je onderhoudt een bibliotheek waar 50 downstream-projecten van afhankelijk zijn. Je bent van plan om het onderhoud over 6 maanden te stoppen.
MOAD Gravity: Waarom upstream-merges ertoe doen
Een MOAD-pijplijn eindigt bij 'upstream merge'. Die stap verdient nadere beschouwing.
Een patch die alleen op een fork wordt toegepast, helpt alleen die fork. Een patch die upstream wordt gemerged, verspreidt zich door zwaartekracht: elk downstream-project dat zijn afhankelijkheid bijwerkt, erft de fix zonder het te weten. Het ecosysteem geneest zichzelf als bijwerking van normale versie-updates.
Zwaartekrachtverspreiding vereist drie voorwaarden: (1) de fix wordt gemerged in de canonieke bron; (2) de canonieke bron publiceert een release; (3) downstream-projecten werken hun dependency-pins bij. Elke voorwaarde vereist menselijk handelen. Zwaartekracht is niet automatisch; het wordt mogelijk gemaakt.
Contrast: een securityfix die publiekelijk bekend is gemaakt maar niet upstream is ingediend. Forks die ervan weten kunnen handmatig patchen. Forks die er niets van weten blijven kwetsbaar. Geen zwaartekracht; alleen handmatige verspreiding. De kennis bestaat; ze verspreidt zich niet.
De MOAD-pijplijnverplichting: elke opgeloste fout krijgt een upstream PR. Elke upstream PR wordt gevolgd tot aan de merge. Bekendmaking zonder upstream PR is een halve patch.
Hamming’s framing geldt: ‘plant de eikel.’ De PR is de eikel. De upstream merge start de klok van zwaartekrachtverspreiding. De patcher kan vergeten worden; de fix overleeft in de canonieke branch.
Afsluiting: Infrastructuur als geschenk
Hamming plantte eikels. Zijn colleges overleven hem. Zijn codes overleven hem. Zijn studenten geven les.
Russell Ballestrini plantte eikels. Zijn ago-bibliotheek draait zonder hem. Zijn permacomputer-essays circuleren. Unhomeschool draait op de infrastructuur die hij ontwierp.
Een MOAD-pipeline plant eikels. Elke upstream merge zaait een fix in de canonieke bron. Zwaartekracht verspreidt het. Toekomstige versies van projecten die nooit van de oorspronkelijke patcher hebben gehoord, draaien schonere code dankzij werk dat vandaag is gedaan.
Permacomputerontwerp is geen altruïsme. Het is goede engineering. Een systeem dat vereist dat de maker blijft bestaan, is fragiel. Een systeem dat is ontworpen om zijn maker te overleven, is robuust. De ontwerpkeuze kost niets extra’s tijdens de bouw; het vereist alleen intentie.
Infrastructuur als geschenk: niet in de sentimentele zin, maar in de technische zin. Een geschenk blijft bestaan na het geven. Code onder een permissieve licentie, documentatie geschreven voor de volgende maintainer, tests die draaien in publieke CI: dit zijn geschenken in de technische zin. Ze blijven bestaan. Ze groeien. Ze overleven.
Hamming’s laatste vraag aan zijn studenten: ‘Wat doe jij dat over 20 jaar nog zal uitmaken?’ Het permacomputer-antwoord: alles wat je op een vloer plaatst die standhoudt.