Hamming alla scala della civiltà
Il principio di ingegneria dei sistemi di Richard Hamming: ottimizzare il sistema, non i componenti. Un componente ottimizzato in isolamento degrada le prestazioni del sistema rompendo le interfacce che condivide con altri componenti.
Lo ha applicato ai team di ricerca, ai linguaggi di programmazione, alla progettazione educativa. Il principio si scala. Russell Ballestrini lo ha applicato all'infrastruttura stessa.
Russell Ballestrini ha fondato unturf.com e scritto ago, una libreria Python che umanizza gli intervalli temporali in frasi come 'tre giorni fa'. L'ha pubblicata come open source. Pubblico dominio. La libreria funziona su piattaforme che non controlla. Quando smette di mantenerla, un fork la riprende. Il codice non richiede la sua esistenza.
Il suo manifesto del permacomputer: un'infrastruttura che persiste, si auto-ripara e serve la propria comunità senza estrarre rendite. Cresce il capitale intellettuale e sociale come sottoprodotto del suo funzionamento. Non ha bisogno di un modello di business perché non deve trarre profitto da ogni interazione.
Proprietà chiave del design del permacomputer:
1. Il codice sopravvive agli autori — il software pubblicato come pubblico dominio o open source sopravvive all'individuo. L'autore può smettere di interessarsene; la comunità può continuare.
2. L'infrastruttura sopravvive ai costruttori — sistemi progettati affinché altri possano forkare, correggere e continuare senza il coinvolgimento del progettista originale.
3. Nessuna tassa sulla piattaforma — zero estrazione di rendite dalle transazioni. Nessun addebito di attrito O(N²) sugli scambi. L'infrastruttura non estrae valore da ogni interazione.
4. Miglioramento progressivo — funziona senza JavaScript, funziona senza un browser specifico, funziona senza un client specifico. La capacità guida la presentazione; il contenuto guida l'accesso.
Contrasto: funzioni AWS Lambda scritte da un solo team, senza documentazione, eseguite in un runtime proprietario, dietro un'API proprietaria, che servono traffico solo finché quel team paga la bolletta. Quando il team si scioglie, la funzione scompare. Il calcolo era affittato, non costruito.
Codice che sopravvive al suo autore
Russell Ballestrini ha scritto ago. Potrebbe non mantenerlo più. Il codice continua a funzionare.
Platform Tax: attrito O(N²)
Platform tax: rendita estratta da ogni transazione in uno strato di scambio. Un marketplace prende il 15-30% di ogni scambio. Un processore di pagamenti prende il 2,9% + $0,30. Un provider cloud addebita ogni chiamata API. Nessuno di questi costi rappresenta nuovo valore creato; rappresentano estrazione dallo scambio.
A piccola scala: invisibile. A N=1.000.000 transazioni: la piattaforma accumula una vasta riserva mentre i contributori accumulano proporzionalmente meno. La formulazione O(N²) si applica quando le commissioni della piattaforma si compongono: un appaltatore su una piattaforma dentro un marketplace dentro un processore di pagamenti paga tre livelli di rendita.
L'infrastruttura Permacomputer elimina la platform tax dal proprio livello. Calcolo gratuito, esecuzione del codice gratuita. L'infrastruttura non addebita per transazione. Il valore fluisce senza pedaggio.
Questo non significa che l'infrastruttura non costi nulla. Significa che il modello di costo non scala con l'uso in modo da estrarre valore dai partecipanti. Un server che esegue software open-source consuma elettricità; quel costo non si moltiplica per transazione.
Hamming sui sistemi: lo scopo di un sistema è ciò che fa, non ciò che dice di fare. Uno strato di scambio che afferma "colleghiamo acquirenti e venditori" ma addebita il 30% per transazione: il suo scopo, rivelato dal comportamento, è l'estrazione di rendita. La connessione è il servizio; l'estrazione è il modello di business.
Contenuto come Pavimento, Interattività come Soffitto
Hamming insegnava: progetta sistemi in modo che i componenti si guastino con grazia. Un sistema che dipende dal funzionamento perfetto di ogni componente fallisce costantemente. Ridondanza, percorsi di fallback e modalità degradate ma funzionali prolungano la vita del sistema.
La presentazione guidata dalle capability applica questo principio alle interfacce software. Riferimento: russell.ballestrini.net/capability-driven-presentation/
Il principio: fornisci prima il contenuto, poi arricchiscilo con le capability. Una pagina deve fornire il suo contenuto senza richiedere alcuna capability specifica del visualizzatore. JavaScript arricchisce: aggiornamenti in tempo reale, aree di testo auto-espandibili, navigazione fluida, interfacce di chat. JavaScript non blocca: rimuovere JavaScript non deve rimuovere il contenuto.
Pattern in pratica:
- i blocchi <noscript> nascondono l'interfaccia dipendente da JS (pulsanti di chat, controlli di espansione automatica)
- l'HTML renderizzato dal server contiene l'intero contenuto della lezione
- i moduli vengono inviati tramite HTTP POST standard quando JS non è disponibile
- Miglioramento della chat: il contenuto arriva con la pagina, chat interattiva sovrapposta per gli utenti con JS abilitato
Questo principio va oltre le pagine web. Gli strumenti CLI dovrebbero funzionare senza GUI. Le API dovrebbero funzionare senza SDK client. L'infrastruttura dovrebbe funzionare senza estensioni proprietarie di un vendor specifico. La capacità guida la presentazione a ogni livello.
Contrasto con il design JS-gated: il contenuto viene caricato tramite chiamate fetch JavaScript. Senza JavaScript, l'utente vede uno spinner o una pagina vuota. Il contenuto richiede JavaScript per esistere. Il livello minimo è sceso sotto l'accessibilità.
Perché è importante per il permacomputer: una pagina che funziona senza JavaScript funziona in Lynx, in un lettore di schermo, in un crawler di archiviazione, in un ambiente con restrizioni di sicurezza su JavaScript, in un browser del 2010, in un browser non ancora creato. Il contenuto sopravvive alle assunzioni del visualizzatore.
Design JS-Gated: La Violazione
Scenario: uno sviluppatore crea una piattaforma di apprendimento in cui tutti i contenuti delle lezioni vengono caricati tramite chiamate fetch JavaScript. Senza JavaScript, la pagina mostra uno spinner. Lo sviluppatore sostiene: "Nessuno usa più il web senza JavaScript."
Degradazione Graduale Attraverso i Livelli
La presentazione guidata dalle capacità si applica a ogni livello di un sistema:
- Livello Web: contenuto senza JavaScript. Miglioramento con JavaScript.
- Livello API: funzionale senza una libreria client. Le librerie client forniscono comodità, non accesso.
- Livello Infrastruttura: operativo senza le estensioni di uno specifico fornitore. Le estensioni del fornitore forniscono prestazioni o comodità, non la funzione principale.
- Livello Dati: leggibile senza strumenti proprietari. I formati standard (CSV, JSON, SQLite) consentono l'accesso senza l'applicazione che ha scritto i dati.
Ogni layer ha un floor: ciò che fornisce senza presupporre capacità. Ogni layer ha un ceiling: ciò che abilita quando le capacità sono presenti.
L'obiettivo di progettazione del permacomputer: floor che resistono per decenni. Un database SQLite del 2004 si apre in SQLite 2024 senza migrazione. Un dump PostgreSQL del 2004 si importa in PostgreSQL 2024. Un file JSON del 2004 viene analizzato in qualsiasi linguaggio del 2024. Questi formati hanno mantenuto i loro floor.
Contrasto: un'applicazione Flash del 2004. Il ceiling era alto (interattività ricca). Il floor richiedeva un plugin proprietario. Quando Adobe ha eliminato Flash nel 2020, il floor è crollato. Tutti i contenuti memorizzati in formato Flash sono diventati inaccessibili a qualsiasi visualizzatore senza uno sforzo speciale.
Piantare Ghiande
Hamming: "Pianti ghiande, non vedi querce." Le sue lezioni del 1995 continuano a insegnare nel 2025. I suoi studenti proseguono il loro lavoro. La trasmissione va oltre lui.
La cornice di Russell Ballestrini: pubblica il codice come se dovessi morire l'anno prossimo. Concedilo in licenza in modo che chiunque possa continuarlo. Progetta API in modo che i futuri manutentori possano capirle senza l'autore originale. Scrivi i messaggi di commit come se il lettore non ti avesse mai incontrato.
Una pipeline MOAD funziona così. Ogni merge upstream incorpora una correzione nel sorgente canonico. La gravità la propaga: i fork downstream che aggiornano le loro dipendenze ereditano la correzione. Il patcher può essere dimenticato; la patch sopravvive.
Contrasto: un SDK proprietario mantenuto da un'azienda. La compatibilità all'indietro si mantiene perché l'azienda controlla il calendario delle deprecazioni. Quando l'azienda si scioglie, ogni dipendenza downstream si rompe simultaneamente. La sopravvivenza dell'SDK richiedeva la sopravvivenza dell'azienda.
Un protocollo aperto mantenuto da una comunità vive indefinitamente. HTTP ha superato ogni azienda che lo ha implementato originariamente. TCP/IP ha superato i suoi progettisti originali. Git ha superato decine di sistemi di controllo di versione concorrenti. Il protocollo diventa infrastruttura; l'infrastruttura diventa invisibile; l'infrastruttura invisibile diventa permanente.
Cosa fa durare il codice oltre il suo autore:
- Licenza permissiva o di pubblico dominio (nessun ostacolo legale alla continuazione)
- Documentazione completa (i futuri manutentori non avranno bisogno dell'autore originale)
- Suite di test superata con CI pubblica (i nuovi manutentori possono verificare le loro modifiche)
- Release stabile taggata (i downstream possono bloccare una versione nota e funzionante)
- Avviso di ricerca manutentore pubblicato (la community sa che serve aiuto prima che l'autore scompaia)
- Architettura documentata (le decisioni strutturali sono visibili a chi ricostruirà in futuro)
- Codice trasferito a un'organizzazione invece che a un account personale (i repository GitHub nello spazio-nomi personale muoiono con gli account; i repository delle org persistono)
Progettare un passaggio di consegne elegante
Scenario: mantieni una libreria da cui dipendono 50 progetti downstream. Hai intenzione di smettere di mantenerla entro 6 mesi.
Gravità MOAD: perché le merge upstream contano
Una pipeline MOAD termina con la «merge upstream». Questo passaggio merita un esame.
Una patch applicata solo a un fork aiuta quel fork. Una patch integrata upstream si propaga per gravità: ogni progetto downstream che aggiorna la propria dipendenza eredita la correzione senza saperlo. L’ecosistema si autoripara come effetto collaterale dei normali aggiornamenti di versione.
La propagazione per gravità richiede tre condizioni: (1) la correzione viene integrata nel sorgente canonico; (2) il sorgente canonico pubblica una release; (3) i progetti downstream aggiornano i propri pin delle dipendenze. Ogni condizione richiede un’azione umana. La gravità non è automatica; è abilitata.
Contrasto: una correzione di sicurezza divulgata pubblicamente ma non inviata upstream. I fork che ne sono a conoscenza possono applicare la patch manualmente. I fork che non ne sono a conoscenza rimangono vulnerabili. Nessuna gravità; solo propagazione manuale. La conoscenza esiste; non si diffonde.
L'impegno di una pipeline MOAD: ogni difetto corretto genera una PR upstream. Ogni PR upstream viene seguita fino al merge. La divulgazione senza PR upstream è solo mezza patch.
Si applica il quadro di Hamming: "pianta la ghianda". La PR è la ghianda. Il merge upstream avvia il conto alla rovescia per la propagazione della gravità. Il correttore può essere dimenticato; la correzione sopravvive nel branch canonico.
Conclusione: Infrastruttura come Dono
Hamming ha piantato ghiande. Le sue lezioni lo sopravvivono. I suoi codici lo sopravvivono. I suoi studenti insegnano.
Russell Ballestrini ha piantato ghiande. La sua libreria ago funziona senza di lui. I suoi saggi sul permacomputer circolano. Unhomeschool funziona sull'infrastruttura che ha progettato.
Una pipeline MOAD pianta ghiande. Ogni merge upstream semina una correzione nel sorgente canonico. La gravità la propaga. Versioni future di progetti che non hanno mai sentito parlare del patcher originale eseguono codice più pulito grazie al lavoro svolto oggi.
Il design del permacomputer non è altruismo. È buona ingegneria. Un sistema che richiede la persistenza del suo creatore è fragile. Un sistema progettato per sopravvivere al suo creatore è robusto. La scelta progettuale non costa nulla in più al momento della costruzione; richiede solo intenzione.
Infrastruttura come dono: non in senso sentimentale, ma in senso tecnico. Un dono persiste dopo la donazione. Codice sotto licenza permissiva, documentazione scritta per il prossimo manutentore, test che vengono eseguiti in CI pubblica: questi sono doni in senso tecnico. Persistono. Crescono. Sopravvivono.
L'ultima domanda di Hamming ai suoi studenti: 'Cosa state facendo che avrà importanza tra 20 anni?' La risposta del permacomputer: qualsiasi cosa mettiate su un pavimento che regge.