R: [Discussioni] Microsoft e lo shared source.

[Roberto Galoppini]

Carlo Daffara mercoledì 16 ottobre 2002 9.41 scrisse:

>Hm. Dopo aver passato due ore a Bruxelles a dibattere con il CTO di
>Microsoft Europa, ti posso garantire che le idee le capiscono
>perfettamente, semplicemente loro ne hanno altre.
>Lo shared source e' un esperimento: se un numero significativo di persone
>gli leggono il codice, loro dicono che hanno preso il meglio dell'open
>source (il distributed check and test) e quindi hanno vinto, se nessuno
>gli guarda il codice dicono che l'open source e' una bufala perche' a
>nessuno interessa leggere il codice. Quindi, in un modo o nell'altro,
>vincono lo stesso (al momento, sembra che stia valendo la seconda
>ipotesi).

Non so se l'idea dello shared source sia realmente un esperimento, in realtà
potrebbe essere semplicemente quello che sembra: uno strumento di
fidelizzazione nei confronti dei clienti (o Grandi clienti) e, dall'altra,
uno strumento per aumentare l'efficienza del processo di debugging.
Non credo invece che l'efficacia, ovvero il miglioramento qualitativo dei
prodotti, possa essere un obiettivo allo stato dell'arte, considerato che
raccogliere le esigenze, filtrare e priorizzarle prende tempo (=denaro), che
ha senso spendere solo se funzionale al business.

La forchetta tra software libero e software proprietario spesso è proprio
lì: un'azienda fa scelte aventi come unica metrica la massimizzazione del
profitto attraverso l'uso più efficiente delle risorse, mentre nel software
libero, in assenza del vincolo on time-on budget, è possibile che qualcuno,
o più di uno, si concentri sulla qualità di ciò che produce.
Quanto sopra ovviamente non si applica tout court ai progetti di software
libero commerciale, in quanto la metrica economica è la medesima (ma è anche
vero che essendo software libero terzi possono contribuire e quindi
eventualmente livelli di efficacia possono essere ottenuti, anche se magari
non direttamente dall'autore originale).

Quindi, tornando allo shared source, direi che se funziona spenderanno meno
e i clienti saranno più contenti (trasparenza del codice e maggior rapidità
nel giungere a release stabili e sicure) e se non funziona, ovvero se non si
attiva il meccanismo di review, i clienti avranno comunque avuto trasparenza
sul codice.

Per me se ne deduce che se va bene va bene a tutti (fornitore e consumatore)
e se va male va male al fornitore, che avrà non poche difficoltà ad alienare
i diritti concessi.

Rob Galop