Il sociologo, la sociologia e il software libero: open source tra società e comunità/Capitolo 2/5
 |
Questo testo è completo. | |
| ◄ | Capitolo 2 - 4 | Capitolo 2 - 6 | ► |
Per contro nella rete si possono facilmente trovare testimonianze di tutt'altro tenore:
[...] il mio scopo è sempre stato quello di studiare soluzioni in modo artigianale, e molto mirate per un cliente, ma poi...quando raggiungo il software finale, posso rivenderlo in serie, magari con qualche ritocco qua e là. Il mio software di punta, Winshow Planning, è stato realizzato ad-hoc per un'agenzia di spettacolo a Cinisello Balsamo, ma poi è stato rivenduto negli anni seguenti a 15-20 altre agenzie sparse un po' ovunque. Questo secondo me è il punto: studiare e progettare in modo artigianale, e produrre su larga scala solo in un secondo momento. (http://blogs.ugidotnet.org/ 15 settembre 2010).
In realtà ciò che questo freelance rende evidente è che l'industrializzazione del software a codice chiuso non è così scontata, rappresenta piuttosto una sfida, un'ideale verso cui tendere che trova la sua effettiva realizzazione solo in ambiti ben precisi in particolare nei sistemi operativi, i pacchetti per ufficio che comprendono foglio di calcolo, videoscrittura, editori di presentazioni e tutti quei sistemi che rispondono ad esigenze generalizzate. Nel caso riportato si parla di un prodotto di punta rivenduto in un numero esiguo di copie, peraltro ritoccate (personalizzate) nel corso di anni e ciò conferma a maggior ragione che il software non ha un suo destino industriale così scontato. Chiaramente esistono situazioni in cui il paradigma industriale ha raccolto successi economici evidenti primo fra tutti quello Microsoft. Questa osservazione sopra riportata non ha quindi lo scopo di dimostrare l'improbabilità della produzione industriale del software, di cui peraltro molti aspetti sono operanti anche nel software libero, ma semplicemente evidenziare che tale paradigma non è generalizzabile. Nella fornitura software della pubblica amministrazione italiana il dato economico evidenzia una netta prevalenza del software personalizzato. Tale divario è senza dubbio ancora maggiore, in termini di quantità di istruzioni scritte, in quanto il software personalizzato è costituito da pezzi singoli, quello industriale da pezzi replicati. Inoltre, secondo la teoria dei sistemi di Luhmann la condizione di auto-poiesi non riguarda tanto la replica degli elementi del sistema ma la loro temporizzazione, cioè il loro succedersi in forme diverse. Queste diverse visioni del mondo operanti a livello di sviluppatori on demand come quelli che sviluppano con tecnologia open o come l'autore di “Winshow Planning”1 che sviluppa con tecnologia closed riflettono la stessa dialettica che si dispiega a livelli scientifici specializzati e che riguardano scuole di pensiero e paradigmi:
[...] Negli ultimi anni, il settore informatico è stato caratterizzato da un notevole incremento della produzione del software2 nei riguardi dell'hardware, e questo si riflette sui costi di un sistema informatico. Con queste premesse risulta necessario evitare di produrre software in base alle esperienze e/o iniziative del programmatore: il processo di produzione del software non può essere un processo di tipo artigianale (negli anni '60 il programmatore usava mille trucchi per risparmiare memoria!), ma deve servirsi di metodologie e tecniche sistematiche di progettazione e programmazione con fissati parametri di qualità e in maniera standard. La software engineering (ingegneria del software) è la branca dell'ingegneria informatica che raccoglie il patrimonio di metodi e tecniche per la produzione del software. Il processo di industrializzazione del software, introduce metodi e standard, riduce i margini di creatività e personalismo e consente i seguenti requisiti: buon livello qualitativo; produttività medio-alta; impiego di personale non troppo specializzato (la specializzazione è fornita dallo standard); riduzione sensibile del costo del prodotto … Ogni modulo deve possedere un singolo e ben precisato compito … Nell'ambito di un progetto software l'analisi richiede la capacità di acquisire le informazioni necessarie alla comprensione e di strutturarle in un modello che esprima, in un linguaggio adeguato, una rappresentazione coerente e completa di cosa deve fare .. Ma tra gli aspetti o le proprietà degli algoritmi da valutare con più attenzione sicuramente il più importante è proprio il progetto che si presenta come onerosa attività intellettuale (molto più onerosa di quella di esprimere l'algoritmo con un linguaggio di programmazione) che richiede creatività ed intuito ... (Alla scoperta dei fondamenti dell'informatica - Chianese, Moscato, Picariello, 2008, p. 114)
Questo estratto mette in evidenza un'esigenza organizzativa diffusa, come si vedrà più avanti, cioè quella di dare una collocazione sinottica e prevedibile attorno a quella che è un'attività essenziale dello sviluppo software e cioè la programmazione. Questa necessità viene ripresa ogniqualvolta si voglia affrontare il problema dell'industrializzazione del software. Diventa quindi centrale, un nodo indispensabile da risolvere:
[...] lo sviluppo software è ... lento e costoso, e genera prodotti che contengono seri problemi che causano problemi di usabilità, affidabilità, performance e sicurezza. All'inizio di questo capitolo, l'industrializzazione è stata definita come un metodo per aumentare efficienza e qualità e ridurre i costi implementando metodi standardizzati e altamente produttivi. Gli obiettivi di qualsiasi progetto software possono essere classificati in qualità, quantità, tempo e costi. Harry M. Sneed dipinge la loro interazione come il quadrilatero del diavolo, nel quale i quattro fattori sono in una relazione antagonista. In relazione alla disponibilità produttiva di una organizzazione efficace è limitante e non può soddisfare tutte le necessità, qualcosa deve essere sacrificato. Per esempio, maggiore lavoro di alta qualità causerà più costi e maggiori tempi di sviluppo. Tuttavia, applicando i metodi industriali, qualità e complessità del prodotto possono anche essere aumentate pur riducendo costi e tempi di produzione.
Molti sforzi sono stati fatti per applicare tali metodi allo sviluppo software. In riferimento al precedente capitolo, i principi industriali chiave ora possono essere trovati nel campo dell'ingegnerizzazione del software. La specializzazione è rappresentata dal Software Product Line (SPL – sviluppo di prodotti in linea), standardizzazione e sistematico riuso può essere trovato nello Component Based Devolopment (CBD - sviluppo basato su componenti) e il Model Driven Engineering (MDE – ingegnerizzazione orientata ai modelli). Sfortunatamente, il più importante concetto, specializzazione, è stato incluso per ultimo. Sennonché semplicemente, per mancanza di scopi ben definiti, lo sviluppo basato sui componenti e la sviluppo di prodotti in linea sembrano aver fallito al loro inizio. Solo recentemente tutti i concetti sono stati posti in essere e possono essere usati per sopportare l'industrializzazione … l'ultimo e più importante concetto è quello di sviluppo di prodotti in linea … è molto difficile se non impossibili concepire come i meccanismi di riuso e automazione possano essere implementati in un contesto arbitrario … ciò richiede di separare lo sviluppo di prodotti dalla sviluppo di prodotti in linea. Il primo contiene lo sviluppo di prodotti in senso stretto, mentre l'ultimo contiene l'assetto richiesto .. concentrando gli sforzi su uno scopo chiaro e delimitato, l'assetto produttivo può essere più potente come, per esempio, il riuso di componenti, ambienti e architetture. Tuttavia la specializzazione di per se non consentirebbe alcuna diversificazione così come viene richiesto dai diversi committenti. La produzione di software in linea inoltre identifica funzionalità ricorrenti e i punti di variazione per definire piattaforme e architetture comuni nelle quali le specifiche esigenze dei clienti possono essere prese in considerazione. Questo concetto, in altri settori dell'industria, è anche conosciuto come personalizzazione di massa … durante lo sviluppo di prodotti vengono definiti nuovi assetti che ritornano come feed-back alla produzione in linea. (Minich, Muehlbauer, Wentzel, 2009)
In sintesi Minich, Muehlbauer e Wentzel individuano un modello a due fasi:
- la produzione in linea che assorbe la specializzazione;
- la produzione di software in senso stretto che permette la personalizzazione.
La differenza sostanziale con il modello precedente di Chianese, Moscato, Picariello, consiste nel fatto che la creatività ed il “personalismo” non sono visti come problematici nel senso della loro esistenza, ma nel senso della loro collocazione. In questo ultimo modello il problema della non “industrializzazione della creatività” pone l'accento non sul “personalismo”, ma sulla “arbitrarietà”. Il primo è quindi un modello normativo, il secondo un modello dialettico. Quest'ultimo modello non esaurisce tutta la questione dell'arbitrarietà, semmai tenta di governarla. Non tutta la dimensione relativista viene delegata alla produzione di software in senso stretto perché la produzione in linea necessita di feed-back o, detto in altri termini, necessita di riflessività per la sua incapacità predittiva. In definitiva potremmo dire che sussistono due modelli ingegneristici del software: uno sistemico e sinottico che esclude la creatività; l'altro sistemico e autoregolato orientato a governare la creatività.
Il modello ingegneristico che si è definito dialettico evidenzia un aspetto molto importante ai fini del software libero che è la riflessività. In qualche modo tiene conto “dell'essere” in contrapposizione al “dover essere”. Minich, Muehlbauer e Wentzel rappresentano questo modello come due livelli, produzione in linea e produzione in senso stretto, cioè come due livelli che dialogano tra loro, che si scambiano informazioni in base alle quali adattare la produzione. Ed è proprio la dimensione dialettica che in definitiva caratterizza il software libero che non si limita ad una grammatica del funzionamento del prodotto “industriale” (funziona/non funziona, gestisce/non gestisce, efficiente/non efficiente, lento/veloce, fa/non fa), ma ricomprende anche la sua essenza “intima” cioè il codice, e nella fattispecie il codice aperto. Addirittura la grammatica impiegata nella riflessività ricomprende lo stesso codice (show me the code):
[...] un modo fantastico di vedere i propri cambiamenti accettati da altri è quello che si chiama «show me the code», cioè si fa vedere che un cambiamento di cui si sta discutendo da secoli è possibile, una volta che c'è l'evidenza in termini di codice che il cambiamento è possibile è più facile che collettivamente si decida che quella è la via giusta. (Intervista Stefano Zacchiroli del 17 agosto 2010).
Nel software libero questo modello ingegneristico dell'industrializzazione del software accentua maggiormente l'aspetto dialettico-riflessivo su tre dinamiche. Una prima dinamica è l'ampliamento della grammatica che come abbiamo già visto arriva a ricomprendere ricorsivamente il codice stesso; la seconda è l'ampliamento della stratificazione in cui si dispiega la riflessività; la terza è la contrazione del tempo.
La stratificazione si riferisce ai livelli tra cui si verificano eventi riflessivi. Mentre nel modello di Minich, Muehlbauer e Wentzel si prendono in considerazione due livelli, produzione in linea e produzione in senso stretto, che dialogano tra loro, nel software libero i livelli implicati riguardano i due livelli precedenti ed inoltre il livello “utenti finali”. Inoltre questi livelli si intersecano, uno stesso attore può appartenere a più livelli, o meglio, può passare da un livello ad un altro. La produzione in linea non si riferisce alla semplice replica di software, il tutto si ridurrebbe alla semplice copiatura di programmi che è un'attività che non necessita di sofisticate strategie industriali, ma si riferisce alla produzione di oggetti specializzati con scopi generalizzati riusabili nei diversi prodotti personalizzati, costituiti dalla produzione in senso stretto e destinati a quello che si chiama utente finale.
Poniamo quindi ad esempio il caso in cui un programmatore si trovi sul livello di produzione in senso stretto e che quindi sviluppa software a partire da oggetti già costruiti dalla produzione in linea. In questo caso può facilmente accadere che un “oggetto” prodotto in linea non risponda esattamente alle esigenze di un programmatore in senso stretto per sviluppare un prodotto personalizzato. In questo caso è possibile nell'ambito del software libero, anzi frequente, che egli decida di modificare l'oggetto stesso e che quindi sottoponga quelle modifiche stesse al core degli sviluppatori in linea per essere approvato ed incluso nelle versioni ufficiali, in questo caso l'implementazione dell'oggetto avviene già a livello di produzione in senso stretto, mentre il livello di produzione in linea assume il compito di approvare o meno tale modifica per poi nuovamente renderla disponibile a livello di produzione in senso stretto.
Ma vi è un altro elemento che questo modello non tiene in considerazione. Matthias e Harriehausen, che pure pongono il riuso del prodotto tra i criteri di industrializzazione del software, tengono conto nel loro modello solo del riuso orizzontale. È il livello della produzione in linea che si preoccupa di riutilizzare prodotti da destinare alla programmazione in senso stretto, cioè quella personalizzata, non viene contemplato il riuso orizzontale sul livello della programmazione in senso stretto come invece è possibile nel caso di sorgente aperto e libero da copyright.
Tornando all'esempio del servizio per la gestione delle auto aziendali in un'organizzazione, sviluppato on demand (come un vestito fatto su misura), se chiuso non può essere dato ad un'altra organizzazione che magari ha, metaforicamente, taglia diversa e una diversa cultura aziendale, ma se aperto una certa quantità di codice può essere recuperato, magari quasi tutto o si potrebbe trattare di ritoccare solo qualche istruzione. A tale proposito una survey di Manuel Sojer e Joachim Henkel della Technische Universität München (TUM), che ha riguardato 686 sviluppatori open source, rivela la maggiore propensione a riusare codice già scritto da parte di chi ha un'ampia rete di conoscenze negli ambienti open source, quindi dispone di capitale sociale (Coleman, 2005) chi ha partecipato a più progetti open source. Ma questo è proprio uno degli scopi dell'industrializzazione, cioè il riuso:
[...] Le chiavi concettuali di tali metodi (industrializzazione ed integrazione del software) possono essere sintetizzate in specializzazione & standardizzazione e riuso sistematico e automazione. (Minich, Muehlbauer, Wentzel, 2009)
L'inclusione del feed-back dell'utente finale non è una prerogativa esclusiva del software libero ma la differenza sostanziale consiste nel fatto che in questo caso i canali sono molto più accessibili e fluidi. Il software proprietario non può permettersi di pubblicare la lista dei difetti del suo software per ovvi motivi di immagine. Quindi necessariamente il feed-back dell'utente finale deve essere intercettato attraverso la mediazione formale e riservata introducendo così notevoli attriti. Sempre in considerazione del fatto che il feed-back deve avvenire in modo controllato e mediato, causa una maggiore dilatazione del tempo, e per contro una maggiore contrazione del tempo nel contesto del software libero, quindi una maggiore temporizzazione e auto-poiesi come conseguenza della riflessività. Ognuno degli attori vede gli altri due. Inoltre il feed-back dell'utente verso la produzione in linea riguarda oltre la segnalazione di bugs, anche donazioni, attività di promozione nelle diverse associazioni, come ad esempio i LUG (Linux User Group) diffusi in tutto il mondo, la stesura e traduzione di manuali d'uso. Gli utenti possono essere anche organizzazioni che finanziano specifici progetti a volte anche governative come il governo austriaco che finanzia per intero il progetto Proxmox, un programma di virtualizzazione3. Il contributo per il software libero in questo caso è ovvio, si tratta di finanziamenti, per il governo austriaco il feed-back consiste nel risparmio dei costi per la virtualizzazione dei suoi sistemi informatici.
Questi modelli spiegano perché le argomentazioni che pone il software libero non si esauriscano semplicemente con il monopolio ma coinvolgono visioni molto più complesse e articolate che riguardano concezioni etiche, di libertà e diritti negati. C'è fondamentalmente un agire etico non solo coerente con gli assunti economici di base che qui si sono esposti ma che sostiene il settore informatico nel suo complesso. Il problema da un lato non si esaurisce con l'eliminazione del monopolio informatico e dall'altro non si esaurisce con la soluzione della questione morale che pone Richard Stallman:
[...] numero zero, la libertà di utilizzare qualunque software, a qualunque scopo. Numero uno, la libertà di studiare il funzionamento del programma, e di cambiarlo a piacimento. Ovviamente il presupposto di questa libertà è avere accesso al codice sorgente. Numero due, la libertà di ridistribuire copie di qualunque software a chi ti pare. Numero tre, la libertà di distribuire copie del tuo software modificato a chi ti pare. Il tutto in una visione altruistica, cioè per aiutare chi ti sta intorno … “
Il software libero e l'open source in genere non hanno il semplice compito di fare concorrenza a Microsoft per contenere le esternalità del monopolio; non ne hanno né lo scopo (mission), né la funzione, intesa come causa di effetti sistemici emergenti, né hanno lo scopo di calmierare i prezzi. In secondo luogo molti degli attori coinvolti non sono necessariamente moralmente impegnati, si può partecipare per scelta economica o semplicemente per divertirsi. Per contro c'è, come abbiamo visto, una concezione di modo di produrre industriale legata al software chiuso ancora per certi aspetti legata a concetti di parcellizzazione del lavoro, di controllo dei processi, di mortificazione o negazione della creatività, di alienazione e di separazione dell'uomo dal suo manufatto. C'è La pressione normativa sugli assetti organizzativi. Non di rado sono le persone e le organizzazioni a doversi adeguare ai processi di automazione e quando ciò accade è un segnale evidente del fatto che ci stiamo adeguando alle esigenze di industrializzazione del software intesa in modo parcellizzato e burocratico.
[...] La bruttezza vera non sta negli oggetti tecnologici né, secondo la metafisica di Fedro, essa dipende dai soggetti della tecnologia, cioè da chi produce o da chi la usa, ma sta nel rapporto tra chi produce la tecnologia e le cose prodotte, il quale determina poi un analogo rapporto tra chi usa la tecnologia e le cose usate. (Pirsig, 1992, p. 281)
Pirsig mette in evidenza un genere di isomoforfismo particolare, non quello tra organizzazioni che svolgono la stessa funzione, come possono essere isomorfe le industrie automobilistiche, le amministrazioni comunali, i governi. Si tratta di un isomorfismo non orizzontale ma verticale, in cui l'industria del software o chi produce il software in questo caso, determina un rapporto analogo con il prodotto da parte di chi lo utilizza. Quindi l'industria software necessita di industrializzare la produzione e pertanto necessità di utenti a loro volta industrializzati e soprattutto uguali tra loro. È facile immaginare come la cultura organizzativa si rifletta sul software prodotto. Ad esempio una software house rigidamente gerarchica, che separa nettamente la progettazione dallo sviluppo, produrrà software strutturato gerarchicamente il cui utilizzo richiederà una profilazione4 gerarchica degli utenti, la quale dovrà corrispondere ad un organigramma gerarchico della stessa organizzazione che lo adotta.
La creatività è ciò che consente di personalizzare, umanizzare la tecnologia di adeguare l'informatica ai bisogni dell'uomo, diversamente il dramma appare in tutta la sua evidenza. Il rischio è il “riduttivismo informatico” che delegittima le eccezioni per il semplice fatto che non riesce a gestirle in serie. La creatività viene percepita allora come una caratteristica pericolosa perché imprevedibile. Cosi Gian Antonio Gilli su Platone (1988, pg 63):
[...] se il modello della repubblica è sfavorevole ai portatori di téchne, quello proposto nelle Leggi è di gran lunga più duro. Opera insieme assorta e disincantata, frutto della tarda vecchiaia di Platone, Le leggi mostra un apprezzamento della divisione del lavoro come fonte di controllo sociale assai minore rispetto a quello mostrato nella repubblica, e una ridotta fiducia nei processi di interiorizzazione della norma da parte di ogni individuo. Il minor affidamento su queste forme di controllo potrebbe spiegare il ricorso a modalità più dure di controllo diretto sui portatori di téchne
Salvatore La Mendola (Comunicare interagendo, 2007), riprendendo da Gian Antonio Gilli spiega come il portatore di téchne non agisca secondo i principi con cui funziona la società, in modo utilitaristico, la società nasce contro i technai. Le loro capacità (creatività) devono essere assoggettate e questo avviene, nella società moderna, nelle organizzazioni e nelle aziende dove i portatori di téchne vengono affiancati a venditori perché la mediazione risolve la contraddizione tra la loro inadeguatezza sociale e la loro utilità. È ricorrente nella storia politica e organizzativa questa urgenza di controllo della creatività, oltre a questo bisogno di ribadirne la subordinazione se non l'inferiorità:
[...] è proprio il progetto che si presenta come onerosa attività intellettuale (molto più onerosa di quella di esprimere l'algoritmo con un linguaggio di programmazione) che richiede creatività ed intuito. (Chianese, Moscato, Picariello p. 114)
È la stessa urgenza che Platone attribuisce al Faraona Thaumus:
[...] O peritissimo Theuth, altro è colui che è capace di generare i ritrovati della téchne, altro è colui che è capace di giudicare quali esiti di danno o di utilità essa abbia per coloro che se ne serviranno. (Gilli, 1988, p. 45)
Per quale ragione dovrebbe essere così necessario in un manuale di ingegnerizzazione del software ribadire un tale monito? Di fatto, la legge di Platone e Alla scoperta dei fondamenti dell'informatica di Chianese, Moscato e Picariello, hanno la stessa necessità di ribadire un ordine e con esso una gerarchie di funzioni e di ruoli che non può essere confusa al fine di raggiungere un bene superiore, sia esso il governo di uno stato o il governo di un processo informatico. La minaccia a questo ordine ideale, stabilito a priori, non è data storicamente, secondo Gian Antonio Gilli, da forme di rivendicazioni dirette, corporativiste o sindacali, ma dall'energia che il portatore di téchne riesce a convogliare attraverso la sua attività in modo naturale e che minaccia un ordine sociale necessario e da realizzare. La contraddizione che il portatore di téchne porta con se è documentata dal disprezzo dei letterati e della politica nei confronti degli artigiani dell'antica Roma che nonostante questo, come dimostrano gli scavi archeologici (Dante, 2002), riescono ad acquisire uno status economico elevato nonostante il basso prestigio sociale, esprimendo ciò che Gerhard Lensky chiama squilibrio di status (Lensky, 1981).
La minaccia è la perdita di controllo che sul piano politico è dovuta alla competizione sul consenso tra l'autore dell'opera d'arte e la dimensione sacra che la stessa opere d'arte esprime e che ha la funzione di tenere unita la società (Durkheim, 1962). Sul piano informatico il problema del controllo verte sul potere informale (Crozier, 1978), cioè sulla notevole potenziale capacità dei programmatori di controllare gli spazi di incertezza in un campo che, come si vedrà più avanti, è ad alto rischio. Sempre secondo Crozier la “one best way” descritta ne L'organizzazione scientifico del lavoro da Edward W. Taylor (1974) è irrealizzabile in senso generale, porta al paradosso che l'eliminazione della discrezionalità minerebbe il senso stesso della gerarchia. Se in senso generale è difficile, se non impossibile, eliminare la discrezionalità a maggior ragione ciò diviene fortemente improbabile nel settore informatico. Il rischio che si creino situazioni di dipendenza dal technai è però molto alto. Se un'organizzazione investe su di un prodotto informatico dei capitali non può convivere con l'incertezza che il ritorno di tali investimenti possa dipendere dalla “creativita arbitraria” di un singolo programmatore. Ma nel caso informatico sussiste un altro paradosso oltre al fatto che l'eliminazione della discrezionalità porta alla perdita di senso della gerarchia (Crozier, 1978), in più vi è il fatto che è proprio il criterio della licenza d'uso che minaccia l'appropriazione del copyright da parte del programmatore e in generale di controllare gli spazzi di incertezza. Anche se le clausole contrattuali possono prevenire questa eventualità diviene estremamente costoso riuscire a controllare che gli algoritmi scritti nell'ambito dell'organizzazione non vengano ceduti o sfruttati dal programmatore stesso in concorrenza con lo stesso datore di lavoro. Questo è vero in molte realtà produttive, ma il settore informatico è particolarmente esposto a questo rischio proprio per la possibilità di spostare facilmente prodotti software o pezzi di programmi attraverso supporti di memoria o la rete. A tale proposito Nikolai Bezroukov Fairleigb della Dickinson University (NJ) nel 1999 osservava come il 38% degli sviluppatori del kernel Gnu/Linux scrivessero codice per il progetto GNU/linux durante l'orario di lavoro.
L'affermazione che sia il progetto che si presenta come onerosa attività intellettuale e non l'esprimere l'algoritmo con un linguaggio di programmazione contiene quattro messaggi importanti:
- separa il concetto di progettazione da quello di programmazione;
- ridefinisce il programmare come l'esprimere algoritmi e di conseguenza ridefinisce il ruolo del programmatore come colui che esprime, cioè si limita a tradurre in termini informatici un progetto già ben definito;
- pone l'attività intellettuale come prerogativa della progettazione;
- ribadisce l'ordine gerarchico in cui il programmatore (espressore di algoritmi) viene subordinato al progettista.
Come quando si mette in produzione un software, la questione a questo punto diviene: funziona? Quindi: funziona questo modello organizzativo? Purtroppo la risposta a questa domanda può essere solo dialettica, la ricerca su questi aspetti organizzativi è scarsa se non nulla. Vediamo cosa succede al di fuori, quando si utilizzano i prodotti informatici, ne facciamo esperienza tutti i giorni, ma non sappiamo in che rapporto stanno questi modi di produrre software con l'utente finale in termini di ansia che si esprime come irritabilità, dolori di testa, difficoltà ad imparare ad usare il computer sino al rifiuto totale della tecnologia (Maeran, 2002, p. 278). Non sappiamo in che rapporto stanno con il tecno-stress, dove gli stressori più frequenti sono i crash della macchina, soprattutto se associati a perdita di dati, dimenticare le password, la lunghezza dei tempi di attesa di caricamento del software ed ingenerale tutti i tempi di attesa (De Carlo, 2004, vol. IV, p.86). Quindi nello specifico contesto di produzione software è davvero possibile separare così agevolmente la progettazione dalla programmazione, sapendo che altra causa di patologie organizzative è l'ambiguità dei ruoli (De Carlo, 2004, vol. IV, p.84)? Quanto è il software che non fa quanto promette? E quanto quello prodotto con certi criteri piuttosto che con altri? O più semplicemente: Quanto il modo di produrre software influisce sul suo grado di usabilità, di ergonomia e quanto mantiene le promesse? E, non meno importante, sappiamo quanto la pubblica amministrazione spende per adottare software, ma non sappiamo quanto di questo software venga poi effettivamente messo in produzione. Non è facile rispondere a queste domande, e considerata la rilevanza socio-economica di questi argomenti non è sufficiente guardare alle patologie organizzative, allo stress, al sovraccarico, alle ambiguità di ruolo, ai giochi di potere, finanche al mobbing in maniera decontestualizzata dal modo di produrre tecnologia che necessariamente si riverbera nei contesti lavorativi dove viene applicata.
Ai nostri scopi attuali diviene importante rilevare che i modelli che si dispiegano nella produzione di software libero sono per alcuni aspetti diversi. Innanzi tutto, la differenza sostanziale, è che proprio il programmatore ha un ruolo centrale. Il caso più significativo è quello di Linus Torvalds iniziatore del sistema GNU/Linux, Andrew Tridgell iniziatore del progetto SAMBA5, lo stesso Richard Stallman che ha programmato EMACS6 e il debuger di Gnu/Linux, Miguel de Icaza iniziatore di Gnome7, Rasmus Lerndorf iniziatore di PHP che è oggi il linguaggio WEB più utilizzato in assoluto. La lista potrebbe essere ovviamente molto più lunga, ma ciò che è importante notare è che si tratta di programmatori che avendo dimostrando competenze notevoli nella programmazione, ed avendo “creato” strumenti e software largamente diffusi in tutto il mondo hanno assunto ruoli importanti in molte compagnie, come google o yahoo, università, organizzazioni e via dicendo. Nell'ambito del software libero e dell'open source in genere ciò che occorre per far carriera è programmare e dimostrare cosa si riesce a fare con i linguaggi, cioè programmare in modo “creativo”.
Note
- ↑ Il suffisso “Win” prima di “show” indica che è un programma desktop per “Windows”
- ↑ Per contro, questa tesi vuol dimostrare che il software proprietario limita il mercato complessivo.
- ↑ Per virtualizzazione si intende la creazione di una versione virtuale di una risorsa normalmente fornita fisicamente. Ad esempio: un computer virtualizzato può essere ospitato assieme ad altri computer virtualizzati in un altro computer fisico, così come un computer virtualizzato può essere ospitato assieme ad altri computer virtualizzati in un altro computer virtualizzato.
- ↑ Gestione informatizzata dei ruoli dei componenti di una organizzazione.
- ↑ Software per la condivisione di risorse tra diversi sistemi operativi
- ↑ Interprete per l'elaborazione di dati complessi e massivi
- ↑ Interfaccia grafica di Linux in molte distribuzioni tra cui Debian e Ubuntu