WMTools n.ro 19
di Andrea Monti
Uno dei paragoni che ricorre con ossessiva frequenza quando si parla di IT è quello con il mondo dell’automobile. Sono oramai consegnate alla storia le innumerevoli boutade circolate nell’internet su cosa accadrebbe se certi sistemi operativi fossero autovetture e viceversa. Questa volta però vorrei tentare un altro paragone e mi chiedo: cosa accadrebbe se i programmi fossero banane? Risposta se i software fossero banane dovrebbero fare i salti mortali per meritare il bollino blu, e quelli che non saltano abbastanza in alto sarebbero immediatamente riconoscibili ed estromessi dal gioco.
Fuor di metafora (e a parte gli scherzi) affrontare il problema della garanzia sul funzionamento del software diventa sempre più urgente, perché oramai quest’idea della licenza “as is” (cioè nelle condizioni in cui il programma si trova al momento dell’acquisto del pacchetto) comincia a perdere sempre più significato. È abbastanza chiaro che nella prospettiva di una dipendenza dalla qualità del software delle attività aziendali e dell’e-business in particolare sempre più accentuata non è più pensabile servirsi di strumenti poco efficienti ma soprattutto dei quali non si sa praticamente nulla. Vi siete mai chiesti, consultando i risultati di una complessa analisi finanziaria condotta con un foglio elettronico, se i risultati fossero veramente giusti, oppure quante volte – preda di quella che Winn Scwhartau chiama binary schizophenia – avete ricontrollato con la calcolatrice da tavolo un conteggio che “a naso” non tornava?
Il punto è che oramai ci siamo abituati (o ci hanno fatto abituare) al fatto che i programmi più o meno “funzionicchiano” fra un crash e l’altro del PC, fra un virus e una perdita di dati, fino al punto di considerare la cosa assolutamente normale
Non è così, eppure quello del software è l’unico settore nel quale ai produttori è consentito impunemente di mettere sul mercato un prodotto senza offrire alcuna garanzia sul suo funzionamento e sulla robustezza intrinseca della sua realizzazione. In altri termini, a fronte delle spesso notevoli cifre sborsate per l’acquisto di una licenza d’uso, a parte qualche gadget e la scheda di registrazione non si ottiene assolutamente nulla in cambio, se non l’uso di un software che probabilmente non funzionerà come deve.
Contro questo stato di fatto nessuno o quasi ha mai osato protestare e i produttori – che nel frattempo guadagnano sui contratti di manutenzione e sulla commercializzazione di service pack, upgrade e via discorrendo – si sono sempre difesi sostenendo che il software è un “materiale” talmente complesso che non è possibile garantirne al 100% la funzionalità. Se da un lato questa affermazione è politically correct (nel senso che in effetti non si può prevedere ogni ambiente nel quale il programma andrà a funzionare) dall’altro è concettualmente inaccettabile e giuridicamente sbagliata. Un conto infatti è dire “non posso garantirti che la cosa funzionerà, ma ti garantisco che ho fatto del mio meglio per farla funzionare”, un altro conto è dire, come accade normalmente, “non solo non ti garantisco che la cosa funziona, ma mi chiamo fuori da qualsiasi problema che si dovesse presentare”.
In altri termini, anche allo sviluppo di software si applica la normale regola di diligenza che vale per qualsiasi attività, e dunque – con buona pace del ponziopilatismo che domina i contratti di licenza – se un software è fatto con i piedi, questo genera responsabilità a carico di chi lo ha sviluppato. Passando dal teorico al pratico, la prova della malafede di molte software house è contenuta in tre lettere “Y2K” (altresì note come “Millennium Bug” che – detto per inciso – è l’errore di una miope cultura aziendale e non un problema tecnico). Da quando il mondo si è accorto del “problemino” causato dal gestire le date con due caratteri invece che con quattro, sul mercato si cominciano ad intravedere applicativi sui quali campeggia la dicitura “pronto per anno 2000” o equivalenti. Tradotto dalla lingua dei pubblicitari al giuridichese, questo significa che l’applicativo in questione è garantito in rapporto a quel particolare difetto, cioè che è stato progettato e realizzato per non creare problemi con la gestione delle date. No, un attimo, fermi tutti – dice lo sbigottito utente finale – Ma allora questo significa che anche quando si parla di software si può garantire qualcosa!
La risposta è chiaramente positiva, con un’aggiunta, però: esiste una significativa differenza o meglio disparità di trattamento nella categoria degli sviluppatori. Se il programma difettoso lo ha realizzato una piccola software house, i clienti non scuciranno una lira fino a quando il tutto non funzionerà alla perfezione. Quando il “pacco” arriva da un gigante, non solo tutto viene pagato, ma vengono sottoscritti pure i contratti di manutenzione e aggiornamento; come dire: farsi pagare per correggere i propri errori. Misteri dell’universo aziendale!
Poi, nello specifico, ci sarebbe da affrontare il discorso del perché – essendo Y2K un fatto noto da svariati anni – siano stati immessi sul mercato dei prodotti (applicativi e sistemi operativi) che solo nell’ultima release dichiarano di essere esenti dal questo difetto, e del come mai ciò che costituisce un errore di chi realizza i programmi, si traduce in un esborso ulteriore per l’utente.
Ma questa è un’altra storia.
Possibly Related Posts:
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Le sanzioni UE ad Apple e Google aprono un altro fronte nella guerra contro Big Tech (e incrinano quello interno)
- Il caso Crowdstrike rivela le cyber-debolezze Ue
- GDPR e OpenAI: quanto sono fondate le accuse del Garante?
- L’ AI open source non è un crimine e non aiuta i criminali