[Egov] software libero per la pubblica amministrazione

Roberto Resoli resoli at libero.it
Fri Apr 22 16:51:25 UTC 2005


> ----- Original Message ----- 
> From: "Bud P. Bruegger" <bud at comune.grosseto.it>
> To: "e-government e software libero" <egov at softwarelibero.it>
> Sent: Friday, April 22, 2005 11:11 AM
> Subject: Re: [Egov] software libero per la pubblica amministrazione
> 
> 
> At 22.16 21/04/2005 +0200, you wrote:
> 
>>>Ottima idea, era già in cantiere anche per noi
>>>OpenPA è a disposizione per diffondere l'idea e i contenuti
>>>inoltre, lavorando anche io per una pubblica
>>>amministrazione gli spunti non mancano.
>>>Direi di iniziare a contarci, mettiamo giù degli
>>>obbiettivi e poi iniziamo.
>>
>>Oltre che a contarci potremmo iniziare anche a raccogliere informazioni 
>>sul software esistente.
>>Fatevi avanti.
>>F.
> 
> 
> Sugli obiettivi sono del tutto d'accordo.  Sto provando da un bel puo (da 
> quando ho iniziato lavorare per il Comune) in questa direzione. [Parlo come 
> individuo, non come Ente].  L'approccio che prendo non e' quello di avere i 
> prodotti, però.  Prodotti, senza supporto e senza evoluzione continua non 
> sono molto attrattivi.  Ormai non sarò l'unico di guardare quanto e' attivo 
> una mailing list prima di decidere di usare un prodotto open source...
> 
> Da questo punto di vista, mi sembra che il fattore critico sta nella 
> collaborazione su prodotti tra Enti, non sui prodotti stessi.  A me sembra 
> che, anche se ci fosse un bel prodotto libero, una Ente che no ha capacità 
> interna ed ha al meno un impiegato con cultura di collaborazione open (con 
> o senza source), non e' probabile di adottare quella software o se lo 
> fosse, non ottiene tutti i benefici che vengono della liberta' (adattazione 
> locale, ecc.).
> 

Questo è fondamentale. L'Open Source vive di collaborazione e attività
continua. Senza la massima apertura (non solo  verso altre  P.A., ma verso CHIUNQUE 
voglia collaborare ) i progetti non raggiungeranno, per quanto buoni,
la massa critica necessaria per evolversi secondo i meccanismi
virtuosi che ben conosciamo. 

> Il nostro Comune ha scritto il maggior parte del suo software inhouse.  E 
> questo ha portato tanti vantaggi.  Ad esempio, tutti i nostri 
> prodotti/componenti seguono una unica strategia e tutti sono integrati.  Ad 
> esempio, abbiamo un unico DBMS per tanti applicazioni (da anagrafe a 
> polizia municipale) e tutti vedono la stessa toponomastica.  

Questo vale pari pari per il comune di Trento.
(Spesso parlando con bud mi viene da pensare che Grosseto e Trento siano
comuni "gemelli" dal punto di vista informatico)

> In contrasto, 
> siamo in lotta continua con fornitori esterni che ogni uno vuole il suo 
> DBMS su la piattaforma sua preferita, vuole rifare mezza della anagrafe, 
> fare la sua gestione dei controlli di accesso (invece di integrarsi in una 
> soluzione single sign on), e la sua interpretazione di integrazione 
> significa di comprare tutti i suoi prodotti.

Questo è  meno vero per noi, forse perchè il mercato informatico
in Trentino è meno aggressivo...
Le "lotte" con i fornitori sono molto meno frequenti.

> 
> I tempi di scrivere grandi applicazioni inhouse sono ormai finiti.  Ci sono 
> rimasti pochissimi Enti locali che lo fanno--e penso che tutti si rendono 
> conto che non e' piu' sostenibile di mettere il costo dello sviluppo e 
> della manutenzione di un prodotto su un singolo cliente.  Il vero 
> potenziale dell'open source per Enti Locali (quelli con il piu' ampio 
> potenziale di riuso e quelli piu' pragmatici e result-oriented) nella 
> collaborazione per lo sviluppo e la manutenzione di applicazioni.  Questo 
> sarebbe la ricetta di salvaguardare gli vantaggi di capacità interna, di 
> integrazione, ecc. e lo stesso condividere il suo costo con altri.

E' vero; secondo la mia esperienza di sviluppo basato su progetti OpenSource,
esso è diventato il modo per sfuggire alla tradizionale dicotomia "build" or "buy",
introducendo il paradigma "use & collaborate".
Come chiunque abbia utilizzato il sw sviluppato in una ATTIVA comunità OSS sa,
l'assistenza che si riceve dalla comunità tramite documentazione, web, mailing lists
è diversi ordini di grandezza migliore di quella dei prodotti proprietari.
Fondamentale comunque è l'investimento sulle persone e sulla formazione; non va dimenticato 
che quello che nel paradigma "use & collaborate" si risparmia rispetto al "buy" va
reinvestito in conoscenza e cura della motivazione degli sviluppatori.

Questo ha permesso al comune di Trento, ad esempio, di poter transitare in 
tempo relativamente breve (circa un paio d'anni) da
un modello di sviluppo obsoleto (per quanto ancora efficacissimo), 
con applicazioni RPG AS400 "green screen", ad un framework applicativo web-based, MVC, 
three-tier basato sull'applicazione "leggera" di J2EE.
Questo unicamente utilizzando e costruendo su  strumenti liberi come Jakarta Tomcat e Struts, 
FOP, Apache web server, Eclipse, e molti altri che ora non mi vengono in mente.
Il framework, una volta ripulito e documentato, verrà messo a disposizione dell'intera
comunità (non solo delle atre P.A.).
Questo modello tra l'altro permette di integrare magnificamente nel sistema informativo le vecchie applicazioni
(non si butta via niente!) con quelle nuove;  terminale e browser lavorano fianco a fianco.

Su un'altro versante,  il comune
ha ritenuto di rilasciare in GPL il lavoro (già disponibile su http://j4sign.soutceforge.net ) 
fatto per la firma digitale, nella speranza:
1) Di innescare la collaborazione di altri sviluppatori.
2) Di contribuire allo sviluppo di strumenti liberi in questo campo che diventerà
fondamentale importanza nel prossimo futuro.

> 
> Open source da solo non si puo fare, o al meno e' triste.  Open Source 
> senza coinvolgere l'utente finale nel ciclo del software toglierebbe una 
> componente essenziale dell'approccio.  Open source richiede sia il 
> coinvolgimento forte dei Enti che usano, che la collaborazione tra molti.
> 
> Non e' per niente facile però di implementare un tale visione.  Come dici 
> tu si deve iniziare con passi piccoli.  Mi sembra che molto lavoro e' già 
> al interno dei Enti:  Chi decide deve avere esperienze pratiche su come 
> funziona l'open source.  Non e' pensabile di fare investimenti 
> significativi che poi dipendono su fattori sconosciuti/puramente teorici e 
> su partners sconosciuti.  Per questo penso che una persona al interno 
> dell'Ente chi già vive open source e' indispensabile.  Penso anche che ci 
> devono essere veri collaborazioni che creano storie di successo e fiducia 
> nell'approccio.
> 
> Ho visto tanti Comuni che decidono di adottare l'open source, poi tanti 
> policy makers che promuovono l'open source, poi certo la comunità (esterna 
> dall'Ente) che promuove, e alcuni (già pochi) imprese che fanno prodotti 
> open source.  Ma non vedo come questa crea fatti, come arriva nella 
> realtà.  Molte cose che ho visto io rimangono li', rimangono parole e 
> dichiarazioni...  Penso che dobbiamo fare meglio, e nella mia oppinione 
> questo significa collaborazioni veri tra enti.
>
Cosa aggiungere? Tutto questo mi sembra sacrosanto.
In una parola: le comunità open source nascono " dal basso",  attraverso 
uno spontaneo moto collaborativo.

> Il nostro Comune ha ovviamente fatto alcuni passi su questa 
> strada.  Abbiamo già sperimentato collaborazioni open source su piccoli 
> progetti non troppo critici.  E il nostro interesse e la nostra fiducia 
> interno ha certamente aumentato, ma non e' ancora arrivato al punto di 
> essere pronto di applicarla su grandi progetti critici.  Abbiamo fatto 
> anche un passo importante iniziando veri collaborazioni con altri Enti, al 
> momento maggiormente con il Comune di Trento (con Roberto chi e' anche su 
> questa lista).  Siamo anche nel processo di estendere questa collaborazione 
> ad altri Enti Locali.  Per questo stiamo organizzando uno workshop su 
> collaborazione open source a quale invitiamo enti locali che già fanno open 
> source, che già hanno le persone e la cultura interna...  Teniamo la 
> riunione piccola a posto per evitare grandiosi dichiarazioni e 
> presentazioni e invece identificare alcune aree concreti su quale 
> collaborare.  Meglio piccole cose che non richiedono finanziamenti esterni 
> e vengono fatti e completati, che cose grandiose che poi finiscono con 
> l'annuncio.  Vi prego di segnalarmi Enti locali che sono già pronti e 
> disposto di concretizzare collaborazioni vere.
> 
> In tutto questo processo, mi sembra che non si puo dare abbastanza 
> importanza alle persone interne ai Enti con cultura open source.  Penso che 
> la crescita' del open source nella P.A. e' solo possibile tramite questi 
> persone.  Mi sembra indispensabile di creare un canale per mettere queste 
> persone in contatto--e la cosa bella e' che gia' esiste:  si chiama ROSPA 
> (Rete dell'Open Source nella Pubblica Amministrazione) ed e' al sito 
> www.rospa.it (in questo momento sembra giu', la copia di google e' qui: 
> http://64.233.183.104/search?q=cache:gUKd-1XEwzAJ:www.rospa.it/+rospa+rete+open+source+&hl=it&client=firefox-a). 
> 
> 
> Sono molto interessato di sentire che ne pensate di questa strategia.
> 
> saluti
> 
> -bud
> 
> 
> 
> -------------------------------------------------------------------------------------------------
> Ing. Bud P. Bruegger, Ph.D.                 +39-0564-488577 
> (voice),  -21139 (fax)
> Servizio Elaborazione Dati                    e-mail:  bud at comune.grosseto.it
> Comune di 
> Grosseto                            http://www.comune.grosseto.it/cie/
> Via Ginori, 
> 43                                      http://OpenPortalGuard.sf.net
> 58100 Grosseto (Tuscany, Italy)           jabber:  bud at amessage.info
> 
> Free Software in Public Administration:  not just a good idea, but a necessity
> 
> Perfection is attained, not when there is nothing more to be added, but 
> when there is nothing more to be taken away -- Antoine de Saint-Exupery 
> 
> _______________________________________________
> Egov mailing list
> Egov at softwarelibero.it
> http://softwarelibero.it/cgi-bin/mailman/listinfo/egov





More information about the Egov mailing list