Due delle forze economiche che hanno reso possibile la nascita dell'Open Source sono la perdita di monopolio e la cosiddetta "asimmetria informativa".
[ZEUS News - www.zeusnews.it - 09-09-2003]
Ogni studente di economia del primo anno impara a calcolare la perdita di monopolio: il monopolista, non avendo concorrenti, è in grado di massimizzare il proprio profitto producendo solo quel tanto che gli conviene (tecnicamente: fino a raggiungere l'indifferenza nel costo marginale del prodotto rispetto al ricavo marginale). Il software, tuttavia, non è un prodotto fisico, e ha la caratteristica di essere riproducibile all'infinito a costi marginali che si avvicinano allo zero.
A una prima analisi, la regola della perdita di monopolio sembrerebbe non valere, ma in realtà essa cambia solamente forma: non è nella mera produzione dell'ennesimo "pacchetto" venduto che si applica questa regola, ma nella produzione del "primo campione", ossia nella fase di ricerca e sviluppo.
Il monopolista del software continuerà a ricercare solo fino al momento in cui è certo che la sua attività sarà sufficiente a rendere il proprio prodotto vendibile. Quindi, egli non ha alcun interesse a creare un prodotto perfetto, o eccellente, o semplicemente buono. In poche parole, basta che funzioni quel tanto che serve, non solo per quanto riguarda caratteristiche generiche come velocità e stabilità, ma anche per quanto riguarda le funzionalità offerte (le "cose", in senso ampio, che il software è in grado di fare).
L'altra motivazione di fondo alla quale abbiamo accennato è l'asimmetria informativa, uno dei tre fattori chiamati in economia "fallimento del mercato" ossia una condizione per cui l'incontro tra domanda e offerta non è in grado di determinare un prezzo corretto. Si parla di asimmetria informativa quando per gli acquirenti non è possibile, nemmeno dal punto di vista teorico, entrare in possesso di tutte quelle informazioni necessarie a valutare un prodotto.
L'adeguatezza di un sistema informatico alle necessità di una determinata impresa non può essere conosciuta perfettamente a priori, prima di verificarne le caratteristiche sul campo. Gli amministratori di un impresa sono costretti a prendere le proprie decisioni sull'adottare un sistema piuttosto che un altro sulla base di informazioni insufficienti. Già lo studio dei manuali dell'applicazione, che potrebbe quantomeno fornire una lista precisa di funzionalità presenti, assenti o male implementate, è una attività che non viene svolta prima dell'acquisto di un software pacchettizzato, nella speranza che le sue potenzialità pubblicizzate siano sufficienti a soddisfare le necessità della propria impresa.
Inoltre, il solo studio dei manuali non sarebbe sufficiente a comprendere a fondo quale sia il costo implicito di utilizzare un software piuttosto di un altro. Il semplice modo diverso di due software di gestire la stessa funzionalità potrebbe rendere molto difficile (quindi costoso) implementare una certa soluzione.
Questi due fattori concorrono alla creazione del primo motore dell'Open Source come soluzione aziendale. Possiamo chiamare questa leva, che nasce dall'inefficienza del monopolio e dell'asimmetria informativa "inadeguatezza". Le imprese si trovano oggi a fronteggiare l'inadeguatezza dei software pacchettizzati disponibili a basso prezzo, ma assolutamente inadeguati a soddisfare le loro specifiche necessità. Essendo molto minore che in passato, l'offerta di know how e soluzioni personalizzate non è sufficiente a coprire questa inadeguatezza e le imprese sono costrette a riportare all'interno alcuni dei processi prima esternalizzati.
Un esempio banale è quello di un dipendente che impiega tempo per costruire un report con un foglio elettronico, o a preparare una presentazione dei risultati della propria area per il consiglio di amministrazione.
Questa attività di adeguamento delle risorse informatiche è da vedere come accessoria all'attività caratteristica dell'impresa. Ad esempio, in genere nessuna impresa troverebbe interessante vendere i fogli elettronici prodotti dai suoi dipendenti, per quanto sofisticati (e potenzialmente carichi di un valore economico) questi siano. Farlo risulterebbe essere una attività estranea al core business che richiede nuove competenze, investimenti, attività di setup, consulti legali e quanto altro.
La cosa diventa macroscopica quando l'inadeguatezza stessa diventa macroscopica; il caso classico è quello di una azienda che abbia bisogno di un software con certe funzionalità per svolgere il proprio lavoro, ma che questo diventi improvvisamente indisponibile, a causa del fallimento di tutti i potenziali fornitori, e che le versioni preesistenti diventino obsolete o inutilizzabili con i nuovi sistemi operativi.
La scelta, in certi casi, è sviluppare il software necessario o chiudere l'impresa; di fronte a questa scelta, ecco che le imprese in questa situazione potenziano il proprio CED e lo dedicano prevalentemente alla produzione di quella soluzione che è necessaria alla sopravvivenza dell'impresa. Eppure, anche quando viene fatta questa scelta, vendere il software prodotto internamente è spesso improponibile: richiederebbe una gamma di investimenti e di competenze che sono estranei alla missione aziendale. Tuttavia, rimane indispensabile trovare il modo di ridurre il costo di produzione del software personalizzato.
Questo articolo CONTINUA >>>
1 - Open source come modello di business
2 - La perdita di monopolio e la cosiddetta "asimmetria informativa"
3 - La riduzione dei costi attraverso la condivisione del lavoro
4 - La grande disponibilità di software di base e strumenti di sviluppo
Se questo articolo ti è piaciuto e vuoi rimanere sempre informato con Zeus News
ti consigliamo di iscriverti alla Newsletter gratuita.
Inoltre puoi consigliare l'articolo utilizzando uno dei pulsanti qui
sotto, inserire un commento
(anche anonimo)
o segnalare un refuso.
© RIPRODUZIONE RISERVATA |
|
|
||
|