Organizzazione del lavoro ( was R: [Discussioni] La memoria presentata da Suse all'audizione al Senato)

[Marco Ermini]

On 25 Jul 2002 12:00:48 +0200, Federico Di Gregorio <fog a initd.org> wrote:

[...]
> si vede che di sviluppo "aperto" hai capito abbastanza poco.. 

Probabilmente si sta confondendo lo sviluppo software professionale con
progettini da nerd. E si vede che allora non stiamo parlando di sviluppo
software professionale. Allora, vediamo se mi spiego, a costo di essere
prolissi come sempre.


> e` proprio il *dover* convincere altre teste, altre persone delle
> proprie scelte che rende il software libero cosi' forte dal punto di
> vista tecnico.

Su questa frase non esprimo commenti ed in linea di massima sono d'accordo,
anche se molto, molto spesso e' semplicemente falsa, visto che la gran parte
dei software liberi viene sviluppata (per esempio, parlando anche solo del
linguaggio di programmazione) in un certo linguaggio solo perche' il
programmatore lo conosce meglio, o perche' e' piu' facile da utilizzare, o
perche' ci sono pezzi di codice simile gia' fatti ecc., o comunque per motivi
marginali rispetto a quello che e' "meglio tecnicamente". E si potrebbero
tirare in ballo altre cose, come le tecniche ed i paradigmi di programmazione,
che nel software libero lasciano a volte a desiderare. Ma vorrei tornare a
quello di cui stavamo discutendo, che era ben altro.

Tu "devi convincere altre teste". Allora, stai sviluppando un software, con
licenza GPL, per un tuo cliente, e lo stai facendo in Perl. Un tizio su una ML
vuole darti ad intendere che e' meglio farlo in C. E se non le convinci? che
fai, cambi idea tu? e ricominci tutto da capo? ma per favore!

Non puoi cambiare idea su un progetto commerciale, quando sei pagato per
svilupparlo ed hai dei tempi da rispettare, e questo non c'entra un fico secco
con la licenza con cui lo rilasci!

Quando rilasci un software libero, lo rilasci ovviamente convinto che sia una
soluzione giusta per un problema: e diciamo (siamo magnanimi...) che lo e'
stata per il *tuo* problema - che era quello del tuo cliente.

Adesso che lo hai rilasciato, non devi convincere proprio nessuno: se a
qualcuno piace, lo usera', altrimenti fara' le sue critiche, obiezioni ecc.
oppure la sua versione. Da qui inizia il ciclo di miglioramenti "a bazaar". Ma
questo processo (ripeto) non ha *nulla* a che fare con il processo originale,
quello commerciale, di acquisizione di un cliente e dello sviluppo della sua
fornitura. Qui ci sono in gioco tempi e soldi, aziende e famiglie, non si sta
parlando di progettini amatoriali e di discussioni tra nerd!


> stessa cosa per i clienti, un cliente convinto della scelta tecnica e`
> un cliente che da molte meno rogne. quello convinto dalla "pubblicita`",
> ovvero che non ha capito la scelta tecnica, dara` in media + problemi.

Beato te che non hai mai avuto a che fare con certe persone... sai che in
certe aziende ci sono i cosiddetti "project manager" che seguono lo sviluppo
tecnico di una fornitura e riferiscono ai capi? praticamente sono pagati per
criticarti.

Per finire: personalmente non ho mai lavorato grazie alla "pubblicita'", ma
solo con la presentazione di un progetto dettagliato, di un prospetto
avanzamento lavori ed in seguito di un piano di test. Questo perche' ho
lavorato abbastanza nell'automazione industriale e questo e' necessario.


ciao

-- 
Marco Ermini
http://www.markoer.org - ICQ UIN 50825709 - GPG KEY 0x64ABF7C6
Never attribute to malice that which is adequately explained
by stupidity. (Hanlon's Razor, corollary to Finagle's law)