Il calderone magico/Perché chiudere il codice sorgente
 |
Questo testo è completo. | |
| ◄ | L'inverso dell'area comune | Modelli che promuovono il valore d'uso | ► |
Prima di passare a una tassonomia dei modelli aziendali open source, ci occuperemo dei vantaggi dell’esclusione
in generale. Che cosa proteggiamo esattamente, quando chiudiamo l’accesso al codice sorgente?
Supponiamo che incarichiate qualcuno di scrivere un pacchetto software di contabilità, specifico per la vostra impresa. Il problema non sarà più facile da risolvere, che il codice sorgente sia aperto o chiuso: l’unica motivazione razionale per tenerlo segreto è se si intende vendere il pacchetto ad altre persone o impedirne l’uso da parte della concorrenza.
La risposta più ovvia è che stiate proteggendo il valore di vendita, ma questo non si applica al 95% dei software scritti per uso interno. Quindi, quali altri benefici apporta la chiusura?
La seconda possibilità (proteggere il vantaggio competitivo) richiede un esame più attento. Supponiamo che optiate per la disponibilità del codice sorgente del pacchetto contabile. Il pacchetto si diffonderà e migliorerà, grazie ai perfezionamenti apportati dalla comunità. Ma anche la vostra concorrenza inizierà a usarlo, ne trarrà beneficio senza pagare costi di sviluppo e minaccerà la vostra impresa. Può considerarsi un argomento contro l’open source?
Può darsi, ma può darsi anche di no. Il problema reale è se il beneficio ottenuto dalla ripartizione degli oneri di sviluppo supera le perdite dovute all’aumento della competizione a causa del free riding. Molti tendono a fare ragionamenti semplicistici su questo argomento, (a) ignorando il vantaggio funzionale derivante dall’impiego di più addetti allo sviluppo; (b) non considerando i costi di sviluppo come costi sommersi. Tanto per formulare un’ipotesi, dal momento che i costi di sviluppo sarebbero da pagare ugualmente, sarebbe errato calcolarli come costi dell’open source (qualora si scelga questa strada).
Ci sono altre ragioni puramente irrazionali che motivano la non disponibilità del codice sorgente. Potreste, per esempio, star lavorando nell’illusione che il software commerciale tuteli l’impresa contro i cracker e gli intrusi. Se è così, vi consiglio immediatamente una conversazione a scopo terapeutico con un crittografo. I veri paranoici del lavoro sanno che è meglio non fidarsi della sicurezza dei programmi commerciali, perché la dura esperienza ha insegnato loro che è meglio non farlo. La sicurezza è un aspetto dell’affidabilità: soltanto gli algoritmi e le applicazioni che siano stati accuratamente controllati e rivisti da più persone potranno essere considerati sicuri.