[Gfoss] Basta tagli dalla parte sbagliata

Cavallini wrote:
Ecco, appunto: quando paghi ti tuteli; ergo, fai un contratto con una
ditta, che ti da' supporto, alle condizioni contrattuali.
Certo, se qualcuno vuole usare software libero, senza pagare niente a
nessuno, e poi avere anche garanzie, che probabilmente non ha neppure
con il sw proprietario, li' non so se ridere, arrabbiarmi, o chiamare
la neuro.

Occorre pero' essere onesti altrimenti parrebbe che il software GFoss
offra totali garanzia.
Non è del tutto vero, e occorre stare attenti perche' addirittura
introduce delle dinamiche nuove che non sono presenti nel softwares
commerciali.

E di cui occorre stare attenti e con gli orecchi dritti.

Ad esmepio:
Il software commerciale proprio per il fatto di essere chiuso un
vantaggiolo ha ed è che tutte le volte che lo compri sai quello che
compri. :slight_smile:

Mi spiego con il solito esempio della grande ditta.
Si era ipotizzato che dal software proprietario ci poteva ricavare un
extraguadagno da un eventuale sconto sull'acquisizione delle licenze.

Ma anche dal software GFoss possono venire dei vantaggi, magari non
come extra-guadagno subito, ma come ganrazia di una nicchia di lavoro
per gli anni a venire.

Infatti supponendo che abbia da mettere in piedi il solito sistema
chiavi in mano, magari con un anno si manutenzione/gestione del
sistema.
SI prende il software GFoss, ci mete dentro tre o quattro cambiamenti
al suo modo di funzionare, chesso' cambia qualche protocollo di
comunicazione , mondifica insomma 4 bischeratine.

Ovviamente lo fa' solo sulla versione rilasciata a quel cliente, ed
ecco che ha creato una nicchia di mercato tutta sua.
Se dopo quanche anno il sistema viene passato in appalto ad altro
soggetto questi non riuscira' piu' a mettercile mani, i protocolli non
tornano , non colloquino etc...

Anche questo è uno scenario che il cliente potrebbe temere.
Perche' creerebbe una sorta di dipendenza nei confronti di chi ha
sviluppato/rimaneggiato il sistema.

Chi gli garantisce che cio' che la ditta ha messo in piedi con il
software GFoss di turno sia replicabile o non sia una cosa
customizzata talmente che un altro soggetto non potrebbe rimetterci le
mani ?

Anche questo è un comportamento moralmente deprecabile, specie se
viene compiuto all'insaputa del cliente oppure mascherato sotto
discorsi del tipo:
"abbiamo fatto delle correzioni a dei difetti riscontrati", o frasi
del genere....
I commerciali delle ditte sono maestri nell'intortare i discorsi in
maniera da darla a bere a chiunque.

In casi come questi il software commerciale offre una garanzia in piu'
proprio dall'essere chiuso e quidi non modificabile.
:slight_smile:

Saluti,

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Condivido in pieno quanto hai espresso Andrea. A me pare, dopo quasi venti anni di lavoro con la PA, che questo sia un problema generale nell’ assegnazione di porzioni di lavoro ad un fornitore. Ossia che la migliore garanzia dei suoi interessi il cliente può averla solo se mantiene il controllo dei progetti.
Tu mi fai le cose perché mi conviene così piuttosto che fare tutto al mio interno, ma io debbo mantenere il controllo, ossia possedere anche le competenze tecnologiche per capire se la tua proposta nasconde delle insidie. Insidie e problemi che possono anche essere causati in buona fede dal fornitore.
Venendo all’ Open Source io ritengo che da questo punto di vista un prodotto aperto è più facilmente controllabile. Fatto salvo che il controllore deve avere la voglia di esercitare il controllo e quindi attrezzarsi per farlo.

Stefano

Il giorno 11/mar/2013 15:20, “Andrea Peri” <aperi2007@gmail.com> ha scritto:

Cavallini wrote:
Ecco, appunto: quando paghi ti tuteli; ergo, fai un contratto con una
ditta, che ti da’ supporto, alle condizioni contrattuali.
Certo, se qualcuno vuole usare software libero, senza pagare niente a
nessuno, e poi avere anche garanzie, che probabilmente non ha neppure
con il sw proprietario, li’ non so se ridere, arrabbiarmi, o chiamare
la neuro.

Occorre pero’ essere onesti altrimenti parrebbe che il software GFoss
offra totali garanzia.
Non è del tutto vero, e occorre stare attenti perche’ addirittura
introduce delle dinamiche nuove che non sono presenti nel softwares
commerciali.

E di cui occorre stare attenti e con gli orecchi dritti.

Ad esmepio:
Il software commerciale proprio per il fatto di essere chiuso un
vantaggiolo ha ed è che tutte le volte che lo compri sai quello che
compri. :slight_smile:

Mi spiego con il solito esempio della grande ditta.
Si era ipotizzato che dal software proprietario ci poteva ricavare un
extraguadagno da un eventuale sconto sull’acquisizione delle licenze.

Ma anche dal software GFoss possono venire dei vantaggi, magari non
come extra-guadagno subito, ma come ganrazia di una nicchia di lavoro
per gli anni a venire.

Infatti supponendo che abbia da mettere in piedi il solito sistema
chiavi in mano, magari con un anno si manutenzione/gestione del
sistema.
SI prende il software GFoss, ci mete dentro tre o quattro cambiamenti
al suo modo di funzionare, chesso’ cambia qualche protocollo di
comunicazione , mondifica insomma 4 bischeratine.

Ovviamente lo fa’ solo sulla versione rilasciata a quel cliente, ed
ecco che ha creato una nicchia di mercato tutta sua.
Se dopo quanche anno il sistema viene passato in appalto ad altro
soggetto questi non riuscira’ piu’ a mettercile mani, i protocolli non
tornano , non colloquino etc…

Anche questo è uno scenario che il cliente potrebbe temere.
Perche’ creerebbe una sorta di dipendenza nei confronti di chi ha
sviluppato/rimaneggiato il sistema.

Chi gli garantisce che cio’ che la ditta ha messo in piedi con il
software GFoss di turno sia replicabile o non sia una cosa
customizzata talmente che un altro soggetto non potrebbe rimetterci le
mani ?

Anche questo è un comportamento moralmente deprecabile, specie se
viene compiuto all’insaputa del cliente oppure mascherato sotto
discorsi del tipo:
“abbiamo fatto delle correzioni a dei difetti riscontrati”, o frasi
del genere…
I commerciali delle ditte sono maestri nell’intortare i discorsi in
maniera da darla a bere a chiunque.

In casi come questi il software commerciale offre una garanzia in piu’
proprio dall’essere chiuso e quidi non modificabile.
:slight_smile:

Saluti,

Andrea Peri
. . . . . . . . .
qwerty àèìòù


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
638 iscritti al 28.2.2013

Ciao a tutti,
alcune _personali_ osservazioni inline.

Regards,
Simone Giannecchini

Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.

Ing. Simone Giannecchini
@simogeo
Founder/Director

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

2013/3/11 Andrea Peri <aperi2007@gmail.com>:

Cavallini wrote:
Ecco, appunto: quando paghi ti tuteli; ergo, fai un contratto con una
ditta, che ti da' supporto, alle condizioni contrattuali.
Certo, se qualcuno vuole usare software libero, senza pagare niente a
nessuno, e poi avere anche garanzie, che probabilmente non ha neppure
con il sw proprietario, li' non so se ridere, arrabbiarmi, o chiamare
la neuro.

Occorre pero' essere onesti altrimenti parrebbe che il software GFoss
offra totali garanzia.
Non è del tutto vero, e occorre stare attenti perche' addirittura
introduce delle dinamiche nuove che non sono presenti nel softwares
commerciali.

E di cui occorre stare attenti e con gli orecchi dritti.

Ad esmepio:
Il software commerciale proprio per il fatto di essere chiuso un
vantaggiolo ha ed è che tutte le volte che lo compri sai quello che
compri. :slight_smile:

io direi piuttosto il contrario, in quanto a tutti gli effetti compri
a scatola chiusa
e ti devi fidare di quello che ti viene detto proprio perché anche
volendo ed essendone in grado
ti è vietato di controllare (almeno nella maggioranza dei casi).

Mi spiego con il solito esempio della grande ditta.
Si era ipotizzato che dal software proprietario ci poteva ricavare un
extraguadagno da un eventuale sconto sull'acquisizione delle licenze.

Ma anche dal software GFoss possono venire dei vantaggi, magari non
come extra-guadagno subito, ma come ganrazia di una nicchia di lavoro
per gli anni a venire.

Infatti supponendo che abbia da mettere in piedi il solito sistema
chiavi in mano, magari con un anno si manutenzione/gestione del
sistema.
SI prende il software GFoss, ci mete dentro tre o quattro cambiamenti
al suo modo di funzionare, chesso' cambia qualche protocollo di
comunicazione , mondifica insomma 4 bischeratine.

Ovviamente lo fa' solo sulla versione rilasciata a quel cliente, ed
ecco che ha creato una nicchia di mercato tutta sua.
Se dopo quanche anno il sistema viene passato in appalto ad altro
soggetto questi non riuscira' piu' a mettercile mani, i protocolli non
tornano , non colloquino etc...

Anche questo è uno scenario che il cliente potrebbe temere.
Perche' creerebbe una sorta di dipendenza nei confronti di chi ha
sviluppato/rimaneggiato il sistema.

Chi gli garantisce che cio' che la ditta ha messo in piedi con il
software GFoss di turno sia replicabile o non sia una cosa
customizzata talmente che un altro soggetto non potrebbe rimetterci le
mani ?

Ehm, l'aver scritto la gara di appalto in modo corretto invece di
prendere il prezzo piu' basso dal primo pollo che passa?

Noi nel nostro piccolo _assicuriamo per iscritto_ ai nostri clienti
che _tutte_ le modifiche che facciamo ai vari software Open Source
finiranno sulle rispettive repository a meno che il cliente non
richieda diversamente (nel rispetto delle varie licenze ovviamente)
o che la modifica non sia talmente specifica da non essere di
interesse generale e quindi rigettata dagli altri membri del
progetto.
In tal caso solitamente si provvede ad aprire un punto di estensione
(se non gia' presente) per la feature specifica e si mette quantomeno
il codice
a disposizione del cliente e se di interesse della comunità (sandbox,
community modules, etc. etc.).

In definitiva, usare software open source non garantisce di per se
_niente_ soprattutto quando ci si affida a persone/aziende prive dei
requisiti e della esperienza
necessarie a garantire un corretto approccio alla comunità. Ma questo
non è colpa dell'open source è colpa:

-a- delle aziende che approfittano dei progetti Open Source come dei
parassiti senza partecipare in alcun modo allo sforzo (soldi, codice,
doc, support in ml, etc..)
-b- di chi scrive i bandi richiedendo Open Source senza fare un minimo
di attenzione a come poi il lavoro venga fatto ed ad un corretto suo
posizionamento verso i progetti e le rispettive community di
riferimento

Caso tipico.
L'azienda X prende il lavoro L promettendo di sviluppare una serie di
feature sul software OS Y. L'azienda X parte ed in quasi totale
isolamento si fa il suo lavoro.
Siccome spesso la doc è carente (magari mettere anche la doc nei
bandi sarebbe na buona idea, invece niente..) ogni tanto incontra
degli scogli
a volte son problemi veri a volte invece sono mancanza di esperienza
con il tool in questione (non nascondiamoci dietro un dito, spesso la
gente prima vince le gare sparando un prezzo bassissimo poi al limite
controlla il software che dovrà usare): risultato, si cominciano a
stratificare una pletora di workaround e soluzioni
specifiche, spesso anche sbagliate.
Finito il lavoro L, l'azienda X consegna al cliente un fork
sostanziale del progetto (voluto o meno) perchè "interfacciarsi con la
communità è una perdita di tempo" e "abbiamo dovuto fixxare un certo
numero di bug".
A quel punto il cliente si ritrova con un malloppo ingestibile e già
morto prima di essere usato (chi gestisce eventuali upgrade, ma
soprattutto come?).

Ora, qualcuno ci vede un limite del software OS, io ci vedo un limite
di tanti che ci si appoggiano solo _per risparmiare_ allettati dalla
mancanza del peso della licenza.
Chiunque ha lavorato con OS sa bene che questo caso descritto non è un
caso isolato, è _molto_ frequente.

Anche questo è un comportamento moralmente deprecabile, specie se
viene compiuto all'insaputa del cliente oppure mascherato sotto
discorsi del tipo:
"abbiamo fatto delle correzioni a dei difetti riscontrati", o frasi
del genere....
I commerciali delle ditte sono maestri nell'intortare i discorsi in
maniera da darla a bere a chiunque.

In casi come questi il software commerciale offre una garanzia in piu'
proprio dall'essere chiuso e quidi non modificabile.
:slight_smile:

Di nuovo non sono d'accordo, anzi penso il contrario (stavo per _è
vero il contrario_ ma diffido di pensa di avere la verità assoluta :))

La tua linea di ragionamento è secondo me sbagliata anche se fotografa
in qualche modo l'approccio standard all'Open Source
di molti che si basa su valutazioni e motivazioni spesso sbagliate
(vedi sopra) ma anche ovviamente su esperienze negative.

Il software OS non risolve tutti i mali del mondo, piuttosto offre un
modello di business molto più sostenibile ed aperto alla concorrenza e
quindi alla
innovazione (ci sono N studi in proposito) rispetto al modello basato
su SW proprietario.
Se certo uno di un modello potenzialmente buono prende solo certi
aspetti e ne piega in modo negativo altri
difficilmente il risultato finale sarà ancora buono :slight_smile:

Saluti,

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
638 iscritti al 28.2.2013

On Mon, Mar 11, 2013 at 03:20:31PM +0100, Andrea Peri wrote:

SI prende il software GFoss, ci mete dentro tre o quattro cambiamenti
al suo modo di funzionare, chesso' cambia qualche protocollo di
comunicazione , mondifica insomma 4 bischeratine.

Ovviamente lo fa' solo sulla versione rilasciata a quel cliente, ed
ecco che ha creato una nicchia di mercato tutta sua.

In questo caso la versione del software rilasciato non ha lo stesso valore
di quello "originale". Possiamo dire che il valore aumenta con l'aumentare
della condivisione effettiva e diminuisce con la sua diminuzione.

Chi gli garantisce che cio' che la ditta ha messo in piedi con il
software GFoss di turno sia replicabile o non sia una cosa
customizzata talmente che un altro soggetto non potrebbe rimetterci le
mani ?

Ci vuole capacita' di discernimento da parte del cliente.
Nel caso di software proprietario e' _sicuro_ che nessun altro soggetto
possa metterci le mani. Nel caso di software libero la capacita' di altri
di metterci le mani va valutata. Il bello e' che si puo' fare. Ad esempio
analizzando la comunita' che ruota attorno al software, composta sia da
sviluppatori che da autori di documentazione, traduttori, utilizzatori...
Quanto piu' amore riceve un progetto, tanto piu' il progetto cresce
rigoglioso.

Un'altro indice di valutazione e' anche la leggibilita' del codice,
la presenza di commenti, la presenza di documenti architetturali.
Un'altro e' la facilita' di partecipazione, il modo in cui viene recepito
un bug report...

Il effetti Scegliere software libero non ti esonera dal valutarne la qualita'.
Se si vuol essere esonerati si puo' scegliere il grosso fornitore e dire che
e' colpa sua, lasciando che le cose non funzionino e il paese vada a
scatafascio ...

In casi come questi il software commerciale offre una garanzia in piu'
proprio dall'essere chiuso e quidi non modificabile.

Questo non e' vero. Il software "proprietario" (il commercio non c'entra)
e' modificabile, ma solo dal proprietario. E le ragioni per modificarlo o
meno dipendono _esclusivamente_ dal proprietario.

Nel caso del software proprietario, alla domanda: "chi potra' metterci le
mani in futuro?" la risposta e' scontata: solo il proprietario.

Nel caso del software libero la risposta e' meno scontata. Puoi aumentare
le tue garanzie richiedendo al tuo fornitore di realizzare il maggior numero
di modifiche possibile in modo tale che queste siano accettate nella versione
comunitaria del software. Quella, per capirci, che e' considerata patrimonio
comune. Quella che non e' facile "rovinare" perche' riceve attenzioni da
un alto numero di soggetti.

--strk;

Sono d'accordo, anche se in questi tempi di outsourcing non va di moda: la competenza interna è un grosso investimento, in termini di qualità ma anche di mero risparmio economico. Ed il discorso non vale solo per la PA, ma anche per il privato che se di grossa dimensione ha dinamiche e difetti assolutamente simili a quelle che avete descritto nei precedenti interventi (per esempio scelgo il grande nome così non rischio che mi venga rinfacciata una scelta più economica ma meno blasonata... tanto non sono mica soldi miei e non sono misurato su quanto risparmio) ; parlo per esperienza diretta, avendo avuto modo di lavorare in entrambi i contesti. Indubbiamente andare "contro corrente" non è facile e spesso non è possibile farlo nel 100% dei casi per tanti motivi di tempo, scadenze, investimenti già fatti, facilità di trovare personale già addestrato su certi strumenti etc.; l'inerzia anche dei sistemi informatici è notevole.

Sapendo "fare" le cose puoi avere il polso della situazione su come vanno fatte per evitare problemi o costi futuri e per avere un'idea della congruità dei costi. Senza contare il fatto che le scelte devono essere calibrate sulla realtà della propria organizzazione, cosa che valuta molto meglio un "interno". E in un campo come quello dell'IT, in continua evoluzione e cambiamento, non si mantiene questa competenza senza "fare" in prima persona le cose; ovviamente facendosi aiutare anche dall'esterno, ma come giustamente dice stefano "mantenendo il controllo".

Il 11/03/2013 15:48, Stefano Iacovella ha scritto:

  Condivido in pieno quanto hai espresso Andrea. A me pare, dopo quasi venti anni di lavoro con la PA, che questo sia un problema generale nell' assegnazione di porzioni di lavoro ad un fornitore. Ossia che la migliore garanzia dei suoi interessi il cliente può averla solo se mantiene il controllo dei progetti.
  Tu mi fai le cose perché mi conviene così piuttosto che fare tutto al mio interno, ma io debbo mantenere il controllo, ossia possedere anche le competenze tecnologiche per capire se la tua proposta nasconde delle insidie. Insidie e problemi che possono anche essere causati in buona fede dal fornitore.
  Venendo all' Open Source io ritengo che da questo punto di vista un prodotto aperto è più facilmente controllabile. Fatto salvo che il controllore deve avere la voglia di esercitare il controllo e quindi attrezzarsi per farlo.

  Stefano

  Il giorno 11/mar/2013 15:20, "Andrea Peri" <aperi2007@gmail.com> ha scritto:
  
    >Cavallini wrote:
    >Ecco, appunto: quando paghi ti tuteli; ergo, fai un contratto con una
    >ditta, che ti da' supporto, alle condizioni contrattuali.
    >Certo, se qualcuno vuole usare software libero, senza pagare niente a
    >nessuno, e poi avere anche garanzie, che probabilmente non ha neppure
    >con il sw proprietario, li' non so se ridere, arrabbiarmi, o chiamare
    >la neuro.
    
    Occorre pero' essere onesti altrimenti parrebbe che il software GFoss
    offra totali garanzia.
    Non è del tutto vero, e occorre stare attenti perche' addirittura
    introduce delle dinamiche nuove che non sono presenti nel softwares
    commerciali.
    
    E di cui occorre stare attenti e con gli orecchi dritti.
    
    Ad esmepio:
    Il software commerciale proprio per il fatto di essere chiuso un
    vantaggiolo ha ed è che tutte le volte che lo compri sai quello che
    compri. :slight_smile:
    
    Mi spiego con il solito esempio della grande ditta.
    Si era ipotizzato che dal software proprietario ci poteva ricavare un
    extraguadagno da un eventuale sconto sull'acquisizione delle licenze.
    
    Ma anche dal software GFoss possono venire dei vantaggi, magari non
    come extra-guadagno subito, ma come ganrazia di una nicchia di lavoro
    per gli anni a venire.
    
    Infatti supponendo che abbia da mettere in piedi il solito sistema
    chiavi in mano, magari con un anno si manutenzione/gestione del
    sistema.
    SI prende il software GFoss, ci mete dentro tre o quattro cambiamenti
    al suo modo di funzionare, chesso' cambia qualche protocollo di
    comunicazione , mondifica insomma 4 bischeratine.
    
    Ovviamente lo fa' solo sulla versione rilasciata a quel cliente, ed
    ecco che ha creato una nicchia di mercato tutta sua.
    Se dopo quanche anno il sistema viene passato in appalto ad altro
    soggetto questi non riuscira' piu' a mettercile mani, i protocolli non
    tornano , non colloquino etc...
    
    Anche questo è uno scenario che il cliente potrebbe temere.
    Perche' creerebbe una sorta di dipendenza nei confronti di chi ha
    sviluppato/rimaneggiato il sistema.
    
    Chi gli garantisce che cio' che la ditta ha messo in piedi con il
    software GFoss di turno sia replicabile o non sia una cosa
    customizzata talmente che un altro soggetto non potrebbe rimetterci le
    mani ?
    
    Anche questo è un comportamento moralmente deprecabile, specie se
    viene compiuto all'insaputa del cliente oppure mascherato sotto
    discorsi del tipo:
    "abbiamo fatto delle correzioni a dei difetti riscontrati", o frasi
    del genere....
    I commerciali delle ditte sono maestri nell'intortare i discorsi in
    maniera da darla a bere a chiunque.
    
    In casi come questi il software commerciale offre una garanzia in piu'
    proprio dall'essere chiuso e quidi non modificabile.
    :)
    
    Saluti,
    
    --
    -----------------
    Andrea Peri
    . . . . . . . . .
    qwerty àèìòù
    -----------------
    _______________________________________________
    Gfoss@lists.gfoss.it
    http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
    Questa e' una lista di discussione pubblica aperta a tutti.
    I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
    638 iscritti al 28.2.2013

  _______________________________________________
  Gfoss@lists.gfoss.it
  http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
  Questa e' una lista di discussione pubblica aperta a tutti.
  I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
  638 iscritti al 28.2.2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 11/03/2013 15:55, Simone Giannecchini ha scritto:

Ciao a tutti, alcune _personali_ osservazioni inline.

Salve.
A me pare che le indicazioni di Simone siano estremamente ragionevoli
ed efficaci, e possano essere un'ottima base per le linee guida che
proponeva Luca.
Cordiali saluti.

- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFArzsACgkQ/NedwLUzIr4zDACfUvkyHd91eSqk29lATTzP4I+G
OaoAnRN9JHi7CamABC/jIrzmCwT88mQj
=sWCN
-----END PGP SIGNATURE-----

Il 11 marzo 2013 16:15, Alessandro Radaelli
<a.radaelli@comune.prato.it> ha scritto:

Sono d'accordo, anche se in questi tempi di outsourcing non va di moda: la
competenza interna è un grosso investimento, in termini di qualità ma anche
di mero risparmio economico. Ed il discorso non vale solo per la PA, ma
anche per il privato che se di grossa dimensione ha dinamiche e difetti
assolutamente simili a quelle che avete descritto nei precedenti interventi
(per esempio scelgo il grande nome così non rischio che mi venga rinfacciata
una scelta più economica ma meno blasonata... tanto non sono mica soldi miei
e non sono misurato su quanto risparmio) ; parlo per esperienza diretta,
avendo avuto modo di lavorare in entrambi i contesti. Indubbiamente andare
"contro corrente" non è facile e spesso non è possibile farlo nel 100% dei
casi per tanti motivi di tempo, scadenze, investimenti già fatti, facilità
di trovare personale già addestrato su certi strumenti etc.; l'inerzia anche
dei sistemi informatici è notevole.

Si, il problema della competenza non è assolutamente ripartibile nella
semplificazione:

PA = incompetenti
Privati = Competenti

Si tratta di una situazione assolutamente trasversale. Per mia
esperienza personale diretta, ed indiretta attraverso amici e
colleghi, ho incontrato persone assai competenti e volenterose in
alcune PA e uno sconsolante deserto di competenze ed idee in altri
casi, non di rado anche all'interno della stessa organizzazione.

Concordo con te che la dimensione non sia, da sola, garanzia di
qualità della competenza del fornitore.
Forse su questa cosa servirebbe una riflessione profonda per capire se
alcune clausole, che per loro natura dovrebbero tutelare
l'investimento pubblico, non vadano invece spesso nella direzione
opposta.
Penso in particolare a tutte le clausole su fatturato pregresso e
fidejussioni bancarie. Il razionale alla loro base è evitare che
l'appalto sia aggiudicata ad un fornitore improvvisato che non dia
garanzia sul buon esito. Ovviamente il fine è del tutto condivisibile,
nessuno di noi si augura che la PA sperperi i nostri soldi con il
primo venuto. L'effetto collaterale è che ci siano sempre i soliti
grandi nomi che concorrono per alcuni appalti, magari senza averne la
competenza adeguata.
Non credo siano particolarmente rari i casi in cui la competenza viene
reclutata post aggiudicazione.
Superare questo problema non è semplice, dal mio punto di vista
potrebbe aiutare la scomposizione delle forniture in porzioni più
piccole e più semplici da gestire e controllare. Certo questo complica
la gesione, devo bandire n gare invece di una, n procedure di
aggiudicazione n collaudi etc etc

Sapendo "fare" le cose puoi avere il polso della situazione su come vanno
fatte per evitare problemi o costi futuri e per avere un'idea della
congruità dei costi. Senza contare il fatto che le scelte devono essere
calibrate sulla realtà della propria organizzazione, cosa che valuta molto
meglio un "interno". E in un campo come quello dell'IT, in continua
evoluzione e cambiamento, non si mantiene questa competenza senza "fare" in
prima persona le cose; ovviamente facendosi aiutare anche dall'esterno, ma
come giustamente dice stefano "mantenendo il controllo".

Sapere fare o almeno saper gestire. E farsi carico della complessità e
dell'obbiettivo condividendolo tra cliente e fornitore.
Le storie di insuccessi, sempre dalla personalissima casistica
personale, sono spesso legate ad irrigidimenti da una delle due parti
o da entrambe.
Ad esempio il fornitore che cerca la soluzione più semplice ed
economica senza tener conto della reale necessità dell'utente.
Ma anche il cliente che si svincola dalla fornitura delegando tutta la
responsabilità al fornitore come se l'oggetto da realizzare non gli
interessasse in se ma solo come metro di valutazione della qualità del
fornitore.

E visto che siamo su GFOSS penso che l'uso di tecnologie open possa
solo agevolare questa collaborazione. Perchè se il mio fornitore è
vincolato, per sua natura o perchè così ha specificato nell'offerta da
tecnologia proprietaria, sarà più difficile reperire le competenze
necessarie all'azione di controllo.

Stefano

---------------------------------------------------
41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 15/03/2013 10:06, Stefano Iacovella ha scritto:

Si, il problema della competenza non è assolutamente ripartibile
nella semplificazione:

PA = incompetenti Privati = Competenti

Totalmente vero.

Concordo con te che la dimensione non sia, da sola, garanzia di
qualità della competenza del fornitore.

Concordo con l'analisi.

Superare questo problema non è semplice, dal mio punto di vista
potrebbe aiutare la scomposizione delle forniture in porzioni più
piccole e più semplici da gestire e controllare. Certo questo
complica la gesione, devo bandire n gare invece di una, n
procedure di aggiudicazione n collaudi etc etc

Non concordo sulla soluzione: secondo me l'unica soluzione possibile
e' un ente pubblico forte, con competenze interne, che sia in grado di
valutare con puntualita' ed attenzione la qualita' del lavoro fatto,
non pagando se non quando i risultati sono raggiunti.
A corollario, sono necessarie clausole contrattuali predisposte in
modo aderente al modello di sviluppo FOSS, come ad es. il gia' citato
obbligo di inserire il lavoro nel codice sorgente, ecc.
Togliere dal funzionario bendisposto verso FOSS l'onere di inventarsi
delle regole e' il minimo che si possa fare.
C'e' qualcuno con l'esperienza necessaria che ossa fare proposte?
Oppure buoni esempi da seguire?

Grazie.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFDS4IACgkQ/NedwLUzIr41OgCdFpJ8iAt0Ig+JpbRthlKiR1M2
1gYAn3FSQo9OYwodh2JJ9UlIGDubvT0X
=6zOz
-----END PGP SIGNATURE-----

Il 15/03/2013 10:06, Stefano Iacovella ha scritto:

dal mio punto di vista
potrebbe aiutare la scomposizione delle forniture in porzioni più
piccole e più semplici da gestire e controllare.

Il Codice dei contratti pubblici vieta espressamente il frazionamento di un appalto
allo scopo di non superare la soglia comunitaria. Inoltre l'ultima modifica del codice
vieta di richiedere un fatturato globale minimo come requisito per la partecipazione
agli appalti.

Ciao,
     Marco
-- Inviato dal mio cellulare Android con K-9 Mail.

Il 15 marzo 2013 17:25, Paolo Cavallini <cavallini@faunalia.it> ha scritto:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 15/03/2013 10:06, Stefano Iacovella ha scritto:

Si, il problema della competenza non è assolutamente ripartibile
nella semplificazione:

PA = incompetenti Privati = Competenti

Totalmente vero.

Concordo con te che la dimensione non sia, da sola, garanzia di
qualità della competenza del fornitore.

Concordo con l'analisi.

Superare questo problema non è semplice, dal mio punto di vista
potrebbe aiutare la scomposizione delle forniture in porzioni più
piccole e più semplici da gestire e controllare. Certo questo
complica la gesione, devo bandire n gare invece di una, n
procedure di aggiudicazione n collaudi etc etc

Non concordo sulla soluzione: secondo me l'unica soluzione possibile
e' un ente pubblico forte, con competenze interne, che sia in grado di
valutare con puntualita' ed attenzione la qualita' del lavoro fatto,
non pagando se non quando i risultati sono raggiunti.
A corollario, sono necessarie clausole contrattuali predisposte in
modo aderente al modello di sviluppo FOSS, come ad es. il gia' citato
obbligo di inserire il lavoro nel codice sorgente, ecc.
Togliere dal funzionario bendisposto verso FOSS l'onere di inventarsi
delle regole e' il minimo che si possa fare.
C'e' qualcuno con l'esperienza necessaria che ossa fare proposte?
Oppure buoni esempi da seguire?

Secondo me hai travisato il senso del mio intervento.
Prima di tutto non proponevo una soluzione ma un approccio, ossia
quello della riduzione della complessità attraverso scomposizione del
problema complesso in più problemi affrontabili e risolvibili. Non è
certo una noità ma può dare risultati anche nel campo specifico degli
appalti della PA per forniture di sistemi informativi territoriali.

E non esclude affatto la competenza, tutt'altro. Come dicevo nella
precedente email, e anche in questa, in una sezione che tu non hai
quotato, non c'è alternativa al fatto che il cliente debba mantenere
il controllo sul progetto. E per farlo deve avere, attraverso suo
personale, o attraverso un fornitore esterno le competenze
tecnologiche.
Dobbiamo poi metterci d'accordo su cosa intendi per ente pubblico
forte, per me anche qui vale la massima che "piccole è bello".

Stefano

---------------------------------------------------
41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

Il 15 marzo 2013 19:47, <marcocurreli@tiscali.it> ha scritto:

Il 15/03/2013 10:06, Stefano Iacovella ha scritto:

dal mio punto di vista
potrebbe aiutare la scomposizione delle forniture in porzioni più
piccole e più semplici da gestire e controllare.

Il Codice dei contratti pubblici vieta espressamente il frazionamento di un appalto
allo scopo di non superare la soglia comunitaria.

Ma se io PA devo creare una SDI ad esempio, e parto da zero, posso
creare bandi diversi di cui ad esempio uno abbia come oggetto la
progettazione complessiva e poi mettere a gare le varie componenti in
maniera separata?

Inoltre l'ultima modifica del codice
vieta di richiedere un fatturato globale minimo come requisito per la partecipazione
agli appalti.

Grazie per l'informazione, non lo sapevo, però mi pare di aver visto
anche in bandi recenti l'indicazione di un fatturato minimo in
attività aanloghe a quello oggetto di offerta, sbaglio?

Ciao e grazie

Stefano

Ciao,
     Marco
-- Inviato dal mio cellulare Android con K-9 Mail.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
638 iscritti al 28.2.2013

On 19:54 Fri 15 Mar , Stefano Iacovella wrote:

Ma se io PA devo creare una SDI ad esempio, e parto da zero, posso
creare bandi diversi di cui ad esempio uno abbia come oggetto la
progettazione complessiva e poi mettere a gare le varie componenti in
maniera separata?

In generale direi di si, ma bisogna vedere caso per caso; comunque la
fornitura o l'opera richiesta dev'essere completa, cioé idonea ad
essere utilizzata per gli scopi previsti. Dal punto di vista della PA
sono più facili da gestire due o più appalti sotto soglia che uno
sopra soglia, per cui il funzionario che deve gestire un appalto
questo problema se lo pone quasi sempre. Bisogna comunque stare
attenti a non esporsi a ricorsi delle grosse aziende, alcune delle
quali hanno nel loro organico più avvocati che tecnici. Per fortuna
oggi il funzionario pubblico ha possibilità di accessso ai documenti
che prima non aveva, come il sito dell'autorità sui contratti pubblici
dove si possono fare ricerche sulla giurisprudenza per articolo del
codice, e il sito istituzionale della giustizia amministrativa che ha
un database per la ricerche sulla giurisprudenza.

Grazie per l'informazione, non lo sapevo, però mi pare di aver visto
anche in bandi recenti l'indicazione di un fatturato minimo in
attività aanloghe a quello oggetto di offerta, sbaglio?

Quello è il fatturato specifico, che può essere indicato, relativo a
lavori, beni o servizi per attività analoghe all' oggetto
dell'appalto.

Ciao,
  Marco

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 15/03/2013 19:51, Stefano Iacovella ha scritto:

E non esclude affatto la competenza, tutt'altro. Come dicevo nella

si', certo, credo che siamo d'accordo.

Dobbiamo poi metterci d'accordo su cosa intendi per ente pubblico
forte, per me anche qui vale la massima che "piccole è bello".

Concordo: per me forte significa che ha in mano la situazione, non che
e' grande. Purtroppo vediamo spesso enti che, di fronte a lavori
malfatti, non sono in grado di contestare puntualmente la fornitura,
per mancanza di competenze interne o per altri problemi, e questo e'
senz'altro un male.

Saluti.
- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlFENkEACgkQ/NedwLUzIr7oRQCdGdi53oNmeHNPYOeuatXfNTpa
Fk0AoIoJRba2S2qstFO7pTE01Jw0RXjq
=qcCJ
-----END PGP SIGNATURE-----