7 criteri di scelta per un CMS Open Source.

Funzionalità e diffusione non sono gli unici criteri per scegliere un CMS opensource. Esistono altri aspetti da tenere in considerazione. Vediamone un elenco.

Nel processo di software selection esistono degli aspetti che spesso rimangono trascurati perché eclissati da elenchi di features o dal prezzo indicato dal fornitore. Ma il successo di un progetto CMS dipende anche da altri fattori. Come se non bastasse, gli altri aspetti concorrono direttamente sul TCO (Total cost of Ownership) ribaltando completamente la cifra iniziale che si pensava di  pagare.

Licenza Software Open Source.

Logo OpenSourceLa licenza esprime le modalità in cui siamo autorizzati ad utilizzare un determinato software. La licenza regolamenta anche aspetti collaterali all’uso del software  come la copia, la sua  distribuzione e la modifica. Quando si acquista un software CMS quindi, ne si acquista una licenza d’uso.

Esistono anche delle sfumature, come la fornitura di software SaaS che anche da un punto di vista fiscale è trattato diversamente essendo considerato un servizio e non un bene immateriale come avviene per il software su licenza.

In egual misura, quando si commissiona l’implementazione di un progetto software bisogna tener conto di quali componenti software si riutilizzano e quali sono le modalità concesse per poter sviluppare nuove estensioni.

La Free Software Foundation (FSF) si è occupata di stilare un nuovo documento sui migliori criteri di scelta della licenza di distribuzione più adatta al proprio lavoro in formato digitale. 

I dettagli sono moltissimi, soprattutto per le pubbliche amministrazioni che godono di diversi vantaggi nell’utilizzare licenze Open Source come l’apertura e disponibilità dei sorgenti, il reale riuso del software, nessun incentivo a comportamenti illegali e soprattutto la creazione e fertilizzazione di un insieme di imprese ICT locali.

Ad esempio si verificano casi particolari come EUPL e GPL v3, che sono attualmente licenze FOSS – Free Open Source Software - tra loro  direttamente incompatibili. Gruppi di lavoro come eupl.it oltre ai temi di promozione e diffusione si occupano anche delle questioni sui risvolti legali nel mondo della pubblica amministrazione.

Il team di sviluppo.

Bisogna fare attenzione al team di sviluppo dietro al software CMS che state considerando. Per esempio si tratta di un progetto Open Source con una eterogenea comunità di sviluppatori alle spalle, il frutto del lavoro di una singola persona o addirittura il prodotto di una sola azienda?

Un team prima della partita

Nessuno dei casi è necessariamente sbagliato, tuttavia bisogna considerare la vita a lungo termine del software che stiamo acquistando.

Anche nel caso in cui nascano da azioni di volontari, i progetti Open Source sanno essere altamente produttivi. Questi però possono anche morire facilmente se subentrano progetti più interessanti. Se state considerando una soluzione Open Source, è opportuno saper riconoscere le persone, ovvero gli autori del codice, e da quanto tempo queste persone lavorano sul progetto e sulle tematiche relative come, ad esempio, la gestione dei contenuti fuori dal contesto software. In questo modo è possibile distinguere “progetti meteora” da quelli maturi e ormai consolidati che offrono supporto nel lungo periodo.

Nei progetti senza la presenza di un’azienda è utile capire come viene finanziato il lavoro, se ci sono finanziatori, VC, Business Angel o in generale le dinamiche di come il progetto guadagna la sua sostenibilità.

Nel caso di prodotti commerciali, bisogna fare anche i conti con l’azienda che sarà in grado di fornire assistenza su quel prodotto specifico. Meglio accertarsi anche della loro stabilità finanziaria.

In tutti i casi si dovrà fare i conti con il rilascio regolare di aggiornamenti nei confronti di questi sistemi, soprattutto per gli aspetti legati a questioni di sicurezza. Un eccessivo numero di rilasci lascia presagire alti costi di manutenzione o un software particolarmente problematico mentre, al contrario, una scarsa attività può essere indice di una poca attenzione alla sicurezza o troppe poche installazioni per avere abbastanza feedback.

Un'idea dell'attività del team di lavoro dietro ai progetti Open Source è la prerogativa di ohloh.net

Sicurezza.

La sicurezza è una questione importante per ogni content management system. Se il tuo sistema lascia spazio a interventi malevoli è possibile compromettere non solo i dati ma anche il traffico dei tuoi visitatori, ad esempio compromettendo la fiducia su questioni importanti come la privacy.

Purtroppo giudicare la sicurezza di un CMS Open Source non è semplice se non si hanno delle spiccate competenze tecniche. La cosa migliore è chiedere un’opinione che venga supportata da dati concreti e razionali e non dalla sola percezione. Attraverso una ricerca google accostando al nome del CMS “security issues”, è possibile portare alla luce gli avvisi di sicurezza per bug o anomalie riscontrare e vedere come si comporta la community di riferimento.

  • Tempi di risposta - Come risponde la community? In quando tempo queste falle di sicurezza vengono corrette?
  • Gravità - Di quale entità stiamo parlando: sono errori gravi che compromettono l’intero sistema o sono semplicemente delle anomalie?
  • Esposizione al rischio - Qual è l’esposizione al rischio? Sono immediatamente vulnerabile oppure si tratta di condizioni che si verificano difficilmente?

Una valida risorsa online per tenere d'occhio i bollettini di sicurezza è il progetto Security Focus.

Accessibilità e qualità del codice.

Un altro aspetto difficile da considerare per chi non è un tecnico è la qualità del codice scritto nel CMS. Per evitare davvero l’effetto lock-in con un fornitore promesso dal software Open Source è necessario che siano seguite delle pratiche di programmazione in grado di lasciare “in ordine” il codice e permettere ad altre persone di proseguire nel lavoro. 

Come posso valutare, in prima istanza, la qualità del codice di un progetto Open Source? Ad esempio è possibile fin da subito esaminare alcuni fattori:

  • il riuso di librerie conosciute e già utilizzate;
  • basarsi su framework o piattaforme già esistenti e testati;
  • la presenza di test automatici del codice;
  • la presenza di documentazione accurata ed aggiornata;
  • un elevato numero di contributor al codice sorgente;
  • l’adozione di metodologie di programmazione che favoriscono il riuso (programmazione ad oggetti o a componenti).

Documentazione e formazione.

Una buona documentazione è una componente cruciale nel rapporto tra autori e amministratori. Spesso succede che gli autori dei contenuti non utilizzino quotidianamente il sistema dimenticando facilmente le sue funzionalità, comprese quelle più elementari. La documentazione quindi deve essere utilizzata a supporto degli amministratori, comprensiva e facile da utilizzare. Alcuni CMS comprendono anche dei percorsi di formazione Integrata e dei video tutorial.

Inoltre è necessaria anche una documentazione specifica per gli sviluppatori. Questo permetterà al team interno di adattare il CMS alle nuove esigenze che, inevitabilmente, arriveranno. Senza questa documentazione è facile che chi arriverà dopo venga preso dal desiderio di buttare tutto il lavoro fatto finora per reimplementarlo da zero.

Oltre alla documentazione anche la formazione è una risorsa importante. Ad esempio è il modo più efficace per iniziare il percorso di primo utilizzo con gli autori, lasciando il compito alla documentazione per dubbi su questioni più specifiche. Un’esperienza formativa è anche un ottimo metodo per entrate in contatto diretto con casi concreti e know-how del fornitore, che è in grado di dare un valore aggiunto indicando più soluzioni alternative da intraprendere per lo stesso problema.

Supporto.

Per capire l’importanza di questo criterio basta farsi alcune domande. Cosa succede se identifico un bug nel mio Content Management System? Dovrò pagare affinché sia messo a posto? In quale tempo posso aspettarmi una risposta? È davvero necessaria una disponibilità 24/7?

Oltre ai bug ci sono anche altre questioni relative all’assistenza, ad esempio la possibilità di richiedere un consiglio di fronte ad una problematica che non riguarda direttamente il sistema. Questo tipo di supporto è da mettere in conto?

Chiedere un supporto dalla community non è sempre facile e soprattutto immediato. Vigono regole costruite perlopiù per chi vuole partecipare attivamente al progetto e non per chi chiede sporadici e frettolosi consigli. Dal punto di vista del supporto professionale invece, spesso lavorare con aziende più piccole sposta l’attenzione su un rapporto di assistenza più “umano” dove tra fornitore e cliente nasce un rapporto di fiducia che può compensare le piccole problematiche quotidiane. Diversamente, in grandi aziende è consigliabile prevedere la frequenza con cui si accederà a qualsiasi tipo di supporto per mettere in conto anche questo centro di costo.

Community.

Le community nascono per tutti gli individui che vogliono utilizzare quel CMS. Tra loro condividono consigli ed esperienze via forum, mailing list e siti di supporto. Le community sono particolarmente importanti per i CMS Open Source perché rappresentano l’ambiente dove si influenzano e si programmano i futuri sviluppi del prodotto. 

Foto di gruppo con twitter avatar

Una buona community è in grado di rispondere alle domande, offre supporto e si esprime continuamente con la produzione di plug-in che possono essere utilizzati con il CMS. Prima di investire in un CMS Open Source bisogna assicurarsi che abbia alle spalle una comunità attiva. 

Per scoprirlo basta visitare il sito ufficiale, capire quanti utenti ne fanno parte e lo spessore di portfolio dei membri più attivi. Esaminando il tipo di argomenti che la gente discute si può capire come vengono trattati i nuovi membri, la professionalità delle risposte e i problemi più comuni.

È facile ormai imbattersi in community “finte” o create ad-hoc per mascherare il lavoro di una singola azienda, spacciandolo per un progetto collaborativo. La differenza sta in chi decide il futuro del software: se sono i membri delle community o aziende che ne traggono un singolo e diretto profitto.

Conclusioni.

I criteri di scelta per un CMS Open Source sono diversi e non si limitano solo al costo o alla diffusione del software. Devono essere scelti tenendo in considerazione gli obiettivi di business della vostra azienda o le esigenze di comunicazione del vostro ente. Ogni criterio porta con sé dei requisiti specifici che vanno elencati per poter comprendere meglio le differenze tra i diversi software. Avendo ben chiari questi presupposti, sarà più semplice individuare il software più adatto a voi e migliorerà nettamente il rapporto con il futuro fornitore.

Share this on

Share |

On same topics

Commenti

comments powered by Disqus