Il Cloud è una prigione. Il movimento del software Local-First può liberarci?
Il Cloud è una prigione. Il Local-First può liberarci?
Qualche anno fa, il forum di discussione Hacker News, dove gli ingegneri decidono collettivamente cosa gli altri ingegneri dovrebbero leggere, ha sviluppato una caratteristica particolare. Una nuova frase era entrata nel lessico dei programmatori e sembrava spingere i link in cima alla pagina con tale forza che per alcuni i ranking potevano sembrare truccati. La frase – “local-first software” – aveva un suono artigianale, a chilometro zero, allo stesso tempo familiare e alludendo a qualcosa di nuovo. Forse alcuni ingegneri l’hanno scartata come un semplice termine di marketing. Ma altri, dedicando i loro pomeriggi lavorativi, sembravano vederla come la soluzione a un problema che avevano da tempo percepito: il software che stavano scrivendo era difettoso.
Uno dei primi link di Hacker News faceva riferimento a un white paper pubblicato nel 2019, scritto congiuntamente da un informatico dell’Università di Cambridge di nome Martin Kleppmann e un gruppo di sviluppatori open source di un “laboratorio di ricerca industriale” indipendente chiamato Ink & Switch. Kleppmann e gli altri erano ex membri di startup tech di successo che avevano fatto ciò che le startup tech di successo sono generalmente destinate a fare: essere acquisite. Avevano fatto un giro all’interno delle loro aziende acquirenti ed erano emersi pentiti, delusi da alcuni aspetti del loro settore. C’erano più sviluppatori di software che mai, ma non stavano creando esperienze migliori per i loro colleghi o utenti. Stavano scrivendo per il cloud.
Il lamento non era esattamente nuovo. Uno slogan stampato su adesivi per paraurti, magliette e bottiglie d’acqua nella Silicon Valley ha da tempo preso in giro l’industria locale con la frase “Non esiste il cloud. Esiste solo il computer di qualcun altro”. Quel “qualcun altro” è un’azienda. Vieni a Sand Hill Road con un’idea per un’app rivolta ai consumatori e ci sono due vie per ottenere un assegno abbastanza grande da farti finire su TechCrunch: monetizzare i dati dei tuoi utenti per la rivendita o la pubblicità, oppure far pagare loro una tariffa per accedere a quei dati. Qualunque sia il modello di business basato sul cloud che scegli – “Senatore, mostriamo annunci” o “Pagaci o sennò” – è imperativo che i dati passino attraverso i tuoi server.
Il white paper sul local-first (“manifesto” potrebbe essere il termine più appropriato) indicava una terza via. La bellezza del cloud, per l’utente medio, è che è accessibile da molti dispositivi e consente la collaborazione tra molte persone in diverse stanze e continenti. Gli autori proponevano di mantenere tutto questo, ma con un software essenzialmente senza cloud. La parola “locale” nel nome si riferisce al tuo computer personale. “Primo” significa che il tuo computer ha la priorità su quello di “qualcun altro”. Se io e tu volessimo lavorare su un documento insieme, non saremmo più costretti a dipendere da un centro dati di Google nel deserto dell’Oregon per mantenere la copia principale. Invece, avremmo ciascuno una copia memorizzata localmente sui nostri dispositivi. Io potrei modificare la mia copia offline e tu potresti modificare la tua, e i due file concilierebbero le nostre modifiche ogni volta che si connettono, che sia una volta al minuto o una volta alla settimana.
Per costruire prodotti come questi sarebbero necessari modi fondamentalmente diversi di strutturare i dati. Matematiche diverse. Il risultato di questo sforzo? Software meno scadente. Liberati dalla preoccupazione per i back-end, i server e le estorsioni delle tariffe di cloud computing, le startup e gli sviluppatori indipendenti potrebbero saltare il finanziamento VC legato a condizioni e dedicarsi ad app più interessanti. Inoltre, potrebbero approfittare dei miglioramenti hardware che spesso sfuggono ai developer del cloud. Quando un’app è basata sul cloud, le sue prestazioni sono limitate dalla velocità della connessione al server centrale e da quanto velocemente quel server può rispondere. Con un’app local-first, il dispositivo dell’utente esegue tutto il codice. Più il tuo laptop o smartphone è performante, più l’app può fare.
- Oggi Best Buy praticamente regala questo HP Chromebook | ENBLE
- Questo monitor Dell da 27 pollici 4K può essere tuo per $300 oggi |...
- Questo aggiornamento potrebbe prolungare la vita del tuo Chromebook...
Per uno sviluppatore, le tendenze opposte di macchine in accelerazione e tempi di caricamento stagnanti sono piuttosto sciocche. Offensivi, davvero. Dovresti esserne offeso anche tu, perché significa che ti sei perso qualcosa. Il cloud appare paradisiaco, finché non lo è più. Non hai notato, ultimamente, come le cinghie si stringono nella Silicon Valley, che la tua personale connessione internet sembra meno abbondante di prima? Che alcune cose stanno diventando un po’ più costose o un po’ meno convenienti? Un costo mensile per conservare tutte le tue foto o fare il backup del tuo telefono. Un upgrade premium per consentire a più utenti di modificare lo stesso file. Un videogioco che richiede un abbonamento e lagga proprio mentre stai per vincere.
Il giornalista e autore di fantascienza Cory Doctorow usa il termine “enshittification” per descrivere come il capitalismo delle piattaforme sprechi tecnologie utili. Una nuova piattaforma, piena di capitale di rischio, inizia bene con i suoi utenti. Poi gli inserzionisti arrivano per il suo pubblico e la piattaforma diventa buona anche per loro. Poi, ancora affamata di profitti, avvelena il pozzo. Inizia a interferire con le funzionalità che tu apprezzi fino a quando ne sei stufo. Questo è “come muoiono le piattaforme”, scrive Doctorow. La logica di business fredda apre questo triste percorso, ma sono le scelte tecnologiche a pavimentarlo.
Forse va bene. Forse il processo è rigenerativo, come un incendio che brucia la sottobosco. Fa spazio per nuove piattaforme che tornano a essere buone per noi, almeno per un po’. Ma cosa succederebbe se qualcosa di diverso potesse radicarsi? Cosa succederebbe se cambiando l’interno del software, invisibile per la maggior parte di noi, potesse aiutare a spingere la tecnologia fuori dalla merda?
Io e Kleppmann siamo sospesi a tre piani sopra il parcheggio del City Museum di St. Louis, un vecchio fabbrica di scarpe trasformata in un parco giochi e una discarica architettonica. È l’ora di chiusura e le guardie vorrebbero che scendessimo e ce ne andassimo. Kleppmann, però, punta al punto più alto della struttura, un jet d’affari degli anni ’60 scavato, accessibile attraverso un tubo ripido fatto di maglia metallica. Indossa un maglione blu reale che in qualche modo lo identifica immediatamente come europeo, i suoi capelli arancio-marroni arruffati raccolti in una coda di cavallo stretta. Mentre scivola nel fusoliera, immagino di inseguire una volpe.
La notte al museo è la parte preferita di Kleppmann di Strange Loop, che potrebbe essere la sua conferenza preferita per sviluppatori. È un evento che fonde gioia e stranezza con praticità, la sua combinazione ideale. Kleppmann è forse più conosciuto per un libro di testo chiamato Designing Data-Intensive Applications, che spiega i fondamenti dello spostamento di grandi quantità di dati in vasti sistemi informatici. Una guida stravagante per la sopravvivenza dei moderni sviluppatori, ha venduto più di 200.000 copie, sufficienti a meritare lo status di celebrità in questa comunità. I fan si fermano Kleppmann davanti alla bocca spalancata di una scultura di una balena a grandezza naturale e quando emerge da una scivolo di cinque piani, lo ringraziano per averli aiutati a ottenere il loro primo lavoro nel settore software.
I semi del manifesto local-first si trovano in una piccola casella alla pagina 174 del libro di Kleppmann. Descrive qualcosa chiamato tipo di dati replicati senza conflitti, o CRDT, che definisce come una “famiglia di strutture dati” che permettono a molte persone di collaborare su un file e “risolvere automaticamente i conflitti in modo sensato”. Nel libro, Kleppmann osserva che l’implementazione degli algoritmi CRDT è “ancora giovane”.
Tuttavia, secondo gli standard informatici, i CRDT stessi erano vecchi. Sono stati co-sviluppati da un teorico informatico francese di nome Marc Shapiro circa due decenni fa, quando la rivoluzione del cloud era ancora agli inizi. Shapiro, che aderiva a molti degli ideali del movimento peer-to-peer, stava cominciando a temere dove il cloud computing potesse portare il web. Mentre il protocollo internet stesso rimaneva aperto e decentralizzato, le cose che venivano costruite sopra di esso si stavano muovendo in una direzione monopolistica. Le aziende tecnologiche stavano creando bei giardini per attirare gli utenti, per poi costruire muri per scoraggiarli a lasciare.
Tuttavia, un’area che non avevano ancora completamente conquistato era la collaborazione online. La connettività non era abbastanza buona all’epoca. Shapiro e il suo collega Nuno Preguiça si chiedevano: le persone dovevano essere online per collaborare online? O potevano lavorare offline e collaborare peer-to-peer?
Concettualmente, non era così difficile immaginarlo: creare molte copie dello stesso file, ognuna delle quali si allinea automaticamente a uno stato identico ai suoi peer, come gli atomi nell’entanglement quantistico. Che tu modifichi la tua copia prima e riceva poi le mie modifiche, o che io modifichi la mia copia e riceva poi le tue modifiche, l’algoritmo produce lo stesso risultato per entrambi. In termini matematici, questa è la proprietà “commutativa” (infatti, è ciò che la “C” in CRDT inizialmente significava).
Come dovrebbe procedere l’algoritmo? Nella maggior parte dei casi, la risposta è semplice. Se io aggiungo un paragrafo e tu ne rimuovi un altro, l’ordine non importa. Ma supponiamo che entrambi giochiamo con la stessa parola; tu pensi che dovrebbe essere viola e io penso che dovrebbe essere malva. Cosa impedisce che il risultato sia purmaupleve? I diversi CRDT risolvono questo problema con regole diverse volte a preservare l’intento dei vari collaboratori. Possono fare affidamento sui timestamp per ordinare i nuovi elementi, o forse hanno un modo per codificare la relazione di ciascun elemento con gli elementi circostanti, preservando qualche nozione di parole o frasi. Le possibilità sono numerose.
Questi trucchi per preservare l’ordine possono rendere anche i CRDT terribilmente inefficienti. Sono troppe informazioni da tenere traccia. Quindi, l’altro compito per la progettazione di un CRDT è quello di decidere la quantità minima di informazioni che le repliche devono inviarsi a vicenda per produrre un risultato armonioso, e come confezionare tali modifiche in modo efficiente.
Shapiro e Preguiça hanno inizialmente pubblicato il loro algoritmo CRDT come un rapporto tecnico. Shapiro pensava di avviare un’azienda focalizzata sulla modifica collaborativa. “Pochi mesi dopo, boom, esce Google Docs”, mi dice. Il nuovo software utilizzava un vecchio processo di fusione delle modifiche chiamato trasformazione operativa, o OT, e si basava ancora su un server centrale di Google. Shapiro credeva di aver inventato qualcosa di più teoricamente solido, una base stabile per un software veramente peer-to-peer. Ma quando Kleppmann si imbatté nel suo articolo anni dopo, poche persone stavano utilizzando il software.
Kleppmann era cresciuto in Germania giocando sia con i computer che con la sua viola. Dopo un flirt abbandonato con una carriera nella composizione (le idee della “torre d’avorio” su cosa fosse buono e cosa fosse spazzatura non gli andavano d’accordo), aveva seguito la classica carriera da tecnico: aveva cofondato una startup (chiamata Rapportive, integrava dati dai profili dei social media nei contatti email); si era trasferito nella Bay Area (più vicino agli investitori e ai giganti dei social media); la sua startup era stata acquisita da un colosso tecnologico (LinkedIn). Kleppmann durò alcuni anni prima di lasciare per assumere una posizione di ricerca a Cambridge.
Il nuovo lavoro dava a Kleppmann ciò che aveva sempre desiderato: un ritorno alla creatività. Aveva la flessibilità di esplorare approcci più insoliti alla programmazione, inclusi progetti che potrebbero non pagare immediatamente. Spiega il suo lavoro con un’analogia presa in prestito dalla moglie, insegnante di chimica delle scuole superiori. Se si pensa ai singoli byte di dati come atomi, le strutture dati sono come le molecole. Per qualsiasi nuovo programmatore, il passo successivo dopo “ciao, mondo” è imparare queste disposizioni – liste, alberi, tabelle hash e grafi, per citare alcune categorie generali. Ciò che Kleppmann voleva scoprire erano disposizioni atomiche più strane che potessero consentire diversi tipi di applicazioni.
Descrive il paper di Shapiro come “un risveglio”. Nei CRDTs, Kleppmann vedeva la base tecnica per una nuova classe di software che nessuno stava fornendo. Ma gli algoritmi erano per lo più inutili per i programmatori professionisti. Eran troppo inefficienti e mancavano degli strumenti tipici che gli sviluppatori usano effettivamente per creare app. Kleppmann si rese conto che avrebbe dovuto rendere facile la vita dei programmatori local-first, guidando l’idea da un insieme di prove matematiche a un codice pronto per la produzione. Si mise a codificare un’implementazione open source di CRDTs, che chiamò Automerge, che le persone potevano utilizzare liberamente per creare app.
Vidi il frutto di questo sforzo qualche anno dopo, poco dopo che il manifesto local-first apparve su Hacker News. Incontrai Peter van Hardenberg, uno dei coautori di Kleppmann, in un caffè a San Francisco. Era, come Kleppmann, in fase di riavvio dopo un lungo viaggio attraverso il cloud, prima come parte del team fondatore di Heroku, che aiutava altre startup a far decollare i loro servizi cloud, e poi all’interno della sua acquisitrice, Salesforce. Voleva mostrarmi un’app chiamata Pushpin, concepita come una bacheca digitale.
Van Hardenberg aprì un progetto vuoto sul suo iPad. Caricai una replica dello stesso file sul mio computer portatile. Abbiamo iniziato a smanettare, aggiungendo immagini e caselle di testo ai nostri file, e poi li abbiamo fusi. A volte questo funzionava senza problemi; altre volte i cambiamenti smettevano di caricarsi, o i pixel trascinavano con una latenza da connessione dial-up. Pushpin sembrava un giocattolo, il tipo di app che un paio di brillanti studenti universitari di Stanford potrebbero programmare nella sala comune con visioni di un round di finanziamento iniziale e poi riporlo nell’imbarazzo.
Ma van Hardenberg era ben lungi dall’essere imbarazzato. L’infrastruttura tecnica si stava gettando le basi, credeva, per versioni local-first di Slack, Discord, Google Docs, Photoshop. Migliori app di progettazione, calendari, budget. Programmi più complessi, troppo, se Automerge potesse diventare molto più efficiente. C’era la possibilità di crittografia end-to-end privata per tutte queste app collaborative, poiché nessun server si metterebbe in mezzo. C’erano limiti tecnici ai CRDTs – e molte applicazioni che il cloud avrebbe servito molto meglio. Ma per lui, il prototipo sembrava una rivoluzione. Non c’era un server tra noi. Eppure funzionava. Per lo più. Eravamo due pari che comunicavano, come i primi costruttori di Internet intendevano.
La visione di Van Hardenberg era un po’ più facile da vedere quando ci siamo incontrati di nuovo a St. Louis. I giganti tecnologici stavano scivolando. Il valore delle azioni di Meta era ai minimi degli ultimi sette anni. Twitter era in mezzo a una presa di controllo ostile da parte di Elon Musk. Kleppmann trascorreva alcune ore ogni settimana come consulente tecnico per Bluesky, nato da Twitter come un esperimento decentralizzato e improvvisamente gettato sotto i riflettori, destinato a diventare suo concorrente. Il suo design “federato” prometteva di dare alle persone la possibilità di abbandonare server e servizi che le trattavano male. Bluesky non stava utilizzando i CRDTs, che sarebbero stati troppo lenti per coordinare i feed di milioni di utenti dei social media, ma l’obiettivo era simile: una migliore relazione con “il computer di qualcun altro”. Le alternative di calcolo erano di nuovo di moda.
Tra queste, i CRDTs. Strange Loop era piena di presentazioni sulla local-first: una sorpresa per Kleppmann e van Hardenberg, che fino a poco tempo fa tenevano traccia di ogni progetto tramite Google Alerts e di bocca in bocca. I CRDTs stavano emergendo anche nel mondo più ampio. Gli sviluppatori del The Washington Post li avevano utilizzati per costruire uno strumento per organizzare gli articoli sulla homepage. Le persone che si stavano guardando nel codice dell’app Note di Apple avevano notato i CRDTs. Jupyter Notebooks, un’app di data science popolare, aveva ripristinato i suoi strumenti di collaborazione utilizzando i CRDTs dopo che Google aveva eliminato il servizio cloud su cui precedentemente dipendeva.
Tra i relatori a Strange Loop c’era un sviluppatore canadese di nome Brooklyn Zelenka, cofondatore di un’azienda chiamata Fission. Quando ha letto il manifesto local-first, ricorda, “ho pensato, questa è una grande frase. Prima di allora, avevamo queste frasi imbarazzanti, come ‘indipendenza dalla posizione’ o ‘dati di proprietà dell’utente'”. Zelenka era interessata alle idee di Web3 – il soprannome adottato dalle app “decentralizzate” che utilizzano la tecnologia blockchain e le criptovalute – ma ha trovato la sua cultura “aggressiva”, che ha attribuito all’attenzione al denaro “in modo così evidente, tutto il tempo”. Era bello essere entrati presto nel local-first. “Tutto è facile da raggiungere in questo momento”, mi ha detto Zelenka.
La sua era una traiettoria comune. Crypto “ha portato fuori tutto il peggio delle persone”, mi ha detto van Hardenberg a pranzo durante la conferenza, ma ha anche parlato degli stessi principi di local-first. Secondo lui, semplicemente utilizza un approccio errato, promettendo agli utenti decentralizzazione e indipendenza, ma legandoli a incentivi finanziari speculativi. È anche il contrario di offline-first: complicati blockchain, controllate da chi accumula più risorse, mediano ogni interazione. Tuttavia, la crypto ha offerto una lezione su come l’hype possa alimentare la creazione di nuovi prodotti. Van Hardenberg ha notato il gran numero di programmatori annoiati e insoddisfatti presso aziende come Meta e Google che hanno cambiato campo durante l’apice della bolla crypto.
Van Hardenberg pensava che il local-first potesse alla fine suscitare la stessa eccitazione, ma con software che fosse effettivamente buono. Ciò di cui aveva bisogno, ha detto van Hardenberg, era una grande “uscita” che avrebbe portato “segni di ricchezza visibili” a un gruppo fortunato di sviluppatori local-first e avrebbe contribuito ad attirare più talento e risorse. La crescita era anche spaventosa. Van Hardenberg e Kleppmann finora avevano evitato il finanziamento del capitale di rischio per Automerge stesso, temendo che li avrebbe costretti in varietà di modelli di business che “vanno totalmente contro i valori del local-first”, come mi ha detto Kleppmann. Ma a un certo punto, si sono resi conto che la crescita sarebbe stata necessaria. Speravano che il software potesse parlare da solo. “I VC amano una riprogettazione”, ha detto van Hardenberg.
Pochi mesi dopo la conferenza, “local first” era nuovamente in tendenza su Hacker News. Un commentatore ha definito i CRDT la spada “uccisore di draghi” che consentirebbe alle app local-first di competere con il cloud. Un altro si lamentava del fatto che ogni interessante post tecnico sui CRDT degenerava in una “strana discussione politica sulla decentralizzazione”.
Nonostante i molti movimenti per la decentralizzazione tecnologica, il tesoro del drago d’oro continua a crescere. Uno dei problemi è la percezione che i principi vadano a scapito della comodità. Per quanto appagante e virtuoso possa essere costruire il proprio tavolino da caffè, è anche difficile. Alla fine ci si stanca e si compra il prossimo pezzo di mobili su Amazon. Così avviene per la gestione dei dati. “È molto più facile essere pigri e lasciare che Apple o Google lo facciano per te”, mi ha detto Shapiro. Quando gli ho chiesto com’era usare l’internet moderno aderendo ai suoi principi, mi ha detto che semplicemente si astiene dalla tecnologia il più possibile. “È uno spreco terribile del tuo tempo”, mi ha detto.
Ero curioso se il termine “local first” infastidisse Shapiro in qualche modo, se lo considerava una rietichettatura indesiderata della sua creazione tecnica. Sono rimasto sorpreso quando mi ha detto che gli piaceva molto. Pensava che ci fosse magia nella frase. Forse la rivoluzione deve essere un po’ furtiva per sferrare un colpo: attirare gli sviluppatori con le possibilità tecniche, chiamarla un “movimento” per attirare i giornalisti ossessionati dalla politica (ciao). Forse deve anche arrivare al momento giusto, quando le piattaforme Big Tech sembrano pronte a crollare, rivelando le funzionalità perse e gli abusi subiti in cambio di comodità.
Kleppmann non chiedeva un ritorno all’analogico o di distruggere tutti i server cloud, che fanno molte cose utili. La spada non era un uccisore ma uno strumento per creare qualcosa di migliore – e anche lui direbbe che ha ancora bisogno di essere affinato. Quando gli ho chiesto se potevo provare un nuovo editor di testo basato su CRDT su cui stava lavorando, la sua solita espressione di calma attenzione si è trasformata brevemente in allarme. Ovviamente, teoricamente potrei eseguire il prototipo che è pubblicato online, dato che è open source – “ma per favore non farlo”, mi ha detto. Mi avrebbe fatto sapere quando il local-first fosse pronto.
Fateci sapere cosa ne pensate di questo articolo. Inviare una lettera all’editore a mail@wired.com.
