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:

• middleware (server applicativi o componenti da integrare in architetture più complesse);
• strumenti di produttività per ingegneri del software (ambienti di sviluppo, editors, ambienti di controllo del processo di produzione del software, compilatori ed interpreti);
• utility e programmi di uso generale (office automation, client di posta elettronica, browser per internet);
• sistemi operativi (Linux, ma non solo);
• utility di sistema (sistemi di windowing, tool per la crittografica, utility di gestione dei file, utility per le reti).

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:

• cosa faccio se il software smette di funzionare, bloccando i miei processi, ed il fornitore non è in grado di fornire una soluzione;
• esistono dei fornitori alternativi, che possono offrirmi lo stesso prodotto, consentendomi di negoziare un prezzo più basso?
• se la società esterna che mi assiste sul prodotto non mi segue più bene, aumenta i costi, cambia mercato, quante alternative ho?
• se esce un nuovo prodotto, di un altro produttore, con caratteristiche migliori o costi molto minori, quanto mi costa migrare su di esso?

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:

• assenza (spesso) di costo di licenza,
• assenza (spesso) di costo di manutenzione,
• necessità di maggiori skill specialistici interni,
• maggiore indipendenza dalle strategie del produttore,
• maggior numero (teorico) di società di servizi in grado di supportare il prodotto.

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:

• adottare tecnologie open source;
• sviluppare programmi open source.

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:

• allo specifico modello di business che sta dietro al mondo dell'open source;
• alla coerenza fra la propria politica nelle risorse umane e consulenziali nell'area IT ed i requisiti per una corretta gestione di progetti open source;
• all'offerta di mercato per la soluzione di cui ha bisogno;
• alla sua strategia di sviluppo nel futuro;
• a quanto è importante una profonda conoscenza - all'interno dell'azienda - dei meccanismi e della logica di funzionamento della propria applicazione;
• all'opportunità, o meno, di garantirsi un'indipendenza da uno specifico fornitore o provider di servizi;
• a come intende modulare gli investimenti nel settore.

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:

• strumenti di supporto alla metodologia interna di sviluppo, controllo e rialscio del software;
• applicazioni di raccolta dati dalla clientela, preferibilmente via Web, che non siano necessariamente mission critical (ad esempio richieste di manutenzione, o distribuzione di estratti conto, ecc.);
• interfacce fra applicazioni aziendali;
• automazione di procedure burocratiche interne (ferie, acquisti di materiale d'ufficio, ecc.);
• sistemi di gestione e pubblicazione dei contenuti della intranet aziendale.

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.

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:

• voglio avere il pieno controllo del software, a tutti i livelli,
• preferisco avere competenze all'interno dell'azienda,
• il progetto è "aperto", ovvero so che ci saranno molti sviluppi ulteriori, ma non so bene in che direzione,
• non voglio rischiare di fare investimenti a vuoto,
• voglio cooperare nello sviluppo con diversi fornitori di servizi,
• voglio spendere di meno nella realizzazione del progetto,
• penso di poter riutilizzare parte dei componenti sviluppati.

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:

• E' necessario acquisire un elevato livello di know-how in azienda. Spesso si intraprendono progetti senza avere specialisti interni competenti sulle tecnologie utilizzate. Le tecnologie open source hanno generalmente strumenti di gestione meno raffinati, per indenderci, necessitano di qualche "smanettone" che li aggiorni, controlli, amministri. La filosofia dell'open source prevede inoltre di dare valore all'utilizzatore mediante la conoscenza del prodotto - anche tramite i sorgenti - e questo comporta la presenza di figure specialistiche.
• E' necessario interagire strutturalmente con la community che ruota intorno alle tecnologie usate. Il campo dell'open source è forse quello in cui il fenomeno delle comunità virtuali ha raggiunto la massima maturità. Le community sono quelle direttamente legate al prodotto usato (la comunità di chi ha sviluppato il prodotto, lo mantiene e lo documenta), e quelle più aleatorie dei newsgroups, delle mailing lists, dei wiki. All'interno delle comunità si trova generalmente un ampio patrimonio di conoscenza e suggerimenti, anzi i problemi più particolari, specifici di un certo ambiente operativo, o di una certa funzionalità, si trovano documentati solo all'interno di tali comunità. E' necessario quindi che tutto il team di sviluppo (interno o esterno) sia abituato ad usare regolarmente queste risorse, per essere più veloci nella risoluzione dei problemi.
  E' importante anche abituarsi ad interagire con la comunità. Ritengo che l'interazione con le comunità presenti un effetto "leva": il sapere, il lavoro, "immesso" nella comunità ritorna indietro amplificato con un fattore di 100, 1000 o più. Non è strettamente necessario essere "protagonisti" di una comunità, ma aiuta: si troverà infatti spesso (Attenzione non sempre) qualcuno che presta attenzione al nostro quesito; inoltre l'essere riusciti a fornire una soluzione sarà un elemento di stimolo per il nostro staff, e misurarsi con i problemi posti dalla comunità un'ottima palestra.
  La comunità è accogliente e disponibile, ma anche molto selettiva. I nostri primi interventi ci qualificheranno sempre come newbie (novellino, burba), ed una domanda ingenua sempre stigmatizzata. Prima di porre una domanda è necessario sudare un pò per trovare la soluzione da soli, e documentare gli sforzi fatti, documentare il fatto che si sono seguite tutte le istruzioni, i README. Se si cercano scorciatoie, si troveranno solo risposte vaghe.
• E' consigliabile frazionare il lavoro fra sottoteam specializzati nelle singole tecnologie e componenti usati; ad esempio chi disegna la veste grafica, chi il flusso funzionale, chi il database, chi i moduli con la logica di business, ecc. Si tratta di un tema delicato, in quanto comporta generalmente un maggiore onere organizzativo. Se si usano le tecnologie giuste per lo sviluppo, la comunicazione fra i team può risultare molto semplificata. Occorre curare molto bene la definizione e la documentazione delle interfaccie: si ricordi che se le interfaccie non sono bene documentate, c'è un'alta probabilità di introdurre nel sistema dei difetti nascosti, che emergeranno durante il collaudo, o peggio durante le prime fasi di esercizio. Il frazionamento può consentire di ricorrere a piccole aziende, giovani, economiche, dinamiche. Se si ritiene di non avere una struttura interna adeguata ad un project management di questo tipo, si può ricorrere ad un grosso player, che copra solo questo ruolo: in tutti i casi è fondamentale che il capo progetto abbia una perfetta conoscenza degli obiettivi del progetto, del contesto aziendale, dell'architettura.
  Il frazionamento dei compiti obbliga ad aumentare la quantità di documentazione prodotta, limita quindi il rischio di restare legati alle competenze di un singolo partner (o peggio ancora di un singolo sviluppatore); se in futuro si dovrà riprendere il progetto per ampliamenti o integrazioni, sarà molto più facile impegnare un nuovo partner.

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:

• la specificità delle esigenze di una determinata filiera produttiva;
• le specificità del sistema normativo e fiscale italiano (che la UE dovrebbe "attenuare"...);
• la barriera linguistica fra l'italiano e l'inglese, che può ostacolare le aziende nell'uso di tecnologie senza il supporto di un partner "poliglotta".

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

• una modulazione più graduale delgi investimenti necessari;
• una spinta all'uso delle tecnologie più moderne.

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:

• la PA (ed i beni che acquisisce) sono patrimonio dello Stato, e quindi bene pubblico; il fatto che il software che usa sia open source (e quindi potenzialmente utilizzabile da chiunque) si accorda quindi con la natura di queste entità;
• le PP.AA. non operano in regime di concorrenza, non hanno quindi "segreti industriali" o particolari processi di business da nascondere per garantirsi un vantaggio competitivo, in quanto operano secondo un sistema di leggi che è pubblico; il fatto che il pubblico possa sapere (analizzando il codice pubblico) come un'amministrazione svolge il suo lavoro può solo agigungere trasparenza all'operato della PA.

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?

• Un volano di sviluppo di un'industria del software avanzata e distribuita su tutto il territorio nazionale, partendo dal basso, favorendo l'inserimento di risorse giovani nel mondo del lavoro;
• una maggiore potenzialità di riutilizzo delle soluzioni sviluppate fra tutte le Amministrazioni dello Stato;
• un potenziale risparmio nei costi di sviluppo (e penso anche ad una migliore qualità intrinseca dei prodotti);
• una minore dipendenza da fornitori specifici per la manutenzione delle applicazioni, e quindi un minore cost of ownership.

Utopia?

Formazione

... continua ...