Nel 1984 Richard Stallman, computer scientist presso il MIT, ragiona sulla scarsa qualità del software che giunge sul mercato. Alla luce della sua analisi, la causa risiede nelle caratteristiche del processo di sviluppo, nella documentazione, nella manutenzione del prodotto licenziato. L’attenzione dedicata dagli sviluppatori al debugging (all’eliminazione di imperfezioni ed errori nel codice) è insufficiente.

La softwarehouse profit oriented deve necessariamente tendere a portare sul mercato il prodotto il più presto possibile. Inoltre, il modello organizzativo adottato dalle softwarehouses non è in grado di generare la necessaria attenzione alla eliminazione degli errori. Il lavoro è parcellizzato e l’obiettivo comune è, per le risorse coinvolte, scarsamente visibile. Il lavoro svolto è scarsamente documentato, perché lo sviluppatore, non sentendo proprio il progetto, non è stimolato a socializzare le conoscenze (tende anzi a lasciare margini di oscurità in merito al lavoro svolto, sia per gioco, sia per garantire la propria indispensabilità futura). La manutenzione –e cioè il debugging progressivo del prodotto licenziato, ed il suo aggiornamento a fronte di nuove esigenze manifestate dagli utenti– è realizzata in modo insoddisfacente: la softwarehouse ha scarsa convenienza ad investire in mantenimento di un prodotto già venduto, perché è difficile farsi pagare dai clienti questo servizio; inoltre è onerosa e di difficile gestione la gestione dei flussi informativi provenienti dai clienti: raccolta delle informazioni sulle disfunzioni e sulle implementazioni richieste, definizione delle priorità negli interventi.

Dunque un software non sarà mai del tutto liberato da imperfezioni (bugs); un software può essere continuamente migliorato. Ma c’è di più: lo sviluppo di un software è parte di un processo senza soluzione di continuità e senza termine. Il software si produce a partire da software ed è materia prima di altro software. Il processo è sfumato nei passaggi, ma anche nell’input e nell’output. A monte e a valle della conoscenza codificata in software sta altra conoscenza prodotta e riprodotta in continuo da soggetti pensanti (knowledge worker). Rispetto a questo processo ogni software è solo (a seconda di come si guardino le cose) mezzo di produzione o semilavorato.

Queste peculiarità rendono centrale una domanda: quando, e in base a quale criterio, può un software essere ‘rilasciato’, reso disponibile per l’utilizzo?

Se il software è destinato ad essere venduto, il momento sarà di fatto definito da ragioni di tipo economiche. Gli investimenti destinati al progetto terminano, e a quel punto si decide che il progetto è concluso. Tanto, in qualche modo, il software ‘funziona’. Oppure il momento del rilascio è stabilito a partire da scelte di marketing: è indispensabile arrivare sul mercato entro la tal data, per anticipare o rincorrere i competitori.

Si tratta di vincoli esterni, del tutto slegati da riflessioni sulla capacità del prodotto di rispondere ai compiti ai quali è destinato. Dunque, un software deve essere rilasciato, i progetti debbono terminare e produrre effetti. Ma come individuare i modi ed i momenti?

Il passaggio chiave visto da Stallman sta nel non contentarsi dei vincoli esterni. Ed anzi nell’avere il coraggio di chiedersi come potrebbe essere prodotto il software al di fuori delle condizioni di mercato, e storiche e culturali, all’interno delle quali lui stesso si trovava a produrre software.

Stallman pensa così che se il software è conoscenza, il migliore contesto per la crescita della conoscenza (per il suo miglioramento continuo) è una situazione dove la circolazione delle informazioni è libera e trasparente. Solo se il gruppo di progetto avrà una visione complessiva del lavoro e pieno accesso alle informazioni il lavoro potrà essere veramente efficace. Solo se tutti gli utenti, a tutti i livelli, saranno coinvolti nel miglioramento continuo del codice, il software potrà progressivamente essere liberato dai bugs.

Dunque da una riflessione sulle criticità insite nello sviluppo del software nasce –con Stallman, [1] poi con Raymond [2] e con Torvalds, [3] e in genere con il contributo di un numero sempre crescente di appartenenti alla comunità professionale degli sviluppatori di software– un nuovo approccio alla condivisione delle conoscenze ed alla organizzazione del lavoro, di cui Linux è il caso ed il frutto esemplare. [4] I risultati del gruppo di lavoro che ha prodotto Linux (ma è solo un caso tra tanti) dimostrano come attraverso meccanismi di cooperazione volontaria, di coordinamento orizzontale, di autoregolazione, di condiviso orientamento alla qualità è possibile ottenere risultati che mettono in discussione consolidate prassi e teorie relative al controllo e al project management.

Perciò il movimento dell’Open Source e del Free Software [5] meritano attenzione: non tanto e non solo per come impongono un cambiamento al mondo dell’Information Technology, ma per come –in senso più generale– mostrano all’opera un interessante modello, per molti versi nuovo, di organizzazione del lavoro e di produzione di conoscenza. Un modello fondato sulla libertà di partecipazione e di esplorazione, riconducibile, su un piano teorico, alle riflessioni sui sistemi complessi adattativi.

Dunque l’interesse per esperienze maturate nel ristretto e specialistico mondo dell’Information Technology va ben al di là dei confini di questo mondo. Già Stallman ne era del tutto consapevole

(“le libertà per essere reali devono essere irrevocabili fin tanto che non si fa qualcosa di sbagliato”).

Peccato che poi, paradossalmente, gli stessi esponenti del movimento ne condizionino la conoscenza e la diffusione a causa di un atteggiamento fondamentalista e purista.

Attenti a coltivare la propria diversità, minoranza aristocratica, i programmatori convertiti all’Open Source, o cresciuti con l’Open Source, perpetuano, e in fondo portano all’estremo, un errore che caratterizza in genere i professionisti dell’informatica: il linguaggio chiuso, l’atteggiamento autoreferenziale, la difficoltà a farsi promotori di una ‘cultura d’uso’ realmente accessibile ai non specialisti. Più in generale: il mondo dell’Open Source appare poco interessato a mostrarsi come esempio di organizzazione praticabile anche al di fuori del campo della produzione di software.

Commenta un attento osservatore, Paolo Attivissimo: “questo atteggiamento fondamentalista è semplicemente fallimentare. Occorre ingoiare il rospo e sacrificare un po' di purezza pur di raggiungere uno scopo moralmente più elevato.” [6]