[RoLUG] aggiunta ala relazione filosofica (lungo)

[Diego De Stefani]

come promesso questa =E8 la parte da aggiungere alla mia relazione riguar=
dante=20
l' economia Open Source. Questo =E8 quello che sono riuscito a fare, anch=
e se=20
non =E8 che mi convinca moltissimo... l' argomento andrebbe trattato in m=
odo=20
pi=F9 complesso (e magari da uno che ne capisce un po' di economia....) e=
 io ho=20
dovuto sintetizzare il pi=F9 possibile la mia gui=E0 troppo lunga relazio=
ne...

3.1 Basi economiche dell' Open Source.
La domanda pi=F9 comune che ci si pone quando si sente parlare di Open So=
urce =E8=20
su come sia effettivamente possibile guadagnarci denaro. Eric Raymond=20
affronta l' argomento nel suo saggio "The magic cauldron", nel quale prop=
one=20
divesi modelli per ottenere ricavi dalla produzione di sofware Open Sourc=
e.=20
Egli sostiene che gran parte della tensione sottostante questa domanda de=
riva=20
da modelli divulgativi assai diffusi sull'economia della produzione del=20
software, che si rivelano falsi alla prova dei fatti. Per iniziare, occor=
re=20
far notare che i programmi informatici, come tutte le altre classi di=20
strumenti o beni capitali, hanno due tipi distinti di valore economico:=20
hanno, cio=E8, un valore d'uso e un valore di vendita.
Il valore d'uso di un programma =E8 il suo valore economico in quanto str=
umento.=20
Il valore di vendita di un programma =E8 il suo valore in quanto articolo=
=20
commerciabile (nel gergo professionale degli economisti, il valore di ven=
dita=20
=E8 il valore come bene finito, mentre il valore d'uso =E8 il valore come=
 bene=20
intermedio).
Quando il profano cerca di ragionare sull'economia della produzione di=20
software, tende a prendere come esempio la fabbrica, sfruttando un modell=
o=20
fondato sulle seguenti premesse:
   1. La maggior parte dell'orario di lavoro degli sviluppatori =E8 retri=
buito=20
in base al valore di vendita.
   2. Il valore di vendita di un software =E8 proporzionale ai costi dell=
o=20
sviluppo (cio=E8 al costo delle risorse necessarie per duplicarlo in modo=
=20
funzionale) e al valore d'uso.
In altre parole, c'=E8 una forte tendenza a presupporre che il software=20
condivida le caratteristiche di valore di un tipico bene manifatturiero. =
Ma =E8=20
possibile dimostrare che entrambe queste presupposizioni sono false.
Innanzitutto, il codice scritto per la vendita non =E8 che la punta dell'=
iceberg=20
rappresentato dalla programmazione. Esistono prove empiriche che circa il=
 95%
del codice viene ancora scritto all'interno di aziende, senza essere dest=
inato=20
alla vendita. Tale codice comprende la maggior parte dei sistemi di gesti=
one=20
informatica, codice tecnico-specialistico come i device driver, nonch=E9 =
tutti=20
i tipi di software incorporato per le nostre macchine, dagli strumenti=20
meccanici agli aerei di linea a reazione, dalle macchine ai forni a=20
microonde, fino ai tostapane. Inoltre la "manutenzione" del software=20
rappresenta la stragrande maggioranza (pi=F9 del 75%) del lavoro per cui =
sono=20
pagati i programmatori. Di conseguenza, il programmatore passa gran parte=
 del=20
suo tempo (e guadagna gran parte del suo salario) scrivendo e aggiornando=
=20
codice aziendale che non ha alcun valore di vendita.
In secondo luogo, la teoria per cui il valore di vendita di un software =E8=
=20
collegato ai suoi costi di sviluppo si sfata altrettanto facilmente. Ment=
re=20
per i beni tradizionali (cibo, automobili, strumenti meccanici) una=20
proporzione di questo genere regge, per il softwaare questo non vale. Ad=20
esempio, quando un produttore software cessa l'attivit=E0 (o se il prodot=
to sta=20
andando fuori produzione), il prezzo pagato dal consumatore andr=E0
rapidamente verso lo zero, a prescindere dal valore d'uso teorico. Il pre=
zzo
pagato dal consumatore =E8 determinato, in realt=E0, dalle previsioni sul=
 valore
futuro dei servizi del produttore (dove "servizi" comprende, in questo ca=
so,
personalizzazioni, aggiornamenti...).
Vale anche la pena notare che l' "illusione manifatturiera" incoraggia un
assetto dei prezzi patologicamente scollato rispetto alla reale scomposiz=
ione
dei costi di sviluppo. Se (com'=E8 generalmente accettato) oltre il 75% d=
ei=20
costi del ciclo vitale di un normale progetto software =E8 legato alla=20
manutenzione, alla messa a punto e alle estensioni, la comune politica de=
i=20
prezzi, consistente nell'imporre un elevato prezzo fisso all'acquisto e=20
contributi per l'assistenza relativamente bassi o addirittura nulli, =E8=20
destinata a condurre a risultati deludenti sia per il produttore che per =
il=20
consumatore (l' assistenza spesso non =E8 mai all' altezza).
E se non il modello della fabbrica, quale? Per far fronte in modo efficie=
nte=20
alla reale struttura dei costi del ciclo vitale di un software (sia nel s=
enso=20
informale di "efficienza", sia nel suo significato in gergo economico), s=
erve=20
una struttura dei prezzi fondata su contratti per determinati servizi,=20
abbonamenti e scambio di valore continuativo tra produttore e consumatore=
=2E=20
Pertanto, date le condizioni di ricerca dell'efficienza imposte dal liber=
o=20
mercato, possiamo prevedere che, se questo tipo di struttura dei prezzi s=
i
imporr=E0, il risultato finale sar=E0 un'industria del software matura. I=
l=20
software Open Source pone quindi una sfida non puramente tecnologica, ma=20
anche economica, nei confronti dell'ordine costituito. Pare che l'effetto=
 del=20
rendere un software "libero" sia quello di costringerci a entrare in un m=
ondo=20
dominato dallo schema servizio/costo e mostrarci come il valore di vendit=
a=20
degli articoli commerciali sia sempre stata un'impalcatura relativamente=20
fragile.

commenti please...
--=20
Linux user # 209015 on Linux machine # 97103
RoLUG member --> http://rovigo.linux.it
"Signora, lei e' brutta". "E lei e' sbronzo!". "Si', ma a me domani passa=
".
(Winston Churchill)