OPEN SOURCE

Riportiamo parte di un articolo apparso su zerounoweb.it

La proposta di valore delle componenti Oss è ormai maturata attraverso varie fasi. È giunto il momento, per gli utenti, di definire una consapevole economia di approvvigionamento fra software proprietario e software open. Serve darsi criteri e best practice di adozione differenziata e controllata, prevedendo di acquisire anche codice open source, piuttosto che subirne una inconsapevole quanto inesorabile “infiltrazione”, evitando sorprese e infortuni

Leggi anche Oss: quali sono oggi i segmenti più maturi
Rinaldo Marcandalli - 05/03/2010

Gnu, il libero sistema Unix “Gnu is Not Unix”, è nato nel 1983. Il progetto Java è partito nel 1991. Dai tempi di Richard Stallman e James Gosling, i due rispettivi “padri”, le Comunità Open Source Software (Oss) si sono moltiplicate; nel “radar” delle tecnologie nascenti ne appaiono costantemente di nuove; schiere di “artigiani” e di “fornitori” si radunano attorno ai Common asset. Ricerche Forrester e Gartner alla mano, viene definito ormai maturo il tempo per l’utenza aziendale di guardare seriamente al trend da parte dell’offerta (l’ecosistema fornitore Comunità, vendor, Isv, Service Provider) di progressivo “unbundling dal software” dei servizi indotti dal software stesso.
La proposta di valore delle componenti Oss è ormai maturata attraverso varie fasi. Non tutta la domanda (l’ecosistema fruitore) ha preso coscienza di un equilibrio dinamico di mercato in cui il software open guadagna terreno su quello proprietario, quantomeno nelle aree più basse dello stack software, in particolare laddove risuona più frequentemente la parola “commoditizzazione”. Quando parliamo di open ci riferiamo all’intero sviluppo software, requirement compresi, non al solo sorgente, implicando che la produzione è un “perpetuo beta” cui si aggiungono nuove funzionalità quando richieste e testate.
Vero tutto questo, è giunto il momento, per gli utenti, di definire una consapevole economia di approvvigionamento fra i due modelli di business per il software, quello basato su licenze e servizi (software proprietario) e quello basato sui soli servizi (software open). Serve darsi criteri e best practice di adozione differenziata e controllata, prevedendo di acquisire anche codice open source, piuttosto che subirne una inconsapevole quanto inesorabile “infiltrazione”, evitando sorprese e infortuni.