L'archivio che ha cambiato il web (e quello che ci sta insegnando oggi)

C'era una volta, prima di WordPress, prima di Squarespace, prima che qualcuno pronunciasse la parola "no-code" in modo serio. C'era un ragazzo del liceo di nome Matt Wright che un giorno decise di condividere alcuni script Perl che aveva scritto.

Siamo intorno al 1995. Wright lancia Matt's Script Archive, una raccolta modestissima di utility per siti web: form di contatto, guestbook, contatori di visite, e un gioiellino chiamato WWWboard che diventò virale in fretta. Nel giro di pochi mesi, migliaia di siti giravano con il suo codice. Persone normali — che non avevano idea di cosa fosse Perl o come funzionasse CGI — improvvisamente avevano forum funzionanti e funzionalità interattive.

Era il primo assaggio di tool democratici per il web. Con tutte le conseguenze disastrose che quella parola implica.

Il divario tra chi costruisce e chi usa

Ciò che rese popolari gli script di Matt era esattamente ciò che faceva rabbrividire i programmatori: funzionavano. Non elegantemente. Non in sicurezza. Ma funzionavano.

Wright era inciampato in una verità fondamentale sull'adozione del software: la maggior parte delle persone non vuole capire i propri strumenti. Vuole che gli strumenti capiscano loro. Un piccolo imprenditore nel 1996 non si preoccupava della validazione degli input o della prevenzione di SQL injection. Gli importava che i visitatori potessero lasciare messaggi sul suo sito artigianale.

Nel frattempo, gli sviluppatori esperti guardavano quel codice e vedevano un incubo. Password salvate in cartelle accessibili pubblicamente. Variabili d'ambiente esposte negli URL. Una vulnerabilità particolarmente schifosa nel suo textcounter aveva un punteggio CVSS perfetto: 10.0. Traduzione: una porta spalancata al server.

La comunità Perl alla fine rispose con nms (nongreedy's modifications), un progetto che creava sostituti diretti senza esporre gli utenti a compromissioni root. La loro valutazione era brutale ma onesta: "Questi script sono universalmente noti nella comunità Perl per essere mal scritti, pieni di bug e insicuri."

Il paradosso della popolarità

Ed è qui che la cosa si fa filosoficamente interessante.

Gli script di Matt non erano unicamente pessimi per la loro epoca. Tanto codice early-web aveva falle di sicurezza. Ciò che rendeva pericoloso il suo lavoro era la portata. Quando migliaia di siti usano lo stesso software vulnerabile, ottieni una superficie d'attacco enorme. Improvvisamente, una vulnerabilità teorica diventa un'epidemia reale.

Questo schema si è ripetuto all'infinito da allora. Windows. WordPress. jQuery. Qualunque strumento diventi abbastanza popolare diventa un bersaglio, non perché sia progettato male, ma perché è ovunque. Il lavoro della comunità di sicurezza non è solo correggere bug — è convincere le persone che "abbastanza buono adesso" potrebbe non esserlo più tardi.

Ma ecco la tensione: a volte "abbastanza buono adesso" è esattamente ciò che consente la crescita. Una startup che usa uno strumento instabile potrebbe costruire il prossimo WordPress. Impedire alle persone di costruire con strumenti imperfetti significa impedire loro di costruire del tutto.

Ciao, Vibe Coding

Avanti veloce di trent'anni. Abbiamo una nuova generazione di tool "abbastanza buoni": piattaforme di coding assistito da AI, app vibe-coded, snippet di codice generati da LLM rilasciati direttamente in produzione.

La risposta della comunità di sicurezza si sta già sviluppando. Sì, c'è preoccupazione per codice generato da AI con vulnerabilità sottili. Sì, ci sono dibattiti accesi su whether il vibe coding sia responsabile. E sì, qualcuno sta assolutamente rilasciando robaccia insicura in produzione.

Ma ciò che i critici non cogliono: il vibe coding sta facendo esattamente quello che fecero gli script di Matt. Sta permettendo a persone che non sono sviluppatori professionisti di spedire prodotti funzionanti. Un solopreneur può ora costruire un'app web funzionante in un pomeriggio. Non è niente? È la democratizzazione della creazione stessa.

La domanda non è se le app vibe-coded siano sicure. Spesso non lo sono. La domanda è se i benefici dell'accessibilità superino i compromessi sulla sicurezza. E la storia suggerisce che la risposta sia complicata ma generalmente positiva — con la precisazione che servono tool migliori, default migliori, e educazione migliore.

La storia del Domain

C'è un epilogo a questa storia che è particolarmente rilevante per chi considera i domain più di semplici indirizzi.

Worldwidemart.com — il domain che un tempo ospitava Matt's Script Archive — alla fine è scaduto. Per un po' ha ospitato il tipo di contenuti spam pieni di gambling che fanno venire gli incubi ai software antivirus. Poi, alla fine dello scorso anno, qualcuno ha comprato il domain scaduto specificamente per preservare la storia dell'archivio.

Qualcuno si è preoccupato abbastanza della storia del web da salvare un pezzo di essa dai cybersquatter. Vale la pena notarlo. I domain non sono solo asset tecnici — sono artefatti culturali. A volte la storia che un domain racconta conta più del suo valore SEO.

Cosa significa per te

Allora, qual è il takeaway per sviluppatori moderni, founder di startup, imprenditori tech?

Prima cosa: "abbastanza buono" ha sempre guidato l'adozione. Non scartare tool solo perché gli esperti li disprezzano. I tool che le persone usano davvero contano più dei tool che gli esperti approvano.

Seconda cosa: il debito di sicurezza si accumula. Se stai costruendo su fondamenta "abbastanza buone", capisci cosa stai ereditando. Pianifica il debito tecnico. Inserisci audit di sicurezza nella tua roadmap.

Terza cosa: accessibilità e qualità non sono nemici, ma richiedono equilibrio. L'obiettivo non è impedire alle persone di costruire — è rendere più facile costruire in sicurezza che costruire in modo insicuro. Questo dipende dai creatori di tool. Dalle piattaforme. Da noi.

Matt Wright non aveva l'obiettivo di plasmare internet. Ha solo reso disponibili alcuni script a persone che ne avevano bisogno. A volte è esattamente ciò di cui il mondo ha bisogno. Semplicemente, forse, tieni i tuoi dependency aggiornati.