RED HAT, il potere della collaborazione

Cosa è oggi il modello open source?

La nostra è la più grande azienda open source al mondo. Nel 1993, Red Hat è stata una delle prime società a distribuire Linux. Passarono ancora cinque anni prima che il termine “open source” fosse coniato. Linux e il software open source non erano ampiamente conosciuti.
Noi oggi distribuiamo e supportiamo prodotti software partendo da progetti delle community open source e restituiamo valore ai progetti e alle community di cui ci avvaliamo. Noi non possediamo brevetti o proprietà intellettuale, ma tutto quello che viene prodotto, realizzato e distribuito è frutto del lavoro della community estesa a livello globale. A livello community Red Hat ha un ruolo importante perché facciamo da moderatori, finanziamo, offriamo supporto, creiamo tecnologia, insomma alimentiamo questo tipo di movimento e una volta che individuiamo tecnologie che ci sembrano interessanti all’interno dei vari progetti, non facciamo altro che industrializzare quei progetti. Insomma rendiamo delle buone tecnologie un prodotto adeguato alle esigenze dei clienti enterprise. Ciò significa integrare il codice open source, consolidarlo sul piano tecnico, renderlo scalabile e fruibile su lungo periodo quindi aggiornabile, verificarne tutti gli aspetti di sicurezza, di robustezza, solidità. E lo facciamo con le nostre risorse di ingegneria. Una volta concluso questo percorso, il prodotto viene brandizzato e distribuito e il nostro business è offrire supporto su quel prodotto. Red Hat ha una missione: essere l’elemento catalizzatore nelle community di clienti, contributori e partner per realizzare tecnologie migliori attraverso il modello open source.

Il codice è la vera proprietà intellettuale. Quali i vantaggi nel condividerlo?

Tutto il software ha il codice sorgente. Come sappiamo, non tutti i creatori di software scelgono di condividere quel codice. Ma quando lo fanno, qualificano la libertà di scelta per l’utente. Le industrie non possono più operare in silos, né le aziende all’interno di un singolo settore, né le industrie separate l’una dall’altra. Il mondo sta diventando solo più connesso. Ciò di cui un’azienda ha bisogno oggi, un’altra azienda ne avrà bisogno domani. Quando una persona o un’organizzazione crea un pezzo di codice per le proprie esigenze e lo condivide, un’altra organizzazione è in grado di riutilizzarlo in modi imprevedibili. Questo è il valore dell’open source e succede ogni giorno.

Chi partecipa alle community?

Sono tanti e diversi tra loro gli attori delle community, persone che a diverso livello e titolo sviluppano software per interesse, per ricerca, per motivi accademici, commerciali e così via. C’è il giovane studente che si è sviluppato la sua routernet e l’ha inserita dentro un github di progetto oppure un committer di livello professionale alto, ma anche brand come Oracle, VMware, Microsoft, Ibm. In tal modo si possono intercettare una serie di tecnologie, prodotte in modo spontaneo. A valle delle nostre sono attività di consolidamento del prodotto, il codice sviluppato viene condiviso con la community. Così non abbiamo mai una ownership intellettuale, un brevetto sui prodotti, ma andiamo a condividere l’effort tecnologico. Si ottengono due risultati, alimenti la community mantenendo il focus su determinati progetti, determinate tecnologie e quindi puoi garantire la lunga durata di un supporto al prodotto, un lungo ciclo di vita di un prodotto. Inoltre questa metodologia ci permette di implementare un differente modello di Research and Development  (R&D). Red Hat infatti non ha concentrazioni di ingegneri che in qualche luogo sviluppano, la nostra ingegneria è diffusa su tutto il territorio. In Italia, per esempio, abbiamo un centinaio di ingegneri che sviluppa software.

Italia è sensibile a questa metodologia?

C’è una grande partecipazione italiana, una diffusione direi verticale. Questo può apparire un ossimoro, nel senso che probabilmente nel mondo accademico o in altri specifici contesti è favorevolmente accettato, in altri settori la sensibilità è minore. Questo è probabilmente vero anche per la Pubblica Amministrazione, sia in termini di partecipazione alle community sia, più in generale come propensione a condividere le proprie esperienze, probabilmente per un fattore culturale. Inizialmente la PA ha inteso l’open source come possibilità di accesso a software gratuito. Vero c’è una gratuità di prodotto, ma si cambia anche il modello e in realtà si trasferisce il costo da un’altra parte. In una fase prolungata di compressione dei budget pubblici, l’utilizzo di prodotti dei brand tradizionali, con una crescente incidenza dei costi ricorrenti, determina la percezione della commodity, magari a basso valore, e quindi può apparire come uno “spreco”, soprattutto se puoi accedere gratuitamente a tanti prodotti con i quali fare innovazione. Il TCO (costo totale di proprietà o costo totale di possesso) sottostante a questo mdello è stato per diverse ragioni poco considerato non c’è nulla di gratis in natura e a maggior ragione in contesti produttivi a livello enterprise: se si acquisisce un prodotto open source in termini di bilancio non ti costa nulla, ma la manutenzione, il consolidamento, l’integrazione di quel prodotto può avere un costo pazzesco, se tu non sei strutturato opportunamente per supportare in casa quelle attività.
È chiaro che questo modello è insostenibile, se approcciato tatticamente come elemento di risparmio, quindi è successo che qualcuno si è buttato sul gratuito, si è fatto scottato e poi è ritornato al software proprietario, probabilmente senza migliorare la situazione. Per dirla con una battuta, è prevalso una sorta di “populismo informatico..
In realtà l’open source è un modello organizzativo, prima di essere una tecnologia. Quando andiamo dai nostri clienti, vendiamo certamente il prodotto/servizio, ma quello che trasferiamo al cliente è un modello, quello della condivisione, che alla Pa potrebbe essere di grande utilità. Mettiamo a fattor comune la nostra competenza con quella di altri, ottenendo non la nostra expertise, ma un insieme di expertise di una comunità molto grande, trasferendo così il valore di innovazione della comunità nella fornitura del prodotto al cliente. Queste considerazioni che possono apparire filosofiche, ma anche sul piano dello sviluppo e della innovazione sono aspetti importanti che nella Pa, come in altri settori d’industria, non sono immediatamente. Prova ne sia che oggi noi abbiamo una Pa tutta frammentata e segmentata su iniziative e progetti verticali. Per esempio già nel 1999 si parlava della carta d’identità elettronica. La discussione negli anni successivi è stata tutta improntata nello stabilire di chi fosse il dato, chi possedesse l’identificativo univoco del cittadino, se il Ministero dell’Economia con il codice fiscale o il Ministero dell’Interno con i registri anagrafici. Tema sicuramente rilevante, ma il risultato, è che non tutti abbiamo la CIE e siamo ancora lontani da una Carta Nazionale dei Servizi.

Qual è il vostro giudizio sui piani e progetti digitali delineati dai governi Italiani per l’informatica nella PA?

Il giudizio per la volontà, per l’obiettivo è sicuramente positivo. La Pubblica Amministrazione Italiana deve muoversi con un minimo di sincronia e con una chiara programmazione. L’obiettivo dei Piani Triennali di dare un indirizzo comune, serve a introdurre il concetto di sistema, che non sempre ha governato i provvedimenti assunti. Il concetto della condivisione, del fare sistema invece è premiante. Un esempio, è il concetto del riuso che nella Pa non sempre ha funzionato. La logica della soluzione verticale è risultata fuorviante, sviluppata una applicazione o una soluzione, si rende disponibile il package. Il modello di riuso del mondo open è l’opposto. Si struttura un prodotto (meglio, un progetto), lo si condivide mettendolo a disposizione di altri che lo possono migliorare o utilizzare in parte. Il riflesso di sostenere il proprio progetto e prevederne l’adozione in modo automatico senza doverci mettere mano, è limitante perchè limita la possibilità di crescere insieme. Prova ne sia che la Pa si è impantanata quando ha cercato di trovare l’unico attore che coordinasse e gestisse il cambiamento, il soggetto che si mette al centro della scena per decidere, dettare le regole, selezionare le tecnologie, indicare gli standard: insomma fare le cose per tutti. E’ chiaro che ache dietro questo approccio c’è sempre stata l’idea corretta di condividere e riusare, ma la metodologia si è rivelata sbagliata. Ora che ci sia un’unica cabina di regia, un’unica direzione programmatica è sicuramente legittimo e sano. Ma bisogna sempre considerare che esistono diversi punti di vista, esperienze e competenze diffuse all’interno della Pa e eliminando questa pluralità, se ne perde l’elemento qualificante. Un solo Ente della Pac non ha la visibilità che possono avere tutte le altre organizzazioni del complesso istituzionale dell’Amministrazione. Una Regione, una Provincia, un Comune, che ha maturato esperienze e realizzato progetti in un dato contesto industriale che ha specifiche capacità e esigenze di servizio, può fornire una competenza diversa e complementare, rispetto ad un’altraamministrazione che si misura con una realtà locale a vocazione turistica o agroalimentare. Entrambe queste competenze vanno valorizzate, vanno fatte collaborare, per raggiungere l’obiettivo di rispondere maggiormente all’esigenza di ottenere una più sostanziale ricchezza di funzionalità.

Però la necessità di mettere ordine è corretta: 22 mila, Amministrazioni, 11.000 Data Center, 25.000 siti web, 160 basi di dati, 200.000 applicazioni e 5,8 miliardi di Euro di spesa ICT annuale…

Certo che bisogna mettere ordine. Tenga anche presente che l’80% dei 5.8 miliardi sono destinati al seplice mantenimento. E’ corretto che ci siano delle politiche e scelte condivise in generale. Nelle nostre community lavorano milioni di sviluppatori, coome si fa in questo caso a mettere ordine tra tutti quelli che sviluppano un progetto? Il tema è lo stesso. Alla base c’è un concetto molto semplice: è quello della trasparenza e degli standard. Uno deve avere l’attitudine a condividere, se uno la possiede, lavora al proprio progetto, lo sviluppa secondo standard comuni e lo rende disponibile mediante protocolli condivisi. Quello che veramente occorre definire sono gli standard con cui trasferire, collaborare. Una volta che ho aperto il canale di comunicazione tutte le informazioni possono servire.

Quali consigli darebbe alla Ministra Pisano?

Intanto prevedere un Intervento molto deciso sulle persone. La Pa ha bisogno di aggiornamento delle competenze, di cambiamento culturale. A partire dai responsabili dell’IT: se chi guida la macchina non aggiorna continuamente le sue competenze, non si va molto lontano. Nella Pa vi sono molte competenze verticali, su specifiche tecnologie, magari anche con voglia di crescere. Questo desiderio si scontra però con la burocrazia, il sistema della classificazione dei livelli professionali, la gestione del personale, la mancanza di risorse. Può accadere anche che la formazione il personale sia somministrata non in funzione di interessi e a esigenze organizzative, ma del ruolo e dell’inquadramento. Inoltre procederei a una rivisitazione del Codice degli Appalti. Per come è pensato ora, funziona molto bene per la realizzazione di grandi infrastrutture, appalti e progetti di lunga durata, per interventi dal ciclo di vita molto lungo. Per l’approvvigionamento di tecnologia i cui cicli di vita sono brevi, se ti va bene di 3 anni, l’attuale Codice e i meccanismi di procurement publico non aiutano. Il modello di acquisto imperniato sulla Consip comporta il rischio di fornire alla Pa tecnologia obsoleta. Per motivi procedurali regolamentari, per i tempi tecnici di gara, tra la definizione dei requisiti tecnici e la conclusione del processo di gara, possono passare anni con il rischio che alla Pa arrivino tecnologie e servizi ormai datati. Un altro fenomeno molto strano è quello della svalutazione delle competenze professionali. È ormai normale vedere nelle gare pubbliche figure teoricamente altamente qualificate offerte a prezzi improbabili, del tipo 80 euro al giorno/persona , mettendo il fornitore nelle condizione di offrirti competenze che difficilmente potranno essere del profilo richiesto. Quindi il rischio di avere da un lato tecnologie che possono essere obsolete, dall’altro competenze non suficientemente qualificate: un mix per la Pa che può rallentarne l’innovazione. Diciamo che il processo di procurement va ripensato, la tecnologia ha bisogno di un diverso processo. In questo tragico periodo in cui siamo stati costretti a lavorare da casa, le Amministrazioni sono state autorizzate , per gli acquisti acquisti tecnologici legati allo Smart Working , a derogare al Codice degli Appalti. La parola d’ordine è comprare quello che serve subito perché altrimenti ci facciamo male. Se nell’emergenza, quando hai un rischio di sistema scopri che il tuo strumento d’acquisto non funziona, una riflessione la devi fare.

Qual è il vostro modello cloud?


Noi produciamo tecnologie abilitanti per il cloud ibrido. Anche questo sembra uno slogan però è così. Il nostro prodotto di punta è il RHEL (Red Hat Enterprise Linux). Si tratta della base da cui partire per rendere le app esistenti scalabili e distribuirle su software su piattaforme tecnologiche eterogenee: bare metal, ambienti virtuali, container e tutte le tipologie di ambienti cloud pubblici. Inizialmente abbiamo portato le capacità dei sistemi operativi UNIX su architetture hardware poco costose. Sulla base di Linux poi sono stati integrate una serie di altre componenti middleware, di gestione, automazione e infine quelle di abilitazione al cloud. Per quest’ultime sono stati introdotti dei prodotti che permettono di astrarre il servizio applicativo dall’infrastruttura tecnica su cui quest’applicazione vive. Realizzato questo disaccoppiamento con tecnologie, servizi, funzioni, si puoi costruire una applicazione che gira sul tuo pc in casa, sul server fisico o virtuale in azienda, e può essere migrata in maniera trasparente sul Cloud Provider. Questo è il concetto di cloud ibrido. Tutto questo set di tecnologie che ci permettono di creare piattaforme, applicazioni e gestire gli automatismi di trasferimento di questi carichi e la loro gestione, sono nel portafoglio di Red Hat. Il poter fornire tutte queste tecnologie abilitanti, ci mette nelle condizioni di relazionarci con l’utente non più solo a livello di infrastruttura tecnologica ma anche di intercettare le sue esigenze organizzaive per creare delle soluzioni cloud native, quelle che nascono per vivere nel cloud, o rendere cloud ready ciò che non è stato pensato per il cloud. Svincolato dall’infrastruttura tecnica, dall’aspetto funzionale, ci si può concentrare solo sul servizio che devi offrire. Le piattaforme che noi creiamo permettono di progettare un servizio per l’utente, di svilupparlo e rilasciarlo con un tempo e un ciclo di sviluppo che può richiedere in alcuni casi, quelli più semplici, qualche ora o, in presenza di progetti più complessi, qualche mese e non anni come spesso accade. Noi abbiamo queste tecnologie, le stiamo deployando anche nell’ambito della Pa con livelli di maturità differenti. L’obiettivo è questo: fornire una piattaforma tecnologica che permetta di sviluppare una applicazione del tutto indipendente dall’ambiente nel quale la fai girare. La nostra piattaforma OpenShift che ha proprio queste caratteristiche, è stata sviluppata integrando nella tecnologia Kubernetes alcune funzionalità che la possano rendono enterprise ready: l’orchestrazione, la security, gli aspetti gestionali, tutti i tool di automazione.

Quali sono le garanzie di sicurezza nelle vostre soluzioni?

Può sembrare pleonastico sottolineare l’importanza della sicurezza di qualsiasi apparato, soprattutto in questi anni in cui i crimini informatici sono all’ordine del giorno. Credo che vantare il fatto che uno dei clienti più importante di Red Hati è il Governo Usa, racconti molto della solidità dei nostri sistemi in tema di sicurezza. Tutti i dipartimenti ed enti governativi americani utilizzano queste piattaforme certificate. Però la cosa principale è che sono gli ambienti Linux intrinsecamente molto sicuri. Riescono a garantirti il livello di isolamento dei processi che poi ti abilita tutta la gestione della sicurezza. Questa caratteristica di base e la presenza strumenti per la personalizzazione dei profili d’uso e l’implementazioni di policy di sicurezza aumenta l’affidabilità delle nostres soluzioni. Il nostro business si riferisce alle piattaforme che abilitano lo sviluppo e la gestione delle applicazioni. Poi naturalmente ci sono altri livelli di sicurezza che vanno considerati come quelli di rete e perimetrali, ma non riguardano le nostre piattaforme.

Quali sono le best practices di Red Hat con la PA?

La premessa è che il nostro brand è legato alla tecnologia Linux e quindi è abbastanza difficile trovare una realtà pubblica o privata dove non ci sia una base installata Red Hat. Red Hat è molto attiva in ambito PA e vanta varie collaborazioni sia con le amministrazioni centrali, sia con gli enti locali.
Sono in corso collaborazioni molto interessanti con Il Mef, su tecnologie open source abilitanti al Cloud, con un ruolo importante di Sogei. Ma ci sono altri progetti in corso, così con la Protezione Civile con Inail, Inps, Istat, e sono tutte realtà nelle quali le tecnologie di abilitazione al cloud sono entrate negli ultimi anni. A livello locale abbiamo collaborazioni con la Regione Lazio, con la Regione Piemonte, con Lispa, con la Regione Veneto, e altre località locali come il Comune di Palermo.
Occorre ammettere che, di norma, la Pa arriva sempre con qualche ritardo rispetto all’industria sul terreno dell’innovazione. Ma nel caso del cloud paradossalmente il gap è assai ridotto.
Io vedo, mediamente parlando, un maggiore allineamento tra i diversi segmenti di industria, per cui potrei dire che ci sono ambiti PA che hanno sopravanzato il settore finanziario in Italia. La rivoluzione cloud ha livellato un po’ certe distanze. Il percorso di trasformazione della Pa è arrivato in un contesto dove di maturo non c’è moltissimo. Poste Italiane sta portando avanti un programma di trasformazione impressionante partito due anni fa. Adesso stanno accelerando sul mondo cloud. Una realtà come Enel, è quella più avanzata in Italia in ambito cloud, ma è partita pochi anni fa. I gap temporali, tecnologici e anche progettuali non sono così intensi. La Pa si sta muovendo con decisione solo negli ultimi due o tre anni. Qual è il problema? A mio avviso quello dell’implementazione, in quanto io ho la sensazione che la Pa ha meno capacità, competenze, in house per fare innovazione. Ha una riconosciuta capacità di governance e di gestione di grandi progetti ma spesso la fase implementativa è demandata ad attori esterni, il classico system Integrator spesso non scelto ma ereditato nell’ambito di qualche contratto Consip. Sono tutti fattori che non aiutano ad accelerare. Poi il gap più importante è quello delle persone, degli skill, delle professionalità. Perché quando si imprimono queste accelerazioni, il fattore umano delle competenze è importantissimo perché si affronta un salto quantico. Si esce dalla comfort zone e ci si trova in un mondo che non si domina più. A maggior ragione, considerando che gli skill sono altrettanto scarsi nell’industria e trovare un partner che sappia utilizzare queste tecnologie orientate al cloud non è una passeggiata.