Roma, 5 Dicembre 2003
e-learning e software libero: un rapporto sostenibile?	Versione del 26/11/03

Approfondimenti

Il tema del convegno

E-learning e software libero: un rapporto sostenibile?
Parole chiave: opensource, sostenibilità, standard, costi, cooperazione, apertura

Il convegno vuole esser un incontro di discussione aperto a tutti coloro che vogliono ragionare sulla possibilità (e l'opportunità) di utilizzare piattaforme OpenSource per la Formazione a Distanza.
Lo scopo dell'incontro è duplice, sia teorico che pratico.

• Da un lato si discuterà degli aspetti teorici e pratici, oltre che tecnici, impliciti nella scelta dell'utilizzo di software liberi per la gestione di portali e-learning.
  C'è un rapporto tra la costruzione collettiva della conoscenza e l'impostazione didattica aperta e collaborativa dei corsi a distanza?
  Qual è la sostenibilità di un'iniziativa di formazione a distanza in cui i costi maggiori vengano assorbiti dai compensi per lavoro e non dal pagamento di licenze, in particolare per scuole, centri di formazione, Università etc.?
  Quali standard concreti possono essere adottati per garantire l'accessibiità e l'interoperabilità dei corsi e la portabilità delle piattaforme?
  Queste le domande verranno poste a chi concretamente ha introdotto in Italia e sta usando tecnologia opensource nella formazione a distanza.

• Lo scopo pratico dell'incontro consiste invece nell'offrire la possibilità a figure professionali come giornalisti, responsabili delle decisioni degli enti di formazione, amministratori di sistema e formatori etc di 'mettere le mani' sulle piattaforme opensource già esistenti e funzionanti.
  L'intenzione è di mostrare "dal vivo" alcune piattaforme GPL, italiane e straniere: Claroline, ILIAS, Moodle, Fle3, Adept, Chirone e ADA.
  

Il tema del seminario

Gli standard non scritti dell'elearning opensource
Parole chiave: portabilità, interoperabilità, accesibilità, SQL, templates, Learning objects, XML, HTML4

Pur se lentamente, la FaD si sta diffondendo anche al di fuori del mondo aziendale. Attualmente lo scenario più comune è quello di un'Amministrazione pubblica, un'Ateneo come un Ufficio scolastico regionale, che "adotta" una piattaforma unica che viene offerta a tutti i docenti per ospitare i loro corsi online. E' però probabile - o almeno possibile - che man mano che si precisano i bisogni delle singole discipline verrà riconosciuta una specificità maggiore alle piattaforme e si andrà verso modelli "multipiattaforma".

Se questo fosse vero, diventerebbe sempre più importante poter trasferire contenuti (interi corsi o semplici Learning Objects) da una piattaforma all'altra, poter condividere dati da un database all'altro, poter riportare moduli software specifici da una piattaforma all'altra.
Un limite grosso a questo trasferimento è sicuramente rappresentato dalla natura chiusa del software proprietario; ma anche in ambito opensource possono nascere, e difatti nascono, difficoltà tecniche se non legali dovute alle differenze di architetture, formati, linguaggi etc.
Se il rispetto formale degli standard esistenti (AICC, SCORM,...) rischia di essere un giogo troppo pesante per gli sviluppatori OS, forse alcune regole generali possono essere facilmente condivise.
D'altra parte, l'uso di piattaforme OS al di fuori del mondo aziendale implica anche necessariamente una maggiore attenzione per le differenze tra gli utenti, tanto in termini di tecnologie che di preferenze o di canali sensoriali per l'accesso.

Quali soluzioni strategiche, oltre che tecniche, vanno elaborate per affrontare questi problemi? Sono possibile strade diverse.

1. A livello di standard: si può richiedere ad ogni piattaforma OS la conformità ad alcuni principii generali (p. es. indipendenza delle funzioni di accesso al DB dallo specifico dialetto SQL, indipendenza del codice dall'interfaccia utente, uso di formati di scambio etc).
2. A livello di architettura: possono essere definiti degli strati completamente autonomi (interfaccia, logica, db) che possano essere interfacciati liberamente tra di loro
3. A livello di strumenti di supporto: bisogna muoversi nella direzione della scrittura di moduli di conversione tra un formato e l'altro, tra un DB e l'altro.
4. ci sono altre strade possibili? e quali?

Ecco quindi le domande alle quali risponderanno i partecipanti:

1. quale di questi problemi vi sembra più urgente
2. quale strategia generale (A,B,C,?) vi sembra vincente, e perché
3. quale soluzione avete adottato, o quale secondo voi andrebbe adottata