Attraverso Internet, è possibile cercare altre imprese, o alle volte singoli privati, che siano interessate a produrre lo stesso software, o software con caratteristiche simili. Si creano così delle joint venture informali che raccolgono gruppi di imprese alla ricerca di una soluzione comune.

Se poi si decide di pubblicare il progetto e di renderlo non solo Open Source, ma anche Free Software, ecco che una vasta platea di utenti può provare il software sviluppato, effettuando così dei test approfonditi e descrivendo eventuali problemi, o anche possibili soluzioni, agli autori originali. Quanto costerebbe avere un gruppo di test così vasto? Per una impresa il cui core business non è nemmeno la produzione del software sarebbe un costo insostenibile.

Sento spesso obiettare, a questo punto: "Perché mai un utente di un software dovrebbe svolgere questo lavoro? Perché dovrebbe segnalare gli errori, o addirittura correggerli, senza volere nulla in cambio?"

Il motivo è semplice: perché l'utente è interessato a usare il prodotto, per le stesse motivazioni dell'impresa o dell'entità che ha sviluppato il software in origine. Quindi, se esiste un errore che riduce le potenzialità del software, o una funzionalità che è fortemente utile a un certo utilizzatore, questi ha tutto l'interesse a comunicare l'errore, correggerlo se possibile o addirittura implementare la funzionalità mancante. In un certo senso, dato che ha un bisogno che dipende dalla struttura della propria catena del valore, sopporterà il costo di partecipare allo sviluppo in cambio del vantaggio economico che deriva dall'utilizzo del software.

Un esempio pratico può aiutare a comprendere come agisce questo meccanismo. In un sito con caratteristiche di commercio elettronico, stavo utilizzando due prodotti Open Source molto maturi e stabili: Interbase, un database relazionale dalle caratteristiche paragonabili a Oracle, e PHP, un sistema per la generazione di contenuti web dinamici. Mi sono accorto, a un certo punto, di un grave errore nel modulo PHP per la gestione di Interbase: in certe condizioni, i decimali venivano riportati in modo scorretto. Seppure l'errore era evidentemente "piccolo", era tale da rendere quasi impossibile l'utilizzo della soluzione che avevo adottato, e sulla quale avevo investito un certo tempo in termini di ricerca e know how. Era quindi opportuno tentare di correggere tale errore. Essendo il modulo relativamente piccolo e ben scritto, ho impiegato circa mezz'ora a trovare il problema, e un'altra mezz'ora per per risolverlo. Infine, in un quarto d'ora ho eseguito le procedure di configurazione e installazione del modulo corretto.

La scelta era: tenere questa scoperta per me o comunicarla agli autori del modulo (e del PHP) per permettere la correzione dell'errore. Anche ammettendo che le persone siano intrinsecamente egoiste (così come afferma la teoria economica), esisteva un valido motivo non esserlo: se non avessi comunicato l'errore e la relativa soluzione, a ogni nuova versione che avessi deciso di installare (e ne esce circa una ogni due-tre mesi), avrei dovuto verificare se tale errore era stato risolto nel frattempo, altrimenti verificare che il codice che avevo scritto fosse ancora valido, modificarlo, installarlo e testarlo; un lavoro di circa un'ora. Comunicando l'errore, cosa che ho fatto in dieci minuti, la mia modifica è stata controllata e inserita nella versione successiva del software, da persone che erano interessate come me ad avere un prodotto funzionante, con un risparmio netto di circa quattro ore di lavoro per anno. L'altruismo paga.

Una situazione simile è impensabile se si parla di software commerciale, soprattutto se il suo mercato ha caratteristiche di monopolio. Anche ammettendo di trovare un errore, tentare di correggerlo è oggi un atto illegale, punibile con quattro anni di detenzione. Inoltre, la correzione di alcuni errori potrebbe essere valutata come troppo costosa; è da ricordare infatti che, agendo come monopolista, è possibile, anzi probabile, che il costo di correggere l'errore sia ritenuto più alto del ricavo ottenibile.

Questo articolo CONTINUA >>>
1 - Open source come modello di business
2 - La perdita di monopolio e la cosiddetta "asimmetria informativa"
3 - La riduzione dei costi attraverso la condivisione del lavoro
4 - La grande disponibilità di software di base e strumenti di sviluppo

Hai a disposizione ancora caratteri. Per inserire commenti più lunghi (e senza CAPTCHA), iscriviti.
Il tuo nome:		La tua email: