<div>Ciao Andrea, ho letto solo ora la tua mail di ieri:</div>> Di solito quelle a massimo ribasso si adottano nelle situazioni in cui<br>> cio' che va fatto è indicutibile assolutamente certo e senza una<br>> componente progettuale<br>

> rilevante. Non è il nostro caso.<br clear="all">
<div><div> </div><div>Non sarei proprio sicuro!</div><div>Al contrario, esistono molti casi (purtroppo) di gare in cui vince il massimo ribasso e la componente progettuale non esiste proprio.</div><div>Probabilmente non e' il caso di Regione Toscana, ma sicuramente lo e' quello di altre Regioni o Province che si appoggiano a societa' in house che a loro volta realizzano gare per generici "servizi GIS" [1].</div>


<div>E lo e' anche, a parer mio, quello di enti che realizzano direttamente (senza passare per societa' in house) bandi di gara monumentali, a volte da svariati milioni di euro.</div><div>Vogliamo fare un elenco e pubblicarlo?</div>


<div><br></div><div>Il problema e' che spesso, in questi casi, i capitolati tecnici non hanno assolutamente nulla di progettuale.</div><div>Spesso non hanno elementi di dettaglio sufficientemente dettagliati.</div><div>

Spesso non hanno nemmeno indicazioni precise per capire "cosa serva realmente" all'ente, a quante persone, in quali processi amministrativi, ...</div>
<div>Spesso, con "contrattoni" di questo tipo, prima di scrivere la prima linea di codice ci vogliono diverse riunioni con decine di persone (dell'ente) [2], la quali hanno posizioni diverse tra loro, con idee poco chiare, e con richieste contrastanti.</div>


<div>Spesso la direzione lavori e' inadeguata, o a volte assente.</div><div>Spesso il linguaggio usato dai diversi attori (sviluppatori, responsabili progetto, utenti, ...) e' talmente diverso che si fatica a trovare la quadra.</div>


<div>Spesso e' difficile far passare una tecnologia open perche' "... qui da noi non abbiamo le competenze per ...".</div><div>Ciononostante, in questi "contrattoni" quadro viene richiesta comunque una progettazione, che significa tempo e persone non per sviluppare, ma per capire che cosa occorra.</div>


<div>E sempre piu' spesso, questi "contrattoni" quadro prevedono tariffe che a volte toccano i 150euro/giorno ("all inclusive", quindi comprensivi di tutti i costi di eventuale viaggio, trasferta, etc).</div>


<div><br></div><div>Ecco, secondo me il Problema con la "P" maiuscola sono i contratti di questo tipo ... i "contrattoni" da svariati milioni e senza progettualita' a monte.</div><div>Progettualita' che, a parer mio, si puo' realizzare solo con una corretta e trasparente collaborazione tra settore pubblico, settore privato, universita' e organizzazioni no-profit, ma al di fuori di "contrattoni" quadro di cui sopra.</div>


<div><br></div><div>Sarebbe bello riuscire ad avere anche in Italia (o meglio in Europa?) qualcosa tipo questo: <a href="http://www.whitehouse.gov/innovationfellows" target="_blank">http://www.whitehouse.gov/innovationfellows</a></div>

<div>
Sigh!</div><div><br></div><div>pg</div><div><br></div><div><br></div><div>[1] per chi non lo sapesse una di queste realta' e' CSI-Piemonte, che a livello operativo conta diversi supporter GFOSS e sta virando sempre piu' al mondo open, mentre a livello politico/dirigenziale ha da poco messo in Cassa Integrazione a 0 ore circa 200 persone e bandisce garoni come questo (2011):</div>

<div><a href="http://www.csipiemonte.it/cms/images/stories/files/forniture_gare/archivio-gare/2011/G11-14SE-AAA-avviso_appalto_aggiudicato_GUCE_inviato.pdf">http://www.csipiemonte.it/cms/images/stories/files/forniture_gare/archivio-gare/2011/G11-14SE-AAA-avviso_appalto_aggiudicato_GUCE_inviato.pdf</a></div>

<div><br></div><div>[2] qualche anno fa, in una regione italiana di cui non faccio il nome, mi e' capitato di partecipare a riunioni sul tema "metadati" (che notoriamente e' un argomento dei piu' noiosi) e avere di fronte circa 10 persone dell'ente, e discutere per ore di ... label da usare nella webapp di consultazione ... no comment!</div>


<div><br></div><div>______________________________</div><div>Piergiorgio Cipriano</div><div> </div></div>
<br><br><div class="gmail_quote">Il giorno 11 marzo 2013 20:42, Andrea Peri <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Purtroppo capisco che non sono riuscito a spiegarmi abbastanza bene.<br>
<br>
>Ehm, l'aver scritto la gara di appalto in modo corretto invece di<br>
>prendere il prezzo piu' basso dal primo pollo che passa?<br>
<br>
Questo non centra niente con l'obiettivo del mio discorso, ma pero'<br>
penso che sia utile una precisazione.<br>
Ci sono vari tipi di gare. Ci sono quelle basate sul prezzo piu' basso<br>
ma ci sono quelle basate sulla "offerta economicamente piu'<br>
vantaggiosa".<br>
<br>
Di solito quelle a massimo ribasso si adottano nelle situazioni in cui<br>
cio' che va fatto è indicutibile assolutamente certo e senza una<br>
componente progettuale<br>
rilevante. Non è il nostro caso.<br>
Il caso teorico che indicavo io (assolutamente di fantasia e senza<br>
alcun riferimento a fatti e cose realmente esistiti) era di un<br>
soggetto che è chiamato a progettare un sistema di complessita'<br>
medio-alta proponendo lui la strada da seguire.<br>
Ovvio che in una situazione di questo genere non si va certo a massimo ribasso.<br>
<br>
>In definitiva, usare software open source non garantisce di per se<br>
>_niente_ soprattutto quando ci si affida a persone/aziende prive dei<br>
>requisiti e della esperienza<br>
>necessarie a garantire un corretto approccio alla comunità. Ma questo<br>
>non è colpa dell'open source è colpa:<br>
><br>
>-a- delle aziende che approfittano dei progetti Open Source come dei<br>
>parassiti senza partecipare in alcun modo allo sforzo (soldi, codice,<br>
>doc, support in ml, etc..)<br>
>-b- di chi scrive i bandi richiedendo Open Source senza fare un minimo<br>
>di attenzione a come poi il lavoro venga fatto ed ad un corretto suo<br>
>posizionamento verso i progetti e le rispettive community di<br>
>riferimento<br>
<br>
Come dicevo non sono riuscito a spiegarmi e quindi ti ho confuso. :)<br>
<br>
Io non facevo un caso esplicito di un lavoro che nasce gia' basato su<br>
software GFoss, ma piuttosto in cui viene selezionato con gara un<br>
soggetto che poi dall'alto della sua competenza sapra' lui discernere<br>
la soluzione (commerciale o gfoss ) da usare.<br>
Lo so' che è uno scenario teorico e probabilmente non reale, ma serve<br>
solo per arrivare aspiegare il concetto che una azienda sa' trarre<br>
profitto in ogni situazione e non sempre la semplice scelta di un<br>
software GFoss da di per se' garanzia al cliente e in determinate<br>
condizioni (come nel caso che dici te quando il capitolato non è<br>
scritto bene) puo' addirittura nuocere.<br>
<br>
Ovviamente non volevo assolutamente dire che non ci si deve fidare<br>
delle ditte che lavorano con il software GFoss.<br>
<br>
E comunque non volevo certo entrare nel discorso di come dovrebbe<br>
essere fatto un capitolato di lavoro su software GFoss.<br>
<br>
Saluti,<br>
<span><font color="#888888"><br>
--<br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . .<br>
qwerty àèìòù<br>
-----------------<br>
_______________________________________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
638 iscritti al 28.2.2013</font></span></blockquote></div><br>