Open Source

Business o folclore?

Autore M. Coletti - bozza, aggiornata al 10 dicembre 2003
Copyright (C) Massimo Coletti 2003

Guida al documento

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.

Glossario

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.

Linux
E' un sistema operativo "open source", molto simile allo Unix. Infatti si basa sullo standard POSIX, che è un tentativo di definire un sottoinsieme di funzionalità di Unix che risulti standard su ogni implementazione. Spesso si considera Linux un sinonimo di open source, ma è una semplificazione.
Licenza
E' il contratto stipulato fra chi produce un software e chi lo utilizza. Descrive gli obblighi di entrambi i contraenti, ed i limiti di questi obblighi. Una licenza può essere onerosa (prevedere la corresponsione di un corrispettivo, oppure no). A volte la licenza definisce anche i limiti (contesti) in cui può essere utilizzato il software.
IDE
Integrated Development Environment, è tipicamente un programma, o una suite, che aiuta lo sviluppatore nel suo lavoro, consentendogli di sviluppare automaticamente parti del software, testarle, documentarle, compilare l'applicazione, modificarla, lavorando in un'unico ambiente.
CVS
Acronimo di Concurrent Versioning System, è un'applicazione, open source, tanto diffusa da essere quasi uno standard, che consente di gestire le versioni di un gruppo di sorgenti a cui lavorino contemporaneamente più sviluppatori. Moltissimi progetti open source usano CVS per condividere i sorgenti fra i membri del progetto, oppure per consentirne il download a chi vuole consultarli.

Cos'è, e come si usa

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:

  1. è possibile modificarlo a piacere,
  2. è possibile capire perchè si comporta in un certo modo, anche se la documentazione a corredo non fornisce indicazioni specifiche.

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.

Quali sono i software open source

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.

Cost of ownership

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:

L'Open Source in azienda

Dove introdurlo

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...

Costo dell'Open Source

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:

Licenze per il software di base
Soluzioni tradizionali si appoggiano su server il cui sistema operativo (Unix, Windows, o altri) ha un costo. Una soluzione basata su un sistema operativo open source (nella stragrande maggioranza Linux) non ha tale costo, oppure lo ha in misura largamente inferiore (i costi per acquisire i supporti della distribuzione prescelta - da notare che alcune aziende, Red Hat fra tutte, traggono larga parte del loro fatturato da questo ricavo sia pure modesto).
Licenze per il middleware
In questo termine rientra una parte sempre più larga di software: sistemi di gestione del database, server web, server applicativi, sistemi di messaggistica, gestione del workflow. Una tipologia di applicazioni sempre più diversificate, che forniscono alle soluzioni software una base sempre più ampia di funzionalità aggiuntive. L'ampliamento e diversificazione dell'offerta è andato di pari passo con un incremento dei costi di licenza, che a volte possono diventare una delle componenti preponderanti nel costo complessivo di acquisizione. L'offerta open source offre molte soluzioni in questo settore, alcune delle quali (caso eclatante, il server Apache, che ha oltre il 60% del mercato, o il database server MySQL) hanno un'importanza determinante, oppure risultano anche più evoluti dell'offerta di mercato "commerciale".
Si deve porre molta attenzione a questa voce quando si valuta una soluzione "convenzionale": può accadere infatti che il fornitore dell'"applicazione" vi quoti un costo, aggiungendo poi fra i prerequisiti, "server X, database Y, server applicativo Z", senza esplicitare il fatto che il costo di acquisizione di queste licenze è a carico del committente del progetto, e non è incluso nel costo della fornitura. E' ovvio che in questi casi, tirando le somme, il costo finale potrà essere ben al di fuori del budget.
Strumenti di sviluppo
Quanto più complessa è l'architettura dell'applicazione, quanto più è verosimile che, per poterla manutenere, siano necessari degli strumenti di sviluppo (IDE - Integrated Development Environment). Spesso, anche se non sempre, le soluzioni "proprietarie" di un produttore software richiedono verosimilmente, senza molte alternative, l'IDE offerto dallo stesso produttore. Il mondo open source si basa invece spesso su IDE anch'essi open source. Anche nel caso di "linguaggi" specifici di un particolare componente open source (ad esempio il linguaggio 'tal' per il server Zope) sono facilmente rappresentabili su normali file di testo, senza richiedere software specifici.
Oggi, alcuni IDE che stanno acquisendo una diffusione predominante nel mondo open source sono Eclipse (finanziato da IBM), Net Beans (finanziato da Sun), Poseidon (la versione community di un prodotto normalmente a pagamento della Gentleware); questo elenco è sicuramente incompleto.
Personalizzazioni ed estensioni
In linea teorica, il costo dovrebbe essere simile nei due casi. Va considerato che le soluzioni open source richiedono in genere un volume di personalizzazioni o sviluppo maggiore; la situazione del mercato dei servizi vede però tariffe generalmente inferiori per specializzazioni in ambito open source. Un altro fenomeno è quello del "proporzionamento" che a volte si verifica fra il costo delle implementazioni ed il costo dei componenti di base e middleware, che tende a caratterizzare generalmente come meno costose le soluzioni basate sull'open source.
Installazione e configurazione
I componenti open source raramente fanno parte di "suite" di prodotti più o meno integrati fra di loro (anche se con rimarcabili eccezioni come Apache + Tomcat, oppure OpenOffice). Questo fa si che il system integrator debba studiare in modo più approfondito la documentazione, fare prove, per arrivare a "legare" insieme la soluzione finale. La stessa documentazione è generalmente più frammentata. Il software su licenza tende invece ad essere più integrato, soprattutto se viene dallo stesso fornitore, per motivi commerciali.
Tuning
Ritengo che si tratti di una componente invariante. Tuning significa ricercare la configurazione che rende le prestazioni del sistema ottimali, per il dato carico di lavoro. I sistemi proprietari hanno di frequente strumenti migliori, anche se il mondo open source ha generalmente un'attenzione maggiore all'ottimizzazione delle risorse e delle performance: il tuning può essere più difficile, ma esiste documentazione molto approfondita e si parte da una "base" generalmente più efficente.
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:

Un modello di calcolo

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.

Organizzare il team di sviluppo per l'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:

L'Open Source ed il Sistema Paese

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?

Sviluppo di soluzioni

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à:

Pubblica Amministrazione

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?

Formazione

 

... continua ...