Che l’informatica necessiti sempre più di una riflessione etica è un dato comunemente condiviso. Quando gli strumenti diventano più potenti e più umanamente pervasivi, è sempre indispensabile riflettere se il loro uso sia o no corretto, se le finalità per le quali vengono utilizzati siano o no buone.
E tuttavia, senza nulla togliere all’importanza di queste riflessioni, c’è un altro senso, a mio parere ancora più importante, in cui l’etica incrocia l’informatica. È il senso in cui l’informatica incorpora già di per sé dei valori morali, il senso in cui insomma non deve aspettare di essere indirizzata da una riflessione etica, perché al contrario è essa stessa che può creare una certa sensibilità morale e umana.
La Ue sceglie Signal: così etica e software libero si prendono la rivincita
Ciò potrebbe essere visto in molti aspetti diversi: non credo che sarebbe difficile mostrare come praticamente ogni grande innovazione nell’informatica sia stata mossa da una preoccupazione umana, a volte anche più esattamente sociale, politica. Qui vorrei provare a mostrare come tutto questo sia vero in un campo limitato sì, ma anche decisivo: quello del software libero.
Software libero e valore morale
Non tanto nel senso che il software libero sia «buono» mentre quello proprietario sia «cattivo» (questo sarebbe un discorso diverso, che comunque avrebbe bisogno di molte precisazioni: è bizzarro assegnare qualifiche morali ad una sequenza di byte!): ma piuttosto nel senso che collaborare al software libero implica attitudini che hanno (queste sì, sicuramente) valore morale.
Partiamo dalla cosa fondamentale: la caratteristica essenziale del software libero non è (come talvolta si crede) il fatto che esso è gratuito: è piuttosto il fatto che chiunque ha il diritto di usarlo abbia il diritto anche di modificarlo come crede, purché riconosca questo diritto a coloro che a loro volta useranno questa versione modificata. È questa appunto la «libertà» che deve qualificare il software. Questo principio può essere formulato in maniere leggermente diverse, ma il suo senso è chiaro: devo comportarmi nei riguardi degli altri esattamente come voglio essere trattato io.
Il principale promotore del software libero, Richard Stallman, esplicitamente notò che questa è nient’altro che un’applicazione del principio dell’etica di Immanuel Kant, il grande filosofo illuminista che ogni studente liceale incontra: «Agisci secondo quella massima della quale tu puoi volere nello stesso tempo che essa divenga una legge universale». In termini più semplici, è anche la cosiddetta «regola d’oro» conosciuta da innumerevoli tradizioni culturali e religiose.
Perché mai modificare un programma dovrebbe essere così importante
Ma perché mai la possibilità di modificare un programma è così importante? Semplicemente perché essa è il segno che un programma non viene trattato come un oggetto da usare, ma piuttosto come un «discorso» nel quale si può entrare, che è permesso fare proprio. Un programma come un semplice oggetto da usare sarebbe come (per usare un esempio estremo) un libro che fosse venduto solo a condizione di essere lasciato chiuso e non essere mai letto: senza dare quindi la possibilità che le sue idee arricchiscano, che le sue parole possano essere riutilizzare ed entrare nei discorsi del lettore.
La disponibilità a collaborare
Anche se tutto questo ha perfettamente senso pure per progetti portati avanti da una singola persona, il caso più tipico e frequente nello sviluppo del software libero è quello in cui si collabora ad un progetto comune. Il motivo è evidente: appena si supera un certo livello di complessità, è praticamente impossibile per una persona sola curare e sviluppare tutti gli aspetti di un prodotto informatico. Ma tutto questo significa che il software libero richiede attitudini tipiche del lavoro comune. La prima è appunto la disponibilità a collaborare: sia nel senso della disponibilità a costruire sulla base di ciò che altri hanno già fatto, sia nel senso della disponibilità a lasciare che altri (anche perfettamente sconosciuti e imprevisti!) perfezionino e modifichino il proprio lavoro. Questa disponibilità è tutt’altro che ovvia: sia perché molto facilmente entra in gioco il sottile orgoglio che spinge a desiderare che una creazione sia solo «propria», sia perché è possibile che prima o poi in un lavoro comune nascano irrimediabili differenze di valutazione sulla sua direzione. Può arrivare il momento in cui si conclude che è meglio dividere le proprie strade? Ovviamente sì, i casi di «fork» (cioè appunto creazioni di progetti paralleli) sono frequenti. Ma è anche vero che questo non è l’ideale, perché ogni cosa grande è il risultato di tante forze che si sono unite.
La disponibilità a collaborare secondo certe regole
Ma oltre a questa disponibilità generica a collaborare c’è anche un altro aspetto che è richiesto: la disponibilità a collaborare secondo certe regole, secondo uno stile che è quello della comunità. Per chi conosce il mondo della stampa, si tratta anzitutto dell’equivalente delle «norme editoriali» che ogni editore o rivista possiede. Nel caso dell’informatica si tratta però spesso anche di cercare di imitare lo stile, il metodo di approccio che è proprio di un certo progetto. Si tratta, insomma, di mettere tra parentesi le proprie personali preferenze per seguire quelle che permettono al progetto comune di essere più uniforme e facile da gestire.
Scrivere il codice in maniera chiara
Oltre all’adeguazione allo stile comune, c’è un’altra regola implicita in ogni progetto collettivo: che si scriva il codice in maniera chiara. La regola in realtà vale pure nel caso che si scriva un programma solo per sé stessi. Come recita una battuta spesso ripetuta, il codice informatico viene scritto una volta, ma letto poi decine di volte: è quindi molto più importante che esso sia facile da leggere come facile da scrivere. Poche cose sono più frustranti che rileggere (magari a distanza di anni) un proprio programma e non capire più come funziona, perché anziché scegliere la strada più chiara è stata scelta la più breve, o la più (inutilmente) veloce, o la più originale. Se questo vale quando si scrive per sé, mille volte di più vale quando si scrive all’interno di una comunità. Sembra un’indicazione facile… finché non ci si sforza realmente di metterla in pratica. La chiarezza e la semplicità a volte sono gli obiettivi più difficili da raggiungere. Spesso il primo modo che viene in mente per codificare un procedimento è contorto, molto spesso per spontanea pigrizia si usano scorciatoie contemporaneamente pensando «io lo so il motivo per cui sto seguendo questa strada». Ma il fatto è che collaborando ad un progetto comune sono anzitutto gli altri che devono capire quale strada è stata seguita, e perché.
L’importanza della brevità
Alla chiarezza contribuisce anche un’altra caratteristica preziosa: la brevità. A parità di altre condizioni, dieci righe di codice si comprendono più rapidamente di cento. La brevità ha però anche un valore aggiunto: la brevità implica anche un minore dispendio di risorse, oppure permette che le altre risorse siano adoperate per altri scopi.
Trovo molto curioso che in un’epoca in cui c’è una giusta preoccupazione per l’impiego delle risorse naturali del nostro pianeta così poco venga detto in favore di un uso moderato delle risorse informatiche, che riguardano il campo tecnologico oggi in maggiore espansione. Senza dubbio giocano un ruolo in questa noncuranza sia il fatto che l’informatica appare singolarmente eterea (in fondo i programmi non sono entità puramente logiche?), sia lo sviluppo rapidissimo della tecnologia (codificato per esempio nella celebre legge di Moore, che osservava che ogni anno il numero dei transistor in un circuito integrato grosso modo raddoppia). Ma il problema è che, se i programmi sono entità puramente astratte, le macchine che li eseguono non lo sono, e il fatto che la tecnologia progredisca rapidamente non significa purtroppo che non consumi preziose risorse.
Un programma dieci volte più breve di un altro può anche essere eseguito su macchine più vecchie, per esempio per chi non può permettersene di nuove. (L’uso della didattica a distanza in un paio di anni di restrizioni sanitarie ci ha fatto vedere quanto il problema sia reale!) Insomma: se quando si collabora a un progetto comune si è spinti a scrivere un codice breve ed efficiente, contemporaneamente si sta contribuendo anche ad un’informatica più a buon prezzo e democratica, e perfino al futuro del nostro caro pianeta.
Mantenere chiari e limitati i propri obiettivi
Collaborare a un progetto informatico comune significa anche mantenere chiari e limitati i propri obiettivi. Il celebre Discorso sul metodo di Descartes stabiliva come seconda regola la suddivisione di un singolo problema in numerosi sottoproblemi: «dividere ognuna delle difficoltà sotto esame nel maggior numero di parti possibile, e per quanto fosse necessario per un’adeguata soluzione». Non credo che esista un campo intellettuale in cui questa esigenza sia più evidente che nella programmazione informatica. «Funzioni», «tipi», «classi», «metodi», «librerie»: queste e altre sono forme oggi ritenute indispensabili tramite le quali un grande problema viene appunto sminuzzato, fino al punto che ognuna delle parti possa essere agevolmente compresa e dominata, e contribuisca ad un obiettivo più grande pure ignorando il funzionamento interno delle altre parti. Edsger Dijkstra esprimeva questo principio come quello che deve guidare «l’umile programmatore»: le dimensioni del cranio sono sempre molto limitate, e un risultato affidabile si può raggiungere solo rimpiccolendo un problema finché esso possa, appunto, entrare nel proprio cranio. E l’«umiltà», cioè il senso delle proprie misure, è una delle qualità umane indispensabili per non precipitare nelle disgrazie (pure informatiche!): le tragedie greche già lo insegnavano molto bene.
Software libero: un lavoro che dà soddisfazioni
Aggiungiamo infine un ultimo aspetto: anche se, come abbiamo detto, il fatto che un software sia «libero» non ha niente a che fare con il fatto che sia gratuito, è pur sempre vero che la maggior parte dei progetti di software libero si basano sul contributo volontario e gratuito di moltissime persone. La spinta per la quale si possa decidere di lavorare gratuitamente è sovente un oggetto di riflessione nel campo delle scienze sociali. Forse la risposta più semplice è questa: perché, indipendentemente da qualsiasi compenso, quel lavoro (piccolo o grande che sia) dà soddisfazione. Dà soddisfazione anzitutto perché pare che gli esseri umani da qualche parte abbiano qualche istintiva tendenza alla socialità. Se poi pensiamo più direttamente al campo dell’informatica, dà soddisfazione perché in ogni programma non banale c’è un aspetto di sfida intellettuale che lo rende molto affine al gioco. Riuscire a risolvere in generale un problema di programmazione, o farlo con una soluzione più breve, più elegante, più chiara, più veloce di quanto fatto finora o di quanto ci si aspettasse, dà una soddisfazione paragonabile a quella della vittoria in un’intricata partita a scacchi.
Conclusioni
Sicuramente non avrei pensato di scrivere quasi nulla di ciò che precede se da circa quattro anni non fossi coinvolto, nel mio piccolo, in una di queste piccole imprese di collaborazione ad un progetto di software libero. Ogni volta che aggiungo qualche contributo mi stupisco sempre nell’osservare come, mentre nella mia normale attività lavorativa sono più o meno spontaneamente inserito in un contesto dove vige il culto dell’originalità e della proprietà intellettuale, lì spontaneamente ragiono al contrario.
Ma non si tratta di una curiosa eccezione: è stupefacente pensare che qualsiasi cosa oggi facciamo col nostro computer, o col nostro telefono, implica sicuramente milioni di righe di software libero, scritte appunto gratuitamente, per contribuire ad una causa comune, e spesso con lo spirito del gioco. Sarebbe bello poter pensare che essere educati al mondo del software libero potesse contribuire in generale ad un mondo migliore, come una sorta di scoutismo informatico.
Purtroppo, le cose non sono così semplici: che attitudini intellettuali e morali possano trasferirsi per osmosi da un campo all’altro dell’esistenza è tutt’altro che sicuro. Ma perlomeno (questo è difficile da contestare), il mondo del software libero mostra come la competizione, l’accaparramento e la proprietà non siano gli unici criteri in base ai quali le società umane possono funzionare.
