Sulla vita dei (prodotti dei) nostri pensieri nel mondo reale

Oblomov — Wed, 21 Dec 2011 16:45:00 +0100

Ovvero del come le navicelle del nostro ingegno finiscono immancabilmente per infrangersi sulla scogliera della realtà: dal software alle ideologie, i motivi per cui le migliori intenzioni degenerano nel proprio opposto al momento della loro realizzazione. O anche del come le rivoluzioni spostino i problemi senza risolverli. E qualche suggerimento su come evitare tutto ciò.

Il mito del ‘nuovo inizio’

Il fresh start è una grande tentazione per chiunque si ritrovi impelagato in situazioni da cui sembra impossibile uscire: mollare tutto e ripartire da zero è un'idea che porta insita la promessa che l'esperienza finora accumulata ci possa aiutare ad evitare di impelagarci, di nuovo, nelle stesse situazioni.

La realtà è ben diversa, e non tanto perché le situazioni passate possono riemergere, possono tornare a perseguitarci: anche quando si riesce davvero a liberarcisi delle catene del passato, a ripartire con rinnovata energia da una tabula rasa, inevitabilmente le stesse problematiche si riprogono, errori simili vengono commessi, e nuovamente ci si ritrova immersi in una melassa indistricabile.

Portrait of the programmer as an adolescent

Chi ha mai sviluppato o mantenuto software di dimensioni non insignificanti conosce molto bene la problematica: si raggiunge prima o poi un punto in cui la struttura del programma diventa talmente complessa che mettere mano in un qualunque punto del programma comporta conseguenze spesso imprevedibili da tutt'altra parte; lo sviluppo diventa sempre più simile all'irrisolvibile problema del coprirsi con una coperta troppo corta.

Ed il meccanismo inevitabilmente evolutivo di sviluppo del software porta il software stesso ad assumere una struttura intricata, contorta: vi sono aree che nessuno sano di mente guarderebbe nemmeno, meno che mai ardirebbe metterci mano: sembrano funzionare, e solo un pazzo potrebbe richiedere una migliorìa, una nuova funzione che le coinvolga. Eppure, queste situazioni sono e diventano insostenibili. Le migliorie sono richieste, i problemi devono essere sistemati. E qual è il modo giusto di uscirne?

La tentazione è, inevitabilmente, quella di riscrivere il software da zero: forti dell'esperienza della precedente versione, si sarà sicuramente in grado di rendere tutto pulito, funzionale e mantenibile. Questa idea è talmente integrata nel pensiero dell'ingegneria del software che plan to throw one away è uno degli argomenti più famosi e discussi di The Mythical Man-Month.

Un programma abbastanza famoso che ha subìto questo processo almeno due volte (e che si appresta a cadervi per la terza volta) è Mozilla Firefox. In origine era la Mozilla Suite, nata dalle ceneri del Netscape Communicator e riscritta in parte anche per eliminare le parti che non potevano essere rese pubbliche per motivi di licenze e brevetti. La sua pesante lentezza portò alla scelta di smembrare le varie componenti della suite (browser, posta elettronica e newsgroup, chat, editor per pagine web) in programmi separati ed independenti, ridotti al minimo indispensabile, con supporto per le famose ‘estensioni’ per chi vi desiderasse maggiore funzionalità.

Eppure, a sette anni dalla sua nascita, il ‘piccolo e veloce’ erede del browser della Mozilla Suite si ritrova ad essere talmente grosso e pesante da non poter essere più nemmeno compilato su Windows a 32-bit, nonostante i ripetuti e continui tentativi di evitare la sua abnorme crescita di dimensioni.

Che cosa è successo? Come brillantemente spiega Joel Spolsky, ricominciare da zero è qualcosa che non si dovrebbe mai fare. Il motivo per cui anche il software progettato nel modo più elegante possibile finisce immancabilmente per diventare un'accrezione inguardabile di spaghetti e polpette pelose è che anche il software progettato nel modo più elegante deve funzionare nel mondo reale.

Funzionare nel mondo reale, per un software, significa svolgere il proprio compito nelle più disparate delle condizioni esterne: da altri software dal comportamento imprevedibile all'utente sbadato, dalla sottoversione più sfigata del sistema operativo più diffuso al monitor con la risoluzione non-standard.

Poiché non si può imporre al mondo reale di comportarsi come il software dal design elegante presuppone che si comporti (ad esempio, nel migliore dei modi possibili), è il software dal design elegante che deve adattarsi alla disfunzionalità del mondo reale, e quindi fronteggiare i casi più strani. Ogni soluzione di uno di questi casi diventa una verruca nell'elegante progetto iniziale del software. E più a lungo sopravvive il software, più queste verruche si vanno accumulando, fino a diventare l'inguardabile obbrorio che spinge il programmatore a dire (inutilmente): basta, ricominciamo!

Ricominciare significa godersi brevemente l'illusione di un software elegante e pulito, finché la sua diffusione non lo riporta a fronteggiare i problemi risolti dalle precedenti verruche, e quindi a sviluppare, nuovamente, le stesse verruche. La riscrittura è quindi, nella gran maggioranza dei casi, una pura e semplice perdita di tempo, un procrastinare per evitare di affrontare il molto oneroso e poco piacevole compito di ripulire, con calma e pazienza, le verruche del codice.

Alla tentazione della riscrittura si cede facilmente quando la sopravvivenza del proprio software non è legato né alla qualità delle specifiche release né a ben determinate scadenze di consegna: ci si concede allora il lusso di rimandare il confronto della realtà per dedicarsi all'artistico compito di riscrivere tutto da capo, per produrre qualcosa di meno funzionale ed ugualmente prono al decadimento di ciò che si aveva prima.

Oltre al succitato Firefox, altri software si sono più volte trovati nelle stesse situazioni: Gnome, ad esempio, per il quale Jamie Zawinski ha coniato il termine CADT, Cascade of Attention-Deficit Teenagers; o alcune delle famose piattaforme ‘beta’ di Google.

La scelta del termine “adolescenziale” per caratterizzare questo comportamento è, a mio parere, molto azzeccata, giacché racchiude brillantemente sia l'entusiasmo, la passione, l'energia e l'idealismo con cui la riscrittura viene affrontata, sia la totale deresponsabilizzazione nei confronti dei compiti sgradevoli e tuttavia inevitabili (ma rimandati a forza): mettere in ordine ~~la stanza~~ il codice, ripulirlo e disinfestarlo.

E la cosa che rende perplessi è che, se anche è vero che nel mondo del software libero abbondano i contributi degli adolescenti, la stessa attitudine si riscontra anche in sviluppatori che dall'adolescenza dovrebbero essere già usciti da qualche decina d'anni.

Pratiche ideologiche

Ma non è solo nel software che l'istinto a ricominciare piuttosto che a risolvere problemi si fa sentire. Mi interessa qui soffermarmi quindi su un altro campo in cui l'abitudine imperversa: quello della politica, del sociale, dell'economia.

Come ho già avuto modo di dire, non si può criticare un'idea, un ideale, un'ideologia, una teoria per induzione da una sua implementazione specifica. È anche vero, d'altronde, che è proprio nel momento in cui dall'astratto si scende nel concreto, nel reale, che l'ideale si trova a dover fronteggiare tutte quelle questioni pratiche che si è potuto risparmiare rimanendo nella mente dei (‘grandi’) pensatori, nelle pagine dei filosofi, nelle chiacchiere dei rivoluzionari da poltrona.

La forma che prende il mito del ‘nuovo inizio’ in questo contesto è infatti quella della rivoluzione, un cambiamento drastico e decisivo, spesso violento, per abbattere il vecchio e sostituirlo con il nuovo.

Quante società attuali possono dire di non aver avuto rivoluzioni, nemmeno una volta nella loro storia? Spontanee “dal basso”, pilotate “dall'alto”, le rivoluzioni sono state in ogni tempo ed in ogni luogo il giunto del tentativo del cambiamento, della riscrittura della politica, della società, dell'economia di un popolo, di uno Stato, di una nazione.

Alla cancellazione, spesso violenta, della verrucosa e pelosa faccia dell'opprimente, insopportabile intoccabile obbrobrio (pars destruens) si è cercata di far seguire la costruzione (pars construens) di una nuova, elegante, giusta, equa, sana alternativa. A volte ci si è riusciti a spingere sorprendentemente lontani, in questo, prima che la realtà raggiungesse i rivoluzionari, e li costringesse ad affrontare quegli scomodi piccoli problemi concreti che nella loro utopica progettazione non avevano considerato —o peggio, avevano considerato diversi da quello che la realtà gli presenta infine.

E così i fortunati che non sono ricaduti in breve tempo nell'obbrobrio che avevano cercato di cancellare, si ritrovano a sviluppare verruche e peletti che deturpano l'ideale, allontanando l'implementazione dallo splendore in cui era avvolta finché rimasta nella mente. E magari con nuove facce, con nuovi nomi, magari persino con mimetici modi diversi, si ricostruiscono quegli stessi rapporti, quelle stesse strutture che si era tentato di cancellare e sostituire.

Tutto questo perché alla fine, nel concreto, anche la più pura delle ideologie dovrà affrontare egoismo, avidità, ingordigia, tradimenti, debolezze, violenza, schadenfreude, sadismo, vittimismo, disinteresse, protagonismo, ed ogni altro neo che da sempre caratterizza l'essere umano nella sua essenza. Ed un'idea che non sia basata su questo sin dal suo concepimento non ha alcuna speranza di sopravvivere, concretamente, nel mondo reale1.

E se l'unico modo di reagire a questi mutamenti, questi allontanamenti dall'idea, è con nuove rivoluzioni2, portando ad una condizione di rivoluzione permanente (o quanto meno ciclica) della quale la Grande Rivoluzione Culturale di Mao voleva essere l'esempio, non si è in una situazione dissimile dal CADT nel software: un sistema che può matenersi solo attraverso le rivoluzioni è, sostanzialmente, adolescenziale3 (nonché insostenibile)

Se anche una strategia rivoluzionaria fosse l'unica strategia possibile per l'implementazione di un particolare sistema sociale, politico, economico, perché essa sia veramente valida (e perché il sistema stesso lo sia), è indispensabile che la “spinta rivoluzionaria” non si esaurisca con il raggiungimento dell'“adolescenza”: è essenziale che la strategia porti la realizzazione fino alla piena maturità, che la consolidi, che la rafforzi, che la mantenga.

L'importanza di essere soft(ware)

Come detto sopra, nel caso del software non è (quasi) mai una buona idea buttare tutto e ripartire da zero. Piuttosto, è ben più proficuo (ma più laborioso e meno gratificante) operare con calma ed attenzione per estendere, ripulire, ristrutturare il software esistente.

È indubbio che il software si ritrova, da questo punto di vista, in una situazione privilegiata: la sua componente fondamentale (i bit che costituiscono il suo codice sorgente) non ‘invecchia’ per il semplice passare del tempo; l'obsolescenza del software non è mai una questione interna al software stesso: è legata piuttosto al variare dell'ambiente circostante: nuove librerie, nuovi sistemi operativi, nuove interfacce, e la necessità di adattarsi a questi mutamenti esterni.

Per contro, qualunque progetto sociale, politico o economico si trova a dover affrontare non solo pressioni esterne dovute alle condizioni ed ai cambiamenti dell'ambiente circostante, ma anche, come già accennato, pressioni interne dovute al naturale mutare delle società (non foss'altro che per il susseguirsi delle generazioni), con trasformazioni che, a seconda delle prospettive, possono essere viste come evoluzione o devoluzione, come progresso o come regresso, ma che immancabilmente si presentano.

Vi è un'altra sostanziale differenza che avvantaggia il software sugli ideali sociali, politici ed economici: la distinzione tra utenti ed implementatori.

Nel caso del software, gli utenti sono generalmente un gruppo diverso da (e tipicamente molto più vasto di) quello di chi crea e mantiene il software: anche se è generalmente consigliato consumare il proprio prodotto (ovvero che chi scrive il software ne sia anche utente), la maggior parte dei programmi hanno un bacino di utenza che va ben oltre quello dei suoi sviluppatori. Per contro, gli utenti di un qualunque sistema sociale, politico o economico ne sono per necessità anche gli implementatori, che ne traggano profitto o che ne vengano sfruttati, che vi partecipino volontariamente o che vi siano costretti, che ne siano gli ideatori o le vittime.

Nel caso del software, la distinzione tra utenti ed implementatori rende complessa la questione della sua esistenza, che si presenta in diverse combinazioni di forme. Finché rimanga un implementatore che si prenda cura di correggerne gli errori, di adattarlo alle variazioni dell'ambiente circostante, il software è mantenuto. Finché rimanga un utente che lo utilizzi (anche a costo di sforzi di vario livello per mantenerne invariato l'ambiente operativo), il software è utilizzato. Un software può essere mantenuto ed utilizzato (‘vivo’), utilizzato ma non mantenuto (‘obsoleto’ o ‘obsolescente’), mantenuto ma non utilizzato (praticamente un'endospora, pronto a risorgere non appena qualcuno ne (ri)scopra l'utilità e (ri)prenda ad usarlo).

Questa stessa distinzione permette la maturazione del software, la sua crescita e la riparazione dei suoi problemi, in modi sostanzialmente ‘indolori’ per l'utente: le modifiche possono essere collaudate prima di venir distribuite all'intero bacino di utenza, cambiamenti strutturali importanti (che semplificano futuri interventi sul software stesso) possono avvenire senza che siano percettibili agli utenti4, pur rendendo la loro esperienza indirettamente migliore, e così via (ovviamente, il fatto che questi mutamenti possano avvenire in maniera indolore per l'utente non vuol dire che nei fatti sia sempre così —non tutti coloro che mantengono software hanno la pazienza di lavorare nella maniera meno intrusiva per l'utente).

Per contro, l'identificazione tra utenti ed implementatori dei sistemi sociali, politici o economici ne semplifica in maniera drastica le condizioni di esistenza (essi esistono finché c'è gente che li pratica), ma ne complica le possibilità di sviluppo. Questi sistemi si trovano così in una situazione quasi paradossale, essendo da un lato soggetti a mutamenti interni ‘involontari’ e non controllati, e avendo dall'altro grandi difficoltà a gestire i mutamenti intenzionali (chi vuole il cambiamento? qual è il suo ruolo nell'attuale sistema? come può agire per modificarlo?).

E la ciliegina sulla torta è il fattore di scala: mentre un software può (almeno potenzialmente) crescere ed espandersi fino ad accontentare le esigenze di tutti (si pensi a come Linux, nato con l'unico obiettivo di funzionare sul computer personale di Linus Torvalds, sia cresciuto fino a coprire una gamma di hardware che va dai tostapane ai supercomputer, senza mai essere stato riscritto da zero), non credo si possa trovare un sistema sociale, politico o economico che possa soddisfare chiunque.

Non è difficile capire che proprio da questo nasce la frequenza delle rivoluzioni, nonostante la loro apparente inefficacia sul medio/lungo periodo.

Anche la scala temporale gioca fortemente a favore del software: i tempi di evoluzione tanto dell'ambiente circostante quanto del software stesso sono infatti estremamente rapidi, l'obsolescenza si gioca nell'arco di anni, e molti dei ‘padri fondatori’ dell'informatica moderna sono ancora vivi; per contro, le scale temporali per la società, la politica e l'economia sono molto più lunghe: si misura infatti in decadi, persino generazioni quello che nel mondo del software si misura in mesi, al più anni. Spesso, il promotore di un'idea non giunge nemmeno a vederne la prima implementazione, mentre nel mondo del software l'ideatore è spesso il primo implementatore.

Trasformazioni senza rivoluzioni

Nonostante le suevidenziate differenze, c'è a mio parere una importante lezione che si può apprendere dalla capacità del software di maturare senza rivoluzioni (o forse due lezioni, ma talmente legate l'una all'altra da poter essere considerata un'unica lezione).

Vorrei partire per l'occasione dal noto paradosso della nave di Teseo, la nave in legno del mitico eroe greco, mantenuta negli anni sostiuendo di volta in volta le parti deteriorate con nuove, uguali. Quando l'ultimo pezzo originale fu sostiuito, la nave era ancora identica alla nave di Teseo, ma non era più, materialmente, la stessa nave. Il paradosso verte su una questione ontologica (la nave dopo l'ultima sostituzione è o non è ancora la nave di Teseo? e se non lo è, quando ha smesso di esserlo?), ma a noi interessa solo come base per una problematica più sofisticata.

Dopo tutto, se la nave deve essere mantenuta in qualità operativa, perché non approfittarne per sfruttare il progredire delle scienze navali per migliorarla di volta in volta? Ovviamente, lasciando che ad ogni sostituzione, ad ogni aggiunta, ad ogni intervento il naviglio rimanga funzionante. E magari, secolo dopo secolo, la nave di Teseo si trasforma nel Pelican 5.

Volendo, il processo potrebbe continuare, o prendere strade diverse, magari trasformando la nave in un mezzo anfibio, ed infine perfino in un veicolo terrestre, qualcosa di completamente diverso.

Quando non si scade nel CADT è proprio questo l'approcio con cui viene mantenuto e sviluppato il software: un progredire da uno stato al successivo, mantenendo costantemente (quanto possibile) la piena funzionalità; un mutare che potremmo definire organico per la sua somiglianza con i processi evolutivi noti in biologia (anche se nel caso del software è ovviamente più corretto parlare di Intelligent Design piuttosto che del classico evoluzionismo per selezione naturale).

È grazie a questo tipo di processi che certo software è sopravvisuto, funzionale, fino ai nostri tempi, pur avendo origini che risalgono ad una trentina d'anni fa (che in termini informatici sono tempi lunghissimi).

Ed è questa la prima ‘lezione’ che si può apprendere dal software: non a caso, i più profondi e duraturi mutamenti sociali, politici ed economici (pensiamo ad esempio alla nascita della borghesia, o al relativo svilupparsi del sistema capitalista, prima della sua formalizzazione ed istituzionalizzazione) sono spesso avvenuti in una maniera che potremmo ugualmente dire organica, senza soluzioni di continuità dai sistemi precedenti, piuttosto che imposti dopo la cesura netta di una rivoluzione (quando rivoluzioni ci sono state, esse sono piuttosto state a posteriori, per stabilire nuovi equilibri di potere all'interno dei nuovi sistemi).

Pur quando spontanei, questi mutamenti hanno incontrato resistenze anche violente da parte dei sistemi all'interno del quale si sono sviluppati, resistenze vinte anche con la violenza, ma in definitiva con l'abitudine, con il lento diffondersi delle nuove formæ mentis necessarie per accettarli. Un mutamento sociale, politico, economico si stabilizza, giunge a maturazione quando non è più considerato qualcosa di nuovo, ma “come le cose ci si aspetta che siano”, diventando così “invisibile” alla percezione quotidiana dei suoi utenti/implementatori, ovvero quando è accompagnato da un opportuno mutamento nella psicologia collettiva (predominante).

Questo, per inciso, ci dice qualcosa di più del (tutto sommato banale) fatto che per avere successo una rivoluzione deve avere l'appoggio della popolazione: ci dice che se le idee alla base della rivoluzione non sono già state assimilate dalla popolazione, la rivoluzione sarà di breve durata, riuscita magari soltanto per un elevatissimo grado di esasperazione raggiunto dalla popolazione, che però a mente fredda, finite le agitazioni, si ricorda di non amare le nuove idee più della precedente condizione (purché non esasperata). Ci dice che perché una rivoluzione abbia successo, e perché i suoi effetti permangano nel tempo (piuttosto che essere una valvola di sfogo per poi portare nel tempo ad un ritorno alla condizione precedente, in una sinusoide di esasperazioni, distruzioni, restaurazioni, esasperazioni), è necessario che le sue idee siano già diffuse —ed accettate— dalla popolazione prima che la rivoluzione avvenga.

La prima lezione ci dice quindi che le idee con maggiori garanzie di successo sono quelle che maturano e si diffondono gradualmente. La seconda lezione che il software può dare è strettamente legata a questo, ma può anche essere esposta in maniera indipendente.

Come detto sopra, per potersi affermare e maturare nella pratica, un'idea deve poter sopravvivere anche a condizioni avverse, come il software deve potersi interfacciare con una moltitudine di ambienti diversi, per poter essere utilizzato in una variegata gamma di situazioni.

Con questa prospettiva, ad esempio, le idee di Trotsky sulla impossibilità del socialismo di un solo Paese, per quanto possibilmente ben motivate pragmaticamente, davano allo stesso tempo al socialismo (o quanto meno alla sua idea di socialismo) una vena di immaturità: se il suo ideale poteva essere raggiunto solo se lo fosse stato da tutti contemporaneamente (o comunque in un breve lasso di tempo), diventava abbastanza evidente che tale ideale era, di fatto, irragiungibile.

Per contro, la possibilità di mettere in pratica un'idea anche in condizioni avverse è una forte indicazione di maturità, nonché un punto essenziale per almeno due ottime ragioni: la prima è che, molto banalmente, la sua messa in pratica funge da “banco di prova” per l'idea6; ed in più, l'implementazione circoscritta diventa la giusta piattaforma per la diffusione dell'idea stessa.

Vediamo più in dettaglio la prima delle ragioni.

Il passaggio dalla teoria alla pratica richiede un lavoro di tipo ingegneristico, dove le conoscenze sui meccanismi puri si devono scontrare con la natura grezza della realtà. Nello sviluppo di un prodotto, che sia un software o un oggetto fisico, il lavoro procede sempre per gradi: dai principî più astratti (le leggi della natura secondo la nostra conoscenza, i concetti fondamentali dell'informatica) si passa ad un tentativo di design astratto (un progetto o un algoritmo), seguito a sua volta da uno o più prototipi, fino a giungere alla creazione del prodotto finale.

Ciasuno di questi passaggi, dall'idea più astratta alla sua implementazione concreta destinata all'utenza finale, svela una nuova serie di effetti, di influenze inattese, di fenomeni sconosciuti o trascurati, che richiede spesso una ripetizione, un ritorno a fasi precedenti del progetto, affinché le nuove conoscenze acquisite sugli effetti della realtà sull'implementazione dell'idea possano essere presi in considerazione.

Questo graduale lavoro di raffinamento e maturazione, che procede inevitabilmente per tentativi ed errori, è esattamente quello che manca in buona parte dei grandi progetti rivoluzionari. Mettere in pratica “localmente” un diverso sistema sociale, politico o economico diventa così l'equivalente dello sviluppo del prototipo: non riuscirà a svelare tutti i problemi che si manifesterebbero in un'implementazione su larga scala, ma potrà già dare parecchie idee su quali ostacoli un'implementazione “definitiva” dovrà superare, su quali problemi (reali) non erano stati presi in considerazione negli iniziali, astratti, sviluppi dell'idea, nei dibattiti che magari avevano contribuito alla sua iniziale diffusione.

Il fallimento di un ‘prototipo’ del nuovo sistema non sarebbe necessariamente (quante volte lo ripeterò?) una prova dell'inadeguatezza dell'idea, ma sarebbe comunque una preziosa esperienza che nello sviluppo dell'idea dovrebbe essere presa in considerazione (perché l'implementazione ha fallito? cosa è stato fatto di sbagliato? cosa non era stato previsto?), a patto che l'analisi venga fatta con mente critica (e non quindi, ad esempio, sbarazzandocisi dell'esperienza negativa scaricando la colpa sulle condizioni avverse —anzi, il punto è proprio quello di far funzionare l'idea già in quelle condizioni, piuttosto che nelle condizioni ideali che gli si prepara nella mente).

Per contro (e si giunge così alla seconda ragione), il successo di un simile ‘prototipo’, soprattutto se in condizioni avverse (quindi contro la naturale resistenza di un sistema allo sviluppo di alternative), diventa già un'indicazione della bontà dell'idea stessa, nonché uno strumento utile per la sua diffusione. Una cosa è infatti dire «la mia proposta è migliore di ciò che abbiamo adesso, perché io penso che le cose andrebbero meglio» (semplicemente in base ad elucubrazioni mentali che magari sorvolano, per disattenzione o ottimismo, su come la realtà complicherebbe le cose), una cosa è poter dire «la mia proposta è migliore, e posso dirlo perché la vivo quotidianamente (nel mio ristretto ambito) e funziona bene».

Così il prototipo del nuovo sistema avrà occasione di estendersi dal condominio in cui vivo con i miei amici a quello dirimpetto, per poi diffondersi a poco a poco in tutto il quartiere, e così via. Con l'espandersi dell'influenza del prototipo, interverranno fattori di scala che nella piccola implementazione locale non erano significativi, ovvero perché, più banalmente, ciò che funzionava bene per me ed i miei amici potrebbe non funzionare ugualmente bene per qualcun altro: ed è qui che il filone di questa seconda lezione che si può imparare dal software (ma in realtà dall'ingegneria in generale) converge con il primo: i nuovi problemi che emergeranno con il fattore di scala non devono portare a cancellare tutto e ripartire, bensí ad aggiustare il nuovo, prototipale sistema per tenere conto delle nuove problematiche.

La crescita del nuovo sistema secondo queste righe è la chiave per una trasformazione che possa giungere a maturità, perché è un meccanismo che porta alla diffusione dell'idea, ed al suo riconoscimento, prima (e auspicabilmente anche senza) che il cambiamento diventi repentino e violento. Un sistema che non dovesse riuscire a diffondersi e a ‘prendere’ in questo modo, molto difficilmente avrebbe successo, su qualunque scala temporale, in un tentativo di imporlo con una violenta rivoluzione.

Beninteso, questa strategia è tutt'altro che semplice da seguire. Al contrario, direi che proprio per questa essa non viene, normalmente, seguita: il lavoro che richiede è ben più pesante, nonché duraturo nel tempo, e molto meno gratificante e soddisfacente del lavoro di concetto del pensare i nuovi sistemi, o del farne propaganda verbale, o del semplice criticare i sistemi esistenti.

È altresì beninteso che vi sono contesti sociali, politici ed economici in cui un approccio di questo genere è quasi inevitabilmente destinato ad una violenta e sanguinosa repressione: se è vero che nei contesti più fortunati basterebbe impostare la strategia nei termini meno (espressamente) antagonisti possibile nei confronti del sistema esistente, è anche vero che in altri contesti qualunque accenno ad un'alternativa viene soffocato nel silenzio quando non nel sangue7.

In altre parole, vi sono indubbiamente casi in cui una rivoluzione è necessaria già solo per avere la possibilità di costruire un'alternativa (persino nel software, con la sua posizione altamente privilegiata, vi sono casi in cui le riscritture si devono fare); ma l'errore di fondo è pensare che solo con una rivoluzione l'alternativa possa prendere il sopravvento: più spesso che non, questo diventa solo una scusa per non fare nulla per costruire l'alternativa in cui si dice di credere.

Un esempio: FLOSS

Un esempio molto interessante delle ‘rivoluzioni lente’ di cui ho parlato finora viene sempre dal software, ma ha interessanti implicazioni anche su società, politica ed economia.

Nello specifico, mi riferisco al software libero e all'open source, concetti messi in pratica con successo negli ultimi venti/trent'anni, e che hanno alle spalle anche movimenti fortemente ideologici.

Il movimento del software libero nasce con GNU e con la Free Software Foundation verso la metà degli anni '80. Specificamente, GNU nasce con l'obiettivo di creare un'alternativa libera a Unix. Per evitare ogni questione legale, i programmi GNU vengono scritti da zero, piuttosto che modificando software non-GNU equivalente.

Da poco prima, un'altra alternativa a Unix è in via di sviluppo presso l'università di Berkeley, in California, sotto una licenza (BSD, Berkeley Software Distribution) che permetteva il riutilizzo del codice anche in prodotti commerciali. Per contro, per il software GNU viene sviluppata una licenza specifica, la GPL, con lo scopo di garantire che ogni derivazione del software libero ed aperto rilasciato con quella licenza rimanesse ugualmente libero ed aperto.

È interessante qui vedere le differenze ideologiche tra i due approcci (BSD e GPL), nonostante entrambi, a modo loro, vogliano garantire ‘libertà’: nel primo caso, la libertà arriva fino a permettere derivazioni non libere, nel secondo si proibiscono le derivazioni non libere. In qualche modo, entrambe le licenze manifestano uno spirito libertario (formalizzato come richiesto dalla compatibilità con il contesto in cui sono nate), ma in maniera profondamente diversa l'una dall'altra.

Ma è solo con la nascita di Linux che il software libero e l'open source cominciano a diffondersi: se anche è vero che le questioni ideologiche hanno avuto un loro peso, è soprattutto la gratuità del software, e la sua resilienza agli attacchi informatici cui è soggetto il software commerciale dominante (sistema operativo ed applicativi della Microsoft) che gli permettono di diventare quasi una moda, se pure ‘da alternativi’.

Software il cui uso era fino ad allora rimasto principalmente tra le mani di sviluppatori (e quindi gente capace di ‘metterci le mani’ in caso di problemi, e che grazie alla natura aperta del software stesso ne aveva la possibilità) comincia così a diffondersi oltre l'ambito circoscritto di utenti selezionati, ed incontra i primi problemi: da un lato, la propria natura tecnica raramente adatta ad utenti per cui “internet è la e blu sullo schermo” (non erano ancora i tempi di Facebook), dall'altro la necessità dell'interoperabilità con l'ambiente (sempre più ostile) della monocultura dominante: poter scambiare file con utenti Microsoft Windows, poter leggere e scrivere documenti in Microsoft Office, a volte persino poter utilizzare programmi per Windows che in Linux non hanno equivalenti.

Ci sono voluti una ventina d'anni prima che il paziente lavoro di migliaia di persone giungesse a dare la possibilità a buona parte degli utenti non specializzati la possibilità di vivere senza Windows. Ovviamente, che questa possibilità sia sfruttata o meno è un altro discorso.

Se da un lato la possibilità di interoperabilità è offerta dagli sviluppatori di una variegata gamma di software (dal già citato Firefox per navigare in Internet all'ex-OpenOffice —ora LibreOffice— per i documenti, dal Samba con cui condividere file in rete con macchine Windows al Wine per eseguire programmi Windows all'interno di un sistema Linux), sul fronte della familiarità per l'utente il lavoro forse più significativo è stato svolto da Canonical con il famoso Ubuntu.

La storia di Linux e del software open source fino ad ora è un esempio brillante di come un graduale lavoro di sviluppo ed espansione può portare la novità da qualcosa di circoscritto a pochi intimi ad una diffusione quasi popolare (significativo l'esempio delle edicole, passate dall'offire la rivista di fumetti Linus quando si chiedeva una rivista su Linux all'offrire una rivista su Linux se non si specifica che per Linus si intende la rivista di fumetti), arrivando persino a minacciare l'enstablishment8.

Peraltro, anche se la questione ideologica non è stata principale nella sua diffusione (anzi, ha comportanto l'insorgere di non pochi ostacoli per la sua adozione in ambiti aziendali e governativi; anarchia e comunismo, in certe parti del mondo sono ancora parole minacciose: e cosa c'è di più anarco-comunista del software libero e dell'open source?), la diffusione del software ha portato una crescita dell'attenzione verso la possibilità di ottenere prodotti di grande qualità con approcci di tipo molto diverso da quelli del sistema economico predominante: il software libero e l'open source diventano la porta per una possibile trasformazione proprio di questo sistema.

È anche interessante notare però che gli stessi fautori della fase di maggiore espansione della diffusione del software libero hanno anche più recentemente commesso uno dei più grandi errori di cui si è parlato in questo articolo: gli ultimi passi compiuti da Canonical (ma anche da Gnome) in termini di interfaccia utente sono infatti l'esempio di come non si fanno le cose.

Spinti non si capisce bene se dalla voglia di emulare MacOSX o semplicemente dal desiderio di creare qualcosa di nuovo ed originale (dopo anni di accusa di “copiare” Microsoft, quando le interfacce diverse venivano disdegnate perché “non familiari” —una situazione dalla quale non si può uscire vincitori), sia Ubuntu con Unity sia Gnome con la nuova Gnome Shell hanno rivoluzionato l'interfaccia utente, imponendo la novità senza possibilità di (o richiedendo notevoli sforzi per) tornare a qualcosa di più familiare.

A prescindere dalla qualità del nuovo approccio per l'interfaccia grafica, le modalità con cui questa è stata imposta sono esattamente l'opposto di ciò che è opportuno per aiutarne la diffusione: la risposta tipica non è stata «ok, ormai c'è questo, adattiamoci», bensí «mamma che schifo, vediamo cosa posso fare per non averci nulla a che fare», con il risultato che la gente è corsa a cercare alternative più familiari, lasciando Gnome per KDE, o Ubuntu per Linux Mint.

Così Ubuntu e Gnome, diventati (per merito) sinonimi del Linux accessibile agli utenti meno smaliziati, con questa scelta e la conseguente necessità di cercare un'alternativa hanno forse inflitto alla possibilità di espandere ulteriormente la base utente il loro colpo più grave.

Un esempio: Humble Indie Bundle e Louis CK

Un altro esempio di idee che nel loro piccolo possono promettere grandi cambiamenti senza bisogno di imposizioni riguarda la vendita e la distribuzione di contenuti su Internet.

L'enstablishment in questo caso è formato dai grandi gruppi editoriali e dalle società che proteggono i loro interessi (associate nella SIAE in Italia, MPAA e RIAA negli Stati Uniti, e così via). Abituate (per ragioni storiche) ad un sostanziale monopolio sul controllo della produzione e della distribuzione su larga scala di contenuti, queste corporazioni (che mi piace definire collettivamente come mafia del copyright) sono arrivate nel nuovo millennio —dominato invece dall'infinita replicabilità delle “opere d'ingegno” e dalla possibilità di distribuirne le illimitate quantità in tempi ed a costi ridottissimi— senza riuscire ad accorgersi della irreversibilità della loro obsolescenza e dell'impossibilità di evitare la propria sostanziale inutilità a colpi di legiferazioni.

Eppure, la ‘guerra’ contro i loro abusi delle leggi sul diritto d'autore non verrà vinta con l'ormai endemica ed irreversibile (nonché impropriamente denominata) ‘pirateria’: infatti, la pura e semplice violazione delle leggi (per quanto assurde e ridicole) non fa altro che apportare giustificazioni argomentative (altrimenti dette scuse) al loro pervertirle, al loro forzarne altre (leggi che, peraltro, non riusciranno mai ad invertire l'ormai ben insediata psicologia che sta alla base della ‘pirateria’ stessa).

Invece, il vero cambiamento sarà guidato dallo sviluppo di piccole iniziative locali che riusciranno a dimostrare sfacciatamente come la pirateria stessa sia frutto (piuttosto che causa) degli abusi delle suddette corporazioni (dall'eccessività dei pezzi alle già menzionate assurde leggi).

La questione del prezzo è già stata messa profondamente in discussione da iniziative come il negozio online della Apple, seguita a breve dall'equivalente di Amazon nonché dal tentativo di emulazione di Google: ma queste iniziative spostano semplicemente il controllo dalle corporazioni attuali a pochi giganti che si presentano già da ora come le corporazioni future.

Molto più interessanti sono invece le iniziative di distribuzione diretta, la più recente delle quali è quella di Louis C.K., un famoso (negli Stati Uniti) comico che ha deciso di vendere online il proprio ultimo show direttamente dal proprio sito, all'insignificante prezzo di $5: un modico prezzo con il quale si può scaricare lo show per poterselo poi godere dove si preferisce, quando si preferisce, senza alcuna restrizione di sorta.

Secondo il terrorismo psicologico propugnato dalle attuali corporazioni dell'editoria, un'idea del genere sarebbe destinata al fallimento: quattro gatti l'avrebbero comprata, qualcuno di loro avrebbe messo il file online in una delle tante reti peer-to-peer, e tutti gli altri si sarebbero procurati il file da lì, lasciando il povero comico (e tutti quelli che hanno lavorato per lui allo show ed alla distribuzione del video) con un palmo di naso.

La realtà è stata ben diversa. Come il comico stesso ha modo di scrivere, nel giro di 12 ore i costi dell'iniziativa erano stati pienamente recuperati, con profitti pari alle spese iniziali raggiunti appena quattro giorni dal lancio dell'iniziativa. Nel giro di due settimane l'iniziativa ha passato il milione di dollari, che l'artista ha variamente distribuito per coprire le spese iniziali, dare un bonus al proprio staff, donare ad un po' di charities, lasciando il restate (al momento della ‘spartizione’, meno di un quarto del milione e passa di dollari) per sé.

Per inciso, il video è disponibile sulle reti peer-to-peer (basta ad esempio cercare il nome dello show su un qualunque motore di ricerca per torrent), ed è condiviso da non poca gente, ma questo non ha impedito al comico di farci un buon guadagno. Gli unici ad averci perso, con questo tipo di iniziativa, sono esattamente i grandi distributori, le corporazioni tanto accanite nel difendere il vecchio sistema che ne giustifica l'esistenza.

Un precedente tentativo in una direzione del genere era stato fatto dai Radiohead per il loro album In Rainbows, il primo dei loro album a seguire la fine del loro contratto con EMI: per qualche mese, l'album fu reso disponibile con la strategia del pay what you want: il cliente poteva scegliere il prezzo (anche eventualmente nullo), e scaricare le canzoni dell'album in formato MP3. Dopo la pubblicazione del supporto fisico, però, l'iniziativa fu terminata.

L'idea del pay what you want è un'idea che sta prendedo piede soprattutto tra gli sviluppatori indipendenti, programmatori che sviluppano (tipicamente) giochi senza essere legati a nessuna grande azienda. La vendita e distribuzione di questio giochi è sia diretta sia per tramite di alcune grosse piattaforme di distribuzione (come Steam o Desura).

In occasione del primo ‘compleanno’ del gioco, lo sviluppatore del gioco World of Goo ha deciso di offrire il software, normalmente venuto a $20, con libera scelta del prezzo per una decina di giorni. L'esperimento è stato valutato dallo stesso autore un enorme successo.

Proprio l'esperienza di World of Goo è stata l'ispiratrice dell'Humble Bundle, un'iniziativa che da poco più di un anno distribuisce periodicamente raccolte di giochi di sviluppatori indipendenti, al prezzo scelto dall'utente. I risultati sono molto interessanti: i pacchetti raggiungono le migliaia di vendite nel giro di pochi giorni, con introiti lordi che si aggirano sul milione, milione e mezzo di dollari (in media). Questi soldi vengono poi distribuiti tra gli sviluppatori dei giochi e, secondo proporzioni scelte sempre dal compratore, ad alcune associazioni senza scopo di lucro ed agli organizzatori del sito stesso.

Il dato più interessante nelle vendite degli Humble Bundle è forse quello che riguarda la distribuzione del numero di vendite per piattaforma (anche se il compratore può scaricare i giochi così acquistati per tutte le piattaforme: Windows, MacOSX e Linux, ha la possibilità di ‘identificare’ quale piattaforma andrà contata a fini statistici) e la distribuzione del contributo medio per piattaforma.

Risulta infatti che le vendite sono in larga misura (oltre il 50%) per Windows, con il restante 50% diviso in parti grosso modo uguali tra Linux e Mac; ma soprattutto risulta che gli utenti Linux sono i più ‘generosi’ nella scelta del contributo (con una media sopra i $10) seguiti dagli utenti Mac (media appena sopra i $5), lasciando gli utenti Windows tra i più micragnosi (media di $4 e cocci): paradossalmente, la gente più abituata ad avere legalmente software gratis è quella disposta a pagare di più per avere altro software (sempre legalmente), laddove gli utenti Windows, per i quali nella maggior parte dei casi software gratis significa anche software ottenuto illegalmente, sono meno predisposti al pagamento.

Conclusioni

I mutamenti più significativi e duraturi non avvengono con una rivoluzione violenta, ma con la graduale maturazione della psicologia della gente. I bruschi cambiamenti di direzione, in un sistema sociale, politico o economico come nel mondo dell'informatica, non possono arrivare molto lontano: nascendo dal desiderio di cambiamento senza la maturità di affrontare a fondo i dettagli pratici delle nuove idee, si ritrovano facilmente ad affrontare gli stessi medesimi problemi che si sperava di cancellare con un ‘nuovo inizio’.

Sempre dal mondo del software si possono imparare lezioni importanti su come procedere per creare e far maturare nuovi sistemi, con quella gradualità che è necessaria sia per il raffinamento del sistema stesso, sia perché la novità possa essere assimilata dalla psicologia collettiva.

Sebbene vi siano indiscutibilmente casi in cui una rivoluzione, una tabula rasa siano necessari perché si possa procedere anche solo con gli iniziali prototipi del nuovo, troppo spesso la foga rivoluzionaria nasconde solo un'adolescenziale superficialità ed uno scarso interesse verso il faticoso e poco gratificante labor limæ che costituisce la vera ossatura della messa in pratica di qualunque idea.

Alle estreme consequenze, questo comporta che un'ideologia che sia fondata su questi principî (sopraffazione, abuso, violenza, avidità, odio, etc) avrebbe molte più speranze di successo di una fondata su principî quali l'eguaglianza, la libertà, la solidarietà, ed indisponbile ai compromessi che la vita reale richiede. ↩
rivoluzioni che volendo riportare ad uno stato precedente (anche se non troppo) hanno comunque un sapore reazionario: si può essere progressisti solo una volta. ↩
e dopo tutto, cos'era la GRC se non un atto di ripicca di Mao per la propria perdita di potere? ↩
La cosa è talmente vera che per il software commerciale capita che vengano fatte modifiche estetiche all'interfaccia, senza alcuna motivazione funzionale, solo per giustificare la vendita di una nuova versione le cui vere, sostanziali differenze rispetto alla precedente sono altrimenti invisibili agli utenti. ↩
Il galeone di sir Francis Drake, dallo stesso poi rinominato in Golden Hinde dopo l'attraversamento dello Stretto di Magellano durante la circumnavigazione del globo. ↩
con l'immancabile caveat, già menzionato, che il fallimento di una implementazione (o anche di innumerevoli implementazioni) non implica in alcun modo che l'idea in sé sia fallimentare. ↩
E questo contro l'opinione diffusa in certi ambienti secondo i quali situazioni come quella della Russia —dove il solo parlare di omosessualità o transessualità può essere pericoloso— sono sostanzialmente equivalenti, in termini di oppressione, ad una Spagna dove i matrimoni omosessuali sono legalmente riconosciuti. ↩
Famose in tal senso le campagne con cui la Microsoft negava di temere il progresso di Linux, poi rivelate false dai memoranda interni noti come Halloween Documents, il primo dei quali è già del 1998, e gli ultimi dei quali rivelano le strategie infide ed al limite della legalità adottate dalla Microsoft per contrastare ad ogni livello possibile la diffusione di Linux. ↩

pages tagged maturità