Autore M. Coletti - bozza, aggiornata al 10 dicembre 2003
Copyright (C) Massimo Coletti 2003
Questo documento raccoglie alcune considerazioni, derivanti dallo studio e dall'esperienza personali, sul fenomeno dell'open source, ed in particolare sulle opportunità che può rappresentare per un'azienda italiana.
Troppo spesso, nel campo dell'informatica, si usano ed abusano dei termini, senza capirne realmente il significato. Lo fanno spesso i professionisti, lo fanno spesso i manager. I secondi rischiano, perchè "lavorare" su un termine di cui non si comprende a fondo il significato espone al rischio di sprecare le risorse che devono invece gestire.
Inizio quindi questa nota con un piccolo glossario, per spiegare cosa intendo, quando uso un certo wording.
Un software open source prevede che i suoi sorgenti siano pubblici. Non prevede che il software sia gratuito, anche se, nella maggior parte dei casi, ciò avviene. Per un'azienda che usa questo software, o per un ingegnere del software, questo significa due cose:
L'insieme di queste due condizioni comporta che:
"è possibile correggere autonomamente gli errori nel software"
In termini di modello di business, questo significa che l'azienda può decidere quali strategie adottare per la gestione del proprio parco software senza avere molti vincoli imposti dal produttore del software.
Senza pretendere di fare cataloghi, il software open source appartiene generalmente a queste categorie:
Sono pochi, ad esempio, i programmi open source che fanno le fatture. E' però possibile, anzi sempre più frequente, trovare un programma che faccia le fatture (o mi gestisca un sito per il commercio elettronico) che usa, anche estesamente, componenti open source.
E' un termine lanciato qualche anno fa, quando alcune grandi aziende, IBM e Sun in testa, cercarono di combattere il dominio della Microsoft proponendo i thin client, terminali evoluti, ma senza autonomia di elaborazione come i PC, che promettevano alle aziende un risparmio in termini di cost of ownership del posto di lavoro.
Il concetto ha avuto più successo del prodotto che pubblicizzava: ci siamo resi conto che il costo di un software risiede solo in minima parte nella licenza, ma si spalma su canoni di manutenzione, formazione, supporto di sistemisti specialisti, acquisto di nuove release, manutenzione delle interfacce. L'insieme di questi oneri può portare a quintuplicare, o a decuplicare il costo sostenuto dall'azienda durante il periodo di vita economica del cespite, rispetto alla licenza iniziale.
Il costo of ownership è un concetto importante anche perchè le aziende cominciano a considerare il software come un asset la cui vita economica è molto più lunga del periodo di ammortamento della licenza. Da quello che si sente "in giro", anche con la spinta dei nuovi IAS (International Accounting Standard, i principi contabili a cui dovranno ispirarsi una buona parte delle aziende nella redazione del bilancio), il software tende ad essere considerato alla stregua del capitale dell'azienda, ed il costo necessario al suo mantenimento è una forma di hedging per proteggersi dal rischio che "ci molli" senza preavviso.
Più di recente, sull'onda della moda per il risk management, il discorso si è spostato anche su altre considerazioni:
Non do le risposte. Chi ha vissuto questo genere di problemi le ha bene in mente, gli altri, spesso, le sottovalutano.
Il software open source si caratterizza generalmente per un diverso mix di costi:
Se un'azienda desidera introdurre l'open source nei suoi sistemi informativi ha sostanzialmente due opzioni, che non si escludono a vicenda:
Tipicamente è la prima strada quella che si percorre inizialmente; si deve tuttavia ricordare che è abbastanza raro trovare delle applicazioni "finite" open source, ma è più facile trovare dei componenti, che si useranno per costruire l'applicazione desiderata.
Chi sarà allora l'attore con la responsabilità di introdurre tali tecnologie?
E' un bel problema, in quanto i "decisori tencici" (orribile termine, ma rientro ahimé in questo gruppo) che vogliono proporlo si trovano davanti al rischio di un insuccesso (che cerrà addebitato alla loro scelta non convenzionale), alla diffidenza del top management ("ma lé l'é minga un no global?"), alla resistenza a volte degli staff IT, che non vedono perché imbarcarsi in un ginepraio nuovo.
Il top management percepisce inoltre il fenomeno in "bianco e nero" (bianco = è gratis, nero = non conosco), e può essere influenzato da pregiudizi o aspettative eccessive del suo staff, dal passaparola. Purtroppo si tratta di scelte strategiche, che vanno affrontate imprenditorialmente, e non con la irrazionalità con cui si sceglie il gusto del gelato.
Un manager che voglia valutare l'opportunità di introdurre l'Open Source nella sua azienda dovrebbe pensare:
Come in tutte le cose, occorre fare un po' di "gavetta" per misurarsi e capire veramente le opportunità di questa filosofia. Ritengo quindi indispensabile identificare delle aree pilota, in cui introdurre delle componenti open source, per poi trarre le somme. Alcuni possibili campi di azione possono essere:
Dopo il dove, occorrerebbe passare al come, ma ci penseremo dopo, per ora pensiamo al quanto...
Cerchiamo di delineare,ora, il diverso impatto economico che può avere su un'azienda il ricorso a soluzioni che includano - almeno in parte - componenti open source, rispetto all'approccio tradizionale.
Nella tabella viene rappresentato con dei segni più ("+") un costo, con dei segni meno, l'assenza di costi. Illustro ora le motivazioni alla base di queste stime.
Premetto che il modello di costo analizzato, è relativo ad un'azienda che acquisisce una soluzione software di una certa dimensione e rilevanza per il proprio business, che richiede comunque un certo intervento di personalizzazione (quindi non è reperibile sul mercato già "confezionata"); l'azienda è interessata a mantenere un certo controllo sull'applicazione, dotandosi di alcune competenze necessarie all'amministrazione dell'applicazione e dei server che la gestiscano, ed acquisendo gli skill necessari a capire come mantenere il software o almeno a capirne il funzionamento.
Innanzi tutto c'è la fase di acquisizione iniziale della soluzione; si escludono i costi dell'hardware, in quanto considerati invarianti. E' un assunto non sempre vero, perchè a volte le soluzioni open source richiedono risorse hardware inferiori. Tale fase prevede i costi:
Componente |
OS
|
Tradiz.
|
Licenze | ||
sistema operativo |
-
|
+
|
middleware |
-
|
+++
|
strumenti di sviluppo |
-
|
++
|
sistemi di monitoraggio |
+
|
+++
|
Sviluppo | ||
personalizzazioni o estensioni |
++
|
+++
|
System integration | ||
installazione e configurazione |
+++
|
+
|
tuning |
+
|
+
|
Formazione | ||
utenti |
++
|
++
|
personale tecnico |
+++
|
++
|
Manutenzione | ||
canoni di manutenzione licenze software |
-
|
++
|
canoni di manutenzione delle parti custom |
++
|
++
|
servizi specialistici di supporto |
+
|
++
|
Evoluzione | ||
costo delle evoluzioni programmate |
+++
|
++
|
costo delle evoluzioni non programmate |
+
|
+++
|
Domanda finale: conviene l'Open Source (ho usato le maiuscole, perchè il momento è importante)?
Il mio parere è si, anche se a certe condizioni e per certi progetti, ed in questo parere ho l'illustre conforto della commissione governativa organizzata dalla CNIPA. Alcune condizioni che possono far propendere per il si sono:
Ho sviluppato un semplice modello di calcolo per raffrontare gli ipotetici costi dello sviluppo in-house di un prodotto, comparandoli col costo dello stesso sviluppo realizzato cooperativamente, in modalità open source.
Sono convinto che l'open source richieda un diverso modello di business rispetto a quello che lega tradizionalmente un'azienda ai suoi fornitori di software e servizi. Questo modello va interiorizzato, valutato e compreso, adattato alla propria specifica realtà. Occorre cambiare la propria mentalità.
Vediamo cosa contraddistingue questo modello di business:
Voglio affrontare ora un tema più "politico", ma sicuramente non trascurabile per la nostra realtà economica.
Il mercato IT italiano è sicuramente dominato dalle multinazionali. Aziende come IBM, HP, Dell, Cisco, CSC, EDS, le big della consulenza (per quanto ne è rimasto), le filiali dei grossi software vendor (Microsoft, SAP, Oracle, ecc.) coprono in termini di hardware, software e servizi la maggioranza del mercato. Questo significa che una quota aconsistente del fatturato del settore va all'estero, anche se l'indotto - soprattutto in termini di occupazione - ha una importanza assoluta.
Il nostro paese è anche caratterizzato da una rete abbastanza fitta di piccole software house, che operano come system integrator, ma spessissimo sviluppano piccole applicazioni, personalizzazioni, per l'impresa artigianale, familiare o comunque small business. Abbiamo anche delle realtà, prettamente nazionali, importanti: Formula, Byte, Engineering, Zucchetti, CAD, TAS, sono tutte storie di successo, che hanno conquistato un ruolo di presenza "industriale" nel nostro mercato.
La dipendenza dall'estero resta comunque determinante, e larga parte delle nostre imprese che operano nel settore hanno dimensioni troppo piccole per competere su una scala che non sia quella strettamente territoriale (provincia/regione al massimo), per investire in ricerca e sviluppo delle proprie risorse umane, per reagire alla durissima crisi che il settore attraversa. Tali imprese sono anche praticamente escluse dal mercato della Pubblica Amministrazione, che è uno dei "clienti" principali del mercato, sempre perchè - giustamente - i filtri di accesso ai progetti della PA sono incompatibili con tali realtà minime.
In questo quadro risulta sicuramente problematico l'affermarsi di un tessuto imprenditoriale nazionale, ed i casi di successo sono appunto "casi", talmente rari da risultare facilmente enumerabili, e comunque spesso legati a mercati di nicchia.
Cosa c'entra l'open source con tutto questo?
L'open source consente ad una piccola azienda di realizzare una software factory con investimenti molto contenuti. Questo può rappresentare una facilitazione per lo sviluppo di proprie soluzioni, rendendo più sostenibile la fase degli investimenti, che naturalmente dovrebbe essere coadiuvata da un supporto economico. In questa fase può intervenire lo Stato (con strumenti tipo le note leggi di supporto all'imprenditoria giovanile, fondi comunitari, ecc.), il distretto economico o gli Enti Locali (attori che possono avere interesse a finanziare iniziative che poi offrano strumenti economici di miglioramento dell'efficenza e produttività per le aziende che vi ricadono), il sistema finanziario (in particolare fondi di venture capital).
Si ricordi che - in linea generale - applicazioni sviluppate sulla base di componenti open source possono essere distribuiti solo come open source; non si tratta però di un ostacolo, in quanto i mancati ricavi da licenze possono essere compensati dai ricavi per servizi. Lo sviluppo di un'applicazione open source può inotre costituire un patrimonio di risorse e conoscenza facilmente condivisibile in ambito di distretto o di ambito territoriale, costituendo quindi un'opportunità di moltiplicazione delle realtà imprenditoriali in grado di lavorarci sopra.
Ci possiamo domandare quale mercato esiste in realtà per queste ipotetiche "nuove applicazioni". Il mercato secondo me esiste, favorito da alcuni fattori:
Il diffondersi della banda più o meno larga per le connesisoni ad internet aiuta inoltre nella gestione remota degli interventi di installazione e supporto tecnico. Questo fa si che realtà anche piccole possano offrire supporto a clienti abbastanza dispersi sul piano geografico senza dover necessariamente costituire reti di filiali capillarmente distribuite (sostenendo costi probabilmente proibitivi).
Le caratteristiche dello sviluppo open source possono inoltre favorire il costituirsi di reti di piccole aziende cooperanti nel medesimo progetto di sviluppo, anche al di fuori di specifici vincoli contrattuali. Si tratta probabilmente di un certo salto di mentalità, ma perchè non immaginare due piccole software house, una di Carpi ed una di Barletta, che lavorino insieme ad un progetto open source di utilità per laboratori tessili? Entrambe potrebbero trovare sinergie nello sviluppo, incrociare le competenze specifiche dei loro territori, sfruttare le risorse dell'"altra" software house in caso di necessità, divenendo comunque figure di riferimento per un certo tipo di competenze "verticali".
Tutto questo può essere chiaramente possibile (e forse auspicabile) anche senza il ricorso all'open source, che però aggiunge - lo ripeto - elementi di specificità:
Gli ultimi indirizzi della PA hanno preso atto dell'esistenza del fenomeno open source, dell'opportunità di risparmio e razionalizzazione che rappresenta, dandogli (per ora solo potenzialmente) una pari dignità nella definizione di progetti in ambito IT.
Rimane comunque il fatto incontrovertibile che una software house di 10 persone non potrà mai aspirare ad una commessa di sviluppo per un ministero. Dobbiamo però ricordare che la PA opera in un contesto particolare:
Penso quindi che, di fronte ad una gara pubblica, un imprenditore o un RTI
con adeguata dimensione, potrebbe assumersi la responsabilità (ovvero
rischi e garanzie) di condurre un progetto come main contractor, utilizzando
però un congruo numero di piccole imprese coinvolte nello sviluppo, ed
utilizzando tecniche di analisi e project management proprie dell'open source
ed un modello di cooperazione distribuita, retribuendo le aziende partecipanti
sulla base del lavoro effettivamente svolto (con parametri come i function
points, il livello di qualità, ecc.).
In tal modo il rischio derivante dalla frammentazione dei partecipanti al progetto
potrebbe essere compensato dalla facilità nell'interscambiare le singole
aziende che vi partecipano. Il main contractor offrirebbe le garanzie
di solidità finanziaria, di capacità nel project management, di
uso delle corrette metodologie, mentre la PA interessata (magari tramite l'opera
di organismi specializzati come la CNIPA) potrebbe vigilare sulle condizioni
di esecuzione del contratto, sui criteri di scelta delle aziende coinvolte,
ed in generale sulla correttezza del processo.
Che benefici potremmo avere da questo modello?
Utopia?
... continua ...