Un progetto di ricerca industriale su un sistema di gestione contenuti prototipa spesso su uno stack e consegna la piattaforma definitiva su un altro. Le due fasi possono divergere parecchio, e quando succede conviene fissare cosa attraversa davvero il confine. Quasi mai è il codice del prototipo; sono le decisioni che l’hanno guidato — quali tipi di contenuto servono al dominio, come si separano gli stadi di un workflow, dove passa la linea tra ciò che è riusabile e ciò che è specifico del committente.

Contesto

In Italia i programmi del MIUR (Ministero dell’Istruzione, dell’Università e della Ricerca) per la ricerca industriale — i Pacchetti Integrati di Agevolazione, tra gli strumenti a sostegno dell’innovazione — finanziano consorzi tra imprese e atenei su orizzonti pluriennali. Il rendiconto chiede un risultato consegnabile e misurabile: per un progetto su un CMS, di norma, una piattaforma installabile e la sua documentazione. La scelta dello stack non è un adempimento; è una decisione tecnica con conseguenze tecniche, e nei trenta mesi di un progetto può cambiare in corsa.

Il prototipo Open Source

Sul fronte CMS, in questi anni, chi lavora in Python ha come riferimento Zope con il Content Management Framework (CMF), e sopra di esso Plone. Zope esce sotto Zope Public License; CMF e Plone sono Open Source e disponibili pubblicamente (Plone 1.0 è del febbraio 2003, Plone 2.0 del marzo 2004, plone.org). È un terreno su cui la prototipazione corre veloce, perché l’esperienza maturata su un CMS già in produzione — workflow asincroni, content type estensibili, export verso formati interoperabili — vi si traduce in fretta in un sistema funzionante.

Conviene fissare cosa offre lo stack. Zope poggia su ZODB (Zope Object Database), il database a oggetti transazionale in cui ogni contenuto è un oggetto Python persistente. L’acquisition — il meccanismo per cui un oggetto eredita comportamenti e variabili dal contenitore, risalendo l’albero — è il tratto che più caratterizza il modello. Il CMF aggiunge i servizi che trasformano un sito in un portale: portal_types per i tipi di contenuto, portal_workflow per stati e transizioni, portal_catalog per indicizzazione e ricerca, portal_skins per separare logica e presentazione (zope.org, documentazione CMF). I tipi non banali si definiscono a codice con Archetypes, il framework a schema attivo che dallo schema genera maschere, validazione e persistenza (la 1.3.0 RC2 è del settembre 2004). La scelta di questa base non è scontata: è il risultato di un’analisi comparativa tra i CMS Open Source dell’epoca, da eZ publish a Typo3 a Midgard.

Il punto critico

Un prototipo che gira non garantisce la piattaforma definitiva. Il passaggio dipende da fattori che con il codice del prototipo c’entrano poco. Per parte sua, lo stack Zope/CMF attraversa una rottura interna: Zope 3, uscito a novembre 2004 (Wikipedia, Zope), porta interfacce e componenti come modello di base e riscrive gran parte dell’impianto, conservando dello stack precedente quasi solo ZODB; un codice legato troppo stretto all’acquisition e alle convenzioni di Zope 2 invecchia in fretta. Ma la spinta decisiva è di contesto: una piattaforma destinata a un committente industriale viene pesata per maturità degli application server, competenze reperibili sul mercato e adozione presso i partner. Su quel metro lo stack definitivo si sposta verso Java Enterprise (J2EE), in ambito enterprise più diffuso di quanto Zope fosse in Italia a metà anni Duemila.

La migrazione di stack è una scelta legittima e frequente, e ha una conseguenza che va detta per intero: il codice del prototipo non confluisce nella piattaforma finale, e tanto meno «a monte» in Plone. Quello che attraversa il confine tra le due fasi sono le decisioni — i tipi di contenuto disegnati per il dominio, la separazione degli stadi di un workflow editoriale, la linea tra riusabile e specifico.

Implicazioni

La conseguenza riguarda la rivendicazione. Quando il prototipo è Open Source ma la piattaforma definitiva no, la tentazione è raccontare il primo come se fosse confluito nel secondo, o nell’ecosistema da cui veniva. È una semplificazione che non regge alla verifica. Le piattaforme Open Source mature — Plone tra queste — nascono dalla convergenza di molti attori sull’arco di anni, e la coincidenza temporale tra un progetto e una versione non fonda nessuna paternità. Dire che un progetto industriale «ha dato origine» a Plone è quasi sempre una forzatura; quando la piattaforma finale è migrata su un altro stack, lo è del tutto. Zope e CMF sono semmai la base comune da cui Plone è cresciuto per conto suo: un fatto dell’ecosistema, non un lascito del singolo progetto.

Resta da chiedersi cosa un progetto del genere lasci davvero. La parte verificabile sono i documenti: l’analisi comparativa che motiva la scelta della base, il disegno della suddivisione modulare, le specifiche dei moduli di workflow, sicurezza, indicizzazione XML e tassonomie. È un’eredità più sobria di una piattaforma diffusa, ed è l’unica che si può mostrare nero su bianco.

Limiti

Questa lettura vale per un consorzio di ricerca con un committente industriale e per i programmi MIUR di questi anni; non si trasferisce in automatico ad altri contesti. Dove committente e deliverable sono a loro volta Open Source, il codice del prototipo può sopravvivere davvero; dove la piattaforma definitiva passa a uno stack enterprise, ciò che resta sta nei documenti e nelle competenze, non nei repository.

C’è poi il fatto che la scelta dello stack non è solo tecnica: pesano le competenze interne, i contratti di manutenzione, ciò che i partner sanno già far girare. Un prototipo elegante su una tecnologia di nicchia perde regolarmente il confronto con una piattaforma meno raffinata che l’organizzazione sa mantenere. È una tensione reale, e si decide caso per caso.

Il percorso del progetto CMOS — prototipazione su Zope/CMF e migrazione a Java Enterprise come architettura definitiva — è raccontato sia nell’insight sia nella scheda di progetto pubblicati da noze: https://www.noze.it/insights/cmos-conclusione/ e https://www.noze.it/progetti/cmos/.

Immagine di copertina: il logo del progetto CMOS con i marchi dei partner del consorzio, Bassilichi e noze.