OPEN SOURCE

OPEN SOURCE
Concetti chiave e implicazioni per le
scelte aziendali (fornitori e utenti)
OBIETTIVI
• Cosa sono i sw open source?
• Cosa li distingue dai sofware “non open”?
• Quali implicazioni per:
– I professionisti del SW e dei sistemi informativi
– Le strategie dei fornitori di sistemi ICT
– Le strategie delle aziende utilizzatrici
• Quali implicazioni per le “reti”?
Cosa sono i software Open Source
OPEN o no?
•
•
•
•
•
•
•
•
WINDOWS SERVER (web server)
APACHE (web server)
MS WINDOWS (sist. operativo)
GNU/LINUX (sist. operativo)
INTERNET EXPLORER (web browser)
MOZILLA FIREFOX (web browser)
WINZIP (utility compressione file)
EUDORA (client posta elettronica)
DUE PROSPETTIVE
• “Open” ossia: “l’uso è libero”
la questione delle licenze e copyright
• “Open” ossia: “lo sviluppo è comunitario”
 progetti di sviluppo a partecipazione aperta e
coordinamento “lasco”
Fonte: Muffatto-Faldani,
2006
Open source & free sw
OPEN o no?
•
•
•
•
•
•
•
•
WINDOWS SERVER (web server)  proprietario
APACHE (web server)  open source
MS WINDOWS (sist. operativo) proprietario
GNU/LINUX (sist. operativo)  free software
INTERNET EXPLORER (web browser)  freeware
MOZILLA FIREFOX (web browser)  open source
WINZIP (utility compressione file)  shareware
EUDORA (client posta elettronica)  shareware
Storia
Web server: quote di mercato
TIPOLOGIE DI SOFTWARE O.S.
TIPI
n. progetti
attivati –
2003
%
21.591
48,3
8.178
18,3
14.954
33,4
SW DI SISTEMA
protocolli e sw per Internet; sistemi operativi e server;
strumenti e ambienti di sviluppo
ESEMPI: apache, linux, perl
SW MULTIMEDIALI E DI COMUNICAZ.
ESEMPI: mozilla
APPLICATIVI
SW scientifici, editor testi e office, database, utilities, giochi,
applicazioni aziendali (ERP), ecc.
ESEMPI: openoffice
Progettazione del software:
Il modello tradizionale
PRO E CONTRO
• Modalità strutturata di gestione del • Rigidità
progetto
– A livello di progetto (scarsa
• Controllo di budget, risorse, tempi
esplorazione delle possibili soluzioni
e avanzamenti
progettuali?)
• Gestione “gerarchica” del progetto
– Per i partecipanti al team di progetto
– Controllo “globale” del progetto e
delle sue varie parti
– Controllo “proprietario” del prodotto
realizzato
(limitata creatività e scarso spazio di
crescita personale?)
• Necessità di una pianificazione
rigorosa
• Necessità di definire gerarchie e di
impegnare risorse nel project
management
Il modello di progettazione “open”
COMUNITA’ OPEN SOURCE
Prosumer
Utenza
Team virtuale
Team dei leader
Imprese
Istituzioni
Comunità open source
• Prosumer: utenti che al tempo stesso partecipano
anche al progetto (ad es. programmatori che sono
utilizzatori dei programmi)
• Utenza: utilizzatori finali (consumatori, aziende)
• Team dei leader: coloro che (per autorevolezza
riconosciuta) guidano i progetti o sottoprogetti
• Imprese: aziende (software) che possono dare un
contributo ai progetti, influenzarne l’evoluzione, o
utilizzarne i risultati
• Istituzioni: amministrazioni pubbliche che possono
influenzare lo sviluppo di open source (stabilendo
regolamenti, o favorendo investimenti, ecc.)
PRO E CONTRO
PRO
• Libertà di partecipazione
– Progettazione “democratica”
– Assenza di gerarchie rigide
– “Meritocrazia”
• Evoluzione e innovazione
– circolazione dell’informazione
– possibilità di esplorazione
– flessibilità
CONTRO
• Problema di leadership
– Autorevolezza e non autorità
• Scarsa focalizzazione
– “code forking”: esplorazione
contemporanea di soluzioni parallele
– Progetti troppo complessi
• Scarsa pianificazione
– Del prodotto finale
– Dei tempi di release
– Degli aggiornamenti
Perché partecipare a un team open
source?
MOTIVAZIONI
• INDIVIDUI:
– SOCIALI/ETICHE
– TECNICHE
– ECONOMICHE
• ORGANIZZAZIONI
– SOCIALI/ETICHE
– TECNICHE
– ECONOMICHE
O.S. DAL PUNTO DI VISTA DEI
FORNITORI DI SW E SISTEMI
APPROCCI E STRATEGIE
Strategie relative alle licenze
Atteggiamenti in relazione all’O.S.
Strategie dei provider informatici
•
Strategia di difesa:
– Open source come “minaccia”; iniziative (di marketing, pressione, protezione, ecc.) volte a limitare lo
spazio dei concorrenti open source
•
Strategia di osservazione:
– Mantenimento di una strategia proprietaria, ma apertura dei propri sistemi (proprietari) alla connessione e
interazione con sistemi open source
•
Strategia di supporto:
– Posizione neutrale e aperta nei confronti dei produttori di sistemi complementari (ad es.: strategia di
produttori di hardware che non stringono alleanze vincolanti con nessun produttore di sistemi operativi)
•
Strategia ibrida (produttori di sistemi):
– Coinvolgimento diretto nello sviluppo di open source; si punta a dare valore ai propri prodotti/servizi
(proprietari) sfruttando al tempo stesso l’integrazione con le opportunità dell’open source e cercando di
influenzarne lo sviluppo.
•
Strategia ibrida (produttori di software)
– Idem come la precedente; inoltre, parziale apertura di parti di codice proprietario trasformandoli in open
source
•
Strategie “pure player”
– Imprese create esplicitamente per sfruttare il modello open source soprattutto come vendita di servizi di
assistenza, configurazione, manualistica, formazione, ecc.
IL PUNTO DI VISTA DEGLI UTENTI
OPPORTUNITA’ E PROBLEMI
IL COSTO DEL SOFTWARE
• TCO: TOTAL COST OF OWNERSHIP
–
–
–
–
–
–
DIRITTO ALL’UTILIZZO
MIGRAZIONE E INSTALLAZIONE
FORMAZIONE
GESTIONE
SUPPORTO E ASSISTENZA
UPGRADE
LICENZE
ATTIVITA’
E SERVIZI
ACCESSORI
I VANTAGGI DI COSTO DELL’O.S.
rispetto ai sw proprietari
IL TCO DI UN SW O.S. NON E’ ZERO!
• Risparmi nei costi di licenza
• Ma possibili maggiori oneri per attività e servizi
accessori, formazione interna, migrazione
apparati, ecc…
DISPONIBILITA’ DI SOLUZIONI
•
CRESCENTE DISPONIBILITA’ O.S.
–
•
ALCUNI CAMPI DI APPLICAZIONE ANCORA
SCOPERTI
–
•
applicazioni, sistemi, librerie, risorse accessorie, ecc.
specialmente sw business o per uso sofisticato
PROBLEMA DELLE “ESTERNALITA’
–
“Quanti dei miei partner commerciali usano lo stesso
sistema? Usano la stessa release?”
RELAZIONE CON I FORNITORI
• DIVERSIFICAZIONE DELLE FONTI DI INNOVAZIONE
– varie comunità di sviluppatori possono lavorare in parallelo
proponendo nuove soluzioni al mercato
• MAGGIORE INTEROPERABILITA’ TRA SISTEMI DI
FORNITORI DIVERSI
– Open source come “standard”
• INDIPENDENZA DAL SINGOLO FORNITORE
– bassi “switching cost”, niente effetto “lock-in”
QUALITA’ DEL SW
• ASPETTO CONTROVERSO
– BUONA PORTABILITA’
• indipendenza dalle varie piattaforme
– INTEROPERABILITA’ CON ALTRI SW:
• DIPENDE (specialmente con i sw proprietari)
– SICUREZZA:
• OPINIONI CONTROVERSE (in generale DIPENDE)
– FLESSIBILITA’: elevata perché
• Indipendenza da fornitori e piattaforme
• Possibilità di (auto)sviluppare nuove soluzioni
SVILUPPO E AGGIORNAMENTI
• NON SI DEVONO ATTENDERE LE “RELEASE
UFFICIALI” DEL FORNITORE PROPRIETARIO
• PERO’ NON C’E’ UN SOGGETTO “DI RIFERIMENTO”
(non esistono “date ufficiali” di nuovi rilasci: si deve
attendere che qualcuno sviluppi oppure farseli da sé)
ASSISTENZA
• LA COMUNITA’ O.S. DISPERSA E NON
PARTICOLARMENTE ORGANIZZATA PER FORNIRE
ASSISTENZA AL BUSINESS
• PERO’ POTREBBERO ESSERCI PIU’ FORNITORI
LOCALI ALTERNATIVI DISPONIBILI A DARE
ASSISTENZA