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
Ning è Platform as a Service, non Software as a Service. Pare un sofismo ma il SaaS è roba che gestisci tu anche se offerta come servizio. Mentre il PaaS è di terzi e quindi paghi pegno come da te descritto…
Grazie della precisazione, Marco. Il lock-in del fornitore è comune a entrambe le formule, mentre il lock-in del database accade solo con PaaS.
Ciao, ti perseguito seguendoti ovunque. Il mio gruppo di lavoro che è composto da me (sociologo di formazione, valutatore professionista con competenze in metodologia della ricerca e supporto alla governance di progetti complessi), un prof. universitario di statistica con competenze informatiche spiccate e uno statistico con competenze informatoche significative e di metodologia della ricerca dal punto di vista statistico altrettanto significative, abbiamo sviluppato più che un SW una cosa che noi abbiamo chiamato sistema che permette di mettere insieme le funzionalità della macchina e la competenza delle persone. Esattamente lo sporcarsi le mani che tu intendi spalmato su tre teste che lavorano all’unisono per dare al cliente la miglior soluzione possibile. Quello che abbiamo creato funziona alla perfesione ormai da due anni ed è sempre in evoluzione. Se trovi/troviamo soggetti pubblici interessati a capire come si usano cose del genere e a cosa servono, io/noi siamo a disposizione per partecipare e far conoscere la nostra “invenzione” finalizzata a monitorare e valutare policy, programmi, progetti anche di grande e grandissima entità, ma non necessariamente.
Perseguitami pure! Queste persecuzioni fanno solo piacere. Tengo gli occhi aperti.
Voglio leggermi questo post con calma 🙂
Ciò che scrivi è molto utile. Tradotto nel mio linguaggio significa anche per me molto lavoro in più come committente di sistemi di dialogo tra amministrazione e privati individui. Però mi convince anche, perchè, superati (momentaneamente e temporaneamente) i costi di acquisizione di competenze, questo farebbe di me un gestore di poltiiche pubbliche molto più forte e autonomo.
Credo che apprezzerai queste slide
http://www.slideshare.net/55thinking/understand-open-source-ecosystems
Buon articolo, si capisce che è stato “vissuto”.
Non è la prima volta che mi capita di vedere una persona camminare su questo percorso o uno simile: la pratica dell’ “outsourcing totale” molto raramente paga ed infatti si capisce che sei arrivato con l’esperienza a percepire la necessità di un metodo di sviluppo di progetto differente, che probabilmente si sposa bene con ciò che gli addetti ai lavori chiamano “agile”, che tra le altre cose prevede la partecipazione attiva del cliente(senza pretendere necessariamente la presenza di power user, chiaramente).
Non so se l’hai già visto, ma probabilmente riconoscerai certi valori nel manifesto: http://agilemanifesto.org/
Ciao e grazie ancora della citazione! 😉
Conoscevo lo sviluppo agile via un’amica, che ne è entusiasta. Da quello che ho capito, ciò che i grandi corporates chiamano “sviluppo agile” nel mio mondo è lo stato di default. Grazie a te!
Una riflessione e una prospettiva interessante!
Sulla base di pensieri molto simili alcuni anni fa è nato http://www.innovatoripa.it. Uno spazio per gruppi e comunità che nascono nella PA italiana. Quando abbiamo iniziato a disegnarlo è stato naturale copiare le caratteristiche di ning e facebook, ma anche di http://www.fainotizia.it/.
InnovatoriPA è sviluppato con Drupal ed è disponibile per tutte le PA che ne facciano richiesta.
Stiamo per fare una revisione e un aggiornamento su Drupal 7, forse potremmo condividere qualche idea, funzionalità o modulo…
Buon lavoro!
Sono anche un utente di innovatoripa, anche se non lo uso da un bel po’.
Volentieri, parliamoci! Chi sviluppa per voi? Vi va di collaborare su Edgeryders?
Ma prego…. 🙂
So che ho ancora un lavoretto in sospseso da sistemarti…lo so…lo so… 😉
non posso che essere d’accordo, i software/servizi “black box” sono tanto semplici quanto pericolosi se ci appoggi sopra la tua attività/servizio/sito/.
Ultimamente mi sono cimentato timidamente con un sito di e-commerce, e il fatto di avere il controllo completo di tutto il contenuto del sito e del db non ha pari.
Basta un backup e se cade l host o emigra sulla luna, in mezz’ora lo ripristino dove voglio.
(per che fosse interessato, sto usando PrestaShop come piattaforma)
Ciao Alberto
Being my self in the position of the publict sector (even if not a public servant) sollution buyer, I agree with your points and rely myself on opensource sollution (Drupal) hosted in the Public Sector Infrastructure
Your Idea of getting your hands dirty goes very much along what I heard in one of the sessions in Drupalcon Chicago: the more and the earlier Project managers get involved deep in technology and design decisions the better for the project.
I agree with the procurement fiasco in Governement being all to often the case that the Governement itself doesnt have a clue or doesn’t want to have a clue on the technology and sollution it is buying leaving this decision either to external consultants or even to the company providing the sollution with results that are far from optimal in most of the cases.
I agree also that the opensource community has a better starting point to finding a sollution vs the company that is relying on its sollution / software to make its profit and that will try to sell it to you and lock you in it as soon as possible.
Nevertheless from my experience the opensource / Drupal development doesnt come cheap either in terms of man/hours spent. Once you need to provide deeper and finer functionality and you need to tweek the user interface to provide decent UX to users to drive adoption, you will need to get top class experienced developpers that will know how to do the trick and bend Drupal to fit your needs while keeping it portable to the next version of Drupal.
Actually the cost of doing a deeply customised Drupal website is probably the same as building it from scratch without Drupal. The undeniable advantage being nevertheless the possibility to tap into the sea of modules and functionality tweaks provided by a large community and the relative independence from your software developers. A good drupal project can be transfered to a new (as competent) team without them havingto spend weeks trying to understand what the previous team wanted to do.
I also agree with the software as a service limitations, but only in the case of the private clouds out there that pretend to be public.
Indeed a really public cloud is needed to make sure all this community energy invested on there is not hijacked by any private company that used honey-pot tacktics to then lock-in and convert free users to unhappy paying customers.
A public sector cloud (internally hosted in gov infrastructure) is also a crucial evolution point in the future of e-governement and the much needed digitisation of internal workflows and business processes and internal knowledge sharing. Too much of it still relies on just shared folders, word, excell and outlook.
Chris
Thanks for your insights, Chris. Given your experience in the field, they are really invaluable.
I fully agree we need a solid public sector cloud. While we are at it, I would add some public social web infrastructure. At that point, software-as-service would indeed look like an attractive solution.
My position on the “tweaking Ux” issue is a little more nuanced. You are clearly right when you say Drupal is famously difficult to submit to fine-tuned control. And yet, I am a little skeptical of Ux itself: somehow, it seems to be the computer version of advertising. Its philosophical assumption is that there is someone out there called “a user”. He/she is stupid, uninterested, and has a very limited attention span. He/she should not be trusted to use a piece of software responsibly. You, the person in charge, has to make it problem-free for them.
This is not wrong. But I wonder if it might be a self-fulfilling prophecy, like Taylorism in manufacturing or advertising in communication. In those cases, designing for a dumb user actually made users dumb. Drupal projects can be quite a bit cheaper than fully customized ones if you work from the technology core outwards, instead of starting from the Ux. Essentially, what you are saying is “hey, user! This is a piece of software. Help us keep costs down by taking on some responsibility for managing its complexity.” Would not this kind of thing produce a faster, more efficient human/machine system in the medium run?
Ciao Alberto,
ottimo post, pienamente condivisibile. Ne abbiamo twittato, la proposta è: riusciamo a farne diventare un’azione per l’agenda digitale di Bologna Iperbole2020?
Luca (@capitanachab)
Dipende da voi! Io se serve una mano ve la do, ovviamente.