|
There are no translations available.
Qualità del software libero e di quello proprietario L'autore di questo articolo ha tentato molte volte con poco successo di convincere imprenditori e responsabili di aziende italiane ad adottare software libero per costruire i vari programmi applicativi. – "È vero che non dovrò pagare le royalties" – gli osservavano – "ma chi mi garantirà la qualità del prodotto? chi mi assisterà nella manutenzione? –.
E ancora, su sollecitazione del solito grande esperto della nota società internazionale di consulenza: "Il software libero è noto a tutti, e quindi "hacker" e "cracker" ci sguazzano.
Chi mi proteggerà dalle intrusioni?" Esaminiamo separatamente le tre questioni della qualità, dell'assistenza tecnica e, infine, della sicurezza, iniziando dalla prima e probabilmente la più importante, la qualità.
È molto difficile formulare un giudizio obiettivo sulla qualità di un prodotto software. Probabilmente come conseguenza della soggettività del giudizio il dibattito sul confronto della qualità del software proprietario e del software libero è cosí infuocato. Da un lato, i produttori del software proprietario sostengono che non può offrire alcuna garanzia di qualità il frutto di un lavoro collettivo svolto con modalità caotiche e anarcoidi da una pluralità di lavoratori disseminati sulla superficie dell'intero pianeta, riuscendo facilmente con questa argomentazione a convincere la grande maggioranza degli imprenditori e dei manager nostrani.
Sull'altro fronte, i sostenitori del software libero rilevano la qualità eccezionale dei prodotti più noti del loro mondo - Linux, Apache, BSD (Berkeley Software Distribution, UNIX) - e ne deducono una legge universale sulla superiorità del software libero.
Uno dei più importanti esponenti di questa scuola di pensiero, artefice anche della Debian Society, è Eric Raymond, che in un saggio molto noto nella comunità mondiale degli informatici. La cattedrale e il bazar, [7] ha raccontato e analizzato la storia di Fetchmail, un programma libero per la gestione remota della posta elettronica, traendo dal successo di quell'esperienza indicazioni di carattere generale sull'intero universo del software libero.
Nel suo saggio Raymond confronta il processo di produzione del software caratteristico di un'azienda importante, ove ogni atto è parte di un rituale collettivo preordinato, preciso, gerarchico, con il processo caratteristico del software libero, ove come in un bazar una moltitudine di soggetti si scambiano beni in modo caotico, senza disciplina e autorità superiori. Diciannove regole d'oro costituiscono secondo Raymond le chiavi del successo di un prodotto software; quasi tutte sono applicabili soltanto nel bazar.
Sinceramente, molte delle argomentazioni proposte da Raymond suscitano, a giudizio di chi scrive, qualche perplessità. Complessivamente, la cattedrale sembra, a chi scrive, un luogo più idoneo del bazar allo sviluppo del software.
Tuttavia, due ragioni fondamentali potrebbero spiegare la presunta superiorità dei migliori prodotti del software libero rispetto ai corrispondenti prodotti del software proprietario.
La prima è la possibilità di buttare in campo centinaia di utenti programmatori nella fase di debugging.
Raymond attribuisce a Torvalds il seguente enunciato, noto appunto come "Teorema di Linus": "Given enough eyeballs all bugs are shallow" ossia " Date tante pupille, tutti i bachi diventano bazzecole".
La seconda ragione è sintetizzata dall'osservazione che nove donne in un mese non fanno un bambino. I programmatori liberi lavorano per la soddisfazione personale e la stima degli amici, senza fretta avendo la qualità come obiettivo centrale. I programmatori delle aziende che vendono software su licenza devono produrre una nuova versione ogni due anni, per non uscire dal mercato e produrre nuovo fatturato. Ma la complessità dei nuovi prodotti cresce molto rapidamente e soltanto sacrificando la qualità è possibile superare le sfide della complessità. Assistenza tecnica Dal punto di vista industriale la questione dell'assistenza tecnica è uno dei fattori più importanti che giocano a favore dei grandi a danno dei piccoli. La piccola software house di Paperino, ad esempio, che producesse un prodotto di grande interesse per il mercato non riuscirebbe a diffonderlo perché non disporrebbe disporrebbe delle risorse finanziarie per creare un'adeguata rete di assistenza. Per contro, Paperone ha attuato un meccanismo per l'assistenza ai propri prodotti che, secondo alcuni fanatici sostenitori del software libero, rivela la sua natura diabolica ma che più razionalmente, si deve riconoscere, dimostra il genio della finanza. Infatti, la multinazionale di Paperone incarica aziende specializzate di organizzare corsi di specializzazione per aspiranti tecnici di assistenza e incassa denaro per l'iscrizione ai corsi, l'organizzazione degli esami e la concessione dei diplomi. Così, la creazione di una rete capillare di assistenza basata su competenze di alto livello, che a Paperino costerebbe come mille fatturati annui, contribuisce al riempimento delle leggendarie casseforti di Paperone.
Tuttavia, a dispetto di questi meccanismi finanziari e dell'obiettiva capacità delle multinazionali di creare reti di assistenza di alto livello, la superiorità delle multinazionali del software proprietario rimane discutibile.
Infatti, quando la complessità del problema dell'attuazione della funzionalità particolare o dell'integrazione con altri prodotti supera un certo livello, allora diventa necessario per il tecnico conoscere a fondo cosa fa il prodotto, e come lo fa, e per questa conoscenza è necessaria l'analisi del codice sorgente, che Paperone non consente per non correre il rischio di essere copiato (o scoperto nel caso che uno dei suoi programmatori avesse copiato qualcosa).
Così, alla superiorità economica si contrappone un'intrinseca debolezza tecnica che in prospettiva non potrà non condizionare pesantemente lo sviluppo del software proprietario. Sicurezza Talvolta qualche sostenitore del software proprietario propone un'argomentazione quasi "truffaldina" che all'analisi non troppo meditata di un dilettante potrebbe apparire ragionevole: afferma, ad esempio, che i prodotti chiusi possono contare su livelli di sicurezza più elevati, e in particolare su una migliore crittografia, rispetto ai prodotti aperti, che adottano algoritmi noti a tutti in quanto il loro codice può essere letto e studiato a fondo.
E invece è proprio vero l'esatto contrario, infatti, in linea teorica, la crittografia costruita su chiavi sufficientemente lunghe è assoluta- mente imbattibile in quanto non è noto, e forse non lo sarà mai, un algoritmo per batterlo.
Ma i sistemi crittografici spesso presentano punti deboli, generalmente rappresentati da chiavi troppo corte e da soluzioni tecniche per la distribuzione delle chiavi attaccabili con vari stratagemmi. Cosí, sicurezza e crittografia sono obiettivi molto difficili, forse i più difficili dell'informatica e, per raggiungere una ragionevole tranquillità, occorre sottoporre procedure e algoritmi a verifiche severe condotte da molti studiosi di alto livello, possibilmente appartenenti ad ambienti diversi.
Per sapere se una serratura è sicura, occorre affidarla a uno o più esperti, che la aprano e la studino a fondo per verificare che non possa essere aperta con un idoneo chiavistello.
Se la serratura non può essere aperta, perché affogata, ad esempio, in un blocco di cemento, non è possibile verificare se quella è una buona o cattiva serratura. Un ladro professionista potrebbe corrompere il fabbro che ha costruito la serratura, farsi spiegare come funziona e costruire un idoneo chiavistello; viceversa, se la serratura è perfetta, non esiste un chiavistello in grado di aprirla.
|
