Il calderone magico/L'illusione manifatturiera
 |
Questo testo è completo. | |
| ◄ | Oltre la cultura del dono | "L'informazione vuole essere libera": un mito. | ► |
Per iniziare, occorre far notare che i programmi informatici, come tutte le altre classi di strumenti o beni capitali,
hanno due tipi distinti di valore economico: hanno, cioè, un valore d’uso e un valore di vendita.
Il valore d’uso di un programma è il suo valore economico in quanto strumento. Il valore di vendita di un
programma è il suo valore in quanto articolo commerciabile (nel gergo professionale degli economisti, il valore di
vendita è il valore come bene finito, mentre il valore d’uso è il valore come bene intermedio).
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.
- La maggior parte dell’orario di lavoro degli sviluppatori è retribuito in base al valore di vendita.
- Il valore di vendita di un software è proporzionale ai costi dello sviluppo (cioè al costo delle risorse necessarie per duplicarlo in modo funzionale) e al valore d’uso.
In altre parole, c’è una forte tendenza a presupporre che il software condivida le caratteristiche di valore di un tipico bene manifatturiero. Ma è possibile dimostrare che entrambe queste presupposizioni sono false.
Innanzitutto, il codice scritto per la vendita non è che la punta dell’iceberg rappresentato dalla programmazione. Nell’era precedente il microcomputer, era opinione comune che il 90% di tutto il codice diffuso nel mondo fosse scritto all’interno di aziende, come banche o compagnie di assicurazione. Probabilmente, questo non è più vero: oggi, altre industrie sono assai più coinvolte nel software, per cui la frazione del totale realizzata dall’industria finanziaria è diminuita. Ma vedremo, tra breve, che esistono prove empiriche che circa il 95% del codice viene ancora scritto all’interno di aziende.
Tale codice comprende la maggior parte dei sistemi di gestione informatica, compresi gli adattamenti del software a scopo finanziario e la gestione di banche dati necessarie a tutti i media e alle grandi imprese. Comprende codice tecnico-specialistico come i device driver (ma quasi nessuno fa soldi vendendo device driver e su questo punto torneremo in seguito), nonché tutti i tipi di software incorporato per le nostre macchine, sempre più basate sui microchip, dagli strumenti meccanici agli aerei di linea a reazione, dalle macchine ai forni a microonde, fino ai tostapane.
Gran parte di questo codice, prodotto a livello aziendale, è integrato nel suo ambiente attraverso modalità che rendono molto difficili il riutilizzo e la copia (ciò è vero sia che per "ambiente" si intenda una serie di procedure interne agli uffici di un’impresa, sia che si intenda il dispositivo di iniezione del carburante in una mietitrebbia). Perciò, con il variare dell’ambiente, occorre sempre molto lavoro per l’adattamento del software.
Si tratta della "manutenzione" che, come sa qualsiasi ingegnere o perito informatico, 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: il lettore potrà facilmente verificare questo fatto esaminando le offerte di lavoro per programmatori in qualsiasi giornale che contenga una sezione di annunci economici.
Scorrere gli annunci di lavoro su di un quotidiano locale è un esperimento illuminante a cui vorrei invitare il lettore o lettrice. Esaminate le offerte di lavoro per programmazione, elaborazione di dati, ingegneria informatica e cercate lavori che coinvolgano lo sviluppo di software. Suddividete le varie offerte a seconda del fatto che il software venga realizzato per l’uso o per la vendita.
Emergerà ben presto che, anche attenendosi alla più elastica definizione di "vendita", almeno diciannove su venti dei salari offerti proverranno esclusivamente dal valore d’uso (ossia dal valore del bene intermedio). Qui si trova la nostra ragione di ritenere che solo il 5% dell’industria sia sostenuta dal valore di vendita. Notate, però, che il resto dell’analisi svolta nel presente saggio è relativamente insensibile a questo dato: anche se fosse il 15 o addirittura il 20%, le conseguenze economiche resterebbero essenzialmente le stesse.
(Quando prendo la parola in convegni tecnici, solitamente inizio il mio intervento ponendo due quesiti: quante persone nel pubblico sono pagate per scrivere software, e per quante il salario dipende dal valore di vendita del software. Generalmente, ottengo una selva di mani alzate alla prima domanda, poche o addirittura nessuna alla seconda, e molta sorpresa da parte del pubblico davanti a una tale proporzione.)
In secondo luogo, la teoria per cui il valore di vendita di un software è collegato ai suoi costi di sviluppo o sostituzione si sfata ancora più facilmente, esaminando il comportamento stesso dei consumatori. Sono molti i beni per cui una proporzione di questo genere regge (prima della svalutazione): cibo, automobili, strumenti meccanici. Ci sono anche molti beni non tangibili il cui valore di vendita è strettamente collegato ai costi di gestione e sostituzione: i diritti di riproduzione di musica, cartine o banche dati, per esempio. Tali beni possono mantenere o addirittura aumentare il proprio valore di vendita, una volta uscito di scena il produttore originale.
Al contrario, quando un produttore software cessa l’attività (o se il prodotto sta andando fuori produzione), il prezzo massimo pagato dal consumatore andrà rapidamente verso lo zero, a prescindere dal valore d’uso teorico o dai costi di sviluppo di un equivalente funzionale. (Per verificare questa affermazione, basta osservare gli scatoloni delle rimanenze al negozio di software più vicino a casa vostra.)
Il comportamento dei rivenditori, quando un produttore chiude, è assai rivelatore. Ci fa capire che i rivenditori
sanno qualcosa che i produttori non sanno. Ciò che sanno è che il prezzo pagato dal consumatore è determinato,
in realtà, dalle previsioni sul valore futuro dei servizi del produttore (dove "servizi" comprende, in questo caso,
personalizzazioni, aggiornamenti e progetti in progressione.)
In altre parole, il software è in gran parte un’industria di servizi che opera sotto la persistente, ma infondata
illusione che si tratti di un’industria manifatturiera.
Vale la pena esaminare il motivo per cui, normalmente, tendiamo a credere il contrario. Potrebbe essere semplicemente perché la piccola porzione dell’industria del software che produce a livello industriale per la vendita è anche la sola a pubblicizzare i suoi prodotti. Inoltre, alcuni dei prodotti più visibili e fortemente pubblicizzati sono effimeri, come giochi che hanno ben pochi requisiti in materia di servizi di aggiornamento (che sono l’eccezione, piuttosto che la regola) SH.
Vale anche la pena notare che l’illusione manifatturiera incoraggia un assetto dei prezzi patologicamente scollato rispetto alla reale scomposizione dei costi di sviluppo. 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, la comune politica dei prezzi, consistente nell’imporre un elevato prezzo fisso all’acquisto e contributi per l’assistenza relativamente bassi o addirittura nulli, è destinata a condurre a risultati deludenti per entrambe le parti.
I consumatori perdono perché, anche se il sofware è un’industria di servizi, gli incentivi nel modello della fabbrica vanno tutti contro l’offerta da parte del produttore di un servizio competente. Se il denaro del produttore proviene dalla vendita di articoli, la maggior parte dei suoi sforzi si concentrerà sul produrne il più possibile e mandarli fuori al più presto; l’ufficio assistenza, non attraendo profitti, diventerà una discarica per i meno efficienti e avrà soltanto le risorse strettamente necessarie a non alienarsi un numero eccessivo di clienti.
L’altra faccia della medaglia è che la maggior parte dei produttori che accettano questo modello della fabbrica finirà per fallire, nel lungo periodo. Finanziare spese di assistenza a scadenza indefinita, a partire da un prezzo fisso, è fattibile solo in un mercato in espansione abbastanza rapida da coprire i costi per l’assistenza e il ciclo vitale applicabili alle vendite di ieri, ma con i guadagni di domani. Una volta che il mercato raggiunge la maturazione e le vendite rallentano, la maggior parte dei produttori non avrà altra scelta se non tagliare le spese, abbandonando il prodotto.
Che ciò sia fatto in modo esplicito (mettendo il prodotto fuori catalogo) o implicito (rendendo più difficile l’accesso all’assistenza), l’effetto è comunque la fuga di clientela verso la concorrenza (poiché distrugge il valore futuro del prodotto, che è parte integrante del servizio). Nel breve periodo, si può sfuggire a questa trappola rilasciando file che correggono errori di programmazione ("bug-fix") facendoli passare per nuovi prodotti, con un prezzo nuovo, ma i consumatori si stancano facilmente. Nel lungo periodo, tuttavia, l’unico modo per cavarsela è non avere concorrenza, il che equivale a detenere un vero e proprio monopolio sul mercato. Alla fine, ne rimarrà soltanto uno.
E, in effetti, abbiamo visto diverse volte questo modello uccidere concorrenti anche forti al secondo posto in una nicchia di mercato. (Lo schema dovrebbe risultare particolarmente chiaro a chiunque abbia mai esaminato la storia dei sistemi operativi proprietari per il personal computer, dei word processor, dei programmi di contabilità e del software per l’impresa in generale). I perversi incentivi insiti nel modello della fabbrica conducono a una dinamica di mercato per cui il vincitore prende tutto e in cui anche i clienti del vincitore finiscono per perdere.
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 (sia nel senso informale di "efficienza", sia nel suo significato in gergo economico), serve una struttura dei prezzi fondata su contratti per determinati servizi, abbonamenti e scambio di valore continuativo tra produttore e consumatore. Pertanto, date le condizioni di ricerca dell’efficienza imposte dal libero mercato, possiamo prevedere che, se questo tipo di struttura dei prezzi si imporrà, il risultato finale sarà un’industria del software matura.
Fin qui, ci siamo addentrati nel motivo per cui il software open source pone una sfida sempre più stringente e non puramente tecnologica, ma anche economica, nei confronti dell’ordine costituito. Pare che l’effetto del rendere un software "libero" sia quello di costringerci a entrare in un mondo dominato dallo schema servizio/costo e mostrarci come il valore di vendita degli articoli commerciali sia sempre stata un’impalcatura relativamente fragile.
Il termine "libero" è fuorviante anche in un altro senso. Abbassare il costo di un bene tende a far aumentare, piuttosto che diminuire, gli investimenti totali nell’infrastruttura che lo sostiene. Quando il prezzo delle automobili diminuisce, la richiesta di meccanici per auto aumenta: è per questo che, probabilmente, anche quel 5% di programmatori, attualmente retribuiti in base al valore di vendita, non ne risentirebbe in un mondo open source. Chi perderebbe, nella transizione, non sarebbero i programmatori, bensì gli investitori che hanno scommesso su strategie di non disponibilità del codice sorgente in casi in cui non sono opportune.