Dal 1 giugno 2007 tre progetti europei di e-government costruiti su Plone — CommunesPlone (Belgio e Francia), UdalPlone (Paesi Baschi) e PloneGov.ch (Svizzera) — confluiscono sotto il nome PloneGov, e in queste settimane il modello arriva in Italia: il primo ente pubblico ad aderire è la Camera di Commercio di Ferrara. Qui interessa la regola che il content management system si porta dietro: un’applicazione che risolve un bisogno comune si scrive una volta sola e si riusa, invece di ricomprarla ente per ente.

Contesto

Tutto parte nel 2005 a Sambreville, un comune della Vallonia, dove Joel Lambillotte, allora responsabile informatico, doveva attrezzare una intranet per documenti e procedimenti e scelse di costruirla con Plone invece di comprarla. Da lì il gruppo si è organizzato come una comunità di software libero tra enti locali: ogni comune mette sviluppo, gli altri lo riusano. Le stime che girano nella comunità parlano di un investimento dell’ordine di qualche centinaio di migliaia di euro l’anno dal 2005, in larga parte tempo di sviluppatori dipendenti delle amministrazioni. Il documento OSOR riporta che il costo per singolo portale è sceso da circa 10.000 a circa 1.000 euro una volta scritta l’applicazione di base, che resta solo da personalizzare — un ordine di grandezza in meno rispetto alle cifre tipiche di una intranet proprietaria. Sono numeri indicativi, dichiarati dai membri del progetto e non da una contabilità terza.

Il coordinamento internazionale è in mano a ZEA Partners, una rete no-profit di piccole e medie imprese che lavorano su Plone. ZEA segue le operazioni cross-border, la documentazione condivisa e la comunicazione; lo sviluppo resta agli enti e ai loro fornitori. In Italia il fornitore tecnico del lancio è noze, e la prima rete di adesione comprende — oltre alla Camera di Commercio di Ferrara — l’Università e la Provincia di Ferrara, i Comuni di Modena e Arezzo, l’Unione Reno Galliera e l’ARPA Veneto. Le note di noze sull’evento di lancio italiano, ospitato dall’ente camerale ferrarese, sono raccolte in un insight dedicato: https://www.noze.it/insights/plonegov-lancio-italia/.

Architettura

Plone è un CMS scritto in Python che gira sull’application server Zope. La versione 3, uscita il 21 agosto 2007, ha portato il controllo di versione integrato sui contenuti, l’editing inline, l’editor visuale Kupu 1.4 e un modello di permessi su utenti e gruppi più fine. Per il caso PloneGov pesano soprattutto due cose di quel rilascio.

La prima è GenericSetup: un meccanismo per descrivere la configurazione di un sito — tipi di contenuto, workflow, ruoli, profili di permessi — in file XML versionabili, tenuti separati dal database dei contenuti. Un ente che ha modellato un procedimento amministrativo può consegnarne il profilo dentro un pacchetto installabile, e un altro ente lo applica al proprio sito senza ricostruirlo a mano.

La seconda è il passaggio all’impacchettamento via egg Python e zc.buildout. Qui un add-on è una libreria Python con le sue dipendenze dichiarate; un file buildout.cfg elenca gli egg da scaricare e i sorgenti da sviluppare in locale. Così un’estensione PloneGov — un tipo di contenuto per le delibere, un workflow per il protocollo — diventa un artefatto riproducibile, che si installa su un’altra istanza con la stessa ricetta di build. Su questa base tecnica il riuso smette di essere una buona intenzione e diventa una pratica: senza un formato di pacchetto e una configurazione dichiarativa, la condivisione si ridurrebbe a copiare codice a mano tra installazioni che a quel punto divergono.

I sorgenti dei moduli stanno su svn.communesplone.org sotto licenza GNU GPL, con la logica di una qualsiasi comunità FLOSS (Free/Libre and Open Source Software): repository pubblico, commit dei vari enti, applicazioni che un comune scrive per sé e che gli altri possono installare.

Punto critico

Il modello regge finché la configurazione resta esprimibile come dato versionabile e i pacchetti restano componibili tra istanze. È un equilibrio fragile. Plone consente personalizzazioni profonde via codice — override di template, viste, adapter — e ogni personalizzazione fatta fuori dal profilo GenericSetup è un pezzo di stato che non viaggia con il pacchetto e va riconciliato a mano quando si aggiorna l’add-on condiviso. Il rischio vero, in una rete di enti con esigenze locali diverse, è il fork silenzioso: ciascuno parte dalla stessa base, ci accumula sopra modifiche non impacchettate, e dopo qualche ciclo le installazioni divergono al punto che il “comune” da riusare non esiste più.

La disciplina che PloneGov chiede è quindi prima organizzativa che tecnica: tenere generica la base condivisa, isolare le specificità locali in pacchetti a parte, far rifluire a monte le correzioni invece di tenersele in casa. Le note pubbliche del progetto descrivono proprio questo — individuare i problemi insieme, documentare le soluzioni, non riscrivere lo stesso software più volte — ma è una pratica che dipende da chi la applica, non una garanzia dello strumento.

Implicazioni

Per un ente italiano il conto si verifica, non si prende sulla fiducia. La domanda non è se Plone sia il CMS migliore in assoluto, ma se un dato procedimento — un albo pretorio, una gestione documentale, una intranet di protocollo — sia già stato modellato da un altro ente della rete e sia disponibile come pacchetto installabile. Quando la risposta è sì, il costo passa dall’acquisto di una soluzione chiusa alla personalizzazione di una soluzione esistente, con i sorgenti ispezionabili e nessun vincolo verso un singolo fornitore.

C’è poi una conseguenza meno evidente sul mercato dei fornitori. Con le licenze proprietarie il fornitore rivende lo stesso prodotto a più enti; con il codice in comune vende tempo di sviluppo su un bene di tutti. ZEA Partners prova a tenere in piedi un mercato di piccole imprese su questo presupposto. Per i fornitori italiani che entrano adesso il valore non sta nel possedere il codice, ma nel saperlo modellare e tenerlo allineato alla base condivisa.

Limiti

Plone 3 ha un costo d’ingresso operativo che non si può ignorare: lo stack Zope/Python chiede competenze specifiche per il deploy e la manutenzione, e l’ente che adotta il modello deve poter contare su personale o fornitori che maneggiano buildout, gli egg e GenericSetup. Il risparmio dichiarato dai membri di CommunesPlone vale per chi resta dentro la disciplina del riuso; chi tratta l’installazione come un prodotto chiuso da personalizzare a piacere ne perde gran parte e si ritrova con un sistema complesso senza la rete che lo giustifica.

Resta da verificare sul campo italiano: la rete europea ha qualche anno di pratica alle spalle, quella italiana parte adesso. Quanti pacchetti vengano davvero condivisi e reinstallati tra enti, e quanti restino fork locali, si potrà leggere solo tra qualche ciclo di sviluppo.

Immagine di copertina: Foto di gruppo di decine di membri della comunità open source Plone riuniti alla Plone Conference 2009 a Budapest — foto di Christian Scholz, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Plone_Conference_2009_Group_Photo_-_Flickr_-_MrTopf.jpg