Plugin Moodle vs sviluppo custom: come scegliere

Il Plugin Directory di Moodle (moodle.org/plugins) è una delle sue forze più grandi: oltre 1.800 plugin gratuiti, mantenuti dalla community, per quasi ogni esigenza.

Ma "quasi" è la parola chiave.

Quando un cliente ci dice "ho bisogno di questo, non trovo un plugin", la risposta non è quasi mai immediata. Prima si analizza. Questa è la logica che usiamo.

La trappola del "lo prendiamo dal Plugin Directory"

Il Plugin Directory sembra la soluzione più veloce e economica. Spesso lo è. Ma la decisione "usiamo questo plugin" senza una valutazione rischia di portare a:

Plugin non più mantenuti. Sul Plugin Directory ci sono plugin con l'ultima release nel 2019. Usarli su Moodle 4.x è un rischio di sicurezza e stabilità.

Fit funzionale parziale. Il plugin copre il 70% del requisito. Il 30% restante richiede workaround operativi, o peggio, modifiche al codice del plugin stesso.

Dipendenze da fork non supportate. Se modificate un plugin open source per adattarlo, create un fork che dovete mantenere voi. Ogni aggiornamento di Moodle può rompere le vostre modifiche.

Conflitti tra plugin. Più plugin si installano, più aumenta la probabilità di conflitti — hook che si sovrascrivono, namespace collisi, regression in funzionalità preesistenti.

Prima di scegliere un plugin, 4 minuti di verifica possono evitare 4 settimane di problemi.

4 domande da fare prima di scegliere

1. Quando è stata l'ultima release?

Un plugin aggiornato negli ultimi 6 mesi per la versione corrente di Moodle è probabilmente mantenuto. Un plugin con l'ultima release 18 mesi fa su una versione di Moodle precedente è un rischio.

2. Quante installazioni attive ha?

Il Plugin Directory mostra il numero di installazioni segnalate. Non è perfetto (molte installazioni non segnalano nulla), ma sotto le 500 installazioni attive il plugin è poco testato in scenari reali diversi.

3. Il maintainer risponde alle issue?

Andate su GitHub o sul forum di supporto del plugin. C'è attività nelle ultime 3 versioni di Moodle? Le issue aperte vengono chiuse, o si accumulano?

4. La licenza è compatibile con il vostro uso?

La quasi totalità dei plugin Moodle è GPL 3. Se erogaste il plugin come servizio SaaS a terzi senza modifiche al codice, tecnicamente potreste avere problemi di compliance (dipende dall'interpretazione della GPL sull'uso come servizio). Per uso interno su propria piattaforma, nessun problema.

Tipi di plugin Moodle: quale usare quando

La scelta del tipo di plugin non è estetica — è architettonica. Usare il tipo sbagliato porta a codice difficile da mantenere.

La maggior parte delle esigenze aziendali custom finisce in un local plugin. È il tipo più flessibile: può fare quasi tutto, ha accesso a tutte le API Moodle, e non richiede una UI specifica.

Esempio: stesso requisito, tre soluzioni a confronto

Requisito: l'azienda vuole che ogni nuovo dipendente iscritto a Moodle sia automaticamente iscritto a un corso di onboarding basato sulla propria business unit (recuperata da un campo custom del profilo utente).

Soluzione A — Plugin directory (enrol_cohort): crea una cohort per ogni BU, configura l'iscrizione automatica via cohort. Funziona, ma richiede di mantenere le cohort sincronizzate manualmente (o via script separato) con il sistema HR. Costo: 0 € di sviluppo, 1-2 ore di configurazione.

Soluzione B — Fork di enrol_cohort: modifico il plugin per leggere il campo custom del profilo direttamente invece delle cohort. Costo: 2-3 giorni di sviluppo. Problema: il fork va mantenuto ad ogni update di Moodle.

Soluzione C — Plugin local custom: scrivo un observer sull'evento \core\event\user_created che legge il campo BU dal profilo e iscrive automaticamente l'utente al corso corretto. Costo: 1-2 giorni di sviluppo. Vantaggio: non tocca nessun plugin esistente, è manutenibile in modo indipendente, è estendibile (domani aggiungo la logica per i trasferimenti BU).

La Soluzione C, in questo caso, ha il TCO più basso nel lungo periodo nonostante il costo iniziale di sviluppo.

Scaffold minimale per un local plugin

Per dare un'idea concreta della struttura, ecco il minimo indispensabile per un local plugin:

// local/business_enrol/version.php
<?php
defined('MOODLE_INTERNAL') || die();
 
$plugin->version   = 2026050800;
$plugin->requires  = 2023042400; // Moodle 4.2+
$plugin->component = 'local_business_enrol';
$plugin->maturity  = MATURITY_STABLE;
$plugin->release   = '1.0.0';

// local/business_enrol/db/events.php
<?php
defined('MOODLE_INTERNAL') || die();
 
$observers = [
    [
        'eventname' => '\core\event\user_created',
        'callback'  => '\local_business_enrol\observer::enrol_new_user',
        'priority'  => 200,
    ],
];

// local/business_enrol/classes/observer.php
<?php
namespace local_business_enrol;
 
class observer {
    public static function enrol_new_user(\core\event\user_created $event): void {
        global $DB;
 
        $user = $DB->get_record('user', ['id' => $event->objectid]);
        $business_unit = $user->profile_field_business_unit ?? null;
 
        if (!$business_unit) {
            return;
        }
 
        // Recupera il corso associato alla BU dalla config del plugin
        $course_id = get_config('local_business_enrol', "course_{$business_unit}");
        if (!$course_id) {
            return;
        }
 
        // Iscrizione manuale tramite API Moodle (non tocca il core)
        $enrol = enrol_get_plugin('manual');
        $instance = $DB->get_record('enrol', [
            'courseid' => $course_id,
            'enrol'    => 'manual',
        ], '*', MUST_EXIST);
        $enrol->enrol_user($instance, $user->id, 5); // 5 = student role
    }
}

Questi tre file (più lang/en/local_business_enrol.php per le stringhe) costituiscono un plugin funzionale. Non è una boilerplate complicata — è l'architettura minima che poi si estende.

Calcolo TCO su 3 anni

La colonna che spesso viene dimenticata nella valutazione: il costo del plugin commerciale con licenza annuale nel lungo periodo. Per plugin con licenze da 500-2.000 €/anno, dopo 3 anni il TCO supera spesso quello dello sviluppo custom — che poi non richiede licenze.

Per approfondire il processo di sviluppo custom e le tecnologie coinvolte, leggi la nostra pagina su sviluppo custom Moodle. Se il vostro requisito riguarda la rendicontazione o il tracciamento, leggete anche l'articolo su Moodle e Fondimpresa per casi d'uso simili.

Se state pianificando una migrazione prima di sviluppare nuovi plugin, consultate prima la checklist di migrazione Moodle 3→4→5.

Conclusione: tre punti da portare via

1. Il Plugin Directory è il primo posto dove guardare, non l'unico. Un plugin ben mantenuto con alta adozione è quasi sempre la scelta migliore per funzionalità standard.

2. Il fork è la scelta peggiore nella maggior parte dei casi. Meglio un plugin custom nuovo che mantenere un fork di qualcosa di altrui.

3. Calcolare il TCO su 3 anni cambia spesso la decisione. Il plugin commerciale con licenza annuale sembra economico nell'anno 1. Nel triennio, spesso non lo è.

Hai un requisito che il Plugin Directory non copre? Mandaci 3 righe di descrizione: in 48 ore ti diciamo se esiste già qualcosa o se serve sviluppo custom, e quanto costerebbe.