Il sociologo, la sociologia e il software libero: open source tra società e comunità/Capitolo 2/2

Da Wikisource.
2.2 l'economia informale e formale

../../Capitolo 2/1 ../../Capitolo 2/3 IncludiIntestazione 20 agosto 2011 75% Da definire

Capitolo 2 - 1 Capitolo 2 - 3

Considerando il software libero come una peculiarità economica sostanziale anziché formale implica che non possa sussistere l'economia formale senza l'economia sostanziale (Polanyi, 1977). Il fatto che il software libero abbia grosse implicazioni dal punto di vista dell'economia formale non fa altro che confermare questa tesi. Polanyi (1977) distingue efficacemente tra economia del dono (Mauss, 2002) basata sull'abbondanza ed economia formale basata sulla scarsità.

Nella fattispecie del software libero è quindi più che plausibile il sussistere di una risorsa per sua natura abbondante utile a gestire risorse scarse. Il software è automazione di processi che veicolano informazione al fine di supportare le decisioni. Il software ha quindi la sua peculiarità nei processi decisionali, quindi trova la usa naturale utilità nei processi organizzativi e quindi anche nell'ambito dell'economia formale e non. Si pensi ad esempio quanto tempo risparmiamo facendo pagamenti on-line anziché fare la file allo sportello, quanto tempo risparmiamo spedendo una lettera con la posta elettronica anziché attraverso una busta e gli esempi sarebbero tantissimi. In particolare il software abbondante ottimizza molto bene una risorsa scarsissima che è il tempo. A questo punto ci basta solo dimostrare che il software è per sua natura abbondante mentre il fatto che il tempo sia una risorsa scarsa nelle società moderne non ha bisogno di troppe dimostrazioni.

Il software, o meglio la produzione di software ha in realtà dei costi altissimi e questo contraddice l'idea di abbondanza. Una volta prodotto non costa nulla ri-produrlo e, meno che meno, distribuirlo attraverso la rete. Nello sviluppo software sono alti i costi di progettazione, se vi includiamo la stesura del codice, di fatto anche gli ambiente di sviluppo gestiscono, in termini tecnici informatici dei progetti, in generale con il termine progettazione includiamo l'attività progettuale in senso cognitivo1. Nell'industria automobilistica invece sono maggiori i costi di produzione e distribuzione per ovvi motivi. Inoltre la maggior parte di codice è dedicato a soluzioni personalizzate. Secondo una stima commissionata dal Ministero per l'Innovazione Tecnologica del governo italiano del 2003, dal 35% al 45% delle spese informatiche della pubblica amministrazione riguardano personalizzazioni, mentre il 10 - 20% riguarda pacchetti di base, il rimanente 35 - 55% riguarda la formazione e il mantenimento. In media le spese per la personalizzazione sono 2,9 volte quelle per le licenze. Questo significa che le licenze d'uso essendo codice replicato in quanto non personalizzato costituisca una fetta ancora minore in termini assoluti del codice scritto ad uso personalizzato. Sia i pacchetti di base che il codice personalizzato sono acquisiti come closed source, con formule riconducibili al copyright. Inoltre la netta prevalenza di codice personalizzato è indice di scarsa efficienza in termini di scarsa riutilizzazione.

Molte soluzioni personalizzate sono necessariamente monolitiche2, a volte solo per piccole differenze strutturali delle diverse amministrazioni pubbliche questi pacchetti non possono essere riutilizzati. Se il codice fosse aperto diverrebbe molto più semplice adattare il codice alle diverse peculiarità organizzative. Possiamo prendere ad esempio un sistema per la gestione degli automezzi (car sharing) in dotazione ad un'organizzazione sviluppato negoziando con gli utenti le sue funzionalità, come ad esempio la possibilità di forzare la prenotazione dell'auto da parte di alcuni referenti o la possibilità di utilizzare alcuni mezzi solo da parte di alcuni specifici profili di ruolo. Un software così personalizzato se chiuso, cristallizzato non potrà mai essere usato da un altra amministrazione con esigenze anche solo leggermente diverse, mentre se sviluppato con criteri open source potrà essere facilmente riusato, cambiando poche righe di codice, da una qualsiasi altra organizzazione con simili esigenze.

L'indagine commissionata del Ministero dell'Innovazione Tecnologia del 2003 conclude con il suggerimento per la pubblica amministrazione di optare per l'open source in funzione del riuso. Open source in questo senso viene inteso come caratteristica tecnica dell'open source da cui deriva indirettamente un'idea di qualità. Il riuso richiede una forte capacità del software di adattarsi ai diversi contesti organizzativi e questo avviene più facilmente attraverso l'open source. La spesa pubblica nel settore informatico è significativa per i nostri scopi in quanto rappresentativa del mercato nel suo complesso considerato che in Italia, nel 2003 la spesa totale in software per la pubblica amministrazione è stata di 45 milioni di euro. Spesso si parla di software libero e open source come assurdo economico ma a guardar bene ciò che risulta difficile spiegare è la chiusura del codice, la richiesta di brevetti, la pretesa di diritti d'autore su prodotti molto personalizzati. Si fatica ad immaginare come il software di gestione degli automezzi, di cui si è fatto l'esempio più sopra, possa essere adeguata per una qualsiasi altra organizzazione.

Non vi è garanzia che chiudendo il codice se ne possano derivare dei vantaggi in termini di dipendenza del committente da chi ha sviluppato il software, il cosiddetto lock-in. I fattori che intervengono sono molti. In prima istanza la reputazione. L'ennesima volta che il “locker”, o “pusher” nel gergo del software libero, chiederà una cifra “esagerata” per adattare il “suo” prodotto a nuove esigenze del cliente il cliente tenterà di svincolarsi da questo ricatto continuo, e comunque tenterà di rivolgersi a qualcun altro per ulteriori esigenze. A questa minore garanzia della chiusura del software inoltre si affianca una diversa idea di fare “business”. Se il produttore di software distribuisce il suo prodotto in forma open ha maggiori possibilità che lo stesso possa essere eventualmente adattato e adeguato anche in-house (autonomamente dal cliente). Il fatto che lo stesso software abbia maggiore possibilità di essere mantenuto nel tempo gioca a favore della sua reputazione e quindi della reputazione di chi lo ha prodotto. Il fatto che sia distribuibile in fine non fa che aumentare le probabilità che chi ha prodotto quel dato software venga interpellato per adeguarlo, mantenerlo o implementarlo ulteriormente.

Note

  1. diversamente da come fa invece la scuola di ingegnerizzazione del software che si rifà al modello top-down, che vedremo più avanti distingue nettamente la progettazione dalla fase di sviluppo.
  2. contengono solo codice sviluppato appositamente per quella soluzione.