# Il calderone magico/Quando l'open source, quando il software commerciale/Capire quando è il momento

../Doom: un caso di studio ../../L'ecologia aziendale dell'open source IncludiIntestazione 8 settembre 2014 75% Open Source
Il calderone magico Eric Steven Raymond 1999 CC BY-SA 3.0 GFDL //it.wikisource.org/w/index.php?title=Il_calderone_magico/Quando_l%27open_source,_quando_il_software_commerciale/Capire_quando_%C3%A8_il_momento&oldid=- 20140908115200 //it.wikisource.org/w/index.php?title=Il_calderone_magico/Quando_l%27open_source,_quando_il_software_commerciale/Capire_quando_%C3%A8_il_momento&oldid=- 20140908115200
Doom rappresenta un interessante caso di studio, in quanto non è né un sistema operativo, né un software di comunicazioni in rete. Pertanto, è assai lontano dagli esempi ovvi e canonici di successo nel settore open source. Anzi, il ciclo vitale di Doom, compreso il cambiamento di categoria, potrebbe assurgere a esempio del ciclo vitale delle applicazioni software nell’odierna ecologia del codice: un ambiente in cui le comunicazioni e il calcolo distribuito creano seri problemi di resistenza, affidabilità e misurabilità affrontabili soltanto con la revisione reciproca, ma anche frequenti passaggi di categoria sia tra vari ambienti tecnici, sia tra attori in concorrenza (con tutte le relative questioni di fiducia e simmetria).
Doom si è evoluto da gioco individuale a deathmatch. L’effetto rete si identifica sempre più con l’elaborazione. Tendenze simili sono sempre più evidenti anche nelle più consistenti applicazioni aziendali, come i pacchetti gestionali integrati, via via che le aziende costruiscono reti più fitte con i fornitori e con la clientela: e sono implicite, naturalmente, nell’intera architettura del World Wide Web. Ne consegue che quasi ovunque, i vantaggi dell’open source sono in crescita costante.
Se si manterranno le tendenze attuali, la sfida centrale della tecnologia del software e della gestione dei prodotti, nel prossimo secolo, sarà comprendere quando sia il momento buono per agire, cioè quando consentire al codice commerciale di passare all’infrastruttura open source, per sfruttare gli effetti della revisione reciproca e attrarre maggiori guadagni nel settore dei servizi e sui mercati secondari.
Sono ovvi gli incentivi economici dell’indovinare il punto critico per il cambio di categoria, non superandolo, né precedendolo di troppo. Oltre a questo, attendere troppo a lungo comporta un serio rischio di opportunità: quello di essere battuti da un concorrente che opti per l’open source nella stessa nicchia di mercato.
La ragione per cui si tratta di una questione seria è che, per qualsiasi categoria di prodotto, la risorsa rappresentata dalla clientela, così come le risorse di talento disponibili per il reclutamento nella cooperazione open source, sono limitate e il reclutamento tende a mantenersi nel tempo. Se due produttori sono rispettivamente il primo e il secondo a diffondere due codici sorgente in competizione tra loro e con funzioni pressoché uguali, il primo ha più possibilità di attrarre il maggior numero di utenti e la maggioranza dei co-sviluppatori, nonché i più motivati. Il secondo dovrà accontentarsi degli avanzi. Il reclutamento tende a mantenersi, anche perché gli utenti prendono dimestichezza col prodotto e gli sviluppatori investono il loro tempo nel codice stesso.