OPEN SOURCE
Transcript
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