>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. :) 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
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. Stefano Il giorno 11/mar/2013 15:20, "Andrea Peri" <[hidden email]> ha scritto:
>Cavallini wrote: _______________________________________________ [hidden email] 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 |
In reply to this post by Andrea Peri
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 <[hidden email]>: >>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. :) > 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. > :) 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 :) > > Saluti, > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
In reply to this post by Andrea Peri
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; _______________________________________________ [hidden email] 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 |
In reply to this post by Stefano Iacovella
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:
_______________________________________________ [hidden email] 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 |
In reply to this post by Simone Giannecchini
-----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----- _______________________________________________ [hidden email] 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 |
In reply to this post by Alessandro Radaelli
Il 11 marzo 2013 16:15, Alessandro Radaelli
<[hidden email]> 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". > 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 _______________________________________________ [hidden email] 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 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----- _______________________________________________ [hidden email] 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 |
>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. _______________________________________________ [hidden email] 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 |
In reply to this post by pcav
Il 15 marzo 2013 17:25, Paolo Cavallini <[hidden email]> 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 _______________________________________________ [hidden email] 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 |
In reply to this post by Marco Curreli
Il 15 marzo 2013 19:47, <[hidden email]> 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. > _______________________________________________ > [hidden email] > 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 [hidden email] 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 _______________________________________________ [hidden email] 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 |
In reply to this post by Stefano Iacovella
-----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----- _______________________________________________ [hidden email] 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 |
Free forum by Nabble | Edit this page |