RIF: [Discussioni]Cara commissione Meo...

Ven 27 Giu 2003 07:20:06 CEST

Vediamo se riesco a fare un passo in avanti:

1. Il software custom non è quello che gira su mainframe. Ci può essere software custom per mainframe e software custom per linux. Ci può essere un pacchetto per mainframe e un pacchetto per Linux. Non è che il software custom è il passato e i pacchetti il futuro. Non funziona così. Il software custom serve in certi ambiti, i pacchetti in altri. E' stato così e sarà così. By definition, e non perchè lo auspica Fuggetta o impone qualcun altro. 

2. Il software custom non è solo software in COBOL. Ci può essere software custom in COBOL e ci può essere software custom in JAVA, perl, php o quello che vuole lei.

3. Se il software è di SOGEI non c'è alcun vincolo a renderlo pubblico. Non è una questione di licenze. E' una questione di volontà. Se quelli di SOGEI non vogliono renderlo pubblico, il problema è a monte e non lo risolvo richiedendo una dichiarazione di principio a favore dell'open source. Quand'anche ci scrivessi su GPL, chi vieta a SOGEI di continuare a tenerlo chiuso in un cassetto?

4. Siccome ho lavorato per SOGEI (feci lo studio di visione del fisco telematico nel 95), ricordo benissimo quello che successe quando SOGEI propose di sviluppare e distribuire gratuitamente a tutti il software (inclusi i sorgenti) per i commercialisti che dovevano inviare le dichiarazioni. Ci fu una levata di scudi di società come Zucchetti e Buffetti che volevano fare i pacchetti relativi e che giudicavano l'iniziativa di SOGEI una turbativa del mercato.

5. Anch'io spero che in futuro le architetture su mainframe lascino il posto a piattaforme più agili. Ma primo oggi non è così (manco per nulla). Provi a chiedere al responsabile dei sistemi informativi alla pubblica istruzione quanto gli costerà (soldi e tempo) passare dai mainframe a altre architetture: un delirio. 
In secondo luogo, non cambiano i termini del problema. Non è che avendo Linux tutto il software che posso far girare su Linux è by definition pacchetto open source. Ci può essere chi offre un pacchetto proprietario per Linux. E ci potrà essere chi dovrà necessariamente richiedere lo sviluppo di software custom su Linux. Quindi i termini  generali del problema non cambiano rispetto a quello che dicevo io. 

6. Nel suo testo che l'implicita assunzione che il software proprietario è scritto male mentre quello libero è scritto bene. E chi lo ha detto?

Lo ripeto. Non sto dicendo che non ci sono problemi nei processi di procurement e gestione del software nelle PA. Lo so benissimo che ci sono e le assicuro che consumo il mio fegato per cercare di affrontarli. Vi sto dicendo che la lettura che voi date dei fenomeni è parziale o in alcuni casi fuorviante. Sull'analisi di massima siamo d'accordo: le cose non funzionano bene. E sulle conseguenze che se ne traggono che io non sono d'accordo con alcune cose che dite voi.

Alfonso

	-----Messaggio originale----- 
	Da: Antonino Iacono [mailto:aiacono a tiscalinet.it] 
	Inviato: gio 26/06/2003 23.35 
	A: discussioni a softwarelibero.it 
	Cc: 
	Oggetto: Re: [Discussioni]Cara commissione Meo...

	On Thu, 26 Jun 2003 17:11:39 +0200
	"Alfonso Fuggetta" <Alfonso.Fuggetta a polimi.it> wrote:

	> La PA non compra al supermercato. Deve fare un capitolato e una gara. Se nel capitolato scrivo che voglio una soluzione custom (per esempio per l'anagrafe tributaria), indico che compro servizi di sviluppo e la soluzione corrispondente (il sorgente). Lo scrivo prima ancora di sapere chi partecipa. E, come continuo a ripetere, in questi casi l'AIPA si assicura che la proprietà del codice sia della PA appaltante, come è straovvio che sia.

	e dopo essersene assicurata cosa fa?
	Ho notato che lei cita spesso l'anagrafe tributaria, bene, visto
	che io ne faccio parte, pur in periferia, e, si sa, le decisioni
	in questi casi si prendono a RM, mi permetta di rivolgerle qualche
	domanda.
	Il software custom realizzato (o fatto realizzare) da Sogei per
	conto del Ministero dell'Economia e/o delle Agenzie Fiscali,
	dovrebbe essere di proprieta' della PA appaltante che puo',
	come ha scritto lei, farne quello che vuole.
	Per quanto ne so' il codice finisce nei cassetti e nei nastri
	e nessuno, o pochi sono autorizzati e/o capaci a mettevi mano.
	Eppure basterebbe pubblicarlo sulla intranet.
	Su 20.000 dipendenti che vi si connettono qualche centinaio sono
	sicuramente in grado di studiare quel codice e trovarvi errori
	o solamente procedure che potrebbero essere migliorate.
	Ha idea di quanti "errori del Fisco" e "cartelle pazze" si
	eviterebbero?

	Ogni anno, in questo periodo, viene realizzato il programma
	per la compilazione e la trasmissione del modello Unico.
	E' sicuramente un grande passo avanti e un vanto dell'Italia
	in Europa, ma, anche qui con poco si potrebbe fare molto di
	piu'.
	Il programma realizzato in Java, *stranamente* funziona solo
	per Windows e Macintosh.
	E, anche in questo caso, la pubblicazione del codice seppur
	limitata ai dipendenti del Ministero e dell'Agenzia delle
	Entrate, nel sito intranet porterebbe alla realizzazione di
	un sorgente piu' pulito, senza le chiamate alle librerie
	proprietarie del S.O. e quindi realmente portabile su altri
	sistemi operativi.
	E se si pubblicassero i sorgenti su internet?

	Sono convinto che nel giro di una settimana ne verrebbe fuori
	una versione per GNU/Linux.
	E non credo di dire eresie affermando che nella altre
	Amministrazioni la situazione e' simile se non peggiore.
	Forse servirebbe un po' di formazione/informazione ai
	dirigenti pubblici su questi temi?

	Oppure si e' ancora convinti che la sicurezza si ottiene
	blindando i sorgenti? Convinzione ancora molto in auge
	negli uffici ministeriali.
	Ho notato pure che spesso lei parla dell'uso del CICS nelle
	amministrazioni pubbliche.
	E' vero che fino a 5/6 anni fa il 99% del software girava
	su questa infrastruttura, ma negl'ultimi tempi questa
	percentuale e' andata via via scendendo.
	Oggi non e' raro vedere, anche nella Pubblica Amministrazione
	prodotti software che fanno uso del Web come interfaccia
	grafica, molte procedure, che prima richiedevano SNA (con
	tutto cio' che ne consegue) adesso vanno tranquillamente
	sotto TCP/IP.
	Il software custom per antonomasia quello scritto in Cobol,
	sta scomparendo, sostituito spesso da prodotti piu' leggeri
	piu' riusabili, piu' facilmente e liberamente compilabili,
	in poche parole piu' alla portata di tante persone.
	Se prima un programmatore non poteva certo avere a casa
	un S390 e smanettarvi sopra, oggi si mette il sorgente c,
	java, perl, php in un pen drive e fuori dall'ufficio lo
	integra e modifica come vuole.
	Per questo credo non si debba fare troppo affidamento ai
	quei dati e quelle percentuali, perche' rispecchiano un
	modo di usare l'informatica molto diverso da quello attuale.

	Grazie

	--
	antonino
	---------------
	http://opensignature.sourceforge.net
	jabber://aiacono@amessage.de
	_______________________________________________
	Discussioni mailing list
	Discussioni a softwarelibero.it
	http://lists.softwarelibero.it/mailman/listinfo/discussioni
	Totale iscritti:     201 

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        winmail.dat
Tipo:        application/ms-tnef
Dimensione:  9246 bytes
Descrizione: non disponibile
URL:         <http://lists.softwarelibero.it/pipermail/discussioni/attachments/20030627/c444aa1f/attachment.bin>