confsl 2010 - Conferenza Italiana sul Software Libero

Transcription

CONFSL 2010
Atti della IV Conferenza Italiana sul Software Libero
Cagliari, 1112 Giugno 2010
Editor: Vincenzo Bruno
Comitato Tecnico Scientifico
Vincenzo Bruno (Program Chair )
Maurizio Agelli Walter Ambu Nicola Asuni Ernesto Belisario Francesco Bolici Davide Carboni Carlino Casari Marco Ciurcina Vincenzo D'Andrea Carlo Daffara Renzo Davoli Stefano De Paoli Roberto Dentice Arturo Di Corinto Roberto Di Cosmo Paolo Didonè Daniel Donato Davide Dozza Gianni Fenu Matilde Ferraro Giovanni Battista Gallus Roberto Galoppini Massimiliano Gambardella Flavia Marzano Angelo Raffaele Meo Francesco Paolo Micozzi Alessandro Narduzzo Gavino Paddeu Norberto Patrignani Susanna Pelagatti Massimo Rimondini Andrea Rossato Alessandro Rossi Cristina Rossi Lamastra Alessandro Rubini Francesco Rullani Claudio Sacerdoti Coen Alberto Sillitti Domenico Talia Maurizio Teli Francesco Virili Stefano Zacchiroli
INTRODUZIONE
Con questa quarta edizione della ConfSL facciamo il punto sul Software Libero in Italia, sulla sua diffusione nella PA, sulla produzione di prodotti e servizi basati su nuovi modelli di business e sullo stato delle comunità che ruotano intorno al Software Libero.
Sono passati circa 10 anni da quando in Italia si e' organizzato il primo LinuxDay e da allora e' stato un crescendo sotto tutti i punti di vista: tecnologico, giuridico, economico e soprattutto sociale. La vera rivoluzione che stiamo vivendo consiste nel fatto che il Software Libero e' ormai un fenomeno di massa, ampiamente diffuso sia tra i ragazzini “nativi digitali” che sui Pc di aziende e Pubbliche Amministrazioni. Ormai installare Gnu/Linux non e' più quella impresa che poteva essere nel 2001, quando far funzionare una scheda grafica rappresentava un piccolo passo per l'umanità ma un grande salto (di gioia, nel vero senso della parola) per l'appassionato smanettone. Oggi il Software Libero gira tranquillamente sui portatili e sui desktop di moli utenti e su una grossa fetta di server piccoli e grandi. Basta scaricare il CD di una qualsiasi “distro” per avere in meno di un'ora un sistema operativo libero sul proprio portatile e non manca il supporto di aziende grandi e piccole per qualsiasi necessità aziendale.
Allora quale e' il senso di una convention nazionale di così ampia portata? Esistono in Italia molti eventi incentrati a vario titolo sul Software Libero: dal citato LinuxDay ad una serie di eventi più o meno verticalizzati su un prodotto o una comunità. Ci sono quelli mono marca, come l'Open Source Day (Red Hat Symposium) del 17 giugno, quelli monotematici, tipo la PyCon, conferenza Python, del 79 maggio a Firenze, e così via. In generale ognuno di questi e' focalizzato su una comunità ristretta, mentre la ConfSL ha come suo principale obiettivo quello di riunire le diverse anime del Software Libero, in modo da creare un punto di aggregazione annuale in cui scambiare conoscenza, discutere idee, avanzare proposte di collaborazione. La ConfSL e' sempre organizzata in sinergia tra Università e Associazioni. Così e' stato a Cosenza nella prima edizione (l'idea della ConfSL e' partita proprio dall'Associazione Hacklab Cosenza), e nelle successive di Trento e Bologna, cosi come in questa di Cagliari.
In questa edizione del 2010 si riuniscono nel capoluogo sardo molti soggetti diversi: abbiamo le due sessioni parallele di stampo scientifico, con la partecipazione di ricercatori, aziende e associazioni da tutta Italia; le sessioni di Workshop organizzate dal Java User Group Sardegna, dei workshop su Postgres organizzate dall'Italian PostgreSQL Users Group, oltre a 3 sessioni dedicate alla Pubblica Amministrazione ed un Brokerage Event finalizzato a far incontrare soggetti diversi per avviare nuovi business.
Il Software Libero e' ormai maturo, ma c'è ancora moltissimo da lavorare. Non c'è solo il software da sviluppare ma e' necessario approfondire la conoscenza dei risvolti giuridici del SL (la recente sentenza della Corte Costituzionale sulla Legge Regionale Piemontese per il Software Libero ne e' la prova), dei suoi modelli economici e delle sue ricadute sulla società. Per tali motivi molte delle Sessioni della ConfSL sono su aspetti Filosofici
GiuridiciSociologici e su Enti Pubblici/PA/Scuola.
Questa conferenza e' ormai una tradizione e si spera che continui finché ci sarà in Italia la necessità di sostenere il Software Libero contro gli attacchi monopolistici del Software Proprietario, con l'obiettivo di garantire maggiori benefici ai cittadini a partire dalla loro Libertà. Organizzatori
Un enorme grazie va a tutti gli organizzatori che hanno lavorato duramente affinché si potesse realizzare questa Conferenza.
General chair della conferenza e' Giulio Concas, Università di Cagliari.
Il comitato organizzatore (Steering Committee) e' costituito da:
•
Vincenzo Bruno, Hacklab Cosenza / Università della Calabria
•
Vincenzo D'Andrea, Università di Trento
•
Renzo Davoli, Università di Bologna
•
Michele Marchesi, Università di Cagliari
•
Flavia Marzano, UnaRete
Comitato Organizzatore Locale
•
Giammaria Ogana, GULCh
•
Romina Lobina, GULCh
•
Nicola Asuni, GULCh
•
Giuseppe Destefanis, Università di Cagliari
Tutti i contenuti di questo libro, tranne dove espressamente indicato dagli autori, sono rilasciati con licenza Creative Commons – Attribution – Share Alike 2.5
http://creativecommons.org/licenses/bysa/2.5/it/
Indice generale
L'ATTIVITÀ DI NORMAZIONE:
PRINCIPI, SOGGETTI E PROBLEMATICHE........................................................1
LE LICENZE PUBBLICHE DI RIUSO E IL SOFTWARE LIBERO.............................16
LIBERAMENTE DIDATTICA LIBERA NEL COMUNE DI PISA...................................................27
PA E SOFTWARE A CODICE SORGENTE APERTO: IL DIFFICILE CONNUBIO TRA FLOSS, RIUSO E CONCORRENZA. ..........................................................36
CAQDAS – UN APPROCCIO LIBERO.........................................................................46
ANALISI ETNOGRAFICA DI UN PROGETTO LIBERO............................................59
FAME, A METHODOLOGY FOR ASSESSING SOFTWARE MATURITY...............71
IMPACT AND ECONOMIC RISK ASSESSMENT OF FLOSS ADOPTION BY PUBLIC ADMINISTRATIONS.............................................................................83
DESKTOPASASERVICE FACILE CON VIRTUAL DISTRO DISPATCHER.........95
UNA SUITE INTEGRATA DI SERVIZI PER PA E IMPRESE
AN INTEGRATED SERVICE SUITE FOR PUBLIC ADMINISTRATIONS AND ENTERPRISES.....................................................................................................105
SOFTWARE LIBERO E RADIO 2.0: ANB WEB RADIO, UN ESPERIMENTO SOCIALE..............................................................................................................118
LE CARATTERISTICHE DELLE IMPRESE SOFTWARE IN EMILIAROMAGNA: TRE MODELLI DI IMPRESA A CONFRONTO.................................................129
UN ECOSISTEMA SOSTENIBILE: IL MODELLO DI JAPS 2.0..................................................................................139
SVILUPPARE APPLICAZIONI WEB CON IL FRAMEWORK PHP SYMFONY.....148
THE EVOLUTION OF DEFECTS AND PATCHES IN SOURCEFORGE PROJECTS: A QUANTITATIVE ANALYSIS ........................................................................162
LA STRUTTURA DELLE RELAZIONI NEI PROGETTI DI SOFTWARE LIBERO: UN’ANALISI COMPARATA..............................................................................176
SHARE IT AND BRING IT HOME: OPEN SOURCE, COMMONS AND PIRATES 187
RIUNIONI DIGITALI .........................................................................................202
ILDJIT: A parallel, free software and highly flexible Dy-namic Compiler...........212
Atti della IV Conferenza Italiana sul Software Libero, 1112 Giugno 2010, Cagliari
L'ATTIVITÀ DI NORMAZIONE:
PRINCIPI, SOGGETTI E PROBLEMATICHE
Aliprandi, Simone, Progetto Copyleft-Italia.it, www.copyleft-italia.it,
simone.aliprandi@gmail.com, www.aliprandi.org
Questo paper prosegue nel solco dell'analisi da me effettuata nelle due scorse edizioni della ConfSL in
materia di standard informatici aperti ed interoperabilità, ponendo questa volta la lente su alcuni
aspetti particolarmente tecnici, non molto noti ma non per questo poco importanti.
Infatti l'argomento degli standard e dell'interoperabilità assume sempre più valore nel dibattito
relativo allo sviluppo di software libero, alla diffusione di protocolli informatici aperti, alla
promozione del cosiddetto pluralismo informatico. Tuttavia l'argomento della normazione (anche
detta standardizzazione) è spesso poco trattato o comunque non se ne conoscono nel dettaglio le
dinamiche e i meccanismi di funzionamento.
Dando per acquisito che cosa siano gli standard informatici e quale fondamentale ruolo giochino nel
mondo dello sviluppo tecnologico, nonché la distinzione concettuale fra standard de facto e standard
de jure (argomenti per i quali si rimanda il lettore ai due paper precedenti), in queste pagine
cercheremo di approfondire i meccanismi che stanno dietro l'attività di formalizzazione degli standard
de jure (anche detti norme), i soggetti impegnati in questa attività e le problematiche teoriche ad essa
legate.
Si inizierà fornendo una breve panoramica storica della normazione dalla fine del XIX secolo fino ai
giorni nostri, mostrando anche i due diversi approcci che nel corso degli anni si sono consolidati
negli Stati Uniti e in Europa.
Si passerà a introdurre i tre principi fondanti dell'attività normazione, che sono la consensualità
(ovvero la ricerca del massimo grado di consenso da parte dei soggetti coinvolti nel processo di
normazione), la democraticità e la trasparenza.
In secondo luogo si tratteranno le fasi del processo di standardizzazione, partendo dalla segnalazione
e valutazione della necessità dello standard, passando alla ricerca e consolidamento del consenso
sulle caratteristiche dello standard, per arrivare all'approvazione formale e pubblicazione del
documento di specifica in cui appunto sono descritte le caratteristiche tecniche dello standard.
A questo punto si giungerà ad un approfondimento sugli enti che si occupano di questa attività,
analizzandone la loro natura giuridica (non così chiara), il loro funzionamento interno nonché i
rapporti (spesso di forte sinergia e interdipendenza) fra le varie realtà attive nel campo. Si potrà così
spiegare che esistono fondamentalmente tre livelli di normazione (il livello nazionale, quello europeo
e quello internazionale) e cogliere quale importante ruolo viene oggi giocato da questi enti per la
determinazione degli equilibri di mercato.
Infine si cercherà di mettere in luce le principali problematiche che un'attività tanto complessa quanto
determinante può implicare. Innanzitutto si tratterà il rapporto fra l'attività di standardizzazione e
l'innovazione tecnologica; successivamente le questioni che essa pone in materia di proprietà
intellettuale e specialmente della difficile convivenza fra la divulgazione di uno standard e le classiche
tutele del diritto industriale (copyright, brevetto e segreto aziendale); in ultimo i punti di attrito tra la
predisposizione di uno standard (il quale per molto tempo condizionerà pesantemente il mercato) e le
regole a presidio della libera concorrenza.
Pagina 1
Parole Chiave: norma, normazione, standard, standard aperti, formati aperti, enti di
normazione, interoperabilità, proprietà intellettuale, brevetti, innovazione, concorrenza.
1 DINAMICA STORICA DELLA NORMAZIONE E IL
DIFFERENTE APPROCCIO DI EUROPA E USA
Come si può dedurre dai più recenti studi in materia di sociologia dell'innovazione, il
radicarsi di pratiche mirate alla formalizzazione di standard industriali è direttamente
proporzionale al grado di complessità e trasversalità di un determinato mercato, ma
soprattutto al livello di convergenza tecnologica verso cui quel settore si sta dirigendo.
Non è difficile intuire quindi che negli ultimi decenni si è assistito ad un esponenziale
ampliamento dell'attività di standardizzazione, con una sensibile crescita di organizzazioni
nate per iniziativa spontanea delle aziende attive in un determinato settore.
Ripercorrendo lo schema proposto da Granieri (nell’ottimo libro sui rapporti fra attività di
normazione e diritto industriale, scritto con Calderini e Giannaccari), possiamo quindi
individuare tre fasi evolutive della standardizzazione.
Una prima fase che si inaugura già alla fine del XIX secolo e arriva fino alla seconda metà
del secolo scorso (tra gli anni 60 e gli anni 80) nella quale la tendenza è quella di legittimare
forme di monopolio (i cosiddetti monopoli legali, creati per lo più per scelta politica)
specialmente nei settori dell'energia, della telefonia e delle telecomunicazioni in generale.
Una prospettiva che circoscriveva automaticamente la problematica degli standard ad una
dimensione pressoché nazionale. E' il periodo infatti in cui in gran parte degli stati
industrializzati (soprattutto europei) vengono costituiti dai governi enti espressamente
preposti a vigilare sull'uniformazione tecnica dei vari settori.
Abbiamo poi una seconda fase il cui elemento centrale è la liberalizzazione dei mercati
accompagnata da una vertiginosa crescita ed espansione delle tecnologie e delle
telecomunicazioni. Inizia qui a percepirsi l'importanza della standardizzazione non solo a
livello nazionale ma anche internazionale.
Infine, vi è una terza e più recente fase ispirata alla massimizzazione della convergenza
tecnologica, nella quale le industrie si trovano (volenti o nolenti) a dover far parte di un
meccanismo di mercato sempre più integrato e cumulativo. E' palese che in un simile
contesto la ricerca di standard chiari e universalmente condivisi non è più percepita come una
possibilità in più ma come una vera e propria esigenza.
In questa evoluzione (qui presentata in verità in maniera molto sintetica e schematizzata)
sono andati definendosi due modelli differenti relativi alle due aree di massimo sviluppo
industriale e più coinvolte dal fenomeno della standardizzazione. Da un lato abbiamo
l'approccio più tipicamente statunitense per il quale l'attività di standardizzazione deve essere
lasciata il più possibile al mercato, salvo però stabilire delle regole chiare a garanzia della
concorrenza: in questo contesto assumono infatti particolare importanza gli organismi creati
per iniziativa delle aziende interessate.
Pagina 2
Dall'altro abbiamo l'approccio più tipico dell’area europea, dove la presenza di diverse realtà
nazionali e di un'istituzione sovranazionale come la Comunità Europea (la cui precipua
attività sta proprio nella regolamentazione del mercato e degli equilibri concorrenziali fra gli
stati membri) ha portato ad una soluzione – per così dire – più pubblicistica: qui infatti
assumono un ruolo particolarmente centrale enti di natura governativa (come il CEN, il
CENELEC e l'ETSI) preposti proprio ad occuparsi di tali dinamiche. 1
2 L'ATTIVITÀ DI NORMAZIONE
Come si è già avuto modo di accennare in altre sedi 2, l'iter che porta alla formalizzazione di
uno standard (nel senso di standard de iure, ovviamente) è chiamato processo di
standardizzazione (o di normazione): esso si struttura in più fasi, si fonda sulla fissazione
delle caratteristiche convenzionali costitutive dello standard ed è gestito da appositi enti
specializzati la cui autorevolezza e credibilità sono ampiamente riconosciute.
A titolo di precisazione terminologica è il caso di evidenziare che quando in questo ambito si
parla di “norma” non si fa riferimento all’idea più comune di norma giuridica, ovvero quella
di precetto imposto da un’autorità per regolare i rapporti di un gruppo sociale e sostenuto
dall’imposizione di sanzioni giuridiche. Si tratta più che altro di “norma” intesa come “tipo”
o “modello” a cui determinati soggetti (gli operatori di un determinato mercato) devono
conformarsi per poter far parte del “gioco”, pena l’esclusione dal gioco stesso (o quantomeno
una difficile partecipazione).
In altre parole, da un lato abbiamo un gruppo sociale i cui individui sono tutti tenuti al
rispetto di una regola e la violazione della stessa comporta per gli individui l’applicazione di
una sanzione giuridica; dall’altro lato abbiamo un modello di riferimento definito con
dinamiche convenzionali ai quali i soggetti (gli operatori del mercato) sono liberi di aderire o
meno, tenendo però presente che la non adesione comporterà concrete difficoltà nella
partecipazione al mercato. 3
L'attività di normazione, come avremo modo di approfondire, è uno dei punti cardine
dell'innovazione tecnologica in senso lato in un mondo permeato di tecnologia come quello
attuale; e proprio per questo rappresenta un terreno molto delicato e complesso, che implica
problematiche di natura (oltre che tecnica) giuridica, economica, politica, etica: tutte di non
facile gestione.
2.1
Principi base dell’attività di normazione
L'attività di normazione si ispira ad alcuni principi di fondo, il cui rispetto attribuisce
affidabilità ed autorevolezza allo standard prodotto. Essi sono:
Per un approfondimento di questa dicotomia fra modello USA e modello Europea si legga Calderini M., Giannaccari M., Granieri A., Standard, proprietà intellettuale e logica antitrust nell'industria dell'informazione, Il Mulino, 2005 (pag. 82).
2
Aliprandi S., Gli standard nel settore informatico: classificazioni e problematiche, in Atti della II Conferenza Italiana Software Libero (Trento, maggio 2008); disponibile online al sito www.confsl.org.
3
Sarebbe interessante un approfondimento del tema alla luce delle categorie tipiche della filosofia del diritto e della teoria generale del diritto. A titolo di semplice spunto si legga quanto scrive Stefano Moroni che avvicina norme come gli standard tecnici alla definizione di “regola tecnotattica”. Si veda il par. 2.3.8. di Moroni S., Le regole
tecnonomiche,
documento
disponibile
online
al
sito www.giuri.unige.it/intro/dipist/digita/filo/testi/analisi_1998/Moroni1.rtf.
1
Pagina 3
•
la consensualità, ovvero la ricerca del massimo grado di consenso da parte dei
soggetti coinvolti nel processo di normazione. Essa si pone come elemento fondante della
credibilità del processo e della stabilità dello standard; 4
•
la democraticità, poiché un processo basato su meccanismi democratici permette che
«tutte le parti siano rappresentate nelle diverse fasi […] e che tutte concorrano in modo
paritetico all'approvazione consensuale del progetto»; 5
•
la trasparenza, dato che durante il processo di normazione è importante che tutti i
soggetti coinvolti abbiano «il diritto, ed il dovere, di conoscere le “regole del gioco”, ovvero i
regolamenti che disciplinano i lavori delle commissioni e dei gruppi di lavoro e le aree di
competenza, ma anche di avere pieno accesso alla documentazione che testimonia il processo
normativo in itinere». 6
Ovviamente, si tratta più che altro di principi ideali a cui l'attività di normazione “dovrebbe”
ispirarsi. Il condizionale è infatti d'obbligo, dato che (come abbiamo visto a proposito dei
formati di file7), non tutti gli enti di normazione vi fanno riferimento in maniera integrale e
costante.
2.2
Fasi di un processo di standardizzazione
Ogni ente di standardizzazione stabilisce proprie norme, adotta proprie procedure e segue
proprie prassi per la formalizzazione di uno standard. Tuttavia in quasi tutti i processi è
possibile ritrovare un paradigma comune su cui possiamo fondare la nostra analisi. Secondo il
modello proposto dall'ISO8, ogni processo si sviluppa in linea di massima secondo tre grandi
fasi:
•
segnalazione e valutazione della necessità dello standard; 9
•
ricerca e consolidamento del consenso sulle caratteristiche dello standard; 10
•
approvazione formale e pubblicazione del documento. 11
«Ciò che si persegue non è solo un accordo, una validità pubblica di tipo utilitaristico, ma la piena accettazione del risultato cui si è pervenuti da parte del gruppo impegnato nel lavoro normativo, rappresentativo della comunità nel suo complesso.» UNI (a cura di), Le regole del gioco, UNI, 2006 (pag. 22), disponibile online alla pagina www.uni.com/uni/controller/it/chi_siamo/regole_gioco.htm.
5
ibidem (pag. 26)
6
ibidem (pag. 26)
7
Aliprandi S., I formati documentali aperti, in Atti della III Conferenza Italiana Software Libero (Bologna, giugno 2009); disponibile online al sito www.confsl.org.
8
Si veda www.iso.org/iso/standards_development/ processes_and_procedures/how_are_standards_developed.htm.
9
«The need for a standard is usually expressed by an industry sector, which communicates this need to a national member body. The latter proposes the new work item to ISO as a whole. Once the need for an International Standard has been recognized and formally agreed, the first phase involves definition of the technical scope of the future standard. This phase is usually carried out in working groups which comprise technical experts from countries interested in the subject matter.» ibidem
10
«Once agreement has been reached on which technical aspects are to be covered in the standard, a second phase is entered during which countries negotiate the detailed specifications within the standard. This is the consensus
building phase.» ibidem
11
«The final phase comprises the formal approval of the resulting draft International Standard (the acceptance criteria stipulate approval by twothirds of the ISO members that have participated actively in the standards development process, and approval by 75% of all members that vote), following which the agreed text is published as an ISO International Standard.» ibidem
4
Pagina 4
Secondo altra fonte12, la realizzazione di una norma internazionale può essere invece
articolata come segue:
•
proposta della norma e valutazione della sua necessità;
•
preparazione di una bozza di norma;
•
ricerca del consenso sulla base della bozza;
•
inchiesta, ovvero una fase in cui il progetto di norma viene diffuso anche all'esterno
della cerchia dei soggetti coinvolti nel processo per raccogliere osservazioni, critiche,
obiezioni o consensi;
•
approvazione della norma nel suo testo definitivo da parte dell'ente di normazione;
•
pubblicazione della norma ufficiale;
•
eventuale fase di revisione della norma, dovuta a particolari richieste ed esigenze
emerse dopo la sua pubblicazione.13
Si può facilmente notare che questo secondo schema non fa altro che dettagliare
maggiormente quello precedente.
Nella maggior parte dei casi i lavori di redazione della bozza di norma tecnica vengono svolti
all'interno di commissioni tecniche e gruppi di lavoro formati da «esperti che rappresentano
le parti economiche e sociali interessate (produttori, fornitori, clienti, utilizzatori, distributori,
centri di ricerca, consumatori, pubblica amministrazione...)» 14. Dunque, l'organismo di
normazione svolge più che altro una funzione di coordinamento dei lavori e di messa a
disposizione della sua struttura organizzativa.
Infine, si tenga presente che sono sempre più frequenti i casi in cui gli enti di normazione
internazionale si trovano a far propria una norma già formalizzata da altri enti di normazione:
si parla in questo caso di una normazione di secondo grado. Ciò si verifica specialmente in
campi di applicazione molto complessi (quali sono appunto quelli del mondo ICT) per i quali
l'opera di standardizzazione richiede valutazioni tecniche lunghe e articolate e può essere
meglio gestita da enti di normazione specializzati; in questo modo l'ente di normazione
superiore potrà prendere in esame la norma ad uno stadio già avanzato per una semplice
rielaborazione e ratifica.
2.3
Pubblicazione e utilizzo degli standard
Il tema dell'utilizzo di strumenti informatici alternativi a quelli imposti dal mercato è per
vocazione un tema caro al settore pubblico, sia per ragioni di principio, sia per le ragioni di
concreta convenienza economica, sia per ragioni di opportunità tecnico-pratica. Una volta
formalizzati, gli standard si presentano sotto la forma di documenti testuali o ipertestuali
contenenti tutte le informazioni necessarie a ricalcarne e riprodurne il modello: cioè le
cosiddette specifiche dello standard. Dunque le aziende interessate a sviluppare un prodotto
conforme allo standard devono poter avervi accesso nel dettaglio.
UNI (a cura di), Le regole del gioco, UNI, 2006 (pag. 108).
Tra l'altro, nel caso di norme ISO, vi è una revisione periodica della norma che avviene almeno ogni cinque anni.
14
UNI (a cura di), Le regole del gioco, UNI, 2006 (pag. 25).
12
13
Pagina 5
Salvo rare eccezioni (come avremo modo di verificare), i principali enti di standardizzazione
considerano la documentazione da essi realizzata come materiale a tutti gli effetti coperto
dalle tutele di diritto industriale (copyright e segreto). Ciò comporta che normalmente gli enti
di standardizzazione non diffondono la loro documentazione liberamente (tranne in alcuni
particolari casi, che vedremo nei prossimi capitoli) e, per accedervi, gli operatori interessati
devono versare una royalty e acquisire i necessari permessi.
Si legga a titolo esemplificativo quanto emerge dal sito di UNI in materia di condizioni di
accesso e utilizzo ai propri standard:
«Il cliente riconosce che: i prodotti sono di proprietà di UNI in
quanto titolare del copyright - così come indicato all'interno dei
prodotti - e che tali diritti sono tutelati dalle leggi nazionali e dai
trattati internazionali sulla tutela del copyright; tutti i diritti, titoli e
interessi nei e sui prodotti sono e saranno di UNI, compresi i diritti
di proprietà intellettuale.»15
Da ciò deriva appunto che l'ente di standardizzazione, vantando tali diritti di privativa, può
regolamentare l'accesso e l'uso (e indirettamente anche l'implementazione) da parte dei
soggetti interessati.16
Tuttavia è importante chiarire che queste considerazioni attengono più che altro alla fase
dell’accesso alla documentazione relativa allo standard e non alla fase (logicamente
successiva) dell’implementazione dello standard stesso. Infatti, oltre alle tutele giuridiche per
l’accesso alla documentazione di cui si è accennato, possono sussistere dei diritti di proprietà
industriale (tendenzialmente dei brevetti) sulle soluzioni tecniche contenute e descritte nello
standard. Di conseguenza, chi ha legittimamente acquisito tale documentazione può trovarsi
comunque nell’impossibilità di adottare e implementare lo standard, se non dietro pagamento
di un’ulteriore royalty ai titolari dei brevetti in esso contenuti.17
Si tratta di una distinzione davvero fondamentale per comprendere le problematiche
giuridiche relative all’attività di normazione e di sviluppo tecnologico in generale. D’altro
canto, come mostreremo a breve, la gestione della proprietà intellettuale è non a caso uno
degli aspetti più delicati in fatto di standardizzazione.
Si tenga infine presente che gran parte degli introiti degli enti di normazione derivano – oltre
che dalle quote di iscrizione/partecipazione delle realtà ad essi associate o affiliate – proprio
dalla diffusione della documentazione relativa agli standard e dalla cessione in licenza dello
standard stesso per la sua implementazione da parte di soggetti (aziende e altri operatori del
settore) anche non coinvolti attivamente nel processo di standardizzazione.
http://webstore.uni.com/unistore/public/conditions.
A titolo di completezza è importante segnalare un interessante orientamento giurisprudenziale secondo cui alla documentazione prodotta dagli enti di normazione di matrice pubblica/governativa sia da applicare il disposto dell’articolo 5 della legge 633/1941, che esclude dalla tutela di diritto d’autore i testi degli atti ufficiali dello stato e delle pubbliche amministrazioni. Si legga a tal proposito la sentenza del caso Centro elettronico it. vs Soc. Hoepli ed., Corte appello Milano, 3 marzo 1995 (in Giust. civ. 1996, I, 203).
17
Come vedremo, alcuni autori stigmatizzano questo comportamento indicandolo come una minaccia a tutto il sistema della standardizzazione. Si veda a titolo di esempio la pregnante ricostruzione fatta da Carlo Piana a proposito del caso Rambus: www.piana.eu/rambus_ce.
15
16
Pagina 6
3 GLI ENTI DI NORMAZIONE E IL LORO FUNZIONAMENTO
Gli enti di normazione (anche detti in Inglese “standard setting organizations”) sono
«organizzazioni spontanee di natura privata, finalizzate alla definizione di standard tecnici
che permettono di ottenere la compatibilità tra prodotti o servizi realizzati da diverse
imprese.»18
Tali enti svolgono attualmente un ruolo davvero centrale per lo sviluppo industriale e
tecnologico, con ripercussioni sostanziali a livello macroeconomico e politico; dunque è
importante comprenderne i meccanismi di funzionamento.
3.1
Natura giuridica e funzionamento
Come già accennato ci si sta dirigendo sempre di più verso enti di normazione di natura
spontanea, creati per iniziativa delle stesse aziende interessate alla fissazione di un
determinato standard.
Dal punto di vista della natura giuridica, il diritto italiano tende a ricondurre tali enti (con le
dovute specificazioni) generalmente al modello consortile.
Per il diritto privato (si veda l'art. 2602 Cod. Civ.) si ha un consorzio quando più
imprenditori, per mezzo di apposito contratto, costituiscono «un'organizzazione comune per
la disciplina o per lo svolgimento di determinate fasi delle rispettive imprese.»
In verità, a seconda dei contesti giuridici di riferimento e dell'evoluzione storica dei vari enti,
gli enti di standardizzazione hanno denominazioni differenti: consorzio, comitato, istituto,
associazione o, con tono ancora più asettico, ente.
Tuttavia, al di là della loro precisa qualificazione giuridica (non così essenziale ai fini
pratici), possiamo con certezza inquadrare tali realtà associative (e quindi anche i loro
meccanismi di funzionamento) nell'humus del diritto privato contrattuale e del diritto
commerciale.
Come tutti gli enti di tipo associativo anche gli enti di normazione fondano il loro
funzionamento sulle disposizioni contenute nei propri statuti. Fra queste disposizioni
assumono particolare rilevanza quelle relative alle condizioni di ingresso, ai meccanismi di
voto, all'organizzazione interna, alle sanzioni per eventuali violazioni dello statuto o dei
regolamenti emessi dall'ente. Sarà proprio l'analisi degli statuti dei vari enti che ci permetterà
di valutare il loro approccio all'attività di normazione e l'autorevolezza (e l'apertura) degli
standard da essi prodotti.
3.2
I tre livelli della normazione: nazionale, europeo, internazionale
La normazione si divide tradizionalmente in tre livelli relativi all'ambito di applicazione dello
standard e all'area di competenza dell'ente che se ne occupa.
Calderini M., Giannaccari M., Granieri A., Standard, proprietà intellettuale e logica antitrust nell'industria dell'informazione, Il Mulino, 2005 (pag. 28).
18
Pagina 7
a) livello nazionale
Quasi tutti i paesi del mondo industrializzato possiedono uno o più enti nazionali di
standardizzazione19, che si occupano di rilasciare standard concepiti per il contesto nazionale
e non necessariamente in un'ottica internazionale. In ambito europeo si può affermare che
ogni paese dell'Unione registra la presenza di almeno un ente interno di standardizzazione.
Soffermandoci sul caso italiano, nel nostro paese le due principali realtà dedicate a questa
funzione sono l'Ente Nazionale Italiano di Unificazione (comunemente abbreviato in UNI) e
il Comitato Elettrotecnico Italiano (comunemente abbreviato in CEI).
L'UNI, come si estrapola dal sito istituzionale (www.uni.com), «è un'associazione privata
senza scopo di lucro, i cui soci, oltre 7000, sono imprese, liberi professionisti, associazioni,
istituti scientifici e scolastici, realtà della Pubblica Amministrazione.» 20 Mentre i suoi campi
di attività possono essere suddivisi in tre aree: elaborare norme che vengono sviluppate da
organi tecnici ai cui lavori partecipano tutte le parti interessate (assicurando così trasparenza
e condivisione nel processo); rappresentare l'Italia nelle attività di standardizzazione a livello
mondiale ed europeo; pubblicare e diffondere le norme tecniche ed i prodotti editoriali ad
esse correlati, sia direttamente, sia attraverso appositi centri di informazione e
documentazione, sia tramite Internet.
L'UNI svolge un ruolo centrale per il settore industriale italiano, sia per l'attività interna, sia
per la gestione dei rapporti con i principali enti internazionali di standardizzazione: essa
infatti partecipa, in rappresentanza dell'Italia, all'attività normativa di organismi come ISO e
CEN. Infine, si tenga presente che fra i suoi soci sono presenti altri enti di standardizzazione
che possono essere considerati a tutti gli effetti come federati di UNI e che operano ciascuno
in uno specifico settore industriale o merceologico: ai fini della nostra analisi, si segnala
principalmente UNINFO che appunto si occupa di tecnologie informatiche e loro
applicazioni.21
L'UNI, con l'ausilio degli enti federati, opera in tutti i settori industriali, commerciali e del
terziario ad esclusione di quello elettrico ed elettrotecnico che sono invece competenza del
CEI. Come emerge dal sito ufficiale www.ceiweb.it le finalità istituzionali di questo ente
sono la promozione e la diffusione della cultura tecnica e della sicurezza elettrica. A tale
scopo «il CEI sviluppa una serie di attività normative e prenormative a livello nazionale ed
internazionale che includono, oltre alla redazione dei documenti normativi e al recepimento
delle direttive comunitarie e dei documenti armonizzati, azioni di coordinamento, ricerca,
sviluppo, comunicazione e formazione in sinergia con le parti coinvolte nel processo
normativo.»22
Ai lavori di ricerca e normazione del CEI partecipano oltre 3.000 esperti attivi in prima linea
nel settore e provenienti da ministeri, enti pubblici e privati, università, laboratori di ricerca,
industrie costruttrici e utilizzatrici, associazioni di categoria.
Un elenco abbastanza completo dei principali enti nazionali di standardizzazione è disponibile alla pagina web www.aib.it/aib/lis/s.htm.
20
www.uni.com/uni/controller/it/chi_siamo/ruolo_uni.htm.
21
Maggiori informazioni alla pagina web www.uninfo.polito.it/present.htm del sito ufficiale di UNINFO, dove si legge: «Rientrano nel suo campo di attività i sistemi di elaborazione e di trasmissione delle informazioni e le loro applicazioni nelle più diverse aree, quali, ad esempio, le attività bancarie, le carte intelligenti, la telematica del traffico, l'automazione industriale. In questo ambito l'UNINFO, ente federato all'UNI, opera con delega UNI, a livello nazionale ed internazionale e rappresenta l'Italia presso l'ISO, l'ISO/IEC JTC 1 e il CEN».
22
www.ceiweb.it/Frame02.htm?Settore=Chi&Finestra=presenta.html.
19
Pagina 8
b) livello europeo
A livello europeo è il caso di citare il Comitato europeo di normazione (abbreviato
comunemente in CEN e noto anche come “European Committee for Standardization”) 23, il
quale si occupa di coordinare e monitorare le attività di standardizzazione in ambito europeo
e lavora in accordo con le politiche dell'Unione Europea stessa e dell'EFTA. 24 L'attività del
CEN, unita e integrata con quella di altri due enti di pari rilevanza ma con diverse
competenze, costituisce quello che è chiamato “Sistema europeo per la normalizzazione
tecnica”: questi due enti sono l'Istituto europeo per gli standard nelle telecomunicazioni
(abbreviato comunemente in ETSI dal nome inglese European Telecommunications Standard
Institute)25 e il Comitato Europeo di Normazione Elettrotecnica (abbreviato comunemente in
CENELEC dal nome francese Comité Européen de Normalisation Electrotechnique). 26
Altro importante ente a livello europeo, di cui avremo modo di narrare le vicende nei
prossimi capitoli, è la ECMA International (dove l'acronimo sta per European Computer
Manufacturers Association), un’associazione fondata nel 1961 e impegnata nella
standardizzazione nel settore informatico e dei sistemi di comunicazione. 27
c) livello internazionale
Al di là dei confini europei sono invece attive alcune grandi organizzazioni competenti a
rilasciare standard riconosciuti a livello globale e definiti appunto standard internazionali.
Come già accennato, la realtà principale in assoluto è l'Organizzazione internazionale per le
standardizzazioni (comunemente abbreviata in ISO) 28, la quale collega e coordina l'attività
degli enti nazionali di standardizzazione di ben 157 paesi, fra cui appunto l'UNI per l'Italia.
L'ISO ricopre un ruolo centrale nell'economia e nella politica economica mondiali (come
traspare dal motto presente sul sito ufficiale “International Standards for Business,
Government and Society”); e benché essa si autodefinisca un'organizzazione non
governativa, «la sua capacità di stabilire standard che diventano leggi attraverso accordi e
trattati la rende molto più potente di molte ONG e in pratica agisce come consorzio con forti
legami con i governi.»29
Gli standard ISO hanno la caratteristica di essere contrassegnati da una sigla che li rende
identificabili a livello internazionale; ogni sigla è composta dal prefisso ISO, da un numero e
dall'anno di pubblicazione dello standard, cioè un paradigma come questo: “ISO 9999:aaaa”.
Spesso tale sigla è seguita da un titolo, cioè una breve descrizione dello standard. Un esempio
piuttosto conosciuto è quello dello standard “ISO 9001:2008 - Gestione della qualità” 30;
Il sito istituzionale del CEN è www.cen.eu.
European Free Trade Association (Associazione europea di libero scambio), ente fondato nel 1960 come alternativa per gli stati europei che non volevano entrare nella Comunità Economica Europea, ora Unione Europea. Il suo sito ufficiale è www.efta.int.
25
Ente con sede a Sophia Antipolis (Francia), fondato nel 1988 dalla Conferenza Europea per le Poste e Telecomunicazioni (CEPT); il suo sito istituzionale è www.etsi.org.
26
Ente con sede a Bruxelles (Belgio), fondato nel 1973 e responsabile della normalizzazione europea nell’area dell’ingegneria elettrica; il suo sito istituzionale è www.cenelec.org.
27
Il suo sito istituzionale è www.ecmainternational.org.
28
In verità, il termine ISO non è un vero e proprio acronimo, nonostante in inglese l'ISO venga chiamata International Standards Organization. Il termine ISO deriva invece dal greco isos che significa “uguale”, quindi uniforme, standard.
29
http://it.wikipedia.org/wiki/ISO.
30
Cioè il famoso codice IBAN (International Bank Account Number) che ci viene richiesto per le operazioni bancarie. Maggiori informazioni alla pagina web http://it.wikipedia.org/wiki/ISO_13616.
23
24
Pagina 9
oppure quello dello standard “ISO 13616:2007 - Codici bancari di conto corrente”; oppure
ancora quello dello standard “ISO 2108:1970 - Standard internazionale di numerazione dei
libri”.31
L'ISO, in materia di standard per elettricità, elettronica e tecnologie correlate, è affiancata
dalla Commissione Elettrotecnica Internazionale (abbreviata comunemente in IEC dal suo
nome inglese International Electrotechnical Commission) 32, ente di antica fondazione (1906)
a cui fanno capo circa sessanta paesi e che ricopre anche un ruolo fondamentale
nell'armonizzazione delle unità di misura.
In un altro settore parallelo alle aree di competenza di ISO ed IEC opera l'Unione
Internazionale delle Telecomunicazioni (abbreviata comunemente in ITU dall'inglese
International Telecommunication Union) 33, la cui sezione standardizzazioni è denominata
ITU-T. L'ITU fu fondata già nel 1865 e dal 1947 è una delle agenzie specializzate delle
Nazioni Unite; la prima sede è stata a Parigi, mentre l'attuale sede è a Ginevra.
I suoi standard rappresentano la base di riferimento delle attuali tecnologie di comunicazione
e informazione. «Sviluppate da gruppi di studio costituiti da esperti sia del settore pubblico
che privato, le raccomandazioni I.T.U. aiutano a gestire il traffico globale delle informazioni
permettendo un armonico sviluppo sociale ed economico in tutto il mondo.» 34
4 PRINCIPALI PROBLEMATICHE IN MATERIA DI
STANDARDIZZAZIONE
Cercheremo in questi prossimi paragrafi di mettere a fuoco le principali problematiche che la
letteratura scientifica (principalmente di taglio giuridico-economico) ha sollevato in materia
di standardizzazione. Si tratta, più che di argomentazioni complete, di inquadramenti generali
e di spunti di riflessione, rimandando ad altre fonti più specialistiche il loro approfondimento.
4.1
Standard e innovazione tecnologica
Dalle considerazioni fin qui effettuate pare emergere una generale virtuosità e auspicabilità
della standardizzazione. Potremmo quindi arrivare presto ad affermare che avere degli
standard di riferimento predefiniti sia sempre e a priori un beneficio per lo sviluppo di
tecnologia. In realtà gli osservatori più attenti fanno notare che la questione è più complessa.
Nel momento in cui fissiamo uno standard, quand’anche ciò avvenga con i procedimenti più
concertati e trasparenti possibili, stiamo cercando di cristallizzare un determinato modello di
riferimento a cui per un certo periodo dovrà conformarsi lo sviluppo di quella specifica
tecnologia. Ma d'altro canto sappiamo che lo sviluppo tecnologico è oggetto di una continua
quanto veloce evoluzione e perciò quel tentativo di cristallizzazione sarebbe comunque
travolto dalla corrente di questo fiume in piena. In altre parole, sarebbe solo una fotografia
dello stato dell’arte e della tecnica al momento della fissazione dello standard, e poco più.
Ovvero l'International Standard Book Number, il codice identificativo che ogni libro in commercio dovrebbe possedere per essere individuato su scala internazionale e dal quale si trae il codice a barre presente sul retro
copertina dei libri.
32
Il sito istituzionale dell'IEC è www.iec.ch.
33
Il sito istituzionale dell'ITU è www.itu.int.
34
http://it.wikipedia.org/wiki/International_Telecommunication_Union.
31
Pagina 10
L’attività di standardizzazione deve quindi tener conto di queste dinamiche e porsi in
un’ottica fluida e prospettica, altrimenti rischia di trasformarsi in un freno all’innovazione
invece che fungere da incentivo. I soggetti coinvolti nel processo di standardizzazione
devono compiere valutazioni rivolte al medio-lungo periodo in modo che lo standard possa
essere realmente la base, il punto di partenza per una serie di soluzioni tecnologiche
innovative basate su di esso.
È per questo che nella maggior parte dei casi si giunge a considerare un modello tecnologico
come uno standard quando si tratta di una tecnologia sufficientemente matura e conosciuta.
Mario Calderini ci pone di fronte al fatto cruciale che nell'attività di standardizzazione è
implicita la coesistenza fra due forze opposte che devono essere tenute il più possibile in
equilibrio, se si vuole procedere realmente nella direzione di una maggiore neutralità e
innovazione tecnologica:
«Da un lato, il classico problema legato alle attività di
standardizzazione: assicurare che i processi di convergenza sugli
standard giungano a compimento con esiti efficienti (la selezione
della tecnologia migliore) nel minor tempo possibile. Dall'altro,
[…] garantire una virtuosa coesistenza delle necessità di apertura e
interoperabilità delle piattaforme con l'esigenza di definire un
contesto competitivo fertile all'attività innovativa». 35
Come corollario di questo rischio, ve n'è un altro: un sistema di standardizzazione non ben
congegnato può infatti portare a situazioni di stallo e irrigidimento del mercato, per le quali il
superamento di uno standard ormai obsoleto a favore di uno più moderno può essere frenato
da ragioni squisitamente strategiche. D'altronde, quando uno standard è ben radicato, nel
senso che è ampiamente adottato dalle aziende e altrettanto ampiamente ricercato dai
consumatori, si crea una naturale inerzia che rende particolarmente difficile sostituirlo con
uno nuovo anche se tecnologicamente superiore e innovativo.
Toccando uno dei temi chiave di questo libro, Andrea Giannaccari sottolinea con estrema
efficacia che «le positive esternalità di rete possono risolversi in elevate barriere all'entrata –
sapientemente modellate da strategie di lock-in – con il rischio (tutt'altro che remoto) che la
pratica conduca ad una chiusura oligopolistica e che ciò metta fuori gioco o ritardi l'ingresso
di tecnologie superiori». 36
4.2
Attività di normazione e gestione della proprietà intellettuale
La crescente necessità di standardizzazione che si rileva in un settore ICT come quello attuale
portato sempre più verso la ricerca di convergenza e integrazione tecnologica, rimette in
discussione pesantemente alcuni dei paradigmi classici della proprietà intellettuale.
Ciò dipende dal fatto che (come fa notare attentamente Massimiliano Granieri) l'attività di
standardizzazione si nutre di «un'apparente contraddizione» 37 per la quale partecipare alla
Calderini M., Giannaccari M., Granieri A., Standard, proprietà intellettuale e logica antitrust nell'industria dell'informazione, Il Mulino, 2005 (pag. 17). 36
ibidem (pag. 91).
37
Così si esprime Granieri all'inizio del primo capitolo del libro: «La disciplina delle privative in rapporto alle tecnologie soggette a processi di standardizzazione rappresenta una delle ultime frontiere del diritto industriale. Si tratta di un aspetto che, a ben vedere, si alimenta di un'apparente contraddizione, poiché il regime proprietario 35
Pagina 11
definizione di uno standard implica necessariamente per le imprese coinvolte “giocare a carte
scoperte”, nel senso di condividere con gli altri soggetti coinvolti nel processo il proprio
know-how relativo alla tecnologia che si sta esaminando in vista della sua normazione.
Ovviamente nel concetto di know-how in senso più ampio, oltre ai vari segreti aziendali che
caratterizzano qualsiasi attività di progettazione e sviluppo tecnologico, si contemplano anche
(anzi soprattutto) diritti di privativa industriale come i brevetti e i diritti d'autore.
Questo “scoprire le carte” viene chiamato tecnicamente “IPRs disclosure” (dove IPRs sta per
Intellectual Property Rights) e rappresenta davvero uno dei punti chiave nell'attività di
normazione. È infatti fondamentale che i detentori di diritti di privativa industriale si pongano
il più possibile in un'ottica collaborativa e di massima trasparenza, dichiarando fin da subito
la titolarità di diritti sulle soluzioni tecniche oggetto della standardizzazione e impegnandosi a
non fare usi strategici di questi strumenti di tutela giuridica. Si pensi infatti al caso (non così
raro, tra l'altro) in cui una delle aziende coinvolte nel processo di normazione tenesse
nascosta agli altri soggetti coinvolti la titolarità di un brevetto su una parte delle tecnologia
oggetto dello standard; e rivelasse solo a standard formalizzato e pubblicato la sussistenza di
questi suoi diritti esclusivi, richiedendo royalty o addirittura minacciando azioni legali nei
confronti degli altri soggetti. Sarebbe un comportamento piuttosto scorretto dal punto di vista
etico e concorrenziale, ma soprattutto pericoloso per tutto il sistema della normazione, che
rischierebbe di andare in stallo troppo facilmente e di vedere elusa la sua finalità essenziale di
creare una piattaforma virtuosa per l'innovazione e l'interoperabilità.
È per questo che i più autorevoli enti di normazione prevedono policy trasparenti e coerenti in
materia di proprietà intellettuale.38
Inoltre si consideri che spesso lo standard, dopo esser stato formalizzato, potrà contenere a
sua volta soluzioni tecniche protette da diritti di privativa ed è fondamentale scongiurare il
rischio che l'adozione dello standard “a valle” da parte di operatori estranei al processo di
standardizzazione si trasformi in una specie di “trappola” 39, con pesanti conseguenze dal
punto di vista legale.40
Questo uso strumentale della proprietà intellettuale è secondo alcuni autori di primaria
importanza per il funzionamento degli standard e secondo alcuni autori rischia, se non
monitorato debitamente, di trasformarsi in una sorta di “patologia” capace di svilire l’intero
sistema della normazione.41
connesso con la disciplina della proprietà intellettuale si confronta con il carattere tendenzialmente “aperto” degli standard come tecnologie la cui condivisione rappresenta una condizione di accesso al mercato». ibidem (pag. 17).
38
«Il fatto che diverse tecnologie tutelate da diritti di proprietà intellettuale vengano inserite in uno standard può rendere più agevole il processo innovativo, ma può dar luogo a condotte strategiche da parte di chi detiene le privative. […] Il modo con cui le standard setting organizations fronteggiano gli aspetti legati alla gestione dei diritti di proprietà intellettuale risulta di vitale importanza.» ibidem (pag. 100).
39
Alcuni parlano non a caso di “patent ambushes”. Per approfondire questo argomento si legga Hueschelrath, Patent Ambushes in Standars Setting Organizations. Implications for Antitrust Policy and the Design of IP Rules, AEA, 2008 (www.aeaeu.net/2008Tokyo/DOCUMENTS/Publication/Abstract/HUSCHELRATH.pdf); oppure Farrell, Hayes, Shapiro, Sullivan, Standard Setting, Patents, and HoldUp, 74 Antitrust Law Journal No. 3 (2007); o più semplicemente http://en.wikipedia.org/wiki/Patent_ambush.
40
«È evidente che la scoperta dell'esistenza di un brevetto molto tardi nelle fasi di sviluppo del prodotto o dell'applicazione pone lo sviluppatore dell'innovazione a valle in una condizione di estrema debolezza contrattuale». Calderini M., Giannaccari M., Granieri A., Standard, proprietà intellettuale e logica antitrust nell'industria dell'informazione, Il Mulino, 2005 (pag. 25).
Pagina 12
4.3
Attività di normazione e concorrenza
Anche senza essere esperti di diritto antitrust non è difficile intuire come organizzazioni in
cui le aziende si accordano sugli sviluppi nel mercato scambiandosi informazioni e stabilendo
espressamente tempi, modi e prezzi, vengano osservate con particolare attenzione dalle
autorità preposte a garantire la concorrenza del mercato. Qualcuno ha detto
emblematicamente che gli enti di standardizzazione possono generare «cortocircuiti alle
dinamiche concorrenziali»42 proprio per questa loro caratteristica.
In ambito europeo la norma che per antonomasia viene chiamata in causa è l'art. 81 del
Trattato CE espressamente dedicato agli accordi fra imprese (detti anche “cartelli”).
Il primo e il secondo paragrafo sembrano abbastanza perentori nell'applicazione del divieto e
gran parte delle fattispecie citate sembrano proprio coinvolgere anche gli enti di normazione.
«1. Sono incompatibili con il mercato comune e vietati tutti gli
accordi tra imprese, tutte le decisioni di associazioni di imprese e
tutte le pratiche concordate che possano pregiudicare il commercio
tra Stati membri e che abbiano per oggetto e per effetto di impedire,
restringere o falsare il gioco della concorrenza all'interno del
mercato comune ed in particolare quelli consistenti nel:
a) fissare direttamente o indirettamente i prezzi d'acquisto o di
vendita ovvero altre condizioni di transazione;
b) limitare o controllare la produzione, gli sbocchi, lo sviluppo
tecnico o gli investimenti;
c) ripartire i mercati o le fonti di approvvigionamento;
d) applicare, nei rapporti commerciali con gli altri contraenti,
condizioni dissimili per prestazioni equivalenti [...].
2. Gli accordi o decisioni, vietati in virtù del presente articolo, sono
nulli di pieno diritto.»
A stemperare tale divieto vi è però il paragrafo terzo che pare esser stato scritto proprio per
salvaguardare l'esistenza di pratiche virtuose di accordo fra imprese, quali appunto
dovrebbero essere quelle relative alla normazione.
Si legga la stigmatizzazione effettuata da Piana a proposito del caso Rambus: «Ghosts haunt the standardization process. They go by several names and come in different forms: “standards abuse”, “standards hijacking”, “patent ambush”, “royalty ambush”, “patent trolling”. The standardization world has never been so much under fire. Some companies try to bend the standardization process to fit their own selfish interest, without any regard for the common weal. Some others just sit and wait until some of their patent claims are “necessarily infringed” by a standard, the industry is locked in, and then pass the hat to collect the high toll that standardabiding companies are forced to pay, in spite of the licensing rules of the standard setting bodies (SSB) that would require Reasonable And Non Discriminatory conditions (RAND) as a prerequisite for inclusion of any patented contribution into the standard. Others do the same, but in addition they actively seek to seed the standards with their own patented technology.» Piana C., Rambus and patents in standards, 2009; disponibile online al sito www.piana.eu/rambus_ce.
42
Giannaccari M. e Granieri A., Standardization, Intellectual Property Rights and the Evolution of the Information Industry in Europe (2003), disponibile on line alla pagina www.fondazionerosselli.it/DocumentFolder/Key_Wireless.doc.
41
Pagina 13
«3. Tuttavia, le disposizioni del paragrafo 1 possono essere
dichiarate inapplicabili:
a qualsiasi accordo o categoria di accordi fra imprese,
a qualsiasi decisione o categoria di decisioni di associazioni di
imprese,
a qualsiasi pratica concordata o categoria di pratiche concordate,
che contribuiscano a migliorare la produzione o la distribuzione dei
prodotti o a promuovere il progresso tecnico o economico [...].»
Ciò significa che la Comunità Europea può di volta in volta considerare leciti accordi fra
imprese che siano ritenuti non pericolosi per l'equilibrio concorrenziale ed esentare i singoli
casi dall'applicazione del divieto di cui al paragrafo primo dell'art. 81.
Non a caso infatti la Commissione Europea si preoccupa di fornire regolarmente indicazioni
su come applicare le condizioni previste dall'art. 81, in modo da «aiutare le imprese a
distinguere tra gli accordi compatibili con le regole della concorrenza e quelli che non lo
sono. Un esempio sono le linee direttrici per la valutazione degli accordi orizzontali
(principalmente tra concorrenti) e degli accordi verticali (come gli accordi di distribuzione)».
Inoltre, al di là di questo inquadramento generale nel campo di applicazione dell'art. 81,
sussistono problematiche specifiche e sicuramente più complesse, come principalmente
quelle che implicano trasversalmente i principi del diritto antitrust e il già citato uso
strategico dei diritti di privativa industriale nella gestione dell'attività di standardizzazione (si
pensi ad esempio a quello che tecnicamente viene definito “patent pooling” 43).
Ancora una volta è Granieri a mettere ottimamente a fuoco la questione e a ricordarci che
sussistono significativi profili di contatto e contrasto fra l'attività di standardizzazione, il
diritto della proprietà industriale e le norme collocate a presidio della concorrenza, «in quanto
il diritto sulla tecnologia non significa soltanto possibilità di attuare l'invenzione e
commercializzarla […], bensì controllo sulle possibilità di concorrenza nel mercato della
tecnologia e in quello a valle dei prodotti che della tecnologia stessa fanno uso.» 44
Inoltre, si tenga presente che, sempre in virtù della già citata differenza fra il modello USA e
il modello europeo, la questione dell'attrito fra standardizzazione e diritto della concorrenza
viene trattata con approcci giuridico-economici piuttosto differenti. Questo tuttavia è un
risvolto particolarmente complesso, per cui si rimanda alla lettura di fonti specialistiche per
un suo approfondimento.
«Il Patent Pool è un consorzio di almeno due compagnie e che si accordano per scambiarsi licenze brevettuali, relative ad una particolare tecnologia.» http://it.wikipedia.org/wiki/Patent_pool. Per approfondire l'argomento si legga l'interessante libro di Colangelo G., Mercato e cooperazione tecnologica. I contratti di patent pooling, Giuffrè, 2008.
44
Calderini M., Giannaccari M., Granieri A., Standard, proprietà intellettuale e logica antitrust nell'industria dell'informazione, Il Mulino, 2005 (pag. 33).
43
Pagina 14
Bibliografia
Aa.Vv. (2008), Finalmente libero! Software libero e standard aperti per le pubbliche
amministrazioni, McGrawHill.
Aliprandi, S. (2008), Gli standard nel settore informatico: classificazioni e problematiche, in
Atti della II Conferenza Italiana Software Libero (Trento, maggio 2008); disponibili
online al sito www.confsl.org.
Aliprandi, S. (2009), I formati documentali aperti, in Atti della III Conferenza Italiana
Software Libero (Bologna, giugno 2009); disponibili online al sito www.confsl.org.
Calderini M., Giannaccari M., Granieri A. (2005), Standard, proprietà intellettuale e logica
antitrust nell'industria dell'informazione, Il Mulino.
Giannaccari M. e Granieri A. (2003), Standardization, Intellectual Property Rights and the
Evolution of the Information Industry in Europe; disponibile on line alla pagina
www.fondazionerosselli.it/DocumentFolder/Key_Wireless.doc
ISO/IEC (a cura di) (2004), Rules for the structure and drafting of International Standards
(ISO/IEC directives - part 2); disponibile on line al sito www.iec.ch/tiss/iec/DirectivesPart2-Ed5.pdf.
Moroni S. (1998), Le regole tecnonomiche, documento disponibile online al sito
www.giuri.unige.it/intro/dipist/digita/filo/testi/analisi_1998/Moroni1.rtf
Piana C. (2009), Rambus and patents in standards; disponibile online al sito
www.piana.eu/rambus_ce.
UNI (a cura di) (2006), Le regole del gioco, UNI; disponibile on-line alla pagina
www.uni.com/uni/controller/it/chi_siamo/regole_gioco.htm.
*************************************************************
Disclaimer sul regime dei diritti
Tutti i diritti sul presente articolo appartengono a Simone Aliprandi (www.aliprandi.org). L'opera
è rilasciata nei termini della licenza Creative Commons Attribuzione - Condividi allo stesso modo
Italia
2.5,
il
cui
testo
completo
è
accessibile
dall'indirizzo
web
http://creativecommons.org/licenses/by-sa/2.5/it/.
*************************************************************
Pagina 15
LE LICENZE PUBBLICHE DI RIUSO E IL SOFTWARE
LIBERO
Alma Roberto, Studio Legale DeTullio&Partners
De Tullio Michele Elio, Studio Legale DeTullio&Partners
Bodenham Paul, Studio Legale DeTullio&Partners
Abstract Il riuso del software consiste nella possibilità per le amministrazioni pubbliche di riutilizzare ed
eventualmente modificare un prodotto software o parti di esso realizzato da o per conto di un’altra
amministrazione pubblica. Riutilizzare un programma significa massimizzare il ritorno degli
investimenti sostenuti da un'amministrazione nella realizzazione di un determinato prodotto software.
Il legislatore, soprattutto alla luce delle recenti innovazioni normative contenute nel Codice
dell'Amministrazione Digitale (artt. 68 e 69), ha manifestato una chiara volontà di sostenere e
incentivare i progetti di riuso condotti dalle varie pubbliche amministrazioni.
Lo scopo del presente articolo è quello di analizzare, in particolare, le cd. Licenze Pubbliche di Riuso,
ovvero quei contratti di licenza destinati a disciplinare i diritti e gli obblighi reciproci delle
amministrazioni coinvolte in progetti di riuso. Tali licenze consentono di bilanciare l'interesse delle
amministrazioni che ricevono i programmi all'utilizzazione e alla modifica degli stessi con l'interesse
delle amministrazioni che cedono i programmi stessi alla protezione dei propri investimenti. Tale
bilanciamento viene attuato con una serie di previsioni e, soprattutto, con il divieto per le
amministrazioni riceventi di distribuire versioni “degradate” del programma, ovvero versioni lato
sensu peggiorative del programma originario.
L'avvio di progetti di riuso e la diffusione delle Licenze Pubbliche di Riuso pongono, tuttavia, alcuni
non trasurabili conflitti con il mondo del software libero. L'avvio di un progetto di riuso attualmente
presuppone che l'amministrazione goda della proprietà esclusiva sul programma. Ciò comporta,
inevitabilmente, l'esclusione del sofware libero da qualsivoglia progetto di riuso. Nell'articolo, invece,
si evidenzia che il software libero, alla luce delle ampie facoltà di utilizzo, modifica e redistribuzione
che attribuisce agli utenti (e quindi anche alla P.A) dovrebbe essere al centro di ogni progetto di
riuso. Pertanto, nell'assenza di preclusioni normative di sorta, non si vede la ragione per cui nei
bandi pubblici per il riuso si continui a richiedere la piena proprietà del software.
Al fine di incentivare l'utilizzo di software libero nei progetti di riuso, dovrebbe, però, valutarsi
l'opportunità di modificare le licenze libere e open source attualmente esistenti al fine di consentire la
successiva redistribuzione del programma (con le ulteriori modifiche) da parte di un'amministrazione
pubblica con la licenza di riuso. Tale licenza, infatti, contiene una serie di clausole che, da un lato,
consentono di rendere realmente efficiente il perseguimento di una strategia di riuso da parte della
P.A ma che, dall'altro, presentano dubbi profili di compatibilità con molte delle licenze libere e open
source più diffuse, le quali, infatti, richiedono che il programma sia successivamente redistribuito
negli stessi esatti termini della licenza originaria.
Solo attraverso una maggiore sensibilizzazione di tutti i soggetti coinvolti si potranno verificare le
condizioni necessarie per consentire l'avvio di progetti di riuso di software libero nella P.A. Ciò
potrebbe consentire sia una migliore allocazione delle risorse pubbliche sia una più capillare
Pagina 16
presenza del software libero all'interno amministrazioni pubbliche, rimuovendo, quindi, alcuni dei
tradizionali ostacoli che, fino ad oggi, ne hanno frenato la diffusione.
Parole Chiave: Riuso, Toscana, EUPL, amministrazione, software, licenza.
1 INTRODUZIONE
Il riuso del software è, ormai, un aspetto imprescindibile di qualsiasi efficace politica di egovernment. Nelle linee guida per il riuso delle applicazioni informatiche nelle
amministrazioni pubbliche il CNIPA ha definito il riuso come la possibilità di riutilizzare un
prodotto software e/o sue componenti realizzate da o per conto di un’amministrazione
pubblica nell’ambito di uno o più sistemi informativi di altre amministrazioni pubbliche 45.
Com’è stato autorevolmente chiarito – sotto il profilo operativo – il riuso del software può
essere inteso sia come il riutilizzo senza modifiche di prodotti già esistenti, sia come sviluppo
di nuovi prodotti per l’evoluzione e l’integrazione di componenti già realizzati 46.
In ogni caso – prescindendosi dalle specifiche modalità attuative del riuso 47 – qualsiasi
fattispecie presuppone l’esistenza di almeno due soggetti: un’amministrazione cedente e
un’amministrazione ricevente.
Il documento è reperibile sul sito del CNIPA http://www.cnipa.gov.
Cfr. FLICK C., CIGNONI G. A., AMBRIOLA V., Il riuso del software nella Pubblica Amministrazione, in Dir. Internet, 2008, p. 85. Gli autori evidenziano che, in entrambi i casi, il riuso è finalizzato a moltiplicare il ritorno degli investimenti dedicati allo sviluppo software. Esso costituisce una soluzione strategica per impiegare al meglio le risorse disponibili, dal momento che evita alla singola amministrazione di replicare la realizzazione di un prodotto già disponibile presso un’altra amministrazione, facendo, invece, convergere tali risorse su obiettivi di sviluppo ed evoluzione di nuovi prodotti, che possono essere condivisi e il cui livello tecnico può essere più agevolmente migliorato.
47
Cfr. LOSCO S., Il riuso informatico nelle Pubbliche Amministrazioni: normativa e prime esperienze in Istat, ISTAT, 2009, p. 15. L’autrice distingue tra: “Riuso a cessione semplice”; “Riuso con gestione a carico del cedente”; “Riuso con facility management”; “Cessione del software e attivazione di un servizio ASP” (Application Service Provider).
Per “Riuso a cessione semplice”, s’intende la cessione di un’applicazione a una certa data “nello stato in cui è”. Da tale momento le due amministrazioni provvedono, ognuna per proprio conto, al mantenimento ed all’evoluzione del software che ovviamente si disallineerà in breve tempo.
Per “Riuso con gestione a carico del cedente” s’intende una fattispecie di riuso caratterizzata dal mantenimento nel tempo della completa responsabilità dell’Amministrazione cedente nella manutenzione e nella gestione evolutiva del software, essendo riservato all’Amministrazione ricevente il solo onere della gestione operativa.
Per “Riuso con facility management” s’intende una fattispecie, analoga a quella immediatamente precedente, caratterizzata dall’attribuzione all’Amministrazione cedente dell’ulteriore onere costituito dall’esercizio delle applicazioni.
Per “Cessione del Software e attivazione di un servizio ASP” s’intende la cessione di un’applicativo a un’Amministrazione cedente, unitamente alla garanzia di un servizio di manutenzione, gestione ed esercizio dell’applicativo. Questo può essere erogato direttamente a cura dell’amministrazione cedente (ASP diretto) oppure fornito da un soggetto terzo (ASP con service provider).
45
46
Pagina 17
Per amministrazione cedente, in generale, può intendersi quell’amministrazione che mette a
disposizione di altre amministrazioni, secondo diverse modalità, una o più applicazioni
informatiche (o parti di esse) di propria titolarità.
Per amministrazione ricevente, viceversa, deve intendersi l’amministrazione che riceve
applicazioni (o parti di esse) da altre amministrazioni e le adatta alle proprie esigenze tramite
l'impiego di risorse interne o realizzando tale adattamento tramite un’azienda esterna cui
viene commissionata l'attività (es. in base ad un contratto di appalto).
L’obiettivo del riuso è quello di consentire alle amministrazioni che ne facciano richiesta di
poter acquisire le applicazioni informatiche già realizzate da altre amministrazioni al fine di
utilizzarle ed, eventualmente, modificarle per renderle più adeguate al soddisfacimento delle
proprie esigenze.
Ciò consente, da un lato, di ottimizzare le risorse disponibili - evitando, attraverso il riuso
dei programmi già esistenti il dispendio delle risorse necessarie per lo sviluppo ex-novo dei
predetti applicativi - e, dall’altro, aumentare il grado d’interoperabilità tra i sistemi
informatici delle differenti Amministrazioni 48.
2 IL BACKGROUND NORMATIVO
Il riuso di programmi informatici è attualmente disciplinato dagli artt. 68 e 69 del Decreto
Legislativo 7 marzo 2005, n. 82 (Codice dell’Amministrazione Digitale). In particolare, l’art.
68, nel dettare una disciplina particolareggiata dell’acquisizione di programmi informatici da
parte della P.A – tenuta, com'è noto, a effettuare una preventiva valutazione comparativa
delle diverse soluzioni esistenti sul mercato (e tassativamente indicate dal medesimo art. 68)
– espressamente menziona fra le opzioni disponibili, il riuso dei programmi informatici
sviluppati per conto e a spese della medesima o di altre amministrazioni 49.
Inoltre, le amministrazioni che intendono acquisire un programma informatico devono –
nell’ambito delle procedure previste dal Decreto Legislativo 12 aprile 2006, n. 163 (Codice
dei Contratti Pubblici) – prendere in considerazione, oltre agli altri criteri specificamente
previsti50, anche il potenziale interesse di altre amministrazioni al riuso dei programmi
Sul punto si veda LOSCO S., op cit., p. 9., in cui si evidenzia che il riuso del software, oltre a consentire di razionalizzare le spese e di rendere più omogenee le componenti strumentali hardware e software in uso, è anche uno strumento di egovernment dal momento che, da un lato, permette di condividere esperienze e criteri organizzativi e, dall’altro, rende possibile la fornitura di servizi uniformi e più efficienti agli stessi cittadini.
49
Tale possibilità era già stata introdotta dall’art. 3 comma 2 della Direttiva 19 Dicembre 2003 del Ministero per l’Innovazione e le Tecnologie in materia di “Sviluppo ed utilizzazione dei programmi informatici da parte delle pubbliche amministrazioni”. Tra le diverse soluzioni disponibili sul mercato viene indicato, infatti, alla lettera b.), il “riuso di programmi informatici sviluppati ad hoc per altre amministrazioni”. Allo stesso articolo si precisa che “in sede di scelta della migliore soluzione si tiene altresì conto del potenziale interesse di altre amministrazioni al riuso dei programmi informatici”.
50
Si rinvia sul punto all’ampia disamina svolta da BRAVO F., Software Open Source e Pubblica Amministrazione (L’esperienza europea e quella italiana tra diritto d’autore, appalti pubblici e diritto dei contratti. La EUPL), Bologna, 2009, pp. 86 ss. L’autore individua i criteri in base ai quali deve essere svolta l’analisi comparativa dei programmi. Infatti, le P.A, oltre a considerare il potenziale interesse delle altre amministrazioni al riuso dei programmi, sono tenute a privilegiare, secondo le disposizioni di cui agli articoli 3 e 4 della Direttiva M.I.T 2003: le soluzioni informatiche che assicurino l’interoperabilità e la cooperazione applicativa tra i diversi sistemi informatici della pubblica amministrazione; le soluzioni che rendano i sistemi non dipendenti da un unico 48
Pagina 18
informatici, alla valorizzazione delle competenze tecniche acquisite, alla più agevole
interoperabilità51.
Il favor del legislatore italiano per il riuso si rende ancor più esplicito dalla previsione del
successivo art. 69 (“Riuso dei Programmi informatici”) in cui è stato disposto che: le
pubbliche amministrazioni che siano titolari di programmi applicativi realizzati su specifiche
indicazioni del committente pubblico, hanno l’obbligo di darli in formato sorgente, completi
della documentazione disponibile, in uso gratuito ad altre pubbliche amministrazioni che li
richiedano e che intendano adattarli alle proprie esigenze, salvo motivate ragioni.
Tale disposizione, com’è stato sostenuto, influisce in maniera più che evidente sui contratti
che dovranno essere stipulati dalla P.A (attraverso la procedura di affidamento di cui al
Codice dei Contratti Pubblici) per commissionare a terzi lo sviluppo di specifici software52.
Nei successivi commi 2 e 3 dell’art. 69 si precisa, inoltre, che i programmi così sviluppati
devono essere facilmente portabili su altre piattaforme (comma 2) e che nei contratti di
sviluppo di software devono essere inserite apposite clausole volte a garantire alla P.A
committente il diritto di disporre dei programmi ai fini del riuso 53.
Infine, l’art. 69 comma 4 del Codice dell’Amministrazione Digitale, dispone che nei contratti
di acquisizione dei programmi informatici sviluppati per conto e a spese
dell’Amministrazione, le stesse possono includere clausole, concordate con il fornitore, che
lo obbligano, per un determinato lasso di tempo, a fornire, su richiesta di altre
amministrazioni, servizi che consentano il riuso delle applicazioni. Tali servizi, a titolo
fornitore o da un’unica tecnologia proprietaria; le soluzioni che garantiscano la disponibilità del codice sorgente; i programmi che esportino dati e documenti in più formati, di cui almeno uno di tipo aperto, nonché le soluzioni che presentino un “costo totale di possesso” e “un costo di uscita” inferiore. 51
Sempre BRAVO F., op cit, p. 72, precisa che il riuso può essere effettuato, indistintamente, con riferimento allo sviluppo di programmi di tipo “proprietario” (ad esempio, sviluppato per conto o a spese dell’amministrazione committente) o di tipo “open source” (ad es., quelli sviluppati nell’Ambiente di Sviluppo Cooperativo gestito e coordinato dal CNIPA).
52
Cfr BRAVO F., op cit, p. 73. L’autore descrive, con dovizia di particolari, la procedura di selezione aperta attraverso la quale le P.A individuano i soggetti cui affidare lo sviluppo dei programmi informatici. Si precisa che tali soggetti sono individuati all’esito di una valutazione preventiva della congruità delle offerte sia sotto il profilo del prezzo più basso che sotto quello dell’offerta economicamente più vantaggiosa”. In questo secondo caso, le offerte vengono valutate in base ad un complesso sistema di criteri, quali la qualità, il pregio tecnico, le caratteristiche esteriche e funzionali, le caratteristiche ambientali, il costo d’utilizzazione, la redditività, il servizio successivo alla vendita e l’assistenza tecnica, la data di consegna e il termine di consegna o di esecuzione.
53
Per una critica sul punto si veda BRAVO F., op cit, p. 73. L’autore rimane perplesso dalla portata della norma di cui al comma 3 dell’art. 69. Sostiene, infatti, che il diritto di disporre dei programmi ai fini del riuso, previsto nel comma 3 cit. come oggetto di clausola contrattuale, dovrebbe essere insito nei diritti già detenuti dalla P.A. in quanto “titolare” dei programmi applicativi realizzati su proprie indicazioni, come risulta dall’ampia formula utilizzata al comma 1.
Sul punto si vedano anche FLICK C., CIGNONI G. A., AMBRIOLA V., op cit., p. 89, i quali precisano che la P.A, in virtù dell’art. 2 comma 3 del Decreto Legislativo 12 febbraio 1993, n. 39, Norme in materia di sistemi informativi automatizzati delle amministrazioni pubbliche, conserva la titolarità dei programmi applicativi anche nel caso in cui affidi a terzi l’attività di progettazione, sviluppo e gestione dei sistemi informativi automatizzati. Ne consegue che il diritto di disporre del programma ai fini del riuso non necessiterebbe di alcuna pattuizione contrattuale ulteriore, essendo già ricompreso nell’alveo delle facoltà riservate spettanti ad essa, in quanto titolare dei diritti relativi ai programmi così sviluppati. Tale orientamento è inoltre conforme con quanto disposto dalla legge sul diritto d’autore, secondo cui alle amministrazioni dello Stato, alle province e ai comuni, spetta il diritto d’autore sulle opere create e pubblicate sotto il loro nome ed a loro conto e spese (art. 11). Pagina 19
esemplificativo, possono includere anche l'adattamento del programma al fine di renderlo
utilizzabile su una diversa piattaforma software o hardware.
In conclusione, deve, però, rilevarsi che l’operatività di queste disposizioni presuppone la
titolarità dei diritti esclusivi sul software in capo alla P.A. Al riguardo si precisa che la
questione è stata inizialmente affrontata dal Decreto Legislativo 12 febbraio 1993, n. 39 e
successive modificazioni. L'art. 2 del summenzionato Decreto precisa che le amministrazioni
– ove non provvedano con proprio personale alla progettazione, allo sviluppo ed alla gestione
dei propri sistemi informativi automatizzati – possono conferire affidamenti a terzi, anche
tramite concessione, conservando, in ogni caso, la titolarità dei programmi applicativi.
Inoltre, il successivo art. 12 dispone che fra gli elementi necessari dei capitolati contenenti le
condizioni generali dei contratti di fornitura di software che la P.A stipula con terzi deve, in
ogni caso, sussistere la dichiarazione che i titolari dei programmi applicativi sviluppati
nell'ambito dei contratti di fornitura siano le amministrazioni. In conclusione, la P.A sarà
titolare dei diritti esclusivi sul software sia quando commissioni a terzi lo sviluppo di
software ad hoc, sia quando acquisti tutti i diritti a seguito di cessione da parte del titolare.
Nella prassi, tuttavia, accade non di rado che le P.A, invece di acquisire programmi sviluppati
ad hoc, procedano con l’acquisizione di mere licenze d’uso dai titolari di prodotti software
commerciali54.
In tali casi, atteso che l'acquisizione di una semplice licenza d'uso relativa ad un determinato
programma non può certamente essere equiparata allo sviluppo ad hoc di un software su
indicazioni del committente pubblico, resterebbero, di fatto, inoperanti le sopra richiamate
previsioni normative, con particolare riferimento all'obbligo gravante sull'amministrazione di
fornire i programmi (sviluppati su proprie indicazioni) in formato sorgente unitamente alla
documentazione tecnica alle altre amministrazioni che ne facciano richiesta. Ciò, di
conseguenza, non può che paralizzare inevitabilmente il potenziale interesse delle altre
amministrazioni al riuso di quel determinato programma.
In aggiunta, va rilevato che il contratto di licenza d'uso, come è noto, concede al licenziatario
unicamente la facoltà di utilizzare il programma secondo le modalità definite dal licenziante
stesso. Tale facoltà, logicamente, non ricomprende anche la possibilità di studiare, esaminare,
modificare e ridistribuire il programma. Di conseguenza, il diritto di disporre del programma
ai fini del riuso – che implica l'esistenza in capo alla P.A della facoltà di studiare, esaminare,
modificare e ridistribuire il programma – dovrà, eventualmente, essere oggetto di specifica ed
ulteriore pattuizione contrattuale con il fornitore. 55
.
Tale possibilità è prevista dall’art. 68 lett. C) del Codice dell’Amministrazione Digitale che, infatti, permette espressamente alle P.A l’acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d’uso. In tali casi, però, viene garantita, salvo pattuizione contraria, la disponibilità del solo codice oggetto e non anche del codice sorgente. La P.A, di conseguenza, non è posta in condizione di modificare il programma per adattarlo alle proprie esigenze.
55
Sul punto v. FLICK C., CIGNONI G. A., AMBRIOLA V., op cit, p. 89. Gli autori precisano, infatti, che, in tali casi, non si possa prescindere da un esplicita autorizzazione del titolare dei diritti esclusivi ovvero il fornitore. Si rileva, però, che tale ipotesi è di difficile realizzazione, dal momento che i fornitori, anche quando affermano genericamente di consentire il riuso da parte di amministrazioni diverse dai loro interlocutori, in realtà non permettono la modifica dei propri programmi.
54
Pagina 20
3 LA LICENZA PUBBLICA DI RIUSO
Alla luce delle disposizioni normative e delle problematiche cui sopra si è fatto cenno,
emerge che la disciplina concreta dei rapporti tra amministrazione cedente ed
amministrazione ricevente, nell’ambito di una fattispecie di riuso di software, deve essere
contenuta in atti di autonomia privata, quali le cd. Licenze pubbliche di riuso 56.
Tali Licenze, infatti, sono nate per offire una disciplina ad hoc al riuso, al fine di consentire il
pieno raggiungimento degli obiettivi prefissati dall’amministrazione, bilanciando gli interessi
dei soggetti pubblici e privati alla modifica e redistribuzione del software con quello
dell’amministrazione cedente al ritorno degli investimenti sostenuti nello sviluppo del
softtware in questione57.
Ai fini di questo studio è stata analizzata la Licenza Pubblica di Riuso (versione 1.01)
predisposta dal Centro Regionale di Competenza per il Riuso della Toscana e che potrebbe
essere utilizzata quale modello al fine della elaborazione di una futura Licenza Pubblica di
Riuso condivisa a livello nazionale58.
Chiariscono, infatti, FLICK C., CIGNONI G. A., AMBRIOLA V, op cit, p. 88, che “affinché il riuso sia efficace è bene che tutti coloro che sono interessati possano intervenire per apportare le modifiche che poi saranno utili alla comunità dei riusatori, nell’ottica dell’evoluzione del prodotto. Ne consegue che il soggetto che dà in riuso un prodotto software deve avere la disponibilità dei diritti sul prodotto stesso. In altri termini, i profili giuridici del riuso attengono ai cd. diritti di proprietà intellettuale sul software in particolare i diritti esclusivi di uso, modifica e distribuzione derivanti all’autore dalla creazione di un prodotto software nuovo e originale”. La licenza di riuso è dunque quel determinato contratto di licenza con il quale l’amministrazione cedente (titolare dei diritti esclusivi sul software) concede all’amministrazione ricevente un fascio di diritti (di uso, di modifica e di eventuale redistribuzione) aventi ad oggetto il programma al fine di permettere il riuso a fini istituzionali.
57
Si veda l’ampia disamina svolta da CIGNONI G. A., e AMBRIOLA V., Riuso v. Open Source, un confronto necessario, atti di Pubblica Amministrazione Aperta e Libera PAAL 2008, Cagliari, 1718 aprile 2008, p. 4. Gli autori evidenziano, infatti, che la Licenza di Riuso appare necessaria per superare le criticità connesse all’utilizzazione delle Licenze libere e open source. Si prendono in considerazione tre ipotesi: la prima, in cui un’amministrazione ricevente modifica un programma OS, senza modificare la documentazione e inserendo dipendenze da programmi proprietari; la seconda, in cui un azienda terza riesce a installare sulle proprie macchine il programma OS e a vendere servizi aggiuntivi in modalità ASP, grazie alla sua rete commerciale; la terza, in cui un’amministrazione ricevente aggiunge nuovi sviluppi in modalità quick & dirty, rendendo, di fatto, tale programma incompatibile con i futuri sviluppi realizzati dal titolare. In questi casi si finirebbe, secondo gli autori, per pregiudicare la stessa possibilità di riutilizzare il prodotto in modo efficiente. Il programma di partenza, infatti, subirebbe delle modifiche che, oltre a non apportare alcun valore aggiunto, potrebbero anche menomare le stesse funzionalità del programma. Un ulteriore rischio sarebbe, inoltre, costituito dalla possibilità di finire per attribuire un non trascurabile vantaggio ad aziende private, le quali potrebbero appropriarsi del programma e fornire una serie di servizi aggiuntivi a pagamento, sfruttando, quindi, gli investimenti pubblici nel programma di partenza. CONTRA, invece, CORRADINI A., FLAGELLA T., Il paradigma open source nel contesto dell’attuale modello di riuso del software nella Pubblica Amministrazione Italiana, Atti della Conferenza Italiana sul Software Libero 2008, pp. 3 ss., i quali sostengono, invece, che sarebbe necessario rilasciare tali Programmi sic et simpliciter con licenze libere o open source.
58
La Regione Toscana ha definito la propria azione per il riuso nella Legge Regionale 1/2004 e successivamente nella Delibera di Giunta 1258/2005 che ha stabilito l'istituzione di un Centro Regionale di Competenza per il Riuso. Nel dicembre 2006 la Regione ha affidato, tramite selezione, l'attivazione del CRC.R al Dipartimento di Informatica dell'Università di Pisa, che partecipa al cofinanziamento del progetto. Come hanno rilevato FLICK C., CIGNONI G. A., AMBRIOLA, op cit., p 91, lo scopo del Centro Regionale di Competenza per il Riuso (CRCR) è, secondo le precise indicazioni della Regione Toscana, favorire il riuso nei processi di informatizzazione della Pubblica Amministrazione Toscana. alla Regione. Inoltre, esso definisce le linee strategiche e i criteri operativi per la valutazione e la certificazione della riusabilità dei prodotti e per la gestione di progetti di riuso; pubblica 56
Pagina 21
La predetta Licenza, in primo luogo, definisce i diritti e gli obblighi gravanti sul Titolare del
Programma (amministrazione cedente), sul Riusatore (amministrazione ricevente) e sugli
eventuali Fornitori, intesi come quei soggetti privati che, in qualsiasi modo, ricevono un
prodotto rilasciato con la Licenza di Riuso, e che, al solo fine di poter offrire ai riusatori
servizi di supporto al prodotto, hanno il diritto di studiarlo, modificarlo e redistribuirlo. Ci si
riferisce, in particolar modo, a quelle aziende che, sulla base di idonei contratti di appalto
stipulati con una o più amministrazioni, s'impegnano a fornire una serie di servizi, fra i quali,
a titolo esemplificativo, si segnalano la manutenzione correttiva e/o evolutiva di un
programma e il compimento delle modifiche necessarie atte a consentirne l'utlizzo su una
piattaforma diversa.
In particolare, il Titolare e gli eventuali Contitolari 59 concedono ai Riusatori (e ai Fornitori) il
diritto non esclusivo, a tempo indeterminato e a titolo gratuito, di studiare, modificare e
redistribuire il prodotto. Si può, quindi, concordare con chi ritiene che una delle principali
caratteristiche della Licenza Pubblica di Riuso in esame sia quella di “aprire” i programmi al
riuso, superando il meccanismo della preventiva richiesta del riusatore previsto nel Codice
dell’Amministrazione Digitale60.
Questa ampia libertà riconosciuta a riusatori e fornitori è controbilanciata da alcune
significative limitazioni:
a) ai Riusatori e ai Fornitori è vietato registrare il programma a proprio nome e/o
commercializzarlo (art. 6);
b) ai Fornitori è vietato utilizzare il programma per scopi applicativi propri e/o per fornire
servizi aggiuntivi a terzi (art. 7);
c) ai fornitori e ai riusatori è consentito creare programmi derivati ma la redistribuzione è
vietata qualora tale programma non sia rilasciato con la licenza di riuso e qualora tale
programma possa considerarsi degradato (art. 5 comma 4).
Tale ultimo divieto (quello di redistribuire un programma derivato degradato) costiuisce, ad
avviso di chi scrive, il cuore del bilanciamento di interessi alla base della Licenza Pubblica
di Riuso. Infatti, si considera programma degradato un programma derivato che, per le sue
rapporti periodici per documentare lo stato del riuso nella Pubblica Amministrazione toscana; fornisce alla Regione elementi strategici per promuovere il riuso, abbattendone i costi attraverso il miglioramento dei prodotti e la concentrazione degli interventi su specifiche aree tematiche; svolge attività di consulenza con servizi diretti alle amministrazioni locali, per la progettazione e la gestione di interventi di riuso o la realizzazione di prodotti riusabili. In particolare, il CRCR, mantiene il catalogo di prodotti riusabili, consultabile pubblicamente e contenente informazioni aggiornate sui prodotti software di certificata riusabilità e sui progetti che hanno realizzato o riusato prodotti presenti nel catalogo.
59
Per Contitolari si intendono i soggetti pubblici o privati che hanno collaborato, con un contributo identificato, allarealizzazione e/o all’evoluzione di un prodotto. L’art. 4 della Licenza precisa, inoltre, che i Contitolari sono titolari dei contributi che hanno fornito per la realizzazione e/o l’evoluzione del prodotto.
60
Cfr. CIGNONI G. A., e AMBRIOLA V., op cit., p. 4. Gli autori rilevano, infatti, che attraverso la Licenza di Riuso è la stessa P.A titolare del programma che rende disponibile il prodotto in tutte le sue componenti: sorgenti, dati di configurazione, eseguibili, dati e contenuti iniziali, documentazione per gli sviluppatori, per gli amministratori di sistema, per gli utenti. Inoltre, si evidenzia che, nonostante una così ampia “apertura”, è, in ogni caso, garantita la competizione alla pari per le aziende interessate a fornire servizi di assistenza, manutenzione e sviluppo.
Pagina 22
mutate caratteristiche tecniche, favorisce il riuso con minor efficacia del prodotto originario 61.
In particolare, sono prodotti degradati:
i) prodotti derivati che eliminano funzionalità che non sono obsolete né deprecate;
ii) prodotti derivati che introducono dipendenze da componenti esterne che non sono
rilasciate con la Licenza di Riuso o con una licenza a codice aperto;
iii) prodotti derivati che riducono il numero di di piattaforme tecnologiche sulle quali
possono essere installati ed eseguiti;
iv) prodotti derivati che non hanno aggiornato la documentazione per gli utenti, per
gliamministratori di sistema e per gli sviluppatori.
Interessante, inoltre, la previsione dell’art. 14 della licenza “clausola risolutiva espressa” che
prevede la risoluzione automatica della Licenza in caso di violazione di uno degli articoli
compresi tra il 3 e il 12. Non appena si produce l’effetto risolutivo – ferma restando la
necessaria la manifestazione di volontà del titolare diretta alla controparte per l’operatività
della clausola (ex. Art. 1456 c.c.) – ogni ulteriore atto di utilizzazione del Programma
costituisce violazione dei diritti d’autore e possibile fonte di responsabilità civile e penale.
Analoghe clausole sono, tuttora, presenti in molte Licenze libere e Open Source. Tuttavia, si
è sempre discusso circa la reale qualificazione giuridica delle stesse 62. Tali difficoltà possono
ritenersi del tutto superate con riferimento alla corrente Licenza di Riuso, atteso che la
clausola in esame è espressamente definita come una clausola risolutiva espressa.
4 CRITICITÀ
L’attuale disciplina del riuso presenta, tuttavia, alcuni non trascurabili profili di criticità.
Come è stato autorevolmente rilevato, sia gli attuali bandi per la fornitura di software su
commissione (anche ai fini del riuso), sia i bandi pubblici per il finanziamento dei progetti di
riuso di soluzioni di e-government, presuppongono che la P.A sia proprietaria dei software in
questione. Ad esempio, l’Avviso per la realizzazione di progetti di riuso pubblicato dal
CNIPA nel febbraio 2007 prevede risorse per 60 milioni di Euro per i progetti di riuso e
richiede che le soluzioni di e-Government proposte per il riuso debbano “essere di proprietà e
nella piena friubilità della pubblica amministrazione cedente”.
Rilevano giustamente CIGNONI G. A., e AMBRIOLA V, op cit., p. 5 che “La dimostrazione in sede giudiziale che, in un malaugurato caso, tali comportamenti siano effettivamente avvenuti è cosa che spesso dipende, più che dai fatti, dall’abilità di avvocati e periti nell’indirizzare l’interpretazione del giudice. E questo è un problema comune a tutto ciò che ha spiccati contenuti tecnici”.
62
Si discute in dottrina se possa qualificarsi questa clausola come condizione risolutiva o clausola risolutiva espressa, ma sembra più corretto parlare di essa come di una “delle tante modalità di tutela dell’opera dell’ingegno, che ampiamente condizionata, dai mezzi tecnologici di riproduzione e diffusione, ha la necessità di regolare automaticamente ed in ogni momento gli ampi interessi economici che si sostanziano nel possibile sfruttamento di qualsiasi esemplare”. SANSEVERINO G., Le licenze free e open source. Edizioni Scientifiche Italiane, 2007, pp. 104. ss. L’autore, infatti, rigetta la tesi secondo cui la clausola virale sarebbe una condizione risolutiva, dal momento che la condizione deve riguardare eventi esterni al contratto e non l’inadempimento. Al pari, secondo l’autore, tale clausola non potrebbe neppure essere considerata alla stregua di una condizione risolutiva espressa, in quanto essa dovrebbe concernere una o più obbligazioni specificamente individuate e non l’inadempimento di una qualsiasi obbligazione del contratto.
61
Pagina 23
Un tale approccio costituisce un evidente limite alle stesse potenzialità del riuso, in quanto
non consente la realizzazione di fattispecie di riuso utilizzando come base di partenza una
soluzione software rilasciata con licenza libera o open-source.
Infatti, com’è stato autorevolmente rilevato, se un fornitore volesse rispondere ad una gara
che richiede una certa soluzione software, rielaborando un software open source preesistente,
non potrebbe cedere alla P.A la piena proprietà della soluzione complessiva realizzata, ma
potrebbe, invece, cedere la piena proprietà delle sole modifiche realizzate al software open
source di base. Inoltre, senza il requisito della piena proprietà dell’intera soluzione, una P.A
non potrebbe successivamente accedere ai finanziamenti per un progetto di riuso e, di fatto,
costituisce un ulteriore ostacolo alla realizzazione di fattispecie di riuso a partire da una base
open source63. Pertanto, né i fornitori, né le P.A potrebbero realizzare una soluzione software
ai fini del riuso rielaborando preesistenti Programmi open source, ma dovrebbero, invece,
realizzare tale soluzione da zero: ciò comporta ovviamente una lievitazione dei costi da
sostenere e, come corollario, l’impossibilità di investire, invece, le medesime risorse per
l’evoluzione migliorativa di Programmi già disponibili.
Il presupposto del riuso è, come si è visto, che la P.A possa quantomeno esercitare e,
soprattutto, sublicenziare ad altre amministrazioni il diritto di utilizzare, studiare, modificare
e redistribuire il programma. Il riconoscimento di tali diritti in capo all’utente (sia esso
soggetto pubblico o privato) è, com’è noto, l’elemento centrale delle Licenze libere e open
source64. Di conseguenza, nei futuri bandi pubblici per il finanziamento dei progetti di riuso,
si potrebbe richiedere alternativamente la piena proprietà di un programma (proprietario) o,
quantomeno, la titolarità di una licenza open source, atteso che, in entrambi i casi, si
garantirebbe la possibilità per i futuri riusatori di utilizzare, modificare e redistribuire il
Programma.
Tale soluzione non verrebbe, inoltre, ostacolata dalla lettera dell’art. 69 comma 1, che, come
si è già visto, prevede l’obbligo per le Pubbliche Amministrazioni, titolari di Programmi
applicativi realizzati su specifiche indicazioni del committente pubblico, di concedere tali
programmi – unitamente al codice sorgente ed alla documentazione disponibile – ad altre
Pubbliche amministrazioni che li richiedano. La disposizione testè richiamata, però, non vieta
Si veda sul punto l’ampia disamina di CORRADINI A., FLAGELLA T., op. Cit. pp. 3 ss.. Gli autori, in particolare, ritengono che un siffatto approccio costituirebbe un limite alla qualità delle soluzioni software realizzate per la P.A. In particolare, rilevano che la cessione della proprietà del software da parte del fornitore alla P.A committente implica che il software prodotto non potrà essere utilizzato dal fornitore per altre forniture (salvo patto contrario). Per tale motivo il fornitore – che opera in una logica di massimizzazione del profitto – tenderà a realizzare la soluzione più economica atta a superare il collaudo del software, disinteressandosi della qualità intrinseca del software stesso. Laddove, invece, il fornitore potesse riutilizzare il prodotto stesso per altre forniture, tenderebbe, invece, a considerare la qualità del prodotto finale come un valore a sé stante. Il problema, secondo gli autori, potrebbe essere superato attraverso clausole analoghe a quelle di joint Copyright Assignment – utilizzate per i contributi di molti progetti Open Source, tra i quali OpenOffice – attraverso le quali si potrebbe, quindi, prevedere la duplice proprietà del software sviluppato sia in capo alla P.A committente, sia in capo al Fornitore stesso. Una siffatta previsione, dunque, consentirebbe al Fornitore di riutilizzare liberamente il Programma nell’ambito di altre forniture e/o di rilasciarlo come progetto Open Source. 64
Si rinvia a BERTANI M., Guida alle licenze di software libero e open source, Nyberg Edizioni, 2004, per una organica trattazione delle licenze libere e open source. In particolare si evidenzia che “oggetto del contratto è la concessione della possibilità di copiare, modificare e redistribuire il programma nei limiti di quanto previsto dalla licenza. 63
Pagina 24
alle stesse Pubbliche amministrazioni di consentire il riuso negli altri casi in cui esso sia
concretamente possibile65.
Gli unici ostacoli sarebbero, invece, costituiti dalla compatibilità tra le licenze libere e open
source e la Licenza di Riuso, atteso che quest’ultima, come si è già avuto modo di
sottolineare, prevede alcune limitazioni alle facoltà riconosciute ai riusatori, mosse, appunto,
dall’esigenza di bilanciare gli interessi in gioco. Senza voler qui addentrarsi in una esaustiva
trattazione delle Licenze libere e open source, si intende sottolineare che molte di esse
contengono una specifica clausola, definita clausola virale66, che obbliga l’utente a
redistribuire il Programma negli stessi esatti termini della Licenza originaria (vale a dire che
un Programma rilasciato con una Licenza ad es. GNU/GPL potrebbe essere redistribuito solo
con essa e non con una licenza di riuso). È altrettanto vero, tuttavia, che altre licenze (come la
licenza BSD – Berkeley Software Distribution) consentono la successiva redistribuzione del
Programma anche in termini diversi da quelli della licenza originaria. Pertanto, le concrete
possibilità di riutilizzare un programma-base libero o open source dipenderanno dallo
specifico contenuto della licenza originaria.
Al riguardo, un ulteriore tassello può essere costituito dalla recente introduzione della
European Union Public License (EUPL), una licenza open source redatta dalla Commissione
Europea al fine di soddisfare le specifiche esigenze dell’Unione europea e delle
amministrazioni dei singoli Stati membri 67. In particolare, tale licenza – che può essere
adottata da qualsiasi soggetto privato e pubblico, a condizione che abbiano acquisito la
titolarità dei diritti di proprietà intellettuale – si caratterizza per una spiccata compatibilità
con altre licenze libere e open source, consentendo la redistribuzione delle versioni
modificate del Progamma anche attraverso talune predeterminate licenze definite, per
l’appunto, Licenze compatibili 68. In un prossimo futuro, non si esclude che, nel momento in
cui sia disponibile una versione consolidata della Licenza Pubblica di Riuso, anch’essa possa
rientrare nel novero delle Licenze compatibili indicate dalla EUPL.
Inoltre, laddove si provveda ad apportare le opportune modifiche alle licenze libere e open
source al fine di consentire la successiva redistribuzione dei Programmi anche con licenze di
Cfr. CIGNONI G. A., e AMBRIOLA V., op cit., p. 4., i quali rilevano che, attraverso la Licenza Pubblica di Riuso viene superato il meccanismo previsto dal CAD e basato sulla richiesta esplicita da parte del riusatore: è la stessa P.A che consente ab origine il riuso da parte delle altre amministrazioni.
66
La clausola virale è lo strumento giuridico attraverso il quale l’autore originario può effettivamente avere la icurezza che le libertà riconosciute tramite la licenza non vengano meno con le successive distribuzioni o modificazioni del programma. Si parla di «viralità» di questa clausola perchè non solo si applica alle successive distribuzioni dello stesso programma, ma anche ai programmi derivati o che contengono parti del programma licenziato come software libero, salva l’ipotesi della semplice coesistenza di un programma libero e di uno proprietario su di un unico supporto.
67
Per un’ampia analisi della EUPL si rinvia a BRAVO F., op cit., pp. 89 ss. In particolare, si evidenzia che la EUPL – nata per licenziare i programmi realizzati nell’ambito dell’ambiente di sviluppo cooperativo europeo e, quindi, promuovere la fornitura di servizi paneuropei di egovernment alle pubbliche amministrazioni, alle imprese ed ai cittadini – è stata sviluppata all’esito di un approfondito studio sulle licenze libere condotto dalle istituzioni comunitarie che ha suggerito alle stesse di elaborare una licenza ad hoc.
68
Il riferimento è alla cd. Downstream Compatibility, in quanto la EUPL, pur mantenendo la clausola virale del copyleft, concede ai licenziatari la possibilità di rilasciare il Programma originario e/o le eventuali versioni modificate anche con le seguenti tipologie di licenze libere definite come “licenze compatibili”: la General Public Licence v2;, la Open Software Licence v. 2.1/3.0; la Common Public Licence v.1.0; la Eclipse Public Licence v. 1.0; la CeCill v.2.0 . Si precisa, altresì, che, in caso di conflitto tra i termini della licenza EUPL e quelli della licenza compatibile, prevalgono sempre i termini di quest’ultima.
65
Pagina 25
Riuso, si potrebbe facilitare il riuso stesso e, di conseguenza, anche incentivare una più
capillare diffusione del software libero all’interno della Pubblica Amministrazione.
This work is licensed under the Creative Commons Attribution-Share Alike 2.5 Italy License.
To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/it/ or send
a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California,
94105, USA.
Bibliografia Bertani, M. (2004). Guida alle licenze di software libero e open source. Nyberg Edizioni..
Sanseverino, G. (2007). Le licenze free e open source. Edizioni Scientifiche Italiane.
Cignoni G. A, e Ambriola V. (2008). Riuso v. Open Source, un confronto necessario. Atti di
Pubblica Amministrazione Aperta e Libera – PAAL 2008.
Corradini A., Flagella T. (2008). Il paradigma open source nel contesto dell'attuale modello
di riuso del software nella Pubblica Amministrazione Italiana. Atti della Conferenza
Italiana sul Software Libero 2008.
Flick C., Cignoni G. A., Ambriola V. (2008). Il riuso del software nella Pubblica
Amministrazione. Diritto dell'Internet.i
Losco, S. (2009). Il riuso informatico nelle Pubbliche Amministrazioni: normative e prime
esperienze in Istat. ISTAT.
Bravo, F. (2009). Software Open Source e Pubblica Amministrazione (L'esperienza europea e
quella italiana tra diritto d'autore, appalti pubblici e diritto dei contratti. La EUPL),
Bologna.
Pagina 26
LIBERA-MENTE
DIDATTICA LIBERA NEL COMUNE DI PISA
Dott.ssa Laura Bertellotti, Università di Pisa, l.bertellotti@hotmail.it
Prof.ssa. Marilù Chiofalo, Assessora Politiche Educative e Scolatiche, Promozione
tecnologie per la Formazione, Comune di Pisa.
Prof.ssa Flavia Marzano, Università La Sapienza, Roma.
Abstract «Nulla si crea, nulla si distrugge, tutto si trasforma.»
Antoine Lavoisier
L'avvento del digitale ha invaso ogni aspetto del vivere quotidiano, portando dematerializzazione e
nuove abitudini di interazione, infiniti spazi di conoscenza e nuove possibilità di espressione, in ogni
campo e materia. Il processo di digitalizzazione ha trasformato profondamente e con rapidità il nostro
modo di essere, illustrandoci un segmento, la tecnologia, dalle proteiformi possibilità che ci facilita in
ogni attività quotidiana.
La Rete ci ha insegnato la libertà di espressione, il senso
della condivisione dei saperi e dei pensieri; ci ha dato la possibilità di raccontare il nostro Io
nell'etere e di arricchirlo dei racconti altrui; ci ha permesso di creare legami, unire realtà, abbattere
confini e creare ponti; ed oggi, facendo il suo ingresso nelle scuole, la Rete ci aiuta nella didattica,
divulgando e promuovendo i suoi valori pedagogici tra gli alunni di oggi, abitanti del mondo di
domani. Il piano E-Government 2012 disegna l'immagine di una scuola totalmente digitalizzata e
profondamente vissuta nel Web, come strumento di informazione e confronto, dotato della capacità di
interessare e trasformare lo studio in gioco. La scuola digitale a cui si aspira è costruita su cavi di
fibra ottica che permettono la navigazione veloce ed è composta da computer ed infrastrutture
sinergiche e omogenee che supportano la didattica. Le lavagne diventano interattive e le lezioni
cambiano la propria natura, divenendo aperte e partecipative. Proiettori, webcam, microfoni e
strumentazioni audio-video aiutano lo studente a dare interattività alle materie, rilette in una chiave di
apprendimento personalizzata che simula,\ con programmi e software, scenari e nozioni, rendendo la
conoscenza dinamica e intuitiva. La scuola digitale è la scuola che trasmette ai più piccoli le linee
guida che condizionano la loro crescita e il loro sviluppo e come tale è fondamentale che insegni loro
i valori di base che orientano le scelte e formano la capacità di stare nel mondo. Per questa ragione la
scuola deve promuovere valori di base come l'uguaglianza, la solidarietà, l'educazione, e la libertà di
espressione secondo l'etica della responsabilità. Tutto ciò che ruota dentro e intorno l'istituzione
scolastica deve essere conforme a questi principi, che sono diritti e doveri del mondo virtuale e del
mondo reale. Le linee teoriche e i propositi più nobili spesso si infrangono tuttavia nella necessità
continua di innovare competenze e infrastrutture, e nella mancanza di fondi e sostegno reale per
farlo, così che il sistema scolastico rimane ancorato ad anacronistici retaggi. Nella realtà ancora
confusa e in fase di trasformazione della scuola nell'era del digitale rappresenta un'importante
esperienza quella del Comune di Pisa che, con un progetto articolato e integrato, porta la tecnologia
nella scuola, utilizzando criteri di economicità, collaborazione e innovativa sostenibilità ambientale. Il
Comune di Pisa crede nella scuola del Web e delle lavagne digitali e promuove ed utilizza nei suoi
progetti il software libero, liberamente modificabile e distribuibile, economico e personalizzabile. Un
Pagina 27
modello culturale ed educativo che sta entrando nella quotidianità di alunni e alunne con l'ambizione
di divenire una prassi consolidata.
Parole Chiave: Software libero, Scuola, Didattica, Pisa, Comune.
1
LIBERI DI IMPARARE
1.1 La scuola dell'era digitale
La digitalizzazione della scuola è uno dei principali obiettivi del piano E-Governemnt 2012
che nella tecnologia vede la possibilità di semplificare e avvicinare la scuola ai giovani e alle
loro famiglie.
Il prototipo della scuola dell'era digitale vede la Rete protagonista sia delle dinamiche
didattiche e di apprendimento, che di quelle scuola-famiglia. In entrambi i casi si realizza di
fatto un ampliamento di modalità e livelli di approfondimento individuale e di interazione.
Nel primo caso attraverso l'uso intelligente delle risorse offerte da Internet, la
dematerializzazione dei supporti e l'ampliamento del concetto di apprendimento, con lo scopo
di agevolare studenti e docenti sia nella disponibilità dei materiali didattici che nella
costruzione cooperativa e dinamica di una conoscenza condivisa: diversa ogni volta secondo
le potenzialità presenti in quel particolare momento in quella particolare aula. Nel secondo
caso con l'obiettivo di favorire le comunicazioni docenti-genitori e permettere a questi ultimi
di essere parte attiva del processo di scolarizzazione del proprio figlio, in un contesto sociale
in cui l'individualizzazione e conseguente gestione dei tempi di vita e di lavoro sono difficili .
Lo scopo principale della scuola è quello di formare individui che da alunni si trasformino in
abitanti del mondo e come tali si muovano attraverso mappe cognitive ed intellettive
interiorizzate, trasformabili e riusabili in sempre nuova conoscenza. Questo corrisponde ad
acquisire la distintiva capacità di imparare ad imparare lungo tutto l'arco della vita,
sviluppando le cosidette life-skills: conoscenza, consapevolezza e uso interconnesso di tutte
le proprie e diverse (per ognuno) abilità individuali in modo multidisciplinare, e capacità di
comunicazione interpersonale, conoscenza delle regole e uso delle abilità sociali. Per questo è
importante che, fornendo i giusti strumenti intellettivi, l'istruzione sia specchio del mondo e
che, come tale, lo rappresenti.
L'era digitale ha profondamente segnato il nostro sistema culturale, invadendo le nostre
abitudini e facendo entrare la sua filosofia in ogni segmento del quotidiano. Gli alunni e le
alunne di oggi sono digital natives69, sviluppano le loro capacità intellettive parallelamente
all'uso consapevole e spontaneo dei mezzi digitali e lo fanno con la naturalezza con cui
imparano a camminare e a parlare perchè ne percepiscono la necessità d'uso, crescendo così
viziati e dipendenti da queste commodities.
Una scuola che pertanto anacronisticamente non apra le proprie porte alla tecnologia e tenga
lontana l'informatica dalla propria struttura manca un'opportunità e rischia di non essere un
valido sostegno alla preparazione e alla formazione di soggetti capaci di multidisciplinarietà e
Digital natives: Nativo digitale (dalla lingua inglese digital native) è una espressione che viene applicata ad una persona che è cresciuta con le tecnologie digitali. Fonte: Wikipedia.
69
Pagina 28
flessibilità, lasciando chi impara senza un'adeguata conoscenza del computer come strumento
di apprendimento, di evoluzione e di vita.È possibile che nessuno studente diventi mai
esperto o esperta di programmazione o di informatica nell'arco della propria vita, così come è
possibile che nessuno di loro abbia un futuro nella matematica o nella letteratura, ma è
fondamentale inserire l'uso del computer come percorso culturale e materia d'insegnamento di
base al pari delle altre, con lo scopo di stimolare la curiosità, creare e potenziare le
infrastrutture logiche necessarie ad accogliere ogni tipo di processo mentale, e moltiplicare le
abilità di linguaggio.
Come in ogni processo di apprendimento, le opportunità sono accompagnate da rischi. In
questo caso, la vastità degli spazi virtuali accessibili e la velocità delle connessioni ha effetti
dirompenti sul tempo dell'apprendimento e sul suo uso. Una enorme quantità di informazioni
diventa disponibile in pochissimo tempo, e pone la questione etica – nel senso etimologico
del termine – di una adeguata definizione della qualità della conoscenza che includa in modo
equilibrato ampiezza e approfondimento, diffusione e controllo delle fonti, appropriatezza dei
contenuti.
Ed è proprio nel contesto educativo che il software libero può dispiegare le proprie
potenzialità, coerentemente con la mission della scuola, riuscendo a stimolare la curiosità e a
creare la libertà necessaria ad apprendere l'informatica come forma mentis della nostra epoca
che, sempre più, condiziona in maniera totalitaria la maggior parte delle attività umane.
1.2 Software libero e scuola
Utilizzare un qualsiasi software senza avere la possibilità di sviscerarlo, studiarlo, esplorarlo
è come accontentarsi di conoscere per sentito dire la una trama di un libro, senza poterlo
vivere in prima persona, senza poterne fare un'analisi linguistico-letteraria, vietata per timore
che parole e stili vengano rubati e copiati senza permesso. Il software libero, a differenza di
quello proprietario, ha una natura educativa, nasce e si sviluppa attorno al concetto di
divulgazione di un sapere che cresce arricchendosi dei saperi pregressi, seguendo eticamente
i principi della scuola che fa di conoscenza e libertà le sue bandiere. Il software libero si basa
sulla medesima cultura della partecipazione che pervade la scuola come luogo di incontro
dei pensieri individuali, che intrecciandosi si elevano e moltiplicano, e allo stesso modo della
scuola mira a stimolare lo spirito cooperativo come metodologia formativa essenziale
nell'esercitare la mente e garantire i meccanismi di socializzazione fondamentali per lo
sviluppo dell'intelletto. Questa comunione di intenti rappresenta la base ideale che promuove
l'uso del software libero nella didattica e che si accompagna a importanti motivazioni di
carattere pratico: questa tipologia di software è una tecnologia a basso costo in quanto
elimina l'onere delle licenze, il cui prezzo grava su quanti utilizzano software proprietario, e
permette di avere applicazioni non soggette a scadenze, liberamente utilizzabili e fruibili nel
tempo.
Anche la qualità combacia con le esigenze di una scuola che dispone di fondi limitati per
creare un sistema interno di strumenti efficiente ed efficace e che con il software libero vede
realizzarsi la concreta la possibilità di installare, al solo prezzo della prima copia, il software
su un numero illimitato apparecchi attraverso il meccanismo della copia e della libera
distribuzione.
Pagina 29
1.2.1 L'esperienza del Comune di Pisa
In definitiva, il concetto chiave che definisce l'uso del software libero nelle scuole è quello di
una nuova economia. Le risorse immateriali e di lunga durata come conoscenza e capacità di
sviluppo di ogni individuo sono il bene primario e misurabile per la comunità e in quanto tali
sono rese immediatamente disponibili. È questa la chiave della sostenibilità d'uso delle
risorse materiali e finanziarie, hardware e software, che hanno una durata invece finita.
L'intuizione dell'economicità data dall'assenza di licenze d'uso fa da motore alle molteplici
realtà che affiorano nella scuola italiana dimostrando la superiorità e i vantaggi dell'utilizzo
del software libero, ma soprattutto l'interesse e la sensibilità alle tematiche dell'ottimizzazione
dei costi, della partecipazione e della libertà. Esempio di pianificazione per una progressiva
digitalizzazione della scuola e dell'introduzione del software libero che muove da questa idea
di nuova economia è il progetto articolato e attuato dal Comune di Pisa, volto a creare un
sistema coerente di strumenti da dedicare ad alunni e alunne per favorire la rivoluzione
tecnologica del sistema scolastico. Il progetto nasce da un preciso intento, chiaramente
leggibile dall'istituzione nella più recente legislatura di una delega per la promozione delle
tecnologie digitali per la formazione. La definizione del progetto è stata condotta
dall'Amministrazione Comunale costituendo un team70 di persone addette ai lavori ed esperte
del settore, convinte del valore della tecnologia e del software libero come strumenti per la
qualità degli istituti scolastici in condizioni di carenza di infrastrutture.
Il team ha definito una road-map contenente i punti principali del piano di azione volto a
trasformare la criticità della situazione scolastica del territorio, che vedeva più della metà dei
64 plessi scolastici privi persino di una connessione internet. Il piano d'azione è stato
articolato nei seguenti punti: (1) la copertura del deficit infrastrutturale che affligge gli
istituti, con soluzioni di immediato termine quali connessioni ADSL uniformate su tutti i
plessi e la soluzione di più lungo termine di utilizzare le Scuole, tra tutti i possibili edifici
pubblici, come nodi della cablatura a banda larga prevista nel programma di mandato per la
legislatura, nel settore e assessorato all'e-government; (2) ammodernare il parco-macchine
(hardware e software) delle scuole dove possibile secondo criteri di economicità,
ottimizzazione delle risorse e sostenibilità ambientale; (3) adeguare la formazione di docenti
e personale tecnico-amministrativo all'uso dei nuovi strumenti; (4) realizzare le azioni (1)-(3)
predisponendo strumenti utili a gestire i rischi della rivoluzione digitale, potenziando la
formazione alla libertà di connessioni e contenuti secondo l'etica della responsabilità. Il
metodo di lavoro previsto nel piano rimane centrato sulla partecipazione e la sussidiarietà
orizzontale come elementi di qualità e opportunità. La road-map, approvata in Giunta
comunale, presenta una serie di progetti strettamente legati tra loro che vedono la
collaborazione di Enti pubblici e soggetti privati, ai fini di privilegiare la libera
partecipazione e il mutuo sostegno delle iniziative, in un'ottica di partecipazione dell'intera
collettività cittadina. Il progetto, nella sua interezza e nel suo carattere di programmazione a
lungo termine, ha l'obiettivo di coprire in maniera multidisciplinare un innovativo approccio
di chi vive la scuola con la tecnologia e, per tanto, di innovare il sistema didattico in linea con
i principi emanati dal Piano E-government 2012.
Condotto dall'Assessora Maria Luisa Chiofalo, ne hanno fatto parte persone fortemente impegnate nel tema dei saperi liberi e aperti, come la professoressa Flavia Marzano, esperta di software libero e stratega per la Pubblica Amministrazione, l'Ing.Giovanni Cignoni, docente presso il Dipartimento di Informatica dell'Università di Pisa, il Presidente dell'associazione GULP (Gruppo Utenti Linux Pisa), il Dr. Paolo Mascellani, il Professore Luca Randazzo, maestro della Scuola Primaria "Don Milani" del Comune di Pisa.
70
Pagina 30
1.2.2 Aule informatiche a costo zero
Il progetto relativo all'azione (2) prende forma a partire dall'esperienza della scuola
elementare Don Milani (Istituto Comprensivo Gamerra) di Pisa, dove un docente esperto in
software libero, Luca Randazzo, per risolvere le carenze infrastrutturali e in mancanza di
fondi, ha dato vita ad un progetto di sostenibilità, cooperazione e partecipazione. L'idea
semplice e rivoluzionaria è quella cara al Mauss 71 dell'economia del dono e prevede la
possibilità che chiunque lo desideri possa donare alla scuola il proprio pc, magari quello
vecchio o inutilizzato, contribuendo così a creare postazioni informatiche dedicate. Docenti,
genitori, amici e sostenitori hanno aderito con entusiasmo all'iniziativa, pubblicizzata dal solo
passaparola, scegliendo di riciclare i propri personal computer e donarli alla scuola. I
computer ricevuti, controllati e resi funzionali alle necessità della scuola dallo stesso docente,
sono stati quindi dotati delle più elementari applicazioni di software libero. Ecco dunque la
prima aula informatica a costo zero o, meglio, al costo di hardware, software e competenze
rese disponibili da chiunque ne abbia avuto la possiblità e abbia deciso di contribuire.
Nello spirito della condivisione di esperienze, il team ha dunque deciso di disseminare e
rendere stabile l'esperienza della scuola elementare Don Milani. In una prima fase è stato
definito uno standard minimo di hardware (pc, stampanti e altro). In una seconda fase Enti
pubblici e Aziende presenti sul territorio insieme ai e alle rappresentanti dei genitori sono
stati informati dell'esistenza del progetto e a loro il Comune si è rivolto chiedendo di valutare
la disponibilità a contribuire attraverso la donazione di hardware e ogni altra competenza da
mettere in condivisione. L'Istituto Informatica e Telematica del CNR, la Scuola Superiore
Sant'Anna, Vodafone Italia e l'agenzia formativa Formatica, realizzatrice del nuovo portale
delle Scuole del Comune di Pisa, hanno aderito con entusiasmo al progetto e partecipato in
maniera consistente attraverso la donazione di propri computer in fase di smantellamento,
conformi alle caratteristiche minime specificate, in alcuni casi offrendo anche hardware con
Linux già installato. L'idea del riciclo dei computer e degli apparati hardware risolve il
problema delle dotazioni strumentali scolastiche garantendo al contempo la autosostenibilità
nel tempo del progetto grazie alla donazione periodica e ripetibile delle macchine. In secondo
luogo questa forma di riuso attenua il problema dello smaltimento dei rifiuti e dello
sfruttamento del materiale fino al suo completo esaurimento del ciclo di vita, promuovendo la
filosofia della sostenibilità ambientale. Terzo, Enti e Aziende necessitano di apparecchiature
sempre nuove e costantemente aggiornate con le tecnologie emergenti, e dunque si trovano
comunque a sostituire spesso le proprie macchine, che – per quanto obsolete per le proprie
funzioni - sono perfettamente funzionanti e in alcuni casi sovradimensionate per le funzioni
scolastiche.
In una terza fase è stato effettuato il controllo tecnico e la predisposizione delle macchine
donate a cura degli Uffici tecnici del Comune di Pisa, per operare la distribuzione. D'accordo
con le Direzioni Scolastiche, il processo di riuso è stato concentrato inizialmente sugli Istituti
in stato di maggiore necessità, con l'intenzione di andare a coprire a rotazione nel corso di
circa due anni la totalità degli istituti del territorio pisano. In modo analogo si è proceduto per
l'installazione del software: gli Istituti dotati di competenze interne adeguate hanno proceduto
autonomamente, consentendo di destinare le competenze messe a disposizione su base
volontaria dall'associazione GULP a quegli Istituti non ancora del tutto autonomi. La
condizione di utilizzo dell'hardware donato è stata categoricamente fissata nell'installazione
71
Marcel Mauss, Saggio sul dono, 1925.
Pagina 31
di software libero, accompagnando quando necessario il cambiamento. D'altra parte le Scuole
vivono continue condizioni di emergenza, e dunque per il processo di introduzione del
software libero negli uffici amministrativi, dove i programmi di inserimento dati e di gestione
provenienti dal Ministero sono tutti proprietari, si è invece lasciata la decisione alle Direzioni
Scolastiche, sensibilizzando semplicemente l'uso di software di videoscrittura e navigazione
non proprietari. Nel primo ciclo di distribuzione sono state realizzate quattro aule
informatiche a costo zero, con dieci pc l'una in quattro dei sette Istituti Comprensivi della
Città.
Parallelamente, in accordo con l'azione (3) è stata avviata la necessaria fase di divulgazione
delle competenze e delle abilità nei soggetti designati ad interagire con le macchine e con le
nuove applicazioni libere, a partire dal corpo docente. T-OSSLab, il centro di competenza per
l'open source in Toscana, in collaborazione con lo stesso GULP, ha condotto corsi di
formazione nelle diverse scuole del territorio sottolineando la semplicità di utilizzo di
programmi. Oltre all'insegnamento del pacchetto OpenOffice con le sue potenzialità e di
Mozilla, i corsi di formazione sono stati focalizzati su una serie di software didattici tra cui il
divertente Phun, un freeware che grazie ad una grafica semplice ed intuitiva avvicina i più
piccoli alla fisica, aiutandone l'insegnamento in chiave di gioco.
1.2.3 Il portale delle scuole
Il Comune di Pisa ha parallelamente creato un'asse unitario di informazione e conoscenza
ideando un portale unico dedicato alle scuole pisane (http://scuole.pisa.it/) che permette la
navigazione in tutti gli Istituti della città e l'accesso ad una serie di informazioni
indispensabili ad alunni, alunne e genitori. Navigando nel portale è possibile accedere ad
informazioni di ogni sorta ma in formato omogeneo circa gli Istituti, i piani didattici e gli
orari dei ricevimenti Il portale è stato pensato non solo come luogo di raccolta di dati e
informazione ma anche come strumento di discussione e confronto: è stata infatti creata
un'area blog in cui scambiare informazioni e commenti ed un'area wiki in cui la gestione dei
contenuti può essere totalmente partecipativa e interattiva. In questo quadro si va a delineare
un sistema culturale e scolastico dedito alla libertà dei contenuti, in cui la partecipazione è la
chiave di svolta, e la comunicazione si arricchisce della collaborazione e della condivisione
delle idee.
1.2.4 Smart School
Il processo di dotazione infrastrutturale previsto dall'azione (1) passa attraverso uno
straordinario progetto finanziato dalla Regione Toscana e denominato Smart School. Smart
School introduce le più recenti innovazioni tecnologiche come protagoniste delle lezioni
scolastiche e apre lo scenario a nuovi metodi didattici. La tradizionale lavagna viene sostituita
da nuove lavagne multimediali interattive che, collegate ad una postazione pc e ad un
proiettore, rivoluzionano la struttura delle lezioni, permettendo di proiettare qualsiasi
materiale di supporto delle lezioni in qualunque formato digitale, di costruire in modo
cooperativo la conoscenza ogni volta in modo diverso secondo le diverse risorse mentali e le
diverse abilità di studenti e di docenti presenti in quel momento in quell'aula, di condividere
l'intera esperienza di apprendimento e l'archiviazione delle "lezioni", rendendole accessibili
anche oltre l'orario scolastico e a distanza. Il progetto così strutturato rappresenta il primo
passo verso il più ampio proposito di fornire un notebook dalle funzioni basilari ad ogni
Pagina 32
alunno e alunna. Attraverso questo alunni e alunne possono interagire in maniera interattiva e
partecipativa con la lavagna interattiva multimediale durante le lezioni, anche rimanendo
comodamente seduti al proprio banco, e possono svolgere compiti studiando su libri di testo,
che, nel frattempo, potranno avere assunto la forma di e-book, libri digitali dematerializzati e
leggeri.
Parte cruciale del pacchetto Smart School è stata la connettività: attraverso una
ottimizzazione di risorse e secondo quanto previsto dall'azione (1), l'ingresso di Smart School
nelle scuole pisane ha consentito il completamento della connessione internet in tutti i 64
plessi scolastici della Città, nell'immediato via ADSL mentre il progetto di banda larga del
Comune di Pisa prosegue il suo corso nel lungo termine.
La principale opportunità data da questa moderna strumentazione di insegnamento è l'alto
grado di interattività, che permette di condividere le lezioni, stimolando l'interesse e lo
scambio di idee, e di far partecipare alle lezioni anche quegli alunni che si trovano
momentaneamente impossibilitati a frequentare la propria scuola.
1.2.5 Smart Inclusion
Il progetto Smart Inclusion è dedicato infatti ai bambini e alle bambine che devono sostenere
lunghi periodi di degenza in ospedale. Grazie all'installazione di un terminale touch screen
dotato di webcam e microfono per interagire con la lavagna elettronica, la Regione e
l'Ospedale Santa Chiara di Pisa hanno costruito un ponte con le scuole del territorio
permettendo a bambini e bambine degenti di partecipare in maniera attiva alle lezioni in real
time collegandosi in remoto come se fossero nella propria classe, oltre all'accesso all'archivio
delle lezioni. La scolarizzazione rappresenta un diritto fondamentale per tutti i bambini e
tutte le bambine ed è un potente mezzo di inclusione sociale anche in condizioni ordinarie: in
questa chiave risulta potenziata la fondamentale funzione sociale della scuola, che aiuta il
bambino o la bambina ricoverata in ospedale a sentirsi vicina alla propria dimensione
affettiva, elemento necessario al sostegno psicologico nel percorso di ospedalizzazione.
La dotazione tecnologica oltre a supportare il piano di e-school è di fondamentale importanza
come strumento di intrattenimento, la macchina permette infatti la connessione a Internet e a
un canale video on demand dedicato ai più piccoli, e rappresenta inoltre un utile strumento
ospedaliero, permettendo il controllo via web cam del piccolo o della piccola paziente. La
postazione Smart Inclusion è stata localizzata nella stessa Scuola Primaria – l'Istituto
Comprensivo Toniolo, nel quale il Comune ha inserito – d'accordo con le Direzioni
Scolastiche – la programmazione di una sezione ospedaliera nella rete scolastica.
1.2.6 Il Progetto Troll
La profonda utilità di Internet e della tecnologia in generale si ferma laddove questi mezzi
rappresentano, oltre ad un magazzino inesauribile di informazioni, un pericolo per quanti,
navigatori incauti, si debbano confrontare con contenuti pericolosi. È necessario e doveroso
proteggere i più piccoli e le più piccole dalle insidie del Web, saturo di pericoli, insegnando
tuttavia loro a sfruttare le potenzialità di Internet soprattutto nell'ambito della ricerca e dello
studio. La Rete è infatti il luogo dedicato alla diffusione della conoscenza e, come tale, è
importante che sia riconosciuto dagli studenti come strumento primario di informazione e
apprendimento, capace di fondere lo studio e lo svago, la realtà e il gioco. Con lo scopo di
Pagina 33
permettere la navigazione sicura proprio ai bambini che vi si avvicinano con ingenuità, nasce
il portale TROOL, ideato dalla Regione Toscana e realizzato dall'Istituto degli Innocenti di
Firenze, che, grazie al sistema di filtraggio e alla gestione dei contenuti, garantisce un uso
protetto del Web.
Il concetto di TROOL è semplice: ogni smisurata libertà e potenzialità di azione richiede un
livello almeno pari di etica della responsabilità. Ecco dunque che a navigare sicuri si impara
conoscendo le regole e i rischi, come ad andare a scuola da soli si impara conoscendo il
codice della strada e i pericoli. L'idea che la sicurezza possa essere il risultato di una
alienazione degli spazi viene sostituita dall'idea, altrettanto semplice ma rivoluzionaria, che la
sicurezza sia il risultato di una “occupazione” degli spazi. In questo caso quelli telematici e
virtuali. Il portale TROOL è stato creato dall'Istituto degl'Innocenti per essere accessibile
dalle postazioni informatiche delle scuole e per diventare oggetto di vere e proprie ore di
insegnamento didattico.
Accogliendo la proposta dell'Istituto degli Innocenti, il Comune ha attuato un'azione di
sensibilizzazione affinché nel piano scolastico dell'offerta formativa sia prevista la possibilità
che alle ore di italiano e matematica si affianchino laboratori di TROOL, con lo scopo di
avvicinare i più piccoli al computer e di insegnare loro l'importanza di Internet come supporto
allo studio e mezzo di continuo apprendimento. Il piano di studio comprende l'insegnamento
dei più elementari e indispensabili programmi per l'elaborazione del contenuti, l'uso di blog e
wikis, e lo studio del Web come fonte di svago ma anche come metodologia di studio che
può e deve servire a coadiuvare trasversalmente tutte le materie, superando la concezione
anacronistica di un Internet che rallenta e distrae gli alunni nello svolgimento dei programmi
ministeriali.
Il Comune di Pisa, con l'implementazione e la promozione di questi progetti tra loro integrati,
ha creato un prototipo ben definito di piano d' azione, emulabile e riutilizzabile in altre realtà.
L'innovazione tecnologica nella scuola viene promossa come strumento particolarmente
efficace a realizzare l'obiettivo primario dell'unica economia sostenibile, quella fondata sullo
sviluppo delle capacità umane con la valorizzazione delle diverse abilità di ogni individuo a
partire dai più piccoli, e sullo sviluppo delle abilità sociali. Per questo sono stati combinati
valori etici con risorse umane e strumentali, fondendo il progresso con un'attenzione per
l'ambiente (aule informatiche a costo zero), la sicurezza attraverso l'etica della responsabilità
(portale scuole e Trool) e la solidarietà (Smart Inclusion). Il tutto secondo criteri di
economicità, sussidiarietà e sostenibilità nel tempo.
Bibliografia
Cignoni G.A., Randazzo L. (2009) Recupero di PC per le scuole
http://www.tosslab.it/documentazioneeventi/recupero-pc
Cignoni G.A, Santi A., Ghilardi M, Stilli G. (2009) Applicazioni libere nelle scuole
http://www.tosslab.it/documentazioneeventi/applicazioni-libere-nelle-scuole
Cignoni G.A (2009) Oltre lo scrivitore
Pagina 34
http://www.tosslab.it/documentazioneeventi/osscuole-cignoni
Ferri P. (2008) La scuola digitale. Come le nuove tecnologie cambiano la formazione,
Mondadori
Grimaldi R. (2006) Disuguaglianze digitali nella scuola. Gli usi didattici delle tecnologie
dell'informazione e della comunicazione in Piemonte, Franco Angeli
Mauss M.(1954) The Gift, Cohen & West
Randazzo L. (200..) Migrazione fai da te
http://www.tosslab.it/documentazioneeventi/osscuole-randazzo
Pagina 35
PA E SOFTWARE A CODICE SORGENTE APERTO: IL
DIFFICILE CONNUBIO TRA FLOSS, RIUSO E
CONCORRENZA.
Gianluca Craia, noze S.r.l. (ufficio legale), via Giuntini 25/29, Navacchio – Cascina
(PI), gianluca.craia@noze.it
Abstract Il concetto di open source, e più in generale quello di software libero (nel prosieguo per
comodità FLOSS), rappresenta una problematica strettamente giuridica slegata da ogni
possibile riferimento ad una determinata tecnologia ad un marchio o ad un prodotto.
Ove si prendano FLOSS e software proprietario come i due paradigmi intorno ai quali viene
costruito il mondo delle nuove tecnologie, è facile notare che essi si distinguono in ragione
del differente contenuto dell'accordo negoziale che detta la loro disciplina: la licenza.
E' proprio la licenza che regola la circolazione giuridica di tali beni e, grazie agli istituti
relativi alla normativa sul diritto d'autore, indica sia le operazioni possibili sul codice
sorgente sia la disciplina delle opere derivate.
La famiglia delle licenze FLOSS, al contrario del modello proprietario, garantisce ai
licenziatari la facoltà di accedere al codice sorgente, eseguire il programma, copiarlo,
modificarlo e distribuirlo (di norma) senza alcun costo.
Queste caratteristiche hanno reso possibile il crearsi di molteplici modelli di business, di
particolare interesse per le PMI, grazie a due significative caratteristiche: l'assenza di costi
di licenza e la facoltà di sviluppare, ogni volta, un prodotto potenzialmente nuovo, dotato di
creatività ed originalità, esattamente “cucito” sulle esigenze dell'utilizzatore.
Le stesse caratteristiche di cui sopra rendono il FLOSS un modello di particolare interesse
anche per le PA, le quali, acquisendo e utilizzando software rilasciato "open source"
possono perseguire, a loro volta, due obiettivi fondamentali: abbattere i costi di acquisizione
e svincolarsi dal fornitore.
Se quanto detto finora indica i pregi del modello, l'attuale normativa, in particolare il
"Codice dell'Amministrazione Digitale" (CAD), pone significative problematiche
interpretative che possono scoraggiare la PA virtuosa dall'acquisizione di software FLOSS.
Sorgono diversi dubbi sia relativamente alla titolarità del software realizzato per conto e
spese della pubblica amministrazione sia relativamente all'affiancamento del FLOSS
all'istituto del riuso, modelli che, benchè ad una prima analisi appaiano omologhi in quanto
a finalità, posto che basano la loro essenza sulla condivisione e la diffusione della
conoscenza, sono disciplinati da una normativa disarmonica che rischia di compromettere la
loro compatibilità e frustrare il loro ruolo in favore di svantaggiose politiche di acquisizione
di software proprietario.
Oltre a quanto sopra l'interesse sempre più marcato delle istituzioni regionali e locali al
fenomeno, ha spinto molte Regioni a provvedere ad un normativa di settore che, muovendo
dalle previsioni del CAD affermi e promuova il FLOSS come modello non solo alternativo
Pagina 36
ma più adeguato alle esigenze dell'amministrazione rispetto al software proprietario,
sollevando rilevanti problematiche di legittimità costituzionale.
La partita si è quindi spostata dal piano tecnico ed economico a quello politico e normativo.
Nonostante gli indubbi vantaggi in termini di efficienza, efficacia ed economocità dell'agire
amministrativo, l'insieme di queste problematiche, strettamente giuridiche, delinea un
quadro complesso che rende incerto per la PA e per le imprese l'utilizzo, l'adozione e la
promozione del FLOSS come modello preferenziale per l'informatizzazione della Pubblica
Amministrazione italiana.
Parole chiave: floss, appalti pubblici, riuso, concorrenza, proprieta' intellettuale
1 LA PA E L'ACQUISIZIONE DI FLOSS: IL CONTESTO
NORMATIVO
Secondo le previsioni del D.Lgs. n. 39/1993 (coerentemente con quanto stabilito dalla legge
sul diritto d’autore all’art. 11), le applicazioni software realizzate per conto e a spese della
pubblica amministrazione sono di titolarità della stessa.
Negli ultimi anni le PA hanno sviluppato un forte interesse all'acquisizione di sistemi
software che consentano di offrire servizi migliori ai cittadini, in questo contesto il software
libero e open source sta giocando, senza alcun dubbio, un ruolo di rilievo.
Questa categoria di applicazioni, caratterizzata da licenze che concedono ai terzi i diritti di
accedere al codice sorgente del programma, copiarlo, modificarlo e distribuirlo senza che (di
norma) sia imposto alcun costo, appare immediatamente in contrasto con la normativa di
riferimento indicata in apertura.
Infatti l’utilizzo dietro licenza di elementi open source di titolarità di terzi, impedisce la
nascita del diritto d'autore in capo all’Amministrazione, posto che mancando all'appaltatore la
proprietà dell'opera originaria sarebbe possibile solo la sub-concessione in licenza, non certo
una cessione di diritti e quindi, tanto meno, la nascita del diritto a titolo originario.
A complicare ulteriormente il quadro normativo, e` intervenuto il più recente Codice
dell’Amministrazione Digitale (D.Lgs. n. 82/2005).
Il legislatore, benché avesse l’occasione di rivedere la normativa, riducendo ad unita` le
esperienze ed intervenendo direttamente sul tema, ha preferito limitarsi a prendere atto
dell’esistente.
Così l’art. 68 del Codice si risolve in una mera elencazione delle modalità con le quali è
possibile, per la P.A., dotarsi di programmi per elaboratore, esse sono: a) lo sviluppo di
programmi informatici per conto e a spese dell’amministrazione sulla scorta dei requisiti
indicati dalla stessa amministrazione committente; b) il riuso di programmi informatici
sviluppati per conto e a spese della medesima o di altre amministrazioni; c) l’acquisizione di
programmi informatici di tipo proprietario mediante ricorso a licenza d’uso; d) l’acquisizione
di programmi informatici a codice sorgente aperto; e) l’acquisizione mediante combinazione
delle soluzioni precedenti.
Pagina 37
Sulla base di tale elenco, la singola Amministrazione, a valle di un’analisi comparativa delle
soluzioni disponibili sul mercato in relazione alle proprie esigenze, dovrebbe scegliere la
migliore applicazione in termini di funzionalità, prestazioni e facilità d’utilizzo.
Il legislatore non ha pero` considerato che, con il sistema delineato, la valutazione
comparativa che la P.A. e` chiamata a svolgere ha natura, prima ancora che tecnica, giuridica.
Essa si fonda necessariamente sugli istituti che disciplinano l’applicazione informatica e, in
particolare, sui concetti di titolarità, cessione dei diritti di utilizzazione economica e/o loro
concessione in licenza d’uso.
Per cercare di mettere ordine tra le previsioni normative applicabili, pare necessario
considerare adeguatamente, l’istituto della titolarità delle opere dell’ingegno di carattere
creativo in caso di committenza pubblica.
La norma di riferimento deve senza dubbio essere individuata nell’art. 11 L. n. 633/1941 che
prescrive la nascita della titolarità dell'opera dell'ingegno in capo al committente pubblico.
Non vi è dubbio che nel caso di acquisizione di software da parte della PA gli appaltatori
realizzino un'opera dell'ingegno protetta ai sensi della legge sul diritto d'autore.
Nel particolare caso della realizzazione di software open source, l'appaltatore sviluppa
l'applicazione richiesta dalla PA per elaborazione, partendo da linee di codice sorgente e, in
molti casi, da veri e propri moduli software realizzati da terzi, dei quali può disporre in virtù
di una licenza FLOSS.
E` evidente che in questo caso la problematica della nascita della titolarità di quanto creato in
capo al committente pubblico e` insuperabile con una semplice previsione contrattuale:
l’appaltatore non può ricoprire la posizione soggettiva di titolare dei diritti di utilizzazione
economica dell'opera originaria.
Essendo un mero licenziatario egli potrebbe, tutt’al più, trasferire in licenza quanto ricevuto
ma non certo cederne i diritti a titolo definitivo ( come spesso viene richiesto nei bandi di
gara) e quindi tanto meno, spogliarsi della qualità di autore in favore della pubblica
ammnistrazione secondo quanto previsto dalla normativa.
2 LA DIFFICILE CONVIVENZA TRA OPEN SOURCE E RIUSO
Se tale é la problematica generale, in una prospettiva piu` specifica, essa assume particolare
interesse, in ragione della previsione di cui all’art. 69 D.Lgs. n. 82/2005, con riferimento
all’istituto, di recente introduzione, del riuso di software.
Prima del 2000 non esisteva nell’ordinamento una nozione giuridica di riuso, perciò la sua
definizione postula il riferimento ad elementi extragiuridici.
Per riuso deve intendersi la possibilità di utilizzare un modulo o comunque una componente
software in una o piu` applicazioni informatiche diverse.
Mutuando tale concetto dall’ingegneria del software, l’istituto del riuso trovava la sua prima
espressione normativa con la legge n. 340/2000, la quale stabiliva che le P.A. potessero
concedere in uso gratuito ad altre amministrazioni le applicazioni informatiche nella loro
disponibilità, affinchè queste ultime le adattassero alle loro esigenze.
Pagina 38
Da sottolineare che, con la predetta normativa, la concessione in uso gratuito ad altre
Amministrazioni era solo un’opzione possibile, quindi un’indicazione del legislatore per
indirizzare l’azione amministrativa.
Solo con la successiva “direttiva Stanca” del 19 dicembre 2003, dopo essersi ribadito, all’art.
5, l’acquisizione della titolarità delle applicazioni informatiche in capo all’amministrazione
appaltante, si ha la prima norma che stabilisca un obbligo per la P.A. di prevedere clausole
che favoriscano il riuso e concedere in licenza l'applicazione ad amministrazioni terze che la
richiedano.
La normativa contenuta nella direttiva è stata poi la struttura portante della successiva
disciplina prevista nel Codice dell’Amministrazione Digitale.
Il CAD, dopo aver individuato all’art. 67 le modalità di sviluppo e acquisizione di
applicazioni informatiche e aver imposto con l’art. 68 la valutazione comparativa delle
soluzioni da acquisire, disciplina all’art. 69 il “Riuso di programmi informatici”.
Con l'odierna previsione la Pubblica Amministrazione, ove richiesta, deve acconsentire a
concedere in riuso i software di cui si e` dotata e, posto che l’istituto richiede la titolarità in
capo all’amministrazione concedente, e`necessario che essa abbia acquisito, o comunque in
capo a essa sia nata, non la facoltà di fruire del software, come avviene in caso di
acquisizione di licenze, bensì la titolarità piena dei diritti di utilizzazione economica sul
programma.
Ciò considerato, ove manchi la titolarità, il software non potrà essere “riusabile” nel senso
richiesto dalla normativa.
Una parte della dottrina si confronta con tali problematiche rilevando che ciò che è
effettivamente richiesto dalla norma non è la titolarità, ma la disponibilità del codice sorgente
secondo quanto indicato al comma 3 dell’art. 69.
Una simile impostazione risolverebbe molte controverse questioni posto che, ogniqualvolta la
P.A. possa accedere al codice sorgente, ne acquisirebbe la disponibilità .
In sostanza in tutti i casi in cui il software sia open source ovvero, qualora sia proprietario,
nel caso in cui sia inserita una clausola che preveda l’accesso al codice sorgente, la P.A. può
disporre dell’applicazione e renderla di fatto « riusabile ».
Tale lettura del problema non pare però tenere in considerazione che la disponibilità del
codice sorgente è condizione necessaria ma non sufficiente perché possa operare l’istituto del
riuso.
Il requisito richiesto dal legislatore (non solo attraverso l’art. 69 CAD, ma alla luce
dell’intero impianto normativo) e', e rimane, la titolarità, requisito che contiene in sè la
disponibilità del codice .
Tale assunto si basa sul fatto che la legge sul diritto d’autore, agli artt. 64-bis e ss., riserva
l’esercizio dei diritti di utilizzazione economica relativi al software al titolare di essi.
Da ciò consegue che la disponibilità dei programmi ai fini del riuso, portando con sè la
necessità di copiare, redistribuire e, se necessario, modificare il programma, non può che
presupporre tale titolarità che in caso di software open source parrebbe non potersi costituire
in capo all'ente pubblico.
Pagina 39
In questo senso il combinato disposto dell'art 11 l. 633/1941 con il D.Lgs 39/1993 parrebbe
escludere la compatibilità tra open source e software sviluppato ad hoc per le pubbliche
amministrazioni.
3 LA TITOLARITÀ DELLE OPERE DERIVATE IN CASO DI
APPALTO PUBBLICO
Per proporre una soluzione cercando di rimanere aderenti al dato normativo, potrebbe
richiamarsi la disciplina delle elaborazioni creative di cui all’art. 4 della legge 631/1940.
Di fatto, quando l’amministrazione richiede un’applicazione per soddisfare sue peculiari
esigenze, domanda all’appaltatore di realizzare, sulla base di un’opera originale, una nuova
applicazione adattata ad un particolare ambiente informatico della PA richiedente.
La prospettiva di osservazione in questo caso cambia radicalmente, la domanda da porsi non
è più se possa nascere o meno la titolarità della pubblica amministrazione, ma su che cosa è
richiesto che nasca la titolarità della pubblica amministrazione.
Al fine di risolvere la problematica esposta, preliminarmente risulta necessario analizzare in
termini generali la tematica della titolarità delle opere derivate nel caso di utilizzo di software
open sorce.
La tutela della proprietà intellettuale mette in gioco, in ordine alle modifiche del prodotto e/o
alle singole componenti dell’opera derivata, la possibilità, evidenziata da una parte della
dottrina, che si configurino forme di appartenenza collettiva: a fronte del contributo di una
collettività di sviluppatori, che sottostanno alle regole imposte dall’adesione a licenze
copyleft, si creerebbe una situazione di comunione o, piu` ampiamente, di contitolarita` dei
diritti d’autore sul software.
Sorgerebbero quindi nuovi elementi da analizzare al fine di stabilire la titolarità: forme
organizzative e gerarchiche di natura informale e accanto ad esse forme associative
formalizzate (ad es. fondazioni, come per Mozilla e OpenOffice « ...a hybrid of anarchistic
and hierarchical governance... ), in una parola le community.
Esse, formalizzate o meno, costituite da un insieme di sviluppatori che realizzano un progetto
software autorganizzandosi e basandosi sulle tecniche di sviluppo e le facoltà offerte dalla
licenza, si pongono come soggetto in favore del quale i singoli componenti si spogliano dei
loro diritti sul codice, tanto che di fatto esse stesse provvedono a governare il progetto, in
quanto soggetto, sebbene non di diritto, costituito al fine della realizzazione di un applicativo
stabile e fruibile dagli utenti.
In tali casi una volta venuto ad esistenza, il progetto non potrà che essere riferibile a tutti
coloro che alla community hanno partecipato e non vi è dubbio che la titolarità di esso
nascerà, in modo diffuso, in capo a tutti i soggetti che hanno contribuito alla realizzazione
con il loro apporto creativo ed originale (coerentemente con quanto prescritto dall’art. 10
della l. n. 633/1941).
La tesi risulta senza dubbio suggestiva nel momento in cui muove dall’intuizione che il
FLOSS si contraddistingue per la peculiarità dei suoi modelli istituzionali, ossia: le licenze, le
norme sul diritto d’autore e le forme associative tra privati (spontanee o formalizzate).
Pagina 40
L’intreccio di tali strumenti, che reggerebbero i pur eterogenei fenomeni dell’open source e
del free software, determinerebbe la creazione di un regime atipico di appartenenza collettiva
fondato sul ricorso congiunto alla tutela degli intellectual property rights ed al contratto.
Il modello istituzionale di sviluppo attraverso la community, cui si ispira tale ricostruzione,
ha il merito di interpretare compiutamente il momento genetico di un progetto open source,
ma non pare poter essere esteso all'interpretazione del suo divenire.
Gli appartenenti alla community infatti pongono in essere atti creativi che danno vita, in
combinazione tra loro, alla creazione di un software open source ma, una volta che
quest’ultimo è stato realizzato, gli interventi successivi sono spesso mere correzioni di
anomalie o ottimizzazioni prive di un apporto creativo tale da porre il problema della
titolarità.
L’idea di un’appartenenza collettiva in particolare, non si presta ad essere applicata al caso
delle opere derivate (qualora, in un momento successivo alla realizzazione del software, il
codice sorgente venga modificato o integrato con nuovi moduli in modo da creare un nuovo
prodotto basato sull’opera originaria).
In tal caso infatti mancando la contestualità (intesa non nel senso di contemporaneità, quanto
di appartenenza allo stesso contesto informatico) degli atti creativi e la condivisione della
finalita`con gli autori originari, appare difficile sostenere una contitolarita` dei diritti sul
software: l’opera derivata infatti in questi casi si distingue da quella originaria.
In questi casi di nuove implementazioni, in presenza di un’attività creativa e originale, può
sostenersi che venga ad esistenza un’opera protetta con autonoma titolarità in capo ad nuovo
autore.
Questa posizione è avallata anche da una recente giurisprudenza della Cassazione (Cass. Civ.
581/2007).
In tale ultima pronuncia la Suprema Corte ha enunciato il principio secondo cui “ ...creativita`
e originalita` sussistono anche quando l’opera sia composta da idee e nozioni semplici...
comprese nel patrimonio di persone aventi esperienza nella materia propria dell’opera stessa,
purchè esse siano formulate e organizzate in modo autonomo e personale rispetto alle
precedenti”
La Corte, mutuando tale principio di diritto da un orientamento giurisprudenziale ormai
consolidato in tema di originalità e creatività, va però oltre affermando che, per il software,
l’innovazione e, quindi, l’originalità e la creatività dell’opera risiedono nell’adattare
l’architettura applicativa al caso e all’ambiente tecnologico specifico.
Applicando questo principio di diritto al caso di acquisizione di software da parte della PA, e
possibile osservare come nella generalità dei casi di committenza pubblica si abbia una
realizzazione che nella pratica si sostanzia in un adattamento di codice rilasciato open source
ad un nuovo e diverso contesto informatico e tecnologico.
Se ciò è vero parrebbe corretto affermare che ogni volta in cui l'appaltatore va a creare un
quid novi sul quale, in virtù dei principi richiamati, possa nascere un'autonoma titolarità, per
gli effetti del d.lgs. 39/993 e degli artt. 4 e 11 della legge 633/1941, essa spetta alla PA
committente.
Pagina 41
4 FLOSS, SOFTWARE PROPRIETARIO E CONCORRENZA
Se le problematiche di proprietà intellettuale legate al FLOSS e alla sua acquisizione da parte
della PA, come evidenziato, sono molte e di difficle soluzione, non meno rilevanti sono
quelle legate alla concorrenza e in particolare al dualismo software proprietario - software a
codice sorgente aperto.
Non vi è dubbio infatti che oggi il mercato del software viva questa dialettica in cui, da un
lato il regime proprietario ha creato un sostanziale monopolio legale della conoscenza, che
tendenzialmente determina un innalzamento dei prezzi ed una riduzione dell’offerta,
dall’altro il movimento del FLOSS propone un modello alternativo basato sulla condivisione
della conoscenza stessa quale motore del progresso.
Pure non vi è dubbio che il software rilasciato con modello proprietario abbia negli anni
acquisito una posizione di dominanza del mercato rispetto al software open source. Salvo
alcune nicchie, il software proprietario è infatti più diffuso, conosciuto e utilizzato. Certo è
che il FLOSS presenta vantaggi rilevanti, grazie proprio a quanto previsto nella sua licenza.
Così è iniziato un percorso di scoperta del nuovo modello.
Per prima l'Unione Europea ha mostrato, e mostra tuttora, un forte interesse al fenomeno, si
veda ad esempio l’ eEurope Action Plan 2005, il recente i2010 Initiative — A single
European Information Space, eGovernment Action Plan i2010 e la Comunicazione su
“Interoperability for pan-European eGovernment Services” nei quali l’utilizzo dell’open
source viene definito fondamentale nell’ottica dello sviluppo dei servizi informatici nell’UE.
Il legislatore italiano invece è rimasto inerte e le regioni, in assenza di normativa nazionale,
hanno deciso di muoversi con autonome iniziative per sfruttare i vantaggi offerti dal FLOSS.
La tendenza è stata quella di aprire maggiormente all'utilizzo del FLOSS mettendolo in aperta
concorrenza con il software proprietario ed anzi esprimendo una sostanziale preferenza per il
modello a codice sorgente aperto come se fossero necessarie delle politiche "proconcorrenziali" .
Si pensi, ad esempio, all’esperienza della Regione Toscana che ha intrapreso un percorso di
introduzione dell’open source nell’amministrazione ed è intervenuta a livello sia legislativo,
con la Legge regionale, 26 gennaio 2004, n. 1 (Promozione dell’amministrazione elettronica
edella società dell’informazione e della conoscenza nel sistema regionale. Disciplina della
Rete telematica regionale toscana), sia di programmazione, con il Programma regionale della
Toscana per lo sviluppo della società della conoscenza e dell’informazione 2007-2010, che,
tra i principi e i criteri guida, indica, nel richiamare quanto previsto nella Legge n. 1/2004, "...
il sostegno e l’utilizzo preferenziale di soluzioni basate su programmi con codice sorgente
aperto, in osservanza del principio di neutralità tecnologica, al fine di abilitare
l’interoperabilità di componenti prodotti da una pluralità di fornitori, di favorirne la
possibilita` di riuso, di ottimizzare le risorse e di garantire la piena conoscenza del processo
di trattamento dei dati...".
Il percorso del legislatore toscano è culminato nella legge regionale n. 59/2009 (Istituzione
del sistema informativo e del sistema statistico regionale. Misure per il coordinamento delle
infrastrutture e dei servizi per lo sviluppo della societa` dell’informazione e della
conoscenza), secondo cui "...per assicurare maggiore economicità alle attività della pubblica
amministrazione e favorire al tempo stesso la concorrenza nel mercato delle soluzioni
Pagina 42
informatiche, nelle procedure di valutazione delle gare pubbliche per l’acquisizione di
programmi informatici costituisce titolo preferenziale l’uso di codici sorgente aperti o di
formati liberi, sulla base di una valutazione di tipo tecnico-economico delle diverse soluzioni
disponibili sul mercato e delle esigenze organizzative..."
Queste espressioni di preferenza, nonostante siano dettate da una coscente valutazione dei
due modelli proprietario ed open, destano non poche perplessità in tema di conflitto di
competenza Stato-Regione in materia di concorrenza e non solo.
Di particolare rilievo sono, ai fini dell'argomento trattato, le considerazioni contenute nella
recente pronuncia della Corte Costituzionale n° 122/2010 relativa all'illegittimità
costituzionale della legge della Regione Piemonte 26 marzo 2009, n. 9 (Norme in materia di
pluralismo informatico, sull’adozione e la diffusione del software libero e sulla portabilità dei
documenti informatici nella pubblica amministrazione).
La Corte al paragrafo 6 analizza la richiesta di declaratoria di illegittimità costituzionale
relativa agli articoli 6 comma 1 e 2, 4 comma 1 e 5 comma 1 nella parte in cui essi prevedono
l’utilizzo, ad opera della Regione, di programmi per elaboratore a sorgente aperto, per la
diffusione di documenti soggetti all’obbligo di pubblicità e l’utilizzo di programmi per
elaboratore a sorgente aperto per il trattamento dei dati personali di quei dati la cui diffusione
a terzi non autorizzati può comportare pregiudizio per la pubblica sicurezza.
La questione era stata sollevata dalle osservazioni della difesa dello Stato la quale aveva fatto
presente che le norme indicate sarebbero costituzionalmente illegittime in quanto “invasive
del principio di concorrenza, come elaborato dalla giurisprudenza della Corte di giustizia
della Comunità europea e recepito nel nostro ordinamento nella materia dei contratti pubblici
con il codice dei contratti.
Sarebbe escluso, infatti, che possa ricondursi nell’ambito delle materie afferenti alla potestà
esclusiva o concorrente delle Regioni il potere di normare in modo autonomo, imponendo
alle amministrazioni locali l’acquisto di software esclusivamente a codice sorgente aperto,
considerando che siffatte disposizioni verrebbero a collidere con quanto disposto dall’ art.
117, secondo comma, lettera e), della Costituzione, ai sensi del quale la materia della “tutela
della concorrenza” rientra nella potestà legislativa esclusiva dello Stato.
Osserva, inoltre la difesa dello Stato che un diverso assetto avrebbe portato ad una
“differenziazione territoriale della disciplina dei vari mercati e settori economici”
determinando una regolamentazione anticoncorrenziale, con conseguenze negative per
l’economia nazionale”
All'analisi della Corte la questione è risultata non fondata posto che con la normativa non
viene imposta alcuna scelta ma l'utilizzo di software libero viene indicato solo come possibile
alternativa.
Deducendo a contrario dalle argomentazioni della Corte, se nella parte analizzata la legge
della Regione Piemonte ha superato il vaglio di costituzionalità, qualche dubbio in più
dovrebbe permanere per quelle disposizoni normative (come quelle contenute nella Legge
Regione Toscana 59/2009 citata) che individuano nell'open source titolo preferenziale per
l'aggiudicazione dell'appalto o che attribuiscono punteggi superiori ovvero che richiedono
una motivazione nel caso in cui l'amministrazione non acquisisca software con licenza
FLOSS.
Pagina 43
Ad una prima analisi infatti la valutazione di preferenza che viene assegnata ai formati a
codice sorgente aperto sembra introdurre un criterio di tipo normativo e non tecnico, essa
pare quindi andare oltre la previsione neutra dell'art. 68, comma 1 e in contrasto anche con
l'art. 4 comma 3 del Codice Dei Contratti pubblici relativamente ai criteri di aggiudicazione.
Se infatti la stessa Corte ribadisce che la scelta di uno dei due modelli non riguarda la
tecnologia ma il tipo contrattuale e, in questo senso, è demandata all'utente, quest'ultimo
dovrebbe essere messo in condizione di svolgere una comparazione strettamente tecnica ed
economica delle soluzioni offerte sulla base di criteri neutri, senza essere costretto a fare
riferimento ad un criterio estraneo (il tipo di licenza), o diriga, la sua possibilità di scelta e
incida negativamente, in questo caso sì, sulla concorrenza, dotando i partecipanti alla gara
che adottano lo schema di licenza FLOSS di una posizione di vantaggio competitivo rispetto
a coloro che adottano schemi proprietari, forzando perciò la scelta verso un'applicazione che
non necessariamente da un punto di vista tecnico e/o economico risulti la migliore.
5 CONSIDERAZIONI CONCLUSIVE
Come evidenziato nella trattazione, l'attuale impianto normativo pone molti interrogativi
relativamente all'adozione di FLOSS da parte delle pubbliche ammnistrazioni.
Le tematiche di proprietà intellettuale lasciano spazio aperto a più soluzioni interpretative
evidenziando le lacune di cui è preda il sistema. La conseguenza è l'incerto utilizzo di un
modello di particolare interesse per l'informatizzazione della Pubblica Ammnistrazione e in
questo senso, auspicabile sarebbe un intervento del legislatore che, preso atto di quanto fino
ad oggi emerso, provveda ad eliminare dal campo i principali dubbi interpretativi.
Diverso invece l'approccio alle problematiche concorrenziali.
La pronuncia della Corte richiamata pare cristallizzare un principio di particolare rilievo:
software open source e software proprietario non sono modelli tecnologici distinti ma modelli
giuridici alternativi che identificano due diverse e distinte applicazioni del diritto d'autore.
In questo senso la scelta dell'uno o dell'altro modello è libera e demandata all'utente finale.
La domanda da porsi è quindi se sia non tanto legittima quanto necessaria una normativa
regionale che integri quella statale contenuta nel Codice dell'Amministrazione Digitale
indicando titoli preferenziali.
In fin dei conti il FLOSS, potendo sfruttare il meccanismo della condivisione della
conoscenza, è da un punto di vista tecnico ed economico una soluzione migliore del software
proprietario per l'informatizzazione della Pubblica Amministrazione, già questo dovrebbe
essere sufficiente a dirigere la scelta su applicazioni a codice sorgente aperto, proprio ai sensi
dell'art. 68, comma 1, del CAD.
In conclusione, nonostante le molte problematiche sollevate in relazione alla sua
compatibilità con l'ordinamento vigente, non può esservi dubbio che il FLOSS rappresenti
non una semplice alternativa al modello proprietario, ma la più adeguata risposta alle
esigenze di efficienza, efficacia ed economicità dell'agire amministrativo.
Pagina 44
Bibliografia
A. Rossato, Diritto ed architettura nello spazio digitale. Il ruolo del software libero, Padova,
2006, spec. 165 ss.
A.Sponzili, Le politiche di incentivazione del software libero nell’ordinamento francese, in
Ciberspazio e diritto, 2002, 185 ss.
L. Lessig, Il futuro delle idee, trad. it. L. Clausi, Milano, 2006
V. Zeno Zencovich-F. Mezzanotte, Le reti della conoscenza: dall’economia al diritto, in Dir.
Inf., 2008, 141 e ss.
M. Valimaki, Dual Licensingin Open Source Software Industry, in Systemes d´Information et
Management, 2003.
Boschiero, Le licenze FLOSS nel diritto internazionale privato: il problema delle
qualificazione, in AIDA, 2004, 176 e ss.
G. Ziccardi, Il diritto d’autore nell’era digitale, Milano, 2001
N.F. Ruju, L’acquisizione e il riuso del software nella P.A., Napoli, 2009.
F. Bravo, La licenza pubblica dell’UE per il rilascio di software open source, in Contr., 2008,
1063 ss.
C. Flick-G.A. Cignoni-V. Ambriola, Il riuso del software nella Pubblica Amministrazione, in
Dir.Internet, 2008, 85 ss.
A. Pioggia, Sviluppo, acquisizione e riuso di sistemi informatici nelle pubbliche
amministrazioni. Commento agli artt. 67-70 del D.Lgs. n. 82/2005, in E. CARLONI (a
cura di), Codice dell’Amministrazione Digitale: commento al D.Lgs.7 marzo 2005, n. 82,
Rimini, 2005, 399 ss.
M. Atelli-S. Aterno-A. Cacciari (a cura di), Codice dell’Amministrazione Digitale.
Commentario, Roma, 2008
F. Bravo, Software « open source » per la P.A. tra diritto d’autore, appalti pubblici e diritto
dei contratti. La licenza pubblica dell’UE per i programmi con codice sorgente aperto, in
Dir. inf., 2008, 865 ss.;
G. Scorza, L’open source nella Pubblica Amministrazione. Aspetti giuridici, in F.
SARZANA, e- Governement. Profili teorici ed applicazioni pratiche del governo digitale,
Piacenza, 2003, 255 ss. Markus, M.L. e Robey, D. (1988). Information technology and
organizational change: Causal structure in theory and research. Management Science, 34
(5), 583-598.
LICENZA
L'autore mette l'articolo sopra esteso a disposizione dei terzi che ne vorranno fruire secondo
quanto indicato nella “CREATIVE COMMONS PUBLIC LICENCE” Attribuzione Condividi allo stesso modo 2.5 -ITALIA- (http://creativecommons.org/licenses/bysa/2.5/it/legalcode ) , i cui termini sono da intendersi qui per esteso richiamati.
Pagina 45
CAQDAS – UN APPROCCIO LIBERO
D'Andrea, Vincenzo, Dipartimento di Ingegneria e Scienze dell'Informazione,
Università degli Studi di Trento, via Sommarive 14, 38123 Trento, IT,
vincenzo.dandrea@unitn.it
De Paoli, Stefano, Sociology Department, National University of Ireland, Maynooth,
stefano.depaoli@nuim.ie
Ruzzene, Lorenzo, Facoltà di Sociologia, Università degli Studi di Trento, via Verdi
25, 38122, Trento, IT lorenzo.ruzzene@gmail.com
Teli, Maurizio, Museo Tridentino di Scienze Naturali, via Calepina 14, 38122,
Trento, IT, maurizio@maurizioteli.eu
Abstract
In questo paper viene descritto l'uso di software libero nell'analisi sociologica di tipo qualitativo,
ovvero dei software che vengono chiamati Computer Assisted Qualitative Data Analysis Software o
CAQDAS. Anche se questo tipo di ricerca è patrimonio di altre discipline, quali ad esempio la
psicologia o l'antropologia, in questo lavoro concentreremo la nostra attenzione alla sociologia, per
congruenza disciplinare con gli interessi degli attuali partecipanti al progetto.
L'analisi sociologica di tipo qualitativo è una metodologia di ricerca che pone l'accento sul lavoro
svolto da ricercatrici e ricercatori sui dati, e che si presta bene all'uso di prodotti software a supporto
della ricerca stessa. Per lo stesso motivo, le limitazioni delle soluzioni proprietarie possono diventare
limitazioni alla libertà di ricerca o quanto meno alle potenzialità della metodologia.
In questo lavoro descriviamo due diverse esperienze. La prima è un progetto per lo sviluppo di un
pacchetto CAQDAS basato su Drupal, un progetto sostenuto dall'Università di Trento. La seconda è
centrata sull'utilizzo di Add-on del browser Firefox per condurre una analisi qualitativa su dati
provenienti dal Web.
Gli scopi di questo articolo sono: (a) stimolare un dibattito sull'uso di software libero per condurre
analisi dei dati di tipo qualitativo ; (b) promuovere l'uso di risorse già disponibili per condurre analisi
dei dati di tipo qualitativo; (c) incentivate lo sviluppo di soluzioni adattabili alle esigenze della singola
ricercatrice, invece che costringere la ricercatrice ad adattarsi al software.
Parole Chiave: Ricerca Qualitativa, CAQDA, Drupal, Firefox,.
Pagina 46
1 INTRODUZIONE
Questo articolo presenta una riflessione su due diverse esperienze di utilizzo di software
libero a supporto dell'analisi dei dati nella ricerca sociale di tipo qualitativo (nel seguito
CAQDAS, Computer Aided Qualitative Data Analysis Software). In questo contesto, i nostri
obiettivi sono tre: (1) stimolare un dibattito sull'uso di software libero per condurre analisi dei
dati di tipo qualitativo; (2) presentare una esperienza basata sull'uso di risorse già disponibili
per condurre analisi dei dati di tipo qualitativo; (3) attivare interesse per lo sviluppo di
soluzioni adattabili alle esigenze della singola ricercatrice 72 (invece che costringere la
ricercatrice ad adattarsi al software). Per raggiungere questi scopi, l'articolo è così
organizzato: una introduzione ai CAQDAS; un resoconto su un progetto di sviluppo di
CAQDAS libero; una descrizione delle possibilità di utilizzare estensioni di Firefox come
componenti di strumenti CAQDAS; conclusioni su possibili sviluppi.
2 COSA SONO I CAQDAS
Nelle scienze sociali sono presenti due tradizioni metodologiche di ricerca: la ricerca
quantitativa e quella qualitativa. Per quanto riguarda la prima, sono ben noti e accettati i
pacchetti software in grado di fornire supporto alle ricercatrici. Si tratta di programmi
commerciali come SPSS o Stata, o del progetto open source R, tutti software di importante
rilievo in università, istituti di ricerca e aziende. Anche le ricercatrici che intendono avvalersi
della metodologia qualitativa hanno a disposizione numerosi pacchetti software. I CAQDAS
sono dei programmi finalizzati ad assistere le ricercatrici nelle analisi di tipo qualitativo,
ovvero basate su dati qualitativi. Essi sono in grado di rendere più agevole, trasparente e
tracciabile l’analisi, andando oltre quello che può essere un semplice programma per
prendere appunti.
Nella ricerca qualitativa le tecniche impiegate possono essere, ad esempio, osservazione
partecipante, interviste in profondità o focus group, mentre l'analisi può essere svolta
ispirandosi alla grounded theory, alla frame analysis, all'analisi della conversazione o
narrativa, eccetera. I dati sono principalmente in forma discorsiva e testuale (ma anche
audiovisiva), e possono essere costituiti da interviste (solitamente trascritte), note di campo,
diario della ricerca, tracce audio e video e fotografie.
Tradizionalmente, nella fase di catalogazione, analisi e scrittura dei risultati, si usava un
metodo manuale: sottolineature, evidenziazioni e note a margine, con tutte le difficoltà che si
ponevano alla ricercatrice lavorando su grandi quantità di carta. La diffusione del personal
computer e i primi elaboratori di testo hanno reso più semplici alcuni di questi processi, senza
però riuscire a supportare l'intero processo della ricerca qualitativa. I CAQDAS consentono
di avere tutti i dati raccolti in un singolo contenitore elettronico, spesso definito “progetto”;
all'interno di questo è possibile la catalogazione di tutto il materiale della ricerca,
l'applicazione di etichette (codici) a parti del testo ritenute rilevanti (citazioni) ed i
collegamenti di parti del testo tra loro (link ipertestuali).
La scelta del femminile è legata al noto problema del sessismo nella lingua italiana, sessismo che dovrebbe spingere all'utilizzo di espressioni o neutre o maschili e femminili contemporaneamente. Per economicità della scrittura, si è optato per utilizzare il femminile invece dell'uso doppio maschile e femminile. 72
Pagina 47
Molti studiosi ritengono che mediante l'utilizzo del computer l'interpretazione dei dati risulti
più trasparente e tracciabile, scongiurando il rischio di bias nella costruzione di spiegazioni o
nel testare una teoria. Come ben sintetizzato da Wolcott (1990; 35) “The critical task in
qualitative research is not to accumulate all the data you can, but to ‘can’ (i.e. get rid of)
most of the data you accumulate”. Proprio per questo scopo sono stati sviluppati i CAQDAS.
Non si tratta perciò di strumenti per effettuare la content analysis, ovvero uno studio statistico
sulle frequenze di parole e frasi, o occorrenze di parole e frasi con altre. Sebbene anche alcuni
CAQDAS lo permettano in vario modo, non è il loro scopo principale (Lewins & Silver,
2007; 6-7).
Mangabeira, Lee e Fielding (2004) mostrano come nel campo dei software per la ricerca
computer-assisted, fin da quando si trattava di semplici strumenti di codifica e recupero, si
sono sviluppati tre trend: una maggiore sofisticazione, ovvero è possibile effettuare
operazioni che senza l’ausilio del computer sarebbe altrimenti arduo compiere; la
commercializzazione, ossia lo sviluppo di software proprietari, con il rischio della chiusura a
particolari metodologie e procedure, oltre ai limiti posti nella condivisione tra ricercatrici (la
ricerca è vista quindi sotto certi aspetti come un bene commerciabile); infine, gli autori
osservano un aumento degli utenti, sia in diversità, che in ampiezza. Le principali possibilità
offerte dai CAQDAS sono a nostro avviso sintetizzabili in otto operazioni:
(1) Vicinanza e prossimità ai dati – Un grande vantaggio dei CAQDAS è quello di poter
includere nella ricerca tutti i tipi di dati che si sono raccolti o che si stanno ancora
raccogliendo. Una volta associato il proprio materiale al progetto, è possibile commentare ed
annotare in modo che le proprie osservazioni siano collegate ai dati. Inoltre è possibile
collegare tra loro parti rilevanti dei dati, come ad esempio resoconti che nella narrazione non
sono espressi ordinatamente.
(2) Applicazione di codici a segmenti di dati – I codici hanno lo scopo di facilitare l’analisi,
permettendo di contrassegnare particolari situazioni sociali, esperienze, identificare modelli
(patterns) in atteggiamenti, investigare processi d’interazione. L’applicazione di codici
avviene definendo la quantità di testo da essere codificata (parola, frase, paragrafo, intero
documento), ed assegnando i codici rilevanti ad una porzione o a porzioni sovrapposte. I
codici si possono creare a priori o mentre si leggono i dati, legandoli con il segmento che ha
dato quell’idea, concetto o categoria.
(3) Realizzazione di uno schema di codifica – Strettamente connessa alla questione dei codici
vi è la realizzazione di uno schema di codifica. Da molti l’analisi qualitativa (o per lo meno
una parte importante di essa) viene vista come l’attività di frammentare e poi rimettere
assieme diversi segmenti di dati, cioè creare uno schema di codifica (Lewins & Silver, 2007;
91-100). Alcuni software offrono alla ricercatrice la possibilità di realizzare schemi di
codifica gerarchici, che consentono di tenere un maggior ordine nella codifica ma possono
causare dubbi di assegnazione.
(4) Esplorazione e visualizzazione dei dati semplice – Una volta effettuata la codifica, il
passo successivo è quello di recuperare il lavoro fatto, qualsiasi tipo di codifica sia stato
realizzato. Questo in quanto il così detto “code & retrieve” (codifica e recupero) è alla base
dei CAQDAS. È qualcosa che si dovrebbe fare anche durante la codifica, per vedere modelli,
relazioni, contraddizioni.
(5) Organizzazione della scrittura – È importante annotare pensieri, intuizioni, domande e
teorie non appena vengono in mente, non solo perché potrebbero tornare utili, ma anche per
Pagina 48
tenere traccia delle idee iniziali, cosicché si possa riformularle meglio. Con i CAQDAS è
possibile cercare tra le note, seguendo anche i link tra gli oggetti e i dati.
(6) Mappare idee e collegare concetti – Le mappe permettono di riprendere gli oggetti del
progetto in maniera schematica; danno modo di avere sotto controllo le complesse
interrelazioni dei differenti elementi dell’analisi. Le mappe possono aiutare a lavorare in
maniera più astratta, facilitando il processo d’analisi, aiutando ad integrare e connettere idee
astratte con gli stessi dati. Lavorando con le mappe nei CAQDAS, è importante la possibilità
di manipolare oggetti dal contenuto “attivo”.
(7) Organizzazione dei dati – Permette di focalizzarsi su sottoinsiemi di dati, e combinazioni
di sottoinsiemi, ed è particolarmente importante quando si lavora su un progetto di larga
scala. Facilita la comparazione, l’identificazione di strutture e relazioni, permette un facile
accesso al dataset.
(8) Interrogazione dei dati – L’interrogazione dei dati, al di là del semplice recupero delle
citazioni e dei codici associati, è una delle funzionalità più raffinate offerte dai CAQDAS. Le
operazioni di ricerca possono riguardare il contenuto (ovvero il testo) oppure i codici. Ad
esempio, si potrebbero comparare gruppi di rispondenti, per considerare come hanno parlato
di una tematica; oppure trovare dove alcuni intervistati hanno parlato di un argomento; o
trovare dove gli intervistati hanno parlato di un argomento vicino ad un altro; e così via.
2.1
I CAQDAS esistenti (liberi e non)
Come notato da Lewis e Silver (2006), spesso per il ricercatore è in atto un processo di
selezione di un software adatto per la specificità della ricerca. Tra i vari software proprietari
disponibili, tre di essi hanno ad oggi maggior diffusione e completezza in funzionalità. Si
tratta di ATLAS.ti, MAXqda e NVivo (Lewins & Silver, 2007; Di Gregorio & Davidson,
2008). Altri sono HyperRESEARCH, QDA Miner, Qualrus e Transana. Questi software
facilitano le operazioni di codifica e il recupero dei dati, nonché le fasi di costruzione della
teoria vera e propria (tra cui prendere appunti e note). Le funzionalità di base sono
congruenti, mentre l’elemento caratterizzante è la logica mediante la quale ogni programma
offre le procedure d’analisi e l’organizzazione delle informazioni nel progetto.
Si assiste negli ultimi anni al supporto di un maggior numero di formati, a un miglioramento
dell’interfaccia, e altre di minore entità per gran parte delle utilizzatrici. È presente nelle
ultime versioni una maggiore integrazione con il web per quanto riguarda l’analisi di siti, la
gestione dei collegamenti e la geolocalizzazione mediante Google Earth. I principali software
proprietari per certi versi si influenzano a vicenda nelle novità inserite nelle ultime versioni.
I prodotti proprietari hanno tuttavia limitazioni significative. Nvivo non consente la
manipolazioni di dati in formato HTML e si limita al trattamento dei dati in formato doc e/o
semplici file di testo (limitazione rilevante nel caso sempre più frequente di ricerche basate su
dati presenti nel web). ATLAS.ti ha limitazioni simili, a cui di potrebbe ovviare con la
trasformazione dei dati da HTML a pdf, operazione complessa nel caso di grosse moli di dati.
Infine, la vera e propria analisi dei dati viene salvata in specifici formati di tipo proprietario
che poi possono essere letti e/o manipolati solamente con il software che li ha creati.
Esistono alcune soluzioni CAQDAS software libero. In particolare, le due più rilevanti sono:
 WeftQDA (pacchetto QDA con operazioni di base), realizzato da Alex Fenton, originariamente per l’analisi di interviste e note di campo di una sua ricerca, per il Pagina 49

conseguimento del MSc, riguardo alle cooperative di credito (credit unions) a South London. Si tratta di un software generico per la codifica e il recupero dei dati testuali, mediante una semplice interfaccia. È più limitato nelle funzionalità rispetto ai principali software commerciali, anche se per la realizzazione di operazioni base (codifica, recupero, memo) può essere considerato più che adeguato. Inoltre, caso più unico che raro, supporta sia Windows sia Linux (in futuro anche Mac OS X). Permette di tr attare unicamente dati testuali (testo o PDF), e permette anche semplici ricerche booleane, una certa misura di statistiche descrittive sui dati e crosstab dei codici. Un’altra interessante proposta è RQDA. Si tratta di un pacchetto aggiuntivo del software R, solitamente noto per l’analisi di dati statistici. Creato da Ronggui Huang per la conduzione della sua ricerca di dottorato presso la City University di Hong Kong, nella quale intendeva svolgere l’analisi del contenuto di articoli di giornale. La sua intenzione era quella di poter avere un software multipiattaforma (essendo un pacchetto di R, è utilizzabile in tutti i sistemi operativi supportati da quest’ultimo), avere un software semplice e completamente controllabile da lui stesso. Il pacchetto supporta solo documenti di testo (plaintext), e permette tutte le funzionalità di base dei CAQDAS (codifica e recupero, memo, organizzazione dei dati). Essendo un pacchetto di R, si presta particolarmente per le metodologie miste, possibili anche con altri software tramite esportazione di tabelle con frequenze di parole o codici in un foglio elettronico o pacchetto statistico, ma che in questo caso vengono direttamente gestite dallo stesso strumento. L’interfaccia è tuttavia non intuitiva, e al momento non è uno strumento adatto a gran parte della comunità delle ricercatrici qualitative, e nemmeno degli utenti dei CAQDAS.
Benché queste soluzioni siano interessanti e utili, con il nostro progetto cerchiamo di spostare
la prospettiva dei CAQDAS liberi su un piano decisamente più avanzato delle proposte
proprietarie.
3 IL PROGETTO WEB-BASED
Il progetto attualmente chiamato “QDA-UniTn” ha come obiettivo la produzione di un
software per l'analisi qualitativa dei dati nella ricerca sociale. Il software che in via di
sviluppo ha tre caratteristiche principali: essere software libero e open source; essere multipiattaforma, ovvero utilizzabile con diversi sistemi operativi; essere concepito come uno
strumento che favorisca la collaborazione tra ricercatrici, invece di privilegiare un concetto di
ricerca come attività individuale.
La necessità di una soluzione libera emerge da una analisi di mercato delle soluzioni
attualmente disponibili, analisi che sottolinea come poche di queste soluzioni permettano ad
una istituzione accademica, impegnata nell'analisi qualitativa, di adattare il software per
facilitare i diversi usi dello stesso fatti dalle ricercatrici. Dalla stessa analisi emerge come
poche delle soluzioni disponibili permettano alle ricercatrici di scambiarsi documenti senza
essere costretti ad adottare un ristretto numero di sistemi e ambienti operativi. Infine, la spinta
verso uno strumento che nasca come facilitatore della cooperazione viene dalle recenti
innovazioni metodologiche nella ricerca sociale, sempre più un'attività collettiva, come
mostra l'uso di termini quali “etnografia globale” o “etnografia multi-situata”, concetti che
sottolineano come ormai la ricerca qualitativa coinvolga sempre più gruppi di ricerca che
Pagina 50
analizzano dati similari, se non gli stessi, mentre i prodotti attualmente disponibili nascono
tutti da un concetto di ricerca e di analisi dei dati come attività individuale.
La soluzione adottata si basa sul Content Management System (CMS) Drupal, sul riuso di
moduli già esistenti, e sulla creazione di moduli appositi per il lavoro di analisi di testi
preparati in precedenza.
3.1
Perché una soluzione basata su Drupal
Un approccio web-based è la prima ed intuitiva risposta alle domande su come costruire un
sistema intrinsecamente collaborativo. Da Wikipedia ai Google Docs, la rete è piena di
esperienze di successo che hanno sfruttato il modello cooperativo con un editing
collaborativo di testi, contenuti e strutture, navigando tra pagine e immagini, modificando i
contenuti esistenti e creandone di nuovi.
Le domande che emergono valutando una soluzione basata sul web sono principalmente tre:
 quali i migliori linguaggi per raggiungere un buon risultato (facilità di programmazione e uso)?
 quali le funzioni principali da offrire all'utenza?
 come garantire la possibilità di lavorare offline, in assenza di una connessione a Internet?
Se la risposta al terzo quesito non è ancora stata data, le risposte fornite nell'ambito del
progetto QDA-UniTn agli altri due quesiti si sono concretizzate nella scelta di Drupal come
piattaforma di supporto e nella conduzione di interviste con ricercatori e ricercatrici per
costruire una lista di funzionalità base che ha costituito l'ossatura della costruzione di un
primo prototipo.
Considerando Drupal come CMS, i pregi principali per la costruzione di un software
CAQDAS
riguardano principalmente due aspetti: la struttura modulare e la grande
disponibilità di moduli già costruiti dagli utenti e sviluppatori dello stesso CMS. Parlando di
struttura modulare, un CMS come Drupal permette, partendo da una base poco esigente in
termini di risorse, di aggiungere funzionalità in maniera indipendente, attraverso la
costruzione di uno o più moduli specifici. Inoltre, Drupal fornisce un ampio numero di
moduli già sviluppati dalla comunità che permettono di trovare le soluzioni più adeguate per
tutte le funzionalità di base del progetto. Al momento, solo per la versione 6.x, quella
utilizzata dal progetto, sono disponibili 6881 moduli. Per capire quali di questi moduli
utilizzare e su cosa concentrare lo sviluppo, il gruppo di lavoro ha compiuto delle interviste
con potenziali utenti in modo da costruire una serie di use case ed una lista di funzionalità
necessarie.
3.2
Le funzionalità necessarie
Per rispondere alla domanda “quali le funzioni principali da offrire all'utenza?” si sono
effettuate delle interviste con utenti di altri software CAQDAS, potenzialmente interessate ad
utilizzare la soluzione proposta. In particolare, sono state intervistate due ricercatrici
universitarie ed un ricercatore di un ente pubblico di ricerca non universitario. Tali interviste
hanno fatto emergere un quadro di quali siano le funzionalità imprescindibili di ogni software
CAQDAS:
Pagina 51














caricare documenti di testo in vari formati (doc, odt, pdf, txt ed altri)
creare una scheda identificativa diversa per ogni testo (es. dati specifici, gg, ora, locale,
ecc)
evidenziare il testo con colore, grassetto, corsivo e/o sottolineato
inserire foto, video e audio per illustrare il testo
creare codici associati a parti del testo, associando una descrizione ad ogni codice
creare una propria simbologia di codici
creare, anche in modo assistito, un rapporto tra i codici
creare famiglie di codici, associando commenti alle famiglie
creare grafici o mappe con nodi concettuali
stampare il testo presentato sullo schermo oppure quello dell'intero documento
salvataggio automatico del lavoro ad ogni 3 minuti
il software crea una traccia per ogni modifica fatta dal ricercatore/ricercatrice
il software è dotato di un esploratore di documenti per la ricerca di parole
il software è dotato di un supporto quantitativo per il conteggio di parole
Figura 1: relazioni tra le attività del/la ricercatore/ricercatrice ed il software.
Pagina 52
A questo elenco di funzionalità si è affiancata la produzione di uno use case, che rappresenta
la relazione tra la ricercatrice che intende utilizzare il software ed il software stesso (Figura
1). Tali funzionalità legate all'uso individuale vanno poi ampliate attraverso la gestione di
ricerche che coinvolgono più ricercatori e ricercatrici, attraverso un'attenta analisi dei
permessi da garantire su alcuni specifici documenti. In particolar modo, sono previste almeno
due tipologie di utente:
 responsabile della ricerca
 ricercatore/ricercatrice
La responsabile della ricerca ha possibilità più ampie della singola ricercatrice, in quanto è
l'unica a cui è permesso eliminare file ed assegnare ricercatrici ad un singolo file. È previsto
che sia possibile avere più figure come responsabili della ricerca. La ricercatrice, oltre a poter
gestire i propri file e a poter lavorare su di essi, possono inoltre lavorare su file a loro
assegnati dal responsabile della ricerca. Il prototipo realizzato rispecchia tale distinzione.
In conclusione, l'Università di Trento, nel progetto QDA-UniTn, si è avvalsa finora di risorse
relativamente scarse (un coordinatore di progetto, uno degli autori, per un mese uomo
all'anno per due anni e quattro studenti o studentesse, per un totale di seicento ore di lavoro,
trecento all'anno) ma, sfruttando le potenzialità del software libero di riusare tecnologie
mature e stabili, è giunta alla realizzazione di un primo prototipo che ha enucleato quali siano
le funzionalità fondamentali per attrarre utenti nella fase iniziale. Al momento, il progetto è in
attesa di un nuovo finanziamento per trasformare il prototipo in una versione beta utilizzabile.
Se un approccio libero basato sul riuso è funzionale alla costruzione di un nuovo sistema, il
paragrafo successivo mostrerà come il riuso individuale di componenti separate possa essere
sufficiente nel caso di una ricerca specifica, per condurre raccolta e analisi dei dati di tipo
qualitativo.
4 QDA CON GLI ADD-ON DI FIREFOX
Queste note sono parte della ricerca che uno degli autori sta facendo sul fenomeno del
“cheating” (imbrogliare/barare) nei Massive Multiplayer Online Games (MMOPRGs) (De
Paoli e Kerr, 2010). Senza entrare troppo nel merito dei particolari, questa ricerca è condotta
raccogliendo dati principalmente attraverso Internet e nello specifico i dati della ricerca sono
composti principalmente da discussioni di Internet Forum. In un forum gli utenti formano
spesso una comunità virtuale e discutono di argomenti in comune (per esempio di un
videogame online), oppure di una sua sottosezione (per esempio di “scambio di oggetti
virtuali” in un videogame). Il contenuto degli Internet Forum, come ogni altro contenuto del
World Wide Web può essere recuperato e navigato attraverso l'uso di un Browser. In
particolare, in questa ricerca sul cheating, è stato utilizzato uno dei principali Web Browser
liberi: FireFox. In questa sezione verranno descritti alcuni Add-On del browser Firefox che
sono stati utilizzati in questa ricerca nelle fasi di raccolta ed analisi dei dati.
4.1
Raccolta dei dati
Uno dei problemi principali della ricerca sul “Cheating” è stato quello di salvare ed
organizzare le discussioni degli Internet Forum, così da poter utilizzare questi dati in fasi
successive della ricerca. Ed infatti il problema di salvare il contenuto del Web, che in molti
Pagina 53
casi appare volatile (McCown and Nelson, 2009), è uno dei problemi emergenti della Internet
Research (Pollack and Gatterbauer, 2007).
La raccolta dei dati (i threads dei Forum) è stata fatta attraverso un Add-On di Firefox
chiamato Scrapbook (http://amb.vis.ne.jp/mozilla/scrapbook/). Questo software permette di
realizzare raccolte di pagine web (incluso interi siti-web) che possono essere non solo
immagazzinate ma anche facilmente gestite attraverso le funzionalità del software stesso.
Scrapbook permette di catturare le pagine web e di organizzarle in cartelle (vedi Figura 2). Le
pagine “catturate” sono salvate “in locale” e possono essere successivamente utilizzate (per
esempio per l'analisi dei dati).
Il software Scrapbook possiede diverse funzionalità utili alla ricerca sociale in ambito web ed
Internet: per esempio, come nei sistemi CAQDAS, ha un motore di ricerca interno, è
possibile prendere note, risalire alla pagina web originale, ed operare back-up completi dei
dati.
Figura 2: Catturare una pagina web con Scrapbook. Sulla sinistra si può anche vedere come
i dati possono essere organizzati in cartelle.
Una delle funzionalità di Scrapbook maggiormente interessanti per la ricerca è la possibilità
di avere Scrapbook “multipli”, dove salvare diverse collezioni di pagine web oppure copie (o
parti di) delle stesse collezioni (vedi Figura 3). E' così possibile muoversi tra diverse
collezioni di pagine Web immagazzinate in diversi Scrapbook. Questa funzionalità di
Scrapbook è per esempio utile per distinguere tra la stessa collezione/raccolta di pagine o siti
web nei momenti di raccolta ed analisi dei dati (i.e. si pu avere una copia separata degli stessi
dati per fare l'analisi all'interno di Scrapbook).
Pagina 54
Figura 3: Scrapbook Multipli (Gli Scrapbook sono in questo caso 3:
1) TIBIA_DATA_ANALYSIS, 2) Tibia_Concepts&Memos e 3) Profile folder).
4.2
Analisi dei dati
La ricerca sul cheating ha visto anche una fase di analisi dei dati. In particolare è stato deciso
di adottare una Grounded Tehory (GT) (Charmaz. 2006). La GT è un approccio che mira a
costruire teorie sociali sulla base di un approccio ricorsivo ed induttivo di codifica tra dati e
concetti. La GT comporta la creazione di codici, simili a veri e propri “tag” che si possono
applicare su porzioni di dati (testo nel caso specifico). Molti codici quindi vengono a
comporre categorie di livello più elevato (concetti) la cui organizzazione dovrebbe portare
alla costruzione di una teoria.
Un primo Add-On di Firefox utile per l'analisi è Wired Marker (http://www.wiredmarker.org/en/). Si tratta di un “evidenziatore indelebile e permanente” che si utilizza sulle
pagine Web. Il contenuto evidenziato è anche in grado di essere facilmente recuperato e
visualizato attraverso dei bookmarks che possono essere organizzati in cartelle. In breve,
Wired Marker consente di associare una “codice/bookmark” a porzioni di testo di pagine
web. Il testo può essere associato al bookmark semplicemente evidenziando col cursore del
mouse e poi trasportato con un operazione di “drag-and-drop” verso il bookmark/cartella di
WM (Figura 4). Il testo associato ad ogni codice puo successivamente essere recuperato e
visualizzato (Figura 5).
Pagina 55
Figura 4: Catturare una porzione di testo associarla ad un codice con un "drag and drop".
Figura 5 - Visualizzazione delle porzioni di testo associate ad uno specifico codice.
In breve WM compie le medesime operazioni di base dei comuni CAQDAS : (1) associare
porzioni de testo ad un codice (Figura 4); (2) recuperare successivamente il testo relativo ad
un codice (Figura 5). Grazie all'Add-On Mutlisidebar (https://addons.mozilla.org/enUS/firefox/addon/4534) è possibile avere barre laterali multiple e quindi utilizzare più AddOn contemporaneamente. Nello specifico caso della ricerca sul cheating Wired Marker e
Scrapbook sono stati utilizzati assieme creando uno Scrapbook contenente i dati da
analizzare, che poi sono stati analizzati utilizzando WM.
Per quanto riguarda la costruzione vera e propria dei codici, una delle fasi della GT, vi sono
diverse strategie. In particolare attraverso delle pre-analisi che considerano una analisi fatta
“parola-per-parola”, “linea-per-linea”, o “evento-per-evento”. Optando per una strategia di
costruzione dei codici “linea-per-linea” compiuta su una sample (porzione) dei dati raccolti si
può utilizzare un altro Add-On di Firefox, “Edit and Note” (http://editandnote.ritty.hu/) che
consente di “incollare” una nota all'interno di una pagina Web.
Pagina 56
5 CONCLUSIONI
Nel panorama dei CAQDAS, la nostra analisi ha evidenziato che le soluzioni attualmente
disponibili non sono in grado di supportare le esigenze di collaborazione sempre più rilevanti
nella ricerca qualitativa. Inoltre, sono particolarmente rilevanti le limitazioni riguardanti i
formati dei dati utilizzabili, anche per esporare/importare i dati, aggravate dall'uso di formati
proprietari chiusi per salvare i risultati del lavoro di ricerca.
Poche delle soluzioni disponibili offrono alle ricercatrici la possibilità di condividere i dati
analizzati in maniera semplice. Un'ulteriore spinta in tal senso proviene dalle recenti
innovazioni metodologiche nella ricerca sociale in una forma più tendente all'attività
collettiva, dove la ricerca qualitativa coinvolge sempre più gruppi di ricerca che analizzano
dati simili. I software esistenti sottendono invece un principio di ricerca più classico,
favorendo la ricerca come attività individuale.
In questo lavoro abbiamo presentato un progetto di sviluppo di un CAQDAS libero e la
possibilità di costruirsi una sorta di “cassetta degli attrezzi” con Add-On di Firefox. Non è
esclusa la possibilità di integrare i due approcci, creando una soluzione mista, in parte sul
client (gli Add-On di Firefox), in parte su server (i moduli Drupal). In ogni caso, lo strumento
utilizzato nella ricerca ha rilevanza per l'analisi che si intende svolgere. Mediante strumenti
liberi e collaborativi è possibile ottenere un maggior grado di personalizzazione
dell'interfaccia e delle funzioni del software. Inoltre è possibile ed auspicabile l'interesse di
altre ricercatrici allo sviluppo di plug-in ed estensioni in grado di arricchire le funzionalità del
programma.
RINGRAZIAMENTI
Stefano desidera ringraziare gli sviluppatori degli Add-On di Firefox usati nella ricerca. Un
grazie in particolare a Valeria Ritty, sviluppatrice di “Edit and Note” con la quale ho
intrattenuto interessanti discussioni, in particolare su come usare Scrapbook assieme a “Edit
and Note”. Gli altri autori ringraziano gli studenti e le studentesse che hanno finora
collaborato allo studio di fattibilità, alla progettazione, ed alla realizzazione del prototipo di
“QDA-UniTn”.
BIBLIOGRAFIA
Charmaz, K. (2006). Constructing grounded theory: A practical guide through qualitative
analysis. London: Sage.
De Paoli S. and Kerr. A. (2010). 'We Will Always Be One Step Ahead of Them': A Case Study
on the Economy of Cheating in MMORPGs, Journal of Virtual Worlds Research, 2(4).
Di Gregorio, S., and Davidson J. (2008). Qualitative Research Design for Software Users.
Open University Press Milton Keynes, UK, USA.
Mangabeira, W. C, Lee, R. M. and Fielding N. G. (2004). “Computers and qualitative
research: Adoption use, and representation.” Social Science Computer Review 22:167.
McCown, F. and Nelson, M. L. 2009. What happens when facebook is gone?. In Proceedings
of the 9th ACM/IEEE-CS Joint Conference on Digital Libraries (Austin, TX, USA, June
15 - 19, 2009). JCDL '09. ACM, New York, NY, 251-254. DOI=
http://doi.acm.org/10.1145/1555400.1555440
Pagina 57
Lewins, A., and Silver C. (2007). Using software in qualitative research: a step-by-step
guide. Sage Publications.
Lewis, A and Silver, C (2006) Choosing a CAQDAS Package, CAQDAS Networking
Project, Retrieved January, 2009 from http://cue.berkeley.edu/qdaarticle.pdf
B. Pollak and W. Gatterbauer. Creating permanent test collections of web pages for
information extraction research. In J. van Leeuwen et al, editors, SOFSEM 2007: Theory
and Practice of Computer Science, 33rd Conference on Current Trends in Theory and
Practice of Computer Science. Volume II, pages 103–115. Institute of Computer Science
AS CR, Prague, 2007.
Wolcott, H. F. (1990) Writing up qualitative research (Vol. 20). Newbury Park, CA: Sage.
Pagina 58
ANALISI ETNOGRAFICA DI UN PROGETTO LIBERO
Donato, Daniel, Università di degli Studi di Salerno, 84084 Fisciano (SA), IT,
ddonato@unisa.it
Bonu, Bruno, Praxiling UMR 5267- Université Montpellier 3 – CNRS, FR,
bruno.bonu@univ-montp3.fr
Abstract
Gli studi sull'innovazione ascendente, in ambito informatico, rappresentano da sempre un campo poco
praticato dall'etnografia. Diverse sono le motivazioni che hanno scoraggiato questo tipo di ricerche. Il
carattere imprevedibile dell'innovazione che spesso si manifesta in modo dirompente ed imprevisto al
difuori dei contesti tradizionalmente ad essa deputati rappresenta certamente un ostacolo ad
un'analisi di tipo etnografica dell'innovazione.
Il presente è un tentativo, ancora in corso, di studiare le dinamiche di innovazione che si realizzano
all'interno di un gruppo di lavoro impegnato nella concezione, progettazione e realizzazione di un
Software Libero per riunioni digitali. Per fare ciò abbiamo seguito l'iter di costituzione e realizzazione
di un software per riunioni digitali libero (http://riunionidigitali.net). La ricerca è stata condotta
attraverso registrazioni audio-video degli incontri in presenza e di registrazioni dello schermo delle
sessioni di lavoro. Le fasi dell'attività che sono state monitorate vanno dalla costituzione del gruppo
alla realizzazione dei test sulla piattaforma.
Come ogni analisi di tipo etnografica, la prima parte della ricerca è dedicata a una breve descrizione
dei temi della “cultura” dei partecipanti al progetto e a descriverne la 'storia', la seconda parte
descrive l'attività pratica che il gruppo pone in essere, la terza la metodologia adottata ed in fine i
primi risultati e alcuni spunti di analisi per successivi lavori di approfondimento.
Parole Chiave: Etnografia, Software Libero, Uomo macchina, Interazione, Analisi della
Conversazione.
1 INTRODUZIONE
Si tratta di una ricerca interdisciplinare ancora in corso è volta a fornire un'analisi etnografica del processo di innovazione73. Caratteristica della prospettiva etnografica è l'acquisizione del punto di vista dei partecipanti ad un'attività spogliandosi dallo sguardo ironico del ricercatore sociale sull'attività oggetto di studio. Particolare attenzione è stata accordata all'analisi del punto di vista dei partecipanti. Tenere conto del contesto informativo sotteso dai partecipanti 73
Questa ricerca « Ethnographie de l'innovation ascendante : "Assemblée Numérique" et outils FLOSS (Free Libre Open Source Software)» condotta in collaborazione fra il Laboratorio di Praxiling UMR 5267 dell'Università di Montpellier e l'Associazione Intellicom è stata possibile grazie a un finanziamento dell’Institut des Sciences de la Communication du CNRS (ISCC) et dell'Université Montpellier 3 (BQR) 20082009.
Pagina 59
nel prendere le decisioni di azioni, come nell'interpretare le azioni altrui è una prerogativa di questo approccio. L'analisi verte sull'attività pratica del gruppo impegnato nello sviluppo di uno strumento libero per realizzare riunioni on line.
La ricerca ha un triplice scopo:
a) verificare da un punto di vista etnografico idee presenti nella letteratura sul processo di innovazione in testi che fanno parte della cultura del Software Libero come Raymond (1998) oppure genericamente riferiti all'innovazione (Albero,Linard e Robin, 2008);
b) esplorare nuove piste al fine di poter restituire alla comunità del Software Libero consigli utili a migliorare le pratiche organizzative;
c) fornire consigli utili al gruppo su come migliorare il design dello strumento.
La prima parte di questo articolo espone le caratteristiche del Gruppo (Paragrafo 2) , ci si sofferma in particolare sulla cultura e sulla storia del gruppo. La Seconda parte descrive l'attività pratica che il gruppo pone in essere (Quadro della ricerca, paragrafo 3). La terza parte descrive la metodologia adottata (4) . In conclusione sono presentati alcuni spunti sull'analisi in corso (delle riunioni di concezione) e una breve discussione di quelli che possono essere gli sviluppi futuri della ricerca.
2 IL GRUPPO
2.1
La cultura
Il gruppo preso in esame si riconosce pienamente nel movimento per il Software Libero. Si tratta di un movimento che nasce negli anni '80 con il fine di difendere la comunità degli utilizzatorisviluppatori contro i tentativi di appropriazione del software e di asservimento della libertà degli utenti. Un appartenente al gruppo afferma: ”In effetti, nessuno dei partecipanti ha preso veramente parte alla fase iniziale di quest'avventura. La maggior parte di noi ha sentito parlare del progetto GNU solo negli anni '90. Molti hanno addirittura conosciuto il progetto GNU quando già stavano utilizzando una distribuzione GNU/Linux.”
Pagina 60
2.2
Storia del gruppo
Il gruppo nasce da un'aggregazione informale che si è andata costituendo a partire 2002 intorno all' Hackaserta 81100 (http://81100.eu.org). Il temine Hackaserta sta come contrazione di Hacklab Caserta. Un Hacklab è un laboratorio di Hacking, un posto dove appassionati del Software Libero si incontrano cercando di prendere dimestichezza con tecnologia software e hardware. Dopo aver organizzato per 4 anni il Linux Day, Hackaserta decide di dare vita ad una manifestazione diversa Adunanza Digitale (Donato e Napolitano, 2007). Adunanza Digitale è un'assemblea distribuita fra diverse città. Adunanza Digitale si svolge utilizzando software libero e mettendo in relazione diverse associazioni riunite in diverse città d'Italia. Ciascuna assemblea è dedicata ad un tema diverso. Nel 2007, Hacakserta si rende conto che non è sostenibile il continuo invio di propri membri in tutte le città che decidono di partecipare ad Adunanza Digitale. Approfittando di un concorso del ministero della gioventù (Giovani idee cambiano l'Italia) si decide di presentare il progetto di un software innovativo per riunioni digitali. Il risultato è un successo, il progetto presentato risulta vincitore del concorso nazionale per la categoria ICT. A partire da Hackaserta si 81100 costituisce un gruppo il cui scopo è portare avanti il nuovo progetto.
La motivazione portante del gruppo è quella di dare alla comunità del Software Libero uno strumento per realizzare le riunioni on line. Ciascuno dei partecipanti del gruppo sente di aver sempre preso dal repertorio del Software Libero. Quello che si vuole fare adesso è ricambiare la comunità offrendo il proprio lavoro. Ovviamente offrire il proprio contributo alla comunità è anche un'occasione di riscatto simbolico e professionale. Realizzare un progetto libero richiede inoltre una vasta serie di competenze pratiche che vanno oltre quelle padroneggiate dai singoli membri. Si tratta quindi di un'occasione di crescita e di una sfida. 3 QUADRO DELLA RICERCA
Scopo del progetto è realizzare uno strumento libero per tenere Adunanze Digitali. Con Adunanza Digitale si intende una serie di riunioni di cittadini che si sono tenute in Italia a partire dal 2006 (http://it.wikipedia.org/wiki/Adunanza_digitale). L'esperienza di Adunanza Digitale ha fatto maturare la convinzione secondo cui l'ecosistema del software libero contiene e mantiene tutto il software necessario a realizzare efficaci riunioni on line.
Pagina 61
La totalità dei programmi per riunioni digitali sono concepiti secondo un'impostazione adatta al sistema del software privativo. In questo ecosistema il software deve essere autosufficiente, esso deve includere tutti i moduli necessari. In ambito privativo un software è un'opera individuale, la collaborazione fra software è potenziale fonte di problemi di affidabilità o di proprietà.
D'altra parte l'ecosistema che garantisce le quattro libertà (Stallman, 1996 e 1999) dell'utente è assolutamente favorevole alla collaborazione e alla coesistenza fra software diversi. Questo garantisce, fra l'altro, la compatibilità delle licenze e la collaborazione fra gli applicativi. La nostra scelta, è stata di realizzare un software concepito in modo da poter approfittare dei vantaggi offerti da questo ecosistema.
Riunioni Digitali (RD) integra le componenti base di un sistema di videoconferenza (videostream, desktop sharing, VoIP, chat, etc), non è scopo di questo progetto offrire l'ennesima implementazione di queste funzionalità. Del resto, già nel 1968 Doug Engelbart, con la famosa presentazione del sistema NLS all'Augmentation Research Center dello Stanford Research Institute, ne ha mostrato la fattibilità tecnica. Ciò che si intende realizzare è l'equivalente di un sistema di Package Management (PM) applicato al contesto di una riunione on line vedi Donato (2009).
I PM sono senza dubbio fra le più importanti innovazioni software introdotta grazie all'iniziativa della comunità del Software Libero. Una distribuzione GNU Linux consiste in una decina di migliaia di componenti software, compito dell'amministratore è mantenere costantemente coerente lo stato di questo insieme di programmi. Il PM consiste in una collezione di strumenti per assistere l'utente nella gestione e nella manutenzione del software presente sul proprio computer. In particolare, lo scopo del PM è automatizzare (o almeno assistere) l'utente nel processo di installazione, configurazione, rimozione e upgrade del software presente sul suo computer.
Amministrare una riunione è cosa diversa dall'amministrare un singolo computer. Amministrare un singolo computer consiste nel gestire le dipendenze fra i pacchetti, amministrare una riunione implica: (a) prendere il controllo di diversi computer dislocati in una rete geografica, (b) implementare servizi in modo coerente sui diversi nodi.
In primo luogo, un PM per riunioni, a differenza di un PM per installazioni, deve quindi essere articolato in diverse parti che devono assumere il controllo di diverse macchine e coordinarsi fra di loro. A questo scopo, il sistema da noi realizzato consiste in una parte server (Web Based) e una client desktop based. Il nome del client è Sacks (Sacks And Common Knowledge Say), si tratta di un acronimo ricorsivo (in omaggio alla tradizione Pagina 62
Hacker) ma anche come tributo a Harvey Sacks (19351974) padre fondatore dell'Analisi della Conversazione (AC). Obiettivo della parte web based è offrire servizi comuni, obiettivo del client invece è gestire i servizi sui computer degli utenti, gestendo i servizi come un PM gestirebbe i pacchetti.
In secondo luogo, la gestione di una riunione pone dei problemi di gestione delle prerogative che la gestione di un'installazione non pone. Nel caso di un'installazione l'amministratore di sistema deve avere in permanenza il controllo totale della macchina e non deve rendere conto delle operazioni che compie. Nel caso della riunione la gestione delle macchine dei partecipanti può essere delegata solo secondo modalità predefinite, in un quadro temporale ristretto e rispettando delle politiche di trasparenza.
4 METODOLOGIA
Nel quadro delle ricerche sull'innovazione ascendente in ambito del software libero, il carattere diffuso del processo di innovazione e di utilizzo pone due tipi di problemi. Il primo tipo concerne il carattere diffuso delle attività. Il secondo è l'insieme delle difficoltà poste al ricercatore per l'impossibilità di avere accesso ad osservazioni dirette, non sostenute da registrazioni audiovideo. Ciò si traduce nelle domande seguenti. (a) Come osservare il processo di concezione, disperso nello spazio e nel tempo? (b) Come osservare gli strumenti utilizzati nelle attività di formazione e di scambio a distanza? Come rendere conto dell'orientazione dei partecipanti, progettisti o semplici utilizzatori?
L’ethnografia utilizzata in questa ricerca, è stata sviluppata nelle indagini dell'asse «Interactions et Environnements Technologisés» del laboratorio Praxiling, declinata in maniera specifica per questo progetto. Si tratta di una particolare applicazione dell'etnografia volta a prendere in conto e risolvere i problemi su accennati. I dati sono stati sfruttati mediante una nuova metodologia di ricerca che si fonde prima sull'osservazione delle sequenze di attività registrate in contesto. Il contesto è l'ambiente, in senso ampio, della produzione e della recezione delle attività. Questa metodologia non si limita all'analisi della produzione testuale (come nel caso dei messaggi scambiati via chat) ma analizza anche lo schermo, come ambiente di significato, e lo spazio fisico, occupato dai partecipanti e dagli artefatti, che circondano i partecipanti nella situazione. Il dispositivo di ricerca è stato quindi adattato con la cattura dello schermo e la registrazione audiovideo dell'ambiente. Ciò è stato fatto sia durante le attività di concezione che di uso. Ciò è quanto distingue radicalmente, la Pagina 63
metodologia da noi adottata, da altre etnografie “digitali”. Infatti, caratteristica dell’approccio etnografico in scienze del linguaggio è l'essere caratterizzato per l'esame delle risorse linguistiche e interazionali nella situazione. Gli strumenti dell’Analisi della Conversazione sono qui utilizzati, al fine di identificare le strategie, le traiettorie e le eventuali difficoltà nella produzione e nella ricezione di queste attività in esame. Ciò mette in evidenza gli elementi costitutivi, le possibilità esplicative e i vincoli d'espressione quando gli scambi interazionali riguardano le diverse utilizzazioni. In questo senso le pratica della ricerca in Analisi della Conversazione sono messe in relazione con la teoria dell’Azione Situata e gli studi in ambito del Work Place Studies. L'approccio etnografico multidimensionale qui presentato è quindi innovativo.
Innovativo. L’innovazione è nella metodologia, nell'oggetto di ricerca e nelle modalità stesse del trattamento del corpus di innovazione. Primo, il processo di innovazione è seguito nel tempo, dalla fase di «prototipazione» a quella delle dimostrazioni che saranno oggetto di analisi nell'inserimento in una situazione reale e specifica. Inoltre, la fase di concezione e «prototipazione» sarà messa in prospettiva con le situazioni di di uso tipiche rilevanti, ci sarà quindi un passaggio dall'una all'altra fase del processo di innovazione. Informatico. La dimensione digitale è presente a due livelli. Primo all'interno dell'oggetto, le registrazioni sono basate sull'ambiente e sulle attività di concezione e di utilizzo del dispositivo informatico. Inoltre per quanto riguarda l'analisi, questa è supportata dai partecipanti mediante registrazioni audiovideo. Ciò implica l'osservazione di sequenze video e di altri documenti oltre che la trascrizione mediante delle convenzioni specifiche, degli episodi esaminati.
Interazionale. L'obiettivo di analizzare il processo di innovazione spesso trascura la dimensione, per noi fondamentale, dell'organizzazione degli scambi situati. Analizzare l'interazione nel suo sviluppo temporale sequenziale, implica la registrazione della azioni svolte e delle risorse a disposizione dei partecipanti alla situazione. Le risorse interazionali utilizzate dagli utenti per condurre bene la loro partecipazione nelle situazioni in esame sono di differente natura: sonore (verbali e vocali), visuali (corporali, gestuali, posturali concernenti la direzione dello sguardo e il posizionamento del corpo), «artefattuali» (prodotte da una «fonte» analogica o digitale, testuale o da una o diverse immagini, fisse o in movimento) a disposizione dei partecipanti in situazioni determinate.
Pagina 64
Intersituazionali. Le risorse interazionali sono utilizzate dagli utilizzatori non solo nel quadro delle contingenze locali e globali degli scambi (aperture, chiusure, o implicanti trattamenti tematici), ma i partecipanti tengono anche conto dei vincoli che si esercitano nella temporalità di più lunga portata (relazioni fra gli individui, storia del gruppo, processo di innovazione, ecc...). In breve, la dimensione organizzativa è presente nell'insieme dei comportamenti degli utenti, nelle loro conoscenze, nei loro ragionamenti concernenti il funzionamento del gruppo e la sua organizzazione e sopratutto nelle loro azioni. Il punto di vista corrente ammette comunemente l'importanza della dimensione organizzativa e la prende in conto, ma in questo caso i fenomeni dell'organizzazione studiati nella situazione esaminata. Più esattamente, noi osserviamo allo stesso modo sia l'organizzazione delle interazioni che i legami tra le situazioni. In questo senso, questa etnografia è Strutturata (Heath et Luff 1995). La ricerca sul processo di innovazione deve poter rendere conto del legame pratico in situazione tra individui e esperienze se vuole esaminare le proposizioni, disaccordi, tentativi, sconfitte e riuscite che costituiscono la traiettoria dello strumento «Riunioni Digitali». Interdisciplinare. Quest'analisi richiede l'apporto di più sotto discipline di Scienze del Linguaggio ma anche più ampiamente di orientamenti scientifici appartenenti alle Scienze Umane e Sociali per l'analisi delle dimensioni multiple delle risorse necessarie agli individui per portare avanti e nel migliore dei modi la loro partecipazione competente alle diverse situazioni. Il comportamento e la conoscenza degli attori si sviluppa nelle azioni prodotte. Se si vuole salvaguardare il punto di vista dei partecipanti (infra) e analizzare pienamente le conoscenze utilizzate nell'interazione, è necessario affiancare all'osservazione strumentale (mediante il mezzo audiovisuale) l'osservazione diretta non registrata dell'interazione e all'intervista. Queste pratiche sono utilizzate per accedere a delle informazioni complementari. Gli scambi, più specificamente sono esaminati come una forma di interazione (Bonu 2004). Inoltre, è necessario associare gli attori allo scopo della ricerca. Così uno dei concettori, attraverso la sua doppia competenza di informatico e di etnografo, è anche uno dei responsabili del gruppo di ricerca (Donato 2007).
Concomitante. La ricerca accompagna le diverse fasi del processo di innovazione (decisione, concezione, presentazione, uso) e di conseguenza, lo sviluppo dello strumento tecnologico. Il processo d'innovazione è seguito nel tempo e nella sua elaborazione. Le differenti tappe sono l'oggetto di un esame che tiene conto del loro inserimento nella storia del processo.
Pagina 65
Costitutiva. L'etnografia deve essere in grado di trattare il comportamento e la comprensione umana come la relazione fra parola e azione, l'uso dello spazio e del tempo, l’attività di categorizzazione delle persone. Per esaminare questi domini noi adottiamo un orientamento di ricerca che può essere definito «Etnografia Costitutiva» (Mehan 1978). Questa si declina in quattro punti:
1. disponibilità dei dati. I dati (registrazioni e trascrizioni), in altre parole, le rappresentazioni delle situazioni osservate, devono essere rese disponibili per i lettori e gli ascoltatori. Queste possono essere discusse e osservate non solamente dal ricercatore;
2. esaustività del trattamento dei dati. Le trascrizioni devono essere esaminate in tutti i dettagli. La pertinenza delle ipotesi dell'etnografo deve essere controllata in base al punto seguente;
3. convergenza sulla visione degli eventi tra ricercatore e partecipanti (assumendo il punto di vista dei partecipanti). L'etnografo deve assicurarsi che nei dati sia presente la focalizzazione su degli elementi della situazione assunta dai partecipanti;
4. analisi interazionale. Più specificamente, l'analisi audiovisuale delle interazioni è un approccio metodologico dedicato all'analisi dei dettagli di un caso singolo o di una serie di casi. L'analisi inizia con la discussione di un frammento particolare dell'interazione e con l'esame di un comportamento o di un ragionamento pratico che mette in relazione attività specifiche. L'identificazione di un fenomeno particolare e la caratterizzazione della sua organizzazione legata all'analisi del dettaglio di un frammento specifico dei dati. L'esame è focalizzato sull'orientazione reciproca dei partecipanti e del loro comportamento. La spiegazione è basata sulle procedure e sul ragionamento dei partecipanti che realizzano la produzione e l'interpretazione di un'attività (Heath et Luff 1995).
4.1
Riunioni di concezione nel FLOSS
L'esame delle riunioni di concezione del gruppo informale nel quadro del progetto "Sacks" permette di evidenziare degli interrogativi sulla relazione tra lo svolgimento delle attività di creazione nel dominio più generale del Software Libero e l'organizzazione dell'interazione 74. Questo tema è stato già sviluppato in Analisi Conversazionale mediante gli studi sui colloqui di lavoro profes
sionale in diversi settori di attività (DREW et HERITAGE, 1992). Abbiamo sviluppato una presentazione della te
matica delle riunioni, attraverso una diversa prospettiva argomentativa in Bonu (2007). Per SCHWARTZMAN
(1989) le riunioni « preparate » includono gli incontri formali e informali. Esse sono caratterizzata dal livello della
formalità delle procedure utilizzate per l'attribuzione, l'ordine e la lunghezza dei turni. D'altra parte, le riunioni «
non preparate » implicano un modello di turni di parola prossimo alla conversazione ordinaria, con delle caratteristiche « formali » a proposito di certe responsabilità, chi apre, chiude e dirige la riunione. Sul tema della formalità
in generale, di interesse è il lavoro di ATKINSON (1982).
74
Pagina 66
La strutturazione dei tempi e dello spazio nel processo di innovazione è in gran parte frutto delle caratteristiche dell'organizzazione, l’agenda, l'ordine del giorno, l'animazione, l'ordine di presentazione e le azioni svolte, effettuate nell'incontro, o da venire. In questo senso, la partecipazione è orientata verso la performance e implica una "virtuosità, quasi artistica". L’interazione si sviluppa nel quadro della partecipazione multipla 75 e nelle attività convenzionali complesse come la spiegazione delle azioni, l’argomentazione la risoluzione dei problemi76. Da un punto di vista generale, anche se le riunioni in esame sono molto differenti da quelle che hanno luogo in azienda e in generale nel processo discendente dell'innovazione, le riunioni possono essere definite con Boden (1994, p. 8389) come « un incontro pianificato, interno o esterno ad un'organizzazione [qui, un processo di innovazione] nel quale i partecipanti hanno una percezione dei ruoli 77 [anche se qui questi non sono garantiti e particolarmente fluttuanti] e le attese riguardano l'ambiente (a lungo o a breve termine). Le riunioni hanno uno scopo, una « ragione », un orario, un luogo in senso generale, una funzione organizzazionale ». In effetti, il flusso discontinuo della parola (alternato a delle fasi di lavoro individuale al computer) di questa forma di interazioni sono situate all'interno del ritmo e dei presupposti (infra) del processo di innovazione ascendente. La partecipazione a un progetto «politico e associativo» si ritrova nello svolgimento della riunione, con una tensione constante verso lo sviluppo del progetto e il ruolo predominante giocato nel progetto dai membri più attivi, da una parte, così come l'interazione fra pari, dall'altra. Il contributo conversazionale rappresenta quindi « la modalità fondamentale di trasmissione e di trasformazione dell'agenda organizzativa, delle decisioni, degli scopi del progetto e di strutturazione delle riunioni… » Boden (1994, p. 85). Inoltre, le entità incomplete, vaghe e flessibili rappresentate dalle azioni di integrazione dei diversi strumenti, sono l'oggetto di un continuo lavoro di chiarificazione, da parte dei membri più attivi, in ciò che concerne principalmente lo stato attuale del progetto, le nuove focalizzazioni, la definizione mediante la parola e l'interazione, prima di essere stabilizzate. Questo lavoro si fonda principalmente sulla preparazione delle riunioni (con delle azioni pratiche effettuate prima dell'incontro), elaborazione dei diversi tipi di testi, ricapitolazione delle attività e scrittura informatica nella programmazione, realizzazione concreta del processo di innovazione ascendente (infra). Le decisioni sono discusse, prese e diffuse in un continuo lavoro che si sviluppa sostanzialmente nelle riunioni.
ATKINSON, CUFF e LEE, 1978, p. 146.
SCHMITT, 2006.
77
Sul problema del ruolo interazionale e di categorizzazione vedere anche Bonu, Mondada e Relieu (1994), Enfield
e Stivers (2007), HOUSLEY, 1999. .
75
76
Pagina 67
Questo processo può essere sviluppato efficacemente attraverso l'osservazione della produzione da parte degli interlocutori dei turni di parola e delle sequenze. Lo strutturarsi degli interventi costituisce l’ossatura interazionale delle riunioni. I partecipanti stabiliscono e abbandonano il focus del discorso, sviluppano e controllano i temi, costituiscono le forme di partecipazione e le identità interazionali, producono dei contributi e li piazzano nel corso dell'interazione, compiono attività tipiche (argomentazione e discussione) e producono delle azioni78. Formano anche delle sequenze costituite da domande o richieste di risposte corrispondenti, osservazioni e suggerimenti espliciti. Queste azioni rappresentano un luogo di azione dell'attività di creazione nel FLOSS, attraverso la negoziazione tra « le agende locali e gli scopi più generali » (BODEN, 1994, p. 128). Il funzionamento del gruppo informale è particolarmente sensibile in certe fasi dell'interazione, alla fine del punto sullo stato del progetto, il passaggio al primo tema, il passaggio di parola al primo locutore dopo l'introduzione, il ritorno dell'iniziativa interazionale ai membri più attivi 79. Di conseguenza, le riunioni rappresentano, nei fatti, un terreno di osservazione del funzionamento dei gruppi, del processo di circolazione dell'informazione, di presa di decisione e di evoluzione del lavoro collaborativo.
5 CONCLUSIONI
La parola innovazione è una parola vaga che può avere diversi significati ma che in ultima analisi, spogliata del valore semantico positivo, è equivalente a cambiamento. Per il suo forte connotato positivo il termine innovazione è stato sicuramente molto abusato. La ricerca è volta sostanzialmente a dare una descrizione sia del processo di innovazione, concezione e realizzazione di un nuovo software che delle pratiche di uso. Per quanto riguarda la progettazione del nuovo software attenzione sarà data alla parte organizzativa, in particolare oltre all'analisi del tipo di interazione, sarà studiato il codice sorgente del software prodotto come sarebbe analizzato un qualsiasi testo linguistico. Il ritorno che ci aspettiamo da quest'indagine è duplice. In primo luogo, una maggiore consapevolezza delle pratiche organizzative. Inoltre ci aspettiamo che possano emergere suggerimenti per miglioramento la concezione e l'interfaccia del software.
78
79
MEIER, 1998.
In particolare, l'eventuale "tour de table" regola un accesso « democratico » alla parola. Nelle riunioni in azien-
da, esso è tuttavia limitato a fasi specifiche (CUFF e SHARROCK, 1985).
Pagina 68
6 BIBLIOGRAFIA
Albero, B.,Linard, M., Robin J., (2008), Petite fabrique de l'innovation à l'université: Quatre parcours de pionniers, L'Harmattan
Atkinson, M.A., E.C. Cuff, J.R.E. Lee (1978) 'The recommencement of a meeting as a member's accomplishment'. In: J.N. Schenkein, ed., Studies in the organization of conversational interaction. New York: Academic Press: 13353
Atkinson, J.M., (1982), “Understanding formality: The categorization and production of ‘formal’ interaction”, British Journal of Sociology, 33, p. 86117.
Boden, D., (1994), The business of talk: organizations in action, Cambridge, Polity Press.
Bonu, B., (2007). Connexion continue et interaction ouverte en visiophonie, Réseaux, Vol. 25, n° 144, 2557.
Bonu, B., (2005). Les apprenants dans la mise en place des Espaces Numériques de Travail (ENT), Colloque SIF "Les institutions éducatives face au numérique", organisé par la Maison des Sciences de l’Homme Paris Nord avec le soutien du Ministère délégué à la Recherche, Carré des Sciences, Paris 12 et 13 décembre 2005 http://sif2005.mshparisnord.net/2007
Bonu, B., Charnet, C., (2007). Deployment of a Digital Worspace in Universities : an Innovation Process, Qwerty, vol.2, 520.
Cuff E.C., Sharrock W.W. (1985), “Meetings”, Handbook of discourse analysis, T.A. van Dijk, ed, London, Academic Press, vol. III, p. 14959.
Donato, D., (2007). Adunanza Digitale: la nascita di un movimento, in « TECNOLOGIE EMERGENTI E COSTRUZIONE DI CONOSCENZA », (a cura di M. B., Ligorio e S., Smiraglia), Script Web, ISBN:97888;89543;80;1.
Donato, D., Napolitano, F., (2007). Modellodel Software Libero e partecipazione civile, in Attidella Conferenza Italiana sul Software Libero, p 126 ‐133, Cosenza, 11 ‐12 ‐13 Maggio.
Donato, D., (2009), Il progetto Sacks, in Atti della Conferenza Italiana sul Software Libero, p 208213, Bologna, 1213 Giugno 2009
Drew P., Heritage J. (1992), Talk at work: interaction in institutional settings, Cambridge, Cambridge University Press.
Enfield N. J., Stivers, T. eds. (2007) Person Reference in Interaction: Linguistic, Cultural and Social Perspectives. Cambridge: Cambridge University Press
Free Software Foundation, (1991), GNU General Public License, Version 2,0, http://www.gnu.org/licenses/gpl.txt.
Pagina 69
Heath, C. C. et Luff. K., (1995). Coopération et crises: technologies multimédia dans les salles de commande du métro de Londres, Sociologie du Travail 4/04, XXXVI, pp. 523
545.
Hussley, W., (1999), “Role as an Interactional Device and Resource in Multidisciplinary Team Meetings”, Sociological Research Online, vol. 4, n° 3, www.socresonline. org.uk /socresonline/4/3/housley.html
Mehan, H., (1978), Structuring school structure. Harvard Educational Review 48:32 64.
Meier C. (1998), “In search of the virtual interaction order: investigating conduct in video
mediated work meetings”, (Arbeitsbericht Nr. 4), http://www.unibielefeld.de/soz/personen /bergmann/telekooperation.htm
Raymond, E., (1998). La cattedrale e il bazaar, http://www.apogeonline.com/openpress/cathedral
Schmitt, R., (2006), “Interaction in work meetings”, Revue Française de Linguistique Appliquée, 11/2, p. 6984
Schwartzman H. B. (1989), The Meeting. Gathering in Organizations and Communities, New York, Londres, Plenum Press.
Stallman, R., (1999), The GNU Operating System and the Free Software Movement, Speech http://www.umsec.umn.edu/events/RichardStallmanFreeSoftwareMovementand
GNULin
Stallman R., (1996), The free Software Definition, Free Software Foundation, http://www.gnu.org/philosophy/freesw.html
Pagina 70
FAME, A METHODOLOGY FOR ASSESSING SOFTWARE
MATURITY
Pani F. E., Concas G., DIEE - Università di Cagliari, p.zza d'Armi, 09123 Cagliari,
IT,
{filippo.pani, concas}@diee.unica.it
Sanna D., FlossLab srl, v.le Elmas 142, 09122 Cagliari, IT, daniele.sanna@flosslab.it
Abstract
Una soluzione software è costituita da singole componenti, ciascuna con caratteristiche peculiari, che
influiscono in modo determinante sulla sua qualità. La scelta ottimale di tali componenti costituisce,
quindi, una fase cruciale, in quanto un'eventuale scelta errata potrebbe comportare delle gravi
conseguenze: inefficienza, perdita di informazioni, possibile blocco delle attività operative, costi di
manutenzione e di riprogettazione.
Una delle principali problematiche è costituita dall'immenso panorama di applicazioni che si presenta
agli occhi di chi deve effettuare una scelta valutando la soluzione FLOSS più adeguata alle proprie
esigenze. Da tale considerazione bisogna partire, dunque, per comprendere lo sviluppo negli ultimi
anni di metodologie di valutazione per questo tipo di soluzioni. In tali metodologie, l'efficacia è il
primo obiettivo da perseguire, ma tale aspetto porta ad un aumento di complessità difficilmente
governabile sia dal punto di vista dei costi che delle competenze.
Gran parte dei framework presenti in letteratura è stata studiata e realizzata mediante un approccio
di ricerca, o comunque cercando di analizzare un elevato numero di fattori di valutazione, e non
sempre tali framework si sono rivelati adatti ad ambiti produttivi reali, a causa di una certa
“pesantezza” nella fase di analisi e di valutazione che non sempre è sostenibile, soprattutto da piccole
realtà produttive, siano esse pubbliche o private.
Il lavoro proposto intende indirizzare le problematiche di valutazione della maturità e dell'affidabilità
degli applicativi mediante una metodologia che riduca il grado di complessità di valutazione e che sia
pertanto declinabile in contesti quali quelli delle PP.AA. e delle PMI, puntando a massimizzare
l'efficienza della soluzione da trovare. Tale metodologia, denominata FAME (acronimo di Filter,
Analyze, Measure, Evaluate, ossia le quattro fasi principali di cui si compone), tiene conto delle reali
necessità di un'organizzazione senza l'utilizzo di sistemi di punteggio fissi e predefiniti, e fornisce un
valido supporto nella scelta di soluzioni di elevata qualità e con un’elevata probabilità di essere
sostenibili nel tempo.
Il principio alla base della scelta delle linee guida è basato sulla rispondenza ai requisiti di
completezza, semplicità, adattabilità e consistenza, propri di una valida metodologia che possa
effettivamente rappresentare un efficiente supporto nella fase decisionale.
L'approccio proposto è stato utilizzato con ottimi risultati da FlossLab srl, il primo spin-off
dell'Università di Cagliari.
Parole Chiave: Open Source software, software evaluation, technology transfer, software
quality, assessment model.
Pagina 71
1 INTRODUZIONE
Il software è alla base dell'automazione di ogni produzione tecnologicamente avanzata e di
tutta la moderna industria che tramite i sistemi informatici può gestire efficacemente ed
efficientemente le informazioni. Alla luce di ciò, la giusta scelta di un sistema informatico e
di ogni sua componente è fondamentale per il successo di tutti i processi di business, mentre
una scelta errata può portare a gravi conseguenze per gli obiettivi aziendali, quali
inefficienze, perdita di informazioni, costi di manutenzione, costi di riprogettazione e
inevitabili blocchi delle attività operative.
Negli ultimi anni, il Free/Libre/Open Source Software (FLOSS) si sta affermando come una
valida soluzione per le applicazioni software [1][2]. L'interesse crescente verso questo tipo di
approccio è evidente in tanti contesti differenti, come le comunità di singoli utenti, le aziende
private e le istituzioni pubbliche. Le ragioni di questo successo sono molteplici e non sempre
basate su aspetti prettamente tecnici, ma talvolta anche su elementi da ricercare nell'ambito
etico del mondo della produzione del software. È tuttavia possibile individuare alcuni
vantaggi di carattere tecnico-economico che riguardano il fenomeno dell'Open Source. Tra
questi, citiamo i seguenti:
I.
Costo. Solitamente, i prodotti FLOSS sono disponibili gratuitamente.
II.
Accesso al codice. E' possibile accedere e modificare il codice sorgente; ciò
comporta un continuo miglioramento del prodotto durante tutto il suo ciclo di vita.
III.
Architettura aperta e decentralizzata. Il FLOSS è sviluppato presso comunità virtuali,
decentralizzate dal punto di vista geografico; ne consegue uno sviluppo modulare più
semplice da gestire e da testare.
IV.
Qualità. Deriva direttamente dalle due caratteristiche precedenti, che permettono
un'evoluzione qualitativa notevole dei prodotti [3-7]. La Commissione Europea ha
finanziato diversi progetti di ricerca legati alla qualità del FLOSS: per esempio,
QualOSS [8], FLOSSMetrics [9], SQO-OSS [10] e QUALIPSO [11].
Una delle maggiori problematiche dovute alla notevole diffusione del FLOSS è rappresentata
dal vasto panorama di soluzioni software che si presenta davanti ai decisori, e che va,
dunque, adeguatamente studiato ed interpretato. Alcuni prodotti hanno il proprio sito web
come principale meccanismo di distribuzione per il software; tuttavia, gran parte delle
soluzioni FLOSS sono disponibili attraverso portali che fungono da repository dei progetti.
Su SourceForge, uno dei repository più importanti, sono circa duecentomila i progetti
ospitati. La miriade di prodotti FLOSS esistenti comporta, dunque, la necessità di disporre di
un metodo di valutazione e selezione adatto alle caratteristiche del FLOSS, mediante il quale
sia possibile esaminare con precisione i vincoli ed i rischi specifici relativi all'adozione di un
determinato software [12-17].
Per un'organizzazione, la valutazione del software da scegliere come componente del proprio
sistema informativo è un processo critico. Tale scelta si basa sull'analisi dei bisogni e dei
requisiti tecnici, funzionali, strategici ed economici, e sull'adeguatezza e soddisfacimento di
tali requisiti e bisogni da parte del software. La valutazione deve essere al tempo stesso un
processo facile, valido ma soprattutto attendibile, che permetta di prendere delle decisioni
Pagina 72
importanti sul futuro dello sviluppo aziendale. Nella pratica non esiste, però, un modello
standard e ampiamente utilizzato: ciò complica l'adozione del FLOSS.
Negli ultimi anni sono state definite diverse metodologie per il supporto alla selezione di
prodotti FLOSS: alcuni di questi modelli sono basati sulla valutazione soggettiva di un certo
numero di parametri e sull'attribuzione di un valore peso in relazione all'importanza di
ciascun parametro. La valutazione ottenuta tramite il punteggio finale non è, quindi,
universale ma utile solo ad aziende di tipo omogeneo [18-22].
Una metodologia di valutazione della maturità e affidabilità del software va implementata
pensando alla sua flessibilità e alla sua applicabilità sia a grandi che a piccole entità; tale
valutazione deve tenere conto non solo delle caratteristiche tecniche del prodotto e della
qualità della comunità di sviluppo coinvolta, ma anche dell'analisi costi-benefici specifici
dell'organizzazione coinvolta. In questo senso, il lavoro proposto intende indirizzare lo studio
da un ambito più propriamente di ricerca verso un ambito produttivo e reale, mediante una
metodologia, FAME, in grado di ridurre il grado di complessità di valutazione.
2 METODOLOGIE DI VALUTAZIONE DEL SOFTWARE
In questa sezione presentiamo gli esempi più rappresentativi di quanto offerto dalla letteratura
scientifica relativamente alla valutazione di prodotti FLOSS. Durante il lavoro di studio di
tali modelli, si è cercato di individuare vantaggi e svantaggi in modo da trarne elementi utili
alla costruzione di un valido framework decisionale.
2.1
OSSM di Capgemini
Il metodo OSMM (Open Source Maturity Model), sviluppato da Capgemini nel 2003, utilizza
sei passi per cercare di determinare quale prodotto risponda meglio alle esigenze di
un'organizzazione [23].
Per Capgemini uno dei fattori più importanti è quello della maturità del prodotto; infatti,
quanto più un progetto è maturo più è stabile e solido. OSMM non permette di paragonare i
prodotti commerciali con quelli open ed è bene precisare che questa non è una limitazione del
metodo, ma una ferma convinzione degli autori.
Il metodo si compone dei seguenti sei passi:

ricerca dei prodotti;

calcolo del punteggio dello specifico prodotto;

intervista con il cliente volta all’attribuzione dei pesi;

applicazione dei pesi da parte del cliente in collaborazione con Capgemini;

determinazione del punteggio finale e selezione del prodotto;

valutazione.
Pagina 73
2.2
OSSM di Navica
Tale metodologia è stata sviluppata nel 2004 [24] e si compone di tre fasi fondamentali:

valutazione della maturità degli elementi e assegnazione di un punteggio;

definizione di un fattore peso in base ai requisiti organizzativi;

calcolo del punteggio complessivo di maturità del prodotto.
La valutazione di un software che basa il proprio metodo sull'OSMM assume che la validità e
la solidità di un prodotto Open Source siano direttamente proporzionali alla maturità di un
progetto. Secondo la definizione proposta, un prodotto può essere considerato maturo quando
possiede le caratteristiche di completezza, livello di qualità elevato, longevità, aggiornabilità
e robustezza. La maturità di un prodotto è la chiave per capire il grado di soddisfazione
offerto dal prodotto stesso. Un software è considerato maturo quando il team di sviluppo è
attento alle funzionalità del prodotto ma anche quando progetta una rigorosa attività di
rilascio e di supporto.
2.3
QSOS
Il metodo QSOS (Qualification and Selection of Software Open Source), definito nel 2004
dalla Atos Origin e distribuito con licenza GPL, suddivide il proprio template in due tipologie
di sezione: una generica e una specifica [21]. La sezione specifica è relativa ad una
particolare famiglia di applicazioni (database, Content Management System, ecc.).
Questo metodo si compone di quattro fasi indipendenti ed iterative per valutare un prodotto:

Definition: definizione dei fattori di valutazione da utilizzare nei passi successivi.

Evaluation: valutazione del software su tre assi funzionali: copertura funzionale, rischio
per l'utente e rischio per il fornitore. Ogni asse contiene più criteri.

Qualification: qualificazione di uno specifico contesto dell'utente (azienda o individuo)
per la pesatura dei criteri precedenti.

Selection: selezione e comparazione dei prodotti software, applicando il filtro preparato
al terzo passaggio sui dati forniti dai primi due step.
2.4
OpenBRR
OpenBRR (Open Business Readiness Rating) è stato sviluppato da SpikeSource e Intel
Corporation nel 2005; si propone come modello di valutazione open e standard dei software
Open Source e dà particolare enfasi alle caratteristiche riguardanti il business [25].
Questa metodologia è caratterizzata da quattro differenti fasi:
Pagina 74
Figura 1. Fasi del modello OpenBRR
L'OpenBRR prevede la suddivisione delle metriche in 12 aree differenti (Functionality,
Usability, Quality, Security, Performance, Scalability, Architecture, Support, Documentation,
Adoption, Community, Professonalism). Attraverso un'analisi degli scopi per cui un
determinato software deve essere utilizzato e, dunque, attraverso una raccolta dei requisiti in
base a chi, dove e perché deve utilizzare il software, si determinano delle priorità per le
diverse aree attraverso valori percentuali.
2.5
OpenBQR
Il metodo OpenBQR (Open Business Quality Rating) è stato sviluppato nel 2006 presso
l’Università degli Studi dell’Insubria (Como) e rappresenta una fusione tra le differenti
qualità dei metodi OpenBRR e QSOS, a cui introduce nuove aree di valutazione e modifica la
procedura in modo tale da considerare prima quali siano gli elementi da valutare assegnando
loro un peso, e successivamente, in base all'importanza attribuita, valuta quali elementi
saranno da stimare [26].
Il processo di valutazione si sviluppa in tre fasi:

Quick Assessment Filter;

Data Collection and Processing;

Data Translation.
2.6
QualOSS
L'obiettivo strategico di QualOSS (Quality of Open Source Software) è quello di migliorare la
posizione competitiva dell'industria software europea fornendo metodologie e strumenti per
migliorare la produttività e la qualità dei prodotti software [8]. Per raggiungere questo scopo,
è proposta una metodologia di alto livello da utilizzare nello sviluppo industriale, in modo
tale da abilitare la valutazione delle prestazioni per supportarne lo sviluppo e l'evoluzione.
Un'assunzione centrale e importante nella definizione del modello afferma che la qualità di
un prodotto software non è solo legata al prodotto in sé (codice, documentazione, ecc.), ma
anche al modo in cui il prodotto è sviluppato e distribuito. Per questa ragione, e sin da quando
lo sviluppo di un prodotto Open Source è sotto la responsabilità di una comunità aperta, il
Pagina 75
modello QualOSS tiene conto in parti uguali sia dei problemi del prodotto che di quelli legati
alla comunità.
2.7
SQO-OSS
Il modello di qualità SQO-OSS (Software Quality Observatory for Open Source Software),
definito nel 2007, ha l'obiettivo di supportare un sistema automatico di valutazione [10]. Le
sue variabili, quindi, sono principalmente orientate alla valutazione di metriche per cui è
minimo l'intervento umano. Tale modello si propone di valutare tutti gli aspetti dello sviluppo
di un software Open Source, sia dal punto di vista del codice che della comunità.
Il modello di qualità SQO-OSS si distingue dagli altri modelli per diverse ragioni:
principalmente, è stato costruito con l'obiettivo dell'automazione e cerca di differenziarsi dal
resto degli altri modelli che richiedono pesanti interfacce utente e mancano di automazione
nella ricerca delle metriche. SQO-OSS non valuta la funzionalità; si pensa, infatti, che la
valutazione della funzionalità richieda che chi debba valutare il prodotto giochi un ruolo
importante nel processo di valutazione e, dunque, introduca soggettività. Il modello si
focalizza perciò su altri aspetti fondamentali della qualità di un software Open Source, quali
maintainability, reliability e security.
2.8
EFFLOSS
EFFLOSS (Evaluation Framework FLOSS) nasce nel 2007 e ha come obiettivo quello di
effettuare una valutazione utilizzando solo metriche quantitative e non qualitative [22].
Il processo di valutazione è suddiviso in tre step:

nella prima fase si determinano tutti quei fattori che potrebbero influenzare la qualità e il
successo di un progetto Open Source, allo scopo di effettuare una prima analisi del
prodotti software;

nella seconda fase si identificano le metriche di successo, suddivise in tre grandi aree:
caratteristiche di processo, qualità del sistema, misure quantitative di adozione;

nell'ultima fase del framework si valutano le metriche nella loro complessità con
l'assegnazione di un punteggio. Tale punteggio alle volte non è immediatamente
definibile e deve essere trattato con tecniche di normalizzazione.
2.9
NVAF
Il framework NVAF (Needs, Values and Assessment Framework) nasce per fornire delle
linee guida nella scelta delle soluzioni IT da adottare a supporto delle Pubbliche
Amministrazioni [27]. Le differenti soluzioni IT per cui si effettua la comparazione non sono
vincolate alle sole soluzioni FLOSS, ma anche a quelle proprietarie (se è necessario
considerarle). La scelta finale si baserà sul massimo value for money ottenuto,
massimizzando in questo modo i benefici, minimizzando gli svantaggi e tenendo in
considerazione una serie di vincoli dipendenti dall'entità che deve effettuare la valutazione.
Il framework è suddiviso nei seguenti step:

identificazione e valutazione dei bisogni dell'organizzazione;
Pagina 76

identificazione delle priorità per gli obiettivi chiave;

identificazione e valutazione dei vincoli e dei rischi;

definizione di un framework prioritario.
3 FAME: FILTER, ANALYZE, MEASURE AND EVALUATE
APPROACH
FAME (acronimo di Filter, Analyze, Measure, Evaluate, ossia le quattro fasi principali di cui
si compone), può essere considerato un'evoluzione delle metodologie di valutazione.
L'approccio proposto tiene conto delle reali necessità di un'organizzazione e fornisce un
valido supporto nella scelta di soluzioni mature, affidabili e con un’elevata probabilità,
quindi, di essere sostenibili nel tempo.
Il principio nella scelta delle linee guida è rappresentato dalla semplicità dell’applicazione, in
modo da fornire uno strumento il più possibile user friendly che possa effettivamente essere
utilizzato nella fase decisionale e che nasca da un’analisi della fase di valutazione intesa
come bilancio tra costi e benefici (come qualsiasi attività produttiva). L’obiettivo strategico
consiste nell'individuazione di una raccolta di criteri sufficienti e significativi per ogni
tipologia di software, in modo da potere confrontare tutti gli aspetti possibili che possano
avere effetto sui benefici. L'analisi tiene conto sia degli aspetti tecnico-funzionali che di
quelli economico-sociali, al fine di individuare la soluzione migliore sotto questi aspetti,
evitando l'utilizzo massiccio di risorse e mantenendo, pur in un piano di relativa semplicità,
quelle caratteristiche di generalità e completezza che possano rendere la metodologia
proposta un valido strumento di supporto nella fase decisionale per le Pubbliche
Amministrazioni e per i contesti aziendali.
FAME riprende alcuni punti di forza del framework NVAF [28], di cui può essere
considerato una semplificazione; tra questi, l'individuazione esplicita, nell'analisi, di elementi
economico-sociali (non utilizzati in altre metodologie). Inoltre, FAME ripropone il metodo
della normalizzazione delle metriche non omogenee, che permette, al momento della
valutazione, di non vincolare le fasce di valutazione, come avviene in altre metodologie.
Quindi, tali fasce non sono definite a priori, e ciò conferisce al framework una struttura
semplice ed adattabile a diversi contesti. NVAF si basa sul presupposto cardine che la
possibilità di effettuare una valutazione non sia definita a priori ma derivi direttamente da
esigenze, strategie e obiettivi che l'organizzazione si propone: tale approccio potrebbe
comportare una più lunga fase di analisi ed essere, quindi, controproducente per le piccole
organizzazioni. FAME si propone di eliminare questo svantaggio, cercando di snellire e
rendere più immediata tale fase.
La struttura del modello è rappresentata in Figura 2:
Pagina 77
Figura 2. Fasi del modello FAME
3.1
Filtering
Il primo step di FAME consiste nella scelta dei progetti che soddisfano i requisiti minimi
legati alla particolare esigenza. NVAF non entra, infatti, in merito ai criteri utilizzati per
l'individuazione delle soluzioni candidate alla comparazione, in quanto utilizza informazioni
sulla tipologia del software da comparare, ma non informazioni specifiche sul prodotto. È
impensabile e controproducente procedere alla successiva fase di valutazione su un numero
eccessivo di opzioni, considerando che il panorama del software a disposizione è vasto e
complesso.
In questa prima fase occorre una scrematura che permetta di ridurre in maniera considerevole
il numero di soluzioni candidate; questo è possibile grazie al reperimento di una serie di
informazioni preliminari che si possono trovare nei principali software repositories, e che
permettono di costruire un profilo generale sulla soluzione di interesse. Ovviamente, nel caso
di software proprietario non potranno essere ricavate tutte le informazioni che invece sono
più o meno facilmente reperibili per un software Open Source. Le informazioni raccolte
permetteranno di costruire una carta d'identità del progetto; mediante tale carta, si potrà
effettuare una prima valutazione di filtraggio totalmente qualitativa ma efficace, con
l'identificazione di tutti quei software che possono effettivamente rispondere alle esigenze
strategiche e ai vincoli dell'organizzazione che deve effettuare la valutazione.
3.2
Analysis
Ridotto il numero dei software candidati mediante la fase di filtraggio, si potrà passare a
quella successiva, che consiste nell'identificazione dei bisogni e la definizione delle metriche
associate. Tale fase è quella più critica in una metodologia di valutazione: una corretta
Pagina 78
definizione di tali fattori permette alla valutazione di rispecchiare l'effettiva aderenza del
prodotto alle necessità dell'organizzazione valutante.
La metodologia prevede la suddivisione dell'indagine in due macro-aree:
V.
Analisi tecnico-funzionale. Ci si avvale della valutazione della qualità di un prodotto
analizzata dall'ingegneria del software, e si considerano non solo le metriche di
qualità intrinseca ma anche le metriche che valutano la qualità del processo.
VI.
Analisi economico-sociale. Per la natura complessa di questo tipo di analisi, la
singola organizzazione ha la responsabilità della scelta dei principali fattori
economico-sociali in virtù delle specifiche scelte strategiche e del livello di dettaglio
da raggiungere in tale fase.
In questo step, FAME adotta un approccio di tipo aperto, ossia individua le modalità di
identificazione delle metriche senza però definirle in maniera esplicita (nella forma chiusa, è
il modello stesso che definisce integralmente le metriche). La soluzione mediante una forma
aperta permette di capire le effettive necessità dell'organizzazione, rendendosi in questo modo
uno strumento utile in ambito produttivo.
Nella fase di Analysis, inoltre, si introduce l'uso di una scala di priorità per conferire alla
metodologia di valutazione una caratteristica di dinamicità e adattabilità al contesto
considerato. FAME suggerisce al team di valutazione due modalità per la valutazione globale
delle priorità: breve meeting tra le persone coinvolte per raggiungere una definizione
comune, oppure valutazione individuale e successiva mediazione tra i risultati raccolti. Le
definizioni delle priorità servono per due motivi: il primo è quello di ridurre, se possibile, il
numero di bisogni, eliminando eventualmente le metriche legate a dei bisogni aventi una
bassa priorità; il secondo è legato alla possibilità di attribuire successivamente un peso che
rispecchi la valutazione della priorità del bisogno da cui esso deriva.
3.3
Measurement
Nella terza fase, le metriche identificate vengono valutate utilizzando differenti unità di
misura, a seconda della loro specificità. Alcune metriche potranno assumere un valore binario
(sinonimo di caratteristica presente o assente), altre dei punteggi (su una scala da 1 a 5, per
esempio), altre ancora un valore indice di un costo o di un risparmio. In generale, non esiste
una regola precisa: la scala di variazione o il valore da utilizzare dovranno essere
commisurati alla metrica da calcolare.
Poiché i punteggi derivano da metriche non omogenee, occorrerà effettuare preliminarmente
una normalizzazione dei risultati per far sì che tali valori siano confrontabili. In questa fase,
inoltre, viene applicato un coefficiente peso agli elementi valutati in accordo con la rilevanza
dei rispettivi bisogni, stabilita nella precedente fase. La metodologia traccia delle linee guida
per effettuare la normalizzazione.
Nel caso dei costi si dovrà utilizzare la seguente formula:
S=
C minC max −C ij 
C max 
Pagina 79
I.
S è il punteggio normalizzato;
II.
C min è il prezzo più basso tra le alternative;
III.
C max è il prezzo più alto tra le alternative;
IV.
C ij è il prezzo della voce da normalizzare.
Nel caso in cui la metrica è tanto più positiva quanto maggiore è il suo valore:
S=
V ij
V max
I.
II.
V ij è il valore della metrica da normalizzare;
III.
V max è il valore massimo che la metrica ha assunto tra le soluzioni da comparare.
Nel caso in cui la metrica è tanto più positiva quanto minore è il suo valore:
S =1−
V ij
V max
IV.
V.
V ij è il valore della metrica da normalizzare;
VI.
V max è il valore massimo che la metrica ha assunto tra le soluzioni da comparare.
In tutti gli altri casi in cui la formulazione dei bisogni abbia portato alla definizione di una
metrica qualitativa, si dovrà normalizzare dividendo ciascun risultato per il valore massimo
attribuibile nella scala considerata, in modo da ottenere sempre dei valori compresi tra 0 e 1.
3.4
Evaluation
L'ultima fase è quella della valutazione. Effettuate tutte le normalizzazioni, i valori ottenuti
sono moltiplicati per il peso associato alla relativa metrica. Ogni soluzione avrà un punteggio
finale ottenuto dalla somma dei parziali assegnati ad ogni elemento di valutazione. Basta
sommare i risultati parziali per capire qual è il progetto candidato che meglio soddisfa i
requisiti individuati (ossia, il prodotto che avrà ottenuto il punteggio più alto).
In pratica, un punteggio Pij viene assegnato a ogni soluzione proposta Sj, dove 0 <= Pij <=
Wi per ogni elemento Ei basato su metrica Mi associata a tale elemento (Wi è il peso
associato a Ei). Quindi, ogni soluzione avrà un punteggio totale Pjtot. La soluzione col
punteggio Pjtot più alto sarà la soluzione prescelta.
Pagina 80
4 CONCLUSIONI
La valutazione per la scelta di un sistema informatico è sicuramente un'attività critica in cui le
organizzazioni devono avvalersi del know-how dei propri esperti IT allo scopo di effettuare
una selezione oculata ed evitare di incappare in successivi problemi che una scelta errata
solitamente comporta. Spesso tali esperti non adottano particolari metodi e si affidano
esclusivamente alla propria esperienza o a quella derivante dal semplice passaparola.
In questo lavoro abbiamo presentato FAME, una metodologia di valutazione della maturità
delle soluzioni FLOSS in grado di adattarsi alle esigenze specifiche di un'organizzazione.
FAME si propone come una metodologia semplificata allo scopo di renderne facile l'utilizzo
anche per piccole realtà produttive. Esso tiene conto delle reali necessità di un'organizzazione
senza l'uso di sistemi di punteggio fissi e predefiniti.
FAME soddisfa i requisiti di completezza, semplicità, adattabilità e consistenza, propri di una
valida metodologia che possa effettivamente rappresentare un efficiente supporto durante la
fase decisionale.
Bibliografia:
[1] Feller, J., Fitzgerald, B., Hissam, S. e Lakhani, K. (2005). Perspectives on Free and Open
Source Software. MIT Press, Cambridge, MA.
[2] Free/Libre and Open Source Software: Survey and Study: Final Report (2003).
Disponibile su: http://FLOSS.infonomics.nl
[3] Senyard, A. e Michlmayr, M. (2004). How to have a successful free software project.
APSEC, IEEE Computer Society, pp. 84–91.
[4] Antoniades, I. P., Stamelos, I., Angelis, L. e Bleris, G. L. (2003). A novel simulation
model for the development process of open source software projects. International Journal
of Software Projects: Improvement and Practice (SPIP), special issue on Software Process
Simulation and Modeling.
[5] Feller, J. e Fitzgerald, B. (2000). A framework analysis of the open source software
development paradigm, ICIS, pp. 58-69.
[6] Gonzalez-Barahona, J. M., Pérez, M. A. O., Quiros, P. d. l. H., Gonzalez, J. C. e Olivera,
V. M. (2001). Counting potatoes: the Size of Debian 2.2, Upgrade - The European Online
Magazine for the IT Professional, Vol. II, No. 6, pp. 61-67.
[7] Mockus, A., Fielding, R. T. e Herbsleb, J. (2000). A case study of open source software
development: the Apache server. ICSE: Proceedings of the 22nd international conference
on Software engineering, ACM Press, New York, NY, USA, pp. 263-272.
[8] QUALOSS (2008). http://www.qualoss.org
[9] FLOSSMetrics (2008). http://flossmetrics.org
[10] SQO-OSS (2008). http://www.sqo-oss.eu
[11] QUALIPSO (2008). http://www.qualipso.org
[12] Michlmayr, M. (2005). Software process maturity and the success of free software
projects, in Zielinski, K. e Szmuc, T. (Eds.), Software Engineering: Evolution and
Emerging Technologies. IOS Press, pp. 3-14.
[13] Stewart, K. J. e Ammeter, T. (2002). An exploration study of factors influencing the
level of vitality and popularity of open source projects, in Applegate, R. L and De Gross,
Pagina 81
J. I. (Eds.). Proceedings of the Twenty-Third International Conference on Information
Systems, pp. 853-857.
[14] Weiss, D. (2005). A large crawl and quantitative analysis of open source projects hosted
on sourceforge. Research Report RA-001/05, Institute of Computing Science, Poznań
University of Technology, Poland.
[15] Weiss, D. (2005). Measuring success of open source projects using web search engines.
Proceedings of the The First International Conference on Open Source Systems, pp. 9399.
[16] Crowston, K., Annabi, H. e Howison, J. (2003). Defining open source software project
success. International Conference on Information Systems (ICIS), pp. 327-340.
[17] Crowston, K., Annabi, H., Howison, J. e Masango, C. (2004). Towards a Portfolio of
FLOSS project success measures. Workshop on Open Source Software Engineering,
International Conference on Software Engineering, Edinburgh, Scotland, UK.
[18] Cau, A., Concas, G. e Marchesi, M. (2006). Extending OpenBRR with automated
metrics to measure object oriented open source project success. The Workshop on
Evaluation Frameworks for Open Source Software, The Second International
Conference on Open Source Systems.
[19] Ciolkowski, M. e Soto, M. (2008). Towards a Comprehensive Approach for Assessing
Open Source Projects. Proceedings of the international Conferences on Software Process
and Product Measurement (Munich, Germany), Lecture Notes In Computer Science,
SpringerVerlag, Berlin, Heidelberg, Vol. 5338, pp. 316-330.
[20] Deprez, J. C. e Alexandre, S. (2008). Comparing assessment methodologies for
free/open source software: OpenBRR & QSOS. Lecture Notes in Computer Science,
Springer.
[21] Atos Origin (2006). Method for Qualification and Selection of Open Source software
(QSOS), version 1.6. Disponibile su: http://qsos.org
[22] Cau, A. (2007). EFFLOSS: An Evaluation Framework for Free/Libre Open Source. PhD
Thesis.
[23] Duijnhouwer, F. W. e Widdows, C. (2003). Open Source Maturity Model (Capgemini).
[24] Golden, B. (2004). Succeeding with Open Source. Addison-Wesley Professional.
[25] Business Readiness Rating (2005). A Proposed Open Standard to Facilitate Assessment
and Adoption of Open Source Software. Disponibile su: www.openbrr.org
[26] Taibi, D., Lavazza, L. e Morasca, S. (2007). OpenBQR: a framework for the assessment
of OSS. IFIP International Federation for Information Processing, Springer, Boston,
pp.173-186.
[27] Mannaro, K., Concas, G. e Marchesi, M. (2006). NVAF: un Framework per una valutazione di tipo comparativo delle soluzioni software nelle Pubbliche Amministrazioni. The Second International Conference on Open Source Systems, Esperta Workshop, Como (I).
Pagina 82
IMPACT AND ECONOMIC RISK ASSESSMENT OF FLOSS
ADOPTION BY PUBLIC ADMINISTRATIONS
Cocco L., Marchesi M., Pani F. E., DIEE - Università di Cagliari, p.zza d'Armi,
09123 Cagliari, IT, {luisanna.cocco, michele, filippo.pani}@diee.unica.it
Abstract Il fenomeno FLOSS offre grandi opportunità sia dal punto di vista economico sia dal punto di vista
sociale, e il portavoce più credibile di questa grande rivoluzione è la Pubblica Amministrazione, che
dovrebbe assumere il ruolo di principale promotrice del FLOSS per garantire forti risparmi nel medio
e lungo termine e, soprattutto, per sostenere la diffusione di competenze e il rafforzamento di reti
locali di imprese. Dalle recenti relazioni annuali sullo stato dell'ICT nella Pubblica Amministrazione,
ad opera del CNIPA, emerge un quadro di una P.A. caratterizzata da scarsità di risorse umane e
finanziarie. La spesa ICT è gestita da molteplici centri decisionali e le Amministrazioni non
possiedono un quadro completo e aggiornato. Tutto questo è aggravato dal fatto che il fornitore
esterno, a cui la P.A. si rivolge, si occupa sia della progettazione sia della realizzazione degli
interventi; si ricorre all'innovazione sotto la spinta degli operatori di mercato e non dopo un'attenta
analisi dei fabbisogni informativi e funzionali degli utenti. Ciascuna Amministrazione dovrebbe
sviluppare al proprio interno un centro di R&S, che sia in grado di gestire e fornire almeno in parte
alla P.A. l'intero fabbisogno di IT di cui necessita. Le soluzioni FLOSS risultano essere un valido
aiuto per la P.A., grazie alla loro estrema versatilità e adattabilità, e al fatto che permettono di
risparmiare sui costi delle licenze.
Partendo da un modello economico basato sulla teoria della crescita endogena, abbiamo studiato
come gli investimenti in soluzioni FLOSS influenzano l'andamento dei tassi di crescita di alcune
grandezze fondamentali per la crescita di un'organizzazione, rispetto agli incrementi delle stesse
grandezze derivanti da investimenti in software proprietario (PROPS). Le grandezze analizzate sono il
capitale ICT e non ICT, la produttività, il capitale umano e lo sviluppo tecnologico prodotto. In tale
modello riveste un ruolo fondamentale il capitale umano che, sviluppando le proprie abilità e
conoscenze, incrementa la produttività dell'intero sistema, e la ricerca e lo sviluppo (R&S), essenziali
per la crescita aziendale. Abbiamo risolto il modello economico, rappresentato da un complesso
sistema di equazioni, attraverso la costruzione di un dimostratore software in ambiente MatlabSimulink. In particolare, tale solutore studia come variano nel tempo le grandezze in gioco al variare
dei parametri, in un periodo di tempo T pari a 200 mesi e con un passo temporale pari a 1 mese. Le
simulazioni eseguite evidenziano che investire in software FLOSS comporta un incremento maggiore
dei tassi di crescita dei capitali ICT e non ICT, della produttività, del capitale umano e della
tecnologia, rispetto agli incrementi delle stesse grandezze derivanti però da investimenti in software
proprietario. Per valutare il rischio economico ed operativo legato all'adozione di FLOSS, abbiamo
proposto un secondo dimostratore software, realizzato anche in questo caso in ambiente MatlabSimulink, che implementa il metodo Monte Carlo, effettuando un elevato numero di simulazioni del
modello economico di crescita endogena. Ad ogni simulazione, il dimostratore estrae i valori delle
variabili in input dalle corrispondenti distribuzioni statistiche, e calcola una serie di parametri
statistici dei dati in output, necessari per eseguire accurate analisi del rischio relative ad investimenti
in software FLOSS. E' stato, infine, realizzato un solutore in codice Matlab che implementa sempre il
metodo Monte Carlo, ma ci permette di effettuare un numero ancora più elevato di simulazioni del
modello economico. I risultati ottenuti hanno dimostrato come l'introduzione di soluzioni FLOSS non
comporta alcun rischio significativo. L'introduzione dell'aleatorietà nelle variabili in input comporta,
Pagina 83
infatti, soltanto una diminuzione dei tassi di crescita delle grandezze, ma non una diminuzione tale da
causare rischi economici ed operativi.
Parole Chiave: software libero, Pubbliche Amministrazioni, investimenti IT, modelli
economici.
1 INTRODUZIONE
L'avvento di Internet ha dato il via ad una vera e propria rivoluzione in campo informatico.
La progettazione e la realizzazione dei sistemi software basata su soluzioni chiuse è stata
rimpiazzata da modelli di produzione che puntano all'interoperabilità e alla cooperazione tra
sistemi. Questo ha reso possibile l'accesso da remoto ad applicazioni e basi dati, facilitando
così la cooperazione tra enti pubblici e cittadini, tra enti pubblici e aziende e tra sedi aziendali
dislocate in diverse parti del territorio nazionale o mondiale. La nascita di Internet ha
permesso, inoltre, lo sviluppo del FLOSS, un processo di produzione del software che si
differenzia sostanzialmente dalla produzione del software proprietario per le sue due
principali caratteristiche: apertura del codice sorgente e libera distribuzione.
Negli ultimi anni il FLOSS ha raggiunto una maturità tale da consentire un'adozione di
massa; tale adozione offrirebbe al mondo intero grandi opportunità di sviluppo, sia sociale
che economico. Liberarsi dai vincoli, propri del sistema di produzione del software
proprietario, consentirebbe di informatizzare e rendere molto più trasparenti ed efficienti le
relazioni e le pratiche tra enti pubblici o tra sedi aziendali; potrebbe portare a forti risparmi
nel medio e nel lungo termine, a una minore dipendenza dai fornitori, alla diffusione di
competenze a al rafforzamento di reti locali d'imprese [1].
Scopo del lavoro proposto è la descrizione dell studio accurato svolto per avanzare lo stato
dell’arte relativamente alle problematiche economiche e pratiche legate all’adozione di
software FLOSS, soprattutto da parte delle PP.AA. [2][3]. Lo sviluppo di competenze,
metodiche e strumenti in tale settore è estremamente importante per un'organizzazione che
non voglia solo curare l'aspetto tecnologico-informatico del FLOSS, ma miri ad assistere e
soddisfare il cittadino.
2 L'ITALIA E IL FLOSS
Il nostro Paese è caratterizzato dalla presenza di un gran numero di piccole software house
[1], che operano come system integrator e sviluppano applicazioni per small business. Tali
imprese sono escluse dal mercato della Pubblica Amministrazione dal momento che un tale
mercato non è compatibile con le loro piccole dimensioni. Il FLOSS può essere un valido
aiuto per tali aziende, dal momento che, grazie alle particolari caratteristiche di produzione
del FLOSS, le aziende possono consorziarsi fra loro al fine di produrre un solo prodotto
software, collaborando così alla realizzazione di grandi progetti; al contrario di quanto accade
nella produzione di software proprietario, dove le aziende operano ognuna
Pagina 84
indipendentemente dalle altre e impegnano talvolta investimenti enormi. Inoltre, il FLOSS
costituisce una spinta all'uso delle tecnologie più moderne: un progetto FLOSS si sviluppa,
infatti, a partire dalle esigenze di un individuo o di un gruppo, e mirando a massimizzare il
beneficio dell'individuo e non il profitto di un'azienda. Esso punterà, quindi, all'utilizzo di
tecnologie sempre più avanzate.
Sulla base delle osservazioni riportate, si può concludere che il fenomeno FLOSS offre
grandi opportunità sia dal punto di vista economico sia dal punto di vista sociale, e il
portavoce più credibile di questa grande rivoluzione è la Pubblica Amministrazione, che
dovrebbe assumere il ruolo di principale promotrice del FLOSS per garantire forti risparmi
nel medio e lungo termine e, soprattutto, per sostenere la diffusione di competenze e il
rafforzamento di reti locali di imprese. Se tutte le PP.AA. italiane investissero in soluzioni
FLOSS, si assisterebbe ad uno sviluppo dell'industria del software su tutto il territorio
nazionale, ad un maggior riuso delle soluzioni software sviluppate fra tutte le PP.AA., ad un
potenziale risparmio nei costi di sviluppo e ad una minore dipendenza dai fornitori
(fenomeno del lock-in).
2.1
Panoramica sullo stato dell'ICT nella P.A. italiana
Dalla relazione annuale sullo stato dell'ICT nella Pubblica Amministrazione Centrale, ad
opera del CNIPA [4], emerge un quadro di una P.A. caratterizzata da scarsità di risorse
umane e finanziarie, che produce cambiamenti a piccoli passi, conseguendo leggeri ma non
sostanziali miglioramenti rispetto a quanto rilevato in passato.
Gli ostacoli presenti nella P.A. continuano a restare immutati e toccano diversi aspetti:
gestionali, organizzativi ed economici. La spesa ICT di una P.A. è gestita da molteplici centri
decisionali e le Amministrazioni non possiedono un quadro completo e aggiornato; non ci
sono analisi o valutazioni che permettono all'organizzazione di adottare strumenti che
riducano la spesa preventivata, le ridondanze o la non interoperabilità; il riuso delle soluzioni
software fra PP.AA. è molto ridotto; il personale informatico è nella maggior parte dei casi di
età elevata e il livello di competenza tecnico-gestionale non è sempre adeguato, per cui il
ricorso a fornitori esterni per l'analisi dei fabbisogni, per l'individuazione delle soluzioni e per
il governo dei progetti è nella maggior parte dei casi una scelta obbligata; il fornitore esterno
a cui la P.A. si rivolge si occupa sia della progettazione sia della realizzazione degli
interventi; non esiste un ente che definisce gli obiettivi del progetto e mette a disposizione i
mezzi necessari, considerando le finalità complessive di servizio di tutte le PP.AA.; si
continua a privilegiare il supporto ai procedimenti amministrativi e al funzionamento a
scapito della domanda esterna di servizi e di semplificazione amministrativa; non sono ancora
pienamente disponibili e accessibili le basi dati e di informazioni di importanza rilevante per
il funzionamento di una P.A., come anagrafi sulla popolazione esistente, imprese o catasto; è
presente una produzione di banche dati spesso ridondanti e non collegate fra loro, a causa
della scarsa cooperazione tra PP.AA; si ricorre all'innovazione sotto la spinta degli operatori
di mercato e non dopo un'attenta analisi dei fabbisogni informativi e funzionali degli utenti; i
servizi on-line aumentano ma non si ha un effettivo riscontro della soddisfazione del cliente;
la condivisione dei patrimoni informativi e l'avvio di investimenti ICT per la cooperazione
applicativa è ancora un traguardo lontano; i diversi contesti culturali nel governo
amministrativo delle ICT non facilitano l'ottimizzazione delle spese e la condivisione di
soluzioni per la gestione contabile, per il controllo di gestione o per la gestione del personale.
Comuni e province non svolgono sufficienti attività di studio, progettazione e sviluppo
Pagina 85
software; infatti, nei comuni di grandi dimensioni, il 44% della spesa IT è relativa all'acquisto
di servizi, il 31% al software e il 25% all'hardware [5][6]. Tale spesa è rivolta sia all'acquisto
di soluzioni FLOSS sia all'acquisto di soluzioni proprietarie. Le soluzioni FLOSS sono però
adottate prevalentemente lato server, e l'uso di applicazioni desktop FLOSS risulta ancora
molto basso. Inoltre, solo i centri di ricerca pubblica, come l'ISTAT e il CNR, gestiscono i
propri sistemi FLOSS con personale interno.
Ciascuna Amministrazione dovrebbe mirare alla massimizzazione del benessere collettivo,
sviluppando al proprio interno le competenze necessarie a svolgere attività di analisi dei
fabbisogni, di individuazione delle soluzioni, di realizzazione e gestione dei progetti
software. Essa dovrebbe sviluppare al proprio interno un centro di R&S, che sia in grado di
gestire e fornire almeno in parte alla P.A. l'intero fabbisogno di IT di cui necessita, o almeno
di supervisionare efficacemente le forniture esterne.
2.2
Benefici prodotti da un investimento in soluzioni FLOSS da parte di PP.AA.
Elenchiamo brevemente i benefici prodotti da un ipotetico investimento in soluzioni FLOSS
da parte delle PP.AA. italiane.
Il controllo della spesa pubblica. Il FLOSS permette alle PP.AA. di salvaguardare gli
investimenti fatti in termini di hardware e software senza essere esposti alle scelte strategiche
del fornitore, e di mantenere una maggiore autonomia decisionale nel pianificare gli
aggiornamenti.
Miglioramento dei prodotti proprietari. Di solito, il FLOSS è sviluppato da programmatori
sparsi per il mondo, ognuno dotato di propria esperienza, e questo processo di
implementazione stimola l’innovazione e permette spesso di raggiungere obiettivi superiori a
quelli raggiungibili in un mondo chiuso. Come conseguenza di questo fatto, le aziende
proprietarie sono spinte ad investire continuamente nuove fonti e nuove risorse nel
miglioramento dei propri prodotti, per mantenere le proprie quote di mercato.
Garanzia del pluralismo informatico. Mentre alcuni governi combattono le posizioni
monopolistiche a favore di un mercato ampio, altri fanno accordi esclusivi con produttori
privati per fornire strumenti informatici alle PP.AA. Esiste una via per ostacolare i regimi di
monopolio e contribuire così allo sviluppo del pluralismo informatico: è quella del software
libero, che permette minori costi e migliore utilizzo dei computer a disposizione dell'intera
collettività.
Competitività e trasparenza del mercato. L’ingresso dei prodotti FLOSS ha portato dei
cambiamenti sulla struttura del mercato, e tali cambiamenti saranno tanto più accentuati tanto
più grande sarà lo sviluppo del software FLOSS. La situazione generale di monopolio è stata
sostituita da una competizione tra diversi modelli di business, quello proprietario e quello
FLOSS, e l'ingresso di quest'ultimo sembra in grado di contrastare i monopoli esistenti.
Scelte di sviluppo tecnologico compatibili con l’ambiente. Uno dei principi dell'etica hacker è
quello di non sprecare tempo per cominciare ogni volta a reinventare la ruota, ma utilizzare
quanto già fatto da altri. Ogni nuova release di molti sistemi proprietari richiede, invece, un
nuovo hardware, la cui costruzione utilizza risorse non deperibili, ma ancor di più il suo
smaltimento è causa di danni ambientali.
Pagina 86
Occupazione. Il FLOSS permette di creare nuovi posti di lavoro. L’utilizzo sistematico di
FLOSS nelle PP.AA. porta allo sviluppo di competenze informatiche locali, favorendo
un’occupazione altamente tecnologica locale vicino alla P.A. Non si tratta di un modello
inefficiente, ma del superamento di monopoli con un modello tecnologico a rete locale più
moderno ed efficiente.
Valorizzazione del patrimonio di dati pubblici. Poiché con il FLOSS si possiede il codice
sorgente, è più facile garantire la persistenza, la tracciabilità e la fruibilità dei dati: il cittadino
ha la garanzia che potrà sempre leggere e modificare il file.
Sviluppo economico e sociale del territorio. Il software libero permette la condivisione della
conoscenza e la libertà di copia, permettendo così una crescita culturale e formativa.
L'esperienza delle generazioni precedenti può essere utilizzata dalle nuove, per risolvere
nuovi problemi.
Diminuzione del divario digitale fra cittadini. Diffondere il FLOSS nelle PP.AA.
consentirebbe la riduzione del divario digitale, permettendo a tutti i cittadini di avvicinarsi al
mondo informatico in modo graduale e gratuito.
Nel seguente capitolo sono illustrati i solutori realizzati in ambiente Matlab-Simulink, che
permettono di evidenziare come gli investimenti in IT e in R&S, da parte delle PP.AA,
finalizzati allo sviluppo di soluzioni FLOSS, contribuiscono effettivamente alla crescita e alla
valorizzazione di tali effetti.
3 MODELLO ECONOMICO BASATO SULLA TEORIA DELLA
CRESCITA ENDOGENA
Per valutare l'impatto economico dei prodotti FLOSS sull'innovazione e lo sviluppo del
nostro Paese, partiamo da un modello estratto da un recente studio pubblicato dall'Unione
Europea [7]. Tale modello si rifa alle teorie economiche della crescita endogena [8] e ai
contributi di Romer [9][10]. Esso considera, quindi, il progresso tecnologico endogeno al
sistema economico, e si basa sulle seguenti ipotesi:

ruolo fondamentale del capitale umano che, sviluppando le proprie abilità e conoscenze,
incrementa la produttività dell'intero sistema;

grande importanza per la ricerca e lo sviluppo (R&S);

presenza di rendimenti di scala crescenti derivanti dall'attività di R&S e dall'incremento
di conoscenza.
Riportiamo per maggior chiarezza in Figura 1 il modello proposto da UNU-MERIT [7]. Nella
sezione successiva sono descritte le variabili in gioco.
Pagina 87
dK i
i
=Rt − ⋅K i t 
dt
dK y
=I t − y⋅K y t 
dt
Rt =s R⋅Y t 
I t =sI⋅Y t 
dh
=u⋅h t  ⋅⋅K i t 1−
dt
−
−
1
−
K e t =k y t ⋅[q 1−  / A F tq 1− ⋅AP t ∗A P t q⋅ AF t q 1−⋅A P t −1∗A F t] 
F
  1F  KFi t −h t − Lt
  2F
AF t = 0 t  h t  Lt
P 
P
P
  P
A t =  ht
 L t   K t −h t − Lt
P
0
1
i
2
F
K i t =1−W 1− K i t 
K Pi t =W 1− K i t 
Y t =B⋅1−u⋅ht ⋅Lt 1− ⋅ K e t 
Figura 1. Sistema di equazioni che modellano il sistema economico basato sulla teoria della
crescita endogena.
3.1
Dimostratore software per la valutazione dell'impatto economico dell'adozione di
FLOSS nelle PP.AA.
A partire dal complesso sistema di equazioni sopra riportato, abbiamo costruito un modello in
ambiente Matlab-Simulink per studiare come variano nel tempo le grandezze in gioco al
variare dei parametri. In particolare, abbiamo studiato le diverse grandezze in un periodo di
tempo T pari a 200 e con un passo temporale pari a 1; abbiamo assunto che l'unità di misura
del passo temporale sia pari ad 1 mese e, quindi, che il periodo T sia pari a 200 mesi.
Abbiamo risolto tre equazioni differenziali e studiato come variano nel tempo K i , K y e
h , ossia rispettivamente il capitale ICT, il capitale fisico ed il capitale umano.
Parallelamente alla risoluzione delle equazioni differenziali, abbiamo calcolato ad ogni passo
temporale anche altre grandezze: il capitale effettivo dell'organizzazione, K e , e A F con
A P che rappresentano il numero totale di beni esistenti e possono essere interpretati come
una forma di sviluppo tecnologico associato rispettivamente alle attività FLOSS e alle attività
proprietarie; infine, abbiamo calcolato la funzione di produzione Y. L'obiettivo delle
simulazioni effettuate è conoscere gli ordini di grandezza dei segnali coinvolti nello sviluppo
della produttività, relativamente all'introduzione di prodotti FLOSS piuttosto che proprietari;
in particolare, abbiamo studiato i tassi di crescita delle diverse grandezze sopra riportate.
Nella Figura 2 è riportato lo schema Simulink del modello:
Pagina 88
1 2 :34
t
T a s s o d i c r e s c it a d i A F a ll a fin e d e l p e r io d o d i s im u la z io n e
D i g i t a l C lo c k
7
ta s s o _ A F _ in T
A n d a m e n to n e l te m p o
d e l ta s s o _ A F
ky 0
T a s s o d i c r e s c it a d i A P a lla fin e d e l p e r io d o d i s i m u la z io n e
k y0
1
ta s s o _ A P _ in T
k i0
k i0
d el tas s o _ A P
0 .9
gam m a
T a s s o d i c re s c it a d i h a l la fin e d e l p e r io d o d i s im u la z io n e
G am m a
ta s s o _ h _ in T
0 .8
w
d e l ta s s o _ h
w
c re s c _ e n d _ S im u lin k
1
q
T a s s o d i c re s c i t a d i k e a lla fi n e d e l p e r io d o d i s i m u la z io n e
q
1
ta s s o _ k e _ i n T
A n da m en to n e l te m p o
d e l ta s s o _ k e
p s i0 F
p s i0 F
0 .1
ta s s o _ k i _ in T
p s i1 F
T a s s o d i c re s c it a k i a lla fi n e d e l p e rio d o d i s im u la z i o n e
p s i1 F
1
A n da m en to n e l te m p o
d el tas s o _ k i
p s i0 P
p s i0 P
T a s s o d i c r e s c it a d i y a l la fin e d e l p e ri o d o d i s im u la z io n e
ta s s o _ y _ i n T
0 .1
p s i1 P
p s i1 P
d e l ta s s o _ y
E m bedded
M A T L A B F u n c t io n 1
Figura 2. Schema Simulink per la simulazione del modello economico di crescita endogena.
Analizziamo brevemente le variabili input/output dello schema Simulink sopra riportato,
iniziando dalle variabili in ingresso. Le variabili di input sono le seguenti: K  y ,0  (stock
iniziale di capitale ICT), K i ,0 (stock iniziale di capitale non ICT),  (variabile che
pesa l'influenza del capitale umano e del capitale ICT nella funzione di produzione del
capitale umano), w (frazione di capitale ICT utilizzato nella produzione del prodotto
finale, relativo alle soluzioni PROPS); 1−w (relativo invece ai prodotti FLOSS), q
(differenza del rapporto qualità/prezzo tra soluzioni FLOSS e proprietarie), (parametro che
, P
pesa la forza lavoro nel calcolo delle attività FLOSS o proprietarie),  F
(parametro che
1
pesa l'intensità di capitale ICT nel calcolo delle attività FLOSS o proprietarie).
A partire dalle variabili d'ingresso, il solutore risolve il complesso sistema di equazioni che
rappresenta il modello di crescita economica, fornendo in output il comportamento di diverse
grandezze. Gli output sono i tassi di crescita calcolati alla fine del periodo di simulazione, T,
e relativi alle seguenti grandezze: A F è il numero della varietà di prodotti FLOSS; A P è
il numero della varietà di prodotti PROPS; h è il capitale umano; k e è il capitale
effettivo; k i è il capitale ICT; infine, y è la funzione di produzione, ossia la produttività
dell'organizzazione in esame.
Pagina 89
Riportiamo nella Tabella 1 i risultati ottenuti nella simulazione di riferimento ed in alcune
delle diverse simulazioni eseguite:
Parametri
Simulazione
di
riferimento
Simulazion
e1
Simulazione
2
Simulazion
e3
Simulazione
4
Simulazione
5
Simulazion
e6
Simulazion
e 7
Simulazion
e8
Simulazion
e9
Simulazion
e 10
w
0.8
0.7
0.6
0.7
0.6
0.7
0.7
0.7
0.7
0.7
0.7

0.9
0.9
0.9
0.9
0.9
0.9
0.8
0.8
0.9
0.8
0.8
q
1
1.0
1.0
1.1
1.1
1.0
1.0
1.1
1.1
1.0
1.1
1F 
0.1
0.1
0.1
0.1
0.1
0.2
0.1
0.1
0.2
0.2
0.2
Output
AF
0.89
0.15
0.26
0.3
0.44
1.16
0.7
0.96
1.57
2.17
2.86
AP
1.39
-0.04
-0.09
0.12
0.09
0.68
0.7
0.86
1.09
1.69
2.38
h
0.37
0
0
0
0
0.01
0.19
0.21
0.02
0.25
0.29
ke
3.04
0
0
0.3
0.36
1.59
1.28
1.8
2.39
3.64
4.97
ki
1.81
0
0
0.14
0.17
0.76
0.68
0.93
1.15
1.8
2.44
y
1.97
0
0
0.18
0.22
0.96
0.85
1.17
1.44
2.28
3.1
Tabella 1. Risultati delle simulazioni.
Nella 1° colonna sono riportati i tassi di crescita relativi alla “Simulazione di riferimento”,
nelle altre colonne riportiamo, invece, le variazioni dei tassi di crescita delle diverse
simulazioni rispetto alla “Simulazione di riferimento”, calcolate in T, ed espresse in punti
percentuali. Si noti che i valori dei tassi di crescita riportati nella tabella precedente sono
piccoli ma non per questo insignificanti. Le simulazioni sono state eseguite considerando la
produttività pro capite e, di conseguenza, bassi investimenti in software. Gli ordini di
grandezza diventano, quindi, significativi qualora si considerino gli investimenti complessivi
che una P.A. sostiene. Le simulazioni eseguite hanno evidenziato il maggior contributo che i
prodotti FLOSS danno allo sviluppo economico e sociale di un paese rispetto al contributo
dei prodotti proprietari. Infatti, i prodotti FLOSS contribuiscono maggiormente alla crescita
del capitale fisico, del capitale umano, della produttività e della varietà di prodotti, rispetto ai
prodotti proprietari. Si noti, che per essere il più oggettivi possibile, in tutte le simulazioni
eseguite si è sempree dato maggior importanza al contributo che gli investimenti ICT danno
alla varietà di prodotti proprietari. Infatti, abbiamo impostato il parametro w ad un valore non
inferiore a 0.6, assegnando così il 60% delle risorse ICT ai prodotti proprietari e il 40% ai
prodotti FLOSS.
3.2
Dimostratore software per la valutazione del rischio economico dell'adozione di
FLOSS nelle PP.AA.
Per effettuare l'analisi del rischio economico ed operativo [11], relativo all'adozione di
soluzioni software FLOSS, è stato realizzato un solutore in ambiente Matlab-Simulink e uno
in codice Matlab; i due solutori implementano il metodo Monte Carlo [12][13], uno dei
metodi più semplici e diffusi di simulazione stocastica. Per procedere con la simulazione
Pagina 90
Monte Carlo, bisogna innanzitutto definire ogni variabile d'ingresso in termini di
distribuzione statistica; si procede, quindi, ad effettuare n simulazioni estraendo ogni volta i
valori dalle corrispondenti distribuzioni. Al termine delle n simulazioni si fa una valutazione
complessiva e si ottengono n valori indipendenti delle variabili d'output, n campioni, che
potranno essere analizzati con tecniche statistiche per stimarne i parametri descrittivi [14].
Nella Tabella 2 elenchiamo le variabili rilevanti ai fini delle nostre analisi e assegniamo ad
ogni variabile aleatoria la propria distribuzione statistica gaussiana e ad ogni variabile
deterministica il proprio valore. Si è assunto, inoltre, che il 99% dei valori delle variabili
aleatorie gaussiane cada in un dato intervallo, come indicato in Tabella 2.
1° Blocco simulazioni
4° Blocco Simulazioni
K i ,0
1
1
3
3
K y,0
7
7
9
9

[0.8,0.9]
[0.8,0.9]
[0.8,0.9]
[0.8,0.9]
w

0.8
0.7
0.7
[0.5,0.7]
q
[1,1.1]
[1,1.1]
[1,1.1]
[1,1.1]
 0F 
[0.9,1]
[0.9,1]
[0.9,1]
[0.9,1]
 1F 
[0.1,0.3]
[0.1,0.3]
[0.1,0.3]
[0.1,0.3]
 0P
[0.9,1]
[0.9,1]
[0.9,1]
[0.9,1]
 1P
[0.1,0.2]
[0.1,0.2]
[0.1,0.2]
[0.1,0.2]
Tabella 2. Valori deterministici e/o aleatori delle variabili d'ingresso del modello in esame,
relative ai diversi blocchi di simulazione.
In Figura 3 è riportato lo schema Simulink del modello:
Pagina 91
A F _ M o n te C a rlo
O u t1
Il ve t t o r e A F _ M o n t e C a r l o c o n t i e n e i va l o r i
d e l t a s s o d i c r e s c it a d i A F , o t t e n u t i c o n l e
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c re s c it a d i A F
O u t2
A P _ M o n t e C a rlo
Il ve t t o r e A P _ M o n t e C a r l o c o n t i e n e i va l o r i
d e l t a s s o d i c re s c it a d i A F , o t t e n u t i c o n le
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c re s c it a d i A P
h _ M o n t e C a rl o
O u t3
fo r { . . . }
Il ve t t o r e h _ M o n t e C a r l o c o n t i e n e i va l o r i
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c re s c it a d i h
O u t4
k e _ M o n t e C a rlo
Il v e t t o r e k e _ M o n t e C a rl o c o n t ie n e i va l o ri
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c re s c ita d i k e
O u t5
k i_ M o n t e C a r l o
Il ve t t o r e k i _ M o n t e C a r l o c o n t i e n e i va l o r i
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c re s c it a d i k i
y _ M o n te C a rlo
O u t6
Il ve t t o r e y _ M o n t e C a rl o c o n t ie n e i va l o ri
d e l t a s s o d i c r e s c it a d i A F , o t t e n u t i c o n l e
1 0 0 0 0 s im u la z io n i .
d e l t a s s o d i c r e s c it a d i y
F o r It e r a t o r
S u b s y s te m
Figura 3. Schema Simulink per la simulazione del metodo
Monte Carlo.
Riportiamo nelle seguenti figure i risultati ottenuti risolvendo il metodo Monte Carlo con il
solutore in codice Matlab, e impostando le varibili d'ingresso come riportato nell'ultima
colonna della Tabella 2.
5
x 10
4
5
4
4
3 .5
3 .5
3
F re q u e n z e
3
F re q u e n z e
4
4 .5
4 .5
2 .5
2
2 .5
2
1 .5
1 .5
1
1
0 .5
0 .5
0
x 10
0
0.0 5
0.1
0 .1 5
0.2
Is to g ra m m a d e l ta s s o d i c re s c it a d i A F
0
0 .2 5
Figura 4. Istogramma del tasso
di crescita di AF in
T=200 (4° blocco di
simulazioni)
0
0 .0 5
0 .1
0 .1 5
0 .2
Is to g ra m m a d e l t a s s o d i c re s c it a d i A P
0 .2 5
di crescita di AP in
simulazioni)
Pagina 92
5
x 10
4
5
4 .5
4
3 .5
3 .5
3
3
2 .5
F re q u e n z e
F re q u e n z e
4
4 .5
4
2
1 .5
2 .5
2
1 .5
1
1
0 .5
0 .5
0
x 10
2
4
6
8
10
12
Is to g ra m m a d e l ta s s o d i c re s c ita d i h
14
0
16
x 10
-3
di crescita di h in
simulazioni)
0
0 .05
0.1
0 .1 5
0.2
0 .2 5
Is to g ra m m a d e l t a s s o d i c re s c it a d i y
0 .3
0 .3 5
di crescita di y in
simulazioni)
Gli istogrammi evidenziano che l'introduzione di soluzioni FLOSS comporta un rischio
economico ed operativo trascurabile, e favorisce lo sviluppo della produttività e lo sviluppo
di tecnologie sempre più moderne.
4 CONCLUSIONI
FLOSS significa disponibilità dei sorgenti, occasione di crescita formativa e di
personalizzazione del software secondo le proprie reali necessità. L'aderenza agli standard e
la disponibilità dei sorgenti garantisce totale accessibilità ai dati da parte dell'utente. Il
FLOSS permette la crescita aziendale senza costi aggiuntivi e nessuna restrizione, quindi, sul
numero di installazioni. Il fenomeno FLOSS offre grandi opportunità, sia dal punto di vista
economico sia dal punto di vista sociale, e la Pubblica Amministrazione dovrebbe assumere il
ruolo di principale promotrice del FLOSS per garantire al Paese forti risparmi nel medio e
lungo termine, una minore dipendenza dai fornitori e, soprattutto, per sostenere la diffusione
di competenze e il rafforzamento di reti locali di imprese.
Alla luce dei risultati ottenuti con i due modelli proposti per l'analisi dell'adozione di FLOSS,
riportiamo alcune considerazioni. Con il 1° modello illustrato, abbiamo valutato l'impatto
economico relativo all'adozione del FLOSS, e abbiamo visto come i prodotti FLOSS diano
una spinta maggiore allo sviluppo economico e sociale di un Paese. Essi contribuiscono
maggiormente alla formazione del capitale umano, alla crescita del capitale fisico e ICT. Con
il 2° modello, invece, abbiamo valutato il rischio economico relativo all'adozione FLOSS
rispetto ai prodotti PROPS, e si è visto come l'adozione di soluzioni FLOSS contribuisca allo
sviluppo sociale ed economico, garantendo guadagni nel medio e nel lungo termine, e
contribuendo allo sviluppo di tecnologie sempre più moderne.
I solutori in ambiente Matlab-Simulink proposti sono facilmente configurabili su casi
specifici, settando opportunamente i valori delle diverse variabili d'ingresso. Essi
Pagina 93
rappresentano, quindi, un utile strumento per tutte le PP.AA. che si trovano dinanzi alla
formulazione di un giudizio di convenienza circa l'adozione di FLOSS. Nel caso di PP.AA.,
trattandosi di investimenti pubblici, l'operatore che deve decidere sulla convenienza di un
investimento formulerà il suo giudizio rispetto ad un obiettivo di massimizzazione del
benessere collettivo, dando così maggior peso allo sviluppo del capitale umano, allo sviluppo
della produttività e allo sviluppo di ogni forma di progresso tecnologico. Di conseguenza, si
tenderà a privilegiare quei progetti IT che contribuiscono maggiormente alla crescita di tali
grandezze.
Bibliografia
[1] Marchesi, M., Concas, G., De Petra, G., Marzano F. e Zanarini, P. (2008). Finalmente
Libero!McGraw-Hill.
[2] Open Source Observatory and Repository (2009). The French Gendarmerie goes for
Ubuntu.
[3] Open Source Observatory and Repository (2009). The Swedish National Police.
[ 4] CNIPA (2008). Relazione annuale sullo stato dell’ICT nella Pubblica Amministrazione
Centrale.
[5] Netics (2006). La spesa in licenze d’uso per prodotti software Sistemi Operativi PC Client
e Office Automation nella Pubblica Amministrazione Locale italiana.
[6] Netics (2008). Le ICT nelle Regioni e Province Autonome.
[7] Ghosh, R. A. (2006). Study on the Economic impact of open source software on
innovation and the competitiveness of the Information and Communication Technologies
(ICT) sector in the EU.
[8] Aghion, P. e Howitt, P. (1998). Endogenous growth theory. Cambridge and London, MIT
Press.
[9] Barro, R. J. (1999). Notes on Growth Accounting, Journal of Economic Growth.
[10] Barro, R. J. e Sala-i-Martin, X. (1995). Economic Growth. McGraw-Hill.
[11] Hertz, D. e Thomas, H. (1983). Risk analysis and its applications. John Wiley & Sons,
Chichester.
[12] Robert, C. P. e Casella, G. (2004). Monte Carlo Statistical Methods. Springer-Verlag.
[13] Vose, D. (1996). Risk analysis : a quantitative guide to Monte Carlo simulation
modeling. Elsevier, Amsterdam.
[14] Carlson, A B. e Crilly, P. B. (2000). Communication Systems, an introduction to signals and noise in electrical communication. McGraw Hill.
Pagina 94
DESKTOP-AS-A-SERVICE FACILE CON VIRTUAL
DISTRO DISPATCHER
Lamanna, Davide, Binario Etico Soc. Coop., via del Forte Tiburtino, 98/100 Roma,
IT, davide.lamanna@binarioetico.org
Nasti, Fabrizio, Binario Etico Soc. Coop., via del Forte Tiburtino, 98/100 Roma, IT,
fabrizio.nasti@binarioetico.org
Abstract
Virtual Distro Dispatcher (VDD) è un sistema distribuito che ha lo scopo di proiettare multiple istanze
virtuali di sistema operativo, pienamente usabili come desktop attraverso terminali in una rete. I
terminali possono essere PC obsoleti o thin client a basso consumo, tipo mini-ITX, tutti gestiti da un
potente sistema centrale multiprocessore e clusterizzato. Si può parlare di soluzione Desktop-as-aService (DaaS), derivandone il significato da Software-as-a-Service: i desktop possono essere
trasformati in un servizio a sottoscrizione, comodo, economico e scalabile. In VDD, macchine virtuali
desktop vengono istanziate su un server e quindi fornite ai client nella loro interezza, su richiesta,
attraverso una rete.
Parole Chiave: Cloud Computing, XEN, LTSP, Xorg, Trashware, Thin client, VDD-Project
1 INTRODUZIONE
Richard Stallman ha probabilmente ragione quando definisce il Cloud Computing l'ennesima
campagna di marketing modaiola, priva di un reale contenuto tecnologico innovativo e ricca,
invece, di insidie per la libertà e la privacy degli utenti. Ad ogni modo, è egualmente vero che
lavorare sui temi caldi del Cloud Computing ci dà la possibilità di fare passi avanti nello
studio e nello sviluppo dei sistemi distribuiti, della computazione su vasta scala, della
virtualizzazione, della programmazione parallela e dell'ottimizzazione delle risorse. In
quest'ottica, il progetto Virtual Distro Dispatcher (VDD) intende esplorare alcuni aspetti
specifici del Cloud Computing e proporre una soluzione software basata su sistemi aperti e
liberi e che tenga in considerazione anche le problematiche di privacy. L'idea di base del
Cloud Computing è la fornitura di capacità computazionali le più varie in forma di servizio,
ovvero "as-a-service". Servizi che puntano sull'affidabilità, vengono configurati in data center
di nuova generazione, basati su tecnologie di virtualizzazione, per essere erogati in modo
trasparente e standard agli utenti di una rete, nonostante l'insieme eterogeneo e distribuito
delle risorse hardware e software che li compongono. E' il concetto di Utility computing, in
Pagina 95
base al quale risorse computazionali fisiche vengono impacchettate ed erogate, in modo non
dissimile a quanto avviene per altri servizi pubblici, come l'elettricità o l'acqua. Questo può
avvenire a diversi livelli. Nel caso delle applicazioni si parla di Software-as-a-Service (SaaS).
Se si tratta di sistemi, è possibile derivare il concetto di Desktop-as-a-Service (DaaS). Le
risorse fisiche degli host (memoria, spazio disco, cicli di processore, ecc.) vengono
quantizzate in macchine virtuali multiple, per poi rendere disponibili da remoto queste
macchine virtuali, da usarsi come desktop, attraverso la rete. In tal modo i desktop vengono
trasformati in un servizio a sottoscrizione economicamente vantaggioso, scalabile e comodo.
Un'altra espressione utilizzata in questo contesto è Virtualized Client Computing (VCC).
Virtual Distro Dispatcher è un sistema distribuito che ha lo scopo di proiettare on-demand
istanze di sistema operativo (unix-like e non solo) pienamente funzionanti, su terminali di una
rete.
2 ARCHITETTURA DI VDD
In VDD, la virtualizzazione è utilizzata per disaccoppiare l'ambiente del client (sistema
operativo, applicazioni e dati) dal suo hardware host e isolarlo da altri software o sistemi che
eventualmente girano sul client. VDD fa uso di un sistema di virtualizzazione di desktop per
ospitare, a bordo di un server (o un gruppo di server in cluster tra loro), istanze di ambienti
client completi e isolati; l'interazione con questi desktop virtuali remoti avviene attraverso
sessioni utente (grafiche) virtuali. VDD sfrutta la trasparenza di rete di X-Window-System, in
base alla quale la macchina dove gira un programma applicativo (l'applicazione client) può
differire dalla macchina locale dell'utente (il display server). I client X-Window-System
girano su macchine virtuali lato server, dove vengono create sessioni utente multiple
all'interno di ambienti virtuali multipli. Il display server di X-Window-System gira sui thin
client (terminali). Per i sistemi operativi privi del server X11 (come Windows e ReactOS), è
possibile usare il protocollo VNC.
L'architettura di VDD viene illustrata in Figura 1. I terminali possono essere PC obsoleti o
thin client a basso consumo, come i mini-ITX, che accedono ad un sistema centrale
multiprocessore e clusterizzato. I terminali sono interfacce a vere e proprie macchine isolate,
che possono essere create su misura per qualunque necessità, tipo, numero e quantità di
risorse, nei limiti delle risorse del sistema centrale, ovviamente. Questo è possibile grazie ad
un sistema di virtualizzazione basato su XEN. L'infrastruttura su cui gira questo sistema è un
cluster è ad High Availability, che garantisce continuità operativa. In particolare, è stato
implementato un sistema di Live Migration, grazie al quale è possibile la migrazione di
macchine virtuali da un host fisico ad un altro all'interno del cluster in caso di guasti.
Pagina 96
Figura 1.
L'architettura di VDD.
Il meccanismo in base al quale funziona VDD è trasparente all'utente, che, persino da un PC
obsoleto, può comodamente selezionare una determinata macchina, con determinate
caratteristiche, sistema operativo, ambiente grafico e configurazioni, e lavorare su di essa
come se fosse fisica, locale, dotata di quelle risorse e delle relative performance. Si noti,
infine, che è possibile far funzionare VDD su Internet, anche se le prestazioni sono molto
dipendenti dalla disponibilità di banda in upload e ancora scadenti.
3 SCHEMA DI FUNZIONAMENTO
La Figura 2 mostra il modo in cui le macchine fisiche e virtuali, i loro servizi, le loro
applicazioni, i terminali e i display, entrano in relazione tra loro, in base a quali comandi e
realizzando quali funzioni. La macchina fisica VDD (grande, in verde) ospita al suo interno le
macchine virtuali da "dispatchare" (piccole, in giallo), che nell'esempio della figura 2 sono
tre, Debian, Ubuntu e Fedora. Le macchine fisiche e virtuali sono equipaggiate con server
ssh, per poter accedere ad esse dall'esterno, sia per scopi di manutenzione, che di
funzionamento di VDD. La macchina fisica (il server VDD), che, come detto, è in un cluster
ad High Availability, è dotata anche di servizi per l'accesso da remoto. In questo modo è
possibile configurare VDD da stazioni di amministrazione, sia con la riga di comando che
attraverso interfaccia grafica. Nell'esempio, due macchine, Foo e Bar, assolvono allo scopo.
La soluzione web è stata progressivamente abbandonata in favore della più efficiente e
completa GUI via ssh.
Pagina 97
Figura 2.
Schema di funzionamento.
Tre thin clients (Terminal 1, Terminal 2 e Terminal 3) sono connessi a VDD attraverso LTSP
(Linux Terminal Server Project). Con LTSP è possibile avviare terminali, senza che su di essi
sia installato un sistema operativo. Le prestazioni a cui lavorano i terminali sono prossime a
quelle del server centrale, anche in presenza di hardware molto datato. Quando i terminali si
accendono, eseguono il boot da rete e mostrano (dopo il login) un menu che è parte
dell'interfaccia grafica e che consente all'utente di selezionare la distro (o in generale il
sistema operativo) su cui intende lavorare. In quel momento, l'utente si trova nell'ambiente
del server LTSP e quindi sul server VDD.
La variabile DISPLAY dell'utente su una determinata macchina virtuale, viene impostata per
puntare ad un canale del server X che gira sul server VDD. Nell'esempio, i canali 1, 2 e 3,
uno per ognuna delle tre macchine.
Dai terminali, che attraverso LTSP mostrano l'ambiente grafico del server VDD, si lancia
Xephyr. Xephyr è un server X minimale eseguito in una finestra all'interno della sessione X
corrente. Xephyr è contemporaneamente un client X e un server X. E' client del server X
reale, e server dei propri client, che nel caso di VDD, lo invocano dai thin client. Xephyr è
basato su KDrive, un server X minuscolo, progettato per ambienti con poca memoria a
disposizione. KDrive evita allocazione di memoria a runtime e prova ad eseguire le
operazioni "on the fly", ogni volta che ciò è possibile. Xephyr rappresenta, di fatto, un
rimpiazzo per Xnest, che consente di eseguire un server grafico X11 come client di sé stesso,
all'interno di una finestra autonoma. Rispetto ad Xnest, Xephyr offre prestazioni migliori e
supporto per le estensioni più avanzate (quali Composite, Damage, randr, ecc.).
Nell'esempio di figura 2, Xephyr viene lanciato in ascolto sul canale 2, per poter utilizzare la
macchina Ubuntu.
Pagina 98
Dopo aver avviato il display remoto di Xephyr, è possibile lanciare sessioni grafiche delle
macchine virtuali utilizzando gestori di sessioni X11 (startkde, gnome-session, xfce4session).
Si noti che è perfettamente possibile usare più canali dallo stesso thin client. Questa è una
delle features di VDD, che consente di proiettare su ogni terminale uno o più sistemi
operativi, passando comodamente dall'uno all'altro attraverso il menu grafico.
Una delle caratteristiche di Xephyr più interessanti per VDD è la modalità a tutto schermo,
che rende il sistema completamente trasparente all'utente.
Tutto queste funzioni vengono assolte da script appositi, a cui è collegata l'interfaccia grafica.
4 PRIVACY
Una delle più importanti criticità delle soluzioni Cloud Computing è l'esposizione degli utenti
a possibili violazioni della propria privacy, in quanto i dati personali sono in possesso di chi
eroga il servizio.
VDD integra al suo interno una soluzione che risolve, almeno in parte, questo genere di
problematiche. Gli utenti di VDD possono avere a propria disposizione un volume cifrato su
ognuna delle Virtual Machine a cui hanno accesso. Il volume cifrato, un volume logico LVM,
è montato sul filesystem del server e condiviso tramite Samba sulle Virtual Machine. Per la
cifratura viene usato un sistema basato su dmcrypt-LUKS.
Su un sistema debian-based è necessario installare i pacchetti dmsetup, cryptsetup e,
naturalmente samba, e verificare la presenza dei moduli "aes" e "crypt". Si procede quindi
alla creazione del volume logico e alla sua cifratura (tramite passphrase) con il programma
cryptsetup. Lo stesso programma si occupa poi di decifrare il volume, previo inserimento
della corretta passhrase, mappandolo su un dispositivo logico, sul quale è quindi possibile
creare il filesystem adeguato tramite le diverse istanze del progrmma mkfs. Sempre tramite
cryptsetup si procede infine alla "chiusura" del volume cifrato, la cui preparazione è a questo
punto completata.
Il pacchetto libpam-mount consente poi di utilizzare il comando mount.crypt per decifrare e
montare il dispositivo sul filesystem del server. Per l'automazione di queste procedure nel
contesto VDD si fa uso delle funzionalità messe a disposizione dal comando "sudo",
opportunamente configurato per definirne funzionalità e limitazioni (utenti e comandi
autorizzati, richiesta o meno di password, ecc.)
Ciascun utente può infine attivare la condivisione del punto di mount del proprio volume
cifrato, sfruttando la funzionalità di "usershare" fornita da samba3. A tale scopo, oltre ad
attivare e configurare tale funzionalità nel file di configurazione di samba, è necessario che
l'utente sia membro del gruppo sambashare. Naturalmente l'utente deve essere aggiunto tra gli
utenti samba tramite il comando smbpasswd, con il quale si imposta anche la relativa
password. L'utente può quindi attivare la condivisione che sarà accessibile previo inserimento
delle credenziali impostate.
L'utilizzo di volumi crittati dà agli utenti la possibilità di tenere i propri dati privati e in
sicurezza rispetto ad intrusi. Potrebbe esserci sempre il rischio, però, che vengano sniffati i
dati in fase di trasferimento dal thin client al volume cifrato (vedi TEMPEST attack). Mentre
in un ambiente LAN controllato questo rappresenta un problema poco rilevante, non è invece
Pagina 99
da sottovalutare nel momento in cui VDD entra in funzione “in the cloud”, dove certamente il
rischio è più alto. In questi casi, bisogna ricorrere ad SSL.
Ad ogni modo, la soluzione proposta non risolve del tutto il problema di privacy dei sistemi
basati sul Cloud Computing, in quanto è sempre possibile monitorare le attività degli utenti e
profilarli a scopi pubblicitari o di altro tipo.
5 INTERFACCIA GRAFICA
L'ossatura della GUI è costituita da script, disponibili sul sito insieme a tutta la
documentazione, integrati nella GUI attraverso Zenity. Gli screenshots di Figura 3 e 4
mostrano alcune delle scelte presentate all'utente.
Figura 3.
Selezione del Sistema Operativo della macchina da dispatchare.
Pagina 100
Figura 4.
Selezione del Desktop Environment (solo per GNU/Linux).
Per quanto riguarda l'amministrazione, VDD integra al suo interno virt-manager. Per essere
gestite, le macchine virtuali devono essere "importate" nello xenstore, in modo che la libreria
libvirt possa riconoscerle e gestirle. Ogni volta che si modifica la configurazione, la virtual
machine deve essere cancellata dallo xenstore e poi riaggiunta. Una volta inserite nello
xenstore, le virtual machine possono essere avviate (e spente) sia da linea di comando che
attraverso l'interfaccia grafica.
Figura 5.
Pannello di controllo delle macchine virtuali.
Pagina 101
Figura 6.
Una fase della creazione di una nuova macchina virtuale.
Sono previste 2 modalità di utilizzo del gestore: in locale (sull'host xen) e da remoto (da un
client qualunque). In modalità locale è attiva la funzionalità di creazione di nuove macchine
virtuali, sia da linea di comando che da interfaccia grafica. Sia da locale che da remoto, il
programma ci consente di visualizzare lo stato delle virtual machine, i relativi dettagli e l'uso
di risorse e ci consente inoltre di spegnerle, avviarle, rebootarle (vedi figura 5). Figura 6 e 7
mostrano l'allocazione di spazio, cpu e memoria per una nuova macchina da creare (modalità
locale).
Figura 7.
Un'altra fase della creazione di una nuova macchina virtuale.
Pagina 102
6 TO DO LIST E COMMUNITY
Grazie al finanziamento della fondazione NLNet , VDD ha avuto una nuova fase di sviluppo.
Sono stati completati l'interfaccia grafica, l'analisi delle performance e i test di usabilità. La
documentazione, gli how-to e il codice sono disponibili sul sito www.vdd-project.org
Virtual Distro Dispatcher usa software Open Source/GPL e protocolli di comunicazione liberi
ed è naturalmente rilasciata come Software Libero. L'infrastruttura consente di far girare
sistemi operativi proprietari come macchine guest e questo è regolato da specifiche licenze,
costi e limitazioni, che dovrebbero essere presi in considerazione dagli utenti di VDD.
Gli sviluppatori cercano persone e/o organizzazioni che vogliano collaborare, promuovere,
sviluppare, discutere. Sul sito è possibile iscriversi alla newsletter, al forum di discussione, e
si può richiedere di essere inseriti nella lista del team di sviluppo e poter quindi accedere agli
strumenti di lavoro collaborativi presenti nell'area riservata.
Stiamo in questa fase ridefinendo la roadmap. La nuova to_do list conterrà di sicuro uno
sviluppo delle feature di clustering; dopo aver implementato l'High Availability, potremmo
sperimentare il Load Balancing. Dovremmo lavorare anche su un event log facilmente
fruibile. Rispetto all'accounting, stiamo per ora usando quello standard di LTSP, mentre
invece si potrebbe pensare di introdurre qualcosa di più configurabile e granulare, integrando
OpenLDAP. Abbiamo poi altre idee su possibili sviluppi, che potrete scoprire ed
incrementare contattandoci e portando le vostre! :-)
Bibliografia
1.Flavio Bertini, Davide Lamanna and Roberto Baldoni – “Virtual Distro Dispatcher: A
costless
distributed virtual environment from Trashware” - ISPA '07: Proceedings of the 5th
international
symposium on Parallel and Distributed Processing and Applications, pages 223—234
2.Jeff Dike – “User Mode Linux” (Bruce Perens' Open Source Series), Prentice Hall PTR
(April 22,
2006), 352 pages
3.David Chisnall – “The Definitive Guide to the XEN Hypervisor” - Prentice Hall PTR; 1
edition
(November 19, 2007), 320 pages
4.Linux Terminal Server Project – http://www.ltsp.org
5.Gerald J. Popek and Robert P. Goldberg – “Formal Requirements for Virtualizable Third
Generation
Architectures” - Communications of the ACM, Volume 17, Issue 7, Pages: 412 – 421
6.Michael Rose (Industry Developments and Model) - “Virtualized Client Computing: A
Taxonomy” -
Pagina 103
Dec 2007, http://www.idc.com/getdoc.jsp?containerId=209671
7.C. Hewitt - “ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing” IEEE Internet
Computing, Sept./Oct. 2008, pp. 96-99
8.Ruggero Russo, Davide Lamanna and Roberto Baldoni – “Distributed software platforms
for
rehabilitating obsolete hardware” - OSS '05: Proceedings of The First International
Conference on
Open Source Systems, pp. 220-224
9.Brendan Cully, Geoffrey Lefebvre, Dutch Meyer, Mike Feeley, and Norm
Hutchinson - “Remus: High Availability via Asynchronous Virtual Machine Replication” - In
proceedings of the 5th USENIX Symposium on Networked System design and
implementation, pp.
161–174 – Awarded Best Paper
10. Salvatore Cristofaro, Flavio Bertini, Davide Lamanna and Roberto Baldoni – “Virtual
Distro Dispatcher: a light-weight Desktop-as-a-Service solution ” - First International
Conference on Cloud Computing October 19 - 21, 2009, Munich, Germany,
CLOUDCOMP 2009, ICST, 2009
La versione completa di quest'articolo è stata pubblicata, sempre con licenza Creative Commons
Attribution, Non-Commercial, Share-Alike, su CP/Computer Programming Volume XVII n. 5
Pagina 104
UNA SUITE INTEGRATA DI SERVIZI PER PA E IMPRESE
AN INTEGRATED SERVICE SUITE FOR PUBLIC
ADMINISTRATIONS AND ENTERPRISES
Marchesi, Michele, DIEE - Università di Cagliari, piazza d'armi, 09123 Cagliari, IT,
michele@diee.unica.it
Melis, Marco, Flosslab srl, viale Elmas 142, 09122 Cagliari, IT,
marco.melis@flosslab.it
Manca Dino, Flosslab srl, viale Elmas 142, 09122 Cagliari, IT,
dino.manca@flosslab.it
Antonio Ariu, Flosslab srl, viale Elmas 142, 09122 Cagliari, IT,
antonio.ariu@flosslab.it
Abstract
Le odierne esigenze di Pubbliche Amministrazioni e imprese in termini tecnologici nell'automazione
dei processi, monitoraggio e controllo dei costi e risultati sono notevoli. Per soddisfare tali esigenze,
il mercato offre tutta una serie di applicativi software specializzati per risolvere le singole
problematiche e migliorare la produttività aziendale.
Il massiccio utilizzo di sistemi informatici, gestiti per lo più da sistemi “legacy”, ha portato ad un in cremento esponenziale dei dati immagazzinati. Queste informazioni rappresentano la base della conoscenza che ogni organizzazione ha maturato nel corso del tempo. D'altra parte, è noto che solo una
piccola parte (10-15%) di tutti i dati viene strutturato in sistemi di memorizzazione dell’informazione,
rappresentando quindi una fonte di informazione e conoscenza strutturata e facilmente accessibile,
mentre il restante 85-90% dei dati potenzialmente utili rimane memorizzato in forma non strutturata,
e quindi molto più difficilmente utilizzabile. Proprio questi dati, che costituiscono un patrimonio
inestimabile di ogni organizzazione, necessitano di una riorganizzazione e di un’integrazione in modo
da poter essere valorizzati al meglio.
Il presente lavoro è orientato all'analisi di un possibile modello che consenta l'integrazione e
l'interoperabilità tra sistemi informatici utilizzando esclusivamente componenti software a codice
aperto e standard riconosciuti.
L’approccio più adeguato è risultato essere quello basato su un'architettura orientata ai servizi con
un sistema centrale di integrazione cui si interfacciano i vari applicativi attivi nello specifico con testo.
Il sistema centrale si occupa di gestire e risolvere le specifiche problematiche di integrazione, ed
esporre infine una Suite di servizi orientati all'utente finale, disponibile per le particolari esigenze.
L'utilizzo di un'architettura del genere permette un'integrazione dei vari applicativi minimizzando la
necessità di intervenire a livello implementativo su ciascuno di essi, oltre che permettere di monitor are e gestire da un unico punto l'elevato flusso informativo in gioco.
La particolare soluzione adottata permette di aprire vari altri scenari: la rappresentazione
dell'informazione in un contesto di integrazione e interscambio tra più applicativi e contesti non può
prescindere dal considerare il contenuto semantico che i dati stessi trasportano. Per garantire piena
interoperabilità, al livello tecnologico è necessario affiancare un livello di interoperabilità di tipo semantico. L'obiettivo è che le informazioni scambiate siano immediatamente e mutuamente
comprensibili.
Pagina 105
Parole Chiave: SOA, Web Services, Cooperazione applicativa, Pubblica Amministrazione, Imprese,
Portale, Ontologie
1 INTRODUZIONE
Le odierne esigenze di Pubbliche Amministrazioni (PPAA) e imprese in termini tecnologici
nell'automazione dei processi, monitoraggio e controllo dei costi e risultati sono notevoli. Per
soddisfare tali esigenze, il mercato offre tutta una serie di applicativi software specializzati
per risolvere le singole problematiche e migliorare la produttività aziendale.
Il massiccio utilizzo di sistemi informatici, gestiti per lo più da sistemi “legacy”, ha portato
ad un incremento esponenziale dei dati immagazzinati. Queste informazioni rappresentano la
base della conoscenza che le organizzazioni hanno maturato nel corso del tempo. D'altra
parte, è noto che solo una piccola parte (10-15%) di tutti i dati viene strutturato in sistemi di
memorizzazione dell’informazione, rappresentando quindi una fonte di informazione e
conoscenza strutturata e facilmente accessibile, mentre il restante 85-90% dei dati
potenzialmente utili rimane memorizzato in forma non strutturata, e quindi molto più
difficilmente utilizzabile. Proprio questi dati, che costituiscono un patrimonio inestimabile di
ogni organizzazione, necessitano di una riorganizzazione e di un’integrazione in modo da
poter essere valorizzati al meglio.
Le pubbliche amministrazioni gestiscono una mole di dati che sono per la maggior parte
strettamente correlati tra loro, e per questioni normative devono essere sempre allineati. Si
pensi ad esempio a quanto i dati tributari siano fortemente dipendenti dai semplici dati
anagrafici piuttosto che dai più complessi dati catastali.
In un contesto di forti necessità di allineamento, un grosso ostacolo all'ottimizzazione di
questi processi è dato dal fatto che le varie applicazioni software specializzate nella gestione
dei singoli procedimenti, paradossalmente, troppo spesso non comunicano tra di loro. La
porzione di dati su cui una applicazione lavora e i risultati delle elaborazioni effettuate,
spesso non vengono poi resi disponibili ad altri applicativi che gestiscono dati correlati.
Inoltre, questa mancanza di comunicazione porta all'inefficienza, in quanto gli stessi dati sono
memorizzati in diversi punti, portando a ridondanza o addirittura incoerenza nelle
informazioni.
Il concetto di estraneità reciproca degli applicativi viene ben espresso con i termini “islands
of automation” o “information silos”, attraverso i quali ci si riferisce alle applicazioni che non
sono integrate con le restanti parti del processo di business.
Le problematiche relative all'integrazione sono differenti a seconda del contesto specifico che
si considera. Nel contesto della PA, sono state definite una serie di normative e regole
tecniche per favorire l'interoperabilità e integrazione applicativa, in particolare nell'ambito del
Sistema Pubblico di Cooperazione (SPCoop) [SPCoop]. Queste regole definiscono le
specifiche tramite le quali più organizzazioni possono interagire vicendevolmente
condividendo i propri sistemi informativi. Ogni organizzazione viene qui identificata con il
termine Dominio. Il sistema SPCoop regolamenta le comunicazioni tra Domini diversi (inter-
Pagina 106
dominio). Possiamo distinguere quindi le problematiche di integrazione inter-dominio da
quelle intra-dominio e si possono evidenziare diverse esigenze e soluzioni.
Le esigenze a livello intra-dominio riguardano l'implementazione di un'infrastruttura interna
che permetta di costruire un sistema informativo digitale unitario e coerente. Tale sistema
informativo ha come obiettivo primario quello di rendere possibile l'accesso e la gestione
della mole di dati in possesso della specifica organizzazione, secondo quanto disposto dal
Codice dell'Amministrazione Digitale. Questo dovrebbe essere un prerequisito necessario alla
realizzazione di un sistema di comunicazione con domini esterni. Tale esigenza si scontra con
una serie di problematiche legate ai sistemi software in uso presso gran parte delle PPAA, e
ai limiti che questi impongono sotto vari aspetti, quali:
 assenza di interfaccia applicativa verso sistemi terzi
 sistemi proprietari con codice non accessibile
 tecnologie obsolete
 elevati costi di sostituzione  elevati costi di aggiornamento  limitata scalabilità e flessibilità delle applicazioni in uso Queste problematiche si ripresentano pressoché identiche anche nell'ambito del privato, essendo generalmente imputabili alla carenza di progettazione orientata alla interoperabilità applicativa.
Le esigenze e le problematiche specifiche nello scambio dei dati a livello inter-dominio,
ampiamente indirizzate e risolte con la definizione del sistema SPCoop, riguardano in breve i
seguenti aspetti:
 Definizione e approntamento dell'infrastruttura tecnologica.
 Definizione di regole tecniche per lo sviluppo, la condivisione, l’integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione.  Definizione di standard per assicurare l’interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi.
 Garanzia della sicurezza e della riservatezza delle informazioni.
 Salvaguardia e autonomia del patrimonio informativo di ciascuna P.A.
1.1
Il Contesto Normativo nell'Ambito delle PPAA
Il contesto normativo nazionale di riferimento nell'ambito della Pubblica Amministrazione è
quello del Codice dell'Amministrazione Digitale, emanato con Decreto legislativo del 7
marzo 2005, n. 82, entrato in vigore il 1 gennaio 2006 e successivamente integrato e
modificato in vari passaggi, arrivando all'attuale versione con la Legge n. 2/2009. Esso ha lo
scopo di assicurare e regolare la disponibilità, la gestione, l’accesso, la trasmissione, la
conservazione e la fruibilità dell’informazione in modalità digitale utilizzando, con le
modalità più appropriate, le tecnologie dell’informazione e della comunicazione all'interno
della pubblica amministrazione, nei rapporti tra amministrazione e privati. In alcuni limitati
casi, disciplina anche l'uso del documento informatico nei rapporti tra privati.
La novità più sostanziale apportata dal Codice dell'Amministrazione Digitale riguarda il fatto
che diventa obbligatorio garantire, in forma vicendevole, l’accesso alla consultazione, alla
circolazione e allo scambio di dati e informazioni, nonché l’interoperabilità dei sistemi e
Pagina 107
l’integrazione dei processi di servizio fra le diverse amministrazioni, anche per assicurare
l’uniformità e la graduale integrazione delle modalità di fruizione dei rispettivi servizi on
line. Questo implica che tutte le amministrazioni pubbliche devono dotarsi di un'infrastruttura
applicativa in grado di gestire le richieste di dati e servizi provenienti dall'esterno, ossia da
altri enti della PA nonché da imprese e privati cittadini. A sua volta, la singola
amministrazione può usufruire dei servizi erogati dalle altre amministrazioni, permettendo di
rendere più efficiente la gestione amministrativa in termini sia di velocità di risposta che di
costi globali, oltre a minimizzare l'impatto ambientale che trasporti e produzione di carta
avrebbero nel caso di comunicazioni per via tradizionale.
Per poter rispettare tali principi, la singola PA dovrà agire su due fronti:
 implementare un'infrastruttura interna che permetta di costruire un sistema informativo digitale con lo scopo di garantire l'accesso e la gestione della mole di dati in suo possesso;  realizzare un sistema di interfaccia verso l'esterno in grado di esporre i propri dati e servizi e a sua volta fruire dei servizi e dati resi disponibili dagli altri enti della PA. Al fine di elaborare specifiche di alto livello il Codice dell'Amministrazione Digitale
definisce obiettivi quali: Efficacia, Efficienza, Flessibilità, Trasparenza, Economicità,
Imparzialità, Semplificazione e Partecipazione. Tra l'altro tali obiettivi sono stati codificati
dal diritto amministrativo ben prima della stesura suddetto Codice.
Anche a livello europeo, nell'ambito dell'IDABC80 [IDABC], sono state definite allo stesso
scopo raccomandazioni contenenti principi quali accessibilità, multilinguismo, sicurezza,
privacy, sussidiarietà, uso di standard aperti, uso di soluzioni multilaterali, valutazione dei
benefici del software OpenSource.
Inoltre, secondo quanto esposto anche dal CNIPA81 (recentemente ridenominato DigitPA)
nell'ambito del Sistema Pubblico di Cooperazione [SPCoop], la cooperazione tra differenti
soggetti pubblici richiede la definizione di un modello che sia:
 indipendente dagli assetti organizzativi dei soggetti cooperanti;  indipendente dai sistemi informatici interni dei soggetti cooperanti;  progettato in maniera rigorosa e sostenibile, tale che la sua evoluzione sul medio termine sia già pensata sin dall’inizio, con passi ben delineati. In breve si possono individuare quattro esigenze fondamentali alla base di qualsiasi azione
atta a risolvere le problematiche di cui sopra:
 Facilitare l'interoperabilità verso l'esterno
 Facilitare l'accesso ai servizi per il cittadino
 Partire dallo stato dell'arte
 Usare standard riconosciuti e diffusi
IDABC: Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens
81
CNIPA: Centro Nazionale per l’Informatica nella Pubblica Amministrazione http://www.cnipa.gov.it
80
Pagina 108
2 LA SOLUZIONE ADOTTATA
La soluzione esposta propone un possibile modello architetturale che consenta la
comunicazione/ integrazione tra applicativi. Questa nasce basandosi su un'architettura
orientata ai servizi che integra e rende attuabile la comunicazione tra applicativi, realizzata
attraverso opportune tecnologie di riferimento e con un'adeguata e completa politica di
sicurezza.
Figura 2.1: Modello architetturale di una Suite di Servizi
L’approccio più adeguato è risultato essere quello basato sull'integrazione eseguita attraverso
un nucleo centrale che coordini e renda disponibili una gamma di funzionalità, come fosse
una suite di servizi che ha il fine di offrire una soluzione soddisfacente per le esigenze delle
Piccole e Medie Imprese (PMI) e delle Pubbliche Amministrazioni (PPAA).
In una prima macro-visione dell'architettura possiamo scomporre il sistema in tre elementi
fondamentali:
Pagina 109



Il Documento: è il nucleo del sistema in una visione documentocentrica dell'ar
chitettura (vedi
Figura 2.2). “Documento” va inteso in senso lato, quale contenuto informativo, elemento fondamentale e mezzo di scambio del flusso di dati nella interazione tra i vari applicativi software. La visione documentocentrica nasce dalla analisi delle varie soluzioni tecnologiche degli applicativi che permettono la fruizione immediata dei documenti e delle informazioni in essi contenute. Il documento viene gestito in modo accurato ed efficiente, e integrandosi in Figura 2.2: Visione documento-centrica
modo efficace nel processo in maniera dell'architettura
da porre al centro la produttività dell'utente.
Elementi applicativi: Tutti gli applicativi software che possono fornire servizi utili alle PMI e delle PPAA e che sono stati identificati in base alle esigenze ivi raccolte. Un insieme sostanzialmente generico che copre gran parte delle esigenze specifiche per le imprese è il seguente: DMS, CMS, ERP, suite di Office Automation (OAS), soluzione per la reportistica, soluzione di Business Intelligence e CRM. Per quanto riguarda le PPAA, le esigenze sono più specifiche e legate ad aspetti derivanti da obblighi normativi quali il sistema per il protocollo informatico, la gestione dell'albo pretorio, l'uso della firma digitale e della posta elettronica certificata e, non ultimo, l'esistenza di un portale internet istituzionale rivolto ad offrire i servizi della PA ai cittadini e alle imprese.
Sistema d'integrazione: Ossia il nucleo centrale del sistema che permette di creare e gestire un'architettura di servizi con le opportune tecnologie e gli standard necessari a concretizzarne il funzionamento e attraverso una congrua e solida gestione dei correlati aspetti di sicurezza.
Tra le possibili strategie architetturali utili all’integrazione degli elementi applicativi si è
scelto di trattare e modellare l'architettura usando i concetti e i principi delle Architetture
Orientate ai Servizi (SOA). Essa è infatti la naturale configurazione che ne consegue per la
tipologia stessa di problematiche che si affrontano e le specificità dei vari elementi
architetturali. Inoltre, l'utilizzo di un'architettura del genere permette un'integrazione dei vari
applicativi minimizzando la necessità di intervenire a livello implementativo su ciascuno di
essi.
In questa struttura l'uso di un sistema di integrazione permette di centralizzare alcune
operazioni e non fare ricadere l'onere della comunicazione sui i singoli applicativi e inoltre
permette a ogni singolo applicativo di interagire con gli altri avvalendosi di funzionalità
aggiuntive. A livello centrale, sono gestite anche le problematiche relative alla sicurezza, la
messaggistica e a tutti gli altri aspetti comuni alle varie applicazioni.
Pagina 110
Un altro aspetto dell'integrazione tra applicativi è che questi ultimi devono puntare a esporre
delle interfacce che agevolino l'interazione mediante diverse modalità e protocolli di
comunicazione. In questi casi lo strumento che meglio gestisce questo scenario è un
Enterprise Service Bus (ESB). La struttura sinora descritta può perciò essere implementata
appoggiandosi su tale sistema.
L'ESB è un componente che facilita l'integrazione applicativa con un modello basato su bus,
sul quale i vari applicativi si “affacciano” per poter cooperare con gli altri. Il bus fornisce una
infrastruttura di servizi continua che permette altre funzionalità, quali la mediazione delle
richieste di servizio, la trasformazione e l'instradamento dei dati, e il controllo dei servizi
dell'ambiente.
Nella progettazione dei servizi ci si orienta verso una prospettiva utente-centrica. Per
rispettare tale visione si punta a realizzare e fornire interfacce che permettano di semplificare
l'utilizzo di un applicativo da parte di un utente esterno, nascondendo l'eventuale complessità
intrinseca nell'implementazione. Questo si può ottenere attraverso tecniche di composizione
ed orchestrazione di servizi.
La composizione di servizi, nelle SOA, fornisce la base per il supporto di processi di business
in modo flessibile e relativamente semplice. I servizi sono composti in un ordine preciso e
introducono una serie di regole e un ordine di esecuzione dal quale nasce il processo di
business. Quest’ultimo è quindi una composizione di invocazioni di servizi in un certo
ordine, con regole che influenzano l'esecuzione, come invocazioni in parallelo,
trasformazioni dei dati, dipendenze e correlazioni.
Tra i benefici della composizione aggiungiamo anche la possibilità di poter modificare i
processi di business in modo rapido e, pertanto, di fornire un sostegno più veloce e con meno
sforzi alle esigenze di cambiamenti. Si parla in queste circostanze di servizi di business, ossia
di quelle attività che sono svolte al fine di soddisfare una richiesta, sia essa interna o esterna.
Sono una risposta alle richieste dei clienti. Le attività che non sono state richieste dai clienti
non sono considerati servizi di business.
2.1
Il Ruolo del Portale nell'Erogazione dei Servizi
Il portale di un'organizzazione, sia essa un'impresa o un ente pubblico, svolge un ruolo
fondamentale per la presentazione verso un pubblico esterno della propria immagine e delle
informazioni che si vogliono mostrare. Nel caso specifico della Suite di servizi di cui
trattiamo, il portale ha il ruolo fondamentale utile all'erogazione di questi servizi verso gli
utenti destinatari.
Nell'ambito delle imprese, è importante offrire al pubblico un'immagine di sé quanto più
possibile accattivante e fornire messaggi d'interesse, così da catturare possibili nuovi clienti e
comunque fidelizzare quelli già acquisiti. Ma il portale deve poter anche offrire servizi
evoluti, che permettano l'interazione con l'organizzazione, si pensi ad esempio ai partner o
enti affiliati che hanno la necessità di interagire con l'azienda di riferimento e di richiedere
eventuali servizi. Mediante l'esposizione di servizi, accessibili facilmente tramite un portale, i
flussi comunicativi possono essere resi più continui ed efficienti, facendo risparmiare tempo e
risorse ad entrambe le parti.
Nel caso di un ente pubblico, la presenza di un portale istituzionale diventa un obiettivo
fortemente rimarcato dal Codice dell'Amministrazione Digitale per raggiungere gli obiettivi
Pagina 111
di pubblicità e trasparenza verso i cittadini. Oltre a questo, l'erogazione di servizi di
interazione diretta con gli utenti – siano essi cittadini, imprese, o dipendenti di altri enti
pubblici – se adeguatamente progettati e configurati con una visione utente-centrica, vanno
nella direzione della maggiore efficacia ed efficienza richieste dalle normative vigenti.
Un tale portale permette al cittadino di accedere ai servizi forniti dall'ente facilmente da casa
propria. I vantaggi di tale soluzione sono molteplici:
 raggruppamento in un unico sportello virtuale di sportelli fisicamente dislocati
 eliminazione delle code allo sportello
 servizio sempre disponibile
 riduzione dei tempi di attesa
 migliore trasparenza nelle procedure e atti della PA verso gli utenti
 in generale, soddisfazione degli utenti.
Queste tipologie di portali sono chiamate generalmente Enterprise Information Portal (EIP).
Gli EIP sono, in sostanza, dei siti web che vanno a visualizzare in modo organico semplici
contenuti o componenti interattivi, fungendo da punto unico d'accesso al sistema informativo
e all'insieme di applicativi e servizi specializzati necessari al funzionamento di
un'organizzazione complessa.
3 L'INTEGRAZIONE SEMANTICA
La rappresentazione dell'informazione in un contesto di integrazione e interscambio tra più
applicativi e domini non può prescindere dal considerare il contenuto semantico che i dati
stessi trasportano. Per garantire piena interoperabilità è necessario affiancare al livello
tecnologico un livello di interoperabilità di tipo semantico, come anche previsto nelle
specifiche SPCoop definite dal CNIPA.
L'obiettivo è che le informazioni scambiate siano immediatamente e automaticamente
comprensibili per gli applicativi e gli enti fruitori delle stesse, che spesso utilizzano
terminologie differenti per descrivere concetti analoghi. Una possibile soluzione delle
ambiguità nella rappresentazione dell'informazione e dei concetti può essere fornita dalle
Ontologie.
Il termine “Ontologia” deriva dalla filosofia e si riferisce alla scienza che descrive i tipi di
entità nel mondo e le loro relazioni. La base di partenza su cui si fonda un'ontologia è la
definizione della tassonomia relativa allo specifico contesto, ossia l'identificazione di una
serie di classi di entità che definiscono i concetti in gioco e le relazioni di specializzazione tra
di essi. La tassonomia è appunto la scienza della classificazione. Attraverso tale
classificazione gerarchica si arriva a una rappresentazione che contiene tutte le entità
rilevanti, le relazioni esistenti fra di esse, le regole, gli assiomi ed i vincoli specifici del
contesto. Si parla quindi di ontologia, la quale permette di definire delle regole di inferenza, e
costruire asserzioni nella forma “soggetto” - “predicato” - “oggetto” relativamente alle varie
entità, in modo da consentire a sistemi software di operare in modo “intelligente” sulla
struttura dati rappresentata, favorendo i cosiddetti ragionamenti induttivi.
Con le ontologie si intende quindi gestire le informazioni tramite delle annotazioni
semantiche che permettano di poter poi presentare lo stesso significato con termini presenti
nel “vocabolario” del singolo attore coinvolto nell'interazione.
Pagina 112
Considerando il contesto della pubblica amministrazione, gli attori in gioco sono l'operatore
interno, il cittadino, l'impresa o un altro ente. Ciascuno di essi fa uso di termini, e relativi
significati, in generale diversi, più facilmente comprensibili e vicini al proprio linguaggio. E'
quindi necessario raccogliere le ontologie che raggruppano tutti i significati e i relativi legami
nei contesti in cui ognuno di questi attori si muove. Nelle pubbliche amministrazioni, infatti,
entrano in gioco diverse terminologie a seconda del contesto di riferimento.
Quando si ha a che fare con diverse ontologie si possono eseguire diversi tipi di elaborazioni
che hanno come fine quello di uniformarle in un'unica ontologia di riferimento. Questa
uniformità può essere raggiunta o adottando un'ontologia intermedia e asettica rispetto ai vari
contesti di dominio, o un'ontologia che sia un raggruppamento delle diverse ontologie o
ancora, un'ontologia che estende una delle ontologie sorgenti al fine di aggiungere i concetti
mancanti per la descrizione del contesto globale. In tutti questi casi si dovranno prevedere ed
esplicitare dei mapping (ciò che serve per eseguire una mappatura di un ontologia su un'altra
e viceversa) che permettano di eseguire le opportune trasformazioni all'informazione in modo
da esporla con il linguaggio proprio dell'attore a cui è destinata.
In un'ottica utente-centrica, nel presente lavoro ci si è posti l'obiettivo di presentare tutte le
informazioni provenienti dai vari servizi della Suite con la terminologia propria dell'utente
fruitore finale. Tutti i servizi, compresa anche l'organizzazione dei contenuti mostrati sul
portale, vengono preliminarmente convertiti sull'ontologia di destinazione. In questo modo il
focus viene incentrato sull'utente, il quale riesce a ottenere le informazioni desiderate in modo
più immediato e comprensibile.
4 L'ARCHITETTURA DEL FRAMEWORK DI INTEGRAZIONE
Il framework d'integrazione, basato sul componente centrale ESB, deve quindi orchestrare il
flusso di informazioni provenienti dai vari applicativi, e realizzare la logica adatta ad esporre
un insieme di servizi fruibili con interfacce uniformi e coerenti. Questi servizi sono in
generale utilizzati dagli applicativi stessi: si pensi ad esempio al caso dell'applicativo di office
Figura 4.1: Architettura generale del framework nel caso specifico di PPAA.
Pagina 113
automation che offre una vista sulle cartelle del repository del sistema di gestione
documentale centrale, permettendo di effettuare operazioni quali la visione di uno specifico
documento, la modifica, il relativo salvataggio su DMS, e similari.
In generale, alcuni servizi sono proprio studiati e progettati per risolvere richieste specifiche
provenienti da utenti esterni all'organizzazione. Questi possono essere esposti verso l'esterno,
eventualmente per tramite del sistema di cooperazione applicativa nel caso di PA, per una
fruizione mediante altri sistemi informatici; oppure possono essere direttamente erogati sul
portale dell'organizzazione stessa. In Figura 4.1 viene mostrata l'architettura di massima del
sistema nel caso di ente della PA.
Figura 4.2: Dettaglio dell'architettura : integration framework
Nella Figura 4.2 viene mostrato in maggiore dettaglio la composizione del sistema di
integrazione centrale, in cui il ruolo centrale viene svolto dal sistema ESB e dalla logica di
integrazione che viene implementata.
Affinché il framework possa esporre facilmente la Suite di Servizi sviluppata su un portale, è
stato necessario risolvere alcune problematiche relative alla presentazione verso
un'interfaccia utente web. In modo particolare, è stato necessario definire il sistema di
trasformazione dei contenuti Content Transformer. La necessità di avere questo componente
è legata al fatto che i contenuti provenienti da servizi erogati da applicativi e domini diversi
sono in generale eterogenei. Inoltre, è necessario che i concetti e la terminologia utilizzati
vengano uniformati all'ontologia di dominio. Altra necessità è legata al fatto che i contenuti
che vengono restituiti al portale devono poter essere visualizzati su un browser web, quindi
serve aggiungere informazioni relative alle modalità con cui questi contenuti dovranno essere
rappresentati.
L'obiettivo di questo componente, i cui dettagli di massima sono esposti in Figura 4.3, è
quello di ottenere un formato uniforme che contenga, oltre al contenuto informativo vero e
proprio, dettagli relativi alla classificazione semantica dell'informazione e alle modalità di
rappresentazione sul client web.
Pagina 114
Figura 4.3: Dettaglio del modulo Content transformer
4.1
Servizi specifici esposti dalla Suite
All'interno della Suite sono stati sviluppati una serie di servizi specifici orientati alle
organizzazioni della PA. Questi servizi sono comunque utili anche per le aziende private che
vogliano perseguire gli obiettivi di digitalizzazione e dematerializzazione per perseguire
maggiore efficienza organizzativa.
4.1.1
Autenticazione con CNS e CIE
La Suite d'Integrazione permette l'autenticazione di un utente con CNS (Carta Nazionale dei
Servizi) o CIE (Carta d'Identità Elettronica). Gli utenti che dispongono di una tale smartcard
e relativo lettore correttamente installato e configurato sulla postazione dalla quale si accede
al portale, vengono riconosciuti dal sistema senza la necessità di inserire manualmente le
credenziali.
4.1.2
La Firma Digitale
Tra i servizi forniti dalla Suite d'Integrazione, è di grande interesse il servizio per la firma
digitale dei documenti, la cui validità ai fini giuridico probatori è riconosciuta come
equivalente a quella della firma autografa [FirmaDigitale].
Si è predisposto il sistema d'integrazione in modo che, attraverso il portale, sia possibile il
caricamento di documenti e l'apposizione su di essi della firma digitale. Questa operazione
richiede che l'utente fruitore del servizio sia in possesso di una smartcard rilasciata da un Ente
Certificatore (dispositivo di firma), e dell'apposito lettore, così come per il servizio descritto
in sezione 4.1.1.
4.1.3
Il Notifier e la Posta Elettronica Certificata
La Suite d'Integrazione fornisce il servizio di notifica attraverso il modulo Notifier (vedi
Figura 4.2). Questo modulo riceve delle richieste di notifica da parte del Sistema di
Integrazione e, a seconda del tipo di richiesta ricevuta, predispone la notifica al destinatario.
Come esempio concreto si pensi alle notifiche automatiche in seguito alle operazioni di
registrazione dell'account, notifiche sulle scadenze impostate dall'utente, notifiche su
Pagina 115
aggiornamenti delle sezioni del portale, notifiche di avviso di chiusura di una pratica
personale.
Le notifiche possono essere inoltrate attraverso diversi diversi mezzi, quali email ordinaria,
sms o PEC. Con il termine PEC ci si riferisce al sistema di posta elettronica attraverso il
quale viene fornita al mittente documentazione elettronica, con valenza legale al pari delle
raccomandate A/R per documenti cartacei, attestante l'invio e la consegna di documenti
informatici [PEC].
5 CONCLUSIONI
La soluzione architetturale presentata riguarda la realizzazione di un framework utile a
risolvere una serie di problematiche comuni presenti all'interno di organizzazioni complesse,
che necessitano di ottimizzare i propri processi e migliorare l'efficienza mediante l'uso
appropriato di strumenti software, il tutto realizzabile con tecnologie e standard aperti.
Nell'ambito industriale, è stato realizzato in Flosslab un sistema che implementa l'architettura
qui presentata, facendo uso di applicativi e componenti interamente FLOSS. Nello specifico,
è stato realizzato un portale informativo generico per un ente della PA italiana che si
“poggia” sul sistema di integrazione, il quale espone una serie di servizi per gli utenti, frutto
della composizione e integrazione di servizi elementari provenienti da vari applicativi interni.
Questi servizi vengono erogati tramite le pagine del portale, in base alla tipologia di cui
l'utente fa parte (Cittadino, Impresa, Operatore dell'amministrazione).
In questo modo, un utente del portale potrà richiedere facilmente l'apertura di una specifica
pratica (es. richiesta carta d'identità, pratica edilizia, ...) in modo del tutto automatico, senza
doversi recare allo sportello dell'ente. La richiesta da lui effettuata viene quindi ricevuta dal
sistema di integrazione, il quale si occupa di smistarla, nel caso più generale, al sistema di
protocollo informatico, il quale restituisce il numero di protocollo della pratica e una ricevuta
con i dettagli della stessa richiesta. In ogni momento l'utente potrà verificare lo stato di
avanzamento delle sue pratiche con vari dettagli, tra cui l'ufficio che, in quello specifico
momento, risulta assegnatario della pratica.
In questo lavoro sono state affrontate le problematiche di integrazione tra sistemi informativi
eterogenei sia dal punto di vista architetturale che semantico, proponendo delle soluzioni
integrate basate su componenti FLOSS. Si è giunti a definire un vero e proprio framework di
integrazione capace di adeguarsi alle singole realtà aziendali o amministrative. Tale
framework di integrazione considera esplicitamente la rappresentazione semantica
dell'informazione, e consente l'erogazione di servizi semplici verso utenti esterni,
nascondendo la complessità intrinseca di determinate procedure. Nel caso di enti legati alla
pubblica amministrazione, un tale framework consente di poter agevolmente realizzare
portali di erogazione di servizi e contenuti con alti livelli di interazione con l'utente, secondo
le specifiche definite dal DigitPA.
Bibliografia
1: AA.VV., IDABC, , http://ec.europa.eu/idabc
2: Link.it, Sistema Pubblico di Cooperazione, , www.spcoop.it
Pagina 116
3: CNIPA, Guida alla Firma Digitale, 2009, http://www.cnipa.gov.it/html/docs/GuidaFirmaDigitale2009_a.pdf
4: Presidenza Consiglio dei Ministri, Posta Elettronica Certificata, 2010, https://www.postacertificata.gov.it
Pagina 117
SOFTWARE LIBERO E RADIO 2.0: ANB WEB RADIO, UN
ESPERIMENTO SOCIALE
Ambrosecchia, Domenico, ANB Web Radio, info@anbwebradio.com
Marzano, Flavia, Università di Roma – La Sapienza, Facoltà di Scienze della
Comunicazione, via Salaria 113, 00198 Roma, IT, Flavia.Marzano@uniroma1.it
Olivieri, Alfonso, Avitis Srl, via Ticino 30/G, 20064 Gorgonzola (MI), IT,
alfonso.olivieri@avitis.it
Pani, Fabio, Avitis Srl, via Ticino 30/G, 20064 Gorgonzola (MI), IT,
fabio.pani@avitis.it
Abstract
Il progetto di ANB Web Radio consiste in una diretta radio in streaming, via web, della durata record
di cento giorni: dal 5 marzo 2010 Nico Benz, musicista e ideatore del progetto, si è rinchiuso in uno
studio radiofonico per condurre ininterrottamente questo evento. Con quale scopo? La creazione in
diretta, e in maniera totalmente partecipata, di una piattaforma per la diffusione e la condivisione di
contenuti radiofonici, pubblicata come software libero con licenza GNU/GPL v3.
L'esperimento consta di un laboratorio, aperto e in diretta, dove si intrecciano fra loro diversi temi,
competenze e professionalità, user-generated content: radio, comunicazione, sviluppo software, video,
licenze libere e proprietà intellettuale. Un'alchimia di anime molto diverse tra loro, ma catalizzate
grazie al linguaggio universale della musica, per creare una community probabilmente unica nel suo
genere.
Dati alla mano, i nuovi modi di comunicare non stanno uccidendo la radio, le stanno dando invece
nuova linfa vitale. Rispetto agli altri mezzi di comunicazione, la radio è l'unico a manifestare un
aumento di interesse e di diffusione da quando internet si sta affermando come strumento principale
per la comunicazione multimediale fra le persone: forse è un buon momento per ridefinire nuove
forme comunicative anche per lo strumento principe della telecomunicazione, la radio.
E nonostante la crescita della diffusione di internet sia continua ma lenta (almeno qui in Italia), si
registra invece un'esplosione nell'uso dei social network. Il progetto di ANB Web Radio si
interconnette con i principali social network (Facebook, Twitter, FriendFeed, Youtube, Flickr, ...),
luoghi di discussione per la community e di promozione degli eventi collegati.
Si tratta di una radio che si può vedere come una televisione, che non è televisione e che offre il suo
spazio a interventi di persone diverse, che offrono il proprio contributo divulgativo su temi importanti,
come ad esempio l'uso di licenze libere come Creative Commons, per la tutela e la diffusione delle
proprie opere musicali e artistiche. Grazie al progetto di ANB Web Radio, la SIAE ha accettato
finalmente di discutere pubblicamente, in diretta webradio, dei rapporti con Creative Commons sul
tema della gestione dei diritti dell'autore, al fine di migliorare il difficile rapporto tra le due realtà. La
discussione giova anche alla diffusione della cultura del copyleft, affinché molti artisti emergenti
possano scegliere, se lo desiderano, modi alternativi per la distribuzione delle proprie opere.
Questo esperimento fa ben sperare. I dati statistici che stiamo misurando, dall'inizio dell'evento,
mostrano una partecipazione di molte persone, provenienti da esperienze diverse. I dati mostrano
inoltre una buona affezione al progetto e il clima è collaborativo e propositivo; clima da community,
insomma.
Pagina 118
L'evoluzione della piattaforma servirà a creare nuove radio, ad aggregarle tra loro, a dare a nuovi
artisti nuovi strumenti di creazione di contenuti e opere. Va da sé che i campi applicativi potranno in
futuro discostarsi da quello iniziale della radio e che pertanto la piattaforma potrà essere riutilizzata
per applicazioni diverse; per esempio, per fare formazione e didattica interattiva e a distanza.
Oggi abbiamo a disposizione tutte le tecnologie che ci servono per far evolvere positivamente questo
progetto. Alla fine, fermi restando interesse e partecipazione, farà la differenza poter accedere alla
rete in modo semplice e veloce, come ci si aspetta in un Paese europeo e tecnologicamente avanzato.
Parole Chiave: radio, webradio, streaming, cms, social network, web 2.0, software libero, Creative
Commons, SIAE, community, user generated content.
Pagina 119
1 IL PROGETTO DI ANB WEB RADIO
Dal 5 marzo 2010 il musicista Nico Benz sta tentando di battere un record mondiale:
condurre ininterrottamente una trasmissione della durata di cento giorni in diretta web.
Musica, interviste in diretta, webcam in studio e webcam degli "ascoltatori".
Durante questa prova è consentito a Nico di abbandonare lo studio per brevi periodi; gli è
consentito, inoltre, dormire e lo fa in studio, sotto l'occhio vigile di una webcam.
Che cosa c'entra il software libero in questa iniziativa?
L'idea di Nico Benz è finalizzata alla realizzazione di una piattaforma web (rilasciata come
software libero con licenza GNU/GPL) che consenta, a chiunque, di replicare in modo
semplice una esperienza radiofonica come questa.
La motivazione di tutto ciò nasce dalla convinzione dell'ideatore (e di tutti coloro che hanno
supportato il progetto fin dall'inizio e di coloro che si sono aggiunti nel tempo) che, oggi,
siano disponibili a costi molto bassi tutte le tecnologie necessarie per la creazione di opere
artistiche di ottima qualità e per la realizzazione di sistemi di comunicazione integrati per la
diffusione delle opere stesse.
La piattaforma del progetto ANB Web Radio (http://www.anbwebradio.com) vuole facilitare
l'adozione di strumenti liberi anche da quelle persone (artisti e non solo) che hanno scarsa
dimestichezza con le tecnologie avanzate e guidarle alla scoperta delle alternative efficaci per
la tutela e la diffusione delle opere.
1.1
Internet non ha ucciso la radio, anzi
La radio si è subito integrata con internet, durante la sua evoluzione, e non ne è stata divorata.
Non solo: la diffusione delle stazioni radio commerciali o radioamatoriali, dopo l'avvento di
internet, risulta in crescita mentre altrettanto non si può dire per altri mezzi di comunicazione.
Il rapporto CENSIS 2009 riporta interessanti dati a riguardo.
Ad esempio, il pubblico della radio è aumentato dal 68,8% del 2001 all’81,2% nel 2009, con
nuovi ascoltatori anche attraverso lettori mp3 (18,6%), internet (8,3%) o dal telefonino
(8,1%). D'altra parte, i dati relativi alla diffusione della televisione risultano poco significativi
perché confermano un sostanziale radicamento del mezzo, con un pubblico che nel 2001
raggiungeva già il 95,8% degli italiani, nel 2009 si attesta al 97,8%.
Recentemente la diffusione della carta stampata è calata. La lettura dei quotidiani a
pagamento, almeno una volta alla settimana, è scesa dal 67% del 2007 al 54,8% 2009,
segnando un'inversione di tendenza rispetto al periodo immediatamente precedente.
La diffusione di internet negli anni dal 2007 al 2009 è cresciuta ben poco (dal 45,3% al 47%).
In compenso, per gli utenti internet è negli ultimi due anni è esploso l'uso dei social network,
primi fra tutti Facebook e YouTube.
Pagina 120
Figura 8.
Figura 9.
Utenti internet in Italia 1997-2009 (fonte:
http://www.gandalf.it/dati/dati3.htm)
Utenti internet per età (in Italia, in percentuale) (fonte:
Pagina 121
Figura 10.
Figura 11.
Uso di risorse di informazione e comunicazione in Italia, per genere
(percentuale sul totale per ciascuna categoria) (fonte:
Uso di risorse di informazione e comunicazione in Italia per età (percentuali
sul totale in ciascuna categoria) (fonte: http://www.gandalf.it/dati/dati3.htm)
Pagina 122
Usare il protocollo TCP/IP invece delle onde hertziane ha dei vantaggi: semplifica
enormemente la fattibilità tecnica di una radio broadcast, ne abbatte drasticamente i costi,
raggiunge più facilmente le aree del globo indipendentemente dalla propagazione ionosferica
del segnale. E, naturalmente, interagisce in modo immediato con le altre applicazioni del
web; ad esempio realizzando una comunicazione bidirezionale tra chi fa la radio e chi la
ascolta.
1.2
Le nuove radio libere
Il fenomeno delle webradio ricorda quello della nascita e la diffusione delle radio libere degli
anni '70, inizialmente considerate radio pirata e, pertanto, illegali. Ma sulla base della libertà
di espressione, sancita non solo dalla Dichiarazione universale dei diritti dell'uomo ma anche
dalla nostra stessa Costituzione, esse furono legalmente riconosciute nel 1976.
Così come la liberalizzazione delle radio libere comportò una positiva ricaduta
(miglioramento e innovazione dei contenuti grazie alla competizione con il servizio pubblico,
sperimentazione di nuove tecnologie come ad es. la stereofonia), la diffusione delle webradio
comporterà la nascita di nuove idee di comunicazione, che potranno arricchire anche la radio
tradizionale.
Da alcuni anni le webradio hanno un riconoscimento ufficiale anche in Italia, ma per questo
occorre pagare un tributo annuale a SIAE e SCF. Niente burocrazia né tributi nel caso in cui
le licenze d'uso delle opere ne consentano invece la libera diffusione radiofonica.
Vale la pena citare la nascita, in Svezia, nel 2006, del Piratpartiet (in italiano, Partito
Pirata), un vero e proprio partito politico creato dal basso con lo scopo di modificare il
copyright e il diritto d'autore, in quanto ritenuto troppo sbilanciato a favore dello
sfruttamento economico a scapito dello sviluppo culturale della società (fonte:
http://it.wikipedia.org/wiki/Partito_Pirata_(Svezia)). Questo movimento ha avuto seguito,
nello stesso anno, in altri paesi europei (inclusa l'Italia) e negli Stati Uniti, sempre con le
stesse finalità.
2 LA PIATTAFORMA SOFTWARE
Il progetto di ANB Web Radio ha dato vita a Streammix, software libero rilasciato
pubblicamente con licenza GNU/GPL v3 (https://launchpad.net/streammix). La scelta ricade
su questa licenza in quanto, a nostro avviso, è quella che garantisce la migliore diffusione del
software stesso e la più ampia partecipazione di persone interessate al progetto.
L'architettura generale del software deriva da un precedente lavoro di Fabio Pani, CMSKey
(un CMS82 libero rilasciato con licenza GNU/GPL v2): scritto in linguaggio PHP e supportato
da un database MySQL. Alfonso Olivieri ha curato l'implementazione dell'ambiente di test
iniziale e l'integrazione con i social network e le sorgenti streaming esterni.
La piattaforma per la collaborazione allo sviluppo è Launchpad (la stessa che ospita svariati
progetti di software libero, tra i quali lo stesso sistema operativo Linux Ubuntu): tale
piattaforma è dotata di tutti i principali strumenti per la gestione di un progetto software
condiviso, come ad es. il repository del software, un bugtracker, un wiki e strumenti per la
localizzazione linguistica del software.
82
Content Management System, sistema per la gestione dei contenuti.
Pagina 123
2.1
Motore iniziale del progetto
Per la realizzazione del sito iniziale del progetto è stato utilizzato Wordpress, un CMS libero.
La piattaforma, ancora in fieri, permette già diverse attività con un ottimo livello di
interazione utente. In particolare, in una sola pagina oggi è già possibile:
 ascoltare e vedere in streaming audio/video la trasmissione in diretta (via Livestream la regia audio e video è a cura di Nico Benz);
 comunicare attraverso la chat Livestream fra gli utenti collegati;
 comunicare attraverso una videochat esterna – la videochat può essere ritrasmessa in video da studio;
 mandare in onda brani musicali in modo automatico, tra quelli proposti in un database;
 assistere a spettacoli musicali dal vivo dal bLevel di Milano, incluse jam session tra musicisti sul palco e con lo stesso Nico Benz in studio, oppure collegamenti crossover con altre radio, web o terrestri;
 collegarsi automaticamente ai principali social network (Facebook, Twitter ecc.), discutere e pubblicare automaticamente su questi riguardo agli eventi che sono proposti in diretta web;
 accedere a diverse risorse esterne correlate.
2.2
Funzionalità del software e caratteristiche
La piattaforma Streammix, in fase di sviluppo, consente agli utenti registrati di ottenere una
pagina simile a quella dell'attuale progetto ANB Web Radio, personalizzabile.
La registrazione è libera e gratuita e richiede la specifica di un nome-utente e un indirizzo di
posta elettronica. In alternativa, l'utente può accreditarsi autenticandosi una prima volta ad
uno dei social network che preferisce e al quale è già iscritto (per adesso, Facebook oppure
Twitter ma prossimamente anche su altre piattaforme di social network). Alla conferma
dell'iscrizione l'utente avrà un'area web referenziata come sottodirectory dell'indirizzo
internet (es. http://www.anbwebradio.com/user/nome_utente).
La personalizzazione della pagina consente di impostare le proprie preferenze (ad es.,
modificando la sorgente dello streaming da riprodurre) o agevolare la creazione di una nuova
webradio.
Nella pagina personale (così come nella pagina principale del progetto) sarà possibile
visualizzare una lista di link che puntano alle rispettive pagine degli utenti registrati.
Ovviamente, il software può essere installato in un server diverso da quello che attualmente
ospita il progetto, allo scopo di replicare l'esperienza, per ragioni sperimentali o per la
realizzazione di community alternative, non necessariamente correlate con lo streaming di
trasmissioni radio musicali.
3 SOCIAL NETWORK
L'interazione attraverso i social network è ormai di ampia diffusione presso gli utenti della
Rete. La piattaforma consente di interagire con i principali social network: è possibile
pubblicare messaggi verso tali piattaforme esterne direttamente dalla pagina del progetto; è
Pagina 124
possibile partecipare a discussioni commentando in diretta gli eventi trasmessi nella
webradio estendendo la comunicazione su Facebook, Twitter ecc.
La piattaforma consente di visualizzare, all'interno della pagina della webradio, messaggi
provenienti da social network esterni e sui quali l'utente può autenticarsi in modo semplice e
sicuro.
Gruppi di ascoltatori hanno la possibilità di interagire in audio e video, in modo indipendente
dallo svolgimento della trasmissione radio e comunque all'interno della pagina della
webradio, avvalendosi di una piattaforma di videochat esterna (Tinychat). Se la regia lo
ritiene opportuno, può decidere di mandare in onda la videochat e/o di partecipare essa stessa
alla discussione.
4 CONTENUTI E DINAMICHE SOCIALI
4.1
Una piattaforma usata per definire se stessa
ANB Web Radio è una radio a contenuti prettamente musicali, ma il progetto ha fatto sì che
essa diventasse, fra l'altro, il luogo di discussione per la community che contribuisce alla
fisionomia futura di questo strumento, partecipando alla sviluppo: non solo user-generated
content, quindi, ma partecipazione dal basso anche nella definizione della piattaforma stessa,
proprio come nelle comunità del mondo del software libero e in piena modalità 2.0!
Per noi, questa è la user-generated radio!
La discussione stessa, tra chi di volta in volta partecipa al dibattito, ha valenza divulgativa sui
temi della condivisione della conoscenza, sull'uso del software libero, sull'uso delle licenze di
tipo copyleft per la diffusione del software, delle opere artistiche e la tutela della proprietà
intellettuale; molti sono già stati gli interventi in quest'ottica e molti altri ne sono previsti.
L'utilizzo di un linguaggio universale come quello della musica applicato alla divulgazione
dei temi suddetti è molto innovativo, non solo perché ciò consente di rivolgersi in modo
trasversale a una audience molto diversificata, ma anche per le modalità con cui è nata e si è
sviluppata anche grazie alla collaborazione attiva dei singoli ascoltatori.
Come in una jam session, come in un barcamp, i contenuti dipendono dagli attori del
momento, da chi sta partecipando, e soprattutto evolvono nel tempo in funzione di chi
collabora attivamente. Lo abbiamo sperimentato direttamente, attirando persone provenienti
da altre comunità attive nel mondo del sapere libero, con un apporto concreto di competenza
in materia di Software Libero, di licenze Creative Commons e di reti sociali del web 2.0;
questa è stata in particolare l'attività di Flavia Marzano.
4.2
Interventi in diretta
Grazie all'uso di applicazioni esterne per videoconferenza, videochat o telefonia VoIP (come
ad es. Ekiga, ma anche Skype nel mondo del software chiuso e proprietario, proprio perché
dobbiamo e vogliamo essere aperti il più possibile a interventi di chiunque) è possibile
partecipare in diretta webradio, in audio e video, su discussioni e interviste. Questo dà modo
a molte persone che partecipano al progetto di contribuire concretamente alla diffusione di
Pagina 125
idee e conoscenza presso gli utenti collegati, in particolare alla diffusione del software libero
e dei liberi saperi basati su licenze aperte.
A ConfSL2010 trasmetteremo in streaming da ANB Web Radio gli interventi più
significativi.
4.3
Creative Commons vs SIAE
Non poteva mancare, nella discussione, il tema relativo alla proprietà intellettuale e ai diritti
d'autore delle opere musicali. Grazie al progetto, il dibattito sulle problematiche connesse al
diritto d'autore e la SIAE sta acquistando nuova forza.
La divulgazione sull'uso di licenze libere quali Creative Commons è informazione preziosa
presso molti gruppi di giovani artisti che vogliano usare canali alternativi per la diffusione
della propria musica.
Un interessante effetto di questo esperimento sociale riguarda la SIAE, che ha accettato di
confrontarsi in diretta webradio con Creative Commons, sul tema specifico dei loro rapporti
rapporti reciproci come, ad es., l'inadeguatezza della legge n. 633 risalente al 22 aprile 1941
("Protezione del Diritto d'Autore e di altri diritti connessi al suo esercizio"). Di fatto, si
delinea un possibile avvicinamento tra questi due mondi a livello di legislazione italiana,
anche grazie all'intervento di ANB Web Radio.
4.4
Ulteriori risorse
Durante la trasmissione sono state segnalate dagli utenti/ascoltatori risorse sul web che
diffondono musica con licenze libere, come ad es. OnClassical.com, Jamendo, BuskerLabel,
GNU Funk, dimostrando così, se mai ce ne fosse stato bisogno, l'importanza della comunità e
della partecipazione dal basso nei processi di produzione e diffusione dell'informazione e
della conoscenza!
5 CONCLUSIONI – SVILUPPI FUTURI
5.1
Convergenza dei media
L'esperienza di ANB Web Radio è un ulteriore esempio di convergenza dei media. La radio
diventa anche televisione; le radio si ritrasmettono in diretta tra loro (crossover), via web o
radiofrequenza; l'utente è pure disc-jockey, gli utenti comunicano tra loro (testo, voce e
immagine) ed estendono i propri commenti sui rispettivi network sociali di appartenenza.
Col passaggio dall'informazione analogica a quella digitale, l'infrastruttura della Rete
trasforma gli oggetti del passato a più moderne applicazioni interconnesse, capaci di
comunicare tra loro in modo naturale, sfruttando una piattaforma di comunicazione comune.
5.2
Interesse e partecipazione
Fin dall'inizio del progetto e l'inaugurazione del sito di ANB Web Radio (5 marzo 2010) la
partecipazione è stata discretamente alta. Una valutazione in tempo reale del livello di
Pagina 126
partecipazione è fornita dallo stesso player di Livestream, che indica il numero di utenti
collegati in ogni momento. Questo valore oscilla tipicamente tra venti e quaranta utenti.
Per mezzo di Awstats (un software libero per la realizzazione delle statistiche legate alle
visite dei siti web) sono disponibili misure sul livello di partecipazione. La pagina del
progetto ANB Web Radio riceve in media 300 visite uniche ogni giorno, prevalentemente
dall'Italia83. La media delle pagine viste per visita è di oltre 300 (trecento), in costante
leggero aumento.
La lettura del dato relativo alle visite ricevute attraverso i motori di ricerca non è
significativa, data la conformazione della pagina di progetto che non contiene in sé contenuti
testuali aggiornati e facilmente indicizzabili.
5.3
Sviluppi futuri
La piattaforma può essere utilizzata per applicazioni diverse, ove sia concepibile una
community che fruisca di streaming audio e video di vario tipo; un esempio cui abbiamo
accennato è la possibilità di usare questa piattaforma per realizzare un sistema interattivo per
la formazione a distanza (aula scolastica virtuale), ma anche per convegni, seminari e attività
di comunicazione.
Il codice sorgente per lo streaming fino ad ora usato proviene da sistemi (proprietari) esterni.
Il funzionamento in sé è indipendente dal sistema che genera i contenuti multimediali, ma è
nostro interesse promuovere l'utilizzo di software libero anche per la generazione dello
stream audio/video (ad es. VLC, Icecast).
Pur disponendo di tutte le tecnologie necessarie, oggi, in Italia, il vero limite allo sviluppo di
sistemi come quello usato per il progetto ANB Web Radio è l'arretratezza della nostra
infrastruttura di rete, che si traduce purtroppo in velocità e banda a volte insufficienti, carenza
di punti di accesso, costo ancora elevato della connessione.
Infine, l'abbattimento del digital divide non può che apportare vantaggi allo sviluppo di
tecnologie come quella qui presentata, favorendo l'allargamento della comunità e la
condivisione del progetto e dei suoi contenuti.
83
Il dato è aggiornato al periodo della stesura di questo documento.
Pagina 127
Bibliografia
Concas, G.; De Petra, G.; Marzano, F.; Zanarini, P. (2007). Finalmente libero! McGraw-Hill.
Concas, G.; De Petra, G.; Gallus, G. B.; Ginesu, G.; Marchesi, M.; Marzano, F. (2009).
Contenuti aperti, beni comuni. McGraw-Hill.
Marika de Acetis, “Il Web 2.0”:
http://www.torinoscienza.it/img/pdf/it/s10/00/002c/00002c8a.pdf
Tim O'Reilly, “What Is Web 2.0, Design Patterns and Business Models for the Next
Generation of Software”: http://oreilly.com/web2/archive/what-is-web-20.html?page=1
Enrico Fedi, “Web and radio”: http://sibaese.unisalento.it/index.php/quadcom/article/view/5029/4399
Mattia Miani, “Nuove tecnologie per la comunicazione e l'informazione. Il web 2.0 nella
pubblica amministrazione”:
http://www.tsm.tn.it/documenti/pa/2010/mat_supporto_Nuove_tecnologie_mod.pdf
Tesi di laurea di Sara Piazzalunga, "Il podcasting: la radio fai da te sul web":
http://www.tesionline.com/intl/thesis.jsp?idt=12109
Tesi di laurea di Alba Rizzo: "L'ibridazione mediatica. La radio in rete":
http://www.tesionline.it/default/tesi.asp?idt=13617
Raffaella Natale, "Convergenza dei media: uno studio Ofcom per valutare l’impatto. Italia tra
i primi per IPTV e downloading di musica e podcast":
http://www.key4biz.it/News/2008/02/28/Tecnologie/Convergenza_Ofcom_contenuti_audiovi
sivi_VoIP_video_on_demand_download_to_own_IPTV.html
"Trends in USA Amateur Radio License Classes Over Three Years":
http://www.eham.net/articles/22842
"Ham Radio Growing In The Age Of Twitter": http://www.npr.org/templates/story/story.php?
storyId=125586086&ft=1&f=1019
Questo articolo, nelle sue parti originali, è coperto da licenza
Creative Commons: Attribuzione, Non commerciale, Condividi allo stesso modo.
http://creativecommons.org/licenses/by-nc-sa/2.5/it/legalcode
Pagina 128
LE CARATTERISTICHE DELLE IMPRESE SOFTWARE IN
EMILIA-ROMAGNA: TRE MODELLI DI IMPRESA A
CONFRONTO
Grassano, Nicola, Università di Bologna, strada Maggiore 45, 40125 Bologna, IT,
nicola.grassano2@unibo.it
Rentocchini, Francesco, Università di Trento, via Inama 5, 38122 Trento, IT,
francesco.rentocchini@economia.unitn.it
Tartari, Dimitri, Regione Emilia-Romagna, v.le Aldo Moro 18, 40127, Bologna, IT,
dtartari@regione.emilia-romagna.it
Il presente contributo rappresenta un'anteprima di un più ampio studio denominato “Indagine sulle
caratteristiche e la capacità innovativa delle imprese IT in Emilia-Romagna”, nato all’interno del
gruppo di lavoro Emilia-Romagna Open Source Survey (EROSS), che costituisce il naturale
proseguimento dei diversi progetti aventi ad oggetto la Pubblica Amministrazione (EROSS-PA),
riguardanti l'adozione di software a codice sorgente aperto da parte della pubblica amministrazione
locale.
Nello specifico, nelle pagine che seguono, ci si concentrerà sulle imprese localizzate in EmiliaRomagna appartenenti al settore software, su alcune delle loro caratteristiche strutturali e sul modello
di business che queste adottano (più o meno basato su software open source), al fine di trarne alcune
indicazioni preliminari che fungano da base per futuri approfondimenti.
Lo scopo dunque è di proporre alcuni dei principali risultati descrittivi fin qui ottenuti dall'indagine
con riferimento alle sole imprese software, differenziandole in base al modello di business adottato.
Quest'anteprima dell'indagine sulle caratteristiche e la capacità innovativa delle imprese IT in EmiliaRomagna fornisce un primo contributo importante alla quantificazione delle imprese che a livello
regionale offrono prodotti e servizi basati in tutto o in parte su software open source. Infatti, tale dato
è stato per la prima volta stimato con un’indagine condotta su larga scala e statisticamente robusta.
L'aspetto più interessante che emerge è che le imprese che nel loro modello di business includono il
software open sembrerebbero presentare una migliore performance innovativa (misurata come la
percentuale di fatturato 2008 derivante dall'introduzione di nuovi prodotti e/o servizi) rispetto alle
imprese che offrono prodotti e/o servizi basati principalmente o solamente su software proprietario.
Il rapporto dunque tra modello di business adottato e innovatività dell'impresa merita certamente
ulteriore attenzione e sarà una delle direzioni in cui si muoveranno le analisi future.
Parole Chiave: Open source, imprese, indagine empirica, innovazione
Pagina 129
1 INTRODUZIONE
Il presente contributo rappresenta un'anteprima di un più ampio studio denominato “Indagine
sulle caratteristiche e la capacità innovativa delle imprese IT in Emilia-Romagna”1, nato
all’interno del gruppo di lavoro EROSS2 , che costituisce il naturale proseguimento dei
diversi progetti EROSS-PA, riguardanti l'adozione di software a codice sorgente aperto da
parte della pubblica amministrazione locale.
Nello specifico, nelle pagine che seguono, ci si concentrerà sulle imprese localizzate in
Emilia-Romagna appartenenti al settore software, su alcune delle loro caratteristiche
strutturali e sul modello di business che queste adottano (più o meno basato su software open
source), al fine di trarne alcune indicazioni preliminari che fungano da base per futuri
approfondimenti.
Lo scopo dunque è di proporre alcuni dei principali risultati descrittivi fin qui ottenuti
dall'indagine con riferimento alle sole imprese software, differenziandole in base al modello
di business adottato.
2 LE IMPRESE SOFTWARE IN EMILIA-ROMAGNA
Ogni 10 imprese IT presenti in Regione, c’è n’è una che basa il suo modello di business
sull’offerta esclusiva o prevalente di soluzioni open source, mentre ve ne sono altre due che
adottano un modello “ibrido”, che si fonda cioè sia su soluzioni di tipo open sia di tipo
proprietario (Figura 23). Questo dato è di estremo interesse, dato che non esisteva ad oggi
una stima della diffusione dell’open source tra le imprese della Regione che offrono prodotti
e servizi IT basata su una rilevazione così estesa. Inoltre, la rappresentatività del campione
estratto e delle risposte ottenute permette di essere sicuri circa il peso che tale comparto
assume relativamente al settore IT Emiliano-Romagnolo 84.
4,8% 0,3% percentuale delle imprese IT in base al modello di business adottato
Figura 12. 6,2%Distribuzione
20,1%
20,1%
Esclusivamemte
OSS
Prevalentemente
OSS
Ibrido
Prevalentemente
o esclusivamente
proprietario
No software
Non risponde
48,5%
L’indagine ha coinvolto un campione di 512 imprese localizzate sul territorio regionale che operano nel settore software selezionate all'interno di una numerosità regionale complessiva di 7.854 imprese. Il campione e stato ottenuto tramite una doppia stratificazione per provincia e per classe di raggruppamento di codici di attività economica (ATECO). La somministrazione del questionario è avvenuta tramite interviste telefoniche condotte con il metodo CATI. Le risposte ottenute sono state 373. La minore numerosità del campione effettivo non ha inficiato la precisione dell'indagine che rimane sostanzialmente invariata rispetto al valore calcolato con la numerosità stimata nel disegno campionario.
84
Pagina 130
Concentrandosi solo sulle imprese software e dividendole in tre gruppi in base al modello di
business che adottano (esclusivamente o prevalentemente basato su OSS, ibrido oppure
esclusivamente o prevalentemente basato su software proprietario) è possibile analizzare una
serie di caratteristiche dei diversi gruppi per capire se, e in che misura, si distinguono gli uni
dagli altri.
Le Figure 13 e 14 riportano rispettivamente il numero di addetti ed il numero di tecnici e
sviluppatori per il totale delle imprese software e raggruppate nei tre modelli di business
individuati. Il risultato maggiormente di impatto è che l'11,8 % delle imprese intervistate
sono imprese individuali e che circa sette imprese su dieci (il 70,3 % del totale) hanno al
massimo 5 addetti. Al contrario, solo il 14,1% delle imprese dichiara di avere più di 10
addetti, con quelle che superano i 100 che rappresentano poco più dell'1%.
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
Totale imprese softw are
Nessuno
10-----| 15 addetti
Figura 13.
Open source
1 addetto
15-----| 50 addetti
Ibrido
1-----| 5 addetti
50-----| 100 addetti
Proprietario
5-----| 10 addetti
Oltre 100 addetti
Distribuzione delle imprese per classe di addetti (divise in base al modello di
business adottato)
Nel complesso, quindi, la struttura regionale del comparto software rispecchia la tradizionale
struttura industriale Italiana riscontrabile anche in numerosi altri settori produttivi del Paese,
dato che l'85,9% delle imprese è di piccole e piccolissime dimensioni (meno di 10 addetti).
Non sembra emergere una netta distinzione tra imprese open, miste e non open circa il
numero di addetti, anche se si nota una maggior incidenza delle imprese individuali nei
segmenti open e ibrido rispetto a quello proprietario, che di contro è l'unico nel quale si
registra una presenza significativa di imprese sopra i 15 addetti, pari all'11% del totale
(contro una media dell'intero comparto del 9,1%).
La distribuzione percentuale delle imprese del campione in base alle unità nel ruolo di
sviluppatori/tecnici mostra come il 61,3% delle imprese nel 2008 abbia dichiarato di avere da
1 a 5 addetti nel ruolo di sviluppatori/tecnici, dato molto simile a quello del numero di
imprese quando si considerano di addetti in generale (58,6%). Questo dato riflette e conferma
la forte incidenza del personale tecnico sul numero totale di addetti delle imprese del
comparto IT. Anche guardando la distribuzione percentuale delle imprese software in base
alle unità nel ruolo di sviluppatori/tecnici non paiono significative le diversità tra imprese con
diversi modelli di business, dato che in ogni segmento la percentuale di imprese che dichiara
di avere un numero di sviluppatori/tecnici compreso tra 1 e 5 è di circa il 60%.
Pagina 131
60%
50%
40%
30%
20%
10%
0%
Nessuno
10-----| 15 addetti
Figura 14.
Open source
1 addetto
15-----| 50 addetti
Ibrido
Proprietario
1-----| 5 addetti
50-----| 100 addetti
5-----| 10 addetti
Oltre 100 addetti
Distribuzione delle imprese per classe di personale nel ruolo di sviluppatori/tecnici
(divise in base al modello di business adottato)
La Figura 15 riporta il dato circa il fatturato 2008 delle imprese software che conferma
quanto già evidenziato osservando il numero degli addetti circa le dimensioni delle imprese
confermando dunque la preponderanza di imprese di piccole dimensioni. Come in precedenza
non si notano grandi differenze tra le imprese software a seconda del modello di business
adottato e, analogamente a quanto osservato per il numero di addetti e di sviluppatori/tecnici,
l'unica tendenza che emerge è che le imprese più grandi, cioè con un fatturato 2008 più
elevato, sono quelle che si concentrano su di un'offerta proprietaria.
70%
60%
50%
40%
30%
20%
10%
0%
0--|500
Figura 15.
500--|1.000
Open source
1.000--|2.000
Ibrido
2.000--|10.000
Proprietario
Oltre 10.000
Non risponde
Distribuzione percentuale delle imprese software per classe di fatturato 2008 in
migliaia di euro(divise in base al modello di business adottato)
Se da un punto di vista di numero di addetti, di sviluppatori/tecnici e di fatturato non è emersa
una differenza netta tra le imprese software in base ai diversi modelli di business adottati, la
situazione cambia quando si considera il fatturato innovativo 2008, cioè la percentuale del
fatturato 2008 dovuta all’introduzione di nuovi prodotti e/o servizi, dato riportato in Figura
16.
Pagina 132
60%
50%
40%
30%
20%
10%
0%
Open source
Lo 0% del fatturato
1-----| 5% del fatturato
Figura 16.
Ibrido
Non risposta
Proprietario
Il 100% del fatturato
Distribuzione delle imprese software per classe percentuale di fatturato derivato
dall'introduzione di nuovi prodotti e/o servizi (divise in base al modello di business
adottato)
Poco meno della metà delle imprese software in Regione (46,8%) dichiara che una frazione
positiva del proprio fatturato nel 2008 derivi dall’introduzione di nuovi prodotti e/o servizi.
Se si guarda alla disaggregazione in base al modello di business adottato, la percentuale di
imprese per le quali una frazione positiva del proprio fatturato nel 2008 deriva
dall’introduzione di nuovi prodotti e/o servizi è il 41,4% nel caso delle imprese proprietarie,
mentre la percentuale sale rispettivamente al 56,0% e al 53,6% nel caso delle imprese del
segmento ibrido e di quello open. Inoltre 2,5 imprese open ogni 10 derivano dal 50% al 100%
del proprio fatturato 2008 dall'introduzione di nuovi prodotti e/o servizi, mentre nel caso delle
imprese software nel loro complesso il numero scende a 1,5 ogni 10 imprese. Sembra dunque
emergere una tendenza interessante, il maggiore impatto dell'innovazione sul fatturato per le
imprese software del segmento open e ibrido rispetto a quelle del segmento proprietario.
Le tipologia di prodotti e servizi offerti dalle imprese software nel loro complesso e divise nei
tre gruppi individuati sono riportate rispettivamente nelle Figure 17 e 18.
Come è ovvio, dato che stiamo considerando le sole imprese software, i software sviluppati o
personalizzati per il cliente sono il prodotto maggiormente offerto (53,2% delle imprese li
offrono). Rivestono una certa importanza anche la vendita di hardware (41,1%) e
componentistica e la realizzazione siti web e/o soluzioni e-commerce (38,7%).
70%
Figura
17.
Distribuzione percentuale delle imprese software (divise secondo il modello di
60%
50%
40%
30%
20%
10%
0%
Applicativi gestionali
amministrativi (CRM,
ESP)
Prodotti softw are sviluppati da terzi
Altro: specificare
Open source
Ibrido
Proprietario
Softw are perPagina 133
office
Sviluppo e personaautomation
lizzazione softw are
Prodotti multimediali
Content Management
System (CMS)
Hardw are e componentistica
Nessuno di questi
Realizzazione siti w eb
e/o soluzioni e-commerce
Interessante notare che, se da un punto di vista di tipologia dei primi tre prodotti offerti non
c'è una significativa differenza tra le imprese open, miste e proprietarie (anche se cambia
l'ordine di importanza tra il secondo ed il terzo), una diversità sembra invece emergere dal
punto di vista della varietà dei prodotti offerti, con le imprese open e miste che sembrano
avere un maggior ventaglio di soluzioni software offerte contemporaneamente. Per ogni
tipologia di prodotto offerto, infatti, la percentuale di imprese proprietarie che lo offrono sul
totale delle imprese del segmento non è mai contemporaneamente più alta dell'analoga
percentuale calcolata per le imprese open o miste, indicando appunto una maggior varietà
d'offerta di prodotti da parte di queste ultime tipologie di imprese.
Per quel che riguarda i servizi offerti, i tre principali risultano essere l'assistenza post vendita
(54,9%), la manutenzione software (54,2%), e la consulenza per l’installazione di software
(50,8%). Come notato per quel che riguarda i prodotti offerti, se per tipologia dei primi tre
servizi offerti non c'è una significativa differenza tra le imprese open, miste e proprietarie, le
imprese open e miste paiono caratterizzate da una maggiore varietà dei servizi offerti
rispetto a quelle del segmento proprietario.
80%
70%
60%
50%
40%
30%
20%
10%
0%
Consulenza per l'installazione di softw are
Manutenzione e riparazione sistemi
hardw are
Amministrazione di
banche dati
Altro: specificare
Figura 18.
Open source
Ibrido
Proprietario
Consulenza per l'installazione di sistemi
hardw are
Formazione
Assistenza/servizi
post-vendita
Manutenzione
softw are
Hosting di siti
w eb/banche dati, etc.
Elaborazione dati e/o
data entry
Sistemi di controllo
industriale (SCADA,
DCS, PLC, ...)
Nessuno di questi
Integrazione f ra
componenti softw are
Ricerca e sviluppo
Distribuzione percentuale delle imprese software (divise secondo il modello di
business adottato) in base alla tipologia di servizi offerti (possibili più risposte)
Le Figure 19 e 20 mostrano rispettivamente i canali informativi in “entrata” ed in “uscita”,
quelli cioè che l’impresa utilizza per acquisire informazioni sull’innovazione (entrata) e per
pubblicizzare i nuovi prodotti e/o servizi (uscita).
Per quel che riguarda l'acquisizione delle informazioni sull’innovazione i tre canali principali,
pur con intensità differenti a seconda del modello di business preso in considerazione,
risultano essere: (i) le comunità on line e/o i social network (62,6%); (ii) i fornitori (52,2%);
(iii) le conferenze, i seminari o i convegni (50,5%). Elaborazioni interne all'impresa, così
come mostre e fiere, hanno una certa rilevanza per le imprese open e ibride, che anche in
questo caso mostrano una maggior varietà di canali informativi in entrata.
Pagina 134
80%
70%
60%
50%
40%
30%
20%
10%
0%
Open source
Ibrido
Proprietario
Fornitori
Clienti
Altre imprese
Centri di ricerca pubblici (università, centri
di istruzione superiore,
...)
Associazioni di categoria
Mostre/fiere
Conferenze, seminari,
convegni
Comunità online (anche open-source) e/o
social netw ork
Elaborazioni interne all'impresa
Figura 19.
Centri di ricerca privati
(consulenti, laboratori
privati, ...)
Studi di mercato, pubblicazioni/riviste scientifiche
Canali di acquisizione di informazioni da parte delle imprese software (divise
secondo il modello di business adottato) sulle innovazioni da introdurre
Tale dato è in linea con quanto notato sul fatturato innovativo 2008, che ha già segnalato
come per le imprese open e miste l'impatto dell'innovazione sul fatturato sia percentualmente
maggiore, il che è coerente con un maggior impegno nella ricerca delle informazioni
sull'innovazione da introdurre, ricorrendo a più canali e con maggiore intensità rispetto alle
imprese del segmento proprietario. Per le imprese software nel loro complesso risultano
scarsamente importanti i centri di ricerca, pubblici o privati che siano, pur se con qualche
distinguo in base al modello di business adottato.
Considerando i canali di “uscita”, ovvero le modalità con cui l’impresa rende note le
informazioni circa i nuovi prodotti e servizi introdotti sul mercato, risulta chiaro come siano i
siti internet di settore e blog specialistici (60,3%), newsletter (39,1%) e, infine, conferenze,
seminari e convegni (21,5%) i canali più usati, scarsa rilevanza hanno invece gli spazi delle
associazioni di categoria e le riviste specialistiche. Di nuovo, la differenza tra la imprese open
e miste da un lato e quelle proprietarie dall'altro sembra essere la varietà di canali utilizzati,
maggiore per le prime due tipologie d'impresa.
80,0%
Figura
20.
Canali utilizzati dalle imprese software (divise secondo il modello di business
70,0%
60,0%
50,0%
40,0%
30,0%
20,0%
10,0%
0,0%
Riviste specialistiche
New sletter
Open source
Ibrido
Siti internet di settore,
Fiere, mostre
blog specialistici
Appositi spazi delle
Meeting informali (tipo
associazioni diPagina 135
cateLUG=Linux User
goria (portali di asGroup, ....)
sociazioni, ...)
Proprietario
Conferenze, seminari,
convegni
Tra le imprese che hanno adottato un modello di business basato su software open source
(modello ibrido o modello open) la partecipazione a comunità open source risulta
relativamente scarsa e pari al 21,4% (Figura 21). Questo risultato è molto interessante in
quanto potrebbe segnalare un'offerta di software open legato più a vantaggi tecnici ed
economici che ad un’adesione ai valori di libertà del software e condivisione del codice tipici
della comunità open. Un ulteriore fattore che potrebbe contribuire a spiegare il dato fa
riferimento al comportamento delle imprese IT in Regione in materia di sviluppo di nuovi
prodotti che potrebbe risultare improntato a logiche fortemente competitive.
Si
21%
Non so
1%
No
78%
Figura 21.
Partecipazione attiva da parte dell'impresa a progetti
A tutte le imprese campionate (indipendentemente dunque dal modello di business adottato) è
stato poi domandato di fornire il loro punto di vista circa i motivi che possono incentivare o
disincentivare l’offerta di prodotti e/o servizi open source. La Figura 22 riporta i pareri delle
imprese intervistate che hanno indicato un giudizio positivo (coloro che si sono detti
“d'accordo” o “molto d'accordo”) circa le motivazioni proposte a seconda del modello di
business adottato. Come era ragionevole attendersi, le imprese che fanno riferimento ad un
modello basato prevalentemente od esclusivamente su open source si rivelano maggiormente
a favore delle motivazioni che dovrebbero incentivare l'offerta di open source. Allo stesso
modo, le imprese che adottano un modello ibrido, pur raggiungendo un livello di accordo
inferiore rispetto alle precedenti, sono più favorevoli a tali motivazioni rispetto alle imprese
che fanno affidamento su un modello interamente o prevalentemente proprietario.
Ciononostante, percentuali non banali sono raggiunte anche da quest'ultimo modello di
business relativamente ai pareri favorevoli con, in alcuni casi, punte superiori al 50% dei
rispondenti. Questo dimostra comunque un elevato interesse al tema dell'open source anche
da parte di imprese che adottano un modello di business che, almeno sulla carta, dovrebbe
essere antitetico rispetto a quello open.
Guardando nel dettaglio come cambia il parere delle imprese in base al modello di business
adottato si nota che per le imprese che adottano un modello ibrido, la possibilità di sfruttare
standard aperti (pari all'85,3% del totale dei potenziali rispondenti) e il basso costo iniziale
(80 %) risultano essere i motivi principali, in linea con quanto rilevato per le imprese che
adottano un modello open. Anche la possibilità per le piccole e medie imprese di innovare, la
possibilità di sviluppo collaborativo e la condivisione dei valori dell'open source sono
Pagina 136
motivazioni che trovano d'accordo o molto d'accordo almeno 3 imprese su 4 tra quelle che
adottano un modello di business ibrido.
Se consideriamo invece le imprese caratterizzate da un modello proprietario, tra le ragioni
che potrebbero incentivare la scelta dell'open, il costo iniziale basso risulta essere il motivo
prevalente, con il 62,4% (113 imprese), seguito dalla condivisione dei valori dell’open source
(100, pari al 55,2%) e dalla possibilità di innovare per le piccole e medie imprese (96, pari al
53,0%). Mentre non stupisce che il basso costo iniziale sia il motivo principale per il quale le
imprese che hanno un modello open potrebbero essere incentivate a farlo, è abbastanza
singolare che un'impresa su due indichi la condivisione dei valori dell'open source.
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Open Source
Ibrido
Condivisione dei valori
dell'OS
Assenza di prodotti
proprietari concorrenti
Maggiore fruibilità di
specialisti ICT
Modello di testing
Politiche nazionali rivolte all'OS
Basso costo iniziale
Possibilità di modularizzare gli obiettivi
Sfruttare standard e
formati aperti
Possibilità di sviluppo
collaborativo
Maggiore indipendenza dai fornitori
Migliore interoperabilità
dei sistemi
Figura 22.
Proprietario
Possibilità per le PMI di
innovare
Maggiore
sicurezza/affidabilità
del sof tw are
Possibilità di personalizzazioni
Motivi che possono incentivare l'offerta di Open Source a seconda del modello di
business
La Figura 12 indica invece come tra i fattori che possono disincentivare l’offerta di soluzioni
open ci sono, a giudizio delle imprese del settore che del software open fanno una
componente esclusiva o prevalente del loro modello di business, le eventuali problematiche
di interoperabilità con altri prodotti software (51,2%), seguite dal timore della non continuità
nel supporto da parte della comunità open source (43,9%) e dalla percezione, da parte dei
clienti, di poter avere difficoltà di utilizzo dei prodotti e servizi open (39,0%). Dalla stessa
figura, che riporta i pareri anche delle imprese raggruppate secondo gli altri due modelli di
business, emerge come non vi siano particolari differenze nell'individuazione dei fattori che
principalmente possono ostacolare l'offerta di prodotti e/o servizi open source. Le
problematiche di interoperabilità con altri prodotti software (43, pari al 57,3%), il timore
della non continuità nel supporto da parte della comunità open source (41, pari al 54,7%) e
della percezione, da parte dei clienti, di poter avere difficoltà di utilizzo dei prodotti e servizi
open (41, pari al 54,7%) sono anche per le imprese che adottano un modello di business
Pagina 137
ibrido i tre fattori maggiormente disincentivanti dell'offerta di soluzioni open. E' interessante
notare come per le imprese che adottano un modello proprietario, oltre ai tre fattori citati, che
sono quelli di maggiore rilevanza, il motivo di disincentivo più indicato è la percezione di
una peggior assistenza post vendita da parte della clientela (95, pari al 52,5%).
60%
50%
40%
30%
20%
10%
0%
Open Source
Figura 23.
Ibrido
Licenze OS poco chiare
No continuità supporto
della comunità
La clientela può temere delle difficoltà nell'utilizzo dei
prodotti/servizi OS
La clientela può temere di avere una peggior assistenza postvendita
Proprietario
No
competenze/risorse
per l'offerta OS
Presenza applicazioni
proprietarie incompatibili con le soluzioni
of ferte
La clientela può temere una minor qualità
del softw are offerto
Motivi che possono disincentivare l'offerta di Open Source a seconda del modello di
business
3 CONCLUSIONI
Quest'anteprima dell'indagine sulle caratteristiche e la capacità innovativa delle imprese IT in
Emilia-Romagna fornisce un primo contributo importante alla quantificazione delle imprese
che a livello regionale offrono prodotti e servizi basati in tutto o in parte su software open
source.
Tale dato è stato per la prima volta stimato con un’indagine condotta su larga scala e
statisticamente robusta.
L'aspetto più interessante fin qui emerso è che le imprese che nel loro modello di business
includono il software open sembrerebbero presentare una migliore performance innovativa
(misurata come la percentuale di fatturato 2008 derivante dall'introduzione di nuovi prodotti
e/o servizi) rispetto alle imprese che offrono prodotti e/o servizi basati principalmente solo su
software proprietario.
Il rapporto dunque tra modello di business adottato e innovatività dell'impresa merita
certamente ulteriore attenzione e sarà una delle direzioni in cui si muoveranno le analisi
future.
Pagina 138
UN ECOSISTEMA SOSTENIBILE:
IL MODELLO DI JAPS 2.0
Claudio Ambu, Tzente S.r.l., Viale Elmas 142, 09122 Cagliari, c.ambu@tzente.it
Roberta Quaresima, Tzente S.r.l., Viale Elmas 142, 09122 Cagliari,
r.quaresima@tzente.it
Maria Cadeddu, Agiletec S.r.l., Viale Elmas 142, 09122 Cagliari,
m.cadeddu@agiletec.it
Abstract
Il software libero ed il modello di business ad esso collegato stanno diventando sempre più
protagonisti nel mondo delle imprese, della ricerca ed in particolare delle Pubbliche Amministrazioni,
poiché offrono rilevanti potenzialità di carattere economico, culturale e sociale.
Il software libero è ritenuto un elemento importante per affrontare e risolvere con successo i problemi
legati all'uso e alla valorizzazione dell'ICT nel mondo delle Pubbliche Amministrazioni e favorisce il
rilancio dell'industria informatica nazionale ed internazionale. Infatti in molti casi ormai il software
libero è diventato uno strumento maturo e di qualità che può garantire un adeguato valore sia nel
settore pubblico che privato.
Il progetto jAPS ed il suo modello nascono proprio sulla base di questi presupposti al fine di aiutare
Pubbliche Amministrazioni ed imprese a sviluppare prodotti finiti, progetti e soluzioni che soddisfino
di volta in volta le specifiche esigenze. jAPS 2.0 è una piattaforma portal professionale progettata per
rendere fruibili a tutti informazioni, risorse, servizi e processi di un'organizzazione, sia essa pubblica
o privata.
Nell'articolo saranno illustrate le principali caratteristiche della piattaforma jAPS, tra le quali il
rispetto dei requisiti della legge italiana sull'accessibilità, la Legge Stanca, al quale è legata anche la
mission di jAPS: “vogliamo rendere informazioni e servizi accessibili a tutti”.
Sarà inoltre descritta la storia che ha portato alla nascita di Tzente, il Maintainer ufficiale, e
dell'ecosistema jAPS basato su un modello di business completamente Open Source.
Tzente (che in sardo significa “persone”) nasce infatti in Sardegna con l'obiettivo di creare un
ecosistema di respiro nazionale e internazionale di aziende, pubbliche amministrazioni, università e
centri di ricerca che condividano le loro conoscenze, collaborino e contribuiscano alla crescita del
progetto Open Source jAPS.
Tzente ha come obiettivo quello di far evolvere la piattaforma e creare una rete strutturata come un
“ecosistema” di Partner che condividano valori e obiettivi comuni. Verrà descritto in dettaglio il
modello di business basato sull'offerta delle tecnologie e dei servizi connessi ai Partner sotto forma di
accordi di partnership con sottoscrizione di servizi.
Saranno infine illustrati i principali obiettivi raggiunti e la roadmap del progetto e del modello,
tramite cui si cercherà di evidenziare il ruolo fondamentale dei diversi attori dell'ecosistema per la
crescita stessa del progetto.
Parole Chiave: Software Libero, Portali, Accessibilità, Ecosistema, Modello, jAPS, Pubblica
Amministrazione
Pagina 139
1 INTRODUZIONE
Tzente, il maintainer ufficiale del progetto jAPS (www.japsportal.org), è un società che nasce
sulla convinzione che il software libero e l’utilizzo di modelli di licenze open offrano oggi un
sicuro vantaggio competitivo rispetto alle aziende che sviluppano software proprietario e che
operano sul mercato sulla base di modelli commerciali consolidati. Tzente basa questa
convinzione su un assunto: persone e qualità devono essere i due ingredienti fondamentali per
un progetto open source di successo ed è per questo motivo che il progetto jAPS, che ha fatto
di queste due fattori elementi principe della sua filosofia, continua il suo percorso di crescita
ininterrotta da oramai 6 anni.
1.1
La storia
jAPS è un progetto nato nel 2004 ed è fondato su una semplice idea: realizzare una
piattaforma in grado di conciliare le caratteristiche di framework professionale con
leggerezza e semplicità d'uso e di personalizzazione di un prodotto, in alternativa alle
soluzioni dei grandi attori mondiali.
Il successo dell’iniziativa porta alla naturale costituzione di AgileTec, che prosegue
l'evoluzione del progetto sino al 2009, anno della costituzione di Tzente.
AgileTec, proponendo una piattaforma di sviluppo, si è trovata ad operare non solo
direttamente sui propri clienti, ma anche su un mercato più ampio attraverso il supporto
tecnologico fornito ad aziende nazionali. L'operare in supporto ad altre aziende tecnologiche
ha costituito un'esperienza importante sia per l'esigenza di rispondere con prontezza a sfide
tecnologiche evolute, sia per l'acquisizione di una buona capacità di collaborazione e di
servizio, sia in termini di cultura aziendale che di processi.
Lo stretto contatto con queste realtà e la conoscenza quindi delle loro esigenze ha portato alla
creazione del nuovo maintainer ufficiale del progetto jAPS, Tzente. Il suo obiettivo è quello
di far evolvere la piattaforma e creare una rete di organizzazioni strutturata come un
“ecosistema” di Partner che condividono valori e obiettivi. Il modello di business di Tzente
matura a seguito delle richieste del mercato e dei clienti finali.
1.2
Mission
Il progetto jAPS 2.0 nasce dall'esigenza del web 2.0 di creare soluzioni innovative per la
fruibilità di servizi ed informazioni e per incentivare la collaborazione tra gli utenti. jAPS 2.0
è la risposta al nuovo modo di intendere il web come piattaforma in cui l'utente ha il controllo
dei propri dati ed è in grado di accedere in maniera semplice alle informazioni di
un'organizzazione in base al proprio profilo.
L'enfasi data alla condivisione delle informazioni e alla collaborazione rappresenta un
vantaggio in termini di arricchimento della conoscenza, ma può anche rappresentare un
rilevante ostacolo per tutti gli utenti diversamente abili che devono poter accedere e fruire
delle informazioni e dei servizi offerti. Pensiamo alla possibilità per persone con disabilità
uditive, cognitive e motorie di poter gestire le proprie informazioni. Immaginiamo ad
esempio alle difficoltà che le persone anziane possono avere nell'accedere ai servizi on-line.
Il web 2.0 rischia quindi di aumentare il "digital divide".
Pagina 140
La risposta del progetto jAPS 2.0 si può riassumere in una semplice frase: “Rendere le
informazioni e i servizi accessibili a tutti!”
Questa caratteristica ha coinciso con l'esigenza di rispettare le normative italiane
sull'accessibilità dei siti delle pubbliche amministrazioni (legge Stanca e provvedimenti
collegati). Tali norme, che riprendono le linee guida del W3C (WCAG), hanno equivalenti
anche nella normativa degli Stati Uniti (Disablities Act - Section 508) e del Regno Unito
(Disability Discrimination Act 1995).
La caratteristica di "consentire" il rispetto dell'accessibilità nella realizzazione dei portali web
è stata talmente importante per il successo di jAPS che nella seconda versione (jAPS 2.0) si è
deciso di estendere il rispetto della normativa anche sul back-office (funzioni di gestione e
aggiornamento), in modo da consentire l'accesso agli strumenti di redazione e gestione dei siti
anche da parte di personale con disabilità. Attualmente la piattaforma jAPS 2.0 consente
anche a persone diversamente abili di poter scrivere e pubblicare informazioni e quindi
partecipare attivamente alla redazione dei contenuti di un portale (CMS). Tutti i servizi di
collaboration (plugin webmail, newsletter, forum, bacheca annunci etc) sono accessibili
anche in area di amministrazione e quindi utilizzabili da persona con disabilità. Ad oggi ci
risulta che jAPS 2.0 sia l'unica piattaforma al mondo, fra quelle open source, con questa
caratteristica (e comunque non abbiamo notizia di tale caratteristica neppure fra le soluzioni
proprietarie).
2 LA PIATTAFORMA JAPS 2.0
jAPS 2.0 è costruito sulla qualità (qualità delle persone, qualità dei processi, qualità dei
risultati), espressione diretta di un processo di miglioramento continuo innescato grazie alla
possibilità di raccogliere bisogni ed esigenze reali, in particolare nel mercato della pubblica
amministrazione italiana. Qualità ottenuta grazie al contributo di una community attenta e
partecipe costituita da sviluppatori, esperti in accessibilità, ingegneri e architetti del software,
grafici, professionisti della comunicazione, avvocati ed esperti sulla proprietà intellettuale,
aziende, esperti di e-government, Università e Centri di ricerca.
2.1
Cosa è jAPS
jAPS 2.0 è uno strumento professionale, semplice e versatile, progettato per rendere fruibili a
tutti informazioni, risorse, servizi e processi di un'organizzazione, sia essa pubblica o privata.
In ambito PA, jAPS 2.0 è uno strumento innovativo di relazione, trasparenza, comunicazione
e informazione che favorisce un rapporto aperto tra PA e cittadini.
jAPS 2.0 nasce in Italia in aderenza con le normative vigenti e si propone come uno
strumento adatto per una Pubblica Amministrazione che intenda avviare un processo di
miglioramento della qualità dei servizi e delle informazioni online al cittadino e alle imprese.
jAPS 2.0 è un strumento adatto anche per favorire la condivisione di informazioni tra i
dipendenti pubblici di un'ente e per facilitare il dialogo tra gli stessi enti. L'aspetto più
rilevante, che costituisce un elemento di unicità, è che lo strumento favorisce l'abbattimento
delle barriere digitali sul web: un utente diversamente abile (ad esempio un non vedente) è in
grado di gestire le proprie informazioni, condividerle, partecipare e collaborare (e-inclusion).
Pagina 141
jAPS 2.0 va oltre il classico concetto di sistema portal perché copre uno spettro di esigenze
molto ampio, consentendo di affiancare la completa e semplice gestione dei contenuti alla
capacità di integrare servizi applicativi. I sistemi CMS classici e i pesanti sistemi Portal
coprono solo uno di questi aspetti: un CMS consente di organizzare e pubblicare contenuti
(siti informativi), un sistema portal consente l'aggregazione di servizi applicativi (portali di
servizi). jAPS invece copre molto bene entrambi gli aspetti. In più consente di creare
applicazioni verticali partendo da una base tecnologica solida di componenti software e di
framework collaudati e ben noti.
Le sue caratteristiche peculiari si possono riassumere in quattro parole chiave "Enterprise
Accessible Information Platform":
1 racchiude in un'unica soluzione tutte le caratteristiche "Enterprise" di performance, affidabilità, scalabilità e robustezza dei sistemi Portal più evoluti;
2 consente anche ad utenti diversamente abili di accedere, condividere, pubblicare e gestire le proprie informazioni e servizi ("Accessible");
3 è orientato anche alla gestione dei contenuti tramite uno strumento evoluto di Content Management ("Information");
4 è utilizzabile come framework ("Platform") per la realizzazione di applicazioni verticali basate sui contenuti (Content Enabled Vertical Application).
Le Metodologie Agili utilizzate per la progettazione, realizzazione e gestione della
piattaforma jAPS 2.0, da cui l'acronimo di Java Agile Portal System, sono conformi alle
metodiche indicate dal DigitPA come standard di realizzazione di un portale per la PA e per
la gestione del suo ciclo di vita.
2.2
Cosa posso fare con jAPS 2.0
I componenti e le funzionalità di base coprono la grande maggioranza delle funzionalità di un
portale web e consentono di personalizzare e realizzare un prodotto finito tagliato sulle
necessità del cliente, senza pretendere di risolvere tutte le esigenze possibili a priori. Per
questo la piattaforma è stata progettata tenendo sempre presente l'estendibilità.
La versatilità di jAPS consente di poterlo utilizzare in diversi scenari:
•
semplici siti informativi con la gestione dei contenuti da parte di una redazione ( Content Management System)
•
Portali di grosse dimensioni con Servizi al cittadino, servizi SPCoop (con l'integrazione di porte di dominio)
•
Intranet accessibile, cruscotto o desktop personalizzato per il dipendente (myPortal), creare nuovi plugin applicativi, integrare servizi applicativi e i sistemi di back office (anche tramite utilizzo di Enterprise Service Bus)
•
semplici applicazioni web based su domini specifici (Content Enabled Vertical Application)
jAPS 2.0 è stato progettato per consentire un suo utilizzo come elemento centrale di un
sistema integrato di servizi web. jAPS 2.0 risolve con efficienza i temi della aggregazione
delle informazioni e dei servizi su un front-end unico. Il back office, facilmente estendibile,
Pagina 142
consente di integrare anche le funzionalità applicative di appoggio ai servizi di front-end. La
modularità del sottosistema dei servizi consente di agganciare, con facilità, e secondo un
disegno coerente, i connettori ai servizi esterni da integrare. I moduli già esistenti forniscono
molti dei servizi di infrastruttura necessari nella pratica. In pratica jAPS 2.0 può ricoprire il
ruolo di cruscotto in cui informazioni, servizi e risorse di un organizzazione vengono rese
fruibili in maniera sicura e personalizzata (desktop personalizzato).
2.3
La tecnologia
jAPS 2.0 è basato su piattaforma Java EE. La piattaforma fa uso di framework ampiamente
diffusi, ben noti e riconosciuti dal mercato come Struts e Spring e aggiunge a questi nuovi
componenti software un insieme minimo di funzionalità che accelerano e semplificano il
lavoro di realizzazione di un sistema web su misura.
L'architettura modulare basata sul paradigma Model View Controller, l'utilizzo di design
pattern, l'approccio orientato ai servizi (SOA) e il modello di integrazione a Plugin rendono il
sistema fortemente versatile, flessibile e adatto quindi a scenari in cui la personalizzazione è
un'esigenza molto sentita.
Tutti i dati e contenuti di jAPS vengono immagazzinati con un formato libero e liberamente
leggibile: XML. In questo modo tutti i contenuti possono essere riutilizzati e integrati senza
alcuna limitazione. Questa caratteristica fa di jAPS 2.0 un Open Data framework adatto in
tutti quei contesti in cui si intende favorire la condivisione libera delle informazioni e la
trasparenza.
3 L'ECOSISTEMA JAPS 2.0
L'esigenza di soddisfare una richiesta sempre in aumento di soluzioni basate su jAPS 2.0 ha
dato origine alla realizzazione di un ecosistema di Partners certificati supportati da Tzente.
3.1
Modello di business
Il modello di business di Tzente è il risultato dell’osservazione e dello studio dei
comportamenti dei grandi vendor internazionali, mantainer di progetti Open Source. Il
modello si basa sull’offrire e fornire le tecnologie ed i servizi sotto forma di accordi di
partnership, con sottoscrizione di servizi su base annuale o pluriennale. Le partnership sono
progettate per fornire alle organizzazioni dell'ecosistema una soluzione all-inclusive che
comprende la consegna del software, correzioni in corso, miglioramenti e nuove versioni
della piattaforma sempre più stabili e sicure, nonchè una vasta gamma di servizi di supporto e
assistenza sia in ambito marketing che vendite. Il Partner non compra il software ma i servizi
legati ad una soluzione che considera di elevata qualità e quindi in grado di garantirgli
business presso i propri clienti.
Il software sviluppato collettivamente (Community Edition) viene oggi distribuito sotto
licenza open source (GNU General Public License) e consente, a tutti gli interessati, l'accesso
al codice sorgente e la facoltà di poter utilizzare, modificare e distribuire jAPS 2.0. Questa
modalità di diffusione offre un ampio margine di manovra per i partner (aziende pubbliche e
private di medie-grandi dimensioni) i quali sono legittimati a prendere visione della soluzione
open source, suggerire modifiche, personalizzare o migliorare il software. In tale contesto si
Pagina 143
inserisce la Maintainer Tzente che offre servizi professionali mirati ad elevare il grado di
affidabilità della piattaforma, offrendo una serie di funzionalità e soluzioni migliorative
rispetto alla soluzione a disposizione della community.
Tzente opera con un network di aziende Partner che promuovono e diffondono la piattaforma
jAPS 2.0 nel mercato nazionale ed internazionale. Il ruolo di Tzente all'interno del network è
quello di supporto di secondo livello: fornisce ai partner una piattaforma software Open
Source certificata e supportata (jAPS 2.0 Certified Edition), insieme a tutti i servizi di
consulenza e supporto in ambito di progettazione, sviluppo, marketing, business development
e vendite presso i loro clienti.
Il business si concretizza quindi attraverso 4 canali:
 sottoscrizione di partnership da parte delle organizzazioni che intendono offrire ai loro clienti le soluzioni basate su jAPS 2.0;
 fornitura di servizi aggiuntivi di consulting;
 fornitura di servizi aggiuntivi di training;
 utilizzo della Platform certified edition (versione certificata della piattaforma) per tutti i clienti dei partner.
Il modello di business prevede differenti tipologie di partnership, in base alla specificità
dell'organizzazione e dei prodotti e/o servizi da questa forniti ai propri clienti. Ogni partner
con la sottoscrizione dell’accordo di partnership acquisisce una serie di benefici (3 profili di
benefits SILVER, GOLD , PLATINUM) e obblighi (requirements).
I benefits consentono ai Partner di acquisire una forte capacità di penetrazione del mercato
grazie alla elevata qualità della soluzione jAPS 2.0 proposta ai loro clienti finali e al supporto
diretto del Maintainer; i requirements consentono al Maintainer di finanziare lo sviluppo della
piattaforma e attuare politiche di branding a favore della rete di Partner. Il Maintainer non
opera direttamente sul mercato ma indirettamente tramite i Partner.
Le tipologie di partnership sono:
 System Integrator: organizzazioni che forniscono servizi professionali su jAPS 2.0 Platform
 Solution & OEMs: organizzazioni che sviluppano verticalizzazioni e nuovi prodotti su specifici domini basati su jAPS 2.0 Platform  Technology: maintainer di altri progetti open source che forniscono soluzioni tecnologiche che possono essere offerte insieme a jAPS 2.0 Platform.
 R&D: Centri di Ricerca e Università che contribuiscono al progetto Open Source e, nell'ambito dei propri progetti di ricerca, sviluppano applicazioni innovative basate su jAPS 2.0 Platform
Tzente offre per queste organizzazioni supporto specifico e personalizzato.
L’accesso all’ecosistema dei Partner è selezionato così da garantire e preservare la qualità del
lavoro di tutti i suoi partecipanti. Accedere all’ecosistema significa seguire e condividere i
principi e valori del modello Open Source favorendo il giusto equilibrio tra lo spirito della
community e le esigenze relative alla crescita del proprio business.
Pagina 144
Figura 24.
3.2
Ecosistema dei partner
Principi e valori dell'ecosistema
Il mondo jAPS e l’ecosistema dei partner su cui è costruito sono concepiti come un sistema
integrato dove vigono alcuni semplici principi e valori posti originariamente a garanzia
dell’equilibrio del sistema.
Il ruolo di Tzente, all'interno dell'ecosistema, è quello di far evolvere la piattaforma, garantire
uno standard di qualità elevato del prodotto e dei servizi e fornire supporto professionale sulla
piattaforma a tutte le organizzazioni che intendano essere competitive nel mercato odierno
con una soluzione innovativa.
I principi originari dell'ecosistema sono i seguenti:
 Non concorrenza del Maintainer: il Maintainer non interviene direttamente ed in alcun modo presso un cliente sul quale un soggetto partner dichiari di aver intrapreso una trattativa avente ad oggetto un pacchetto di prodotti e servizi basati su jAPS 2.0;
 Confidenzialità e Trasparenza: il Maintainer garantisce assoluta riservatezza ad un partner nei confronti degli altri partner, nel caso venga a conoscenza indirettamente e nell’ambito di una trattativa commerciale su l'esistenza, i dettagli tecnici e/o commerciali di un progetto specifico.
 Uguaglianza: il Maintainer non garantisce l'esclusività ad alcun Partner. In un'ottica di neutralità opera per fornire sostegno a tutti i Partner, nell'ambito di un progetto che incorpora l'offerta del Maintainer. Il comportamento del Maintainer si ispira sempre a Pagina 145
principi di neutralità, correttezza, lealtà e trasparenza nei confronti di tutti i Partner del network. 3.3
Accordi strategici
Tzente sta attuando un processo di internazionalizzazione attraverso il potenziamento della
rete di Partner in settori strategici per la crescita del progetto.
Tra i principali troviamo l'accordo di partnership tecnologica con PENTAHO il Maintainer
della suite di Business Intelligence (BI) Open Source attualmente più popolare del mondo. La
partnership è estesa alle aree di Europa, Nord America, Sud America, Asia, Africa e Australia
ed è volta a fornire soluzioni competitive per la Pubblica Amministrazione Italiana.
Un'altro accordo di Partnership tecnologica è stato siglato con INGRES, leader mondiale di
“open source information management services” .
4 CONCLUSIONI
Il progetto jAPS ha oggi raggiunto importanti risultati grazie soprattutto ai principi e ai valori
che legano i diversi attori dell'ecosistema i quali, grazie a specifici contributi, alimentano la
crescita e l'evoluzione della piattaforma e del modello.
Il progetto è infatti caratterizzato da un laboratorio R&D al quale partecipano aziende,
università, pubbliche amministrazioni e professionisti. Le idee, l'esperienza e le competenze
di tutti vengono messe a fattore comune per definire la roadmap e realizzare progetti e
soluzioni innovative in diversi settori, quali ad esempio:
1. Integrazione, interoperabilità e cooperazione applicativa
2. Soluzioni di applicazioni su dispositivi mobili
3. Strumenti di sviluppo RAD che consentano di aumentare la produttività dei team di sviluppo
4. Ambiente automatizzato di sviluppo che faciliti la realizzazione di progetti mediante l'utilizzo di tools open source.
L'obiettivo della roadmap è quello di aumentare la diffusione del progetto open source.
Diffusione realizzata anche attraverso la costante crescita della community che accoglie un
sempre maggior numero di iscritti.
Nel Marzo 2010 è stata rilasciata la versione 2.0.10 di jAPS 2.0 contenente un upgrade della
piattaforma e nuove funzionalità. A seguito del nuovo rilascio, nel solo mese di Marzo, si
sono avuti più di 1.200 download dei diversi package.
Riferimenti
http://www.japsportal.org/ Sito di riferimento del progetto
http://dev.japsportal.org/trac/wiki Sito di riferimento per gli sviluppatori
Pagina 146
http://sourceforge.net/projects/japs/files/ Sito per il download del codice sorgente di jAPS
http://www.tzente.it/ Sito di riferimento di Tzente S.r.l.
http://www.cnipa.gov.it/site/it-it/Attivit%C3%A0/Sistema_Pubblico_di_Connettivit
%C3%A0_%28SPC%29/Contrattoquadro_per_siti_web_e_servizi_on_line_nella_PA/Scenari_Innovativi_ICT/
Linee Guida di progettazione e sviluppo per i siti delle pubbliche amministrazioni
http://www.pubbliaccesso.gov.it/normative/legge_20040109_n4.htm Sito di riferimento della
Legge Stanca
http://www.section508.gov/ Sito di riferimento della normativa sull'accessibilità degli Stati
Uniti, sezione 508 del Rehabilitation Act, estensione dell'Americans with Disabilities Act
(ADA)
http://www.opsi.gov.uk/acts/acts1995/ukpga_19950050_en_1 Sito di riferimento della
normativa sull'accessibilità del Regno Unito, Disability Discrimination Act 1995
Questo documento è rilasciato sotto la licenza Creative Commons Attribuzione–
NonCommerciale–Condividi allo stesso modo 3.0
Per leggere una copia della licenza visita il sito web http://creativecommons.org/licenses/bync-sa/3.0/legalcode
Pagina 147
SVILUPPARE APPLICAZIONI WEB CON IL
FRAMEWORK PHP SYMFONY
Luca Saba, HAL Software, Cagliari, IT, lucasaba@gmail.com
Abstract
Lo sviluppo di applicazioni web offre diversi vantaggi rispetto allo sviluppo delle classiche
applicazioni stand-alone. Tra i maggiori vantaggi ci sono quello di non dover distribuire
aggiornamenti su tutte le macchine che utilizzano l'applicazione, l'indipendenza della piattaforma
utilizzata e la facilità di integrazione con altre applicazioni web (Twitter, Facebook, YouTube, solo
per citare le più famose).
Utilizzare un framework per lo sviluppo di applicazioni web porta ulteriori vantaggi. Se nella maggior
parte dei casi, questi vantaggi sono legati al risparmio di tempo e alla possibilità di non reinventare la
ruota ogni volta che si crea una nuova funzionalità, nel caso di Symfony si aggiungono altri diversi
importantissimi aspetti tra cui
•
la qualità della documentazione
•
un'organizzazione del codice che favorisce ottime pratiche di programmazione
•
facile estensibilità tramite plugin
•
e ancora molto altro.
In sintonia con la filosofia di Symfony dell'imparare facendo, utilizzeremo come spunto una banale
applicazione, un piccolo blog dove gli autori possono pubblicare i loro articoli e gli utenti possono
commentarli, per vedere come l'utilizzo di Symfony ci permetta di scrivere, in poco tempo, del codice
elegante, leggibile, ben organizzato, sicuro e testabile.
Per l'accesso alla base dati, Symfony permette di scegliere tra due principali O.R.M. (ObjectRelactional Mapping): Propel e Doctrine. Questi si occupano di automatizzare l'accesso alla base
dati, trasformando i record del DB in oggetti corredati dai relativi getter e setter per l'accesso ai
singoli campi. L'ORM permette anche di tener conto delle relazioni tra le tabelle della base dati,
facilitando così l'accesso ai dati collegati (ad esempio, per recuperare tutti i post di un determinato
autore). Inoltre, sia Propel che Doctrine, permettono di accedere in modo trasparente ai più comuni
gestionali di basi dati, così che lo sviluppatore non si debba minimamente occupare di questi aspetti.
Dall'interazione tra Symfony e l'ORM, vedremo come sia facile generare, all'interno dei nostri
progetti, degli scheletri di moduli che gestiscano il CRUD degli oggetti (ossia la generazione
automatica di pagine per i tipici accessi Create, Read, Update e Delete).
Molti dei moduli interni di Symfony sono dei mini-framework utilizzabili in modo indipendente dal
resto dell'ambiente (come già succede in Zend). Tra questi vi è il framework dedicato alla gestione dei
form e dei filtri. Perchè scrivere la validazione dei campi quando la maggior parte delle informazioni
sono già scritte nella definizione della base dati ? Ecco che il form framework di symfony ci permette
di non preoccuparci di questi aspetti. Abbiamo bisogno di controlli più raffinati sui dati ? Nessun
problema: basterà estendere gli oggetti a nostra disposizione nell'ambiente.
Il framework Symfony è estensibile tramite plugin. Esistono moltissimi plugin per Symfony che si
occupano dei compiti più disparati. Vedremo come l'installazione e l'utilizzo di questi plugin sia
semplice e ci dia immediato accesso a diverse funzionalità.
Pagina 148
Per concludere, daremo uno sguardo all'ambiente di test di Symfony. La gestione dei test è stato uno
degli aspetti più centrali nello sviluppo di Symfony ma anche, troppo spesso, uno degli elementi meno
seguiti da chi programma. Con gli strumenti messi a disposizione da Symfony, diventa facile diventare
test-dipendenti. La semplicità con la quale è possibile definire l'interazione dell'utente con
l'applicazione, consente di scrivere dei test estremamente complessi ed esaustivi. Così che, quando
avvengono delle modifiche nel nostro codice, l'avvio dei test ci da una documentata informazione
sull'affidabilità del codice, facendo sì che il nostro "svn update" non sia più un'azione temeraria.
Parole Chiave: PHP, Symfony, MVC, test driven, best practice, CRUD, ORM, framework
1 PERCHÈ SVILUPPARE APPLICAZIONI WEB
Lo sviluppo di applicazioni web presenta diversi vantaggi sia per lo sviluppatore che per
l'utilizzatore finale. Uno dei vantaggi maggiori deriva dal fatto che esiste un unico posto sul
quale fare gli aggiornamenti. Nella migliore delle ipotesi, ciò può avvenire con un semplice
comando: svn update.
Le segnalazioni di difetti da parte degli utenti possono essere risolte in poco tempo senza
richiedere l'accesso ad ogni singola macchina sulla quale è installata l'applicazione.
Le applicazioni web ci consentono di eliminare (quasi del tutto) i limiti imposti dalla
particolare macchina e/o sistema operativo. Sviluppare un'applicazione che possa essere
eseguita su di un PC, un Power Book, un iPhone, un cellualre Nexus One o un iPad (ma
anche su un futuro gPad) è abbastanza semplice (avendo a disposizione un buon grafico!). Il
tutto senza rinunciare all'elasticità dell'interazione con l'utente grazie a Javascript e alle
tecnologie asincrone (AJAX).
2 PERCHÈ USARE UN FRAMEWORK
L'insieme di operazioni che accomunano la maggior parte delle applicazioni web (e anche
delle applicazioni stand-alone) formano una della parti più noiose del processo della
programmazione. Reinventare la ruota ogni volta che si sente il bisogno di scrivere
operazioni routinarie come l'accesso alla base dati o la gestione di una sessione autenticata,
non solo è un processo noioso ma anche inutilmente ripetitivo. Inoltre, avere del codice
pesantemente testato grazie al suo utilizzo da parte di diverse persone nei contesti più
disparati, dà un certo livello di affidabilità che il proprio (isolato) codice difficilmente
potrebbe dare.
Per questi motivi ricorrere ad un framework risulta una scelta molto vantaggiosa (se non
obbligata).
Pagina 149
3 PERCHÈ USARE SYMFONY
Quando inizialmente ho deciso di usare un framework (correva l'anno 2007) per lo sviluppo
di applicazioni web basato su PHP la scelta è caduta quasi subito su Symfony per un motivo
forse poco tecnico ma per me fondamentale: la qualità della documentazione.
Avere una documentazione adeguata permette di poter sfruttare al massimo i potenti
strumenti messi a disposizione dal framework. In più, l'introduzione a Symfony è, fin dalle
prime versioni, un corso di 24 lezioni che guidano il lettore nella realizzazione di
un'applicazione vera e propria: niente di meglio che mettere le mani in pasta per invogliare
all'apprendimento.
Per vedere gli aspetti salienti di questo framework, sulla falsa riga della sua documentazione,
illustriamo una banale applicazione per la gestione di un piccolo Blog.
Cominciamo a definire una prima iterazione nello sviluppo di questa applicazione:
 un autore può inserire uno o più articoli  gli utenti possono vedere una lista di articoli inseriti dai diversi autori  gli utenti possono aggiungere commenti agli articoli La base dati per questa applicazione è definita da tre tabelle: autore, articolo e commento.
3.1
l'ORM e la connessione alla base dati
Una volta definita lo schema del database, l'ORM si occupa di generare le classi necessarie
per l'acceso alla base dati. L'ORM (Object-Relational Mapping) è uno strumento che mappa
le tabelle della base dati con la definizione di oggetti PHP. In pratica, data la nostra tabella
autore, l'ORM genererà un oggetto Autore con tutti i metodi necessari per modificare i suoi
attributi (del tipo, getNome() e setNome() ), per salvare nuovi oggetti nella base dati
Pagina 150
($autore->save() ), per recuperare dalla base dati singoli oggetti (AutorePeer::doSelectOne() )
o collezioni di esso e anche per recuperare collezioni di oggetti relazionati (ad esempio per
recuperare tutti gli oggetti Articolo collegati ad un determinato autore: $autore>getArticolos() ). Un ulteriore vantaggio dell'ORM è che rende l'applicazione
(potenzialmente) indipendente sistemi di gestione della base dati.
È facile personalizzare le classi generate dall'ORM in modo da modificare la logica di
funzionamento degli oggetti o da aumentarne la funzionalità. Ad esempio, definiamo un
metodo per far si che l'oggetto autore abbia una rappresentazione come valore stringa:
class Autore extends BaseAutore
{
public function __toString()
{
return $this->getNome().' '.$this->getCognome();
}
}
3.2
Il Model View Controller
Veniamo ad analizzare gli aspetti relativi alla View e al Control. Un'applicazione Symfony
contiene diversi moduli. I moduli sono un raggruppamento logico di operazioni. Possiamo
immaginare la gestione degli articoli come un modulo. In relazione alle specifiche del nostro
programma, questo modulo dovrebbe fare tre cose: inserire articoli, vedere la lista degli
articoli, permettere di commentare un articolo. Il modulo, che chiameremo articoli, contiene
un file dove vengono definite le azioni (il Controller) e una serie di file dedicate alla
visualizzazione (la View).
Vediamo come definire la logica sottesa alla visualizzazione degli articoli:
class articoliActions extends sfActions
{
public function executeLista(sfWebRequest $request)
{
$this->articoli = ArticoloPeer::doSelectJoinAll(new
Criteria());
}
}
Niente di più semplice! Vediamo ora un esempio della View:
<div id="articoli">
<?php foreach($articoli as $num => $articolo): ?>
<div class="articolo">
<div class="autore">
Pagina 151
Scritto da <?php echo $articolo->getAutore() ?> il
<?php echo $articolo->getCreatedAt('d/m/Y') ?>
</div>
<div class="titolo"><?php echo $articolo->getTitolo() ?
></div>
<div class="testo"><?php echo $articolo->getTesto() ?
></div>
<div class="commenti">
<?php foreach($articolo->getCommentos() as $commento): ?>
<div class="commento">
<span class="data">Il
<?php echo $commento->getCreatedAt('d/m/Y') ?>
</span>
<span class="nick">
<?php echo $commento->getNickUtente() ?>
</span>
<span class="commento">
<?php echo $commento->getTesto() ?>
</span>
</div>
<?php endforeach; ?>
</div>
<div class="azione">
<?php echo link_to(
image_tag('gtk-edit.png', array('alt' => 'Comment')),
'articoli/commenta?articolo_id='.$articolo->getId());
?>
</div>
</div>
<?php endforeach; ?>
</div>
Fin qui abbiamo visto come l'ORM lavori per noi. Abbiamo anche visto la netta separazione
tra gli aspetti dell'applicazione. Vediamo un fantastico sotto-framework di Symfony: la
gestione dei form e dei filtri.
3.3
I sub-framework: form e filtri
Una delle tediose attività della programmazione delle applicazioni web è la gestione
dell'input da parte dell'utente. In Symfony questo lavoro è estremamente semplice. Possiamo
chiedere a Symfony di generare dei form relativi alle nostre tabelle. Questi oggetti form non
solo inglobano tutti i campi della tabella, ma sono già corredati delle regole di validazione
necessarie per il tipo di dato del singolo campo. Per vedere in funzione il form, aggiungiamo
due nuove azioni nel nostro controller:
//Aggiunto nella classe articoliActions
public function executeNuovo(sfWebRequest $request)
Pagina 152
{
}
$this->form = new ArticoloForm();
public function executeSalva(sfWebRequest $request)
{
$articolo = new Articolo($request>getParameter('articolo_id'));
$this->form = new ArticoloForm($articolo);
$this->form->bind($request->getParameter($this->form>getName()));
if($this->form->isValid())
{
$this->form->save();
$this->forward('articoli', 'lista');
}
else $this->setTemplate('nuovo');
}
Ed ecco come sarà scritta la nostra view:
<?php echo form_tag('articoli/salva') ?>
<table>
<?php echo $form ?>
</table>
<input type="submit" value="Salva" />
E come apparirà:
Vogliamo però che la data di creazione non sia impostata dall'utente ma automaticamente
impostata dal sistema. Per eliminarla dal form basta:
Pagina 153
class ArticoloForm extends BaseArticoloForm
{
public function configure()
{
unset($this['created_at']);
}
}
Ogni aspetto dell'oggetto form è personalizzabile. Il form utilizza diversi widget per la
rappresentazione dei dati. I widget sono automaticamente definiti in base al tipo di dato da
rappresentare (il tutto senza una riga di codice). Nel caso precedente, ad esempio, l'autore è
rappresentato da una select per via del collegamento della tabella articolo con la tabella
autore. Il framework dei form utilizza anche dei validatori che vengono lanciati sui dati
inseriti dall'utente. I validatori entrano in campo alla chiamata della funzione isValid().
Questa funzione controlla la coerenza dei valori inseriti con quelli della tabella della base
dati. Perciò, ad esempio, un campo intero, non potrà mai contenere caratteri dell'alfabeto. In
caso di presenza di errori, il framework ripresenterà il form con i relativi errori eventuali.
Ecco un esempio:
Vediamo come sia facile creare le pagine per il commento agli articoli. Aggiungiamo
l'azione:
public function executeCommenta(sfWebRequest $request)
{
$articolo = ArticoloPeer::retrieveByPk(
$request->getParameter('articolo_id')
);
$commento = new Commento();
$commento->setArticolo($articolo);
$this->form = new CommentoForm($commento);
if($request->isMethod('POST'))
{
$this->form->bind($request->getParameter($this->form>getName()));
Pagina 154
if($this->form->isValid())
{
$commento = $this->form->save();
$this->forward('articoli', 'lista');
}
}
}
La view per questa azione è banale come quella dell'articolo:
<?php echo form_tag('articoli/commenta') ?>
<table>
<?php echo $form ?>
</table>
<input type="submit" value="Salva" />
Il framework si occupa di tutto il resto.
3.4
I plugins
Il framework Symfony è estensibile tramite plugins. Esistono tantissimi plugin a disposizione
che permettono di aggiungere funzionalità al framework in modo semplice e veloce.
Vediamo un banale esempio. Vogliamo creare una funzione asincrona per dare il nostro
gradimento ad un articolo. Per prima cosa aggiungiamo un campo voto nella tabella articolo:
Non vogliamo dare all'autore la libertà di darsi un voto, perciò facciamo sparire il campo dal
form:
class ArticoloForm extends BaseArticoloForm
{
Pagina 155
}
public function configure()
{
unset($this['created_at'], $this['voto']);
}
Impostando il campo a "not null" con "default 0", il salvataggio del form inizializzerà il
valore per noi.
3.4.1
AJAX made easy - sfJqueryReloadedPlugin
A questo punto definiamo le funzioni del nostro Model per l'aumento del voto:
class Articolo extends BaseArticolo
{
public function votoSu()
{
$this->setVoto($this->getVoto() + 1);
$this->save();
}
}
Ecco la vista dell'articolo:
<?php use_helper('jQuery') ?>
..........
<div class="articolo">
<div class="voto">
<div id="voto_articolo_id_<?php echo $articolo->getId() ?>">
<?php echo $articolo->getVoto() ?>
</div>
</div>
<div class="titolo_articolo">
<?php echo $articolo->getTitolo() ?>
</div>
<div class="testo_articolo">
<?php echo $articolo->getTesto() ?>
</div>
........
<span class="valutazione">
<?php
echo jq_link_to_remote(
image_tag('vota.png', array('alt' => 'Vota')),
array(
'update' => 'voto_articolo_id_'.$articolo->getId(),,
'url'
=> 'articoli/vota?articolo_id='.$articolo-
Pagina 156
>getId()
)); ?>
</span>
</div>
jq_link_to remote non fa parte del framework Symfony. È però possibile scaricare il plugin
(sfJqueryReloadedPlugin) che ci permette di utilizzare questa funzione. L'inclusioni nella
pagina web finale del codice javascript necessario è gestita dal plugin stesso. A noi non
rimane che sapere come utilizzarlo. In questo caso, la funzione utilizzata non farà altro che
aggiornare l'elemento della pagina con id voto con il contenuto dell'azione vota del modulo
articoli.
Definiamo l'azione:
public function executeVota(sfWebRequest $request)
{
);
$this->forward404Unless(
$articolo, "L'articolo da votare non esiste"
);
$articolo->votoSu();
$this->articolo = $articolo;
}
e il contenuto da mostrare nel nostro div (nella view votaSuccess):
<?php echo $articolo->getVoto() ?>
Fatto! Una perfetta funzione AJAX senza usare una singola riga di javascript.
3.4.2
Il TCPDF di Nicola Asuni in un pluguin: sfTCPDFPlugin
Una funzione molto utile di alcuni blog è data dalla possibilità di scaricare gli articoli in
formato PDF. Nota personale: non avendolo ancora ringraziato di persona ho pensato di
citare qui Nicola per il suo impagabile contributo al mondo Open e al mio lavoro!
Per fare questo scarichiamo sia il plugin sfTCPDFPlugin che le librerie TCPDF
(http://www.tcpdf.org/). Aggiungiamo un link al PDF nella nostra vista:
<div id="articolo">
...
<div class="pdf-link">
<?php echo link_to(
image_tag('pdf.png', array('alt' => 'Scarica PDF')),
'articoli/scaricapdf?articolo_id='.$articolo->getId()
Pagina 157
);
?>
</div>
</div>
</div>
Definiamo quindi la nostra azione:
public function executeScaricapdf(sfWebRequest $request)
{
);
$this->forward404Unless(
$articolo,
"L'articolo da commentare non esiste"
);
$config = sfTCPDFPluginConfigHandler::loadConfig();
$pdf = new sfTCPDF('L', PDF_UNIT, PDF_PAGE_FORMAT, true);
$pdf->SetCreator('Mio Blog');
$pdf->SetTitle($articolo->getTitolo());
$pdf->addPage();
$pdf->SetFont(PDF_FONT_NAME_MAIN, 'B');
$pdf->Write(
10,
'Articolo di '.$articolo->getAutore().
' del '.$articolo->getCreatedAt('d/m/Y'), null, 0, 'L',
true);
$pdf->Write(10, $articolo->getTitolo(), null, 0, 'L', true);
$pdf->SetFont(PDF_FONT_NAME_MAIN);
$pdf->Write(10, $articolo->getTesto());
$pdf->Output();
}
Fatto!
3.5
Backend: generazione automatizzata dell'accesso CRUD ai dati
Un'altra fantastica funzionalità del framework Symfony è la possibilità di creare in modo
automatizzato i moduli per la gestione del CRUD (Create, Read, Update, Delete) e della
ricerca degli oggetti della base dati. Con un semplice comando possiamo chiedere a Symfony
di creare un modulo per la gestione, ad esempio degli autori:
Pagina 158
luca@demetra:~/blog$ ./symfony propel:generate-admin \
--module="autori" fe Autore
Ed ecco il risultato:
modifica e inserimento:
Nel caso specifico, abbiamo visto delle tabelle molto semplici ma è possibile personalizzare
moltissimi aspetti dei moduli di amministrazione anche senza scrivere un riga di codice ma
semplicemente agendo sui file di configurazione.
3.6
Testing
Vediamo l'ultimo, ma decisamente non meno importante, aspetto di cui parleremo del
framework Symfony: la facilità nel creare i test. Con Symfony è possibile automatizzare
l'esecuzione dei test unitari e dei test funzionali.
I test unitari servono per controllare che ogni funzione o metodo restituisca i valori attesi. Per
fare qualche esempio, definiamo una funzione statica che, dato il titolo di un articolo, ce lo
restituisca "normalizzato". Ecco la funzione:
Pagina 159
class ArticoloPeer extends BaseArticoloPeer
{
static public function normalizza($testo)
{
// sostituisce tutto tranne lettere e punti con il carattere
$testo = preg_replace('/\W+/', '-', $testo);
// cancella gli spazi e converte in minuscolo
$testo = strtolower(trim($testo, '-'));
return $testo;
}
}
Questa funzione può essere utilizzata per la creazione delle url del tipo:
http://example.com/articoli/visualizza/symfony-per-lo-sviluppo-delle-applicazioni-web.
Per testare questa funzione, dovremo creare un file simile al seguente:
require_once dirname(__FILE__).'/../bootstrap/unit.php';
$t = new lime_test(4);
$t->is(ArticoloPeer::normalizza('Hal'), 'hal');
$t->is(ArticoloPeer::normalizza('Hal Software'), 'halsoftware');
$t->is(ArticoloPeer::normalizza('hal software'), 'halsoftware');
$t->is(ArticoloPeer::normalizza('hal,tecnologie informatiche'),
'hal-tecnologie-informatiche'
);
Con la riga di comando possiamo chiedere a Symfony di eseguire i test per noi e, di seguito,
vediamo l'output auspicabile:
luca@demetra:~/blog$ ./symfony test:unit nomeFile
1..4
ok 1
ok 2
ok 3
ok 4
Looks like everything went fine.
luca@demetra:~/blog$
I test funzionali, diversamente da quelli unitari, servono per testare l'applicazione nel suo
insieme. Normalmente, per testare una modifica all'applicazione, dovremmo usare il nostro
browser e provare tutte le combinazioni di azioni di un ipotetico utente. Questo processo è
decisamente prono ad errori e a dimenticanze. Per effettuare i test funzionali, Symfony mette
Pagina 160
a disposizione un oggetto browser. Con questo è possibile effettuare tutte le operazioni
dell'utente. Eccone un'esempio:
$browser = new sfTestFunctional(new sfBrowser());
$browser->
get('articoli/lista')->
;
with('request')->begin()->
isParameter('module', 'articoli')->
isParameter('action', 'lista')->
end()
Come per il caso precedente, con un semplice comando possiamo mandare in esecuzione tutti
i test in modo automatico. Il test funzionale ci permette di analizzare il risultato di ogni
interazione che l'utente abbia con la nostra applicazione in modo metodico e completo. È
possibile cliccare link e pulsanti. È possibile testare l'inserimento dei dati, la funzionalità dei
form. Insomma, a parte Javascript, ogni aspetto dell'interazione può essere testato.
4 CONCLUSIONI
In queste pagine abbiamo visto alcuni degli aspetti salienti di Symfony. Symfony è un
progetto in continua evoluzione (la versione 2.0 disponibile a fine 2010 segna una decisa
svolta verso nuove e più performanti soluzioni). Molti aspetti interessanti di Symfony non
sono stati neanche accennati: il routing, la configurabilità, la migrazione automatizzata delle
basi dati (Doctrine), il framework di gestione degli eventi e tanto altro ancora.
Come ogni prodotto anche Symfony ha un costo di apprendimento. Per me apprendere
Symfony ha voluto dire scrivere codice qualitativamente superiore, meglio organizzato e più
leggibile. A tutt'oggi, correggere bug è un processo estremamente veloce e aggiornare
l'applicazione nel server di produzione è sempre meno un "patema d'animo".
Invito, chiunque fosse interessato ad approfondire questi argomenti, a seguire i 24 articoli su
come creare un'applcazione completa con Symfomy e a contattarmi via mail
(lucasaba@gmail.com).
Bibliografia
Fabien Pontecier, Practical Symfony – Propel Edition http://www.symfonyproject.org/jobeet/1_4/Propel/it/
Fabien Pontecier, The Symfony Reference Book http://www.symfonyproject.org/reference/1_4/it/
Fabien Pontecier and Ryan Weaver, The More with symfony book http://www.symfonyproject.org/more-with-symfony/1_4/it/
Pagina 161
THE EVOLUTION OF DEFECTS AND PATCHES IN
SOURCEFORGE PROJECTS: A QUANTITATIVE
ANALYSIS
Morasca, Sandro, Università degli Studi dell'Insubria, via Carloni 11, 22100 Como
sandro.morasca@uninsubria.it
Proto, Michele, via Borgovico, 171, 22100 Como
michele.proto@gmail.com
Taibi, Davide, Università degli Studi dell'Insubria, via Carloni 11, 22100 Como
davide.taibi@uninsubria.it
Abstract
Open Source repositories are the primary resource where users look when they need to adopt new
Open Source Software (OSS). Their choice is guided by a number of factors. In this work, we focus on
two factors that are usually taken into account: the defect content of the software code and the ability
of a community to provide short-term support if problems are uncovered. Specifically, we
quantitatively analyze the evolution over time of the defect content and patches of Sourceforge
projects, to evaluate the quality of an OSS product and the ability of its community to provide shortsupport when needed. Among other results, we find out that, on average, the more a project is stable,
the more defects are uncovered, and the longer it takes to fix them.
1.
INTRODUCTION
The usage of Open Source Software (OSS) repositories has been continuously increasing in
the last few years, mostly because of the success of a number of well-known projects. This
success is due to multiple reasons, ranging from technical to financial to ethical ones.
Nonetheless, the adoption of OSS is sometimes still viewed as somewhat risky.
When facing the problem of adopting OSS, users and organizations evaluate and compare
projects by looking for several pieces of information in the repositories that host OSS
projects. Repositories are web platforms that provide hosting and specific tools to give
anyone the opportunity to share a project. Moreover, every repository gives the possibility to
download the software, monitor project activity, and easily retrieve useful information.
This work focuses on the analysis of two important factors that users closely take into
account when they need to adopt OSS: the defect content of a project and the likelihood of
receiving support in the future. So, we look at the lifetimes of defects, i.e., how they are
handled and fixed over time by a development community. We analyzed Sourceforge [23],
because of the number of projects it hosts and because it is the main repository that users look
at when they need to evaluate OSS products. Specifically, we analyzed the evolution of bugs
and patches for 135834 OSS projects over a period of six months. Among other results, we
Pagina 162
found that, on average, the more a project is stable, the more defects are uncovered, and the
longer it takes to fix them.
The remainder of this paper is structured as follows. In Section 2, we describe related works.
In Section 3, we concisely describe issues related to the analysis of the evolution of defects
and patches over time in OSS. In Section 4, we first present Sourceforge and then the data
that can be extracted from it that we used in this analysis. In Section 5, we show the results
we found and finally, in Section 6, we summarize our conclusions.
2.
RELATED WORKS
A few studies exist on OSS repositories, some of which we now concisely describe. One of
the initial works was carried out in 2002 [9]. The study drew conclusions from statistics on
the Sourceforge website investigating the time series of total Sourceforge downloads, the
cross sectional distribution of projects at a moment in time, and differential behavior of
segments of the cross section. Another work [10] analyzed the projects evolution over time.
Also, the OssMole project [11] provided a dataset created by crawling repositories web pages
and storing several data in a relational database. In [19] Hahsler and Koch discussed a
methodology for collecting repository data along with the possible information that can be
used for further analysis. They took into account lines of code (LOC) per project, the total
time spent on the project per developer and the development status extracted form
Sourceforge. In [18] Koch analyzed the evolution of a large sample of Sourceforge projects
by means of a linear and a quadratic model. Koch took into account the Number of
programmers, Commits, LOC and development status.
Several other studies have been carried out [12, 13, 14, 15, 16] which report quantitative
statistics on several projects. The main difference from our work and the previous one is
based on the information analyzed in OSS projects. All the previous work took into account
LOC, developers number and few other information while we based our analysis on the
information considered by the users during the OSS adoption.
The definition of the information commonly used by the users when they evaluate OSS
projects has been investigated in the last few years, and several OSS evaluation methods have
been proposed (see for instance [1, 2, 3]). In this context, in QualiPSo project [19] we have
identified [4] a common set of factors that users take into account when selecting OSS. These
factors have been obtained via a number of interviews carried out in industrial contexts, to
elicit the evaluation factors directly from industrial players. Reliability of source code and
short-term support have turned out to be among the most important factors in our analysis[4].
The factors indicated by our interviewees need to be investigated from a quantitative point of
view. As a matter of fact, extensive empirical studies on large collections of OSS are still
limited. Some studies have been carried out on the quality of OSS products and on their
related communities, mostly analyzing single projects [5, 6, 7, 8]. However, most people who
are interested in selecting and evaluating an OSS product often look into the most important
repositories to find the OSS products that best fit their needs.
In this work, we specifically focus on the evolution of defects and patches.
Pagina 163
3.
EVOLUTION LIFETIME OF DEFECTS AND PATCHES
Here, we analyze the evolution of defects and patches over time in OSS, to study the ability
and rapidity of development communities in remove defects.
The reliability of a software product heavily depends on the defects in a software product and
the activities undertaken to correct them. In OSS communities, “bug” commonly refers to a
defect, i.e., a problem in software code that prevents it from behaving as intended. Bugs are a
consequence of the human-intensive nature of Software Engineering. For instance, they arise
from oversights made by computer programmers during design, coding and data entry. Bugs
arise from errors made along all the software development phases, from requirements
specification to coding.
Delivered closed source software contains a number of bugs that are unknown to the users
even when they may already be known to the developers. On the other hand, OSS products
often provide a list of known bugs, which can be useful to users who want to know about the
behavior and reliability of the software they are using. An OSS project often uses a bug
tracking system, which is a software application that keeps track of reported bugs and the
way they are handled. Problems due to bugs are usually identified and submitted by users.
Then, each bug report is usually assigned to a developer, who fixes it by producing a patch as
soon as possible.
Counting known bugs may be more challenging than it may look at first glance. Because
bugs are always submitted and described by users, the definition and the classification of a
bug may be somewhat subjective and unclear. Duplicate bugs may not be recognized as such.
Policies for merging bug reports, for considering (or not) reports related to previous versions,
or even for using the bug tracking system for other issues (such as feature requests) can also
blur the real number of bugs found.
The information contained in the bug tracker can also be used to assess the quality of a
software product. Specifically, one can evaluate the number and severity of bugs over time
and their removal speed. The latter is also a good indicator of the quality of support for the
product. Thus, a bug tracking system can be also used to estimate if and how well an OSS
product will be supported in the future by a community.
Several aspects related to defects and patches need to be known to analyze the effectiveness
of short-term support, since they influence the time needed to solve a bug. If a community
consistently closes bugs rapidly, we can rely on the support provided by the community itself.
The number of developers involved in the project can clearly influence the rapidity with
which defects are fixed. Also, in some cases, the removal of specific defect can be sped up by
"donations." In practice, people can pay the organization maintaining the software for solving
the problem and so the cost/benefit analysis must also consider this cost in the case of a
product with a high donation/bugs ratio.
Thus, as the results in Section 5 show, we have used the following information to study the
short-term support provided by a community:
•
The evolution of the number of bugs and patches over time
•
The number of developers
•
The productivity of developers in terms of writing patches
Pagina 164
•
The number of donations.
We have studied this information in Sourceforge projects from April 1, 2007 to September
29, 2007. A six month period is used in most OSS evaluation methods [1, 2, 3], as it allows
for sufficient observational time of the activities going on in an OSS project.
4.
SOURCEFORGE
After describing Sourceforge, the repository whose projects we studied (Section 4.1), we
illustrate the set of data it provides (Section 4.2).
4.1
The Analyzed Repository: Sourceforge
The majority of OSS projects are distributed via repositories. This allows users and
developers to share and download OSS code and artifacts, to collaborate with other users or
developers in a project. A repository may be a general-purpose one, or it may be dedicated to
a specific program, platform, operating system, or environment. Every repository is based on
a Content Management System platform and provides code versioning tools (e.g., CVS,
Subversion), communication tools (mailing list archives, forums and wikis), and bug tracking
tools (e.g., Bugzilla, Mantis…) to enable collaborative software development:
Some of the most important OSS repositories are: Apache Software Foundation[21],
Codeplex [22], Codehaus[23], Objectweb[24], Rubyforge [25], Savannah[26], and
Sourceforge[20].
Sourceforge is the world's largest OSS repository, with the largest repository of OSS code
and applications available on the Internet. In October 2007, Sourceforge comprised 135834
projects. Sourceforge is owned by OSTG Inc. and provides free services to Open Source
developers. For each project, Sourceforge collects and displays some useful details, such as:
•
Project administrators
•
Number of developers
•
Intended audience (e.g., developers, end users)
•
Licenses
•
Supported Operating System
•
Programming language
•
Registration date
•
Last week activity percentile
•
Development status (from less to more advanced: prealpha, alpha, beta, stable,
mature)
In addition to hosting the source code of OSS projects, Sourceforge provides free of charge
tools for running such projects, including:
•
Bug tracking system
•
Technical support tracking system
Pagina 165
•
Patch tracking system
•
Feature request tracking system
•
Public forums
•
Mailing lists
•
CVS repository.
These tools allow potential developers and end users to retrieve interesting information when
looking for projects that meet specified quality criteria. One of the most interesting pieces of
information is the development status, even though it is not computed algorithmically, but
assessed by the project administrator.
The bug tracking system used in Sourceforge keeps track of all the bugs reported by an OSS
project’s users. A new bug is initially classified as “Unconfirmed,” and it needs to be
confirmed by a project manager or a developer who checks if it is really a bug, thus avoiding
duplications and the assigns the bug to a developer.
The severity of a bug is indicated with a numerical value (from 1 to 9) which we can interpret
as follows:
•
Very important (priority 8-9): critical bugs, e.g., crashes and data losses;
•
High priority (priority 6-7): operational bugs, e.g., a web browser that will only show
text, but not images;
•
Normal (priority 5): some parts of the project are not working the way they should,
e.g., a text editor in which the “paste” functionality does not work;
•
Low priority (priority 3-4): minor bugs and things that can be worked around with
macros or third parties utilities;
•
Not important (level 1-2): cosmetic bugs, default preferences.
A bug is submitted at the median default priority of 5 out of 9. It is examined, it may be
assigned a new priority level, and it is given to a developer to be fixed.
Confirmed bugs can be in two states: Open or Closed. All confirmed bugs are set as Open,
i.e., they are acknowledged as problems that need to be solved. Usually, a bug is closed when
a patch is committed to the CVS by a developer or when a new version is released, but
sometimes bugs are closed for other reasons than being fixed like duplications or invalidity
(sometimes the bug report is simply wrong).
4.2
The Sourceforge Research Data Archive
The project analysis was carried out by using Sourceforge Research Data Archive (SRDA)
[14]: a snapshot of the status of all the projects that Sourceforge shares with the University of
Notre Dame. The SRDA stores all data in a relational database allowing only registered users
to query the database. Starting from some example queries, we have built a set of SQL
queries aimed at extracting the information related to the product quality and the likelihood of
support in the future. A problem we faced with the SRDA is related to the query interface.
SRDA can be queried only via a web form without the possibility to integrate the information
extraction procedures in any external tool or to create any kind of automated procedures.
Pagina 166
5
RESULTS
We first provide some distributions about defects and then we study the factors related to the
support provided by development communities in Sourceforge.
Table 1 shows the distribution of bugs divided by priority for each development status, which
is also represented in Fig. 2. for graphical convenience. Note that the number of bugs in 4is
represented with a logarithmic scale, to conveniently represent the number of bugs at all
priority levels. Using a linear scale would have resulted in priority 5 bugs dwarfing all other
priority levels. However, using a logarithmic scale also implies that comparisons between
bars in the Fig. are clearly distorted with respect to a linear scale.
First, we see an inconsistency in the way the priority level is used because 42 bugs were
classified with priority 10, which should not be allowed in the 1 - 9 predefined range. This
was probably due to a clerical mistake during the bug priority assignment process (all of
these bugs belong to the “Open Visual Viewer'' project). We do not take these priority 10
bugs into account in our analysis.
We now provide an in-depth analysis of priority 5 and priority 9 bugs. Priority 5 bugs are the
vast majority of bugs, i.e., the vast majority of bugs is not modified from the default priority
5 level. Priority 9 bugs are the most critical bugs, so they deserve special attention.
Analyzing priority 5 bugs, the total number of bugs increases with the development status of
projects from prealpha to stable, but there is a sharp drop in the number of bugs from stable
to mature projects (Fig. 2.4). This behavior is consistent across all bug priority levels.
Taking into account the average number of bugs per project, instead of the total number of
bugs, the situation changes dramatically for mature projects, as shown in Table 1.The average
number of bugs per project increases with the development status, including mature projects,
which have by far the highest number of bugs per project. Table 2 (which summarizes a
number of results of this study) shows that the average number of bugs per project are as
follows: prealpha 2.49, alpha 4.20, beta 6.98, stable 13.67, mature 25.76.
5
Average number of bugs per project.
Pagina 167
Table 1. The Sourceforge Bug Distribution
DEV. P 1
P. 2
P. 3
P. 4
P. 5
P. 6
P. 7
P. 8
P. 9
P. 10
PREALPHA
2058
884
1856
729
47146
1239
2743
1464
2726
42
ALPHA
3689
2907
3458
1330
85588
2092
4445
2235
3920
BETA
7365
3254
7192
2807
188902
5153
9758
4768
9454
STABLE
13872
5076
10799
4479
297895
7592
14573
6977
12812
MATURE
2033
2585
2036
938
50137
1174
2078
1123
1567
TOTAL
29017
14706
25341
10283
669668
17250
33597
16567
30479
STATUS
42
Table 2. Analysis summary.
DEV.
BUGS
BUGS
PROJ.
DAYS
DEV.
DEVELOPE
PROJEC
PER
PER
PER
BUGS
STATUS
RS
TS
WITH
PER
PROJEC
PROJEC
DEVELO
DONATIO
BUG
T
T
PER
NS
PREALPHA
48735
24367
60887
2.00
2.49
1.25
120.70
2406
ALPHA
53364
26052
109664
2.05
4.20
2.06
87.43
2764
BETA
76785
34167
238653
2.25
6.98
3.11
94.25
4708
STABLE
71676
27354
374075
2.62
13.67
5.22
96.09
4946
MATURE
7732
2471
63671
3.13
25.76
8.23
147.74
386
6
The distribution of bugs per priority and development status.
Pagina 168
5.1 Bugs and Patches over Time
The diagrams in Figs. 3 and 4 show the average number of bugs per week for each
development status, from prealpha to mature. The number of priority 9 bugs per week shows
a high variability across the 6 month period we studied, as shown in Fig. 4. The same
behavior can be found at all other priority levels (which we do not explicitly show here for
space reasons), except priority 5 bugs, as shown in Fig. 3. 4Also, in each diagram, the curves
representing the number of bugs per week at different maturity levels often intersect each
other (see Fig. 4 for priority 5 bugs). However, the behavior of the number of bugs per week
at priority level 5 is clearer (see Fig. 3.), probably also because priority 5 contains the highest
number of bugs in each development status, which makes casual fluctuations less likely to
make the curves of bugs per week intersect.
In Fig. 54, we represent the average time needed to solve bugs at each priority level and for
each development status. There might be a somewhat decreasing trend of the average bug
fixing time when the bug priority level increases, but that does not appear to be true for all
development statuses, so the trend (if present) is not clear. Taking into account the priority 5
level, we find out that developers solve bugs faster in alpha projects (82 days) followed by
stable (89 days), beta (93 days), mature (100 days) and prealpha (116 days) projects.
Unexpectedly, in the majority of priority levels (and, notably, for the most critical bug
priority levels), mature projects are those which take the longest average time to solve a bug
while stable projects are always faster than mature ones in all priority levels. Fig. 54, which
shows the average bug solving time by development status, across all priority levels,
confirms that mature projects on average take longer than all other projects in fixing a bug.
As TABLE II 4shows, mature projects take an average of 147.74 days to fix a bug, while
stable project an average of 96.09 days.
Next, we analyzed the distribution of the patches to check the ability of development
communities to solve a bug. The analysis of patches is closely related to the analysis of bugs,
except that it is related to fixed bugs instead of open ones. Like for bugs, the vast majority of
patches are classified at priority 5. The number of average weekly patches per project for
each development status (for instance, as shown in Fig. 3 for priority 5 patches) closely
mirrors the number of weekly bugs per project for each development status (for instance, see
Fig. 4 for priority 5 bugs). The only difference between patches per project and bugs per
project lies in the absolute values: the number of patches per week is roughly one-third the
number of bugs. This can be explained because most of times developers release cumulative
patches that solve more than one bug.
Pagina 169
7
Average weekly number of priority 5 bugs per project, for each development status.
8
Average weekly number of priority 9 bugs per project, for each development status.
9
Average bug solving time per priority and development status.
Pagina 170
5.2 Developers and Their Productivity
We now take into account the number of developers. For each project, the number of
developers has been computed by counting the single developers to whom bugs were
assigned. The number of developers and the number of projects at each development status
(0) increase from the prealpha development status up to the beta development status. Both
numbers are slightly smaller for stable projects than beta ones. However, both numbers are
dramatically lower for mature projects than for stable projects. As Fig. 7 shows, the average
number of developers per project increases with the development status, from 2 developers
per prealpha project to 3.13 developers per mature project. The trend is consistent with the
increasing trend of the number of bugs per project, even though nowhere nearly as steep.
This trend is also consistent with the trend of the average time needed to solve a bug across
development statuses: the more stable a project is, the more time is required to fix bugs, on
average. This result seems to contradict what happens with the average time needed to fix a
bug in mature projects, as bugs in mature projects take longer to be solved than in stable ones
(Fig. 5). One would expect that the higher the number of developers assigned to a project, the
lower the time needed to fix a bug, on average. However, this may be explained by looking at
the number of bugs assigned to each developer at each development status (see Fig. 84).
Specifically, as detailed in Table 2, the number of bugs per developer range between 1.25 for
prealpha projects to 8.23 for mature projects. By comparing stable and mature projects,
developers in mature projects solve about 60% more bugs than developers in stable projects
while developers in mature projects take approximately 12% longer than developers in stable
projects.
5.3 Donations
Considering donations, the SRDA does not include any information related to the number and
amount of donations received per project. We can only check if a project has already received
one or more donation. At each priority level, there are a stable number of project which
received donations with some slight variations (Fig. 94). What we find out is that the
percentage of projects that received donations follow the same trend as the number of
projects, growing from 10% in prealpha projects to 18% in stable projects and then falling
back to 15% in mature projects (Fig. 104).
6.
CONCLUSIONS
Here, we summarize are a few findings of our analysis of Sourceforge projects.
The analysis immediately shows a problem in Sourceforge bug tracking system because, by
default, it assign each bugs a priority level 5 on a 1 to 9 priority range from. The consequence
is that priority 5 level contains the 79% of bugs and the other priority levels much less
relevant. This highly concentrated distribution shows the need for changing the priority
assignment mechanism.
The total number of bugs grows with the development status, except for a sharp drop from
stable to mature projects. Taking into account the number of bugs per project, the situation
somewhat changes, with a positive trend as development status increases and with a peak for
mature projects, which contain the highest number of bugs per project.
Pagina 171
Unexpectedly, the time taken to solve a bug also increases with the project development
status and thus peaks in mature projects. We must also take into account that in mature
project there is the highest number of developers per project. The highest time taken to solve
a bug in mature projects is due to the higher number of bugs assigned per developer. In
mature projects, developers have to solve 60% bugs more than in stable projects.
We also fond out that in Sourceforge donations can speed up the development: 14% of
projects received donations.
Considering the number of bugs and the time taken to solve bugs, we can conclude that in
average, in Sourceforge, stable projects are more reliable than mature ones because they
contains fewer bugs than mature and solve bugs faster. Finally, users need to be aware that
stable projects are also those with the highest number of donations per project.
Pagina 172
10
12
14
Developers vs projects, per development status.
11
Developers vs bugs, per development status.
Projects who received donations, per development status.
13
15
Average number of developers per project, per
development status.
Average number of bugs per developer, per
development status.
Percentage of projects that received donations, per
development status.
ACKNOWLEDGMENT
The research presented in this paper has been partially funded by the IST project “QualiPSo,"
sponsored by the EU in the 6th FP (IST-034763); the FIRB project ARTDECO, sponsored by
the Italian Ministry of Education and University; and the project “La qualità nello sviluppo
software,” sponsored by the Università degli Studi dell’Insubria.
We would like to thank Notre Dame University, to which we are deeply indebted for
allowing us to use the SRDA.
Pagina 173
REFERENCES
5. O’Reilly CodeZoo SpikeSource, “Business Readiness Rating for Open Source – A Proposed Open
Standard to Facilitate Assessment and Adoption of Open Source Software” www.openbrr.org”
August 2005.
6. Navica “Open source maturity model” www.navicasoft.com
7. D. Taibi, L.Lavazza, and S. Morasca. OpenBQR: a frame work for the assessment of oss.” in IFIP
International Federation for information processing, volume 234, Open Source Development,
Adoption and Innovation. Springer. Pages 173–186, 2007.
8. L. Lavazza S. Morasca D. Taibi V. del Bianco, M. Chinosi. How european software industry
perceives OSS trustworthiness and what are the specific criteria to establish trust in OSS.
9. Mockus, A., Fielding, R. and Herbsleb, January 2000. A case study of OS software development:
the Apache server. Proceedings of the 22nd International Conference on Software Engineering ,
May 2000, Limerick, IRL, pp 263-272.
10. Stamelos, I., Angelis, L., Oikonomou, A., Bleris, G.L., ‘Code Quality Analysis in Open-Source
Software Devel-opment’, Information Systems Journal, 2nd Special Issue on OS Software, 12(1),
January 2002, pp. 43-60.
11. Koch, S. and Schneider, G. (2000). "Results from software engineering research into OS
development projects using public data." available online at http://opensource.mit.edu/papers/kochossoftwareengineering.pdf
12. Mockus, R.T. Fielding, J.D. Herbsleb, 2002: “Two Case Studies of Open Source Development:
Apache and Mozilla”. ACM Transactions on Software Engineering and Methodology Vol.11, No.
3, 2002, 309-346.
13. F. Hunt, P. Johnson. On the Pareto distribution. of Sourceforge projects.”. In Open Source
Software. Development Workshop, University of Newcastle, Feb. 2002
14. A.Capiluppi, P.Lago, M.Morisio. Characteristics of Open Source Projects. Proceedings of the
Seventh European Conference On Software Maintenance And Reengineering (CSMR’03)
15. Ossmole, “Ossmole: a project to provide academic access to data and analyses of open source
projects,” 2004. [Online]. Available online at http://ossmole.sourceforge.net
16. Dawid, Weiss (2005). Quantitative Analysis of Open Source Projects on SourceForge. Proceedings
od the First International Conference on Open Source Systems (OSS 2005), Genova, Italy.
17. Gregorio Robles, Jesus M. Gonzalez-Barahona, Geographic location of developers at SourceForge,
Proceedings of the 2006 international workshop on Mining software repositories, May 22-23, 2006,
Shanghai, China
18. Mircea Lungu , Tudor Girba, A small observatory for super-repositories, Ninth international
workshop on Principles of software evolution: in conjunction with the 6th ESEC/FSE joint
meeting, September 03-04, 2007, Dubrovnik, Croatia
19. Jennifer Bevan , E. James Whitehead, Jr. , Sunghun Kim , Michael Godfrey, Facilitating software
evolution research with kenyon, ACM SIGSOFT Software Engineering Notes, v.30 n.5, September
2005
20. Huzefa Kagdi , Michael L. Collard , Jonathan I. Maletic, A survey and taxonomy of approaches for
mining software repositories in the context of software evolution, Journal of Software Maintenance
and Evolution: Research and Practice, v.19 n.2, p.77-131, March 2007
Pagina 174
21. Sandeep Krishnamurthy. Cave or community? an empirical examination of 100 mature open source
projects. First Monday, 7(6), 2002
22. S. Koch. Evolution of Open Source Software Systems–A Large-Scale Investigation. Proceedings of
the 1st International Conference on Open Source Systems, Genova, Italy, July, 2005.
23. M. Hahsler and S. Koch. Discussion of a Large-Scale Open Source Data Collection Methodology.
System Sciences, 2005. HICSS‚2005. Proceedings of the 38th Annual Hawaii International
Conference on, page 197b, 2005.
24. QSOS www.qsos.org
25. https://zerlot.cse.nd.edu/
26. QualiPSo: www.qualipso.eu
27. Sourceforge: www.sourceforge.net
28. Apache Software Foundation: www.apache.org
29. Codeplex: www.codeplex.com
30. Codehaus: www.codehaus.org
31. Objectweb: www.objectweb.org
32. Rubyforge: www.rubyforge.org
33. Savannah: http://www.savannah.gnu.org
Pagina 175
LA STRUTTURA DELLE RELAZIONI NEI PROGETTI DI
SOFTWARE LIBERO: UN’ANALISI COMPARATA
Daniele Bertagnolli, Libera Università di Bolzano – rayzxiii@alice.it
Fabio Fonti, Libera Università di Bolzano – fabio.fonti@unibz.it
Alessandro Narduzzo, Libera Università di Bolzano – narduz@unibz.it
Abstract
I progetti Free/Libre Open Source Software (FLOSS) negli ultimi anni hanno avuto forte
crescita e larga diffusione presso utenti, sviluppatori, aziende e Pubbliche Amministrazioni e
sono spesso presentati come un modello innovativo per lo sviluppo di nuovi prodotti.
Questo studio analizza tre progetti FLOSS, specificatamente distribuzioni del sistema
operativo GNU/Linux, ed esamina lo sviluppo delle comunità virtuali che animano tali
progetti. Vengono messi a confronto un progetto che, dopo un periodo di iniziale sviluppo ha
avuto fine, con altri due che invece hanno continuano a prosperare. Partendo da una
comparazione delle caratteristiche specifiche dei tre progetti, lo studio si concentra sulle
relazioni che si formano nelle comunità degli sviluppatori e degli utenti, analizzate
attraverso la Social Network Analysis (SNA) della struttura delle relazioni emergente dalle
rispettive mailing list.
I risultati mostrano che le comunità che animano i tre progetti presentano strutture di
relazioni distinte. I progetti che sopravvivono hanno comunità con un grado di centralità
sistematicamente inferiore rispetto alle comunità dei progetti che sono morti e sono
caratterizzati dalla presenza di almeno una sottocomunità che tende a comunicare più
intensamente, ma non esclusivamente con se stessa.
Parole Chiave: GNU/Linux, sopravvivenza progetti FLOSS, struttura relazioni, Social
Network Analysis.
1 INTRODUZIONE
I progetti FLOSS sono progetti di sviluppo software libero che prendono forma dalla volontà
di determinati individui di iniziare a sviluppare un software per soddisfare un proprio
bisogno. Il codice sorgente del software viene poi reso disponibile dall’iniziatore del progetto
Pagina 176
a chiunque voglia utilizzarlo e modificarlo, secondo un sistema di diritti definiti dal tipo di
licenza adottata.
L’indiscutibile diffusione del software libero ha indotto molti studiosi ad indagare sulle
specificità di questo fenomeno. Ad esempio, un aspetto che ha trovato molta attenzione nella
letteratura è l’analisi delle ragioni che inducono le persone a partecipare su base volontaria a
tali progetti. Questi studi hanno individuato un’eterogeneità nelle motivazioni che spingono a
parteciparvi, rilevando sia motivazioni intrinseche (volontà di partecipare al progetto,
altruismo, sfide che il progetto può offrire, senso di appartenenza ad un gruppo, ecc.) che
motivazioni estrinseche (reputazione o ritorno economico) [1]. Non altrettanta attenzione è
stata invece posta ai driver che spingono l’evoluzione di questi progetti. In tal senso, una
domanda che resta ancora aperta è quali siano i fattori che contribuiscono al successo di un
progetto FLOSS. In questo studio, cerchiamo di dare una risposta a questa domanda mettendo
a confronto tre progetti FLOSS simili dal punto di vista del sistema sviluppato (una
distribuzione GNU/Linux). Due progetti, Ubuntu e CentOS, sono sopravvissuti, mentre
WBEL, dopo una fase di sviluppo iniziale ha smesso di essere attivo e non è più stato
sviluppato. Nel confrontare i due progetti attivi con il progetto inattivo, il nostro scopo è di
individuare se esistono elementi distintivi che vadano oltre la natura del progetto stesso
(quindi la scelta di comparare progetti di natura simile) e che spiegare il destino avuto dal
progetto.
In un sistema competitivo, il successo di un prodotto viene ricondotto alla sua superiorità
rispetto a prodotti concorrenti. Per analogia, si potrebbe sostenere che la diffusione di un
progetto FLOSS dipenda dall’utilità del sistema sviluppato o dalle caratteristiche specifiche
rispetto a sistemi simili. In questo caso, però, a noi interessa andare oltre a questa possibile
causa di eterogeneità e capire se esistano altri elementi legati al progetto che ne condizionino
l’evoluzione: per tale ragione, abbiamo scelto di analizzare tre progetti che riguardano lo
sviluppo di sistemi simili. A questo punto, la ricerca delle ragioni per cui i progetti esaminati
prosperino o scompaiano chiama direttamente in causa le natura delle comunità che
partecipano al loro sviluppo. Analisi empiriche sui progetti di software libero hanno mostrato
come la loro sopravvivenza dipenda dalle capacità di coinvolgere e motivare coloro che
partecipano al progetto [2], ossia gli sviluppatori liberi (che sviluppano il codice sorgente,
implementano nuove funzioni, preparano traduzioni, documentazione, ecc.) e gli utenti (che
utilizzano il software scoprendone bug, dando suggerimenti, ecc.).
In tal senso, in questo studio la nostra analisi si focalizza sulla struttura delle relazioni che si
stabiliscono tra i membri delle comunità legate ad un progetto. Queste relazioni sono
osservate attraverso i flussi di comunicazione che avvengono nei gruppi di discussione a cui
partecipano sviluppatori e utenti. Altri studi hanno già evidenziato l’importanza della
dimensione relazionale nelle comunità che sviluppano software libero. Partecipando a una
comunità le persone condividono conoscenza, possono prendere decisioni riguardo allo
sviluppo futuro del sistema software e le caratteristiche da inserire nelle nuove versioni, ed
aiutano (o sono aiutatati da) altri a risolvere problemi nell’uso del sistema. Alcuni autori si
sono soffermati sull’analisi delle relazioni all’interno della comunità di un progetto FLOSS
per comprendere la struttura di governo [4]. Per esempio, O'Mahony e Ferraro [4] e Torala ed
i suoi colleghi [5] hanno analizzato i ruoli informali ricoperti dai membri delle comunità e
hanno stabilito una relazione tra il successo di un progetto FLOSS, la capacità di creare un
prodotto di alta qualità, l’intensità di partecipazione dei membri alla comunità e la capacità di
attrarre nuovi membri. Dahlander [3] invece ha utilizzato l’analisi delle reti di relazioni per
comprendere come le comunità che animano i progetti di software libero riescano ad
Pagina 177
appropriarsi di capacità (expertise) esterne alla comunità stessa ed ha trovato che è
determinante la presenza e l’attività di sviluppatori sponsorizzati, capaci di influenzare la
partecipazione degli altri membri.
2 METODO
In questo studio empirico sui progetti di software libero l’unità di osservazione è costituita
dalle comunità di sviluppatori e di utenti che animano il progetto. Il metodo scelto per
studiare queste comunità è la Social Network Analysis (SNA) [6], ovvero quella disciplina
che studia le relazioni sociali che intercorrono tra le persone che partecipano ad un network
(o comunità). In ciascuna comunità abbiamo analizzato il network di comunicazione che
emerge da ogni mailing list (di utenti e di sviluppatori) associata al progetto. In tal senso, le
relazioni tra i membri della comunità vengono definite dagli scambi di email che avvengono
tra loro via la mailing list. Quindi, abbiamo utilizzato la SNA per capire la struttura delle
relazioni che si instaurano tra i membri di una comunità, i modi in cui essi si aggregano e la
formazione di gruppi di persone che interagiscono più intensamente tra di loro. Lo scopo di
quest’analisi è di cercare di evidenziare differenze nella struttura relazionale dei progetti
attivi e di quelli dismessi.
Le comunità prese in esame e le relazioni sociali che si stabiliscono al loro interno (via le
mailing list) sono completamente informali ossia si realizzano per volontà delle persone, e
non sono determinate nè in modo casuale, né seguono una struttura gerarchica prestabilita.
Infatti, su ogni mailing list tutti i messaggi arrivano a tutti gli iscritti, che sono liberi di
rispondere o no. Le analisi condotte sulla struttura delle comunità si focalizzano su due
aspetti fondamentali:

Indici di struttura (smallworldliness index e analisi di centralità): un importante
riferimento per mettere in evidenza alcune proprietà strutturali delle relazioni sociali
interne alle comunità è dato dallo smallworldliness index, ossia dal grado in cui tali
strutture si avvicinino ad uno small world [8] e dalla centralità, ovvero l’analisi
dell’importanza delle persone all’interno della comunità, studiando il modo in cui le
relazioni sociali si concertano da o verso altre persone [6];

Analisi dei gruppi informali (via blockmodeling [3], core\periphery [9] ed
homophily). All’interno di ogni struttura sociale abbiamo usato la tecnica del
blockmodeling per evidenziare gruppi di persone che, grazie al loro modo di
comunicare formano, di fatto, dei gruppi informali all’interno della comunità. Tali
gruppi svolgono un ruolo comunicativo, più o meno intenso, a seconda delle relazioni
che intercorrono tra i membri identificati. La presenza di gruppi emersi solo grazie
alla comunicazione tra le persone e non grazie all’imposizione gerarchica o derivante
da una struttura formale, consente di capire come queste persone si rapportino tra
loro e forniscano i propri contributi al progetto. Questi fattori relazionali consentono
inoltre di fare delle ipotesi riguardo alle caratteristiche proprie delle due comunità
(utenti e sviluppatori) ed ai diversi comportamenti che emergono al loro interno, che
poi influenzeranno la buona o cattiva riuscita del progetto in cui tali individui fanno
convergere i loro sforzi. Ancora, studiano lo scambio dei messaggi che mettono in
relazione i membri della comunità, è possibile identificare la presenza di sottogruppi,
dominanti o periferici (analisi cosiddetta core\periphery). Attraverso quest’analisi e
prendendo in esame le relazioni tra i diversi sottogruppi è possibile individuare le
Pagina 178
persone che hanno un ruolo chiave nella vista dell’intera comunità, essendo nella
posizione di poterla animare e influenzare. Infine, tramite la tecnica di homophily, si
analizza in che misura le persone siano più o meno aperte alla comunicazione con
altri membri. A tal scopo, inizialmente vengono contate le relazioni che fanno capo a
ciascun membro della comunità (ossia, il numero messaggi inviati e ricevuti da ogni
individuo); successivamente, si studiano le relazioni in entrata ed in uscita che si
stabiliscono tra i gruppi informali precedentemente individuati per mezzo dell’analisi
di blockmodeling.
Al fine di ottenere la piena comparabilità dei casi in esame, è stata fatta una prima selezione
dei casi in funzione del livello di attività (active e dead), della loro discendenza (forking) e
della disponibilità di informazioni (mailing list ancora esistenti, presenza della home page,
iso scaricabili, ecc.). In letteratura esistono diversi modi di definire il “successo” di un
progetto FLOSS. Ad esempio, English & Schweik [10] e Wiggins & Crowston [11] lo
equiparano al livello di attività che il progetto FLOSS ha al momento attuale della sua vita,
ed identificano sei situazioni distinte, caratterizzate da fattori quali il numero di release che
sono state rilasciate ed il tempo passato tra ogni release, il numero di download e l’iscrizione
delle release nel sistema di SourceForge. Nel nostro caso, per differenziare tra progetti active
e dead, ci basiamo sul sito www.distrowatch.com, una delle maggiori risorse di riferimento
per la comunità GNU/Linux per quanto riguarda le varie distribuzioni, secondo la cui logica,
un progetto FLOSS è active se se ha rilasciato negli ultimi 6-12 mesi una release (oppure ha
dichiarato una data indicativa per la prossima release) oppure, osservando i progetti listati, se
il suo sviluppo non è stato dichiarato cessato o di fatto le sue mailing list continuano ad
essere popolate da messaggi (quindi relazioni sociali) ma non vengono rilasciate nuove
versioni. Tutti gli altri progetti sono da considerarsi di fatto dead.
3 I CASI
I progetti FLOSS presi in esame in questo studio sono tre distribuzioni del sistema operativo
GNU/Linux. Ai fini di una valida comparazione, abbiamo scelto due progetti attivi, Ubuntu
e CentOS, ed uno dismesso, White Box Enterprise Linux. Osservando i dati in Tabella 1, i
tre progetti possono essere messi a confronto rispetto ai seguenti elementi:
 Ciclo di release
, ovvero ogni quanto tempo viene rilasciata una versione stabile dell’OS, e quanto i rilasci sono condizionati da un progetto progenitore (Debian e Red Hat);
 Messaggi , ovvero il numero di messaggi scambiati attraverso le mailing list dei due set di attori presenti in ogni comunità, ossia utenti e sviluppatori;
 Nascita del progetto , ovvero i driver della nascita del progetto, che sono principalmente due:
 Communitydriven, se l’iniziativa è nata da una comunità di utenti o sviluppatori;
 Firmdriven, se l’iniziativa è nata dalla volontà imprenditoriale o di un’impresa.
In entrambi i casi, considerate le caratteristiche dei FLOSS la presenza di comunità di utenti e sviluppatori è comunque necessaria per la sopravvivenza del progetto stesso, nonostante gli utenti possano donare risorse al progetto o gli stessi possano attirare degli sponsor;
 Struttura gerarchica ,ovvero la presenza o meno di sottogruppi di lavoro responsabili dello sviluppo di parti specifiche del sistema. Alcuni progetti sono coordinati da più persone (o gruppi), mentre altri sono gestiti da una singola persona;
Pagina 179


Motivazione , ossia se i progetti dichiarano esplicitamente le forme in cui gli utenti e sviluppatori possono dare il loro contributo al progetto, in termini di denaro, piattaforme informatiche (server), codice sorgente, pubblicità al progetto, ecc. In alcuni casi i project leader (ad esempio, in WBEL) disincentivano ogni forma di partecipazione allo sviluppo del prodotto cercando di sopravvivere unicamente tramite le economie di rete derivanti dalla “copia” delle release del progenitore RHEL, fatto che può incidere sulla propensione delle persone a partecipare;
Supporto , ossia se i progetti forniscono un supporto al proprio prodotto anche dopo il rilascio di una release superiore. Tale supporto si traduce in patches, aggiornamenti di sicurezza, correzione di bugs, ecc.
4 RISULTATI
Le analisi svolte mettendo in relazione il livello di partecipazione dei membri delle comunità
(Figura 1 e 2: in verde gli sviluppatori, in rosso gli utenti) con le politiche di rilascio rivelano
alcuni elementi ricorrenti. Si osservi l’andamento della partecipazione nei progetti attivi e in
quelli inattivi. In WBEL e Ubuntu, osservando i primi momenti di vita delle comunità di
utenti e sviluppatori, si nota un picco di partecipanti fin da subito (una sorta di boom), mentre
in CentOS si registra un’adesione e una crescita lenta nella partecipazione, nonostante i
progetti basati su RHEL (WBEL e CentOS) abbiano avuto a disposizione le stesse release del
progenitore su cui lavorare. Come detto in precedenza, i cicli di rilascio di nuove versioni da
parte dei progetti sono diversi, ma esiste un fattore accomunante ovvero il fatto che a seguito
del rilascio di una nuova release si presenti un picco nel numero di persone attive all’interno
delle rispettive comunità. Questi picchi localizzati di utenze sono evidenziati intrecciando le
date di rilascio delle nuove release dei progetti (righe blu verticali, più marcate per una major
release e meno marcate per una minor release) con la curva del numero di soggetti attivi. I
picchi di partecipazione che sembrano caratterizzare le comunità attive sono caratterizzati, in
Figura 1, dai cerchi gialli e rossi (a seconda che l’aumento di partecipazione caratterizzi solo
la comunità degli sviluppatori o anche quella degli utenti). Le comunità sviluppatori
sembrano meno inclini a fluttuazioni nel numero di partecipanti attivi anche a seguito di
nuove release (anche se ne subiscono comunque un certo effetto), mentre le comunità utenti
risultano molto più condizionate da questo elemento. Come si può vedere dalle Figure 1 e 2, i
picchi si verificano ad ogni rilascio, sia minor che major (anche se in entità diverse), segno
che dimostra come le nuove versioni siano in grado di attirare e sollecitare la comunicazione
delle persone all’interno delle rispettive comunità.
La struttura di ogni comunità (utenti e sviluppatori) è stata analizzata con gli strumenti della
SNA. In particolare, abbiamo analizzato lo smallworldliness index, dopo aver verificato
l’esistenza di una power-law (ovvero di poche persone con molte relazioni e molte persone
con poche relazioni)85. In tutti i progetti, i valori dello smallworldliness index sono maggiori
nelle comunità utenti rispetto alle relative comunità sviluppatori, il che denota che la
tendenza degli sviluppatori a lavorare da soli (clustering basso) ed a instaurare relazioni
principalmente con coloro che sono preposti alla modifica del codice. La natura di small
world delle comunità analizzate, sia nei progetti attivi che in quello fallito, indica la presenza
di un numero elevato di persone con poche relazioni sociali e di alcuni membri con molte
relazioni. Si osserva una forma di preferential attachment (ovvero quando le persone tendono
85
Fa eccezione il progetto Lineox, per l’esiguo numero di membri delle comunità.
Pagina 180
a creare principalmente una relazione con membri della comunità che sono integrati bene nel
tessuto sociale, quindi hanno molte relazioni) ed una crescita [7]: esistono quindi alcuni
individui (hubs) molto importanti, che con la loro partecipazione tengono insieme la
comunità e sono in grado di accumulare, ma anche di condividere la conoscenza con coloro
che gli gravitano intorno. Utilizzando le mailing list come base dati per le analisi, questo
fenomeno risulta attenuato perché il preferential attachment si manifesta quando un hub
decide di comunicare con gli altri membri della comunità (tramite un messaggio email) e non
viceversa (come osservato in comunità dove la struttura sociale è visibile od esistono
organigrammi visibili).
È stata poi effettuata l’analisi della centralità in tutte le comunità al fine di valutare quanto
ognuna di esse diverge dalla situazione di massima centralizzazione (il cosiddetto star graph,
dove esiste un membro al centro del network che è connesso a tutti gli altri membri, a loro
volta disconnessi tra loro). Le comunità utenti (sia nei progetti attivi che in quelli morti)
risultano più decentralizzate rispetto a quelle sviluppatori, ma tutti i progetti sembrano avere
una tendenza all’essere dominate dalla presenza di sottogruppi di utenti e/o sviluppatori,
molto attivi nella condivisione della conoscenza rispetto all’intera “massa” di partecipanti,
denotando complessivamente apertura alle relazioni sociali ed alla comunicazione. Questi
gruppi possono considerarsi open-elites, ovvero gruppi di persone che sono propensi alla
comunicazione con membri di altri gruppi. Inoltre, la centralità è molto più elevata in
ciascuna comunità del progetto inattivo rispetto ai due progetti attivi e alle relative comunità.
Si può quindi pensare che una struttura che tende allo star graph, ossia con network
centralization molto elevata, oltre il 20% circa per gli utenti ed oltre il 30% per gli
sviluppatori (come succede nel progetto abbandonato), non sia adatta ad “ospitare” una
community favorevole allo sviluppo di progetti FLOSS. Questo perché una rete di legami
altamente centralizzata risulta molto affine, se non identica, ad una struttura fortemente
gerarchica, dove le decisioni vengono prese al vertice. Questo tipo di strutture molto
centralizzate portate in contesti informali, fanno sì che la conoscenza si concentri in
pochissimi individui che, per limiti fisici, non potranno mai rispondere a tutte le domande o
questioni sollevate degli altri utenti; quindi, qui si crea un collo di bottiglia nella diffusione
della conoscenza e nel progresso del progetto, come nel caso di WBEL (un solo sviluppatore
con la possibilità di modificare il codice e comunità molto centralizzata). Infatti, in capo a
questi soggetti sviluppatori si viene a creare un rallentamento nel passaggio dei progressi fatti
dalla comunità verso il prodotto finale, a causa proprio dei limiti fisici di queste poche
persone.
Successivamente (si veda Tabella 2), abbiamo cercato l’esistenza di altri pattern relazionali
attraverso il blockmodeling, l’analisi di core/periphery ed homophily. Da questo tipo di
analisi emerge come sia necessaria la presenza di almeno un gruppo centrale (detto anche
core) all’interno della comunità di utenti e di sviluppatori, dove la maggior parte delle
relazioni e della comunicazione avviene all’interno del gruppo stesso. Questo gruppo centrale
comunica prevalentemente con sé stesso, ma ha anche legami con la periferia del network,
ovvero un altro gruppo di persone ritenute periferiche in termini di relazioni e comunicatività,
perciò “dominate” dal primo gruppo. In questo senso, la periferia fa riferimento al gruppo
dominante per informazioni, suggerimenti, richieste, e gli appartenenti alla periferia
comunicano pochissimo con altri membri periferici. Il gruppo dominante funge sia da
generatore sia da accumulatore di conoscenza, diffondendola anche presso i soggetti
periferici (come possono essere utenti o sviluppatori saltuari, o nuovi entrati nel progetto). In
entrambe le categorie di progetti, attivi e inattivi, è stata osservata l’esistenza di un secondo
Pagina 181
gruppo dominante, un’open-elite (eterofilo, che comunica con la propria periferia), che ha
intense relazioni con il gruppo dominante principale. Le relazioni di questo secondo gruppo
con l’esterno, tuttavia, sono mediate dal gruppo dominante principale; quest’ultimo è closedelite poiché la maggior parte delle relazioni avvengono tra i membri che appartengono al
gruppo, piuttosto che con membri esterni. Si concretizza quindi l’esistenza di un secondo
gruppo periferico controllato dalla open-elite; quest’ultima è sottoposta però al controllo del
gruppo dominante principale (closed-elite), il quale controlla anche una propria periferia, per
un totale di due gruppi dominanti e due periferie. Il gruppo dominante “inferiore” rappresenta
perciò un punto di congiungimento tra due parti della comunità diverse o distanti, fungendo
da tramite per la diffusione della conoscenza del gruppo principale anche in zone molto
periferiche della stessa comunità.
I gruppi dominanti identificati nelle comunità sviluppatori sono meno numerosi rispetto alle
comunità utenti. Inoltre, mettendo in relazione la comunità degli sviluppatori e degli utenti
del progetto Ubuntu si osserva che la sopravvivenza non dipende dall’esistenza di gruppi di
coesione, ovvero di gruppi di persone, diversi dai gruppi dominanti, e altamente
comunicative principalmente con soggetti del proprio gruppo.
La ricerca di questi gruppi dominanti e dei gruppi periferici avviene accostando al
blockmodeling (lo studio sull’esistenza di gruppi di persone sulla base delle relazioni sociali
instaurate) un’analisi di core/periphery; in tal senso, l’analisi dei dati mostra che la
dispersione calcolata tramite il coefficiente di Gini sui valori di coreness (ovvero quanto è
probabile che un certo soggetto faccia parte del gruppo dominante) all’interno di tutte le
comunità è molto elevata (confermando il comportamento della power-law iniziale) mentre a
livello “composito” (enfatizzando la ricerca dei gruppi dominanti e quelli periferici) denota il
fatto che vi sono moltissime situazioni di semi-periferia, specialmente nelle comunità utenti.
Esistono quindi soggetti la cui influenza all’interno del network di riferimento è buona
(coreness di poco più basso del valore di soglia) ma non sufficiente a farli rientrare
all’interno dei gruppi dominanti (identificati tramite le relazioni in possesso di ciascun
membro), tantomeno così bassa da farli rientrare nella periferia. Valori più alti per le
comunità sviluppatori dimostrano ancora una volta che le comunità utenti hanno una
tendenza maggiore alla comunicazione rispetto alle comunità sviluppatori.
Un risultato importante è quanto emerge in WBEL, che rappresenta una situazione molto
simile ad un progetto attivo e, considerando il modo in cui i suoi membri comunicano nelle
due comunità, si può pensare che la dispersione delle informazioni all’interno delle comunità
mini la stabilità del progetto stesso. Questo perché, in entrambe le comunità del progetto
WBEL si è realizzata l’esistenza di un solo gruppo dominante con più periferie. Esse sono in
grado di influenzarlo in modo massiccio in quanto i valori di comunicazione da e verso il
gruppo dominante sono molto più elevati rispetto alla comunicazione che i membri del
suddetto gruppo hanno tra di loro, fatto che non si rispecchia negli altri progetti attivi, dove
due periferie si hanno solo con due gruppi dominanti.
Inoltre, è stato preso in esame il fenomeno della cross-partecipation, ossia del fatto che la
stessa persona partecipi sia alla comunità degli sviluppatori sia a quella degli utenti dello
stesso progetto. Questa circostanza è molto importante, in quanto denota che da ambo le parti
vi è volontà di acquisire conoscenza che non prettamente disponibile nella propria comunità
iscrivendosi alla parallela, oppure vi può essere la volontà degli sviluppatori di prendere
spunto dalle questioni sollevate dagli utenti o fungere da tramite informativo tra i due contesti
(un cross-hub per l’appunto). Esaminando il volume complessivo della comunicazione
Pagina 182
all’interno delle comunità si nota che la maggior parte dei messaggi (90%) è inviato\ricevuto
da una piccola massa di membri, una elite; questo elemento è presente sia nelle comunità
utenti che sviluppatori di ciascun progetto. Dall’altro lato, le comunità sviluppatori
dimostrano che questi ultimi hanno la tendenza all’impegno individuale e tendono a
suddividere il lavoro tra di loro, quindi la comunicazione è diretta principalmente verso i
pochi che hanno accesso alla modifica del codice sorgente. Questo fatto è confermato
dall’analisi precedentemente condotta attraverso la Network Centralization, dove si è notato
che gli sviluppatori possiedono una struttura informale più centralizzata rispetto alle
comunità utenti. Questa tendenza è rafforzata anche dal tasso di corrispondenza tra i membri
dell’elite che invia e quella che riceve il 90% dei messaggi (relazioni comunicative OUT-IN),
quindi si verifica se ogni persona funge da:
 Hub, essendo presente nel numero di persone che inviano e ricevono il 90% dei messaggi;
 Mero accumulatore, se è presente solo nel numero di persone che ricevono messaggi;
 Mero diffusore, se è presente solo nel numero di persone inviano messaggi.
Emerge che la corrispondenza di membri tra le due elite (OUT ed IN) è maggiore nelle
comunità utenti rispetto a quelle sviluppatori. Una corrispondenza “bassa” in questo indice
dimostra che la conoscenza non è trasferita in modo univoco e generalizzato anche con
soggetti nuovi o periferici, ma vi sono soggetti che tendono prettamente a diffonderla mentre
altri soggetti tendono ad accumularla. La presenza di accumulatori di conoscenza è un fatto
positivo, fungendo come una sorta di “memoria” storica ed informativa per il progetto stesso
a cui sia utenti che sviluppatori (a seconda della comunità) possono fare affidamento, però,
dall’altro lato la presenza di meri accumulatori rappresenta un fattore di inefficienza e di
stagnazione delle informazioni. Nelle comunità sviluppatori dei progetti attivi, questo tasso è
più basso rispetto agli utenti (rispettivamente oltre il 70% ed oltre l’80%), fatto che potrebbe
indicare ancora una volta che gli sviluppatori tendono a lavorare da soli, comunicando solo se
necessario od allo scopo di comunicare le proprie modifiche. Ancora, i tassi di
corrispondenza sono più alti nelle comunità dei progetti attivi rispetto a quelle dei progetti
morti, manifestando la diffusione delle informazioni in modo inefficiente in queste comunità.
5 CONCLUSIONI
Considerati le limitazioni intrinseche nei dati di cui ci si è avvalsi in questo studio, il fatto che
l’analisi prenda in considerazione l’intero arco di vita di questi progetti e non specifiche fasi
del ciclo di vita del progetto, l’impossibilità di avere informazioni aggiuntive riguardo i
singoli utenti/sviluppatori ed il campione limitato a tre casi di studio, per le ricerche future si
suggerisce la possibilità di costituire un campione di progetti sempre nel settore degli OS ma
più vasto (statisticamente rilevante anche tramite campionamento casuale). Inoltre, l’analisi
del contenuto della comunicazione consentirebbe di estendere le dimensioni del confronto tra
progetti che sopravvivono rispetto a quelli che soccombono, valutando le comunità per la loro
capacità di risolvere problemi e di creare e mobilizzare la conoscenza.
Pagina 183
Ubuntu
CentOS
White Box E.L.
Ottobre 2004
Maggio 2004
Dicembre 2003
Debian
9.10
RHEL
5.4
Condizionata dal ciclo vitale di RHEL
(GAP=1 MESE)
DEVEL: 372
USERS: 3.023
DEVEL: 3.267
USERS: 70.021
DEVEL: 939
USERS: 20.078
Active
RHEL
4.0 Respin 2
Informazioni generali
Nascita del progetto
Progenitore
Ultima Versione
Pianificata in Ciclo di release anticipo; rilascio ogni 6 mesi
Users che hanno postato nella mailing list (almeno 1)
DEVEL: 2.354
USERS: 9.892
DEVEL: 27.448
Messaggi complessivam. Scambiati
USERS: 178.412
DEVEL: 4727
Thread aperti dall’inizio (approx.)86
USERS: 101.395
Classificazione Distrowatch
Active
Condizionata dal ciclo vitale di RHEL
DEVEL: 122
USERS: 762
DEVEL: 444
USERS: 6.701
DEVEL: 367
USERS: 2.839
Dead
Relations with the Community
Nascita Community o Firmdriven?
Offerta di Servizi a pagamento
Partners commerciali/supporto
Entrambe
SI
SI
Community
driven
NO
SI
FirmDriven
(scopo interno)
SI
NO
Community Design
La community La community La community è possiede una possiede una ridotta, poco struttura molto struttura
considerata
articolata
Viene incentivata Viene incentivata La partecipazione è Motivazione
la partecipazione la partecipazione
incentivata poco
Struttura gerarchica
(presenza di gruppi di lavoro)
Supporto economico users
SI
SI
NO
DEB, RPM
Prevista
RPM
Prevista
RPM
Non prevista
18 mesi
(prevista LTS)
circa 7 anni
(in linea RHEL)
circa 7 anni
(in linea RHEL)
Main SW characts
Packages
Server Edition
Supporto oltre il rilascio
Tabella 1. Informazioni sui casi
Il conteggio dei thread è stato fatto verificando la corrispondenza tra ID, REPLY e REFERENCE. Il dato è da considerarsi spurio di errori minimi presenti nel sistema di indicizzazione alla base del server o del meccanismo di estrazione.
86
Pagina 184
Ubuntu
CentOS
WBEL
Comunità
USERS
DEVEL
USERS
DEVEL
USERS
DEVEL
Smallworldliness
43,260
21,144
10,487
6,447
9,610
3,409
C\P
SI
SI\NO
SI\NO
SI\NO
SI\NO
SI\NO
Numero di Core
Numerosità primo C.
E-I primo core
Numerosità secondo
C.
E-I secondo core
RCM
1
(2071)
-0,418
1
(276)
0,356
2
(864)
-0,332
2
(75)
-0,103
1
(190)
0,050
1
(23)
0,094
-
-
(383)
(60)
-
-
251
142
0,446
134
0,406
31
31
22
Concentrazione
0,790
0,777
0,805
0,841
0,815
0,825
Gruppi importanti*
2 (G)
1(P)
1 (P)
2 (P)
2 (P)
2 (P)
2 (P)
Posizioni isolate
Popolazione
Coeff. di Gini
1
(9892)
0,866
1
(2354)
0,768
1
(3023)
0,798
1
(372)
0,775
1
(762)
0,819
1
(122)
0,660
Tabella 2.
Figura 1.
Misurazioni di Social Network Analysis
Crescita boom nel numero di partecipanti
Pagina 185
Figura 2.
Crescita lenta nel numero di partecipanti
BIBLIOGRAFIA
[1] Osterloh, M., Frey, B. S., J. Frost, The Dynamics of Motivation in New Organizational
Forms, International Journal of the Economics of Business, 2002;
[2] E. Katsamakas, N. Georgantzas, Why most open source development projects do not
succeed?, First International Workshop on Emerging Trends in FLOSS Research and
Development, 2007;
[3] Linus Dahlander e Martin W. Wallin, A man on the inside: Unlocking communities as
complementary assets, Research Policy nr.35, 2006;
[4] Siobhan O'Mahony e Fabrizio Ferraro ,The emergence of governance in an Open Source
Community, Technology, Innovation and Institutions Working Paper Series, 2007;
[5] S.L. Torala, M.R. Martínez-Torresb e F. Barreroa, Analysis of virtual communities
supporting OSS projects using social network analysis, Information and Software
Technology, Volume 52, 2010;
[6] S. Wasserman, K. Faust, Social Network Analysis: Methods and Applications, Cambridge
University Press, 1994;
[7] Albert-László Barabási, Eric Bonabeau, Scale-Free Networks, Scientific American,
maggio 2003;
[8] Duncan J. Watts, Networks, Dynamics and the Small-World Phenomenon, The American
Journal of Sociology, Vol. 105, No. 2, settembre 1999;
[9] S. P. Borgatti, M. G. Everett, Models of Core\Periphery, Social Network Vol. 7, 1999;
[10] R. English, C. Schweik, Identifying success and tragedy of FLOSS commons: A
preliminary classification of Sourceforge.net projects, First International Workshop on
Emerging Trends in FLOSS Research and Development, p. 11. IEEE Computer Society
(2007);
[11] A. Wiggins
2010;
e K. Crowston , Reclassifying Success and Tragedy in FLOSS Projects, OSS
Pagina 186
SHARE IT AND BRING IT HOME: OPEN SOURCE, COMMONS
AND PIRATES
Cozzutto, Alessandro, University of Turin, Via Giolitti 33, 10124, Turin, IT,
ale.cozzutto@gmail.com
ABSTRACT
Mass endorsement of new information and communication technologies appears to outline, inside the
world-system, the surfacing of altogether innovative – and potentially democratic – political,
economic and socio-cultural relations, in the long run carrying from the binary language to the FOSS
movements and the “Web 2.0”
This study attempts to inquire into what, quite far from representing something new, appears instead
as the surviving of quite strict relational dynamics peculiar to modern age, in the passage from
techniques to technology and in the substitution of the pyramid with the symbolic representation of
power relationships.
The analysis focuses in particular on the concept of 'Commons', as emerging currency in particular in
the hands of the young actors which cooperate and compete, in a more comfortable way, within the
world wide web, as young were those who have been leading the information revolution.
The article finally examines, according to such analysis, the recent case of the Swedish 'Pirate Party',
first party among the under-30, which has been able to get a seat in occasion of the European
Elections of June 2009, by prompting awareness about issues like removal of copyright restrictions,
privacy of the internauts and free access to knowledge, but also thanks to the emotional wave
engendered in Sweden by the sentence to one year of jail for each operator of the site 'piratebay.org'.
The empirical side of the research focuses on a series of qualitative interviews with some
representatives of the German Pirate Party and an interview with Christian Engstrom, one of the two
members of the European Parliament for the Swedish PP.
In the transformation, in the resistances and in the new categories associated to the capitalist
historical system, new interesting outlooks for comprehensive social sciences are brought forth.
The conclusion of this work argues that “The world might get closer in the sense that rulers are likely
to look to each other more and more, independently from the state-nation they belong to, and folks
alike, but without linearity and with an unfaltering interaction between old (very old) and new, of
everlasting that comes back and of only one that does not matter, of ownership and power. Of
reactions, endurances and voids.
Will social sciences succeed, after getting rid of pyramid slavery, to clutch the fibre age before being
entangled in the web?”
Parole Chiave: Information, Open Source, Commons, Pirate, Ideology
Pagina 187
1. A MATTER OF POWER: THE INFORMATION REVOLUTION
AND THE MICROCHIP CAGE
“The mith of the eternal return states, by negation, that life disappears once for ever and it does not come back, it is like a shadow, weightless, it dies beforehand. Whether it was awful, beautiful, splendid, this dreadfulness, this beauty, this splendour mean nothing. (…) Let's point out therefore that the concept of the eternal return suggests a perspective wherein things don't appear as we knew them: they look without the mitigating factor of their transiency” (Kundera, 1987: 1314, author's translation).
Without the latter, indeed, things would appear in their repetition as they could not be and their dullness would be irreparable. This allows us to void them of the sensationalism which often accompanies novelties, to watch them with the needed detachment to better understand them: this is the difference between the 'eternal return' and the 'only one' that does not count. The growing mass adoption of new technologies of information and communication, of which the Web represents the most successful embodiment, is going to act on the whole of political, economic and social relationships inside the worldsystem at an exponential rate: new fresh methods of making politics, new young economic players, new interaction and dispute customs are breeding in the absolute space outlined by millions of computers wired to each other all over the world (Berra, 2007). The virtual dynamics brought about by that space, and the material ones conveyed into it, put more and more interesting questions to the several branches of the socalled social sciences. Because upstream of any impersonal algorithm, at the source of any set of guidelines a machine is asked to carry out without needing an interpretation, there was always a human will pursuing a well established goal (Marcuse, 1964), although tempered by chance. The acclaimed “The Cathedral and the Bazaar” by Eric Raymond (Raymond, 1998), esteemed as a summary of the theory, the spirit, the attitude at the root of the Linux project (but not, be careful, of the ideology87), supports the libertarian enthusiasm for the open source methodology. From this viewpoint someone even acknowledges the hacker ethics for the merit to have smashed down the steel mails of the capitalistic spirit accounted by Weber (Himanen, 2001).
On the contrary, not differently from previous social phenomena, this article argues, NICT concern power, how the search for (and the accumulation of) it proceeds, starting from which strength and knowledge relationships, it is a matter of how these relationships can be seized and eventually of how rallying the biases of whom, inside these relationships, turns out to be governed rather than governing above any historical determination.
Despite a sociologist of international reputation like Castells emphasizes that, historically, any society was founded on the shapes wherein information was spread inwardly (see how Gutenberg had a hand in the success of the Protestant Reform) and all economies are basically grounded on the codification of some type of knowledge, these two new paradigms, at the bottom of the information society, warmed up the heart of international public opinion just in the last years (Castells, 1996; May, 2002; Webster, 2002; Foray, 2006). Cfr. Cozzutto, A., Open source e ideologia, Creative Commons, available at the address www.dotduepuntozero.org.
87
Pagina 188
So, the information revolution, the last born in the family of power relationships, finds a synthesis of its own in the power relationships (Luhmann, 1982; MacPherson, 1973; Bixio, 1988). And it finds it despite the alleged death of ideologies, claimed more than thirty years ago (Bell, 1973), despite nobody has found out the corpse until now. As Robert E. Murrow, a CBS anchorman put it, “the nuisance with machines are men”. Trying to draft the world history in a few pages, the revolution which brought to the coming of a world information society would have not be achieved without the binary language: the German philosopher of the best of possible worlds, is strikingly impressed by the possibility, although quite remote at those times, to replace through reiterated combinations thought with computation, to devise a language in which any human manifestation can be abridged to two digits: “If we had that language” Leibniz states “we would be able to argue in the metaphysical and moral field in the same way we do it in geometry and calculus.”.
Next two centuries will witness a succession of scientific and philosophical innovations going along with the beginning industrial revolution: the Babbage's machine, Boole's algebra, Russell and Whitefield's Principia Mathematica, the progress in the field of physics, the invention of punched cards by Hollerith, the Turing's machine, the contributions by Shannon, Atanasoff, Zuse and other quaint characters who changed our life much more than we can figure out, but whose contributions kept unknown to the large public, at least as long as the reduction of the complexity in human thought to a computation object will begin to have remarkable matteroffact aftermaths, i.e. as long as the binary computation shows to be able to carry out its function when mostly needed: the world wars (Birrien, 1990; Ligonnière, 1987).
In 1984 a young computer programmer from the Massachusetts Institute of Technology, Richard Stallman, comes up with the project GNU and sets up the Free Software Foundation to working out a free operative system that would be devoid of the copyright restrictions dictated on the software employed in the universities (Williams, 2003). To prevent that his efforts would fall in the public domain, Stallman decides to force the dynamism of the Common Law, mostly because at that time it regulated the software (Hass, 2007: 213) and to construe the legislation about copyright in such a way to guard free access and implementation of software devised by his FSF: that's how the copyleft was born (Liang, 2004).
But for the information revolution to take place it is needed that the breakthrough elements inside the movement, the same logic of sharing and the same legal instruments (the copyleft) should be channelled toward an institutional pattern of computer development that would be devoid of the initial antisystem component. No big software firm of course would let be involved in a to death competition with the incipient Microsoft monopoly just to please the idealism of a fanatical although smart hacker. It is necessary a fortuitous event, time will complete the picture.
The fortuitous event occurs in the summer of 1991: a 21yearold Finnish student, Linus Torvalds, sets up a first rough version of a ' kernel' and asks the community of hackers in the web to help him in the implementation of his creature that he decides to share freely under copyleft: “Linux” was born. Pagina 189
But Torvalds was not Stallman. And he was neither Bill Gates: whereas the second one is inspired by libertarian principles and the latter by profit (see here), the young Finnish maintains that he is a hacker for fun alone. “Open source is about letting everybody play” (Torvalds in TorvaldsDiamond, 2001: 164) says the Linux inventor: everybody should contribute to the improvement of a program, freely and in spare time, regardless of his or her vision of the world (AA.VV., 1999; Levy, 1984). The achievements of the open source principle are anyway unrestrainable: they start in 1988 with the decision from Nescape, manufacturer of the Internet surfing browser “Mozilla Firefox”, the main competitor of Microsoft’s “Internet Explorer”, to issue an “open source” version of it; it keeps going with IBM, Sun Microsystem and Apple’s investments in the field; it is up to its climax with the “surrender” even of Microsoft and is concluded eventually with the announcement from Google to set up a wholly open operative system, starting from 2010.
The achievement of the open source movement, regarded as a technorepresentation of the libertarian and partly ideological instances of the free software movement, allowed that the technique accrued in several centuries of binary revolution would become technology (Musso, 2007), by crossing the wall of the computer alchemy reserved to the experts of the mathematical computation to embrace the wide space of the political, social and cultural relations in the whole (Latrive, 2004). The Web epitomizes this accomplishment in its passage from a release 1.0 to the 'usergenerated content' verbum of “Web 2.0” (O'Reilly, 2009)88.
We are supposed to trust the information revolution, as young spotless heroes did it, 'just for fun' (the title of Torvalds' autobiography). But more than giving the impression to break down the meshes of the old, very old steel cage 89, the coming of the fibre age seems to herald a microchip cage, less visible but not less sturdy. That is due to the increasing ability of the power relationships born with the fibre age to show up as new einmal ist keinmal with the mitigating circumstance represented by its own transience (MacKenzie, 2005). And not as the 'traditional' eternal return of appropriation and imposition of the strength and knowledge relationships and their relative bias. The question is concerned with how to do in order that anything would change so that things remain as they were, i. e. how to get on to manage a cutback of complexity that would rule out from its own sight what is perceived as unsuitable and unnecessary, a scaling down carried out for the purpose to succeed in working out a consistent account of the growing complexity of interdependence systemic relationships (WallaceWolf, 2000; Hirschman, 1991).
The Marxist scientific tradition is worthy for bringing struggle at the core of social sciences’ concern and uncovering the political unfairness resulting from uneven allocation of resources inside the Western economic system (Althusser, 1973; Mancina, 1986; Marx
Engels, 1982; Marx, 1974).
88
O'Reilly, T., Cos'è il Web 2.0, available on 10/10/2009 at http://www.awaredesign.eu/articles/14 CosWeb20.
89
This hope is traceable for instance in Himanen, P. Quoted Work, pp. 1011; o in Feldman, M.P., La révolution d'Internet et la géographie de l'innovation, in Foray, D., et al. ., Quoted Work.
Pagina 190
If money is needed to purchase items and services in the material world yet it does not seem a satisfactory ruling tool in the fibre age. In the Web the only universally customary currency (to purchase items and services prized in the Web only, beware) is not the economic reward as much as the visibility: “..the question is, if you post information on the Web, will anybody notice it?" (Barabasi, 2002: 57).
Barabàsi demonstrated the applicability to the web of the Pareto’s law, socalled of the ratio ’80/20’, accounting for the intrinsically oligarchic nature of any social construction, like the success of Google seem to confirm (Gruppo Ippolita, 2007). The main factor of demurral on a massive postindustrial web are skills and big numbers: the movement for free software succeeded in digging into the rock of the proprietary development by virtue of the notable computer mastery of thousands of its collaborators. Turning to the open content, what is inescapably called for to groups, single individuals and associations with democraticsolidaristic purposes is a mighty tutoring in the field. Which entails a strong differentiation in skills. Which sends back as it could not be otherwise to the network organization: a complex geography of variously sized conglomerates of a transnational character, present on the field and in the capacity to relay their experience in the shape of information and imagines on the global circuit. An uneven and disorderly network apt to cluster together the efforts in sight of restricted skirmishes with a high symbolic value and doomed to pay (it could not be differently) for the lack of a coordinated strategy and a firmness customary of political democratic phenomena of an industrial type.
More than a “worthwhile” force of an alternate political template (Crouch, 2005), an “oppositive” force of bias rebuttal, of which Pierre Rosanvallon was able to pinpoint the noteworthy “counterdemocratic” features with much smartness (Rosanvallon, 2006). The aftermaths of such a kind of resistance can vary but are never conclusive: the complex and systemic interdependence sets the better managed and trained groups all the time on the cutting edge, under the technical and coordinative point of view, in comparison to those who pursue generalist interests (La DueHackfelt, 2008). Nonetheless these results can be remarkable and look like a relentless reshaping process, in a redistributive purport, of the whole system by means of particular achievements and on a local scale, about specific issues and following burdensome sensibilisation efforts (Wellman, et al, 1996). 2. THE COMMONS: ‘SHARE AND BRING IT HOME’
So then what would be the weapon, the bargaining power of these young generations of antisystemic drives, of disinherited and even childless outcasts, which the ploy, the political commitment to oppose to a world with no more remainders of divinity? The British thinkers of the Seventeenth Century had as first pointed out (Hobbes, 1965; Locke, 1997), as a key element of the age that would be later called Modern, the rise of an evolutive process in the society where they lived, called by the Canadian historian MacPherson possessive individualism. “The society is comprised of exchange relationships among owners. The political society turns to a contrivance engineered to the purpose of defending this ownership and safeguarding an orderly exchange relation” (MacPherson, 1973: 23).
Pagina 191
In the fiber age the political enforcement which shapes the newfangled entrepreneurial models and the novel knowledge systems against the second wave of “enclosures” now in progress in the cyberspace (Cahir, 2004: 619), says: “Share and bring it home.”
The real bedrock (but not necessarily a material one) of this political enforcement is comprised of the socalled shared assets, the “Commmons”. The Commons are not public assets or at least not exactly so: the public assets abide by the principles of norivalry and no
exclusiveness in their use (Ibidem: 620621). The assets stored in a digital form, as they can be copied and multiplied without restrictions, assuredly enjoy the first principle, like bread and fish in Jesus Christ’s hands: they can be software (Linux, software GNU, Joomla), knowledge systems (see Wikipedia) or of exploitation of knowledge (see Creative Commons), multimedia (see Pirate Bay, Current Tv), literature (see the collective Wu Ming or the enterprise ‘libreremo’), essays and scientific investigation (see aperto.unito.it, dotduepuntozero.org) [Cheliotis, et al.. 2007].
The mechanism goes ahead like this: as I cannot hinder the circulation of my knowledge, in a digital format on the Web, I autonomously decide to grant it in sharing in order to prompt others to do the same. These sets of knowledge in the Web’s boundless space land up to lose their own utilitarian features in a strictly economical meaning (in fact I cannot cash in commercially on the literary works implemented on Internet in copyleft) and look like shapeless stacks of data from which further knowledge can be drawn.
Where then the falsificability of the phenomenon relies (Popper, 1970)? It lies on the circumstance that the noexclusiveness of its use, granted de jure with free circulation, fades away de facto, making the shared assets different from the public ones: the free availability of so much knowledge just does not grant me assuredly to develop, on my turn, further utilitarian elaborations. It is compulsory to know what to add in, in order to afford the right “to carry home” what others have shared. Because in the autogenerative Internet universe (Zittrain, 2006), which much echoes some of Luhmann’s intuitions (Luhmann, 1978; Id., 1986), more than the sum of its parts is at stake. As the information of which there is plenty on the web are economically unprofitable by themselves, the awareness only in the use of the new technologies allows the finetuning of young entrepreneurial models, innovative knowledge systems or new forms of political representation apt to trigger profit chances. The compound of the Commons broaden therefore the range of possibilities as well as that of complexity, brings about inflation of knowledge and more than that: what it promises to the smartest and more creative fellows is not as much an economic fulfillment, as rather a currency needed to stand out in an environment so leveled out on identical patterns, enforceable for everybody (at least according to the universalist bias) but only abstractedly: Linus Torvalds, today a billionaire, did not stockpile his fortune from the development of Linux but from the consultation work he was called for as soon as his computer skills were established worldwide.
Whereas in the strictly computer field the power relationships are liable to match factual knowledge relationships, in the politicalelectronic area it seems that bias plays a determinant role.
Pagina 192
In the fiber age by means of the Commons it is possible for thousands and thousands of young programmers, researchers and artists to put on conditioned sharing practices, freely bred in the web or freely put in sharing, democratic practices fostered in the real world. And in such a manner succeed in accruing a bias liable to sway on the silent majority so that the approval pointers shift to the direction suitable to the involved economical, ethnic or cultural minorities (see the case study in the following paragraph 90).
The concept of Commons in the meaning of collectively owned assets ever since played a protagonist role in the scientific and technological development of the historic capitalist system (Nelson, 2003: 1691). Nevertheless to bring it out negatively in contemporary scientificsocial epoch was a 1968 article by Garrett Harding, in an emblematic way entitled “The tragedy of the Commons“, where the author argued in support of the rhetoric of reaction according to which “too much freedom kills freedom” (Hardin, 1968: 1244).
The yardstick by which, within the digital space, Hardin’s grievance can be finally rejected, is given by the circumstance that the reproduction cost of the information (Ignatin, 1992). The issue here discussed attracted much academic attention, mostly in the juridic field, due to the mass copyright infringements that the new technologies have forwarded (Jensen, 2003). What Cahir names the “internet information commons” is in fact the distinguishing imprint of the entrepreneurial templates and knowledge systems developed by the web: “…it embraces the decentralized communicative architecture of the Internet. (…) In the respect of the informational resources, the commons represents an effective, and sometimes superior, model for organizing social access and use.” (Cahir, 2004: 641).
But although, the Commons might represent an einmal that is keinmal, a single which does not matter, what we were eager to point out in this study – after accounting for the discussion terms – was rather the eternal approach of dynamics all too often greeted as the new that would turn upside down the epistemological order of material as well as immaterial relations on this planet (Hirschmann, 1991; Pala, 1984: 9; Gramsci in Santucci, 1997: 49).
The young heroes of the information revolution, yesterday governed and tomorrow's governors, sharing commons and visibility on the web, are in the middle of the long way (much longer than any techodeterminism might argue) that separates freedom from and right to. The reduction of such distance, although Leibniz would not agree, embodies a daily conflict rather than a reckoning (Schattschneider, 1998).
Given such a long and complex background – the young and fresh electronic forms of sharing, within the context of eternally returning power relationships –, let's draw some actual application, with respect to those entrepreneurial models, systems of knowledge or forms of political representation we were talking about before.
Cfr. Antonucci, G., I pirati fanno rotta verso Strasburgo, in "Corriere.it", 4th of May 2009, available on 6/5/09 here.
90
Pagina 193
3. HERE COME THE PIRATES!
The recent indictment case of the Swedish pirate bay (‘piratebay.org) is of paramount importance either to surmise more clearly the most momentous aftereffects in our study area, or to clear the field from some misunderstandings that media hype managed around the delicate issue (MiegelOlsson, 2008; Demker, 2008; Firth, 2009).
Scandinavian countries, for reasons that can be glossed over in this article (see European Information Technology Observatory 2004 Report ), are marked out ever since for a cutting edge and homogeneously spread use of the new infocommunication technologies. Just think of the aforementioned Linus Torvalds, the Finnish inventor of the ‘Linux’ kernel, a token of the liberal creativity at the root of the release 2.0 of the world wide web.
There is not to wonder if in this mood of sparkling approach to the mass use of the NTIC, a bunch of Swedish artists and intellectuals established a think tank on the issues of information and knowledge sharing within a digital system. This group, ‘ Piratbyran ‘, sets itself the aim to uncover to the national public opinion the reasons of those who do not share the media criminalization of the socalled pirates. Therefore it masterminds several collateral blueprints aiming to found on practice its own theoretical reasons. So it is started on 11/21/2003 the free and without charge torrent files portal ’The Pirate Bay’, at the web address http://www.piratebay.org (Neri, 2009).
In a few words , this site is a boundless binder of torrent files, a specific tipology of peertopeer files (P2P, i.e. exchangeable from free user to free user, ‘from peer to peer’, files which as a rule but not necessarily are multimedia: music, video but also documents and software (Christin, 2010). By the intermediation of the pirate portal, the users are able to get in touch with and share the contents stored in their own computers. But, and this is a fundamental difference, the shared files do not proceed through the server of the concerned site. A task, besides, supplied by any research engine , like Google. With the difference that the Pirate Bay is exclusively committed to the retrieval of torrent files. That was enough for the Swedish justice to convict in the first degree the site managers. Yet this is not the reason of the interest that, as it is maintained, social sciences should foster in regard of enterprises like this. Which or what, then?
Weighing up the wholehearted comments of partakers to the “pirate bay” forum, the reason why millions of customers have opted for this site (among the many suppliers of torrent files, free or to pay, around the web) in such a measure to let it skyrocket to the threshold of the one hundred more visited sites worldwide 91, got either roots or fruits of a political nature.
The roots are that technolibertarian culture which joins Stallman, Torvalds and the creators of the bay: Fredrik Neij, 30 years, Gottfrid Svartholm, 24, Peter Sunde, 30. The ingredients of the information revolution are not the ‘subversion’ as an end to itself. The ‘pirates’ found their way to the heart of the internauts thanks to the blend of antisystemic libertarian spirit, stateoftheart technology and personal avail quintessential of the radical 22 millions of users, with 6 m. of daily contacts, according to the estimation of alexa.com, the website reaches the 106° place among the most visited, collecting the 50% of the p2p traffic. Cfr. Magrini, M., Un anno di carcere
ai pirati del web, in "Il Sole24ore", 04/18/2009, p. 6.
91
Pagina 194
culture on the web. The free availability of sources, the internationalist language of young programmers, the sleepless nights spent to hone the serviceability or the graphics of an implementation convey that ‘destructive creativity’, to say it reversing Schumpeter (Schumpeter, 1950: 83), which historically marks off the capitalism to the umpteenth power (Rothbard, 1962).
It is not by chance that the founder of the Pirates Party, Richard Falkvinge, claims to be: “a radical capitalist, to the bitter end supporter of free market and sworn foe of the monopoly epitomized by that cultural industry that – made outofdate by the new technologies of information and knowledge distribution – strives for survival on a purely legal way, prompting the government to prosecute the fellowconsumers who embrace the new fashions of availability of music, video and texts. We are not red, blue or green, we are just pirates”92
It cannot be really assessed a sheer 'antiideological' approach, granted that envisaging an electronic society where the acceptance of free circulation of information is formally avowed brings about a well defined technologically deterministic Weltanschaung (Phillips, 2009: 451): “Antiideological? I would say quite the contrary, we are extremely ideological. We stand up for values that we believe are important in a society and we are prepared to leave deciding the exact level of taxing or childare or healtcare or whatever to other people, so we can focus on standing up for the values we think are important. So, I'd say quite the opposite” (interview with C. Engstrom, Brussels 04/16/2010, available on Dot 2.0 account on Youtube) It is unquestionable that we are in front of an updating of a certain liberalliberist
libertarian spirit, a transnational ‘virtue’ party at odds with the greed of monopolist manufacturers, outofdate borgeois new rich (Demker, 2009). Instead what appears meaningful is the transversal appeal to a ‘monothematic’ program – the replacement of copyright international laws in force (about file sharing but also about the ticklish issue of the electronic privacy) and the abolition of monopolies in the information and show business industry – of political impact and immediate implementation: “In providing platforms for sharing and for voicing dissent towards the established entertainment industry, the increasing autonomy gained by these piratical actors becomes more akin to the concept of ‘positive liberty’ than to a purely ‘negative,’ reactive one.” (Andersson, 2009: 64).
Standing as a candidate at Swedish political polls in 2006, attaining no more than 0.63%, corresponding to about 34.918 ballots (Demker, 2008: 17), the Pirates Party is successful93 in availing itself of the emotional wave prompted by the conviction on 4/17/2009 of the three Pirate Bay founders to a oneyear jail term and €675,000 fine for each of them 94. A wave made even more emotional by the news spread around that one of the justices of the first grade bench, Tomas Nostrom, was allegedly member of more than one of manufacturer organizations for copyright protection95.
In Formenti, C., Svezia, alle elezioni il Partito dei Pirati, in "Corriere della sera", 01/17/2006, p. 27.
Sjoden, K., Swedish Pirate Party Doubles in Size After Bay Verdict, retrieved May 20, 2009, from Wired, available at http://www.wired.com/threatlevel/2009/04/swedishpirate.
94
Gualerzi, V., 'Carcere agli hacker', Pirate Bay perde la guerra del copyright, in "La Repubblica", 04/18/2009, p.
21.
95
Cfr.Adinolfi, M., La baia dei pirati adesso è a Strasburgo, in "Europa", 06/10/2009, p. 7.
92
93
Pagina 195
At the polls for Brussels/Strasbourg Parliament, after hitting per cent peaks of 8 and 9, Falkvinge’s Pirate Party earns at the polls a surprising 7.13 % (see here), enough for the election of Christian Engstrom, fiftyyearold software entrepreneur, to the benches of the legislative European Assembly (but with the ratification of the Lisbon Treaty and allocation of national delegations, the seats have become two, with the 27yearold Amelia Andersdotter's nomination). Although matteroffactly it can be assumed that the piracy glee will not survive to long times of politics (and to passages of bills that a complex subject such as copyright in the international law calls for) what is more striking in the Swedish experience is concerned with the spacetime coordinates of nowadays politics: the speed with which the pirate party moved forward from secrecy to parliamentary presence (time compression) and the allure it was able to trigger internationally since onset (space extension, see) to the point to have already several copiers in more than 40 European or otherwise countries (see piratepartyinternational.org): “Trying to get elected, as a Swede, … it make sense to focus, when it comes to be elected, to focus nationally. But now that I'm here I see me as representing pirates from all over the world, it is a global movement, Internet is truly global.
So in a way I see myself more like perhaps representing the Internet than representing Sweden. Every country that has a pirate party was grassroots in that country, felt 'yes, we should have one here as well!'. But the funny thing is that, although we have very little actually contacts between the parties, what we find is that when one party pops up in different countries they all have lots of internal discussions, but then they end up with virtually identical programs in every single country..” (interview Engstrom, quoted). Although in Brussels lobby pressure from entertainment business surely comprises more advocates than libertarian pleas, so that the party could find recovery, and this is no accident, in the parliamentary group “European Greens – Free European Alliance” (48 congressmen in 1999, 43 in 2004, 55 in 2009), the belief is that more and more patent economic grounds will enable some of them to break through as it seems to be partly substantiated by the success of the ‘German unit’ of the party (2.1 % of votes at 9/27/2009 federal elections). The several representatives of the German PP, I have been talking to in Berlin and Hamburg, described me the evolution of the heterogeneous movement against data retention since 2006. Fabio Reinhardt, from one of the 'crew' of the capital, confirmed me the amount of 12 thousands of official 'pirates', quite spread around the country and their various, although generally young, composition. He told me about 'LiquidFeedback', an Internet program which allows the pirates in Berlin to have access to the decision process, by posting proposals and exerting surveillance to the work of the district boards. Simon Lange, press officer in Berlin, revealed his enthusiasm about the future elections and the ability of the party to manage, through free discussions, the problems that a growing movement is supposed to face. He's quite sure the PP will reach the German Parliament soon, and optimistic about being part of a future government. Michael Voeckler, member of the board in Hamburg, where the party got between 3 and 10% at the federal elections, thinks “pirates are very different in the way politics is made, we are absolutely based democratically, everything is made from the base. The members of the party are doing all the politics. (…) Some Pagina 196
members have an idea, they try to convince others and they make something, this idea spreads by a mailing list, by the forums and other ways of communication..” (interviews with the German pirates, April 2010, soon available on Dot 2.0 account on Youtube).
This is the eternal return, the sensible element to single out among the unique events that from the Pirate Bay’s file sharing lead to the Pirate Bay’s success at the European elections: grassrooted political behaviors able to exert a bargaining power on as circumscribed issues as possible (about which the majority of Eurocongressmen coming from traditional political families got little or nothing to say) from young and unusual, if not unlikely, political players. Political action as a rowdy byproduct of underground cultures of international clout, politics submitted to the media with which these rising players fulfilled their first socialization, rather than media submitted to traditionally regarded politics (McLuhan, 2003; Luhmann, 2000). And above all the measureless value of the Commons, universally available assets the usefulness of which is however subject to the awareness with which they are handled, innovated and subjugated to specific political goals: “And this may well be one important explanation of the rapid success of Piratpartiet. It is basically a bottom
up movement, starting from young people’s actual behavior and circumstances, and it became politically significant for them when those interests clashed with the established norms and rules of society.” (MiegelOlsson, 2008: 212). “So there is a need for new business models that take into account the changing needs of the customer as well as the current and future technological developments.” (Parakkal, 2009: 5).
What have the bay pirates shared in common? Not the multimedia files but a simple and fetching graphic interface that would allow its customers ‘to carry them home’. What did the ‘piratebay.org’ managers bring home, besides a conviction? The renown of champions for free access to knowledge but also the €5.000.000 that the software manufacturer “Global Gaming FactorX” shelled out to purchase their creature ( see). What did the ‘Pirate Party’ managers partake in and what do they obtain? “When I blog something that's happening in this House or what the Commission is doing, I get a lot of positive comments saying 'Wow, it's the first time I have voted for somebody and really feel I got something from my money', so to speak. It's so great to have direct information from what it's happening. And in the other way as well, when issues come up, I'm obviously not an expert on everything in the world and I'm not an expert on everything within the information politics either. So, that means when issues come up, I can simply present 'the Commission has presented this paper and asked the Parliament to give an opinion, please tell me what you find in it, tell me what to think about it!” (interview Engstrom, quoted).
CONCLUSIONS
The political and social actors just mentioned, as they could not apply any force relationship, fell back to their own knowledge, exploiting the most unpredictable means, yet the simplest and cheapest of those available, in order to attain the foreshadowed goal: either if at stake it was to defend a hackerlibertarian culture or compete for election in the European Parliament or share a vintage jazz album with a totally unknown buff peer.
Pagina 197
But the implementation of a however tiny political power, proceeding from a bench in Brussels/Strasbourg, kept asking for, just as before the fibre age approach, the rally of a strong bias in the everlasting modern clash between friends and enemies (Schmitt, 1988).
Despite growing chatting of new technologies is better than not talking at all, the impression is that excessive racking of brain about the einmal that is keinmal, the only one that politically does not matter, brings instead to overlook the ever since political feature not of the technique in itself but of political and social aftermaths of its mass use.
Although the several PP popped up around the world almost simultaneously, the success of the Swedish one at the European elections and the intrinsic transnational nature of the Web, the German pirates regard national engagement as the more effective strategy. Engstrom agrees. Some specific instruments ('liquid feedback' or the way the MEP says he and his electors take profit from his blog) seems to improve transparency and accountability. But the impression is that, once we leave the technical field of net politics, we are still far from a substantially renewed decision process or model of representation.
In the occurrence of relentless and noteworthy innovations, technical and social experiments and unusual technological formalisms, is therefore compelling and this is the ultimate meaning of the present article – to focus on the pivotal content and the existential aftermaths but most of all on the political meaning of the tangled dynamics, the intricate mechanisms and the power relationships ruling social life on earth: “..many investigations of the nature of filesharing networks show that relatively few users contribute new, unique content to the networks, and that many more download material without actually contributing anything to any considerable extent.” (Andersson, 2009: 82).
When I met the German pirates, they were working on the most important regional elections in the country, those of NorthernWestfalia, one of the most populated and rich 'land'. The expectations were high, but the 1,5% collected represents an inversion in the trend of the young political formation. When I asked Mr. Engstrom about the risk of 'institutionalization' for his party, he answered: “Of course, we can't! When an organization is new, be it a company or a movement or whatever, then everybody is idealistic about it. But then as the decades go on, more and more people tend to become more interested in the survival of the organization than the original purpose. It happens to every political party that's been around for a long time and I'm sure it will happen to us, as well, unfortunately. It doesn't really matter to me, because by that time I will have left politics anyway!” (int. Engstrom, quoted).
Echoes of what has been discussed: Pareto's law, pyramid and commons, governors and governed, eternal return and keinmal einmal.
In the passage of power from technique to technology, the importance of the “copyleft sharing practices” is and will continue to be (even with still different shapes) pivotal because in favour of the concepts of Commons it sways on the proprietary definition of the game rules in the fibre age. And the concept of ownership, differently put forward, is the modern ground of the Western route to politics (CoombeHerman, 2004: 562).
Copyleft has been in other words a key issue in pointing out economical and juridical benchmarks which are the bedrock in the free circulation of web informations for the success. Authorship acknowledgement in all licenses, for instance those labelled “Creative Commons”, is actually the only default yardstick, i.e. the only mass yardstick common to all license Pagina 198
types: maybe the claim of I against the growing Weberian disenchantment for a more and more global world.
The world might get closer in the sense that rulers are likely to look to each other more and more, independently from the statenation they belong to, and folks alike, but without linearity and with an unfaltering interaction between old (very old) and new, of everlasting that comes back and of only one that does not matter, of ownership and power. Of reactions, endurances and voids.
Will social sciences succeed, after getting rid of pyramid slavery, to clutch the fibre age before being entangled in the web?
References
AA.VV. (1999). Open sources, voci dalla rivoluzione OS. Milano: Apogeo Ed.
Althusser, L. (1973). Pour Marx. Paris: François Maspero.
Andersson, J. (2009). For the good of the net: the Pirate Bay as a strategic sovereign. Culture
Machine, vol. 10, 64-108.
Barabàsi, A.L. 2002. Linked, the new science of networks. Cambridge (Massachusetts):
Perseus.
Bell, D. (1976). The coming of post-industrial society. New York: Basic Book inc.
publishers.
Benkler, Y. (2006). La ricchezza della rete. Milano: Ed. Bocconi. First and second parts here.
Berra, M. (2007). Sociologia delle reti telematiche. Bari: Laterza.
Birrien, J.Y. (1990). Histoire de l'informatique. Paris: Presses Universitaires de France.
Bixio, A. (1980). Proprietà e appropriazione. Milano: Giuffrè Ed.
Breton, P. (1987). Histoire de l'informatique. Paris: La découverte.
Cahir, J. (2004). The withering away of property. Oxford Journal of Legal Studies, 24 (4),
619-641.
Castells, M. (1996). The information age: economy, society and culture. Oxford: Blackwell,
vol. I.
Cheliotis, G., Chik, W., Guglani, A., Kumar Tayi, G. (2007). Taking Stock of the Creative
Commons Experiment. National Center for Technology & Law, George Mason University
School of Law.
Christin, N. (2010). Peer-to-Peer Networks: Interdisciplinary Challenges for Interconnected
Systems, in Dark, M.J., (edited by), Information Assurance and Security Ethics in
Complex Systems, IGI Global.
Coombe, R.J., Herman, A. (Summer, 2004). Rhetorical Virtues: Property, Speech, and the
Commons on the World-Wide Web. Anthropological Quarterly. Vol. 77, No. 3, 559-574 .
Crouch, C.(2004). Postdemocrazia. Roma-Bari: Laterza.
Foray, D. et al (edited by, 2002) La société du savoir. Revue Internationale des Sciences
Sociales, 54, 1/171, 13-24, Paris, UNESCO..
Demker, M. (2008). A New Era of Party Politics in a Globalised World. The Concept of
Virtue Parties. QoG Working Paper, 20.
Firth, C. (November 2009). Pirate Politics. The Nation Reviewed, 18-19, available here.
Foray, D. (2006). L’economia della conoscenza. Bologna: Il Mulino.
Gramsci, A., in Santucci, A.A., (edited by, 1997). Gramsci, le opere. Roma: Ed. Riuniti.
Hardin, G.(1968). The tragedy of the Commons. Science, New series, vol. 162, n. 3859,
1243-1248.
Pagina 199
Hass, D.A. (Spring 2007). A Gentlemen's Agreement Assessing the Gnu General Public
License and Its Adaptation to Linux. Chicago-Kent Journal of Intellectual Property, vol. 6.
Himanen, P. (2001). L'éthique hacker et l'esprit de l'ère de l'information. Paris: Exils.
Hirschman, AO. (1991). Retoriche dell'intransigenza. Bologna: Il Mulino.
Hobbes. T. (1965). Il Leviatano. Torino: Unione tipografico-ed. Torinese.
Ignatin, G.R. (1992). Let the Hackers Hack. University of Pennsylvania Law Review, 140
(5), 1999-2050.
Jensen, C. (2003). The More Things Change, the More They Stay the Same: Copyright,
Digital Technology, and Social Norms. Stanford Law Review, 56 (2), 531-570.
Kundera, M. (1987). L'insoutenable légèreté de l'être. Paris: Ed. Gallimard.
La due, R., Huckfelt, R. (2008). Social capital, Social networks, and political participation.
Political psychology, 19 (3), Special Issue: Psychological approaches to social capital,
567-584.
Latrive, F. (2004). Du bon usage de la piraterie. Paris: Exils Ed.
Leibniz, G.W. (1992). Scritti di logica. Roma-Bari: Laterza, vol. I-II.
Lessig, L. (2004). Culture libre. French version available here.
Levy, S., (1984). Hackers, heroes of the computers revolution.Stephen Levy, chapters 1 and 2
available here.
Liang, L. (2004). Guide to Open Content Licenses. Rotterdam: Piet Zwart Institute.
Ligonnière, R. (1987). Préhistoire et histoire des ordinateurs. Paris: Ed. Robert Laffont.
Locke, J. (1997). Deux traités du gouvernement. Paris: Vrin.
Luhmann, N., (1982). Potere e codice politico. Milano: Feltrinelli, 21-61.
Luhmann, N. (1978). Stato di diritto e sistema sociale. Napoli, Guida.
Luhmann, N. (1986). The Autopoiesis of Social Systems, in Geyer, F., Van der Zouwen, J.,
(edited by), Sociocybernetic Paradoxes. Sage: London, 1986.
Luhmann, N. (2000). The reality of the mass media.Cambridge: Polity Press.
MacKenzie (2005). Un manifesto hacker. Milano: Feltrinelli.
Macpherson, G.B. (1973). Libertà e proprietà alle origini del pensiero borghese. Milano:
Isedi.
Mancina, C. (1986). Marx e il mondo contemporaneo. Roma: Ed. Riuniti.
Marcuse, H.(1964). One dimensional man. London: Routledge & Kegan Paul Ltd.
Marx, K., Engels, F. (1982). L'idéologie allemande. Paris: Ed. Sociales.
Marx, K. (1974). Il capitale. Roma: Editori Riuniti, book 1, vol. II.
May, C. (2002). The information society: a sceptical view. Cambridge: Polity.
McLuhan, M. (2003). Understanding media, the extension of man. Corte Madera: Gingko
Press.
Miegel, F., Olsson, T. (2008). From pirates to politicians, in Carpentier, et al. (edited by).
Democracy, journalism and technology: new developments in an enlarged Europe. Tartu
University Press, 203-216.
Musso, P. (2007). L’ideologia delle reti. Milano: Apogeo Ed.
Neri, L. (2009). La baia dei pirati. Roma: Cooper.
Nelson, R. (2003). The Advance of Technology and the Scientific Commons. Philosophical
Transactions: Mathematical, Physical and Engineering Sciences, 361 (1809), 1691-1708.
Pala, G. (1984). Il nano e l'automa nel corso del tempo. Roma: Kappa.
Parakkal, M. (2009). Digital piracy, a special focus on the economic perspective. Univ. of
Wien, 2009, here.
Phillips, J. (2009). It’s my party and I’ll cry if I want to. Journal of IP Law & Practice, 4 (7).
Pagina 200
Rapport mondial de l’UNESCO (2005). Vers les sociétés du savoir. Paris: UNESCO Ed.
Available here.
Raymond, E. (1998). La cattedrale e il bazar. Italian version available here.
Rosanvallon, R. (2006). La contre-démocratie. Paris: Éd. du Seuil.
Rothbard, M.N. (1962). Man, Economy, and State. Princeton: Van nostrand.
Schattschneider, E.E. (1998). Il popolo semisovrano. Genova: Ecig.
Schmitt, C. (1988). Théologie politique. Paris: Ed. Gallimard.
Schumpeter, J.A. (1950). Capitalism, socialism and democracy. New York: Harper &
Brothers.
Sombart, W. (1926). Le bourgeois. Paris: Payot.
Stallman, R. (2003). Saggi scelti. Viterbo: Nuovi equilibri. Available here.
Torvalds, L., - Diamond, D. (2001). Just for fun, the story of an accidental revolution. New
York: Texere.
Wallace, R.A., Wolf, A. (2000). La teoria sociologica contemporanea. Bologna: Il Mulino,
chap.II, 27-80.
Webster, F. (2002). Theories of the information societies. London: Routledge.
Wellman, B., et al. (1996). Computer networks as social networks. Annu. Rev. Sociol., 22,
213–38.
Williams, S. (2003). Codice libero. Milano: Apogeo Ed..
Zittrain, J.L. (2006). The Generative Internet. Harward Law Review, 119, 1974-2040.
Pagina 201
1
Riunioni Digitali
Daniel Donato, e Università degli Studi di Salerno, Fisciano, ddonato@unisa.it
Marcello Di Gugliemo, Associazione Intellicom, marcellodgl@gmail.com
Keywords: Sviluppo Software, Riunioni Digitali, Multimedia, Collaborazione
Summary. Scopo di quest’articolo è descrivere il progetto RD (Riunioni Digitali) sviluppato dall’associazione Intellicom. RD è un sistema libero per tenere riunioni on line proficue
almeno come quelle in presenza. Per raggiungere questo ambizioso traguardo, RD integra tecnologie libere sia web based che desktop based. In questo articolo, dopo una breve panoramica
sul sistema in generale (descrizione funzionale del sistema), ci focalizzeremo, in particolare,
sulla struttura del client Sacks (licenza GPL v.3). Immaginando che il lettore possa essere interessato a cimentarsi nella realizzazione di un’estensione, accanto alla descrizione dell’albero
classi del client saranno fornite indicazioni a questo fine.
1.1 Introduzione
La realizzazione di riunioni on line è stato un sogno di molti ricercatori fino dagli
anni ’60. Nella famosa presentazione del sistema NLS, Doug Engelbart all’Augmentation
Research Center dello Stanford Research Institute ha mostrato un’implementazione
di ciascuna delle tecnologie necessarie a raggiungere questo ambizioso obiettivo. Al
1968 la fattibilità tecnica è sembrata essere stata raggiunta. Grazie all’ampia diffusione dei personal computer, delle tecnologie di compressione audio-video, e al
capillare sviluppo della banda larga questo modo di lavorare potrebbe essere alla
portata di un ampio pubblico. Sono infatti ampiamente diffuse le tecnologie hardware necessarie a rendere possibile le riunioni on line e la maggior parte delle tecnologie software è rilasciata con licenze libere. Ciò nonostante, sono ancora pochi
sia gli individui che le associazioni, le imprese e gli enti pubblici che beneficiano di
questa possibilità. A 32 anni di distanza, il settore delle riunioni on line, nonostante
le possibilità tecniche, non esprime ancora a sufficienza la sua potenzialità.
1.1.1 Descrizione dell’idea
Le piattaforme per riunioni digitali attualmente presenti sono strutturalmente distinguibili in due tipologie: web-based e desktop-based. Caratteristica peculiari della
Pagina 202
2
Authors Suppressed Due to Excessive Length
piattaforma (RD), su cui daremo supporto, è quella di integrare il meglio delle tecnologie web based (un sistema di scrittura collaborativo basato su Mediawiki, la piattaforma di gestione dei contenuti Drupal, il server di streaming VLC) con il meglio
delle tecnologie desktop based come (le librerie qt, l’ambiente e gli applicativi di
KDE e VNC) in un sistema integrato e multipiattaforma. La perfetta integrazione
dell’approccio web based e quello desktop based è ciò che differenza e rende innovativo il software su cui daremo supporto. Il nostro servizio di supporto e assistenza
su RD si differenzierà da tutti gli altri perché il nostro sarà l’unico tenuto dagli sviluppatori ufficiali del software; inoltre il nostro servizio sarà l’unico che potrà utilizzare
il logo ufficiale di RD.
1.1.2 Descrizione del percorso
L’idea di realizzare un sistema per riunioni digitali è nata nell’ambito di Adunanza
Digitale. Adunanza Digitale è consistita in una serie di assemblee distribuite che si
sono tenute
in Italia a partire dal 2006. Si è trattato di una sperimentazione socio-tecnologico
(Donato e Napolitano, 2007). L’assemblea si è articolata in una serie di tavoli di
discussione che sono stati organizzati da diverse associazioni nelle seguenti città:
Caserta, Napoli, Salerno, Trieste, Padova, Vigevano (PV), San Giorgio a Cremano
(NA). La partecipazione a ciascun’assemblea è stata resa possibile sia alle persone
in loco che a tutti gli utenti di Internet. Quest’esperienza ha portato alla maturazione
della consapevolezza che l’ecosistema del Software Libero è in grado di offrire tutti
gli strumenti necessari alla realizzazione di un’assemblea digitale. Nonostante ciò,
la realizzazione di una riunione digitale continua ad essere un compito assolutamente non banale. Quello che manca è un software accessibile e usabile che integri tutte le diverse funzioni. La realizzazione di questo progetto mira a colmare
questa mancanza scrivendo un software che renda l’utilizzo di tutte queste tecnologie fruibile. Abbiamo deciso dall’inizio, non solo di voler realizzare questo software
come software libero, ma anche di volerlo concepire in modo tale di essere adatto
all’ecosistema del Software Libero.
1.2 Descrizione funzionale
In questo sistema, per convenzione si stabilisce: l’utente che convoca una riunione
nè sarà anche il chair.
1.2.1 Alcuni giorni prima della riunione.
1. Per indire una riunione (ed essere chair).
• Ammettiamo, per esempio, che l’utente P ippo vuole indire e moderare una
riunione sullo stato dell’agricolutra nel terzo mondo dal titolo: L’ipocrisia
della Green Revolution.
Pagina 203
1 Riunioni Digitali
•
•
•
•
3
L’utente P ippo si iscrive sul sito web (http://riunionidigitali.net).
L’utente P ippo crea la riunione L’ipocrisia della Green Revolution, inserendo titolo, ora di inizio fine e una breve descrizione. (L’utente riceve
una mail di conferma dell’avvenuta prenotazione)
Lo staff di riunionidigitali decise se accettare la riunione L’ipocrisia della
Green Revolution. (saranno accettate tutte le riunioni tranne quelle con contenuti manifestamente contrari ...)
Se l’utente P ippo riceve una mail di conferma dell’accettazione della riunione L’ipocrisia della Green Revolution, da quel momento l’utente P ippo
è il chair della riunione L’ipocrisia della Green Revolution.
Fig. 1.1. L’interfaccia web per proporre una riunione
1. Per partecipare ad una riunione indetta da altri (senza essere chair).
• Ammettiamo, per esempio , che l’utente pluto voglia partecipare alla riunione indetta da P ippo sullo stato dell’agricolutra nel terzo mondo dal titolo:
L’ipocrisia della Green Revolution.
• L’utente P luto si registra al sito web (http://riunionidigitali.net), nello stesso
identico modo in cui si è registrato P ippo.
• Dopo che lo staff avrà autorizzato la riunione indetta da P ippo, l’utente
P luto troverà sul calendario gli estremmi della riunione indetta da P ippo.
• L’utente P luto può iscriversi alla riunione. Dopo l’iscrizione alla riunione
P luto riceverà una mail di conferma dell’avvenuta registrazione.
A questo punto sia P ippo che P luto possono scaricarre, installare e autenticarsi utilizzando il client Sacks (http://riunionidigitali.net/?q=content/download-
Pagina 204
4
client-sacks). Per autenticarsi gli utenti devono utilizzare le stesse credenziali necessarie per l’accesso al sito web. Attraverso il client sarà possibile fruire di tutti i
servizi messi a disposizione dal server.
1.2.2 Il giorno della riunione
1. Alcune ore prima della riunione
• Il server acquisisce dal sito web le informazioni sulla riunione, riconosce
quindi come chair l’utente P ippo e accetta la partecipazione di tutti coloro
che si sono iscritti alla riunione (P luto incluso).
• Il server invia inolte a tutti gli utenti una mail di remind.
Al momento in cui inizia la riunione
•
•
•
Per partecipare alla riunione, gli utenti registrati, dovranno semplicemente loggarsi mediante il client Sacks. In questo modo sia P ippo, che P luto, ma anche
tutti gli altri partecipanti saranno automaticamente in riunione.
Agli utenti non registrati per la riunione viene dato un messaggio che chiarisce
l’impossibilità di avere accesso
Tutti gli utenti che non si sono registrati possono seguire la riunione mediante
l’interfaccia web.
Gli utenti che partecipanti alla riunione possono fruire di diverse funzionalità. Riportiamo qui quelle più importanti divise per modulo.
Modulo stream audio video
1. Il modulo per lo stream audio/video permette ai partecipanti di potersi vedere,
sentire e di mandare lo stream di ciò che fanno sul proprio desktop.
•
•
•
Dall’inizio della riunione P ippo decide quali utenti possono inviare lo stream
del proprio desktop/web cam.
Tutti gli utenti che partecipano alla riunione possono vedere lo stream di tutti i
partecipanti ammessi da P ippo.
P ippo può decidere di dare la parola ad uno dei partecipanti. Quando l’utente
riceve la parola da P ippo il suo stram viene mandato sulla pagina web (http://riunionidigitali.net).
Modulo desktop sharing
1. Questo modulo permette ai partecipanti alla riunione di coordinare l’uso di un
desktop condiviso. Il desktop condiviso risiede su un server.
•
•
L’utente P ippo può attivare un desktop condiviso.
L’utente P ippo decide di volta in volta quale utente può avere accesso alle
azioni sul desktop condiviso.
Pagina 205
1 Riunioni Digitali
5
Fig. 1.2. Client Sacks con attivo il modulo audio-video
•
Tutti gli altri utenti che partecipano alla conferenza, possono avere sempre
accesso alla visualizzazione.
Cosı̀ quando l’utente P ippo selezionerà, per esempio P luto, questo utente potrà
agire sull’desktop. Tutti gli altri solo guardare.
Modulo VoIP
1. Questo modulo permette di gestire chiamate voip
•
Ciascun utente può inserire nella conferenza utenti chiamandoli attraverso
un servizio di VoIP esterno.
Modulo web
1. Questo modulo permette di gestire l’istanza di un browser sui diversi client
•
Il chair può rimandare tutti gli utenti ad un determinato indirizzo web
Nel contesto di una presentazione, può essere utile guidare la navigazione di tutti
i partecipnti su un’unica pagina.
Pagina 206
6
Fig. 1.3. Client Sacks con attivo il modulo desktop sharing
1.3 Descrizione strutturale
componenti
Il client Sacks è scritto in un linguaggio di programmazione ad oggetti Python. Per
lo sviluppo del client abbiamo adottato il framework Qt. Le consta di alcune classi
che gestiscono le principali attività che sono:
la gestione del protocollo e il coordinamento delle attività del software (pyriunioni) la gestione delle attività specifiche degli utenti della riunione (pyuserBox) il
supporto alla comunicazione con protocollo jabber (pyjabber) la definizione della
interfaccia (pymainWindow) il servizio della attività multimediale e di streaming
(pystream)
e alcune classi che forniscono alcuni moduli aggiuntivi
il supporto alle chiamate su telefonia voip (pyvoip) il servizio di desktop remoto
(pyvnc)
La comunicazione avviene su jabber tramite la libreria xmppy che gestisce le
attività di coordinamento della assemblea mediante un protocollo interno e la comunicazione con messaggi agli utenti. I messaggi scambiati cambiano a seconda
Pagima 207
1 Riunioni Digitali
7
Fig. 1.4. Client Sacks con attivo il modulo web
del ruolo di utente semplice o di utente chair, caso in cui si attiva una modalità che
prevede lo scambio di ulteriori messaggi di coordinamento dell’assemblea.
parta server
Il server coordina le attività multimediali della riunioni, mantiene informazioni e
attiva servizi per la realizzazione della assemblea. La comunicazioni per questa gestione avviene con un protocollo di comunicazione rivolto sia al chair che all’utente.
I contenuti multimediali adoperati per le funzioni di streaming utilizzano un formato
libero (XVID). Un flusso multimediale può essere accessibile su sito web mediante
il plugin di VLC. Sul sito del portale questo contenuto audio-video è visualizzabile
alla sezione ”Streaming”. Il server inoltre comunica con la sezione implementata su
Web del portale di RiunioniDigitali per l’attivazione della assemblea.
1.4 aggiunta di un modulo
In futuro rilascieremo un componente per implementare nel sistema la definizione di
moduli di funzioni aggiuntive.
Sacks è distribuito con licenza GPL v.3, e ogni utente è libero di cimentarsi nel
realizzare nuovi moduli. È possibile scaricare i codici sorgenti (oltre ai compilati per
Pagina 208
8
le principali distribuzioni) da http://riunionidigitali.net/?q=content/download-clientsacks
Nel seguito forniamo uno schema di principio per lo sviluppo di un ipotetico
nuovo modulo sarebbe:
•
•
•
il nuovo modulo previsto dovrebbe per prova già funzionare in modo autonomo
di cui è accertata la stabilità: potrebbe trattarsi un codice scritto da zero oppure
una libreria di cui si vuol accedere a determinate chiamate viste come API;
va definita una classe di interfaccia in codice Python che faccia da ponte al codice
del modulo che realizza le attività previste. In questa classe si richiama alla attività “core” del modulo;
Nella classe di interfaccia vanno definiti eventuali metodi che servono a inizializzare e sincronizzare le nuove attività previste con quelle che vengon gestite dal
client Sacks nel contesto di una assemblea.
Usualmente il nuovo modulo approvato viene stanziato all’avvio del programma
e son previsti il lancio dei metodi specifici. Alcuni metodi sono di inizializzazione
dell’attività, altri sono metodi di coordinamento dell’utilizzo e di aggiornamento
dello stato, di questi si distinguono alcuni per le attività del moderatore e altri per
gli utenti comuni dell’assemblea. Nell’interfaccia del Chair saranno disponibili dei
bottoni o form che consentano l’interazione e l’attivazione di questo modulo e che
quindi ne lanciano i previsti metodi. La classe di interfaccia per mostrare la propria
comunicazione grafica con l’interlocutore genericamente presenta un widget che si
va ad inserire all’interno della interfaccia generale del client Sacks. Specificamente
il widget deve essere realizzato per ereditarietà dalla classe QWidget dell’ambiente
PyQt che è l’ambiente framework del client Sacks. L’aspetto widget può essere creata anche usando l’UI designer di QT che genera il codice da richiamare dalla classe
di interfaccia.
Ulteriormente vanno definiti eventuali nuovi messaggi di protocollo per le nuove
attività previste, essi si vanno inserite nel contesto del complesso sistema di messaggi
che coordinano l’assemblea; alcuni sono da e per il server altri da e per il chair.
il caso del desktop sharing
Il caso del desktop sharing ha seguito la prassi di sviluppo di un modulo esterno
di Sacks. Questo modulo permette di visualizzare un desktop Remoto proveniente
da un server VNC. E’ stata realizzata una classe ”Core” chiamata pyvncCore che
si interfaccia alla libreria che effettua la funzionalità interna del servizio, ossia il
previevo dei frame in tecnica RFB dal server VNC.
The class is "pyvncCore", which is used to create
a connection to a RFB (remote desktop server).
It realizes authentication, manages keys and
mouse events and elaborate screen updates.
It receive ’host’, ’display’, ’password’ as
launching parameters.
Pagina 209
1 Riunioni Digitali
9
class pyvncCore(QtCore.QThread):
def __init__(self, host, display, passwd, parent=None):
QtCore.QThread.__init__(self, parent)
Viene realizzato un Widget con i frame che vengon acquisiti di volta in volta
qualora viene fornito un aggiornamento dal server oppure si genera un evento sulla
interfaccia. Sono usati in questa classe alcuni metodi che elaborano queste attività.
Ad esempio:
def elaboratePix(self, image):
Method "elaboratePix" that sect the updated frame
received from VNC server as parameter
def mousePressEvent(self,mouseEvent):
Method "mousePressEvent" that receive event from
Desktop mouse press interaction, recognize it and
send the value to the server through the vnc
core library.
def keyPressEvent(self,keyPressEvent):
Method "keyPressEvent" that receive event from
keyboard interaction, recognize the characther
and send the value to the server through the
vnc core library.
Un’altra classe chiamata pyvncInterf ace è stata scritta per essere inglobata all’interno
del Finestra principale di Sacks. Si tratta di una classe di interfaccia utilizzata per
ricevere gli eventi di mouse e tastiera e per aggiungere dei bottoni in menù per la
gestione del servizio.
The class is "pyvncInterface", which is
used to create an Interface to a VNC
remote desktop instance. It inherit the
Qt MainWindow definition.
class pyvncInterface(QtGui.QMainWindow):
def __init__(self, parent=None):
QtGui.QMainWindow.__init__(self, parent)
Sono presenti in questa classe di interfaccia dei metodi che attivano il servizio in
questione di Desktop remoto; da parte del Chair vengon ricevuti dei comandi di
protocollo che servon a lanciare questi metodi quando opportuno.
Ad esempio:
def setScreenParameters(self, parameters=None):
Method "setScreenParameters" that set the vnc-session
connection parameters which are received from a protocol
command and launched from a button interaction.
Pagina 210
10
1.5 Conclusioni e prospettive future
Quando abbiamo cominciato a cimentarci nella realizzazione di Riunioni Digitali
avevamo chiaro in mente che avremmo sviluppato, per ragioni etiche, un software
che doveva essere libero. Non ci rendevamo conto di quanto conveniente era la scelta
che stavamo facendo. L’ecosistema del Software Libero mette, infatti, a disposizione
di ogni sviluppatore tutti i principali componenti necessari per confrontarsi con i
principali concorrenti proprietari. In futuro, il progetto evolverà sempre più verso la
direzione di avvantagiarsi della particolarità dell’ecosistema del Software Libero.
Abbiamo intenzione di rendere questo strumento sempre più simile ad un ’service manager’. Con ’service manager’ intendiamo un programma analogo al package manager descritto da Burrow (2005) ma il cui scopo è amminitrare un gruppo
di computer. e sempre più diverso da un sisema di videoconferenza. A questo scopo
abbiamo intenzione di rilasciare al più presto, tutta la documentazione necessaria a
mettere la comunità in grado di realizzare nuovi moduli.
References
1. Donato, D., (2007), “Adunanza Digitale: la nascita di un movimento”, in TECNOLOGIE
EMERGENTI E COSTRUZIONE DI CONOSCENZA , (a cura di M. B., Ligorio e S.,
Smiraglia), Script Web, ISBN:978-88;89543;80;1., Bologna.
2. Donato, D., (2009), “Il progetto Sacks”, Atti ConfSL, Bologna.
3. Burrows, D., (2005), “Modelling and Resolving Software Dependecies.”, Unpublished
manuscript.
4. Donato, D., Napolitano, F., (2007),“Adunanza Digitale: la nascita di un movimento”, Atti
del Primo Convegno Nazionale del CKBG, 27-28 Marzo 2007, Scriptaweb.
Pagina 211
ILDJIT: A parallel, free software and highly flexible Dynamic Compiler
Simone Campanoni, Harvard University, 33 Oxford street, 02139 Cambridge, MA USA,
xan@eecs.harvard.edu
Michele Tartara, Politecnico di Milano, via Ponzio 34/5, 20133 Milano, Italy,
mtartara@elet.polimi.it
Stefano Crespi Reghizzi, Politecnico di Milano, via Ponzio 34/5, 20133 Milano, Italy,
crespi@elet.polimi.it
Abstract
ILDJIT, a new-generation dynamic compiler and virtual machine designed to support parallel compilation,
is here introduced. Our dynamic compiler is a free software released through the GNU General Public
License (version 2) and it targets the increasingly popular ECMA-335 specification. The goal of this project
is twofold: on one hand, it aims at exploiting the parallelism exposed by multi-core architectures to hide
dynamic compilation latencies by pipelining compilation and execution tasks; on the other hand, it provides
a flexible, modular and adaptive framework for dynamic code optimization. Thanks to the compilation
latency masking effect of the pipeline organization, our dynamic compiler is able to mask most of the
compilation delay, when the underlying hardware exposes sufficient parallelism. Even when running on a
single core, the ILDJIT adaptive optimization framework manages to speed up the computation with respect
to other open source implementations of ECMA-335.
Keywords: Virtual machine, dynamic compilation, parallel system.
1 Introduction
The use of a virtual machine language, instead of machine code, is by now a well-established and successful
technique for porting programs across different hardware platforms, without incurring into the difficulties
and draw-backs of software distribution, when done at source-language level. In addition, interoperability
between different source languages is made possible by their translation into a common suitable virtual
code. Java bytecode first, and then CLI (Common Language Infrastructure) are the de facto industrial
standards for such virtualization of the Instruction Set Architecture (ISA). In particular CLI has become
a very attractive framework, where applications written in multiple high-level languages, including also
unmanaged language like C, can be executed in different system environments, at no cost for adaptation.
The increasing acceptance of CLI, also in areas traditionally reserved to direct compilation into machine
code, is witnessed by the growth and consolidation over the years of the tool chains needed to support
virtualization, namely static front-end compilers translating popular source languages into virtual code, and
Virtual Execution Systems (VES), such as .NET, Mono, and Portable.Net. Although the first VES’s were
based on code interpretation, all modern ones use instead Dynamic Compilation (DC), in order to achieve
better performances.
A VES is a very complex software system that takes years for his development and in a sense is never finished, since new requirements keep coming from the advances in machine architectures, source languages,
operating systems and middleware. Therefore it is not surprising that the current generation of VES has been
designed having in mind the desktop personal computers and the traditional embedded systems, before the
advent of multi-core architectures and single-chip multiprocessors, and without taking into consideration
the great opportunities they offer for parallelization inside the VES and between VES and application.
The new free software VES that we present here is named ILDJIT (Intermediate Language Distributed
Just-In-Time) [5]. It is intended for multi-core architectures, and flexible enough to easily adapt to the
evolving and hard to anticipate requirements of modern computer platforms. ILDJIT is designed to be easily
extensible by providing a framework where existing modules can be substituted by user customized ones. It
takes as its input files written in the Common Intermediate Language (CIL) bytecode (designed by Microsoft
for its DotNet framework and later standardized as ECMA-335 [8] and ISO/IEC 23271:2006 [10]) and
executes them after translation to machine code by means of Just-In-Time compilation.
Parallelism is exploited in different ways: by means of a pipeline of translation and optimization phases (see
Section 2), and by using a predictive approach, termed Dynamic Look Ahead (DLA, described in Section
3) to choose the methods to be compiled.
Pagina 212
Figure 1: Pipeline model implemented inside the ILDJIT compiler
In particular, Section 2 and 3 presents ILDJIT’s parallel features, Section 4 describes the recently obtained
ILDJIT portability on different hardware architectures and the overall improvements it brought, and Section
6 presents some numeric results showing ILDJIT performances. Finally, Section 7 sets a road-map for future
research and Section 8 concludes.
2 Pipeline architecture
The work of dynamic compilers can be divided into a series of subsequent steps, namely, loading the input
bytecode, decoding it to an intermediate language, optimizing it, translating it to machine code and finally
executing the program. Even if these steps expose a natural pipeline parallelism, most dynamic compilers,
such as Mono and Portable.NET, perform these steps in a completely sequential way: each method of
the program has to pass through all the phases of the compilation process, one after the other. When the
method being executed needs to invoke another method, the execution will be stopped and the new method
will have, in turn, to undergo the full compilation sequence.
ILDJIT exploits this kind of parallelism found across compilation phases by relying on an internal pipeline
structure (see Figure 1) which aims to overlap as much as possible the compilation efforts. The software
pipeline allows even sequential programs compiled in CIL to benefit from multiple hardware cores: while
one core executes the current method, the other ones can be used to pre-compile and optimize methods
that will have to be used in the future. Each method will have a flag indicating its current translation
state, namely CIL, IR, MACHINECODE, EXECUTABLE. While the names of CIL and IR states are pretty
self-explanatory, some word needs to be spent to clarify the meaning of the other ones: methods in MACHINECODE state are present in the system in CIL and IR form, and have already been translated to
machine code. EXECUTABLE methods are present in the same forms of MACHINECODE ones, but all the
static memory they need has been allocated and initialized, therefore they are ready to be executed.
Deciding which methods can be precompiled is done through DLA, explained in the next Section.
3 Dynamic Look Ahead compilation
Dynamic Look Ahead (DLA) [6] is a recent compilation technique, which aims to mask as much as possible
the compilation delay by overlapping the compilation efforts. As Figure 2 shows, this technique predicts
at runtime where the execution is going to go and it starts the compilation of parts of the application code
before the execution asks for it.
This model is based upon the use of two priority queues (see Figure 3) (a low priority one and a high priority
one) and on runtime code profiling of the bytecode application.
Pagina 213
Figure 2: Look-Ahead-Region of DLA compilers
DLA
IR−>IR
Ram
BC−>IR
IR−>IR
IR−>Bin
EX
IR−>IR
BC−>IR
DLA
invoke
IR−>IR
Figure 3: Internal organization of a DLA compiler. BC is the source bytecode (CIL) and ovals are the
internal threads of the compiler
Most information comes from the Static Call Graph (SCG): it is the graph where each node represents a
method of the program, and two nodes mi and mj are linked by a directed arc mi → mj if mi can invoke
mj .
Even if the information of the SCG is static (therefore it exclusively depends on the source code of the
program), the dynamic compiler does not know all of the SCG immediately: it gets to know it a portion at
a time, while execution takes place. For this reason, the graph is defined Dynamically Known Static Call
Graph (DKSCG).
Each time a method m is compiled, all the methods mi it can invoke are candidates for being executed in
the near future.
Let γ(m, mi ) be the weighted distance between m and mi . We define the Look Ahead Region as LAR =
{mi | γ(m, mi ) ≤ T hr}, where T hr is an implementation-dependent threshold.
It is worth noting that the distance has to be weighted to take into consideration the probability of executing
each method. The weight of the arc a = (mi , mj ) is defined as f ( λ1 , δ) where f is a monotonic function
of its parameters, λ is the likelihood of invocation of the method mj from mi , and δ is the estimated time
distance between the execution of the first instructions of mi and of mj if the a arc is taken.
Methods in the LAR are added to the low priority queue to be precompiled, in an order depending on their
execution probability. If during the execution of the program a not yet compiled method is invoked, a
trampoline is taken, that calls an internal function of the compiler which will add the called method to the
high priority queue (together with methods potentially invoked by it), in order to immediately compile it
and resume the execution of the program.
As it can be seen, in an ideal situation, the high priority queue should never be used, and all the methods
should already be ready when needed, thus completely masking out the delay introduced by JIT execution.
However, it may happen that a wrong prediction leads to the need to insert a method in the high priority
queue, or that compilation delay makes necessary to move a method from the low priority queue to the high
priority one.
Pagina 214
4 A multi-platform JIT
Another outstanding feature of ILDJIT is its portability: currently ILDJIT is able to run on top of ARM,
x86 and AMD 64 bits processors. In this section we focus on the back-end developed for ARM processors.
In recent years, computational devices are changing. More and more frequently we find that smartphones,
PDAs and other devices that are not usually associated with the concept of “computational power” are
using increasingly powerful processors. In most cases, these processors are not compatible with Intel x86
Instruction Set Architecture, therefore, for a software to support them, it means that it has to be ported.
The development of ILDJIT is mainly done on Intel x86 processors, but the compiler has now been ported
to ARM architectures too. This port has been done as part of the work for the Open Media Platform (OMP)
European project, aiming at the definition of an “open and extensible service & software architecture for
media-rich end-user devices, such as mobile phones or mobile media players, that will address software
productivity and optimal service delivery challenges”. [2]
The work led to the realization of a fully-working implementation able to run on ARM9 hardware with
Vector Floating Point (VFP) coprocessor and, with partial functionality, even on hardware without VFP. At
the moment, VFP is used just to perform floating point operations. Vector capabilities of this coprocessor
are not yet used by ILDJIT.
ARM development is performed using the Qemu [1] emulator as the development platform, targeting an
ARM926 processor. This choice is due to the ease of development offered by the emulated environment
with respect to using a development board.
From time to time, results are validated by running ILDJIT on real hardware, namely an NHK15 development board by STMicroelectronics. This is needed because there is some difference between Qemu’s
emulated hardware and the real one, in particular with respect to the memory model. ARM9 hardware
does not allow unaligned accesses to memory: each load or store operation has to be aligned to a multiple
of the size of the data that are being read. This is due to architectural and performance reasons: in order
to reduce the time to access memory, the power consumption and the cost of the processor, there is no
hardware support for unaligned access. Failing to comply with this limitation, leads to having invalid data
returned by load operations or saved by store operations. On the other hand, as of version 0.11, Qemu
emulation permissively supports unaligned memory accesses. This is probably due the fact that Intel x86
processors support this kind of operation and Qemu directly uses the underlying primitives to interact with
the emulated memory.
As of the end of the OMP project, ILDJIT is able to run on the NHK15 board JIT-compiling a Scalable
Video Decoder translating an H.264 video to YUV format.
Porting ILDJIT to a second architecture brought several advantages: first of all, it increased the number of
potential users and uses, and, due to the widespread adoption of ARM processors in the embedded systems
industry, widened considerably the number of devices it can run upon.
Recently, multi-core ARM processors are starting to show up in commercial applications (such as the
Cortex-A8 ARM dual core chip, used by Nokia’s N900 Linux-based Internet tablet). ILDJIT’s internal
structure focused on the exploitation of hardware parallelism (already described in Sections 2 and 3) and
based upon the use of many different operating system threads will automatically improve the performances
of the compiler when run on such processors.
5 Project diffusion
The compiler ILDJIT is available on the web [4] since May 2007 and, after that date, more than one hundred
releases have been provided. Table 1 reports the important improvements among the main releases of the
project.
ILDJIT project started at Politecnico di Milano and currently both this University and Harvard University
collaborate to this project.
Based on the number of downloads, it can be stated that after few months from the first release of the
compiler, an increasing interest on the project has been shown. The number of downloads of the compiler
increases month after month, and at the time this dissection has been written, more than ten thousands
downloads have been registered. Moreover, Figure 4 shows the distribution of accesses to the website and
downloads of the project over the world.
Several tutorials and documentations of internal aspects of the project are available within the several releases, in order to enable outside researchers and software developers to start to work within the project.
Pagina 215
Table 1: Improvements of ILDJIT among its main releases
Release
0.0.1
0.0.1.2
0.0.1.7
0.0.1.8
0.0.1.9
0.0.2
0.0.3
0.0.4
0.1.0
0.2.0
0.3.0
Main improvements
Start release
Support of the 30% managed CIL provided
Dead code and constant propagation optimizations
provided
5 code optimization algorithms provided
2 Garbage collectors provided
Support of the 10% unmanaged CIL provided
4 Garbage collectors provided
Add the support of EM64T ISA
Add the partial support of ARM ISA
Add the partial support of Windows OS
Add the partial support of MacOS OS
Complete the support of ARM processors
Add the partial support of Solaris OS
Add the partial support of Solaris OS
Year
2005
2006
2007
2007
2007
2008
2008
2009
2009
2009
2010
Figure 4: Snapshot of the world wide interests on ILDJIT project in April 2010
Pagina 216
Figure 5: Execution time of Mono, Portable.NET and ILDJIT compiler. Benchmarks are considered with
both small input set size (S) and large one (L).
Moreover, the ILDJIT project is currently used both at Politecnico di Milano and at Harvard University in
teaching classes.
6 Experimental results
In this section, some measurement will be provided, comparing ILDJIT with the Mono and Portable.NET
Just-In-Time compilers.
Intel x86 results were obtained by running on top of a Intel Xeon E5335 at 2 GHz. ARM results have been
taken in Qemu 0.11, running on an underlying Intel Core 2 Duo P8400 dual core processor at 2.26GHz
processor.
The numerical results reported are the mean value of four execution of the benchmarks out of five. The
timings of the first execution have been discarded to prevent negative effects due to the caching of data to
memory from the hard disk.
Figure 6: Distribution of times between the various phases of compilation for ILDJIT running Linpack
CIL loading
0,27%
CIL→IR
0,25%
IR Opt.
0,61%
IR→EXE
0,08%
Static mem. init.
0,15%
Pagina 217
Trampolines
0,96%
Execution
97,67%
Table 2: Percentage of time required by each of the JIT compilation phases, for ILDJIT running Linpack
(where “EXE” stands for “executable machine code“.
Figure 7: Comparison of ILDJIT and Mono running on ARM
Mono
ILDJIT
FFT
0,968
1,709
Montecarlo
13,869
1,842
SOR
0,677
1,442
Linpack
4,389
2,784
BinaryTree
1,238
8,072
SHA1
1,176
4,622
SparseMM
2,45
1,659
Table 3: Execution times for some test programs with ILDJIT, compared with Mono on ARM platform
Figure 8: DLA results as a function of the number of CPU
The chosen benchmarks are taken from well-known test suites, such as Java Grande [9], Linpack and
Scimark [11]. In particular, the following benchmarks have been used:
JGFFFT (FFT) part of the Java Grande benchmarks, it computes Fourier coefficients, which test the computation of floating point transcendental and trigonometric functions.
Pagina 218
SciMarkMONTECARLO (Montecarlo) part of the SciMark test suite, it estimates π by approximating
the area of a circle using the Montecarlo method.
SciMarkSOR (SOR) part of the SciMark test suite, it solves the Laplace equation in 2D by successive
over-relaxation.
Linpack measures how fast a computer solves a dense N × N system of linear equations Ax = b. This
test was originally written for Fortran. This particular version is in C# and comes from the Pnet [12]
test suite.
BinaryTree taken from the Great Computer Language Shootout website [3], aimed at measuring the performance of various programming language, this test performs a series of operations on binary trees.
SHA1 it contains an implementation of the Secure Hash Algorithm (SHA), and in particular, of the SHA-1
variant, that produces a 160-bit message digest for a given data stream. Therefore, this algorithm can
serve as a means of providing a "fingerprint" for a message. The test applies the SHA-1 algorithm on
a series of test patterns.
JGFSparseMatMult (SparseMM) it is taken form the Java Grande Benchmark Suite and it exercises
indirect addressing and non-regular memory references. An N × N sparse matrix (with a prescribed
sparsity) is multiplied by a dense vector 200 times.
The first important evaluation is about the overhead of having a multi-threaded compiler: Figure 5 shows
that even when ILDJIT runs on top of a platform that provides only one core, it is competitive w.r.t its
competitors (Mono and Portable.NET). In order to compare the virtual machines, we have considered small
inputs (benchmarks with the S character at the end of their name) and large inputs (L). We can notice
that whenever the application code runs for less than 1 second (Small input), ILDJIT is slower than its
competitors; this is due to the fact that the bootstrap of our compiler is more complex than others (it has to
spawn threads, etc. . . ) that are single thread program and therefore ILDJIT needs more time to start. On
the other hand, if we consider application codes that run for more than 1 second (L), ILDJIT starts to be
competitive.
As it can be seen in Figure 6 and in Table 2, overall JIT compilation times are just a tiny fraction of the total
execution time.
Data in Table 3 and Figure 7 show a comparison between running times of some benchmarks with ILDJIT
and Mono on the ARM platform. Mono [7] is the main open source JIT for CIL: it is a Virtual Execution
System for programs in CIL bytecode, and it is developed by a wide community of programmers, with
support from Novell.
As it can be seen in Figure 7, the results of the two compilers are quite close, with Mono frequently ahead.
The outstanding results obtained by ILDJIT in some of the tests (such as the Montecarlo benchmark) come
from the fact that its code generator is able to produce instructions for the VFP coprocessor, where available,
therefore obtaining a great advantage in terms of performance on floating point based benchmarks. On the
other hand, in other cases Mono is faster than ILDJIT, because of the better and more optimized code
produced by its code generator when there are no floating point operation involved.
Figure 8 shows the effect of compiling a program with DLA with respect to JIT. The benchmarks used are
Jpeg and Heapsort, taken from the MiBench suite. As it can be seen, DLA is strongly dependent on the
number of used CPUs. With one CPU, it can be even slower than JIT compilation (because of the cost of
handling the compilation pipeline) but as the number of CPUs increases, the result become increasingly
positive. However, it has to be noted that the performance improvement is bounded. In particular, it
depends on the branching factor of method calls in the compiled program. Once there are enough CPUs to
precompile all of the methods, adding more CPUs does not bring any additional improvement.
7 Future work
At this time, ILDJIT focuses on exploiting parallelism internally, in order to make the JIT compilation as
lightweight and as hidden as possible, through its software pipeline and DLA compilation. The executed
program is not influenced by this.
In the future, some exploratory work will be done aiming at extracting parallelism from the executed code,
in order to make its execution even faster and to allow legacy sequential code to take advantage of the
increased degree of parallelism of the incoming architectures.
Pagina 219
This could happen at two different levels, with detection of either fine-grained or coarse-grained parallelism
(or even both). First of all, the code generator could be extended to support vector instructions, to perform
Single Instruction Multiple Data calculations. On the other end, blocks of code that are not dependent on
the rest of the program could be moved to a new thread and run on a different processor core, thus obtaining
faster execution.
8 Conclusions
This paper presented the ILDJIT compiler and the features it has aimed at exploiting hardware parallelism
present in recent architectures.
In particular, the software pipeline and DLA, built upon operating system threads, allow the compiler to
adapt to the underlying hardware, fully exploiting its resources, even when running programs non-explicitly
written for parallel systems.
References
[1] Qemu - open source processor emulator. http://www.qemu.org.
[2] Open Media Platform (OMP) European project. http://www.openmediaplatform.eu, 2008.
[3] The Great Computing Language Shootout. http://shootout.alioth.debian.org/, 2009.
[4] S. Campanoni. ILDJIT website, December 2009.
[5] S. Campanoni, G. Agosta, S. Crespi Reghizzi, and A. Di Biagio. A highly flexible, parallel virtual
machine: design and experience of ildjit. Softw. Pract. Exper., 40(2):177–207, 2010.
[6] S. Campanoni, M. Sykora, G. Agosta, and S. C. Reghizzi. Dynamic look ahead compilation: A
technique to hide jit compilation latencies in multicore environment. In O. de Moor and M. I.
Schwartzbach, editors, Compiler Construction, pages 220–235. Springer, 2009.
[7] M. de Icaza, P. Molaro, and D. Maurer. http://www.go-mono.com/docs. Mono documentation.
[8] ECMA. ECMA-335: Common Language Infrastructure (CLI). ECMA (European Association for
Standardizing Information and Communication Systems), Geneva, Switzerland, fourth edition, June
2006.
[9] Edinburgh Parallel Computing
http://www.epcc.ed.ac.uk/research/
javagrande/benchmarking.html.
Centre.
Java
Grande
Forum
Benchmark
Suite.
[10] ISO-IEC. Programming Languages—C#, ISO/IEC 23270:2006(E) International Standard, ansi standards for information technology edition, 2006.
[11] R. Pozo and B. Miller. http://math.nist.gov/scimark2. SciMark benchmark.
[12] Southern Storm Software. http://www.southern-storm.com.au. DotGNU Portable .NET project.
Pagina 220
Si ringraziano

confsl 2010 - Conferenza Italiana sul Software Libero

Transcription

Similar documents

9th International Workshop on Neonatology - Bologna, 21

Local Organizing Committee

"°"1

Il Territorio in cui vivo. Ambiente, storia, tradizioni, economia.

Coppa Italia Calcio a 5 Final Eight serie A2 2014

Local Organizing Committee

L`Evento E Ombra

Kit Didattico di Giocosimulazione sui cambiamenti climatici

Jan , 26tn.2076 dari Unit Kokuriulum , JPN Per:ak berkaitan perkara

Laboratorio dello sport

sicurezza sul lavoro - Gazzetta del Sulcis Iglesiente

Documento PDF - UniCA Eprints - Università degli studi di Cagliari.