Avanti i pensatori radicali!

“Sei un radicale!” Quando ero un adolescente scontroso e polemico, mio padre intendeva questa frase come una critica. Nel mondo in cui siamo cresciuti, essere nella media era una buona cosa: bianco, maschio, un diploma superiore o una laurea presso un’università non troppo prestigiosa, un lavoro fisso, un appartamento ipotecato, 2.3 figli e una tessera del sindacato. L’obiettivo era essere una persona seria, e come tale protetta dall’ombrello della NATO e del welfare state europeo.

Il sogno di stabilità e inclusione sociale di una buona fetta della popolazione (certo non di tutta) è stato bello finché è durato. Ma sembra che l’egemonia della cultura moderata abbia condotto a una conseguenza imprevista: l’incapacità collettiva di riconoscere l’ascesa di problemi globali (disuguaglianze terribili, riscaldamento del pianeta, il rinselvatichimento dei ricchi e la società della sorveglianza) e affrontarli in modo credibile, pensando al di fuori dagli schemi. Non è tanto un problema di conoscenza (anche se certo, ci serve più conoscenza): per almeno alcuni di questi problemi abbiamo risultati scientifici indiscutibili, come ha osservato Stewart Brand (vedi anche il video qui sopra). La capacità cognitiva dell’elettore mediano, quello che fa vincere le elezioni… quella no, non l’abbiamo.

Che fare? In termini di velocità di reazione e rapporto risultati-risorse, credo che l’opzione di gran lunga la migliore sia mettere in campo i pensatori radicali. Esistono, e costituiscono una riserva di pensiero non utilizzata: come ha scritto di recente Vinay Gupta, molti dei problemi veramente importanti per l’umanità (e quasi tutte le soluzioni candidate a risolverli) occupano i pensieri e le giornate di molte persone interessanti. Quasi tutte sono povere, perché i loro progetti sono fuori dalla sfera finanziabile (con questo termine, Vinay intende l’insieme di quelle idee e progetti che i decision makers di buon senso nel mondo accademico, nel settore privato e nel governo ritengono “seri” e quindi meritevoli di attenzione). Questa riserva potrebbe essere messa a valore per mettere in piedi una risposta di policy in qualche modo evolutiva: dare a queste persone lo spazio per collaudare le loro soluzioni, provandone molte, ciascuna in un ambiente ben controllato e con risorse economiche limitate. Provare tutto: geoingegneria, colonizzazione dello spazio, autosufficienza energetica di piccole comunità, reputazione al posto del denaro. Scartare le cose che non funzionano, e investire su quelle che funzionano. Ripetere. Nassim Taleb lo chiamerebbe “posizionarsi per intercettare i Cigni Neri positivi“: ciascuna di queste idee ha una piccola probabilità di produrre benefici enormi, quindi ha senso fare piccoli investimenti in tutte.

Per questa ragione, applaudo la recente mossa di NESTA (l’agenzia britannica per la scienza, la tecnologia e le arti) di cercare e raccogliere intorno a se i pensatori radicali che potrebbero trasformare la società britannica. A quanto ne so, è la prima volta che la parola “radicale” viene usata in un’accezione positiva in un contesto di politiche pubbliche. Non mi sorprende che sia stata NESTA a farlo: il suo direttore, Geoff Mulgan, è uno dei policy makers più interessanti che conosco. La call di NESTA non è molto operativa: non ci sono risorse significative, o piani espliciti di dare leve vere a questi pensatori radicali. Ma è un inizio. Prevedo un’ondata di pensiero più radicale nelle politiche pubbliche: gli scienziati e i policy makers interagiscono in modo più stretto, e un po’ della hybris dei primi rimane attaccata ai secondi. Speriamo che non sia troppo tardi.

dicembre 19, 2011     Alberto     complexity economics, Innovazione sociale, Social innovation, Wikicrazia     comment

Lo zen e l’arte della committenza dei siti web nella pubblica amministrazione: perché i burocrati dovrebbero sporcarsi le mani con la tecnologia

Negli ultimi anni ho lavorato per diverse amministrazioni pubbliche. Gran parte del mio lavoro consiste nel concepire e dirigere progetti che si svolgono prevalentemente attraverso canali Internet. Mi sembra venuto il momento di fare qualche riflessione sulle cose che ho imparato. Come sempre, le lezioni più importanti mi vengono dagli errori commessi – e quando si è trattato di fare errori non mi sono mai tirato indietro.

  • Usare software-as-service non è una buona idea, anche se ci sono eccezioni. Il mio gruppo e io abbiamo commesso questo errore con Kublai, decidendo di aprire la nostra piattaforma su Ning. Questo ci ha permesso di essere online in mezz’ora, e non è un vantaggio da poco; ma, in compenso, ha sequestrato il nostro database – costruito a spese e per iniziativa di un Ministero italiano – e lo ha messo in mano a un’azienda privata americana, per sempre. Un anno dopo Ning ha cambiato CEO e modello di business: ha sostituito la licenza aperta della sua piattaforma con una full copyright, sganciato le API e ritirato i tools di migrazione. Per potere fare un’analisi di rete Ruggero Rossi ha dovuto scrivere un web crawler – è un po’ come dovere scassinare la porta di casa propria. Ci è andata ancora bene: il servizio era gratuito (a quel tempo non esisteva il servizio a pagamento su Ning). Se l’azienda avesse chiuso i battenti e formattato l’hard disk con il database di Kublai non avremmo potuto dire niente. Non rispondevano nemmeno alle mail. Non intendo mai più prendere in considerazione soluzioni che non contemplino un database su un server a cui la mia amministrazione ha accesso root.

  • Usare software proprietario non è una buona idea, di nuovo con alcune eccezioni. È costoso ed equivale a una delega perpetua al proprio fornitore, o quasi. Se una grande software house ti scrive un software su misura di cui poi ti vende la licenza nessuno, tranne quella stessa software house, potrà mai farti la minima modifica al codice. Rischi di trovarti in una situazione di totale impotenza, in cui cambiare il colore dello sfondo o il font ti costa molto in termini di denaro (le famose “billable hours” americane, in cui tu chiami e quelli attaccano il tassametro) e attrito amministrativo. Inoltre, è politicamente discutibile: il software proprietario non è riutilizzabile da altre amministrazioni se non pagando per altre licenze, e questo non è bene, soprattutto in tempi di tagli e di (sacrosanta) diffidenza dei cittadini verso la saggezza delle amministrazioni nello spendere.
  • Questo lascia solo il software libero o open source. Dal 2007 uso WordPress in progetti pubblici; per la piattaforma di Edgeryders, più o meno terminata in questi giorni, il mio gruppo di lavoro si è avventurato in Drupal. Lavorare sul software libero può essere faticoso e frustrante. Funzionalità che sulla carta dovrebbero essere disponibili semplicemente installando un modulo o un plug-in risultano non esserlo; i tempi si allungano; la gran parte del lavoro viene assorbita dal debugging. Nel frattempo, il resto delle attività rischia di inchiodarsi. Credo che l’esperienza possa mitigare il problema, ma mai veramente risolverlo. Il software libero è per definizione organico, “sporco”, vive di hacks e non solo di soluzioni eleganti e razionali.

Nonostante i problemi, la mia esperienza di committente di Drupal si annuncia positiva, come lo è stata prima quella con WordPress. Il motivo è questo: queste piattaforme consentono, e anzi richiedono, l’emersione di una figura intermedia di “admin avanzato” tra quella dello sviluppatore e quella dell’utente. Ciò accade perché le interfacce di amministrazione di WordPress e Drupal sono intuitive e potentissime; soprattutto Drupal ti consente un controllo molto preciso sul sito. Puoi fare queries dal database, formattare il risultato e visualizzarlo su una pagina, un blocco o una mail; puoi impostare regole del tipo SE [condizione] ALLORA [azione]. Queste attività non sono programmazione, ma sono al confine. Inoltre – e qui faccio riferimento alla mia esperienza con WordPress – quando l’interfaccia di admin non ti basta più, in rete trovi facilmente tutorial e informazioni per mettere le mani in parti del codice non core: io dal punto di vista tecnico sono uno sprovveduto, ma fino a mettere le mani nel CSS del blog (e, per cose moolto semplici, tipo incollare del Javascript, nei files PHP) ci arrivo. Ci è voluto un piccolo investimento, testimoniato dalla presenza nella mia biblioteca di libri della serie “for Dummies”. Questo ti dà una libertà inestimabile: quella di sviluppare in modo anche grezzo, lanciare e poi continuare a fare piccoli cambiamenti al tuo sito man mano che il progetto evolve. Fidati: ne sentirai il bisogno, fin dal primo giorno.

Il trucco sta in questo: il ruolo di admin avanzato un po’ smanettone è perfetto per un amministratore pubblico che deve commissionare software. Arrivare a conoscere bene l’architettura di queste piattaforme e a personalizzarle in modo avanzato non significa essere sviluppatori, ma significa che puoi dialogare in modo costruttivo con i tuoi sviluppatori, avere un approccio realistico alle cose che si possono e che non si possono fare, quanto tempo ci vuole, quanto costano. Inoltre, l’admin avanzato può provare a concettualizzare i propri obiettivi in termini del software, e quindi esprimere una domanda molto sofisticata nei confronti degli sviluppatori. Per esempio, su Edgeryders è necessario ricoinvolgere continuamente gli utenti nella conversazione; questo si fa attraverso le notifiche email e il feed di attività recenti. In Drupal, queste funzioni vengono svolte da certi moduli non-core. Se l’amministratore pubblico sa questo, può chiedere non “un sito web che dia l’idea di un luogo vivo”, ma “activity stream deve loggare tipi di attività a cui normalmente non è agganciato”, che è tutt’altra cosa.

Quando ho iniziato a andare in moto, mi sono letto Lo zen e l’arte della manutenzione della motocicletta. La lezione di quel testo è questa: l’attività di guidare la moto non è veramente separabile da quella di farne la manutenzione. I motociclisti “romantici”, che non intendono sporcarsi le mani, non lo accettano, e delegano anche la più semplice delle operazioni di manutenzione a meccanici professionisti. Ma pagano il pegno dell’impotenza di quando le loro moto si fermano, e loro non sanno perché, né come fare a ripartire. Questa impotenza può essere disastrosa nella pubblica amministrazione: nei progetti che dirigo io tipicamente il costo della tecnologia incide per meno del 10% del budget, eppure se la tecnologia non funziona blocca l’intero progetto.

Conclusione. Fare committenza è impossibile se non capisci quello che stai comprando. La comunità del software libero, nella mia esperienza, è disposta a condividere la propria conoscenza, le aziende che fanno software proprietario molto meno. Se ti trovi, come me, a commissionare un semplice progetto tecnologico per il settore pubblico ti consiglio di rivolgersi a questa comunità, armarti di pazienza, e investire un po’ di tempo per sporcarti le mani con la tecnologia che poi gli sviluppatori useranno. Installa e configura siti di prova, aggiungi funzionalità, prova a cambiarne l’estetica. Passa un po’ di tempo con gli hackers. Mostrati desideroso di imparare e fai molte domande. Soprattutto, non cedere alla tentazione del “non è il mio lavoro, fallo funzionare e mandami la fattura”. Non è così che funziona. Ti richiederà molto tempo, ma sempre poco in confronto a quello che poi risparmierai una volta in produzione. Il sistema non è perfetto, ma è di gran lunga meglio delle alternative. In realtà, credo che sarebbe molto utile organizzare un corso per pubblici amministratori volto a formare committenti migliori di software libero. Qualcuno là fuori è interessato? Io parteciperei subito.

Thanks Freddy Mascheretti, Ivan Vaghi, Paolo Mainardi and Claudio Beatrice for their patience and suggestions

dicembre 5, 2011     Alberto     e-government 2.0     16 comments

   


© Contrordine compagni - Wordpress-Theme 0816 by Netprofit Webdesign & Robert Hartl and personalized by Freddy