Una migrazione all'open source non si conclude installando un nuovo programma. Se le persone non riescono a svolgere il proprio lavoro, il cambiamento resta fragile anche quando la scelta tecnica ha buone ragioni.
Nel video rifletto su questo tema a partire da una conversazione con Italo Vignoli al Merge-it, alla quale era presente anche Julian. Non presento un'indagine statistica sui fallimenti: raccolgo gli spunti del confronto e propongo un approccio più attento a chi dovrà usare gli strumenti.
Il costo delle abitudini
L'esempio è il passaggio da Microsoft Office a LibreOffice. Comunicare semplicemente che dal giorno dopo si userà un altro programma non risolve i dubbi su documenti, procedure e funzioni quotidiane.
Una difficoltà non è necessariamente un rifiuto dell'open source. Può essere il timore di perdere tempo, commettere errori o non trovare assistenza. Prima di giudicare la reazione, occorre capire quale attività la persona debba completare e dove incontri un ostacolo.
Nel parlato insisto sulla comfort zone. Non va però usata per liquidare ogni obiezione: possono esistere problemi reali di compatibilità o funzioni indispensabili da verificare.
Spiegare perché si cambia
La formazione dovrebbe cominciare prima dell'installazione. Serve chiarire che cosa si intende per software libero e open source, quali obiettivi abbia la migrazione e quali cambiamenti concreti coinvolgano le persone.
Formati aperti e codice aperto non sono sinonimi: riguardano aspetti diversi dell'autonomia digitale. Spiegarli permette di capire il senso del progetto, invece di percepirlo soltanto come la sostituzione di un'interfaccia familiare.
La scelta va poi tradotta in attività: aprire i documenti abituali, modificarli, condividerli e ritrovarli. È lì che emergono le domande utili alla formazione.
Il supporto deve essere riconoscibile
Una community può offrire risorse preziose, ma rimandare genericamente a un forum non equivale a organizzare l'assistenza di un ente. Chi incontra un problema deve sapere a chi rivolgersi e come ottenere una risposta.
Nel video propongo punti di contatto e momenti di dialogo. Il supporto serve anche a raccogliere problemi ricorrenti, distinguendo ciò che richiede una spiegazione da ciò che necessita di una soluzione tecnica.
Questo lavoro ha un costo organizzativo anche quando il software non richiede una licenza a pagamento. Ignorarlo significa valutare soltanto una parte della migrazione.
Formazione prima, durante e dopo
La mia proposta è mantenere la formazione nel tempo, anziché esaurirla in una presentazione iniziale. Le prime spiegazioni preparano al cambiamento; l'uso quotidiano fa emergere esigenze che prima non erano visibili.
Un percorso graduale permette di provare attività rappresentative, raccogliere osservazioni e correggere le difficoltà prima di estendere il passaggio. Non garantisce il successo, ma rende il progetto più verificabile di una sostituzione improvvisa.
Anche la documentazione deve seguire questo processo: istruzioni comprensibili per le operazioni effettive, non soltanto descrizioni generali del programma.
Dalla discussione a un contributo concreto
Collego questa riflessione al mio impegno in Boost Media e al desiderio di diffondere cultura digitale. L'invito è collaborare con formazione, documentazione e critiche costruttive.
Non considero una distribuzione italiana l'unica scelta possibile, né l'origine del progetto una garanzia di assistenza. Conta che esistano competenze e responsabilità adeguate alle persone coinvolte.
Una migrazione diventa credibile quando mette insieme ragioni del cambiamento, compatibilità dei flussi di lavoro e supporto continuativo. Il software è una parte del percorso; le persone devono poterlo percorrere davvero.
