Computer. Software applicativo
Il software consiste di un insieme strutturato di istruzioni, procedure, regole, documentazioni e programmi espressi in bit di informazione, che possono essere caricati sulla memoria di un computer e quindi eseguiti.
Esiste una distinzione fondamentale tra prodotti software standardizzati o a pacchetto (packaged software) e servizi software adattati alle richieste del cliente o customizzati (IT services). I pacchetti software soddisfano esigenze funzionali di base e ad ampia diffusione come la scrittura, la grafica, la navigazione Internet, la gestione aziendale o la gestione dei dati, mentre i servizi software risolvono una varietà amplissima di problemi specifici e differenziati, sovente individualizzati. Le caratteristiche economiche e le strutture industriali conseguenti sono totalmente diverse.
All’interno dei pacchetti, il software applicativo consiste di programmi che, una volta in esecuzione, realizzano direttamente funzionalità per l’utente. Essi si distinguono dai sistemi software, che includono i sistemi operativi e i sistemi di rete, i quali costituiscono l’interfaccia tra software e hardware.
In questo contesto ci si occuperà del software che può essere fisicamente isolato dall’hardware e venduto separatamente. I programmi incorporati direttamente nell’hardware (il cosiddetto embedded software) danno luogo a mercati diversi, in quanto costituiscono prodotti intermedi rispetto ai prodotti finali, come i telefoni cellulari o le automobili.
Dal punto di vista economico il software appartiene alla categoria dei beni costituiti da informazioni (information goods). I beni informazionali presentano caratteristiche economiche molto diverse dai beni tangibili convenzionali. In primo luogo il software presenta proprietà peculiari di indistruttibilità, modificabilità e riproducibilità. A differenza dei beni tangibili, il software può essere usato un numero illimitato di volte senza perdere di valore. Inoltre può essere modificato a costi contenuti, senza necessità di operazioni che intervengono sulla struttura materiale del prodotto. Infine può essere riprodotto sostenendo il solo costo del supporto fisico, dunque a costi trascurabili o al limite a costo zero. In generale, per di più, le copie non sono facilmente distinguibili dall’originale.
Queste caratteristiche di base spiegano la peculiare natura dei mercati nei quali il software è prodotto e scambiato, che sono fondamentalmente diversi da quelli dei beni convenzionali. In questi ultimi, infatti, quando un’impresa deve realizzare un’unità aggiuntiva di prodotto è costretta a sostenere un impiego di risorse, subendo pertanto un costo marginale, strettamente maggiore di zero. Inoltre i beni non possono essere riprodotti o copiati senza sostenere costi il cui ordine di grandezza è simile a quello sostenuto dai produttori (in generale, se vi sono economie di scala, molto superiore). Ciò esclude la convenienza per gli acquirenti di riprodurre il bene acquistato e di venderlo a terzi. Infine i beni sono soggetti a usura, per cui debbono essere riacquistati alla fine della loro vita utile e i mercati dei prodotti usati sono nettamente separati da quelli dei prodotti nuovi. Queste condizioni fanno sì che sul mercato possano coesistere più imprese di dimensione paragonabile, le cui posizioni relative sono variabili nel tempo, e che una situazione di monopolio si presenti come una rara eccezione.
Gli aspetti economici del software saranno qui esaminati in riferimento alle caratteristiche dei beni prodotti, alla struttura dei costi di produzione, alle condizioni di efficienza nella programmazione, nonché ai regimi di protezione della proprietà intellettuale.
I produttori di software devono assicurarsi che, una volta ceduto il prodotto, gli acquirenti non lo utilizzino per un periodo illimitato (indistruttibilità), non lo modifichino in modo incontrollato (modificabilità) o addirittura ne facciano copia da cedere ad altri in forme non autorizzate (riproducibilità).
Una soluzione largamente usata nei mercati basati sul modello proprietario è la seguente: il software non viene ceduto in proprietà ma venduto in licenza per un periodo limitato. La licenza è esclusiva ed è coperta da diritti di proprietà intellettuale (copyright) che vietano la riproduzione non autorizzata, la modifica del prodotto e la sua circolazione. Poiché il software è indistruttibile, alla cessione in licenza fa seguito una strategia di obsolescenza pianificata basata sul frequente aggiornamento delle versioni (updating), in modo da rendere sistematicamente superata la versione installata e indurre al riacquisto. Per impedire la modifica e la riproduzione incontrollata, inoltre, la licenza dà accesso a una versione del programma già compilata, mentre la versione testuale (definita codice sorgente) resta inaccessibile e protetta dal copyright.
In secondo luogo, l’utilizzo del software soggiace a stringenti condizioni di compatibilità, sia con l’hardware sia con altri programmi. La compatibilità tra diversi programmi e l’hardware dei computer è oggi in gran parte assicurata, mentre sussistono ancora incompatibilità tra sistemi operativi, tra programmi che supportano diversi formati di file e tra versioni successive dello stesso programma. A differenza di altri settori industriali, nei quali la standardizzazione tecnica è sovente uniforme e assicura la compatibilità generalizzata, nel settore del software vi sono molte situazioni di ‘battaglia degli standard’, ovvero di competizione tra produttori rivali e tra coalizioni di produttori per affermare standard tra loro incompatibili. La situazione di incompatibilità rende impossibile trasferire i dati da un programma all’altro e quindi riduce l’utilità del software (in particolare l’utilità dei programmi meno diffusi). Nel campo dei software applicativi il caso più evidente si riscontra nell’automazione di ufficio, dove l’azienda leader Microsoft mantiene una quota di mercato stabile ed elevata.
Questa caratteristica del software genera un fenomeno economico definito di esternalità di rete: l’utilità che si ricava dall’uso di un programma dipende non solo dal suo merito intrinseco, ma anche dal numero di coloro che lo hanno adottato. Infatti, più ampia è la base installata, più alto è il numero di coloro con i quali si possono scambiare dati in formati compatibili e maggiore l’utilità che viene ricavata dal software. Il fenomeno è detto esternalità perché genera effetti economici (in questo caso, positivi) senza che ne venga sopportato il prezzo. La presenza di esternalità di rete genera un vantaggio significativo a favore dei produttori che godono di un’ampia base di clienti, o di coloro che riescono a persuadere in anticipo i potenziali clienti circa la numerosità attesa degli adottanti. La letteratura economica ha mostrato che gli acquirenti attribuiscono un valore molto più elevato ai programmi più diffusi, anche quando sono sensibilmente inferiori dal punto di vista tecnico.
In terzo luogo, l’assenza di standard universali aumenta i costi che gli acquirenti devono sostenere quando cambiano fornitore (switching costs). Tali costi includono il training del personale necessario per apprendere i nuovi programmi, ma soprattutto la conversione dei formati dei file esistenti. L’esperienza tecnica suggerisce che quando i programmi non provengono dallo stesso produttore, si manifestano invariabilmente inconvenienti nella conversione di file. L’acquirente non accetterà quindi il cambiamento di fornitore a parità di prezzo. Di conseguenza il nuovo fornitore sarà costretto a subire per intero i costi necessari ad assicurare l’integrale migrazione dei dati al nuovo standard, mentre il fornitore esistente godrà di un vantaggio di prezzo.
I costi di cambiamento del fornitore sono anche intenzionalmente aumentati dai produttori consolidati, allo scopo di danneggiare i nuovi entranti, attraverso opportune politiche tariffarie e contratti di manutenzione.
La combinazione di incompatibilità e costi di cambiamento del fornitore, in presenza di esternalità di rete, attribuisce un vantaggio strutturale alle imprese incombenti, cioè già attive sul mercato, e costituisce una prima spiegazione della tendenza dell’industria del software (almeno nella componente di prodotto standardizzato) verso configurazioni fortemente concentrate.
Le caratteristiche dell’offerta possono essere comprese esaminando la struttura dei costi di produzione. Come già anticipato, esiste una distinzione tra software standardizzato e customizzato. Iniziamo dai prodotti standardizzati: l’analisi economica ne ha sottolineato una caratteristica peculiare, condivisa anche da altri prodotti digitali.
Essa può essere riassunta nel modo seguente: gran parte della struttura di costo si concentra nella produzione della prima unità di prodotto, mentre il costo di riproduzione delle unità successive è trascurabile o pari a zero.
Questa caratterizzazione, apparentemente paradossale, si giustifica ponendo mente alle proprietà di indistruttibilità e riproducibilità dei beni digitali: una volta realizzato il primo esemplare, questo non si deteriora nell’uso e nella riproduzione, e d’altra parte i costi necessari per riprodurlo equivalgono al solo supporto fisico aggiuntivo. Esiste dunque una sproporzione tra i costi di produzione di unità successive, che non si ritrova affatto nei beni industriali convenzionali, ciascuno dei quali assorbe al margine un ammontare di risorse con un ordine di grandezza paragonabile.
Dal punto di vista economico questa sproporzione ha un significato preciso. Poiché il costo di produzione si concentra nella prima unità, esso ha un andamento indipendente dal volume di produzione successivo. Si tratta, in termini economici, di un costo fisso. A questo si aggiungono, dalla seconda unità in poi, costi variabili di riproduzione del tutto trascurabili ed eventualmente costi variabili di commercializzazione (per es., provvigioni ai venditori) contenuti. È importante osservare che i costi aggiuntivi tendono a essere costanti: per produrre dalla seconda unità in poi occorre consumare un supporto fisico per la riproduzione, e per vendere occorre pagare una provvigione unitaria. Si dice in questo caso che il costo marginale (cioè la variazione del costo totale in seguito all’aumento di un’unità nelle quantità prodotte) è costante. In sostanza, si può affermare che la produzione e la commercializzazione di software avvengono prevalentemente a costi fissi e a costi marginali costanti, il cui livello è sostanzialmente trascurabile.
Poste queste proprietà economiche, ne seguono implicazioni molto convincenti.
In primo luogo, il costo unitario tenderà a decrescere in modo monotono all’aumento delle quantità vendute. Ciò significa che i produttori di software non vanno incontro ai fenomeni di aumento del costo marginale tipici di ogni produzione industriale, allorquando ci si avvicina alla saturazione degli impianti e alla congestione operativa. Nel mondo della produzione industriale esistono limiti alla crescita dimensionale imposti dalla forma a U della curva di costo. Le imprese che producono software, al contrario, hanno un potente incentivo a espandere senza limiti la produzione e incontrano ostacoli solo nella capacità commerciale e di penetrazione del mercato, e quindi nella presenza di rivali e di marche concorrenti. L’industria tende quindi a convergere verso una configurazione di monopolio o di oligopolio concentrato.
In secondo luogo, se il costo fisso di produzione è molto elevato in valore assoluto (per es., perché il programma software è composto di centinaia di migliaia di righe di codice), allora si creano potenti barriere all’entrata di nuovi concorrenti. Le imprese incombenti godranno di un vantaggio incolmabile rappresentato dalla base di clienti già disponibile, che avranno convenienza ad acquistare le nuove versioni del software, nonché nuovi programmi complementari. Per un nuovo entrante il rischio di sostenere un ingente costo fisso e di non avere una base clienti sufficientemente ampia per recuperare l’investimento è eccessivo. L’equilibrio dell’industria sarà dunque tale da consentire un numero di concorrenti proporzionale al rapporto tra volume della domanda totale e costi fissi di sviluppo.
In terzo luogo, poiché i costi marginali sono costanti, la fissazione del prezzo non può avvenire, come nei mercati competitivi, sulla base del costo marginale, perché ciò implicherebbe una perdita. La politica dei prezzi del software risulta altamente imprevedibile, essendo basata sul rapporto tra costi iniziali di sviluppo e aspettative sui volumi di vendita, e non sulle condizioni tecniche di produzione.
Infine, una volta recuperati gli ingenti costi fissi, se i produttori riescono a tenere elevati i prezzi, per esempio con continui aggiornamenti dei programmi, allora la quota dei profitti sul ricavo di vendita tenderà a crescere con le quantità vendute. In generale, esisterà una quantità di soglia, al di sotto della quale la produzione avviene in perdita e al di sopra della quale inizia una zona di profitti crescenti. Anche in questo caso l’industria del software presenta anomalie rispetto ad altri settori industriali, nei quali la quota di profitti sulle vendite si concentra intorno a valori medi piuttosto stabili.
Date queste caratteristiche ne consegue una struttura industriale altamente concentrata, con uno o pochi produttori, alte barriere all’entrata, alta profittabilità e tendenza a scoraggiare l’ingresso di concorrenti.
Condizioni nettamente differenziate si riscontrano nella produzione di software adattato alle esigenze dei clienti. In questo caso, il costo fisso iniziale è costituito (solo se necessario) dal prezzo della licenza del software di base, mentre gran parte del costo è variabile, strettamente proporzionale alle esigenze del cliente. Esso consiste di attività di programmazione software dipendente dalle specifiche del cliente, nonché di consulenza e supporto alla vendita, ed è quindi svolta da personale ad alta qualificazione. In questo caso, non esiste un vantaggio strutturale per grandi imprese o per imprese incombenti, in quanto la domanda finale è frammentata, la prossimità geografica tra domanda e offerta assume valore, il costo marginale è variabile, i margini di profitto sono inferiori.
Di conseguenza l’industria del software ha una struttura industriale duale: da un lato, un oligopolio differenziato nei sistemi operativi e negli applicativi general purpose, con grandi imprese dominanti e tendenze verso il monopolio; dall’altro, numerosi mercati di concorrenza monopolistica altamente frammentati, con piccole e medie imprese locali e nazionali e pochi operatori internazionali.
Dall’analisi che precede si deduce che non sono in essere pressioni volte a ottenere nel tempo significative riduzioni nel costo di produzione del software. Nei mercati concentrati, da un lato, i grandi produttori sembrano in grado di spuntare prezzi elevati grazie alle barriere all’entrata e ai costi fissi; nei mercati frammentati, d’altra parte, pur in presenza di concorrenza, sembra difficile ridurre i prezzi oltre certi limiti, rappresentati da costi marginali del personale altamente qualificato. Si tratta dunque di esaminare se nell’industria del software sono riscontrabili processi di aumento della produttività, derivanti da innovazioni di processo, in grado di consentire riduzioni dei prezzi nel tempo.
La risposta alla domanda appena formulata è in gran parte negativa. L’analisi economica della produzione di software prende dunque le mosse da un paradosso: perché non si sono verificati gli straordinari aumenti di performance e di produttività che hanno caratterizzato il resto dell’industria informatica?
Uno dei fattori che rende la struttura economica del software anomala è l’estrema difficoltà di rendere la programmazione un processo strutturato, ripetibile e prevedibile, così come accade quasi ovunque nell’ingegneria industriale. L’ingegneria del software si trova ancora in uno stato iniziale e niente lascia prevedere che vi saranno miglioramenti drastici in un immediato futuro. Di conseguenza anche la previsione dei costi di progetto è altamente incerta. Come osservò nel 1975 Frederick P. Brooks, la produttività individuale dei programmatori esibisce una variabilità estrema, del tutto inusuale in qualsiasi processo industriale, con intervalli anche da uno a dieci.
Vi sono alcune ragioni strutturali che contribuiscono a spiegare questa situazione, le quali sono state descritte in termini di complessità, conformità, modificabilità e invisibilità. Innanzitutto, i programmi software sono sistemi complessi, composti da numerosi elementi, che esibiscono stati interni multipli durante l’esecuzione. I programmi sono sottoposti a vincoli di compatibilità sia con la macchina sia con altri programmi, senza che le interfacce siano standardizzate a un livello lontanamente paragonabile ad altri settori dell’ingegneria. Inoltre, a differenza dei prodotti tangibili, i programmi sono modificabili a basso costo, senza tuttavia che si possa prevedere con certezza e in dettaglio quali effetti vengono propagati in tutto il sistema. Infine, il software è invisibile, nel senso che non si danno rappresentazioni visuali o grafiche in grado di guidare, sia in fase di progettazione sia di esercizio e manutenzione, una comprensione dettagliata del funzionamento.
Per rendere gestibile la complessità sono stati sviluppati numerosi metodi di progettazione del software, con approccio sia matematico (metodi formali) sia grafico (metodi sistematici). Tuttavia, nessun metodo strutturato è stato sinora in grado di sostituire interamente, o di ridurre di importanza, la conoscenza di dominio che viene acquisita solo con l’esperienza diretta e l’esposizione ai casi. I programmatori più produttivi non solo possiedono una profonda conoscenza del dominio applicativo, ma devono anche assumere responsabilità gestionali nel condurre i progetti e avere talento nel comunicare agli altri le proprie visioni tecniche.
Risultati più incoraggianti sono stati ottenuti con nuove filosofie di progettazione. Un primo importante movimento, avviato a partire dagli anni Ottanta, si è manifestato nella programmazione per oggetti (object-oriented programming). Un oggetto software è definito come un’entità, appartenente a una classe, che possiede uno stato locale definito dalla struttura dei dati e può effettuare delle computazioni. L’oggetto viene attivato da altri oggetti, secondo una struttura a rete (network) e non ad albero, come nei modelli sequenziali di programmazione. La programmazione a oggetti ha bilanciato la tradizionale componente algoritmica e prescrittiva (computazioni) con quella delle strutture di dati (data modelling).
Uno sviluppo ulteriore è rappresentato dalla nozione di programmazione basata su componenti. I componenti software sono definiti in base a funzionalità astratte, ma ben definite, e a interfacce opportunamente specificate con altri componenti. La programmazione basata su componenti ha cercato di costruire librerie di soluzioni rispetto a funzionalità specifiche, di standardizzare le interfacce, di promuovere il riuso di componenti esistenti.
L’applicazione più spinta della filosofia per componenti è chiamata COTS (Commercial off the shelf): in questo approccio si promuove il sistematico utilizzo di componenti con funzionalità esistenti sul mercato, riducendo la programmazione ad hoc all’integrazione dei componenti tra loro.
La programmazione orientata agli oggetti e la programmazione basata su componenti hanno grandemente aumentato la scomponibilità, la modularità e la riutilizzabilità del software. Tuttavia la progettazione del software resta, per ragioni che furono lucidamente formulate da David L. Parnas fin dal 1972, un’attività nella quale esistono molteplici decomposizioni di ogni problema e numerose soluzioni ugualmente praticabili, di modo che lo spazio delle soluzioni resta invariabilmente ad alta dimensionalità.
Per queste ragioni la nozione di massima efficienza nella programmazione di software ha un significato non comparabile rispetto ad altri settori.
La protezione giuridica del software ha avuto una storia complessa e articolata.
Agli albori dell’industria informatica, il concetto stesso di software era assente, in quanto i programmi venivano compilati in linguaggio macchina e venduti insieme ai computer in modo inseparabile (bundling). La scrittura e la manutenzione dei programmi erano considerati in tutta l’industria una componente essenziale del servizio alla clientela. In parallelo, nel mondo accademico statunitense a partire dagli anni Cinquanta si andava strutturando, non senza difficoltà, l’attività di ricerca e di insegnamento nell’informatica, e fino agli anni Settanta i ricercatori e i programmatori in ambito accademico usavano scrivere in codice e farlo circolare liberamente.
Il quadro cambiò drasticamente nel 1969 con la decisione di IBM di vendere separatamente hardware e software. Iniziò la costituzione di un’industria separata, nella quale si registrò un massiccio processo di entrata di nuove imprese negli anni Settanta. I produttori di software indipendenti iniziarono a vendere programmi sotto forma di supporti, ma ben presto si pose il problema della protezione giuridica del loro contenuto.
L’orientamento della giurisprudenza ad assoggettare il contenuto dei programmi, in quanto composto essenzialmente di testo, alla protezione della proprietà intellettuale sulle opere dell’ingegno attraverso il copyright, fu consacrato in legge negli Stati Uniti con il Computer software protection act del 1980. Il copyright protegge il titolare dalla riproduzione non autorizzata del testo, ma anche dalla sua modifica.
Questo quadro di protezione perdura tuttora, ma è stato affiancato da un processo, iniziato negli anni Novanta negli Stati Uniti e proseguito in modo massiccio dopo il 1998, di assoggettamento del software anche al regime legale della brevettazione. Il processo logico-giuridico che ha condotto ad ammettere la brevettabilità del software è controverso e si basa su un’analogia tra gli effetti provocati su una macchina general purpose dall’esecuzione di un software applicativo e gli effetti provocati da una macchina specifica, che realizzi lo stesso risultato per via di principi tecnici di tipo meccanico. Poiché l’aumento di potenza e sofisticazione del software rende le macchine generiche capaci di compiere operazioni molto specifiche, la giurisprudenza statunitense ha ritenuto di poterne equiparare i principi operativi, e quindi di reperire i requisiti oggettivi per la brevettabilità. Tale orientamento non è stato invece recepito in Europa, dove il Trattato di fondazione dell’ufficio europeo dei brevetti (1973) esclude esplicitamente il software ‘come tale’ dalla brevettabilità: un’ipotesi di riforma di sostanziale allineamento al modello statunitense, proposta dalla Commissione Europea nel 2002, è stata respinta da un voto del Parlamento Europeo nel 2005.
In pratica tuttavia il numero di brevetti concessi, anche in Europa, ha conosciuto una crescita massiccia, soprattutto nei casi in cui si riesca a dimostrare che il programma determina delle operazioni nel mondo fisico.
La protezione del software attraverso il copyright fornisce una tutela giuridica, ma non è una condizione sufficiente per l’effettività del divieto di riproduzione non autorizzata. Di fatto si osserva che il mondo del software è soggetto ad ampi fenomeni di pirateria, attraverso la riproduzione illegale del codice sorgente e la messa in commercio di versioni non autorizzate. Senza nulla togliere al profilo giuridico, etico e politico della violazione, l’analisi economica ha esaminato con disincanto la situazione e ha ammesso che una politica di sostanziale tolleranza possa essere nello stesso interesse dei produttori di software. Infatti, il valore del software viene aumentato, in virtù dell’effetto delle esternalità di rete, sia che venga adottato da acquirenti legali sia illegali. Dal punto di vista della domanda, l’acquisto di software non autorizzato attribuisce la stessa utilità intrinseca del software legale (ammesso che la copia illegale sia ben funzionante, cosa che di norma accade), ma ovviamente preclude l’accesso ai servizi postvendita. Si assume in genere che assicurare da parte del produttore del software il rispetto della proprietà intellettuale (enforcement) abbia un costo strettamente maggiore di zero, per esempio per le spese legali. L’analisi economica suggerisce che i produttori di software non abbiano interesse a ottenere il rispetto assoluto del divieto di copia ma ammettano un certo livello di tolleranza, in funzione dell’importanza relativa per i clienti dei servizi postvendita rispetto alla funzionalità intrinseca. Questo spiega la diversa reazione dei produttori di software rispetto ai produttori di dischi e film nei confronti della riproduzione illegale di copie.
In anticipo sul processo di brevettazione del software si è anche affermato un modello di produzione radicalmente alternativo, chiamato Open source software (OSS). Esso è prodotto da programmatori che collaborano a progetti di sviluppo in rete ma non vengono remunerati per il loro lavoro e viene distribuito su Internet con licenze che consentono l’accesso al codice sorgente e la sua modificazione mentre ne vietano la commercializzazione. Il fenomeno è iniziato grazie all’attività di ricercatori nelle università americane e di programmatori indipendenti, decisi a contrastare la progressiva trasformazione del software in prodotto commerciale, attraverso il movimento per il cosiddetto free software. In seguito si è affermato come un paradigma alternativo di produzione grazie al successo nella realizzazione (a partire dal 1991) di Linux, unsistema operativo alternativo a Windows (sebbene an-cora con quote di mercato trascurabili), al dominio nel mercato dei web server di Apache rispetto a Microsoft (iniziato nel 1995) e alla fondazione della Open source initiative per il coinvolgimento delle imprese commerciali (nel 1998). Attualmente esistono versioni OSS anche in tutti i principali segmenti di software applicativo e in alcuni casi la versione libera è largamente diffusa(per es., MySQL nei database, o SendMail nella posta elettronica) e di qualità superiore rispetto alle versioni proprietarie.
L’affermazione del modello di produzione OSS solleva numerosi problemi economici interessanti. In primo luogo, ci si chiede quale sia la motivazione dei programmatori che lavorano gratuitamente. Molti studi hanno mostrato che esistono sia motivazioni non economiche sia spinte economiche: tra le prime, il desiderio di diffondere conoscenza in forma libera, la soddisfazione intrinseca nel programmare, la gratificazione nell’essere riconosciuti come autori di codice di buona qualità; tra le seconde, la creazione di software più adattato a esigenze specifiche, maggiori opportunità di apprendimento in comunità professionali allargate, la possibilità di creare reputazione tecnica riconosciuta anche nel mercato del lavoro remunerato. Inoltre, una certa quota di sviluppatori OSS viene remunerata direttamente o indirettamente, anche dalle aziende in cui lavora come dipendente e nell’orario di lavoro. A partire dalla seconda metà degli anni Novanta alcune grandi imprese (come IBM, Novell e Sun) hanno iniziato a collaborare con la comunità OSS, diffondendo i propri prodotti con codice aperto.
In secondo luogo, ci si chiede se la circolazione libera dei prodotti software non favorisca comportamenti opportunistici di appropriazione, come per esempio prelevare codice libero, modificarlo e rivenderlo commercialmente. Gli studi hanno messo in evidenza come l’adozione di codici di condotta autoregolati e la rapida comunicazione in rete forniscano notevoli proprietà di robustezza alle comunità professionali OSS: qualunque deviazione viene rapidamente identificata e punita con l’esclusione assoluta da future collaborazioni, in modo da scoraggiare comportamenti non corretti.
Infine, ci si domanda come facciano a sopravvivere sul mercato le numerosissime imprese che hanno abbracciato il modello OSS, visto che non possono vendere sotto licenza commerciale il software da loro prodotto. In gran parte queste imprese sono remunerate per il lavoro diretto di adattamento del codice aperto alle esigenze specifiche dei clienti e per i servizi complementari (consulenza, manuali tecnici, manutenzione). Per i clienti finali il costo totale (TCO, Total cost of ownership), che include non solo la licenza d’uso ma anche il servizio, gli aggiornamenti e la manutenzione, può essere inferiore adottando una soluzione OSS. In molti casi, tuttavia, le imprese adottano un modello ibrido, vendendo sia prodotti OSS sia proprietari. Poiché non hanno proprietà intellettuale sul codice e operano a costi marginali, in genere le imprese OSS sono più piccole delle corrispondenti imprese che operano con il modello proprietario.
A causa delle esternalità di rete discusse in precedenza, non si ritiene che l’OSS giunga a sostituire le soluzioni proprietarie nei mercati nei quali quelle proprietarie sono dominanti (sistemi operativi, prodotti per ufficio), ma possa coesistere con queste e affermarsi con quote di mercato rilevanti in segmenti applicativi innovativi.
Bitzer, Schröder 2006: Bitzer, Jürgen - Schröder, Philipp J.H., The economics of Open Source software development, Amsterdam, Elsevier, 2006.
Boehm 1981: Boehm, Barry W., Software engineering economics, Englewood Cliffs (N.J.), Prentice-Hall, 1981.
Bonaccorsi, Rossi 2003: Bonaccorsi, Andrea - Rossi, Cristina, Why Open Source can succeed, “Research policy”, 32, 2003, pp. 1159-1177.
Brooks 1975: Brooks, Frederick P., The mythical man-month, New York, Addison-Wesley, 1975.
Brooks 1987: Brooks, Frederick P., No silver bullet: essence and accidents of software engineering, “IEEE computer”, 20, 1987, pp. 10-19.
Budgen 2003: Budgen, David, Software design, New York,Addison-Wesley, 2003.
Choi 1997: Choi, Soon-Yong - Stahl, Dale O. - Whinston, Andrew B., The economics of electronic commerce, India-napolis, MacMillan Technical, 1997.
Economides 1996: Economides, Nicholas, The economics of networks, “International journal of industrial organization”, 16, 1996, pp. 673-699.
Lerner, Tirole 2002: Lerner, Josh - Tirole, Jean, Some simple economics of the Open Source, “The journal of industrial economics”, 2, 2002, pp. 197-234.
Mowery 1996: Mowery, David, The international computer software industry, Oxford, Oxford University Press, 1996.
Parnas 1972: Parnas, David L., On the criteria to be used indecomposing systems into modules, “Communications of the ACM”, 15, 1972, pp. 1053-1058.
Shy 2001: Shy, Oz, The economics of network industries, Cambridge, Cambridge University Press, 2001.
Steinmueller 2004: Steinmueller, W. Edward, The European software sectoral system of innovation, in: Sectoral systems of innovation. Concepts, issues and analyses of six major sectors in Europe, edited by Franco Malerba, Cambridge, Cambridge University Press, 2004.
Stolpe 2000: Stolpe, Michael, Protection against software piracy: a study of technology adoption for the enforcement ofintellectual property rights, “Economics of innovation and new technology”, 9, 2000, pp. 25-52.
Varian, Shapiro 1999: Varian, Hal - Shapiro, Carl, Information rules, Boston, Harvard Business School Press, 1999 (trad. it.: Information rules: le regole dell’economia dell’informazione, Milano, ETAS, 1999).