Questo articolo lo rimando da settimane. Le cose senza scadenza si rimandano benissimo. Lo scrivo adesso perché è uno di quei rari periodi dell'anno in cui non c'è niente che scada domani, anche perché so bene come vanno a finire gli appunti che non diventano testo.
Nell'ultimo anno ho sostituito due installazioni Moodle con due piattaforme e-learning costruite da zero, scrivendo il codice insieme a un assistente AI.
La prima era un esperimento. Lo dico adesso come lo dissi allora, senza aggiustare la storia col senno di poi. L'azienda voleva uno strumento modellato sulla propria offerta formativa, non l'ennesima personalizzazione stratificata su una base che tirava altrove. Ho proposto di provarci, dichiarando che era un tentativo. Un po' perché ci credevo, un po' per curiosità professionale, che è una ragione meno nobile e altrettanto vera. Oggi quella piattaforma è in produzione. La seconda è venuta dopo, con meno dubbi.
Nello stesso periodo ho continuato a mantenere altre tre piattaforme Moodle, a svilupparci plugin, a integrarci servizi esterni via Web Services. A settembre porto a MoodleMoot Italia una relazione su un plugin Moodle per la didattica ibrida.
Non sono un convertito al su misura, né un difensore d'ufficio dell'open source. Ho fatto le due cose in parallelo, sugli stessi tipi di cliente, negli stessi mesi. Da lì in mezzo si vede qualcosa che dall'una o dall'altra sponda non si vede.
La risposta breve res"dipende". Il resto serve a capire da cosa. Avviso ai naviganti: a metà articolo cambio parzialmente idea su me stesso, lasciando la contraddizione in piedi invece di nasconderla.
La domanda che mi fanno tutti
Me la fanno così: "adesso che con l'AI scrivi codice dieci volte più in fretta, chi te lo fa fare di usare Moodle?".
Domanda legittima, premessa sbagliata. Presuppone che il costo dominante di una piattaforma e-learning sia scriverne il codice. Non lo è mai stato. La scrittura iniziale vale forse un quinto del ciclo di vita. Il resto è manutenzione, conformità, casi limite, migrazioni, supporto, adeguamenti normativi: roba che si accumula piano e non fa notizia.
Se l'AI ti dimezza quel quinto, hai comprato meno di quanto credi.
La domanda utile è un'altra. Nel mio sistema, che cosa è commodity e che cosa no? Commodity è ciò che tutti gli LMS fanno uguale e che nessuno nota, finché funziona: autenticazione, ruoli, iscrizioni, tracciamento, riproduzione di pacchetti standard. Differenziante è ciò che rende la piattaforma riconoscibile a chi la usa, perché parla del suo lavoro invece che del modello mentale di un software generalista.
Tutto quello che segue discende da qui. Compresa la parte in cui scopro che il confine fra le due categorie si è spostato più di quanto pensassi.
Di cosa parlo e di cosa non parlo
Il perimetro va dichiarato subito, prima che qualcuno scambi una scelta per una dimenticanza.
Parlo di Moodle anzitutto per ragioni biografiche: le due piattaforme che ho sostituito erano Moodle, le tre che mantengo sono Moodle. È l'unico termine di paragone su cui posso dire cose viste, non lette.
Poi per ragioni di contesto. Nella formazione professionale accreditata, nella scuola, nell'università, in gran parte della formazione obbligatoria, in Italia Moodle è lo standard di fatto. Se un ente ha una piattaforma, nove volte su dieci è quella. La domanda "la rifacciamo da capo?" nasce quasi sempre davanti a un Moodle.
Infine per una ragione strutturale. Estendere o costruire è un'alternativa vera soltanto dove l'esistente si lascia estendere: sorgenti aperti, API documentate, nessuna licenza che ti pianti i paletti.
Quello che lascio fuori
Chamilo, ILIAS, Canvas, Open edX. Alcuni ottimi, in certi contesti probabilmente migliori. Non ne ho mai avuto uno in produzione, quindi ne parlerei leggendo schede prodotto. Di articoli scritti così ne circolano già abbastanza.
I SaaS proprietari, da Docebo a TalentLMS. Lì il dilemma non è estendere o costruire, è comprare o costruire. Cambia la natura stessa del problema: canone per utente, dati che stanno a casa d'altri, clausole che decidono cosa puoi portarti via il giorno che te ne vai. Più una questione di dipendenza che di tecnologia. Merita un articolo suo.
Gli LMS su WordPress invece li tengo dentro. Il mio lavoro ne comprende parecchio. Per una fetta precisa dei casi che mi arrivano sono la risposta giusta. Chi viene dal mondo Moodle tende a liquidarli in fretta, sbagliando.
LearnDash e Sensei, dove sono la scelta giusta
Sensei LMS lo sviluppa Automattic, gli stessi di WordPress.com, WooCommerce e Jetpack. Per il microlearning è la cosa più elegante che conosca, perché non combatte contro WordPress: ci vive dentro. I contenuti si costruiscono con l'editor a blocchi, gli Interactive Blocks aggiungono flashcard, video interattivi, hotspot sulle immagini, tasklist e domande dentro qualunque pagina o articolo. Non serve nemmeno creare un corso. Puoi rendere interattivo un post del blog. Per pillole formative brevi, per l'onboarding, per la formazione informale sui prodotti quel modello è più naturale di qualsiasi cosa tu possa combinare in Moodle, dove la stessa identica cosa richiede un'attività dentro un corso dentro una categoria.
Sensei ha aggiunto anche un tutor conversazionale AI dentro la lezione. Dettaglio da tenere a mente, ci torno alla fine.
LearnDash sta un gradino più su per struttura: corsi, lezioni, argomenti, quiz, rilascio a scaglioni, prerequisiti, certificati, gruppi con group leader, reportistica dedicata. I gruppi, in particolare, sono la risposta più vicina che il mercato WordPress offra al bisogno di "un'area dove l'azienda vede i propri dipendenti". Se il caso d'uso è semplice, guardateli prima di scrivere una riga di codice.
Il limite di entrambi, per il tipo di lavoro di cui parlo qui, è duplice.
Primo, lo SCORM. Sensei non lo supporta nativamente, lo dichiara la sua documentazione ufficiale, con la richiesta di funzionalità aperta sul repository di Automattic dal 2023. Nemmeno LearnDash lo supporta nativamente: serve un add-on di terze parti, GrassBlade xAPI Companion, Tin Canny di Uncanny Owl, l'integrazione eLearning Standards. Funzionano bene. Solo che hai aggiunto un fornitore alla catena, con il suo ciclo di rilascio, il suo prezzo annuale, la sua compatibilità da riverificare a ogni aggiornamento di WordPress. Nella formazione obbligatoria, dove i pacchetti arrivano dai fornitori di contenuti in SCORM 1.2 esportato da Storyline o iSpring, lo SCORM non è una funzione accessoria: è il formato in cui il lavoro arriva.
Secondo, erediti WordPress. Superficie di attacco, carico di aggiornamenti, conflitti fra plugin, prestazioni sotto carico concorrente. Per una scuola con quattromila studenti che entrano nella stessa fascia oraria non è la stessa faccenda che per un sito con cinquanta iscritti al mese.
Detto questo: se lo scenario è "vendo corsi asincroni brevi dal mio sito WordPress", il su misura è quasi sempre sbagliato e Sensei è probabilmente la risposta. Non tutto deve essere un LMS.
Cosa è cambiato davvero
Il cambiamento è reale, inutile minimizzarlo. Un modulo funzionante che prima chiedeva tre giorni oggi ne chiede mezza. Prototipare un'interfaccia, generare le migrazioni, scrivere le query, coprire i casi con dei test: da giorni a ore.
Sennonché questa accelerazione non spinge tutta nella stessa direzione.
Estendere Moodle costava caro per una ragione precisa, la curva di apprendimento delle sue API interne. Il sistema dei contesti, la gestione delle capability, l'API dei form, le convenzioni del database, la struttura di un plugin di tipo block o mod. Mesi, non giorni. Quel costo d'ingresso spingeva molte aziende a comprare un prodotto chiuso pur di non toccare codice.
Oggi si è abbassato quanto quello di scrivere da zero, forse di più, perché le API di Moodle sono documentate e il modello è fermo da anni. Il che vuol dire che il valore relativo di Moodle come base è cresciuto, non calato. Ti tieni gratis vent'anni di casi limite già risolti, poi ci monti sopra la parte differenziante a un costo che prima era proibitivo.
È quello che ho fatto sulle tre piattaforme Moodle che mantengo. Un blocco che porta un tutor AI conversazionale dentro il corso, alimentato via Web Services con i contenuti reali del corso stesso. Un plugin per il calendario delle lezioni in didattica ibrida, quello che porto al MoodleMoot. Infine un plugin che chiamo Vimeo controllato, che verifica il progresso effettivo di un video Vimeo, anche quando il video viene aperto in popup, vincolando il completamento dell'attività alla percentuale realmente vista invece che al semplice clic sul player.
Tre funzioni che nessun LMS pronto offriva nella forma che serviva ai clienti, costruite sopra un motore che non ho dovuto scrivere io. Sul terzo però tornerò, perché contiene un argomento che gioca contro tutta questa sezione.
La lezione degli strumenti AI, insomma, non è "adesso posso rifare tutto". È "adesso posso permettermi la personalizzazione che prima non stava nel budget". Conclusioni diverse, decisioni opposte.
Quello che un LMS costa e che il codice non spiega
Prima dei due casi in cui il su misura ha vinto, l'elenco di quello che ci si lascia alle spalle. Senza, tutto il resto è pubblicità.
Lo SCORM, tanto per cominciare. Il runtime sembra banale: quattro o cinque funzioni, LMSInitialize, LMSGetValue, LMSSetValue, LMSCommit, LMSFinish, più il modello dati con cmi.core.lesson_status, cmi.suspend_data, cmi.core.lesson_location. Ne scrivi una versione funzionante in un pomeriggio e ti senti bravissimo. Poi arriva un pacchetto Storyline che riempie il suspend_data fino al limite, uno iSpring che pretende il lesson_status inizializzato in un modo preciso, un altro che chiama LMSFinish prima di aver committato. Quanto alla Sequencing and Navigation di SCORM 2004, è una specifica che quasi nessuno implementa davvero al cento per cento. Moodle compreso, dopo vent'anni.
Poi il gradebook, che a guardarlo sembra una tabella con dei voti ed è la parte più insidiosa di qualunque LMS. Categorie, pesi, aggregazioni, esclusioni, override manuali, ricalcolo a cascata, arrotondamenti, voti nascosti, condizioni di completamento che dipendono dai voti e voti che dipendono dal completamento. Chi lo ha riscritto da zero se ne è pentito. Chi non se ne è pentito, probabilmente non ha ancora ricevuto la richiesta giusta.
L'accessibilità. Su Moodle parti da una base lavorata da anni, con audit esterni alle spalle e una comunità che segnala le regressioni. Sul su misura parti da zero. Il responsabile sei tu. Sul quadro normativo torno più avanti, perché è una delle poche cose su cui si possono fare previsioni con i piedi per terra.
La sicurezza. Moodle pubblica security advisory con cadenza regolare. Su una piattaforma tua ogni XSS, ogni IDOR sui tentativi di quiz, ogni upload non sanificato, ogni escalation di privilegi è tua e soltanto tua. Da freelance è un'esposizione contrattuale del tutto sproporzionata rispetto a quello che riesci a fatturare. Meglio saperlo prima di firmare.
L'interoperabilità: LTI 1.3, xAPI, cmi5, SSO SAML o OAuth, integrazione con un LRS esterno. Ogni cliente strutturato prima o poi te ne chiede uno.
Il mobile, soprattutto l'offline. L'app ufficiale di Moodle scarica i contenuti e consente tentativi senza connessione. Una PWA fatta bene ci arriva, però è lavoro vero, che nella formazione sulla sicurezza pesa parecchio: gente in cantiere con la linea che va e viene.
Niente di tutto questo è un argomento contro il su misura. È quello che va messo sul piatto della bilancia. Alcune di queste voci, l'ho scoperto strada facendo, pesano meno di quanto pesassero due anni fa.
Il problema di Moodle non è com'è fatto, è come parla
Quando si critica l'esperienza utente di Moodle la critica scivola quasi sempre sull'estetica. Interfaccia datata, menù ridondanti, troppa roba nella stessa schermata. Osservazioni in parte superate, visto il lavoro fatto sull'interfaccia nelle ultime versioni, comunque risolvibili con un tema decente.
Il limite vero sta altrove. È un limite di vocabolario.
Moodle ha i suoi oggetti concettuali: corso, categoria, utente, iscrizione, ruolo in contesto, gruppo, coorte, attività, risorsa, voce di valutazione, condizione di completamento. Sono oggetti potenti. È grazie a loro che Moodle riesce a modellare qualunque cosa. È anche il motivo per cui, in certi domini, non modella bene niente in particolare.
Chi disegna la mappa decide che cosa esiste. Vale per le carte geografiche, vale per il modello dati di un software.
La formazione sulla sicurezza sul lavoro, per fare l'esempio che conosco meglio, ha oggetti del tutto diversi:
| Il mondo pensa in termini di | Moodle lo rappresenta come |
|---|---|
| Azienda | Coorte, oppure categoria, oppure campo profilo personalizzato |
| Lavoratore con una mansione | Utente in un gruppo, con un campo personalizzato |
| Formazione obbligatoria per quel ruolo | Iscrizione manuale o regola di iscrizione |
| Scadenza dell'attestato | Nulla di nativo, si risolve con un plugin o con un report |
| Aggiornamento quinquennale | Nulla di nativo |
| Preposto, RLS, RSPP | Ruoli custom da configurare a mano |
| Attestato valido ai fini di legge | Certificato generato da un'attività |
Ogni riga di quella tabella è una traduzione. Ogni traduzione è un punto in cui l'interfaccia smette di parlare la lingua di chi la usa.
Il datore di lavoro non vuole visualizzare il completamento dell'attività SCORM per gli utenti della coorte X filtrati sul campo personalizzato mansione. Vuole sapere chi gli scade fra novanta giorni. Stessa informazione, due prodotti diversi.
Nessun tema risolve una faccenda del genere, perché il problema non è l'aspetto: è l'architettura dell'informazione. Puoi rendere Moodle bellissimo. Resterà una piattaforma che chiede al tuo utente di imparare un vocabolario che non è il suo.
La prima: dove finisce il corso e comincia l'azienda
È la piattaforma nata come esperimento. Serve un ente che eroga formazione in modalità mista, una parte in aula e una parte online, con gli stessi partecipanti che si muovono fra i due mondi.
Descritta così sembra un LMS qualunque. Il punto è che lo stesso motore corsi viene declinato in quattro forme diverse, che sono poi le quattro forme in cui quell'ente vende: il corso vero e proprio, con date, ente committente, referente e lezioni multiple; l'evento singolo, quasi sempre in presenza, con ricevuta e check-in; il corso a catalogo, a pagamento, con posti illimitati e durata dell'abbonamento; la formazione asincrona on demand, fruibile via link tokenizzato, con soglia di visione. Quattro modelli di business dentro la stessa tabella. Nessun LMS generalista ha una nozione di questo genere, perché nessun LMS generalista sa cosa vendi.
Poi c'è la parte che con la didattica non c'entra niente ed è quella che tiene in piedi l'ente.
Gli incassi, per cominciare. Checkout PayPal con Orders API v2 e riconciliazione lato server sull'identificativo dell'ordine, così un pagamento non resta a metà se scade la sessione. Bonifico gestito facendo caricare la ricevuta al discente, che parte in allegato all'amministrazione con i pulsanti approva e rifiuta dentro un link tokenizzato: chi verifica non deve avere un account, non deve ricordare una password, apre la mail e decide. Gift card acquistabili e spendibili sulle iscrizioni. Richiesta di fattura elettronica con la tipologia del cliente, dalla persona fisica alla ditta individuale, dall'azienda all'ente, fino alla pubblica amministrazione con lo split payment.
Provate a immaginare quella catena dentro Moodle. Io ci ho provato per mesi.
Poi l'acquisizione. Landing pubbliche di anteprima corso, link di pagamento che saltano la presentazione e portano dritti al checkout, inviti nominali monouso, posti riservati a una categoria, lista d'attesa, scadenza delle iscrizioni, API pubblica del catalogo asincrono per esporlo su siti terzi.
Poi l'operatività: check-in con QR, dove il discente mostra la ricevuta e la presenza si registra da sola il giorno dell'evento; registro presenze pubblico tokenizzato per gli operatori; attestati personalizzabili con codice di verifica pubblico; portale docente senza login, sempre via link tokenizzato; programma settimanale in area amministrativa con le lezioni dei prossimi dieci giorni e la comunicazione già pronta per il formatore.
Poi la rendicontazione: questionari di gradimento, questionario finale del referente, report in tempo reale su link pubblico, statistiche per docente, report iscrizioni in PDF. Più un modulo di supporto tecnico con FAQ pubbliche, ticket e rendicontazione dei costi delle attività di assistenza.
E infine una scelta architetturale di cui vado stranamente fiero: niente cron di sistema. L'archiviazione dei corsi scaduti, i promemoria di scadenza degli abbonamenti e la sincronizzazione automatica dei docenti dall'Albo Formatori girano opportunisticamente sul routing degli utenti loggati, con un throttle interno. In astratto è brutto. Su quell'hosting condiviso è la cosa giusta. Nessun prodotto generalista avrebbe potuto prendere quella decisione al posto mio.
In Moodle un perimetro così si copre solo a pezzi. mod_attendance per le presenze, un plugin di iscrizione piegato a gestire i voucher, un sistema di prenotazione da cercare fra le estensioni della community, le FAQ come attività database. Sui pagamenti e sulla fatturazione elettronica non si copre affatto. Quattro o cinque plugin di quattro o cinque autori diversi, ciascuno con il suo linguaggio di interfaccia, il suo posto nei menù, la sua idea di dove vada il pulsante di conferma.
Funziona. Non è un prodotto, è un assemblaggio. Gli utenti lo sentono anche quando non saprebbero spiegarlo.
C'è poi un effetto che non avevo previsto, quello che alla fine ha pesato di più. Il tempo di risposta a una richiesta del cliente. Quando arriva la telefonata che chiede una modifica al registro presenze, con Moodle la prima domanda è "il plugin lo permette?". A volte la risposta è no. Allora si valuta se forkare, se cercare un'alternativa, se aggirare. Nel su misura quella prima domanda non esiste proprio. Si passa direttamente a "quanto costa".
Mi aspettavo che il guadagno principale fosse l'esperienza utente. È stato questo, invece. Commercialmente pesa più di qualunque considerazione tecnica.
La seconda: l'azienda che vuole sapere se è in regola
La seconda piattaforma eroga formazione sulla sicurezza sul lavoro. Nasce da una richiesta di una riga: serve un'area aziendale che permetta all'azienda di tenere sotto controllo la formazione dei propri dipendenti.
Una riga, però contiene tutto. Perché il vantaggio del su misura qui è più netto ancora, per un motivo che ho capito più tardi di quanto avrei dovuto: l'utente più importante della piattaforma non è chi fa il corso.
Chi fa il corso è un lavoratore che entra due volte l'anno, guarda i moduli, fa il test, scarica l'attestato. Gli serve che sia lineare e che non gli faccia perdere tempo. Finisce lì.
Chi decide se la piattaforma resta o va via è il datore di lavoro, o il responsabile del personale. A lui serve sapere in ogni momento se l'azienda è in regola. Non quanti dipendenti hanno completato il corso: se domani arriva un'ispezione lui è coperto oppure no. Domanda che ha a che fare con la responsabilità personale, penale per giunta. Chi se la pone non è dell'umore giusto per imparare un'interfaccia.
L'area aziendale è costruita intorno a quella domanda. La prima cosa che vede entrando sono le scadenze, ordinate per urgenza. Non un elenco di corsi, non un elenco di utenti: un elenco di scadenze, con nome del lavoratore, mansione, tipo di formazione, giorni mancanti. Sotto, chi non ha ancora iniziato. Sotto ancora, chi ha iniziato e si è fermato.
In Moodle quella schermata è un report personalizzato, costruito con l'apposito strumento o con SQL, che il cliente non può modificare da solo e che resta un oggetto separato dal resto. Nel su misura è la home.
Tre cose, poi, che in questo dominio contano molto e che nessun LMS generalista modella nativamente. La mansione determina l'obbligo formativo, quindi se cambio mansione a un lavoratore il suo percorso obbligatorio cambia di conseguenza, insieme alle scadenze: logica di dominio, non configurazione. L'attestato ha una validità che decorre dal completamento e si rinnova con l'aggiornamento, con regole diverse per tipologia, mentre in Moodle il certificato è un file generato, senza ciclo di vita. L'esportazione per l'audit dev'essere immediata, in un formato che il consulente accetti senza rilavorarlo, perché quella non è una funzione fra le altre: è la ragione per cui il cliente ti paga.
Nessuna delle tre è difficile da scrivere. Sono difficili da innestare su un modello dati progettato per rappresentare un corso universitario.
Il guadagno, in concreto
Il primo vantaggio, quello da cui discendono quasi tutti gli altri, è il vocabolario di dominio nell'interfaccia. L'utente non traduce. Detto così sembra poco. È la differenza fra una persona che usa uno strumento e una che lo subisce.
I flussi poi sono progettati, non composti: un'operazione che attraversa tre funzioni resta un'operazione sola, non tre schermate di tre plugin diversi. C'è un solo linguaggio visivo, il che non è questione estetica ma carico cognitivo risparmiato a ogni interazione. Il modello dei permessi rispecchia l'organigramma del cliente invece del sistema di ruoli in contesto di un software generalista. Non c'è peso morto: un'installazione Moodle standard espone una quantità di opzioni che il novantacinque per cento delle persone non userà mai, però deve comunque ignorare attivamente ogni volta.
Sulle prestazioni: migliorano, meno strati e meno query. Da sole non giustificano niente. Se qualcuno vi propone di rifare una piattaforma per quello, chiedete un secondo parere.
Cosa scopri dal sesto mese in poi
Sono cose viste succedere, non prudenze da manuale.
C'è un'asimmetria fra lato learner e backoffice che non avevo messo in conto. Il lato utente di una piattaforma su misura è quasi sempre migliore di quello di Moodle, perché lo progetti con intenzione, lo mostri al cliente, ci torni sopra. Il backoffice si degrada in silenzio, perché lo costruisci in modo reattivo, funzione per funzione, quando serve. Moodle ha un pannello di amministrazione brutto e completo. Il tuo è più bello e ha dei buchi, che si presentano sempre nel momento peggiore: l'iscrizione massiva di settembre, l'export per l'audit chiesto per ieri, la correzione di un errore su duecento record, il recupero di un utente che ha cambiato indirizzo email.
Poi gli stati infelici, che sono il problema più specifico del codice generato con l'AI. Gli assistenti producono percorsi felici eccellenti, stati d'errore sottili. Empty state, caricamento, errore di rete, sessione scaduta a metà di un modulo, upload fallito, permesso negato, doppio invio del form, tasto indietro del browser. L'esperienza utente vive quasi tutta lì, perché è in quei momenti che una persona decide se la piattaforma è affidabile o no. Conviene farci una passata dedicata e sistematica invece di risolverli uno alla volta quando arriva la segnalazione, che è quello che ho fatto io all'inizio e che sconsiglio.
Il ripristino dello SCORM merita un capoverso a sé. Se usi pacchetti prodotti da terzi, un bookmark che non riprende dal punto giusto o un completamento che non scatta l'utente non lo legge come bug tecnico. Lo legge come "questa piattaforma è rotta". È il punto in cui il vantaggio di Moodle è più difficile da recuperare, perché è un vantaggio per accumulo, non per progetto.
Il mobile e l'offline li ho già detti. L'accessibilità diventa interamente responsabilità tua: gestione del focus, navigazione da tastiera, semantica per gli screen reader, contrasti, sottotitoli.
Il debito di assistenza perpetua, invece, è secondo me la voce più sottovalutata di tutte. Ogni piattaforma su misura è un impegno a tempo indeterminato. Non puoi dire al cliente "aggiorna alla prossima versione", perché la prossima versione la scrivi tu. Da freelance, tre o quattro clienti su misura saturano la capacità di supporto molto prima di saturare quella di sviluppo. Limite che si scopre tardi.
Resta il rischio di cui nessuno parla: finire per costruire un secondo Moodle. Cinque anni, quaranta richieste di funzionalità accettate, ti ritrovi con la stessa complessità senza i vent'anni di iterazione sull'esperienza utente che l'hanno accompagnata. L'unica difesa che conosco è tenere ferma l'architettura dell'informazione e dire di no alle funzioni che non appartengono al modello di dominio. Dire di no a un cliente che paga è più difficile che scrivere codice. Questo non cambierà mai.
Il conto del codice generato
Scrivere è diventato veloce. Capire e fare debug no.
Nelle prime settimane la produttività è euforica. L'euforia è una brutta consigliera. Generi moduli interi, funzionano, il cliente è contento, tu sei convinto di aver trovato il modo. Il conto arriva dopo. Al quinto o sesto mese, quando devi modificare qualcosa che hai scritto a marzo e ti accorgi che non ricordi perché quella funzione è strutturata così. Non l'hai scritta riga per riga, l'hai revisionata. È una forma di memoria molto più debole di quanto immaginassi.
Le contromisure che ho adottato, in ordine di efficacia reale.
Convenzioni imposte dall'inizio e mai negoziate: struttura delle cartelle, nomenclatura, pattern per l'accesso ai dati, gestione degli errori. Se ogni modulo ha la stessa forma, anche il codice che non ricordi resta leggibile.
Commenti che spiegano il perché, non il cosa. Il cosa si legge dal codice, il perché no. La decisione presa alle undici di sera di gestire un caso limite in un certo modo va scritta, altrimenti fra sei mesi la scambi per un errore e la "correggi". Mi è successo.
Test sui percorsi critici, non copertura totale, che in questo contesto è irrealistica. Iscrizione, completamento, calcolo delle scadenze, generazione degli attestati: le cose che se si rompono si rompono in silenzio.
Revisione vera anche da solo, cioè rileggere il codice generato con la severità che riserveresti a quello di un collaboratore, non con l'indulgenza che riservi al tuo.
Diffidare della velocità sospetta. Se un modulo complesso viene fuori troppo facilmente, quasi sempre manca qualcosa. Di solito mancano proprio gli stati infelici.
Sotto tutto questo resta una domanda che mi fa dormire peggio. La piattaforma su misura è manutenibile finché tu sei disponibile. Se il cliente domani decidesse di cambiare fornitore, quanto ci mette il successore a capire il tuo codice? Domanda legittima, alla quale però negli ultimi mesi ho dovuto rispondere in modo diverso. Ci arrivo subito.
Contro me stesso: dove la prudenza non regge
Riletto fin qui, il pezzo pende da una parte sola. Ogni volta che c'è un dubbio, il dubbio lavora a favore di Moodle. Sarà pure onestà intellettuale, però potrebbe anche essere semplice abitudine, che è tutt'altra cosa.
Provo allora a smontare la mia stessa prudenza, con gli argomenti più duri che le si possono opporre. Alcuni li ho trovati solidi, uno no.
L'obiezione del perimetro. Ho scritto che una piattaforma su misura arriva a un MVP e resta indietro sulle funzioni. Poi rileggo l'elenco della prima: checkout PayPal con riconciliazione lato server, bonifici approvati via link tokenizzato senza login, gift card, fattura elettronica fino allo split payment per la PA, check-in con QR, registro presenze pubblico tokenizzato, attestati con verifica pubblica, portale docente senza account, sincronizzazione dei formatori da un albo esterno via API, catalogo esposto come API pubblica. Non è un MVP. È un gestionale della formazione con dentro un LMS. Di quelle funzioni, in Moodle, la maggioranza non esiste, mentre le poche che esistono in forma vaga esistono peggio. La mia stima di quello che si riesce a costruire in un anno era tarata su un mestiere che non esiste più.
L'obiezione della commodity. Ho sostenuto che la commodity va presa dallo scaffale. Vero finché ti serve davvero. Se i contenuti li produci tu, lo SCORM è un vincolo che ti sei imposto da solo: la formazione asincrona di quella piattaforma è tracciata con una soglia di visione sul video, senza pacchetti, senza runtime, senza suspend_data. Funziona, si legge, si debugga. Aggiungo il particolare che mi ha convinto del tutto: la stessa cosa ho dovuto scriverla anche lato Moodle, con il plugin Vimeo controllato, perché la soglia serviva pure lì e in Moodle non c'era. Sicché il tracciamento me lo sono scritto due volte, una dentro l'LMS e una fuori. Quando il pezzo di commodity devi costruirlo comunque, smette di essere un argomento a favore dell'LMS.
L'obiezione del successore. Ho scritto che con Moodle chi subentra ne conosce già il novanta per cento. È vero soltanto se chi subentra è uno sviluppatore Moodle. Se è uno sviluppatore PHP, un monolite documentato con lo schema versionato in migrazioni gli è più leggibile del sistema dei contesti e delle capability. Poi c'è il fatto nuovo, quello che mi ha costretto a rivedere il capoverso precedente: la barriera del codice altrui si è abbassata in modo misurabile. Anthropic riferisce che nei test iniziali Stripe ha fatto eseguire a Claude Fable 5 una migrazione su un codebase Ruby da cinquanta milioni di righe in un giorno, dove un intero team ne avrebbe impiegati più di due mesi a mano. Sui benchmark di ingegneria del software di lungo respiro il modello si colloca in testa. La stessa Anthropic osserva che il vantaggio cresce con la lunghezza e la complessità del compito. Capire l'intento resta il punto duro, su quello non ho cambiato idea. Capire il codice, invece, non è più il muro che era quando ho imparato io.
L'obiezione dell'abbandono. Ho detto che le piattaforme su misura rischiano di restare orfane. Vero, però l'argomento è simmetrico e me n'ero dimenticato: il repository dei plugin Moodle è pieno di estensioni ferme a versioni vecchie, mentre un assemblaggio di cinque plugin di cinque autori ha cinque probabilità di abbandono invece di una. Lo standard protegge il core. Non protegge quello che ci hai montato sopra, che poi è esattamente la parte a cui il cliente tiene.
L'obiezione che invece non regge. Sicurezza e accessibilità. Qui la prudenza resta intera. Non trovo modo di scalfirla. Il numero di occhi che passano sopra il codice di Moodle non lo compra nessun modello, per quanto capace. La responsabilità di una vulnerabilità su una piattaforma tua resta tua davanti a un cliente e davanti alla legge. Resta intatta anche la fatica di dire di no alle funzioni fuori dominio, che è un problema di carattere e non di tecnologia.
Tirando le somme: la soglia oltre la quale il su misura conviene si è abbassata, non di poco. Non la metterei più a cinque oggetti di dominio fuori dal modello di un LMS. Tre bastano, se sono quelli su cui il cliente guadagna o rischia. Il freno vero non è più la produttività, che è abbondante. È la disciplina di chi scrive, più la via d'uscita che lasci al cliente il giorno che non ci sei più.
La via di mezzo di cui si parla poco
C'è una terza strada, secondo me la più interessante e la meno battuta: Moodle come backend, frontend su misura.
Moodle continua a fare quello che sa fare meglio, cioè utenti, ruoli, iscrizioni, tracciamento, SCORM, valutazioni. Il frontend è un'applicazione tua, che dialoga via Web Services e presenta all'utente esattamente il vocabolario del suo mestiere.
Tecnicamente è alla portata. Si abilitano i servizi, si crea un utente di servizio con le sole capability necessarie, si genera un token, si consumano le funzioni dell'API. Nell'integrazione del tutor AI dentro due delle piattaforme Moodle che mantengo uso esattamente questa strada, con funzioni come core_course_get_courses e core_course_get_contents per alimentare il servizio esterno con i contenuti reali dei corsi.
Ha senso quando la logica di dominio sta tutta nella presentazione e nei flussi, mentre il modello dati sottostante regge il confronto con quello di un LMS. Quando il cliente ha vincoli di conformità più facili da difendere partendo da una base nota. Soprattutto quando vuoi che i dati restino in uno schema documentato, così che il cliente non sia ostaggio tuo. Cosa che dovremmo desiderare tutti, anche quando non ci conviene.
Diventa il peggio dei due mondi quando la logica di dominio pretende oggetti che in Moodle non esistono proprio, perché allora finisci a mappare a forza le tue entità su coorti e campi personalizzati, ritrovandoti con la complessità di due sistemi al posto della semplicità di uno. Oppure quando servono scritture massive, che l'API di Moodle non contempla. Oppure quando le prestazioni contano davvero, perché aggiungi un salto di rete a ogni operazione.
Le domande che mi faccio adesso
Prima di dare una risposta a un cliente, in ordine di peso. Sono cambiate rispetto a un anno fa, in particolare la prima.
Quanti oggetti di dominio ha fuori dal modello di un LMS, quanto pesano davvero? Zero o uno, Moodle senza discutere. Tre o più, se sono quelli su cui il cliente incassa o rischia, il su misura è la scelta ragionevole. Un tempo mettevo l'asticella a cinque.
Serve SCORM, di che tipo? Se il cliente riceve pacchetti da fornitori esterni, in formati diversi, prodotti con strumenti diversi, Moodle ha un vantaggio difficilissimo da colmare. Se i contenuti li produce in casa, il vincolo si allenta parecchio, tanto che la soglia di visione su un video vale spesso più di un runtime SCORM implementato a metà.
Chi mantiene la piattaforma fra tre anni? La risposta non è più automaticamente "scegli lo standard", però il committente ha il diritto di sapere cosa succede se sparisci. Meglio arrivare con una risposta preparata che con una scrollata di spalle.
Quante ore di supporto posso permettermi al mese, per questo cliente, per sempre? Moltiplicate per il numero di clienti su misura in portafoglio. Se il totale supera la capacità, la risposta ce l'avete già. Questo vincolo, a differenza degli altri, non si è mosso di un millimetro.
Il cliente ha obblighi di conformità certificabile? Accessibilità dichiarata, requisiti di un ente accreditante, capitolati pubblici. Allora partire da una base con audit alle spalle vale ancora molto.
Serve l'offline? Se sì, senza budget per una PWA seria, l'app di Moodle è un argomento pesante.
Infine: il su misura, per me, è un servizio o un prodotto? Questa ribalta tutte le altre. La tengo per la fine.
Qualche ipotesi sul futuro, dichiarata come tale
Non mi piace fare previsioni. Nel software invecchiano male, mentre chi le fa raramente ne risponde. Ne metto giù alcune lo stesso, con un metodo dichiarato: parto solo da cose già osservabili oggi, estendo la tendenza senza inventare svolte, dico dove il ragionamento è più fragile.
La prima non è nemmeno una scommessa, perché è già in corso. Avere l'AI smetterà presto di distinguere qualcuno da qualcun altro. Moodle ha un sottosistema AI nel core dalla versione 4.5, uscita a ottobre 2024, ampliato con la 5.0 di aprile 2025 e con le release successive, con un'architettura a provider che permette di collegare OpenAI, Azure oppure modelli locali via Ollama o LiteLLM. Sensei ha il suo tutor conversazionale dentro la lezione. Se in due anni la funzione è arrivata nel core di una piattaforma open source e dentro un plugin WordPress, fra due anni sarà ovunque. Quindi: se il vantaggio della tua piattaforma è che ha l'AI, quel vantaggio ha vita breve. Quello che resta differenziante è il modello di dominio, che nessuno può copiare perché è specifico del tuo cliente.
La seconda è quella di cui sono più convinto, perché è quasi aritmetica. Il costo di scrivere continuerà a scendere, quello di rispondere no. Sicurezza, protezione dei dati, accessibilità e conformità non si automatizzano allo stesso ritmo della scrittura del codice, perché il collo di bottiglia non è la produzione: è la responsabilità giuridica di chi firma. Man mano che la prima voce si assottiglia, la seconda pesa proporzionalmente di più. La direzione si vede già sul fronte accessibilità, dove l'European Accessibility Act, cioè la Direttiva UE 2019/882 recepita in Italia con il D.Lgs. 82/2022, è pienamente applicabile dal 28 giugno 2025, con riferimento tecnico alla norma EN 301 549 che richiama le WCAG 2.1 livello AA, con esenzione totale riservata alle sole microimprese. Chi vende software si sposterà dal vendere sviluppo al vendere garanzia. Chi non è in grado di garantire venderà a meno.
Terza. Nasceranno molte piattaforme verticali piccole. Una parte finirà abbandonata. Se costruire costa meno si costruisce di più, vale per qualunque tecnologia. Statisticamente una quota resterà orfana: il freelance cambia lavoro, l'agenzia chiude, il cliente litiga con il fornitore. Mi aspetto che i committenti più strutturati comincino a chiedere cose che oggi a un fornitore piccolo non chiede quasi nessuno. Portabilità dei dati in formato documentato, deposito del codice sorgente, documentazione minima messa a contratto. In pratica è l'ipotesi più utile di tutte, perché chi offre quelle garanzie spontaneamente, prima che gliele chiedano, si porta avanti di qualche anno.
Quarta ipotesi, dove vado più cauto di quanto andassi qualche mese fa. L'argomento "il mio successore non capirà il codice" si sta indebolendo in fretta. Gli assistenti leggono codice altrui meglio di quanto lo scrivano, come dimostrano i numeri sulle migrazioni di grandi codebase. La parte difficile resta l'intento: perché quella regola di calcolo delle scadenze tratta diversamente il preposto, quale richiesta ha generato quell'eccezione, quale caso reale ha imposto quel controllo apparentemente inutile. Nel codice quella roba non c'è. Corollario: la documentazione delle decisioni diventa più preziosa del codice, perché il codice ormai si rigenera.
Quinta. SCORM non muore nel prossimo giro. Non perché sia una buona specifica, non lo è, ma perché il patrimonio di contenuti già prodotto è enorme e gli strumenti di authoring continuano a esportare in quel formato. xAPI e cmi5 crescono da anni senza sostituirlo. Scommettere che fra tre anni si potrà ignorare SCORM significa scommettere contro l'inerzia dei formati, che nel software vince quasi sempre. Su questa accetto volentieri di essere smentito: basterebbe che un paio di grandi fornitori di contenuti cambiassero le impostazioni predefinite per accelerare tutto.
Sesta. Il confine fra LMS e gestionale della formazione continuerà ad assottigliarsi. La prima piattaforma che ho raccontato ne è già la prova. Nella formazione obbligatoria il problema di erogare contenuti è risolto da tempo, quello di incassare, fatturare e dimostrare la conformità no. Il valore si sposta perciò verso pagamenti, scadenze, attestati, audit, integrazione con i sistemi del personale. Terreno su cui gli LMS generalisti sono strutturalmente deboli, perché non è il loro mestiere. È lì che nasceranno i prodotti verticali più interessanti dei prossimi anni.
C'è invece un'ipotesi che non faccio: che il su misura sostituisca l'LMS generalista. La storia del software mostra che le piattaforme generaliste sopravvivono ai cicli di entusiasmo per il su misura, per un motivo che non è tecnico ma sociale. Comunità, competenze diffuse sul mercato del lavoro, continuità nel tempo. Vantaggi che nessun guadagno di produttività individuale replica, perché non stanno nel codice: stanno nelle persone che lo conoscono.
La domanda giusta non è tecnica
Se stai valutando il su misura per ottimizzare un lavoro su commessa, cioè per servire meglio un singolo cliente, la piattaforma che costruisci è un costo che ti trascini dietro. Ti ripaga sull'esperienza utente, ti presenta il conto sulla manutenzione, con la fattura che arriva ogni anno.
Se lo stai valutando per costruire un prodotto tuo, con più clienti sopra la stessa base e ricavi ricorrenti, la logica si ribalta. Quello stesso codice diventa un asset, la manutenzione si ammortizza su più contratti, la modellazione profonda del dominio diventa il tuo posizionamento sul mercato.
Due strade legittime, che però chiedono decisioni opposte dal primo giorno: architettura, multi-tenancy, configurabilità, documentazione, modello di supporto. Sbagliare lì è l'unico errore davvero costoso, perché è l'unico che non si corregge scrivendo altro codice.
La mia posizione, oggi, riveduta rispetto a come l'avrei formulata un anno fa. Moodle resta il motore giusto quando la formazione è formazione e basta. Le ore che l'AI mi fa risparmiare le investo in plugin e integrazioni che nessuno offre pronti. Il su misura non lo tengo più per i casi estremi: appena il cliente ha tre o quattro oggetti di dominio suoi, soprattutto appena il denaro entra dentro la piattaforma invece che accanto, è la strada più onesta che gli posso proporre. In mezzo, in più casi di quanti ne immaginassi, la risposta è il Moodle headless.
Rifarei quello che ho fatto? Nei due casi che ho raccontato sì, senza esitare, tanto che la contro-verifica di poco fa mi ha tolto qualche dubbio invece di aggiungerne. Quello che non rifarei è il modo: sottovalutare gli stati infelici, rimandare la documentazione delle decisioni, non mettere per iscritto fin dal primo giorno cosa succede al cliente se io sparisco.
Del resto la domanda "conviene farsela da soli?" non ha una risposta generale. Ha soltanto risposte particolari. La parte difficile del mestiere è riconoscere di che caso particolare si tratta prima di aver scritto la prima riga, poi accorgersi quando la risposta che davi l'anno scorso ha smesso di valere.
