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