[Soci SLIP] "coso" per sviluppo progetti open

[Lucio Crusca]

Alle 13:32, venerdì 28 dicembre 2007, Davide Corio ha scritto:
> E' implicito il fatto che il pagamento dello sviluppo dovrebbe avvenire
> solamente nel caso in cui il prodotto finito venga giudicato conforme
> alle richieste.

In realtà non è implicito, anzi, io penso non sia nemmeno il modo corretto, mi 
spiego...
Giudicare un software conforme alle richieste sarebbe uno dei problemi da 
risolvere, per il quale non c'è attualmente nessuno strumento che ci venga in 
aiuto, che io sappia. Il grosso problema, sviluppando open, è che è fin 
troppo semplice per l'utente/cliente giudicare il prodotto non conforme e 
quindi non pagare, consapevole del fatto che tanto la feature ormai è 
sviluppata e pubblicata anche per altri e quindi gli arriverà in ogni caso 
gratis. Per questo motivo io vedevo una sorta di finanziamento allo sviluppo 
più che di pagamento alla consegna. Anche perché la feature sviluppata 
potrebbe in effetti differire un minimo dalla richiesta iniziale, essendo un 
raggruppamento di richieste simili e correlate. Per questo motivo nella mia 
testa mi sono immaginato che l'utente ipotizzi una cifra che sarebbe disposto 
a pagare per la sua richiesta, senza alcun impegno, e poi si impegni per 
un'altra cifra, minore o maggiore come vuole lui (in base a quanto giudica 
importante il pezzo di software che gli viene proposto in risposta alla sua 
richiesta e che sarà sviluppato).
L'eventualità che gli utenti si impegnino per cifre troppo basse non è 
preoccupante: nel momento in cui gli utenti si impegnano a pagare ognuno una 
parte dei costi di sviluppo, sanno anche che se si impegneranno per una cifra 
troppo bassa la probabilità che si raggiunga un'impegno complessivo che copra 
il totale dei costi è minore, quindi sarà minore anche la probabilità che 
quella feature venga effettivamente sviluppata. In questo modo i clienti sono 
incentivati a valutare economicamente la loro richiesta in base a quanto in 
effetti pensano che valga per loro.

D'altra parte non si rischia che il cliente paghi e lo sviluppatore non faccia 
il suo mestiere, perché lo sviluppatore che si intasca i soldi e non fa il 
suo mestiere avrà comunque vita breve. D'altra parte quello che lavora 
seriamente non rischierà di vedere tutti quelli che gli hanno chiesto il 
software fare retromarcia all'ultimo momento, solo perché sono consapevoli 
che tanto il software lo otterranno gratis. Ed è questo uno dei motivi per 
cui servono degli strumenti appositi per gestire la catena degli eventi: è un 
modello economico differente da quello in cui viviamo, quindi temo che gli 
strumenti esistenti non siano adatti.

D'altra parte se l'utente/cliente si trovasse oggettivamente con un software 
non conforme alle richieste, sarebbe primo interesse dello sviluppatore 
soddisfare il suo cliente ed assecondare le sue richieste. 

È chiaro che con il modello attuale, dove il software è commissionato e pagato 
da un solo cliente, il discorso è diverso, lì si può tranquillamente 
rischiare che il cliente non paghi, perché il software, in quel caso, è 
talmente specifico per la sua esigenza che se non paga, nell'ipotesi in cui 
il software sia conforme alla richiesta, rischia più lui a restare 
abbandonato a sè stesso con il suo software di quanto non rischi lo 
sviluppatore per il mancato guadagno. Quindi in quel caso il pagamento alla 
verifica di conformità da parte del cliente funziona.

Lucio.

-- 
Virtual Bit di Lucio Crusca
via Isonzo, 5   10069 - Villar Perosa
http://www.virtual-bit.com