Origini e Filosofia: Windows & Co in Linux window
Microsoft Word, Excel, PowerPoint e Internet Explorer in WINE sotto Linux
Simile a WINE è QEMU di cui si riportano le specifiche tecniche per l’installazione e l’esecuzione in Appendice B: Windows su Linux con QEMU.
Altra possibilità è quella di installare programmi proprietari e dedicati di un Sistema Operativo, su di un altro Sistema Operativo a patto che questo sia predisposto per questa eventualità: essendo Linux un Sistema Operativo talmente duttile, potente ed affidabile i suoi sviluppatori hanno preso in considerazione anche di cimentarsi in questo campo.
Nulla vieta, ad esempio, di utilizzare pienamente Microsoft Office in ambiente Linux attraverso programmi come CROSS OVER OFFICE che, emulando l’architettura Windows, permette di installare gli applicativi più usati nel mondo Microsoft. A riguardo occorre comunque specificare che, in accordo con le modalità di sviluppo Open Source, lo stesso CROSS OVER OFFICE, per la sua emulazione, si basa sulle stesse librerie di WINE.
Altra osservazione risiede nel fatto che, comunque, tali attività devono essere gestite in modo intelligente: infatti, come specificato sul sito del programma 53
CROSS OVER OFFICE, solo MS Office 2000 è pienamente supportato quindi, se non si vogliono avere brutte sorprese, in questi casi è bene documentarsi prima. Di seguito alcuni Screenshots:
Installazione di Microsoft Office con CrossOverOffice 2.1 sotto Linux
Origini e Filosofia: Windows & Co in Linux window
Ma questo non è l’unico caso di interfacciamento, ne esistono altri e sono moltissimi.
C’è infatti anche l’interfacciamento dal lato dei database come ad esempio ORACLE che gira anche su Linux. Oppure l’interfacciamento di stampanti o dati condivisi in rete: nel caso infatti di una rete mista di macchine con Windows e Linux il modo ideale per condividere files e stampanti è quello di usare SAMBA un altro prodotto sviluppato appositamente.
Certo molto spesso queste soluzioni sono rivolte e padroneggiate da utenti esperti nel settore.
Pur tuttavia essi rappresentano un’ulteriore avanzata del mondo Open Source che cerca con tutte le sue forze di dimostrare la versatilità dei suoi prodotti, le competenze tecniche e le abilità Software dei suoi sviluppatori e della comunità tutta che alacremente si adopera nella ricerca di soluzioni sempre nuove ed all’avanguardia tanto da competere e, in casi sempre più frequenti, addirittura di surclassare enormemente la qualità dei prodotti concorrenti sebbene blasonati e considerati leader nei settori più disparati ma caratterizzati anche da prezzi elevati e non privi anch’essi di lacune ed errori.
55
2.06) Microsoft apre all’Open Source.
Microsoft apre all’Open Source, anzi allo “Shared Source”. Si tratta di una iniziativa che muove i primi passi e tende ad aprire il codice di alcuni prodotti come Windows e Office ad enti riconosciuti.
Tutt’ora le Licenze Shared Source sono tre e saranno di primaria importanza per lo sviluppo del concetto di Open Source oltre che per un’ulteriore evoluzione di Linux e Software collegati. L’introduzione di queste Licenze, molto simili alla filosofia Open Source, rappresenta un passo epocale per un’azienda che fino a poco tempo fa criticava in toto il modello a codice aperto. Sia chiaro: Microsoft ribadisce che il suo approccio non riguarda l’Open Source. In questo senso molti intravedono in queste dichiarazioni la volontà di definire una sorta di limbo cercando di creare una terra di mezzo, forse quasi un ostacolo alla crescita del movimento libero.
In pratica, sbirciando il testo delle Licenze, si scopre che non è così o almeno sembra che le intenzioni siano genuine.
Le Licenze sono formulate in maniera molto semplice e comprensibile anche da chi non ha fatto studi di giurisprudenza. La prima, la Ms-PL (Microsoft Permissive License), consente agli sviluppatori di vedere, modificare redistribuire il codice senza alcun vincolo. Il Software può essere impiegato anche per scopi commerciali senza pagare alcuna royalties a Microsoft: delle tre, questa è sicuramente la più libera. Essa assomiglia molto alla BSD- License.
La seconda, la Ms-CL (Microsoft Community License) permette di apportare proprio codice ai prodotti dell’azienda di Redmond. Anche in questo caso il Software creato potrà essere utilizzato senza pagare alcuna royalties su Copyright e brevetti coinvolti. La Licenza, molto simile a quella utilizzata per Mozilla Public License di Mozilla Firefox, dà la possibilità di aggiungere
Origini e Filosofia: Microsoft apre all’ Open Source
funzionalità e correggere bug sebbene il controllo sul prodotto su cui si lavora rimanga proprietario di Microsoft.
Tanto per la Ms-PL che la Ms-CL è prevista una specifica versione limitata, che riguarda in particolare le componenti del prodotto principale di Microsoft, Windows.
L’ultima Licenza, la Ms-RL (Microsoft Reference License), è sicuramente la più restrittiva: consente unicamente la visibilità del codice sorgente ma ne proibisce la modifica e il riutilizzo. Lo scopo principale è dare la possibilità agli sviluppatori di apprendere le logiche interne delle librerie di sistema e permettere alle istituzioni pubbliche di verificare che il codice Microsoft sia privo di backdoor.
In conclusione, queste Licenze cambiano in maniera radicale il modo di fare Software in casa Microsoft. Se fino a ieri esistevano due schieramenti contrapposti, “open” e “closed”, ora si nota una certa convergenza tra le due parti. L’azienda di Redmond, messa nel cassetto la tradizionale avversione verso l’Open Source, ha finalmente compreso che il buon Software si costruisce coinvolgendo sviluppatori e utilizzatori. Secondo un portavoce di Microsoft comunque, la compatibilità delle tre Licenze secondo gli standard OSI (Open Source Initiave) è ancora del tutto fuori discussione. Questo anche malgrado la somiglianza con alcune Licenze Open Source potrebbe consentirne l’interoperabilità i limiti della quale sarebbero ancora da definire e con essi anche la loro estensione.
La Free Software Foundation ha espresso soddisfazione per la scelta di Microsoft a dimostrazione che, in fondo, non si tratta di una guerra tra fazioni per cui se anche il gigante di Windows e Office decide di farsi strada all’interno dell’Open Source sarà il benvenuto.
L’auspicio è che questo sia solo il primo passo di tanti altri rivolti se non alla creazione di un Sistema Operativo unico quantomeno ad una filosofia comune che consenta al Software di integrarsi maggiormente con le varie piattaforme 57
presenti sul mercato e con l’Hardware su cui è implementato; che consenta la definizione di specifiche tecniche comuni a più Software al fine che gli stessi possano dialogare ed interagire fra di loro in modo più semplice ed immediato;
per offrire quindi agli sviluppatori la possibilità di apprendere e mettere in pratica nuove tecniche di programmazione per la creazione di prodotti sempre più innovativi ed accattivanti da poter rendere disponibili ad una platea di utenti più vasta ed esigente soddisfando richieste sempre più numerose di prodotti caratterizzati da affidabilità, sicurezza e semplicità di utilizzo sempre maggiori.
Open Source e Software
3) OPEN SOURCE E SOFTWARE.
59
3.01) Le Licenze Open Source.
I Software per computer altro non sono che algoritmi costituiti da una serie di istruzioni che definiscono processi logici e di calcolo gestiti da cicli reiterati che, interpretati dall’elaboratore, consentono l’esecuzione del programma trasformando quelli che sono dei flussi logici nelle funzionalità dell’applicativo che si sta utilizzando sia esso di tipo gestionale, grafico, musicale o ludico.
La maggior parte del Software viene distribuito nella forma di codice oggetto ovvero direttamente eseguibile memorizzato fisicamente sottoforma di una lunghissima catena di numeri binari (rappresentati da 0 ed 1) su di un supporto magnetico (floppy-disk) o ottico (CD-ROM, DVD).
L’utente tipo che acquista il programma si dedica principalmente all’attività di installazione del prodotto sul proprio computer ed al suo utilizzo non essendo interessato al codice oggetto che soggiace allo stesso né tanto meno al codice sorgente da cui è stato generato non avendo alcun interesse e, molto spesso, neanche le conoscenze per apportare eventuali modifiche.
Gli utenti quindi si trovano a condividere inconsapevolmente gli interessi delle case produttrici di Software il cui scopo è certamente quello di creare programmi di facile utilizzo e dalle funzionalità avanzate proteggendo al tempo stesso il codice sorgente dalla divulgazione in quanto se lo stesso fosse esaminato da un qualsiasi programmatore sufficientemente esperto questi potrebbe scoprire le logiche del suo funzionamento carpendo in tal modo i segreti del programmatore originale che nel Software ha profuso i suoi sforzi, la sua ingegnosità e creatività. In tal modo parti innovative di programmi potrebbero essere prelevate dal codice originario ed essere riutilizzate per la scrittura di altro Software.
Dal punto di vista delle aziende produttrici di Software si potrebbe sostenere che, in questo modo, si perde il vantaggio competitivo dato dal primo
Open Source e Software: Le Licenze Open Source
programma poiché il secondo avrebbe le stesse caratteristiche innovative ma sarebbe sviluppato ad un costo minore.
A differenza delle Licenze tradizionali, lo scopo principale delle Licenze Open Source non è, tuttavia, quello di trarre un vantaggio economico dalla concessione del programma in uso ma quello di consentire una libera distribuzione tra il pubblico del codice sorgente dei programmi per elaboratore.
Mentre nel caso di Software proprietario il suo sviluppo, le modifiche, i miglioramenti e la correzione degli errori sono affidati ai dipendenti delle aziende, nel caso del Software Open Source queste attività sono affidate ad un’intera comunità di sviluppatori sparsi nel Mondo intero. Lo sviluppatore originale si riserva la facoltà di controllare il nuovo codice assicurandosi che qualsiasi modifica o correzione sia ben scritta per essere testata all’interno del codice ufficiale e rendere quindi disponibile la nuova versione.
Nel mondo del Software Open Source le Licenze con cui i programmi vengono distribuiti ricoprono un ruolo di importanza fondamentale in quanto dall’applicazione delle stesse si può stabilire se un determinato programma sia da considerarsi libero o proprietario ed i vantaggi derivanti da questo modo di fare e distribuire Software.
Le Licenze tradizionali per il Software sono basate sulle normative riguardanti il diritto d’autore e generalmente sono finalizzate a difendere gli interessi degli autori e delle case produttrici.
Le Licenze di Software proprietario sono in genere progettate per definire le limitazioni d’uso sul Software che viene venduto concedendo in prestito agli utenti determinati diritti sul Software e restringendone altri. La maggioranza di esse sono studiate affinché le case produttrici possano mantenere il controllo, in particolar modo economico, su di una determinata tecnologia.
Il Software Open Source si contraddistingue invece dalla scelta di cedere agli utenti il controllo sul programma dotandoli di diverse libertà sull’uso del Software.
61
Risulta, comunque, che i criteri indicati dalla Open Source Definition per definire le Licenze per Software Open Source sono meno restrittive di quelle della Free Software Foundation, alcune volte concedendo alcuni privilegi speciali alle aziende pur di coinvolgerle nell’avventura dell’Open Source.
Le Licenze open Software sono, inoltre, accomunate dal fatto di declinare qualunque garanzia. Come chiarisce il testo della GPL:
“L’intero rischio concernente la qualità e le prestazioni del programma è dell’acquirente […] il quale si assume il costo di ogni manutenzione, riparazione o correzione necessaria, qualora il programma si riveli difettoso”. Inoltre, l’autore del programma e i terzi che possono modificare e ridistribuire il programma nei termini consentiti dalla GPL non sono responsabili per danni nei confronti dell’acquirente, a meno che questo non sia richiesto dalle leggi vigenti o appaia in un accordo scritto. Sono inclusi danni generici, speciali o incidentali, come pure i danni derivanti dall’uso o dall’impossibilità di usare il programma: ciò comprende la perdita di dati, la corruzione dei dati, l’inabilità del programma a lavorare insieme ad altri programmi”.
Lo scopo specifico di clausole simili a quella citata è quello di proteggere il proprietario del Software da qualunque responsabilità connessa al programma.
Dal momento che il programma è distribuito a costo zero si tratta di una richiesta ragionevole in quanto l’autore non riceve dal programma un ritorno economico tale da fronteggiare eventuali spese legali.
La definizione delle Licenze è rivolta quindi a disciplinare la creazione , la distribuzione e l’utilizzo del Software Open Source.
Le Licenze Open Source difendono inoltre la proprietà cosiddetta “morale”, ovvero il riconoscimento dei crediti morali per gli autori del Software mentre non difendono il valore commerciale della proprietà.
Open Source e Software: Le Licenze Open Source
Esistono notevoli differenze tra le diverse Licenze Open Source ma al tempo stesso è possibile individuare alcune caratteristiche salienti attraverso l’analisi di alcuni criteri principali:
- la possibilità di combinare e distribuire il prodotto assieme ad altri prodotti Open Source caratterizzati da differenti Licenze;
- la possibilità di combinare e distribuire in un unico pacchetto sia prodotti Open Source che proprietari;
- dal grado di protezione dei diritti di libertà quali quelli di utilizzo, copia, modifica e distribuzione del prodotto nonché dal rischio di appropriazione privata.
Per quanto concerne la protezione dei diritti legati alle libertà esercitabili sul Software sono state sviluppate le cosiddette Licenze Copyleft caratterizzate dall’eliminazione di ogni possibile modifica futura dei termini originari della Licenza imponendo quindi ai prodotti derivati di ereditare i termini di Licenza dei prodotti originari.
Di seguito si analizzeranno alcune delle principali Licenze utilizzate per lo sviluppo del Software.
Licenza GPL (General Public License): Licenza introdotta dalla Free Software Foundation nell’ambito del progetto GNU ad opera di Richard Stallman, il quale l’ha creata per garantire che la libertà del codice sorgente non fosse oggetto di abusi da parte di altri essendo indubbio che rendendo il codice aperto e pubblico, chiunque avrebbe potuto impadronirsene. Stallman pensò quindi ad un qualcosa del tipo
“do ut des”:
63
“chi trae benefici dal Software `e obbligato a condividere con altri i vantaggi che derivano da modifiche e contributi”.
La maggior parte del testo inerente la GPL è rivolto a chiarire i motivi ideologici alla base della sua creazione. Essa è stata redatta grazie alla collaborazione di alcuni giuristi e ciò spiega perché, tra tutte le Licenze Open Source, sia quella scritta con maggiore accuratezza e chiarezza dei termini.
La General Public License è stata congeniata per assicurare la libera distribuzione delle copie, l’accessibilità al codice sorgente e la possibilità di modificare lo stesso o di riutilizzarlo in parte per la creazione di altro Software di tipo open escludendo comunque l’aggregazione con altro codice, sia open che proprietario, che non sia distribuito sotto la stessa licenza.
Per via di tale caratteristica molto restrittiva il comportamento di questa Licenza è stato definito “virale” e, a detta di molte imprese, addirittura inapplicabile in quanto antieconomica;
Licenza LGPL (Lesser o Library General Public License): si tratta di una versione attenuata della GPL rappresentandone un adattamento rivolto allo sviluppo di librerie Software Open Source in quanto, essendo le stesse librerie composte da codice, spesso si rende necessario il loro utilizzo e richiamo all’interno di altri prodotti non necessariamente coperti da GPL per cui l’unica soluzione era quella di attenuare gli effetti di quest’ultima e limitarne il comportamento troppo restrittivo nei confronti di altre tipologie di Software.
La Library General Public License permette anche al Software proprietario di utilizzare librerie Open Source senza dover
Open Source e Software: Le Licenze Open Source
obbligatoriamente modificare i termini della propria Licenza rispettando comunque i termini previsti dall’Open Source Definition;
Licenza BSD (Berkeley Software Distribution License): essa prende il nome delle distribuzioni di codice sorgente dell’Università della California, Berkeley, che erano originariamente estensioni al Sistema Operativo UNIX del settore Ricerca della AT&T. Molti progetti Open Source di Sistemi Operativi sono basati su una versione di questo codice sorgente.
La Licenza BSD consente il libero uso, distribuzione, modifica del Software purché venga riportata notizia del Copyright e del contenuto della Licenza. Inoltre limita l’uso del nome dell’ autore nella promozione dei prodotti derivati. In ogni caso non impone restrizioni sui prodotti derivati.
La Licenza BSD consente di mantenere private le sole modifiche applicate ai codici originali non rendendo obbligatorio distribuire il nuovo codice o applicare allo stesso la medesima Licenza del prodotto originale: ciò potrebbe essere interpretato come una sorta di privilegio e quindi una discriminazione contraria all’Open Source Definition ma a ben vedere si tratta dell’esercizio di un diritto poiché la possibilità di privatizzare il codice è ristretta alla sole parti modificate privatamente.
La Licenza in oggetto lascia maggiore possibilità di adattare e integrare i prodotti open con altro codice anche close. Tuttavia occorre considerare l’evenienza che taluni sviluppatori non rilascino alla comunità le modifiche da essi apportate bloccando in questo modo la possibile evoluzione del prodotto stesso: questo è forse il motivo principale per cui la Licenza BSD non ha raggiunto la stessa diffusione della Licenza GPL;
65
Licenza IBM Public License: si tratta di una licenza “Copyleft” commerciale.
La peculiarità di questa Licenza è quella di comprendere clausole aggiuntive di indennizzo mirate a far sì che chiunque commercializzi un programma protetto da questa Licenza si assuma tutte le responsabilità anche riguardo ai reclami indirizzati agli autori originari;
Licenza QT Public License: QT è la libreria di sviluppo dell’ambiete desktop KDE. L’introduzione di questa Licenza è rivolta ad imporre l’obbligo di rendere disponibile il codice sorgente di ogni programma collegato alla libreria. E’ molto simile alla LGPL ma, a differenza di quest’ultima, la QT Public License non consente ad un codice privato e commerciale di utilizzare la sua libreria; Inoltre tale Licenza obbliga a distribuire le modifiche su patch;
Licenza NPL (Netscape Public License): nel gennaio del 1998, la Netscape Communications Corporation annunciò l’intenzione di rilasciare il codice sorgente del suo browser Web, Netscape Communicator: si trattò di un annuncio di importanza capitale, in quanto, per la prima volta, una grande azienda Informatica adottava il modello di sviluppo, distribuito e globale, tipico del sistema Linux e di altri progetti Open Source.
Nello stesso comunicato la Netscape precisava che sarebbe ricorsa ad una Licenza che avrebbe permesso la modifica e la ridistribuzione del codice sorgente e garantito la piena disponibilità delle versioni modificate sulla base della licenza GPL. Tuttavia l’adozione di una Licenza troppo open risultò una scelta non praticabile, giacché avrebbe significato che tutto il codice collegato sarebbe dovuto essere
Open Source e Software: Le Licenze Open Source
distribuito sotto la stessa Licenza. Questo non era possibile in quanto porzioni del codice di Communicator erano utilizzate per altri programmi di Netscape mentre altre parti erano date in Licenza a terzi. Alla fine, questo fastidioso problema legale fu risolto attraverso la creazione della Netscape Public License (NPL) e della Mozilla Public License (MPL).
La prima è una Licenza non rientrante nell’Open Source Definition ed utilizzata per la distribuzione dei programmi Netscape. Sotto molti aspetti funziona come la GPL, tuttavia conferisce alla società alcuni privilegi speciali. Tra questi il diritto di rilasciare codice a terzi per cui Netscape ha il diritto di mantenere private le modifiche apportate, migliorarle e rifiutarsi di restituire il risultato.
Inoltre la NPL consente a Netscape di inserire il codice sorgente originale di Communicator in altri prodotti che, per due anni, non possono essere soggetti alle condizioni previste per l’Open Source;
Licenza MPL (Mozilla Public License): Mozilla è la versione Open Source del browser Web Netscape Navigator realizzato da Netscape e successore del programma Communicator.
A seguito delle eccezioni sollevate dalla comunità Open Source in merito alla Licenza NPL venne formulata una nuova Licenza.
Essa in sostanza risulta essere un estratto della Netscape Public License, eccetto per quanto riguarda i diritti speciali di cui risulta priva trattandosi di una Licenza maggiormente diretta a promuovere la comunità Open Source. Tanto la NPL quanto la MPL consentono, in ogni caso, di mantenere private le modifiche apportate;
Licenza Artistica: originariamente sviluppata per il linguaggio di programmazione Perl, la Licenza Artistica è stata successivamente
67
adoperata per altri prodotti Software. Si tratta di una Licenza formulata in modo piuttosto impreciso, poiché, pur imponendo determinati requisiti, fornisce poi delle scappatoie che rendono facile aggirarli: prorio per tale ragione quasi tutto il Software sotto Licenza Artistica ha oggi una seconda Licenza molto spesso costituita dalla Licenza GPL;
Licenza Shareware: il Software Shareware è distribuito unicamente nella sua forma eseguibile e, tanto il suo possesso quanto il suo utilizzo, non richiede l’acquisto del prodotto. La Licenza in oggetto prevede la distribuzione libera e gratuita per un periodo di prova (trial) e solo in seguito risulta necessaria la registrazione del prodotto ed il pagamento di un prezzo di acquisto.
Obiettivo della Licenza è quello di diffondere l’uso del Software con rapidità e farne saggiare le qualità dello stesso ad una vasta platea di utenti prima dell’acquisto.
Si tratta di una Licenza di tipo non Open Source visto che non consente la distribuzione del codice sorgente;
Licenza Freeware: essa consente di distribuire e utilizzare liberamente e gratuitamente il Software, limitando tali libertà alla sola forma eseguibile per soli scopi privati e non commerciali: tali peculiarità costituendo delle discriminazioni per l’Open Source non consentono di classificarla come tale.
Da quanto sopra è possibile desumere le principali differenze che caratterizzano alcune delle Licenze esaminate estrapolandone i criteri di peculiarità:
Open Source e Software: Le Licenze Open Source a) gratuità del prodotto, ovvero eventualità di disporne a costo zero;
b) possibilità di distribuire liberamente il prodotto;
c) libera utilizzazione determinata dalla mancanza di restrizioni per l’utilizzo del Software;
d) disponibilità del codice sorgente;
e) possibilità di modificare liberamente il prodotto;
f) protezione della libertà o caratteristica Copyleft consistente nell’obbligo di mantenere le versioni di prodotto derivate conformi alle regole Open Source;
g) possibilità di mixare parti di codice Open Source e parti di codice proprietario all’interno di un prodotto nuovo.
Lo studio di queste caratteristiche consente di individuare all’interno dell’insieme delle Licenze Open Source, una scala di restrizione delle Licenze:
il grado di restrizione di una Licenza Open Source nei confronti delle altre Licenze è dato dalla possibilità di combinare prodotti Open Source con prodotti simili o proprietari e dal grado di protezione delle libertà conferito dalle Licenze stesse.
Ne consegue che la scelta della Licenza appropriata allo specifico Software risulta alquanto difficile ma di importanza strategica e soprattutto vitale per lo
69
stesso Software in quanto, molto probabilmente, la sua diffusione ed evoluzione sarà inevitabilmente ad essa collegata.
Tabella di Confronto fra licenze
Open Source e Software: Come scegliere una licenza
3.02) Come scegliere una Licenza.
Alla base di ogni progetto, e quindi anche in campo Open Source, occorre attuare tutta una serie di scelte che in sostanza definiscono quella strategia che consente di rendere un prodotto disponibile agli utilizzatori finali sia che si parli di un prodotto commerciale che di un prodotto libero.
In campo Software, alla base dello sviluppo di un prodotto, sussiste sempre un’idea ma ogni fase deve comunque essere pensata e selezionata al fine di ottenere i risultati desiderati. Ultimo ma non di minore importanza, anzi di fondamentale rilevanza, risulta la scelta della Licenza che sarà applicata al Software per la sua distribuzione.
La scelta della Licenza riveste un ruolo chiave in tutte le fasi del progetto in quanto è proprio essa, oltre che la qualità del Software, a determinare il grado di gradimento ed assimilazione del prodotto da parte della platea di utenti a cui è rivolto (ed eventualmente anche dal mercato).
Innanzitutto occorre riflettere se si necessita di una Licenza del tutto nuova che abbia caratteristiche innovative rispetto a quelle implementate in altre Licenze a disposizione nel panorama legislativo vigente. In questo caso sicuramente oltre che al supporto di esperti del settore informatico sarà necessaria la consulenza di un supporto legale tenendo ben presente due fondamentali aspetti:
- molto spesso, la proliferazione di Licenze diverse tra loro opera a discapito del Software tipicamente Open Source;
- l’eventuale incompatibilità fra Licenze non permette di combinare parti di programmi provenienti da prodotti diversi.
71
Occorre quindi analizzare il target di utenti a cui si rivolge il Software al fine di determinare la distribuzione e quindi la scelta della Licenza più idonea: gli sviluppatori saranno indubbiamente più interessati alla possibilità di avere disponibile il codice sorgente mentre gli utilizzatori finali sono invece interessati alla possibilità di sfruttare il maggior numero di applicazioni possibili.
Inoltre, in ambito Open Source, la scelta della Licenza influisce spesso su altri progetti che possono in qualche modo competere ovvero completare il progetto: da questo punto di vista un programma rilasciato sotto GPL potrebbe rivelarsi inutile per un altro progetto Open Source licenziato sotto BSD a causa dell’incompatibilità fra le due Licenze implicando minori o maggiori possibilità di profitto da parte di chi vende programmi o fornisce supporto agli stessi.
Nella selezione della Licenza da utilizzare, lo sviluppatore è poi chiamato a valutare la gamma di benefici che il progetto potrebbe portare. Questi ricomprendono:
- la motivazione intrinseca fornita dalla sfida intellettuale;
- la gratificazione personale, e gli incentivi concernenti possibili offerte di lavoro;
- la necessità di risolvere un problema concreto;
- la possibilità di trarre benefici materiali offerti dai ritorni di operazioni commerciali legate al progetto.
Open Source e Software: Come scegliere una Licenza
Lo sviluppatore dovrà quindi valutare in che modo questa gamma di motivazioni influenzerà tutta una serie di condizioni generali. Nella scelta della Licenza è infatti necessario prestare attenzione ad una serie di fattori:
a) il progetto Open Source se isolatamente considerato potrebbe non avere successo ma, la sua combinazione con altri prodotti Software complementari o di supporto, potrebbe essere un fattore chiave per la sua affermazione. Questi ultimi possono essere, a loro volta, tanto Open Source quanto prodotti proprietari. La Licenza influenza quindi anche il modo in cui i diversi prodotti Software si combinano: per esempio, non ammettendo la combinazione con programmi proprietari, la GPL scoraggia la potenziale utenza commerciale. La scelta della Licenza dipende, inoltre, dall’individuazione del settore in cui s’intende rilasciare il prodotto: nel caso si operi in un ambito che utilizzi Licenze restrittive che non consentono modifiche proprietarie al programma lo sviluppatore sarà spinto a scegliere una Licenza dello stesso genere per garantire l’integrazione con gli altri programmi. Un progetto che adotti una Licenza restrittiva potrebbe invece non avere successo in un settore dominato da progetti rilasciati sotto BSD in considerazione del fatto che essa consenta di rendere proprietarie le modifiche apportate al programma;
b) i programmi rilasciati sotto una licenza Open Source potrebbero diventare preda di aziende commerciali che, una volta modificato il codice sorgente originario con parti di codice proprietario, farebbero proprio l’intero progetto. Sebbene il programma risultante possa essere superiore, il soggetto commerciale avrebbe in ogni caso inciso negativamente sulle dinamiche del progetto Open Source in quanto, quantunque il Software possa suscitare scarso interesse, la chiusura del codice priverebbe, in ogni caso, la comunità di tutta una serie di benefici che il progetto avrebbe
73
potuto garantire quali il pagamento di una certa somma di denaro, la possibilità di apportare modifiche o di sviluppare nuove versioni migliorate. In merito, tuttavia, occorre osservare che questo problema sarebbe comunque facilmente superabile da parte di un’azienda commerciale in quanto la stessa, attraverso un’attività di reverse engineering, sarebbe in grado di replicare le funzionalità e le caratteristiche del Software originario: ciò dipende dal fatto che, a differenza della protezione garantita dal sistema dei brevetti, la proprietà intellettuale tutela esclusivamente l’espressione e non le idee ad essa sottostanti;
c) rilevante importanza riveste l’impatto dei brevetti sul Software in quanto l’apertura di azioni legali rivolte alla tutela dei diritti derivanti dalla violazione di un brevetto potrebbe ostacolare lo sviluppo del progetto e scoraggiare tanto gli sviluppatori quanto i potenziali utenti;
d) in ultimo luogo, lo sviluppatore dovrà chiarire quali esigenze di tipo tecnico intenda realizzare:
1) qualora si desideri che le modifiche apportate al Software originario siano rese nuovamente disponibili allo sviluppatore e quindi rilasciate anche all’intera comunità è necessario applicare una Licenza che lo prescriva come la GPL o la LGPL; in caso contrario, è possibile fare ricorso alla Licenza X o Apache le quali consentono di mantenere private le eventuali modifiche apportate;
2) qualora si intenda invece autorizzare altri soggetti a far confluire il proprio programma nel Software proprietario sarà possibile utilizzare la Licenza LGPL che prevede questa eventualità rendendo
Open Source e Software: Come scegliere una Licenza
comunque privato il codice sorgente; in alternativa, è possibile fare ricorso alla Licenza X o Apache le quali consentono di mantenere private le eventuali modifiche apportate;
3) in caso si desideri consentire, a chi volesse, di comprare versioni del Software tutelate da Licenza commerciale sarà il caso di dotare il prodotto di doppia Licenza: la GPL potrebbe, in tal caso, essere la Licenza Open Source.
Da quanto esposto risulta evidente che la scelta della Licenza non è così semplice anzi è il fattore fondamentale affinché il Software sviluppato ottenga il successo che merita e, cosa ancor più importante, ne determina il suo utilizzo, l’integrazione con altri Software e l’eventualità di poter integrare modifiche esterne o di poter successivamente rilasciare nuove versioni del prodotto.
Schema possibile di scelta di una Licenza
75
3.03) La proprietà nell’Open Source.
Da un punto di vista prettamente sociologico risulta interessante analizzare le motivazioni che soggiacciono alla scelta, da parte di numerosi sviluppatori di Software, di rinunciare a cospicue remunerazioni pur di partecipare allo sviluppo di progetti o prodotti Open Source.
A tale scopo risulta indispensabile stabilire chiaramente il rapporto che lega un programmatore ad un progetto in quanto tale operazione diviene alquanto difficile e sicuramente viene complicata dal fatto che, nell’ambito delle nuove tecnologie digitali, l’istituto giuridico della proprietà perde le proprie tradizionali connotazioni: l’oggetto del diritto è già di per sé immateriale essendo costituito da un’opera assimilabile a quelle intellettuali ma, non solo, in questo ambito esso diventa liberamente accessibile attraverso la rete e soggetto pertanto a subire delle modifiche o essere replicato all’infinito pur mutando continuamente l’aspetto prettamente esteriore.
Nel contesto Open Source, tuttavia, il problema dell’individuazione del proprietario del programma e della definizione del contenuto del suo diritto deve essere subito ridimensionato: il detentore del progetto è, infatti, comunemente identificabile nel soggetto che detiene il diritto esclusivo di redistribuire le versioni modificate. Stando così le cose, è possibile fare una prima importante considerazione: se è vero che le Licenze Open Source consentono a chiunque di modificare il programma è tuttavia necessario tenere distinti gli aggiustamenti ufficiali, approvati dalla comunità e incorporati nel Software in evoluzione da parte di chi dirige il progetto, da quelli realizzati da soggetti estranei al progetto e non inseriti nella versione ufficiale e che d’altronde sono in genere malvisti all’interno della comunità.
Avendo fugato ogni dubbio circa il rapporto esistente tra programmatore di un determinato progetto e relativo Software Open Source, il problema da
Open Source e Software: La proprietà nell’Open Source
affrontare si sposta sulle fasi inerenti il momento del concepimento e dello sviluppo del prodotto.
La cultura Open Source distingue, tradizionalmente, tre modi di acquisire la proprietà di un programma:
1) avviare lo sviluppo del progetto: in tale ipotesi proprietario del progetto a titolo originario deve essere considerato colui che scrive una massa critica di codice da sottoporre alla comunità di sviluppatori o, in ogni caso, chi, sin dall’origine, coordina la stesura del programma;
2) ottenere la proprietà del progetto acquisendola dal proprietario precedente: quando si viene a determinare la mancanza del proprietario del progetto dovuta all’impossibilità da parte dello stesso di curare lo sviluppo o il mantenimento dello stesso è usanza che sia la comunità ad eleggere, quale suo legittimo successore, il programmatore ritenuto più competente tra quelli più vicini al progetto;
3) reclamare un progetto vacante facendo pubblicamente presente il disinteresse o la scomparsa del proprietario: in questa fattispecie le consuetudini comunitarie richiedono al potenziale proprietario di fare quanto possibile per rintracciare il precedente detentore per poi dichiarare, attraverso l’esternalizzazione delle proprie intenzioni rese pubbliche mediante la partecipazione a forum in rete ovvero a mezzo newsgroup, di voler proseguire lo sviluppo del prodotto.
In generale, l’acquisizione risulterà tanto più consolidata, quanto maggiori saranno gli sforzi per consentire al proprietario di riprendere il controllo del progetto.
77
L’evoluzione di tali consuetudini, seguite con notevole coerenza dalla totalità dei membri della comunità, ha finito per ripercuotersi in modo positivo sui comportamenti di tutti i membri della comunità. Tale procedura ha consentito lo sviluppo e il determinarsi di una coscienza collettiva attenta e responsabile rivolta a preservare i nomi degli sviluppatori che partecipano a ciascun progetto conservandone la cronologia delle modifiche.
Sembrerebbe quindi che nella realtà Open Source, la rinuncia ai diritti d’utilizzazione economica dell’opera, sia compensata in larga parte da un interesse condiviso, largamente riconosciuto e rivolto alla tutela del diritto alla paternità dell’opera.
Il riconoscimento di questi meriti consacra il suo autore ad essere ricordato per il contributo apportato all’intera collettività oltre che ad essere apprezzato per le idee profuse, la qualità tecnica delle soluzioni ed al risultato ottenuto.
Schema di confronto delle strategie relative a proprietà e controllo
Open Source e Software: Sviluppo del Software
3.04) Sviluppo del Software.
Le fasi relative allo sviluppo di un prodotto Software sono innescate dall’input iniziale costituito dall’idea originaria che, al termine del processo, consentiranno di ottenere un output fondamentalmente rappresentato dal prodotto e possono essere distinte in cinque stadi evolutivi:
1) Concept Development (Sviluppo del concetto di prodotto).
In questa fase viene determinato il segmento target in cui dovrà posizionarsi il prodotto: vengono definite le sue specifiche (funzionalità, interoperabilità, interattività, ecc.) e unitamente vengono svolte delle indagini di mercato dirette all’analisi dei prodotti concorrenti e stilato un rapporto di valutazione economica che ne giustifica lo sviluppo;
2) System-level design (Progetto a livello di sistema).
Il programma viene definito nella sua architettura suddividendolo in sottosistemi e componenti opportunamente descritti e dettagliati determinando un diagramma di flusso relativo al processo di assemblaggio finale;
3) Detail design (Progetto di dettaglio).
In questa fase vengono eseguite le seguenti attività:
- descrizione di dettaglio di ogni componente;
- distinzione di parti proprietarie e parti destinate allo sviluppo esterno;
- rilevazione di risorse disponibili e destinazione di risorse necessarie;
79
- redazione della relazione di controllo che descrive e dettaglia tutti i processi di sviluppo del Software fino al suo assemblaggio finale;
4) Testing e refinement (Testing e raffinamento).
In questa fase vengono realizzate le prime versioni del Software definite:
- alpha: è una fase embrionale in cui molte componenti sono incomplete ed è utilizzata per verificare i requisiti qualitativi richiesti dal prodotto;
- beta: è una versione completa ma non definitiva in quanto necessita di ulteriori aggiornamenti e correzione di bug.
Questi prototipi sono utilizzati in fase di test interni oltre che distribuiti ad un certo numero di utenti finali per sottoporli a valutazione in reali situazioni di utilizzo;
5) Production ramp-up (pre-produzione).
Utilizzando il progetto di dettaglio ed il flusso di assemblaggio vengono prodotte le prime versioni ufficiali del Software che verrà distribuito inizialmente in quantità limitate al fine comunque di poterne saggiare le qualità e poter evidenziare eventuali imperfezioni che andranno eliminate per arrivare con gradualità ad una versione stabile ed efficiente del prodotto.
Nella fase centrale, quella di sviluppo del Software vero e proprio, in base alle regole dettate dall’Ingegneria del Software, devono essere rispettati alcuni principi fondamentali tra i quali risultano di particolare importanza:
Open Source e Software: Sviluppo del Software
- Conservazione: il Software deve poter evolvere continuamente per conservare la propria qualità ed utilità nel tempo;
- Affidabilità: il Software non deve procurare danni fisici ed economici all’utente né propagare l’errore verso altri sistemi;
- Efficienza: il Software deve consentire un efficiente impiego delle risorse tecnologiche;
- Utilizzabilità: l’interfaccia utente deve essere appropriata e di facile utilizzo;
Nella fase di sviluppo del Software è possibile mettere a confronto diversi modelli o strategie indispensabili da attuare al fine di ottenere il prodotto con le caratteristiche migliori in rapporto a risorse e fattori impiegati:
a) Modello Build and Fix: in questo tipo di approccio non è stabilita una sequenzialità nelle attività di sviluppo per cui molto spesso la qualità del risultato è in funzione delle capacità e dell’esperienza del personale tecnico. Ciò determina una continua variazione del processo non potendo assicurare quindi elevati livelli di produttività né il mantenimento di quelli raggiunti nel tempo.
Questo modello spesso, però, risulta adatto solo a piccoli progetti che non necessitano di numerosi aggiornamenti in quanto, altrimenti, rischia di divenire antieconomico a causa dei seguenti motivi:
- l’uscita dal progetto di soggetti chiave;
81
- costi esponenziali dovuti alle modifiche necessarie fino al rilascio del prodotto finale;
- lentezza del processo di sviluppo determinata da una confusa strategia di produzione;
b) Modello Waterfall: questo modello è caratterizzato da sei fasi specificamente studiate a tale scopo:
- Analisi e definizione dei requisiti auspicati dagli utenti;
- Progettazione del sistema e del processo di sviluppo attraverso dettagliate informazioni relative al processo di sviluppo e indispensabili per attuare la migliore distribuzione di risorse tecniche, umane e finanziarie utili a tali settori;
- Sviluppo e controllo delle singole componenti del sistema;
- Integrazione delle componenti e controllo globale del sistema riunendo e analizzando tutto il codice sorgente al fine di ricercare errori o imperfezioni e determinare così la versione finale del prodotto;
- Distribuzione e utilizzo in condizioni operative del prodotto sottoponendo una versione beta dello stesso ad un gruppo di utenti che ne testerà la validità in condizioni reali di utilizzo consentendo così la correzione di errori, la modifica di moduli e lo sviluppo di nuove funzionalità richieste;
Open Source e Software: Sviluppo del Software
- Ritiro del sistema dovuto al mancato apprezzamento dal mercato.
Il Modello Waterfall è caratterizzato della sua linearità: in tal modo le fasi di sviluppo sono tutte eseguite in sequenza e si perviene al completamento di un ciclo prima di dare avvio a quello successivo il che ne determina la sua ripetibilità rendendolo meno soggetto ad interferenze e consentendo il miglioramento dei processi e della qualità dei risultati ottenibili.
I lati negativi intrinseci nel modello risiedono nella necessità di pervenire ad una perfetta conoscenza dei requisiti del sistema già in fase di progettazione il che risulta difficile specie in caso di Software complessi con la conseguenza che cambiamenti e modifiche inaspettate determinerebbero un aumento considerevole sia del tempo necessario a realizzarli sia dei costi ad essi correlati;
c) Modello Iterativo: esso prevede fin dall’inizio la suddivisione del progetto in più cicli reiterati ognuno dei quali costituisce un Modello Waterfall con l’esecuzione di tutte le attività di progettazione, sviluppo e testing ottenendo così un’evoluzione incrementale del prodotto.
Sebbene sia il processo di sviluppo quanto l’architettutra del prodotto possano essere definiti in modo meno rigoroso e completo rispetto al modello Waterfall si potrebbe verificare un problema definito di “evoluzione strisciante” del prodotto che necessiterebbe l’introduzione di nuove funzionalità in ogni ciclo
83
di iterazione il che potrebbe determinare un’eccessiva instabilità e possibili inefficienze difficilmente gestibili;
d) Modello Evolutivo: il modello ripropone il concetto di evoluzione incrementale del prodotto e, in aggiunta, introduce la possibilità di rendere parallela l’esecuzione dei singoli cicli di sviluppo.
I rischi di natura organizzativa del modello sono accentuati dall’introduzione del concetto di parallelismo da cui discende che le diverse soluzioni svilupppate potrebbero risultare incompatibili fra loro. Di conseguenza viene a determinarsi un’inefficienza nell’uso delle risorse ed eventuali problemi di integrità e quindi di qualità del prodotto;
e) Modello del Prototipo: questo modello richiede il continuo aggiornamento delle informazioni relative al processo evolutivo ed al processo di sviluppo del Software che viene così ad essere suddiviso in due parti distinte: la prima fase è diretta allo sviluppo del prototipo mentre la seconda alla versione effettiva.
La costruzione del prototipo richiede la definizione dei relativi requisiti, la progettazione e lo sviluppo: attività queste che necessitano quindi di un’accurata analisi e di informazioni molto dettagliate del prodotto richiesto.
Questo modello, applicato a progetti anche complessi, consente di ridurre i rischi di sviluppo specie per prodotti innovativi con conseguenti risparmi in termini di tempi e costi totali;
f) Modello a Spirale: il modello a spirale riassume le peculiarità dei Modelli Iterativo, Evolutivo e del Prototipo. Esso è caratterizzato da una continua ripetizione dei cicli tipici del
Open Source e Software: Sviluppo del Software
Modello Waterfall; all’interno di ciascun ciclo si ha la sovrapposizione delle attività di progettazione, sviluppo e controllo del codice; viene eseguita una continua revisione delle informazioni raccolte in ogni fase di sviluppo.
Questo modello risulta adattarsi alla dinamicità del Software e soddisfa la necessità di avere un processo di sviluppo molto flessibile abbandonando un approccio di tipo sequenziale e seguendo un’evoluzione di sviluppo del progetto che graficamente può essere rappresentato appunto da una spirale.
Il modello a spirale consente di individuare ed eliminare i rischi e gli errori più velocemente ed assicurare una qualità del progetto più elevata. Per contro necessita di un elevato grado di esperienza e la disponibilità di risorse umane e finanziarie elevate per implementare le procedure.
Il Modello a Spirale, attualmente molto diffuso, viene utilizzato anche da Microsoft con il nome di Modello Synch and Stabilize (Sincronizza e Stabilizza);
g) Modello del Riutilizzo: ai fini dello sviluppo dei prodotti questo tipo di strategia propone il riutilizzo di componenti e parti già esistenti organizzati in librerie per consentire una facile ricerca degli stessi. Il loro uso avviene in base a due modalità:
- il componente viene inserito in modo diretto adattandolo nel contesto nel quale viene a posizionarsi;
- il componente viene sottoposto ad un processo di adattamento e modifica e quindi inserito nel progetto.
85
Nel caso in cui il componente non sia disponibile occorrerà crearlo, inserirlo nella libreria e quindi utilizzarlo.
La strategia del riutilizzo è impiegata per abbattere i costi ed i tempi di sviluppo e per assicurare una certa affidabilità dei prodotti. Ciò comporta comunque la necessità di poter disporre di una libreria composta da numerosi componenti e la previsione di un loro riutilizzo ripetuto.
Schema riassuntivo dei punti di forza e debolezza di alcuni modelli di sviluppo
Questi modelli tipo utilizzati in campo informatico nello sviluppo del Software rappresentano una classificazione teorica e schematica degli stessi in quanto spesso, all’atto pratico, essi vengono combinati fra loro o modificati al fine di sfruttarne appieno i vantaggi ed attenuarne le debolezze col fine ultimo di ottimizzare la produzione. Particolare attenzione riveste poi l’osservazione di un particolare schema di sviluppo Software adottato da una delle maggiori case produttrici e definito:
Open Source e Software: Sviluppo del Software
h) Modello Synch and Stabilize: è il modello utilizzato da Microsoft ed in sostanza è una personalizzazione del Modello a Spirale. Esso si basa sulla continua sincronizzazione delle attività di sviluppo e sulla periodica stabilizzazione dei prodotti.
Le specifiche del progetto non sono statiche ma si evolvono durante tutto il processo di sviluppo.
Si preferisce evitare lo sviluppo di un prodotto completo in un unico ciclo ma distribuire la definizione dei dettagli ed il miglioramento del Software in più cicli successivi (come nel Modello Iterativo).
Microsoft ha inoltre cominciato ad introdurre il concetto di modularità specificatamente studiato per prodotti caratterizzati da rapidi cicli di vita.
Le attività di sviluppo e testing risultano reiterate in ocni ciclo e rese simultanee con altri cicli durante tutto il processo di sviluppo (come nel Modello Evolutivo).
In fase di pianificazione sono stabilite le caratteristiche del prodotto e le sue specifiche.
Inoltre, le informazioni ottenute nei vari cicli sono utilizzate al fine di identificare e migliorare le caratteristiche del prodotto e stabilire tra loro delle priorità il che consente di minimizzare il numero di funzionalità sviluppate contemporaneamente in un singolo ciclo della spirale (come nel Modello a Spirale).
In tal modo vengono sviluppate solo le caratteristiche ritenute necessarie per realizzare un prodotto utile tenendo presenti le esigenze e le richieste degli utenti ed evitando un inutile dispendio di risorse ed energie.
87
Queste ultime sono assegnate in funzione delle differenti specifiche di prodotto a diversi team di sviluppo ognuno dei quali è costituito da un numero uguale di programmatori e addetti al testing in grado di lavorare parallelamente sul codice.
Ogni attività di sviluppo è suddivisa in sottoprogetti il che consente l’inserimento di cambiamenti nel corso dello sviluppo del prodotto e risolvere possibili eventi inaspettati.
Giornalmente viene richiesta l’integrazione (Synch) dei codici sviluppati attraverso la produzione di una release unica e condivisa dall’intero team: in tal modo la maggior parte degli errori viene individuato al momento opportuno evitando che gli stessi si propaghino nei cicli successivi.
Segue la fase di stabilizzazione (Stabilize) in cui si attua il congelamento delle caratteristiche sviluppate per proseguire verso un loro completo e definitivo perfezionamento.
Si arriva così alla fase di testing in cui il prodotto viene sottoposto a funzionamento in base a reali condizioni di utilizzo.
Sono individuati due livelli di testing:
- interno, effettuato dal personale dell’azienda nei laboratori dedicati;
- esterno (beta testing), sottoponendo il prodotto a fasce di utenti costituite sia da professionisti che semplici utilizzatori.
Superato il testing viene redatta la documentazione di supporto al prodotto accompagnato dalla release finale (gold master copy) necessaria per la produzione delle copie destinate al mercato.
Open Source e Software: Sviluppo del Software
Nel caso in cui il test produca risultati negativi il progetto ritorna nel ciclo di sviluppo al fine di eliminare difetti e malfunzionamenti.
Schema di confronto tra sviluppo di tipo Open Source e modello Microsoft
Le caratteristiche di funzionamento della comunità Open Source non consentono di individuare un modello di sviluppo del Software ben definito e standardizzato potendo evidentemente avvicinare lo sviluppo del Software al Modello Build and Fix caratterizzato da talune influenze tipiche dei Modelli Iterativo ed Evolutivo. La combinazione dei tre modelli può essere sfruttata soprattutto nei casi di progetti complessi in cui si può notare la forza della comunità i cui sforzi sono rivolti al miglioramento del codice attraverso ripetute fasi di aggiornamento delle funzionalità dei programmi determinando così una crescita incrementale delle loro potenzialità.
Dato inoltre il diffuso utilizzo delle librerie Software è possibile lo sfruttamento del Modello del Riutilizzo.
89
Il modello Open Source, in sostanza, accogliendo in buona parte gli insegnamenti ed i punti di forza di diversi modelli di sviluppo, potrebbe essere assimilato al Modello a Spirale.
Sebbene il modello Open Source sia differente a prima vista da quello Microsoft, essi hanno notevoli punti di contatto e talune caratteristiche tipiche del modello open sono state recepite ed adottate anche da Microsoft.
Una caratteristica tipica del sistema Linux è costituita dalla modularità dei suoi componenti che determina il funzionamento ottimale di ogni singola funzione consentendo uno sviluppo parallelo dei progetti pur avendo un controllo centralizzato sugli stessi e facilitando quindi l’introduzione di nuove parti di codice nel progetto.
Dal punto di vista Microsoft la modularità sembra essere stata introdotta attraverso i linguaggi ad oggetto anche se l’approccio è ancora rivolto allo sviluppo integrale che consente una facile distribuzione e vendita di diversi prodotti riuniti in un unico pacchetto.
Mentre per Microsoft il parallelismo è associato a ridondanza, spreco inutile di risorse e scarsa ottimizzazione di sforzi e risultati, risulta evidente che nel mondo Open Source il parallelismo viene considerato un vantaggio: il lavoro di più soggetti sullo stesso progetto consente infatti risparmi di tempo, risoluzione di problemi ed evoluzione esponenziale dei risultati.
In ambiente Microsoft lo sviluppo di nuove idee non può essere preso in considerazione subito ma deve essere pianificato essendo correlato un costo a ciascuno di essi. Nell’Open Source le idee nascono tanto dall’apporto fornito dalla comunità che da apporti esterni: esse possono essere sviluppate sia interrompendo il processo legato allo sviluppo del prodotto che attivando un nuovo processo o addirittura lo sviluppo di un nuovo prodotto: tutto ciò è favorito dalla disponibilità di risorse umane e tecnologiche potenzialmente illimitate ed a costi irrisori.
Open Source e Software: Sviluppo del Software
Sebbene la Microsoft effettui fasi di testing sui suoi prodotti in maniera accurata e su una larga fascia di utenti spesso molto competenti in materia è pur vero che essi non hanno a disposizione il codice sorgente: questo, invece, è disponibile in ambito Open Source per cui si assiste ad una revisione dei prodotti completa e rapidissima.
Infine, sebbene i prodotti Microsoft vengano studiati per risolvere le esigenze degli utenti, sviluppando anche configurazioni particolari, nel mondo Open Source il codice sorgente consente agli utenti o sviluppatori di risolvere ogni problematica adattando il Software alle diverse esigenze che potrebbero necessitare agli utilizzatori.
Schema di confronto tra metodologie di sviluppo Software
91
3.05) Creatività, qualità ed etica del lavoro.
Tra gli sviluppatori riveste particolare rilevanza non tanto il lavoro in sé che spesso si confonde con quella che è una passione quanto invece la qualità del lavoro stesso basato molto su quella che viene chiamata “vena creativa”.
La creatività, in pratica, altro non è che la capacità di individuare problemi e risolverli grazie anche all’intuizione ed alla scaltrezza di combinare idee e conoscenze per proporre soluzioni diverse, migliori o più affidabili di quelle già adottate.
Tuttavia, analizzando con metodo scientifico il funzionamento che soggiace al pensiero creativo, ci si rende conto che, molto spesso, ad innescare un particolare meccanismo intuitivo concorrono sia l’esperienza che la motivazione.
L’esperienza è rappresentata da quell’insieme costituito da bagaglio culturale, intellettuale e professionale acquisiti nel tempo dall’individuo e grazie elle quali risulta possibile analizzare il problema, scomporlo nei suoi fattori primi ed arrivare così a raggruppare a fattor comune i metodi risolutivi conosciuti per realizzare concretamente l’intuizione risolutiva.
Per quanto concerne la motivazione, essa si fonda tanto su aspetti esterni quanto su aspetti interiori: nei primi rientrano gli incentivi economici, le attività svolte, l’attrazione verso l’apprendimento di nuove conoscenze; nella seconda categoria invece rientrano passione, interesse e soddisfazione.
Si nota spesso che la creatività è “solleticata” più da motivazioni interiori condite da un senso di sfida e di competizione rivolti alla risoluzione del problema.
Difatti quando di converso il lavoro è interpretato come un peso genera spesso insoddisfazione che si riflette sulla qualità e sui risultati.
Open Source e Software: Creatività, qualità ed etica del lavoro
E’ evidente inoltre che il coinvolgimento di un soggetto in un’attività, se opportunamente stimolata diminuendo la tensione e la pressante necessità di risultati, favorisce un aumento dell’attenzione e concentrazione portando a sfruttare meglio le potenzialità creative.
Molto importante risulta poi lo sviluppo di attività dirette all’apprendimento, all’esplorazione e sperimentazione di nuovi concetti che devono essere accompagnati soprattutto da una fase di gioco inteso tanto in forma ludica vera e propria quanto in forma di manipolazione creativa.
Soprattutto in campo Software e, molto più nell’Open Source in cui ci si trova a confrontarsi con un’intera comunità di utenti e programmatori, questi concetti assumono valore aggiunto determinato dalla constatazione che lo sviluppatore di Software spesso è autodidatta: il suo iniziale interesse è rivolto ai giochi, quindi all’idea di realizzarli e poi a spaziare nella programmazione.
Inoltre, nella filosofia Open Source viene a determinarsi quella che è definita anche “etica hacker”.
In questa nuova definizione il denaro e, più in generale il ritorno economico, sono solo un mezzo ma non sono di fondamentale importanza essendo il lavoro fonte di gratificazione e di intrattenimento.
Ne risulta un’etica basata su valori quali passione, libertà, coinvolgimento, valore sociale, apertura e, soprattutto, divertimento in cui il propulsore motivazionale è dato dall’acquisizione di reputazione, dalla qualità e dalla genialità delle soluzioni adottate nella risoluzione dei problemi e riconosciute come tali degne di rispetto dalla comunità degli sviluppatori.
Sebbene queste attitudini si rivelino principalmente in attività di tipo scientifico o artistico e sembri quasi utopistico che possano essere applicate nel modo di concepire il lavoro, è pur vero che questo nuovo modo di interpretare il lavoro può scavalcare i limiti tradizionali in cui la sua concezione è stata relegata arrivando così alla conclusione che proprio la creatività è difficilmente riproducibile tramite processi e fattori tecnologici.
93
Ne deriva che potrà cambiare in futuro il modo di concepire il lavoro o la sua organizzazione ma difficilmente esso potrà essere annullato dalla tecnologia.
In conclusione il mondo Open Source ancora una volta si dimostra essere fonte per nuovi spunti di riflessione in grado di dimostrare con sempre più determinazione quanto siano solide le basi su cui si fonda la filosofia tipica quasi di avveniristici cavalieri fantascientifici che saltano fuori dalle pellicole dei film di George Lucas: “Open Source: che la forza (del codice sorgente) sia con te…”.
Open Source e Software: Reputazione come valore, ricompensa, incentivo
3.06) Reputazione come valore, ricompensa, incentivo.
Se l’atto di delimitare i confini della propria opera, di svilupparla, migliorarla e di difenderne il titolo di proprietà è di così fondamentale importanza per la comunità degli sviluppatori, lo scopo, non ultimo, è quello di trarre da questa serie di sforzi, un qualche tipo di provento.
Risulta, infatti, che, in base alle modalità di acquisto della proprietà, lo/gli sviluppatori del Software abbiano dovuto sostenere dei costi tanto in impegno, energia e dedizione quanto anche economici diretti all’avvio del progetto, al mantenimento delle cronologie delle documentazioni approvanti i passaggi di consegna da un mantainer all’altro, al tempo impiegato nei forum e nei newsgroup, all’attesa per potersi impossessare di un progetto vacante, tutti oneri questi che, in qualche modo, devono comunque essere bilanciati da un feedback positivo.
E’ necessario quindi indagare circa la definizione di questa entità valoriale che spinge gli sviluppatori a partecipare ad un progetto Open Source.
Osservando il campo d’azione in cui si effettua l’esplorazione occorre in primis escludere da ogni ipotesi che questo incentivo possa essere rappresentato dalla conquista di una posizione di potere all’interno della comunità, non potendo sussistere, all’interno di una rete globale, rapporti di forza.
Gli sviluppatori non mirano, inoltre, ad ottenere un compenso materiale dal momento che il modello di sviluppo non prevede un’equivalente al denaro.
Tuttavia occorre chiarire che, sebbene la stessa filosofia Open Source si basi sulla negazione del perseguimento del fine di lucro, è comunque possibile l’evenienza di un ritorno di tipo economico: può accadere, infatti, che la reputazione acquisita all’interno della comunità consenta allo sviluppatore di ottenere migliori posti di lavoro o richieste di consulenza nel campo
95
dell’industria Software tradizionale quantunque tale effetto collaterale sia raro e marginale.
A questo punto è possibile analizzare il concetto mettendolo a confronto con quello puramente commerciale tipico del Software proprietario.
L’adesione ad un progetto Software, sia esso commerciale od Open Source, sono accomunate comunque dalla possibilità di trarne un beneficio: in particolare tale utilità comprende una ricompensa immediata e una differita.
Alla prima categoria è, senza dubbio, riconducibile il compenso in denaro ricevuto per l’attività di programmazione svolta: si tratta dell’ipotesi ricorrente nel caso in cui il programmatore sia impiegato in un’azienda commerciale.
Esistono poi altri tipi di ricompensa immediata che sono più vicini ai progetti Open Source: tra essi rientrano la libera fruibilità del codice sorgente del programma, la possibilità di correggere gli errori del sistema o di adattare il programma alle proprie esigenze personali; la possibilità di poter distribuire una propria versione migliorata del Software.
Fin dalle sue origini, la cultura hacker ha insistito sull’importanza di guardare alla programmazione come ad un’attività di puro piacere e divertimento: in quest’ottica, la possibilità di ottenere un ritorno economico dall’attività del programmare sembra passare in secondo piano.
La seconda categoria di benefici, quella delle ricompense differite, comprende due distinti tipi d’incentivi: la possibilità di ottenere un avanzamento in carriera, da una parte, e la gratificazione personale, dall’altra.
Risulta infatti che lo sviluppatore si fa valere attraverso la propria attività di programmazione, può ambire a ricevere offerte di lavoro da parte di aziende commerciali o, in alternativa, essere talmente quotato da suscitare l’interesse di finanziatori pronti a supportare l’avvio di nuove imprese.
In merito alla gratificazione personale, questa va a scontrarsi, nel contesto Open Source, con il desiderio di ricevere un riconoscimento da parte degli altri
Open Source e Software: Reputazione come valore, ricompensa, incentivo
membri della comunità per cui si può assistere ad una sana competizione rivolta all’enfatizzazione delle proprie attività di programmatore.
In ogni caso, entrambe le categorie di incentivi descritte sono più forti quanto più visibile risulta il progetto: i programmatori preferiranno, quindi, lavorare su programmi che attraggono un gran numero di sviluppatori onde assicurarsi la possibilità di sottoporre il proprio operato all’attenzione degli altri membri della comunità, del mercato del lavoro o di quello dei capitali di rischio.
I progetti commerciali hanno, senza dubbio, un vantaggio nell’ambito delle ricompense immediate: dal momento che la natura proprietaria del codice genera un’entrata monetaria l’azienda trae vantaggio dall’offrire un salario ai propri dipendenti al fine di poter sfruttare il risultato della loro attività.
Pur non prevedendo la corresponsione di un salario per l’attività di programmazione prestata, il modello di sviluppo Open Source va, in ogni caso, incontro ad una riduzione dei costi per i programmatori in due modi:
- grazie alla sua libera disponibilità, il codice Open Source può essere utilizzato nelle Scuole e nelle Università a fini didattici implicando, quindi, una riduzione dei costi sostenuti per l’addestramento dei programmatori neofiti;
- il costo di un progetto Open Source è tanto minore quanto maggiore risulti essere l’apertura del codice sorgente del programma indispensabile per correzioni, modifiche e nuove versioni determinando quindi una sorta di economie di scala.
Nell’ambito delle ricompense differite, il metodo di sviluppo Open Source gode di un certo vantaggio rispetto all’approccio proprietario, essenzialmente per tre ragioni:
97
a) in relazione ad un programma commerciale, la qualità di programmazione, le sue funzionalità e le sue prestazioni possono essere valutate dall’esterno solo in maniera inesatta non essendo disponibile il codice sorgente; in un progetto Open Source, al contrario, non solo è possibile riconoscere il contributo di ciascun programmatore ma anche verificare se il lavoro svolto ha richiesto uno sforzo notevole, se è stato condotto in maniera logica e se il codice possa essere utile per lo sviluppo di future applicazioni;
b) avendo la piena responsabilità del proprio sottoprogetto, al programmatore è lasciata piena iniziativa avendo questi la responsabilità del successo del proprio sottoprogetto;
c) nel contesto Open Source il mercato del lavoro è caratterizzato da una maggiore fluidità: non essendo legati ad un’azienda specifica i programmatori sono liberi di dirigere i propri sforzi verso progetti eterogenei garantendosi in tal modo maggiori occasioni di visibilità.
In questo contesto, bisogna, inoltre, sottolineare l’importanza di altri tipi d’incentivi individuali evidenziando che i migliori progetti Open Source nascono da quello che Eric Raymond definisce “un prurito personale” vale a dire la necessità di dare un soluzione a problemi quotidiani.
Per comprendere il ruolo svolto dalla reputazione all’interno della cultura Open Source è necessario caratterizzare quest’ultima come una cultura del dono: in quanto tale essa si distingue per la relativa abbondanza delle risorse essendo potenzialmente illimitato sia lo spazio sul disco sia l’ampiezza della banda della rete sia da ultimo la potenza dei computer. Tale disponibilità di mezzi incide, inevitabilmente, sulle relazioni economiche tra gli individui, rendendo, in primo luogo, difficile l’instaurarsi di rapporti di comando: è, infatti,
Open Source e Software: Reputazione come valore, ricompensa, incentivo
improbabile che un qualsiasi soggetto possa ergersi ad autorità e decidere il modo in cui distribuire le risorse. L’abbondanza rende inoltre inutili le relazioni di scambio, eliminando la necessità d’interagire con altri soggetti al fine di ottenere ciò di cui si ha bisogno. Ne consegue che, in un’economia del dono, lo status sociale dell’individuo è determinato, non dalla possibilità di accedere al potere coercitivo o di controllare le cose, ma da ciò che si regala per cui, all’interno di tale cultura, l’unico ambito disponibile per la competizione sarà quello della reputazione fra i consociati.
Nella cultura Open Source l’elemento della reputazione trova la sua massima espressione: i programmi che si devolvono alla comunità sono, infatti, prodotti complessi e costituiscono la prova materiale del tempo e delle energie profuse nel progetto. A differenza di quel che accade per i beni materiali, il loro valore non è, tuttavia, facilmente stimabile: è, pertanto, determinato dal giudizio critico dei soggetti più esperti in materia, vale a dire degli altri sviluppatori.
Dal momento che proprio una buona reputazione è l’unico modo per ambire ad un miglioramento dello status sociale, lo sviluppatore è quindi spronato a creare prodotti di qualità al fine di ottenere il consenso della comunità.
Senza tralasciare il personale piacere che lo sviluppatore trae dalla programmazione, la ricompensa principale derivante dalla collaborazione in un progetto Open Source è, quindi, costituita dalla reputazione.
Se la reputazione rappresenta la massima ricompensa per tutti quelli che si dedicano allo sviluppo di Software Open Source, le consuetudini sviluppate in questa filosofia assicurano che i riconoscimenti vadano ai titolari effettivi e non ad altri.
La cultura Open Source ha, infatti, sviluppato una serie di consuetudini secondo cui:
- spetta al proprietario il diritto esclusivo di approvare le modifiche da apportare al programma e includerle nella versione ufficiale;
99
