[RoLUG] traduzione

[Ferdinando Pucci]

Ho provato a "tradurre" in modo secondo me piu leggero l'ottimo
pezzo che Diego ha aggiunto per completare il suo discorso:

3.1 Basi economiche dell' Open Source.
La domanda più comune che ci si pone quando si sente parlare di Open Source è su 
come sia effettivamente possibile guadagnarci denaro. Eric Raymond affronta l'
argomento nel suo saggio "The magic cauldron", nel quale propone divesi modelli
per ottenere ricavi dalla produzione di sofware Open Source. Egli sostiene che 
gran parte dello stupore sottostante questa domanda deriva dal concetto comune
che si ha sull'economia della produzione del software, che si
rivela falso alla prova dei fatti. Per iniziare, occorre far notare che i 
programmi informatici, come tutte le altre classi beni, 
hanno due tipi distinti di valore economico: hanno, cioè, un 
valore di vendita ed un valore d'uso.
Siccome è un bene commerciabile, un programma ha un valore di vendita, ma 
essendo anche uno strumento per produrre altri beni il programma ha il suo valore d'uso.
Quando il profano cerca di ragionare sull'economia della produzione di software, 
tende a prendere come esempio la fabbrica, sfruttando un modello fondato sulle
seguenti premesse.
   1. La maggior parte del lavoro degli sviluppatori è retribuito in 
base al valore di vendita.
   2. Il valore di vendita di un software è proporzionale ai costi dello 
sviluppo (cioè al costo delle risorse necessarie per duplicarlo in modo 
                              ^^^^^^^^intendi i cd vuoti?
funzionale) e al valore d'uso (perche fornisce la potenzialità di fare qlc).
In altre parole, il buonsenso ci dice che il software condivide
le caratteristiche di valore di un tipico bene manifatturiero come il pane. 
Ma è possibile 
dimostrare che entrambe queste supposizioni sono false.
Innanzitutto, il codice scritto per la vendita non è che la punta dell'iceberg 
rappresentato dalla programmazione. Esistono prove empiriche che circa il 95%
del codice che scrive un programmatore nn è destinato 
alla vendita. Tale codice comprende la maggior parte dei sistemi di gestione 
informatica, codice tecnico-specialistico come i device driver. 
Inoltre la "manutenzione" del software rappresenta la stragrande
maggioranza (più del 75%) del lavoro per cui sono pagati i programmatori. Di
conseguenza, il programmatore passa gran parte del suo tempo (e guadagna gran
parte del suo salario) scrivendo e aggiornando codice aziendale che non ha alcun
valore di vendita.
In secondo luogo,
il prezzo
pagato dal consumatore è determinato, in realtà, dalla previsione di quanto
potra esser utile il software e per quanto tempo. Infatti se la software house
fallisce i prezzi dei suoi prodotti crollano non perche sono antiquati,
ma perche non piu supportati!
Quindi l' "illusione manifatturiera" distacca la reale composizione
dei costi di sviluppo dal prezzo finale, elevato e con contributi per l'assistenza
bassi o nulli. Se (com'è generalmente accettato) oltre il 75% dei costi
del ciclo vitale di un normale progetto software è legato alla manutenzione,
alla messa a punto e alle estensioni, questa politica dei prezzi
è destinata a condurre a risultati
deludenti sia per il produttore che per il consumatore (l' assistenza spesso 
non è mai all' altezza).
E se non il modello della fabbrica, quale? Per far fronte in modo efficiente 
alla reale struttura dei costi del ciclo vitale di un software, serve 
una struttura dei prezzi fondata sui servizi. 
Il software
Open Source pone quindi una sfida non puramente tecnologica, ma anche economica, 
nei confronti dell'ordine costituito. Infatti l'effetto del rendere un software
"libero" è quello di entrare nello schema
servizio=costo e mostrarci come il valore di vendita degli articoli commerciali 
sia sempre stata un'impalcatura relativamente fragile.


Che vi pare?