Contributo di Giovanni Chiola al dibattito sul "progetto freeware" proposto da A.R. Meo.
I messaggi inviati sulla mailing list sono archiviati alla URL http://majordomo.polito.it/archives/freeware/
Copyright © 1999 Giovanni Chiola, DISI, Università di Genova, via Dodecaneso 35, 16146 Genova, Italia.
Questo documento può essere copiato e distribuito liberamente e su qualsiasi supporto fisico purchè venga mantenuta la totale integrità del testo originale, compresa la presente clausola di copyright.
Scritto a Genova, il 12 febbraio 1999.
Il termine "freeware", ancorchè suoni abbastanza bene, é molto generico e induce parecchi equivoci. La possibilità di equivoco non é una mia opinione: é un dato di fatto constatabile da chiunque si legga i messaggi passati sulla lista "freeware". Concordo con molte altre opinioni espresse sulla opportunità di chiarire meglio quale deve essere l'oggetto della discussione, per evitare che si continui a perdere tempo da un lato scambiando "Roma per toma", e dall'altro lato per cercare di chiarire gli equivoci.
Mi pare che ci sia un consenso più o meno ampio sull'idea di considerare significativo un progetto basato sul concetto di software distribuito oppure venduto in forma sorgente, senza nulla nascondere al cliente/utente del prodotto. Mi pare invece ci sia un dissenso abbastanza generalizzato sull'idea di puntare su un progetto per la produzione di software da distribuire in forma gratuita, senza alcun altro requisito se non il "gratis".
Personalmente concordo su questa impostazione, quindi propongo di coniare un nuovo termine (che ne direste di "meoware"?) per non generare equivoci fastidiosi, a cui associare la semantica desiderata.
La mia proposta di semantica per il "meoware" é quindi la seguente:
software di cui viene distribuito all'utente non solo il codice eseguibile, ma anche il sorgente, la documentazione necessaria per consentire ad una persona esperta di comprenderne il funzionamento interno ed i formati usati per la rappresentazione dei dati. Sulla base del sorgente e della documentazione un qualunque programmatore capace deve essere in grado eventualmente di correggere il meoware o migliorarlo, oltre che di interfacciarlo con altri programmi a completa discrezione dell'utente. Inoltre l'utente che acquista la licenza (pagando o meno un compenso, a seconda della maggior o minor filantropia del produttore di meoware) acquisisce anche il diritto di modificare (direttamente oppure incaricando un proprio esperto di fiducia) il prodotto per adattarlo alle sue esigenze. In caso di sviluppo di prodotti derivati da parte di un utente di meoware, questo o il suo esperto programmatore dovrebbe avere il diritto di ridistribuire il prodotto derivato sempre sotto forma di meoware, eventualmente col vincolo di pagare una royalty non superiore al costo della licenza originale del prodotto allo sviluppatore del meoware di partenza. Nel caso lo sviluppatore del meoware originale volesse distribuire lui stesso il meoware derivato mediante miglioramenti da parte di un cliente del prodotto originario, potrebbe essere lo sviluppatore del prodotto originale a dover pagare una royalty al modificatore, sotto forma di una percentuale del prezzo di vendita della licenza in misura adeguata all'entità delle modifiche apportate
Il fatto che la licenza venga rilasciata in forma gratuita oppure a pagamento, e l'ammontare del costo di acquisto della licenza sono questioni irrilevanti ai fini di questa classificazione, e possono essere lasciati "al libero mercato". Mi aspetto quindi di trovare del "meoware" sviluppato in ambiente universitario e distribuito gratuitamente a tutti, e del "meoware" di interesse commerciale sviluppato da qualche ditta e venduto al costo 100000 Euro per utente. Ovviamente mi aspetterei che nell'ultimo caso si trattasse di una "site license" che consenta all'utente di far girare tutte le copie che vuole su un numero arbitrario di computer di sua proprietà.
É chiaro che ha poco senso lanciare un programma nazionale per produrre software col solo vincolo che questo sia distribuito gratis. La cosa secondo me sensata é invece puntare su un progetto che favorisca la diffusione del software già esistente di alta qualità. La qualità del free software é garantita dal fatto che chiunque può ispezionarne il sorgente e trovarne molto facilmente le pecche, e che molta gente ha effettivamente contribuito a scovare errori inizialmente presenti e correggerli.
Se si trovasse il modo di finanziare lo sviluppo di ulteriore free software
(o, più in generale, di meoware così come definito sopra)
oltre quello già esistente, é evidente che il vero valore
aggiunto continuerebbe ad essere nella disponibilità del
sorgente per correggere errori e migliorarne le funzionalità,
e nella disponibilità delle specifiche dei formati dei dati
per interfacciare tale software con altri prodotti.
Mi pare ci sia un consenso unanime sul fatto che la produzione di software, in Italia in modo particolare, ma anche negli altri paesi, sia in gravissima crisi. Questa diagnosi emerge sia dal documento elaborato da Meo sia dai commenti di tutti quelli che si sono espressi sulla lista. Il punto su cui mi pare invece non ci siano le idee molto chiare é sul chi e cosa ci rimette da questa situazione.
Leggendo i commenti di alcuni sembrerebbe quasi che la grave situazione di crisi coinvolgesse in prima persone solo gli "ingegneri del software" che producono (o dovrebbero produrre) le applicazioni, o le software house che non hanno la possibilità o la capacità di competere. Qualcuno arriva al punto di dire che, se in fondo le software house italiane non riescono a produrre software non meritano di sopravvivere ed é giusto ed accettabile per il paese lasciarle affogare, tanto poi gli utenti si potranno rivolgere alle aziende (straniere) "vincenti".
Non condivido questo atteggiamento (apparentemente) "liberista" non tanto per motivi ideologici ma sopratutto per motivi pratici. A me pare che chi fa un discorso del genere non tenga conto della reale dimensione del problema. Il problema della crisi della produzione di software é principalmente un problema per gli utenti che, pur pagando somme più o meno alte, non riescono a soddisfare le proprie esigenze di acquisizione di software affidabile, sicuro e "durevole".
Come giustamente argomentava Meo nel suo documento iniziale, il vero impatto di un programma nazionale sul tema freeware non sarebbe tanto sui (relativamente pochi) produttori di software italiani. Varrebbe la pena spendere centinaia di milioni di Euro per creare o sostenere qualche decina o poche centinaia di posti di lavoro, ancorchè qualificato? Probabilmente no, o almeno non ora, e nemmeno nei prossimi anni di integrazione europea. Il "super-ministro" Ciampi probabilmente (e giustamente) non si lascerebbe convincere da argomentazioni di questo tipo. I posti di lavoro per produrre scarpe o per vendere hamburger costano molto meno, e da questo punto di vista avrebbe molto più senso un programma nazionale sull'incentivazione della produzione di pizza, piuttosto che di software.
La vera ragione per pensare di lanciare un programma nazionale sull'argomento sarebbe (a mio avviso, ma anche alla luce dei dati contenuti nel documento Meo) l'effetto sugli utenti di sistemi informatici, che oggi si traduce nella quasi totalità della popolazione. Favorendo l'adozione di software di elevata qualità e di cui l'utente disponga del "diritto di proprietà pieno" si potrebbero ridurre di parecchio i costi di gestione dei vari servizi (pubblici e privati) aumentando il livello di accettazione da parte dei clienti per le soluzioni informatizzate. Questo si tradurrebbe in maggior efficienza complessiva per il paese, con riduzioni della spesa sanitaria, maggior efficienza del fisco, maggior efficienze per le pubbliche amministrazioni (centrali e locali), ecc. Il vantaggio diretto in termini di creazione di occupazione nel settore dello sviluppo software non sarebbe che uno degli effetti collaterali positivi del programma.
Sarà capitato a tutti noi più volte di trovarsi alla biglietteria ferroviaria oppure in banca o all'ufficio postale con il servizio bloccato, la coda di persone spazientita e l'impiegato che allarga le braccia imprecando per il fatto che "il computer non funziona" e quindi lui non può portare a termine il proprio lavoro. E quante altre volte invece il "computer funziona" ma quell'operazione banale che serve a noi non può essere completata velocemente perchè non é prevista la relativa opzione nel menu e questo non può essere adattato alle esigenze di quel particolare sportello? Nelle molte volte in cui mi sono trovato in situazioni simili mi sono ben guardato dal dire ai miei colleghi di sventura che io sono un Informatico, sopratutto per vergogna. Automazione di procedure, agli occhi della gente comune é ormai diventato da un bel po' di tempo sinonimo di inefficienza, rigidità, perdite di tempo e di denaro, e tutto questo come risultato di anni di adozione di pessimo software per la gestione di tali sistemi. E la gente comune é talmente abituata all'idea che i "computer non funzionano" che non si aspetta nulla in termini di qualità dal software che é "costretta" ad acquistare.
Mi é capitato più volte di provare a spiegare a parenti ed amici che quegli inconvenienti derivano solo da una cattiva utilizzazione dei computer, e non dal fatto che i computer per loro stessa natura siano strumenti inaffidabili ed inadeguati. Quelle poche volte che ci sono riuscito alla fine la discussione si concludeva con considerazioni sconsolate sul ruolo di noi docenti di Informatica, destinati come Cassandra ad osservare la rovina della nostra disciplina senza avere alcun mezzo per contrastarla.
Per questo penso che, in seconda battuta, il problema sia anche nostro, ossia di tutte le persone che operano a livello professionale nel settore della formazione e della diffusione di metodologie e strumenti Informatici. Per questo, pur non essendomi mai occupato a livello di ricerca di tematiche di "software engineering" in senso stretto (e pur non intendendo iniziare a farlo adesso), mi permetto di dire la mia sull'argomento, e penso che anche tutti gli altri colleghi potrebbero e dovrebbero farlo.
Il problema della produzione di software é diventato troppo serio per permetterci il lusso di pensare che possiamo evitare di interessarcene perchè noi personalmente siamo esperti di Sistemi Operativi, o di Database, o di Logica Matematica, o di Sistemi Esperti, o di Lambda Calcolo e non ci interessano invece gli aspetti di certificazione di qualità del software. Noi professori di informatica non siamo solo coinvolti come utenti di sistemi informatici (anche noi abbiamo bisogno di usare un wordprocessor efficiente per scrivere i nostri begli articoli, una qualche forma di database per organizzare le nostre informazioni, un browser per vedere quello che stanno facendo i nostri colleghi all'altro capo del mondo, ...).
Noi siamo anche interessati al fatto che nei prossimi anni ci sia ancora qualcuno motivato a studiare Informatica! Quale motivazione ci sarà per uno studente italiano fra qualche anno a seguire un corso di laurea in Informatica se ci riducessimo ad insegnare quali tasti si schiacciano per fare l'upgrade da "Windows 2000" a "Windows 2001: Odissea nel Cyber-spazio"?
Forse chi esalta la "creazione di nuovi mestieri" di questo genere
e ritiene che l'Università debba favorire la diffusione di
questa nuova forma di "cultura" per adeguarsi a quello che "il mercato
chiede", essendo più vicino di me all'età della pensione,
pensa di non doversi porre questi problemi.
O forse, grazie alla sua maggior versatilità di ingegno,
pensa di potersi dedicare alla ricerca scientifica in altri settori,
una volta appurato che la ricerca in Informatica "tradizionale"
non ha più ragione di essere considerata una disciplina
scientifica rilevante.
Io invece, non pensando di potermi dedicare con altrettanta efficacia
alla ricerca in settori diversi da quelli che ho studiato fino ad
oggi, ed avendo ancora qualche decina d'anni davanti a me da dedicare
ad un lavoro serio di didattica e di ricerca nel settore Informatico,
ci terrei a che questa disciplina non fosse strozzata dalla mancanza di
prospettive di lavoro qualificato nel settore ne' dalla mancanza di
diffusione delle informazioni ritenute fonte legittima di guadagno
per qualcuno.
Il problema della "certificazione" del sofware mi sembra quello che ha soscitato le maggiori perplessità e divergenze di opinione tra tutti quelli sollevati dal documento Meo. Anche in questo caso provo, con estrema immodestia, a proporre il mio punto di vista di perfetto ignorante in materia, ma di persona che si sente quanto meno coinvolta in prima persona dalla mancanza di una soluzione soddisfacente proposta dagli esperti del settore ed adottata dalla maggioranza degli operatori.
Da perfetto ignorante io ho una mia idea naif della certificazione. Mi immagino un utente senza competenze informatiche (il salumiere sotto casa) che deve adottare un nuovo prodotto software (un sistema di contabilità per il calcolo delle imposte da versare). Avendo letto sul giornale che molti sistemi informatici non sono in grado di trattare correttamente date successive al 31/12/99 chiede ad un suo esperto di fiducia (me, visto che sa che io sono professore di informatica), se il famoso prodotto "Grocery '97" pubblicizzato dall'unica multinazionale attiva in modo significativo nel settore presenta o meno tale inconveniente. Evidentemente io non sono in grado di rispondere se non, forse, comprando una licenza di "Grocery '97" e provando a cambiare il "clock" del sistema a 1/1/00. Il fatto che non esca una segnalazione di errore potrebbe essere considerato un sintomo positivo, ma io non mi sentirei certo in grado di garantire al mio amico salumiere che il sistema funzioni come lui si aspetta. Ben diversa sarebbe la situazione se io potessi trovare su un sito web la documentazione dei formati usati per la rappresentazione dei dati interni di "Grocery '97", perchè a quel punto potrei assegnare il compito di verificare il numero di bit usati per la data e gli algoritmi di manipolazione ad un mio studente quale prova pratica d'esame per il corso di "algoritmi e strutture dati", e coglierei due piccioni con una fava.
Mi sembra evidente che gran parte della difficoltà dei problemi di verifica e certificazione del software, almeno di quelli più drammatici e di maggior impatto pratico sugli utenti, sarebbero notevolmente alleviati dalla distribuzione pubblica delle specifiche del software, in modo da sottoporli all'esame critico di chiunque abbia competenze nel settore. Questo é il metodo che si é dimostrato valido in pratica nel caso del "free software". Questo é l'unico metodo universalmente ritenuto accettabile per verificare la sicurezza di un protocollo crittografico. Proprio la mancata applicazione di questo metodo ha generato il problema del "Y2K Bug" sul quale tutti i "pragmatici" ora piangono e invocano "rottamazioni" del software inadeguato (mentre i "teorici" non si abbassano a prenderlo in considerazione come un problema serio), ma del quale nessuno sta cercando di evitare il ripetersi sotto altre forme.
Non avendo accesso alle specifiche, chi può garantire ad un utente che l'upgrade della licenza di un prodotto che risolve il "baco dell'anno 2000" non introduca invece il "baco dell'anno 2048", se non la speranza riposta nella comprovata avversione di qualcuno verso l'adozione del codice binario e la sua preferenza per il BCD? E a partire dall'anno prossimo chi potrà garantire al nostro povero utente che un upgrade del sistema non introdurrà invece il "baco degli anni tra 1900 e 1999", consentendo solo il trattamento di date dal 2000 al 2099"?
Comprando una applicazione "a scatola chiusa" che consente la contabilità in Euro chi potrà certificare che il sistema sappia poi trattare in modo appropriato l'eventuale inclusione della Sterlina Inglese nell'Euro? Comprando una applicazione per il commercio elettronico chi può garantire all'utente che quella applicazione non sia programmata per memorizzare il proprio "codice segreto", magari per poterlo ricordare al cliente quando questo se ne dimentica, dando così la possibilità ad un criminale che venga casualmente a conoscenza della presenza di questa "funzionalità aggiuntiva" di carpire il codice e rubare soldi al cliente in modo semplice?
Vorrei poi ricordare che ad un utente "naif" il fatto che un prodotto sia "certificato" da questo o da quell'altro importa fino ad un certo punto. Quello che importa all'utente é che il prodotto che ha comprato risponda alle sue esigenze, e nel momento in cui compra un prodotto dovrebbe avere un modo per verificare la rispondenza del prodotto alle sue reali esigenze. Alcuni requisiti sono talmente ovvi che a nessuno verrebbe in mente di enunciarli in anticipo perché a nessuno verrebbe in mente che potessero essere violati da un prodotto software. Software che non rispondesse a questi criteri minimi di accettabilità dovrebbe essere identificabile da persone competenti e additato al pubblico disprezzo per salvaguardare il buon nome del software in generale.
La distribuzione del sorgente e della sua documentazione da parte di chi ha prodotto il software costituisce di fatto una forma di "autocertificazione" piuttosto forte. Dall'analisi del sorgente e della sua documentazione, un qualunque programmatore esperto é in grado di valutare il livello di qualità del software in modo molto più accurato ed approfondito di quanto possa mai fare una certificazione (ISO 9000 o altro) del processo di produzione. Sarebbe molto semplice arrivare a dei confronti di qualità per mezzo di una tecnica più che consolidata in campo scientifico: il "peer review".
Chi pubblica un risultato clamorosamente e dimostrabilmente sbagliato rischia di rovinare la propria reputazione. La necessità di pubblicare tutte le informazioni "interne" su un prodotto software ed anche la sola possibilità ipotetica che qualche "concorrente" si metta a "fare le pulci" ad un prodotto può essere un ottimo deterrente contro la perpetuazione di consuetudini deleterie quali il "rilascio" anticipato del software prima di averne completato il testing in modo soddisfacente, oltre che un ottimo incentivo per elevare il livello qualitativo medio dei programmi.
Secondo me il ruolo della "certificazione" del freeware (o meoware)
dovrebbe essere proprio quello di garantire che i dettagli di
realizzazione abbiano superato l'esame critico di almeno qualche esperto
di programmazione esterno alla organizzazione che rilascia il software.
Il fatto che altri programmatori dichiarino che quella soluzione
del problema é più o meno accettabile e può
creare o meno problemi di questo o quel tipo rappresenta un deterrente
per il programmatore a cercare di "barare", oltre che una forma di
garanzia per l'utente sul fatto che, se anche si fosse rivolto ad un
altro programmatore, comunque difficilmente avrebbe potuto ottenere un
prodotto migliore.
Per una serie di circostanze e coincidenze che sfuggono al controllo di chiunque, il software inteso come "bene di consumo" per utenti non necessariamente esperti di informatica ha delle caratteristiche molto peculiari rispetto a tutti gli altri "prodotti" oggi disponibili sul "mercato". Lungi da me qualsiasi intenzione di teorizzare sui pregi e difetti del "libero mercato" in confronto con altre teorie economico-socio-politiche, mi voglio semplicemente soffermare sulle anomalie che noto per il "prodotto software" rispetto a tutti gli altri prodotti. Oltre alle differenze acutamente messe in luce nel documento Meo circa i costi di sviluppo molto alti ed i costi di "replica e distribuzione" praticamente nulli, mi permetto di far notare che c'é un'altra differenza sostanziale.
Mentre per qualsiasi altro prodotto quando l'utente lo compra il prodotto stesso diventa di proprietà dell'acquirente, il quale ne può disporre come meglio crede, nel caso del software "proprietario" l'utente che "compra una licenza" per l'uso di una applicazione software non diventa proprietario del software che "ha comprato". La proprietà del software rimane normalmente alla organizzazione che lo "distribuisce", e che anche dopo il pagamento continua a dettarne le condizioni d'uso.
Quindi, mentre per le automobili io ho la possibilità di scegliere se andare da un concessionario, comprarmene una ed usarla come meglio credo, oppure rivolgermi ad un noleggiatore e, pagando una cifra nettamente inferiore, prenderne una in affitto per una settimana e utilizzarla solo nei modi pattuiti (per esempio senza uscire dal territorio nazionale), per un qualunque prodotto software io non ho di fatto la possibilità di "comprarlo davvero". Questa differenza, questa mancanza di possibilità di acquisto dei pieni diritti sul software da usare, ha delle implicazioni che possono essere accettabili in alcuni casi, ma assolutamente inaccettabili per l'utente in molti altri. La cosa veramente sorprendente é che nessun utente si ribella per rivendicare i suoi diritti e per imporre quindi ai fornitori di software di fornirgli dei prodotti realmente utili.
Il fatto che quando compro un televisore o una lavatrice mi venga fornita la documentazione tecnica (oltre al certificato di garanzia) mi permette di interpellare un artigiano di mia fiducia per le riparazioni, senza dover per forza ricorrere all'assistenza fornita dal produttore se la giudico non conveniente economicamente o non soddisfacente dal punto di vista dei risultati. Il fatto che quando compro la licenza per un database nel quale voglio memorizzare informazioni per me di importanza critica non mi venga fornita alcuna specifica tecnica sulla sua realizzazione, mi venga espressamente negata la possibilità di provvedere anche a mie spese di risalire al codice sorgente per correggere eventuali problemi derivanti da una cattiva (o volutamente sbagliata) realizzazione del programma, e mi venga espressamente negata qualsiasi garanzia sui danni che questi problemi possono arrecare alle mie informazioni mi mette alla completa merc&eagrave; del distributore di software. Una volta automatizzate le mie procedure e "ingoiati" i miei dati vitali, il distributore di software ha una terribile arma di ricatto nei miei confronti, del tutto paragonabile a quella di un sequestratore di persone.
Tale situazione di dipendenza dell'utente dal fornitore é inaccettabile per qualunque utente, indipendentemente da chi sia il fornitore di software. La richiesta di certificazioni del fornitore per garantirne le capacità tecniche, la solidità economica o i "principi morali" non possono minimamente essere considerati sufficienti per bilanciare questo squilibrio nel caso l'utente sia una pubblica amministrazione. L'unica soluzione accettabile dal punto di vista dell'utente dovrebbe essere quella di pretendere di "comprare davvero" il software da usare, in modo da poterne disporre in tutta tranquillità e senza indebite ingerenze da parte del "vero proprietario".
Secondo me uno dei requisiti fondamentali per consentire la difesa degli interessi degli utenti di prodotti software é la distribuzione del codice sorgente ben documentato e la possibilità legale per chi ha acquistato la licenza di incaricare qualcuno di propria fiducia per portare miglioramenti o correzioni al software originario. Solo così:
Poichè i problemi sopra elencati non sono ipotetici, ma ben reali e sotto gli occhi di tutti, l'adozione di una soluzione accettabile per questi problemi mi sembra debba essere considerata molto urgente, oltre che necessaria per l'economia generale.
Per il software l'idea di stabilire delle regole precise a difesa dei consumatori/utenti sarebbe una innovazione rivoluzionaria rispetto allo "stato dell'arte", ma per quasi tutti gli altri prodotti di consumo i fornitori devono già oggi sottostare a precise leggi sia a livello nazionale che Europeo di tutela degli interessi dei consumatori. Tali vincoli non sono considerati da nessuno retaggi sovietici, ma sono invece considerati anche dai "liberisti" più puri come regole indispensabili per il corretto funzionamento del mercato e della libera concorrenza.
Nessuno ne' in Europa ne' negli Stati Uniti può permettersi di
vendere un'automobile che non sia stata prima omologata analizzandone
le caratteristiche tecniche e la rispondenza a precisi criteri di sicurezza,
impatto ambientale, ecc. Nessuno può vendere al pubblico un
barattolo di marmellata senza l'indicazione precisa degli ingredienti.
Perchè qualcuno deve avere invece la possibilità di vendermi
un sistema operativo che non é in grado di rappresentare correttamente
le date oltre il 1999 senza che io lo sappia ne' abbia modo di
verificarlo?
E poi perchè, una volta scoperto il problema, non devo avere
la possibilità non dico di farmi rimborsare i danni e neanche
il costo della licenza per l'uso di una cosa che non potrò
più usare per un "grave difetto di realizzazione", ma neppure di
correggere o incaricare qualcun altro di correggere il problema
a mie spese?
Non mi pare che sia da considerarsi particolarmente "progressista" o
"sovversivo" chi richiede l'introduzione di elementari regole di
garanzia del buon funzionamento del "mercato".
Questa storia é andata avanti anche troppo, ed ormai sembra difficile pensare di potervi rimediare, anche solo a livello nazionale. Certamente studiare qualche nuova e bella teoria sullo sviluppo del software e sviluppare magari qualche strumento innovativo a supporto di tali metodologie non può minimamente scalfire il problema pratico che ci troviamo ad affrontare.
L'unica speranza che vedo per cercare di incidere in qualche modo sulla situazione é quella di cercare di sensibilizzare gli utenti sul problema, educarli su alcuni aspetti tecnici fondamentali, renderli consapevoli dei loro diritti, "costringerli" a rivendicarli, e mostrargli che in pratica esistono già oggi delle alternative, delle strade percorribili per non sottostare al giogo di chi vuole impossessarsi completamente del "mercato del software" per continuare a realizzare indebiti guadagni a loro spese.
In questo senso noi, come docenti di informatica, abbiamo in primo luogo delle responsabilità precise sulla formazione di persone qualificate destinate ad operare nel settore, e ritengo sarebbe nostro dovere (oltre che interesse personale) garantire che continuino ad essere formate persone in grado di sviluppare applicazioni, di comprendere i dettagli realizzativi del software e che pretendano di "vedere quello che c'é dentro" e non si accontentino di essere certificati dalla onnipresente software house di turno come esperti installatori a scatola chiusa dei suoi prodotti.
Come cittadini particolarmente coinvolti in questi problemi, penso poi che dovremmo agire anche in sede politica, per pretendere che, almeno per quanto riguarda il software da adottare da parte della pubblica amministrazione (e che noi contribuiamo a pagare coi soldi delle nostre tasse), vengano emanate delle norme precise che impediscano alle amministrazioni di "comprare licenze" alle attuali condizioni capestro cui viene abitualmente sottoposto il software "proprietario", imponendo al fornitore, se vuole partecipare alla gara di fornitura del software, di fornire il sorgente, le specifiche, ed il diritto pieno di modifica e miglioramento delle applicazioni.
Già solo una regolamentazione di questo genere (emanata con efficacia vincolante di legge) creerebbe un "nuovo mercato" delle applicazioni software di automazione d'ufficio, database ecc., attualmente non coperto dai monopoli internazionali, e quindi aperto anche alle imprese nazionali con sufficiente capacità tecnica ed imprenditoriale. Certo, se fosse possibile attuare una iniziativa di questo genere a livello Europeo anzichè solo nazionale, le prospettive di successo potrebbero essere ben maggiori, ma per arrivare a questo risultato bisognerebbe arrivare prima a convincere almeno qualche governo nazionale dell'Unione ...
Non sarebbe neanche necessario arrivare a forme di incentivazione economica per le software house che decidessero di lanciarsi in questo tipo di mercato, in quanto queste partirebbero sostanzialmente alla pari con gli altri, ossia dalla possibilità di "customizzare" prodotti freeware già disponibili. Non si tratterebbe certo di una azione di tipo protezionistico o "contro la Microsoft", in quanto anche le multinazionali straniere potrebbero, volendo, lanciarsi su questo nuovo mercato. E se poi fosse proprio la Microsoft a lanciarsi anche su questo nuovo mercato rendendo pubblici i suoi formati proprietari, allora a maggior ragione si tratterebbe di una vittoria fantastica dell'iniziativa "freeware".
Una volta "forzata" la creazione di un mercato per software che viene "realmente comprato" dagli utenti e non solo "affittato a condizioni capestro", sarebbero gli utenti stessi, una volta sensibilizzati al problema e "scottati" dal mercato attuale a poter scegliere liberamente in funzione delle loro esigenze, disponibilità economiche e strategie di impresa.
In questa ottica mi pare che anche l'idea di un progetto nazionale
sul freeware potrebbe assolvere un suo ruolo importante, favorendo
un bootstrap anche in Italia di sviluppo di applicazioni a partire
da componenti freeware, magari inizialmente pilotato da Università
ed enti di ricerca in cui é maggiore il livello di conoscenza
sul free software esistente, ma poi certamente sostenuto anche
dall'iniziativa privata
(che in altri paesi informaticamente più avanzati ha già
capito quali siano le opportunità da cogliere).
A mio avviso gran parte della responsabilità dello stato attuale di soggezione degli interessi degli utenti rispetto a quelli dei produttori e distributori di software risiede nella mancanza di educazione degli utenti stessi. É l'ignoranza degli utenti che li porta ad accettare di "comprare" un prodotto di cui non saranno mai proprietari anche dopo aver pagato la licenza iniziale e tutti i canoni periodici di manutenzione ed aggiornamento. É l'ignoranza degli utenti che li porta ad accettare che sia il produttore stesso a "certificare" i suoi prodotti senza sottoporli all'esame critico di nessun esperto esterno. É l'ignoranza degli utenti che li porta ad accettare di pagare una licenza per usare prodotti di qualità provatamente inferiore a quella di prodotti disponibili gratuitamente.
Mi pare che le iniziative avviate di "alfabetizzazione informatica" anche all'interno di scuole ed università siano organizzate in modo da perpetrare questa ignoranza piuttosto che ridurla. Una iniziativa come il progetto "freeware", se ben impostata ed affidata a persone oneste e capaci, potrebbe avere un impatto significativo su questo aspetto, che io ritengo fondamentale, del problema. Incentivando la "cultura del free software" all'interno delle università, infatti, oltre che (forse) produrre qualche applicazione nuova, si contribuirebbe notevolmente alla diffusione delle applicazioni esistenti, rendendole più visibili come valide alternative a molti prodotti "proprietari".
Teniamo presente, infine, che proprio la disponibilità di software significativo in forma sorgente é stato il fattore determinante per la formazione di un gran numero di programmatori qualificati, anche qui in Italia. Qualcuno riesce ad immaginare un corso universitario avanzato su sistemi operativi senza la disponibilità del codice di un (più o meno) "vero sistema operativo" come Minix o Linux? Credo che qualsiasi corso di Informatica a livello universitario con qualche minima valenza applicativa oltre che teorica richieda l'accesso degli studenti quanto meno alle specifiche ad alto livello del software, se non al suo codice sorgente vero e proprio. Chi ritiene che occuparsi di free software non sia abbastanza "nobile" dal punto di vista accademico dovrebbe forse ricordare che tra i doveri accademici ci sono anche quelli didattici, oltre che quelli scientifici, e che sia la produzione che la diffusione della cultura sono i compiti primari dell'università.
Da questo punto di vista non vedo quale altra istituzione meglio
dell'Università dovrebbe mostrare interesse per una attività
di promozione di software di alta qualità accompagnato da
documentazione pubblica e completa.
E visto lo stato attuale della gestione delle risorse finanziarie
mi sembra evidente che, se si vuole che l'Università sia
in grado di assolvere a tale ruolo, ci voglia anche un minimo di
incentivazione economica per chi é chiamato a svolgere questo
compito aggiuntivo ed indispensabile per il bene nazionale.