Riportiamo alcune considerazioni di carattere più economico sul modello di business del Software Open Source

Dal passaggio dal software commerciale all'Open Source, é solo il valore di vendita del software ad essere impattato, teoricamente azzerato, mentre invece il valore d’uso viene completamente preservato. Se quindi, come abbaimo precedentemente illustrato, lo sviluppo con il modello Open Source é veramente più efficace e permette di ottenere un prodotto di qualità più elevata rispetto a quello commerciale, allora diventa plausibile che il solo valore d'uso sia sufficiente per finanziare lo sviluppo dell'Open Source in modo sostenibile.
E, in effetti, non è difficile individuare almeno due study case che hanno dimostrato la capacità del software Open Source di sostenersi dal punto di vista economico. La storia del web server Apache generalizza un modello in cui gli utenti di software trovano vantaggioso sostenere lo sviluppo dell'Open Source perché, così facendo, ottengono un prodotto migliore di come potrebbe essere altrimenti, a un costo inferiore.
L'Open Source serve non tanto ad abbassare i costi, quanto a ripartire il rischio.Tutte le parti in gioco si accorgono che la disponibilità del codice sorgente, così come la presenza di una comunità che agisce in collaborazione, finanziata da più fonti di reddito indipendenti, fornisce una garanzia di sopravvivenza che ha un valore economico intrinseco o, comunque, un valore sufficiente per finanziarla.
I L'Open Source rende piuttosto difficile trarre un valore di vendita diretto dai software. Non si tratta di una difficoltà tecnica: il codice sorgente non è né più né meno copiabile del binario e l'istituzione del copyright e di diritti di licenza che permettano la riscossione del valore di vendita, non sarebbe necessariamente più difficile per i prodotti Open che per quelli commerciali.
La difficoltà sta piuttosto nella natura del contratto sociale che si trova alla base dello sviluppo Open. Per tre motivi che si rinforzano a vicenda, la principale licenza Open Source (la GPL) proibisce la maggior parte delle forme di restrizione d'uso, ridistribuzione e modifica che faciliterebbero la riscossione di profitti derivanti dal valore di vendita. Per comprendere questi motivi, occorre esaminare il contesto sociale nel quale si sono evolute le licenze: la cultura hacker di Internet come spiegato nells sezione relativa alla storia del software Open Source.
Se è vero che una minoranza di hacker resta ancora ostile alla logica del profitto, la volontà generalizzata da parte della comunità di cooperare con aziende i cui prodotti si basano su Linux, come aziende come Red Hat, SUSE dimostra che la maggioranza degli hacker sarebbe felice di lavorare a fianco del mondo dell'impresa, quando è nei loro interessi. Le ragioni reali per cui gli hacker guardano con scetticismo alle licenze che consentono guadagni diretti, sono assai più sottili e interessanti.
Una delle ragioni riguarda la simmetria. Mentre la maggior parte degli sviluppatori Open Source non oppone obiezioni sostanziali al fatto che altri traggano profitto dai loro doni, i più chiedono che nessuno (ad eccezione, eventualmente, del creatore di una parte del codice) si trovi in una posizione privilegiata per fare profitti. Il signor Rossi Hacker è d'accordo che la Bianchi tragga profitti dalla vendita del suo software o delle sue patches, ma solo nel caso che anche lui stesso, almeno in teoria, possa farlo.
Un'altra ragione riguarda le conseguenze indesiderate. Gli hacker hanno osservato che le licenze che comportano la restrizione e il pagamento di contributi per uso "commerciale" o vendita (il tentativo più comune e, a prima vista, nemmeno tanto assurdo, di recuperare il valore di vendita diretto) hanno effetti davvero inquietanti. Un caso specifico è la possibilità di controllare segretamente la legalità di attività come la ridistribuzione di antologie economiche su CD-ROM, che in linea di massima sarebbero da incoraggiare. Più in generale, le restrizioni sull'uso, la vendita, le modifiche, la distribuzione (e altre clausole presenti sulle licenze) comportano spese aggiuntive per la conformità della distribuzione e (con l'aumento dei pacchetti in circolazione e in utilizzo) una combinazione esplosiva di incertezza soggettiva e potenziali rischi legali. Poiché questi risultati si considerano dannosi, si registra una forte pressione sociale per mantenere le licenze semplici ed esenti da restrizioni.
L'ultima e più importante ragione riguarda la dinamica di revisione e di cultura del dono.Le restrizioni sulle licenze, designate per proteggere la proprietà intellettuale o per percepire un valore di vendita diretto, hanno spesso l'effetto di rendere legalmente impossibile la biforcazione dei progetti (questo avviene, per esempio, per le licenze di SUN, le cosiddette "Community Source", per Jini e Java di SUN). Se la biforcazione incontra molto scetticismo ed è considerata come l'ultima risorsa), la presenza di quest'ultima risorsa si considera di capitale importanza in caso di incompetenza o defezione del gestore (a causa, per esempio, di una licenza troppo restrittiva).
La comunità hacker mostra una certa elasticità in materia di simmetria: per questo, tollera licenze, come NPL di Netscape, che concedono alcuni privilegi in materia di profitti agli autori originali del codice (nel caso specifico di NPL, il diritto esclusivo di utilizzare il codice open source di Mozilla in prodotti derivati, anche commerciali). Ma ha meno elasticità nei confronti delle conseguenze indesiderate e nessuna sul mantenimento della possibilità di biforcazione (ed è per questo che gli schemi elaborati dalla Sun per la "Community License" di Java e Jini sono stati in gran parte rifiutati dalla comunità).
Queste ragioni spiegano le clausole della Open Source Definition, scritta per esprimere il parere congiunto della comunità hacker sui requisiti essenziali delle licenze standard (GPL, licenza BSD, licenza MIT e Licenza Artistica). Queste clausole hanno l'effetto (ma non l'intenzione) di rendere molto difficile l'ottenimento di un valore di vendita.
Ciononostante, esistono modi per costruire mercati nei servizi legati al software che comportino un valore di vendita indiretto. Sono cinque i modelli conosciuti e due quelli teorici (ma se ne potranno sviluppare altri in futuro). In figura 1 li abbiamo presentati in maniera grafica, per poi spiegarli dettagliamene in seguito.

Figura 1 di Business per il Software Open Source (fonte Internet).