CMS open source, codice proprietario, framework. Facciamo chiarezza

Molto spesso chi commissiona la realizzazione di un applicativo web è più interessato al cosa debba apparire nell’interfaccia, più che al come questa sia stata realizzata e che motore ci sia sotto il cofano. È lecito, un cliente si affida a professionisti confidando che le scelte tecniche vengano prese da loro.

Ci sono però delle situazioni in cui può essere molto utile affrontare il tema della “filosofia di progettazione”, e tra queste le due principali sono:

• il cliente accenna o richiede una specifica tecnologia, condizione che negli ultimi anni si presenta sempre più spesso, soprattutto nel caso di appalti o capitolati pre-prodotti dalla committente stessa
• l’applicazione è sufficientemente complessa da richiedere, come è giusto che sia, una progettazione a 4 mani (anzi a 6, se includiamo il pubblico), così da poter rispondere al meglio alle esigenze del cliente

In termini molto molto macro possiamo suddividere i principali metodi di sviluppo di un’applicazione web in 3 famiglie, a seconda che si proceda con:

1. CMS open source
2. Codice proprietario
3. Original content

I puristi storceranno il naso: da un punto di vista prettamente tecnico potrebbe non essere la miglior prospettiva con cui affrontare la questione, così come potrebbe essere perfettibile la riduzione a queste sole 3 metodologie, ma questo articolo non è pensato per i puristi dell’architettura del software, è pensato per chi deve capire le principali differenze in termini di costi ma soprattutto di costi di manutenzione futuri.

Si, perché non si tratta, a mio avviso, solo del pronti via e chiavi in mano: il ciclo di vita di un software non termina con il rilascio della “versione 1.0”. Sono sempre necessari, nei mesi a seguire, modifiche, integrazioni evolutive, migliorie di vario tipo, poiché le esigenze cambiano o anche solo perché, in fase progettuale, si sia deciso di dividere il lavoro in vari step, ecc.. Le motivazioni sono molte, tutte corrette, per questo va da sè che sia importante pensare al software come qualcosa di “liquido”, che prenda la forma del suo contenitore, ovvero di ciò di cui io abbia bisogno.
Sono sempre stato dell’idea che il software (così come del resto qualsiasi altro ausilio del genere) sia nato per risolvere problemi all’uomo, e che quindi debba fare ciò che l’uomo vuole, e non il contrario…

Costruire un sito web con un CMS open source

La prima grande famiglia di cui parliamo è quella in cui risiedono tutti i cms open source. Famosi o meno, potenti o meno, l’idea alla base è sostanzialmente sempre la stessa: una community di persone si mette insieme per lavorare ad un prodotto che un utente non tecnico possa scaricare ed utilizzare per costruire autonomamente il proprio sito/applicativo/portale web, aggiungendo “add-on” all’occorrenza.
In questa famiglia troviamo i vari WordPress, Joomla, Magento, Drupal, Prestashop e chi più ne ha più ne metta.
A seconda di cosa si debba fare l’uno può essere più indicato dell’altro, ma in linea generale il concetto di base è sempre quello.

C’è però un risvolto della medaglia, anzi, più di uno…

Sicurezza

In generale CMS di questo tipo non sono propriamente dei mostri di sicurezza. Per loro natura, e per la natura dei loro principali utilizzatori, devono essere “facili” anche nella filosofia. Questo porta allo sviluppo di codice che spesso deve finire in hosting condivisi economici, dove non esiste separazione tra le cartelle pubbliche e quelle private, è tutto pubblico, aumentando moltissimo il rischio di essere violati. Se poi aggiungiamo il fatto che spesso manchino adeguati sistemi di indicizzazione sui motori di ricerca, protezione da DDOS, da Sql Injection, non vi siano ORM che mappano la connessione al database ma query piane nel codice e purtroppo tante altre “cose” tecniche, ecco che il quadretto si compone. L’utente finale troverà aliene queste parole, ed è ovvio, è un utente non tecnico, lo dicevamo. Ma il suo non essere tecnico e la scelta di un sistema per lui facile non lo proteggerà dagli attacchi e dalle parole complicate che purtroppo esistono a prescindere. Anzi, è ancora di più a rischio, proprio perché non sa di doversi proteggere da qualcosa.

Aggiornamenti e manutenzione

Un CMS poco famoso potrebbe ricevere pochi aggiornamenti, potrebbero esserci in rete poche risorse per espanderlo e migliorarlo (plugin, moduli, componenti ecc.), ed un bug di sicurezza potrebbe essere scovato quando ormai troppo tardi, pregiudicando l’installazione fatta a suo tempo e rendendo il sistema instabile.
Un CMS molto famoso d’altro canto è più facile venga preso di mira da attacchi di vario genere, è necessario quindi che la community intervenga tempestivamente, si è quindi “in balia” del loro operato, e successivamente è necessario - altrettanto tempestivamente - che vengano installati gli aggiornamenti, i quali purtroppo non posso essere previsti in anticipo.
In secondo luogo, ma cosa ben più importante secondo me, dal momento che nessuno di questi sistemi lavora solo con il proprio core ma è sempre necessario aggiungere plugin o moduli di terze parti, i rischi aumentano esponenzialmente: il bug o la porta di ingresso per l’attacco potrebbe essere proprio in un componente di questo tipo, non nel core, e quindi si deve attendere che venga fixato da chi ha scritto il componente stesso (sempre che lo faccia).
Oppure ancora i rilasci dei vai fix tra core e plugin potrebbero avvenire in momenti temporali “sbagliati” tra loro, sollevando incompatibilità.
Insomma… La manutenzione, nel caso di un CMS open source, potrebbe essere poca o molta, richiedere poco o molto tempo, generando pochi o molti disservizi ed effort di intervento, il tutto senza poter predire nulla purtroppo, risultando completamente dipendenti da terzi (community e sviluppatori dei vari plugin in uso).

Usabilità del pannello di amministrazione

Un altro aspetto fondamentale risiede nel fatto che un CMS di questo tipo nasce per sopperire a svariate esigenze contenutistiche e funzionali, e per questo il pannello di amministrazione è molto “astratto”.
Il sistema non sa se una certa sezione verrà utilizzata per un’area news o per un post di un blog o per una pagina contatti. Presenta, quindi, pulsanti e obbliga a flussi che per l’utente finale (che al contrario sa bene cosa voglia fare) possono risultare anonimi, al limite del fuorviante. Quando poi la funzione è garantita dall’accoppiata core+plugin è ancora peggio: imposti alcuni parametri in un punto, poi altri in un altro. È tutto un correre dietro a questo collage fatto di pezzi di codice reperiti in rete, ed un incrociare le dita.

Flessibilità

Principalmente per i tre motivi di cui sopra, anche se non solo, ci troviamo proprio nella condizione in cui tu devi fare come vuole il software, e non il contrario.
Devi quindi sapere come lui ragioni, nella sua forma astratta, e piegare il suo modo di vedere cose al tuo modo di volerle. Questo può andare bene quando non hai pretese, quando non cerchi uno strumento professionale, ma in altri casi rende tutto inutilmente complesso: le esigenze del cliente, del suo pubblico, quelle tecniche, e in più anche il CMS che si mette in mezzo dettando i principali binari (per non dire gabbia) in cui muoversi?! Grazie, ma no grazie.
Finchè si tratta di realizzare un sito vetrina di qualche pagina, statica, allora nessun problema, i vantaggi nella velocità di installazione e nel fatto che il cliente sia autonomo possono anche valerne la pena. Nel momento però in cui le esigenze sono differenti, più articolate, allora inizia questo intricato gioco di potere in cui devi cercare la soluzione aggirando tutti gli ostacoli che ti si parano davanti. Se volevo giocare a Mario Bros o tentare la sorte in una escape room bastava dirlo, comunque.
In molti casi, e qui reductio ad absurdum, l’esigenza è tanto articolata e specifica che del CMS se ne usa solo il core (che peraltro spesso mal gestisce cose banalissime come slide, form contatti e multilingua senza tonnellate di plugin esterni) e poi si scrivono tutti i plugin a mano… Allora che senso aveva porre il CMS open come vincolo in quanto “universale” se poi viene totalmente customizzato tutto in quel modo?! L’obiettivo di poter cambiare facilmente fornitore a quel punto non è stato centrato proprio per niente. Ma si sa, molte volte chi decide non è né chi usa né chi paga.

Di solito lo scenario è questo:
“Noi lavoriamo con i CMS open, sono i migliori, i più famosi. C’è la community che supporta, e sono universali, anche un bambino sarebbe capace di metterci mano. Il costo del vostro progetto è di 6k.”
“Ottimo, è il più basso di tutti i preventivi, quindi lo accetto. Ma le eventuali modifiche future?”
“Nessun problema, abbiamo plugin per ogni cosa”

... 6 mesi dopo...

“Il sito è offline, oppure è online ma lento, oppure è online ma in home ci sono degli strani simboli terroristici”
“Impossibile, è super sicuro, devi aver sbagliato qualcosa tu, nell’usarlo”
“Oh, mi spiace, non volevo. Potete sistemare?”
“Certo, alla modica cifra di...”

... Oppure...

“Ogni giorno devo fare quell’operazione, che mi fa perdere molto tempo perché devo fare 8 click in questa pagina e poi altri 6 nell’altra. Non si può rendere il processo più snello?”
“Tu tu tu tu tu...”

... Oppure ancora...

“Ora che il lancio in Italia è andato bene vogliamo attivare anche la lingua inglese, potete farlo?”
“Certamente, purtroppo però c’è un aggiornamento 4.3 pending del core che inibisce l’installazione di nuovi plugin a meno che non siano arrivati alla versione 8.2. Quello del multilingua peraltro non è pienamente compatibile con la slide in home perché ancora alla 12.1.4, andrebbe aggiornato ma poi non funziona sui cellulari più vecchi dell’altro ieri, e c’è un’altra incompatibilità con il campo indirizzo della form contatti, ma riscrivendo tutto è possibile senza problemi, serviranno solo 2 mesi e altri 5k”

Sui CMS open mi fermo qui per non entrare troppo nel tecnico, ma per domande o analisi di situazioni particolari contattateci! Siamo a disposizione per aiutarvi a uscire dall’intricato groviglio.

Acquistare software scritto in codice proprietario

Per codice proprietario si intende un software realizzato con sorgenti privati, protetti, proprietari appunto, che l’acquirente (e il suo eventuale futuro fornitore) non ha realmente acquistato e che non dovrà nè potrà conoscere mai.
L’esempio più semplice per trasmettere il concetto è Microsoft Word e analoghi, dove non acquisti il software o il codice da cui è composto ma solo la licenza d’uso, di quel software. Quindi installi nel computer un pacchetto chiuso, di cui non ne conosci il contenuto, ma che con un doppio click sull’icona avvia qualcosa che ti risolve un problema, e tu paghi per questo. Ineccepibile...

Quando però si trasla il concetto nel mondo del web, e dei progetti su commissione soprattutto, le cose non sono così semplici.
Partiamo con il dire che di questo genere di metodologia ne esistano due dimostrazioni pratiche in commercio:

• da un lato i progetti sviluppati più o meno custom da software house, one to one, su commissione (ad esempio software gestionali, contabili, ERP ecc.)
• dall’altro i servizi “hostati” ed i Saas (software as a service) come shopify ad esempio, wix o tanti altri (ne nasce circa uno al mese, non temete)

Nel primo caso il “Word” di turno è stato realizzato dal fornitore, installato su un server adeguato e fatto girare. Il giorno però che hai qualche problema, o devi fare degli interventi sei vincolato a quel fornitore, pena il rifacimento completo di tutto il progetto. Del resto, se i sorgenti sono compilati e non sono disponibili e non c’è modo di risalire al codice originario. Puoi “copiarlo” facendo reverse engineering, ma se devi rifarlo tanto vale rifarlo in altro modo, non ricascare nella stessa problematica.
Quindi ciò che inizialmente potrebbe risultare anche in questo caso allettante dal punto di vista dei costi, potrebbe però nascondere insidie dietro l’angolo se guardi un po’ in là nel futuro.

Di solito lo scenario è questo:
“Il nostro sistema è super sicuro e super garantito, i sorgenti non sono rilasciati e quindi ciò è un plus. Il progetto, con le vostre richieste di personalizzazioni, costa 10k.”
“Ottimo, è più basso degli altri preventivi. E le modifiche future?”
“Ah, costano poco quelle, siamo esperti e veloci”

... 6 mesi dopo...

Si scopre che quel “poco” in realtà non lo era poi molto, ma non puoi farci niente, perché hai ormai impostato la comunicazione, la contabilità, il magazzino o quel che era su quel programma, hai fatto l’investimento iniziale, e quindi sei vincolato a quel fornitore.

Sia chiaro, non sto dicendo che questo sia l’unico scenario. Ci sono per fortuna tante aziende serie che scelgono di lavorare in proprietario e consci dei contro se ne preoccupano già loro a monte, ad esempio con tool di esportazione dei dati, o listino prezzi per mostrare i costi di manutenzione anche su modifiche custom portando esempi passati. Dico solo che scegliere uno sviluppo in codice proprietario possa creare questo tipo di problema.

Nel secondo caso invece di solito non parli né con sviluppatori né con progettisti ma con un commerciale che ti illustra la scheda tecnica del software, il suo prezzo, solitamente al mese, e fine.
Ti registri e usi il software.
Va da sé che non puoi pensare di avere molto agio nelle customizzazioni. Se una certa funzione esiste, e rientra nel tuo “piano” la potrai attivare ed utilizzare, ma non sperare di poter spostare un po’ a sinistra quel pulsante, o di definire i flussi logici, perché è già tutto stabilito a monte, motivo per cui costa “poco”...

Progettare e sviluppare un'applicazione web in original content

Un software sviluppato in original content è un software che è stato realizzato sartorialmente secondo, e solo secondo, le specifiche esigenze del progetto.
Se non proprietario, e quindi open source, il cliente acquista così anche i sorgenti (PHP, Python, Ruby, Javascript, o quel che sarà) ovvero ha a disposizione l’intero programma, può farne (o farne fare) ciò che vuole.
Lo svantaggio è che ha un costo iniziale sicuramente più alto, ma l’enorme vantaggio è che colma tutti i contro di tutti gli altri sistemi precedenti.
Ma... Tutti tutti...

Framework si o framework no?

Lo sviluppo in original content, ovvero lo scrivere il codice da zero (“from scratch” come si dice in gergo) può richiedere molto lavoro riciclabile. Per citare alcuni argomenti:

• gestione del routing delle pagine
• reindirizzamenti automatici nella localizzazione corretta in caso di multilingua
• meccanismi di registrazione, login e recupero credenziali
• ORM di accesso al database
• paginazione di elementi
• ordinamenti di liste

...e solo per restare in superficie

Questi concetti non sono specifici, sono generici, astratti. Scrivendo un progetto, ad esempio in PHP, da zero ogni volta, bisognerebbe costruire queste funzioni ogni volta usando classi e metodi PHP.

Qui viene in aiuto il framework, che non va confuso con il CMS.
Il CMS è lo strumento per consentire all’utente non tecnico di comandare il proprio sito.
Il framework è la “cassetta degli attrezzi” che consente di sviluppare il sito e con cui - perché no - realizzare anche l’eventuale pannello di controllo per l’utente finale. Agisce ad un livello più basso, non ha a che vedere con l’interfaccia, con l’usabilità, con la grafica, con il marketing, con la comunicazione, ma esclusivamente con la logica di business e l’interfacciamento di Back-End tra codice e database.

Facciamo un esempio semplice:

• Il CMS open source è il tavolino dell’ikea. Lo porti a casa e lo monti. Quello è. Al massimo lo monti sbagliato.
• L’original content invece è il tavolo fatto su misura, e con un framework evito di costruirmi anche cacciaviti e martelli ogni volta. Uso appunto una cassetta degli attrezzi che li contenga già, così posso permettermi il lusso di concentrarmi solo sul vero focus del lavoro, ovvero le misure, l’essenza del legno, la struttura ecc.

Quindi basta prendere un framework e siamo a posto?

Beh... Attenzione. Come in tutte le cose la virtù sta nel mezzo. Non tutti gli attrezzi sono di pari qualità...
Analogamente ai cms open source esistono framework più o meno evoluti, più o meno manutenuti. Del resto anche loro, per la maggior parte, sono open source e quindi sviluppati dalla community, come:

• Laravel e Symfony per PHP
• Django per Python
• Spring per Java
• React per Javascript

o pensati da un’azienda per il proprio progetto e poi rilasciati al pubblico, come:

• Bootstrap per Twitter (sebbene questo sia un framework di front-end, ma è giusto per trasmettere il concetto)
• React per Facebook
• Angular per Google

Perchè non soffrono le problematiche di sicurezza dei cms open?

E’ molto semplice, a differenza del cms qui ancora non c’è niente. Non c’è il legno, di quel tavolo. Solo cacciaviti e martelli. Sarà poi il tuo fornitore a realizzare effettivamente le gambe di quel tavolo lunghe quanto serve e lunghe tutte uguali, non saranno già incluse nel cartone che porti a casa.

Perchè non soffrono le problematiche di aggiornamenti e manutenzione dei cms open?

Dal momento che lo sviluppo non è incluso nel framework, non esiste un unico modo di utilizzare quegli strumenti, e quindi il codice è esponenzialmente molto meno attaccabile, non essendo quello ad essere diffuso in rete pubblica.

E riguardo usabilità e flessibilità?

Torniamo all’assunto che tanto amo: il software deve fare quello che vuole l’uomo, non il contrario. Qui hai una tela bianca, fai quello che vuoi, come vuoi, dove vuoi. Quindi disegni, progetti e sviluppi la logica, l’interfaccia pubblica e l’interfaccia del pannello secondo le competenze specifiche di coloro che lo utilizzeranno. Se serve aggiungere funzioni o modificare qualcosa hai tutto lì a portata di mano, niente vincoli dettati da nessuna gabbia aggiunta.

Se voglio cambiare fornitore?

Niente di più facile. Il progetto è, ad esempio, in PHP + JS? Ti basta trovare fornitori che sappiano scrivere in PHP e JS...
Sono stati impiegati framework e quindi il progetto è “diventato” in Laravel + React? Ecco... stessa cosa...
Chiaro che sì, bisogna trovare professionisti (come in tutto del resto), ma non si è legati a quel fornitore in particolare, come nel caso dello sviluppo con codice proprietario.

Perché allora non fanno tutti così?

La short version, nonché quella cinica, è che servono competenze più profonde, orizzontali e verticali, e figure di questo tipo costano di più rispetto ad altre.
Il quadro poi si completa se ci aggiungiamo il fatto che normalmente il cliente medio non si interessa di quel che stia acquistando, come se non fosse lui a doverlo poi usare, e che si accorge solo mesi dopo aver pagato, che il fornitore non gli va più a genio.

Non esiste una soluzione giusta e una sbagliata. Esistono esigenze, che i clienti dovrebbero esporre sempre al meglio, sperando di trovare di fronte un interlocutore sufficientemente illuminato da poter scientemente effettuare la scelta giusta.

Noi in ASB\COMUNICAZIONE abbiamo optato per quest’ultima soluzione, quella di sviluppare applicazioni web in original content con framework open source. Ci fa dormire tranquilli la notte, e ci permette di risolvere i problemi dei nostri clienti o far cogliere loro opportunità nel mondo del web.
Le altre soluzioni ci paiono valide sì, ma in casistiche a nostro avviso troppo ristrette e non totalmente compatibili con il nostro mercato.
Tutto sta nel capire se vuoi vendere codice o creare relazioni con cui aiutare le aziende clienti. Ergo, se il fornitore è di qualità allora lo sarà anche la sua cassetta degli attrezzi e il prodotto finale che ti consegnerà. In caso contrario... Beh, a quel punto una soluzione vale l’altra, ti abbracciamo forte e ti ricordiamo che siamo a disposizione ;)