OpenSource come modello per la gestione del software d'impresa
La legge delega n. 30 del 14 febbraio 2003[1], meglio nota come legge Biagi, introduce il concetto di progetto in riferimento alla collaborazione coordinata e continuativa. La natura della collaborazione viene descritta come lavoro prevalentemente proprio e senza vincolo di subordinazione. L'eliminazione della gerarchia? Parlando di lavoro informatico, viene da chiedersi come si possano strutturare la produzione e la manutenzione del software al di fuori di una gerarchia aziendale.
In realtà questo già succede. Per capire meglio come, diamo un rapido sguardo al passato.
Già classificato come macchina per ufficio, il computer ha conosciuto una nuova dimensione grazie a Internet, accompagnata dai sogni e dalle disillusioni di un nuovo mercato. I manager EDP, memori di programmatori RPG o Cobol che codificavano l'attività dell'azienda, sono andati evolvendosi in fini conoscitori di pacchetti avanzati, mentre i loro collaboratori si limitavano a fungere da sistemisti, installatori e operatori di help desk. Sono sorte ditte di implementatori qualificati e certificati per configurare chiavi in mano i pacchetti venduti dai grandi produttori di software. Così, l'impresa era libera di concentrarsi sul proprio core business. Verso la metà degli anni novanta è esploso il fenomeno Internet. Giganti come Microsoft compirono sterzate vistose per adattarsi alla nuova tendenza. Si presagì l'affermarsi del commercio elettronico in tempi medio-brevi ma fu un fallimento. Convenzionalmente se ne attribuisce la responsabilità a Bin Laden, anche se la recessione si era già manifestata prima dell'11 settembre.
A ben guardare, c'è qualcosa in Internet che proprio non può essere classificato un flop. Visti dall'altro lato dell'interfaccia uomo-macchina, gli eventi appaiono molto più logici. I computer hanno bisogno di software, gli umani sono oramai maturi per scrivere software anche al di fuori di comunità ristrette, la grande rete ne può coordinare lo sviluppo come un ecosistema. E' la nascita dell'open source. I suoi apologeti, quali Eric Raymond[2], citano Kropotkin quando parlano dell'agire basato sul principio della comprensione condivisa grazie al quale una miriade di programmatori sparsi per il mondo riescono a coordinarsi su un progetto delle dimensioni di Linux lavorando in proprio e senza vincoli di subordinazione. E rieccoci alla legge Biagi.
I tecnici informatici possono suddividersi in due grandi categorie. Da una parte ci sono i manutentori, depositari delle specifiche, conoscitori profondi del sistema nel suo assieme. Dall'altra gli sviluppatori, creativi compositori di nuovi programmi. Come tutti sanno, la fase dello sviluppo ex novo occupa un periodo relativamente breve nel ciclo di vita del software. Durante questo periodo sono necessarie quelle figure professionali addizionali che la legge inquadrerebbe come lavoratori a progetto.
L'architettura del sistema informativo è quanto di più specifico e caratteristico l'azienda possegga. Il raggio d'azione dell'ICT comprende non solo contabilità e magazzino, automazione d'ufficio, paghe e contributi, ma anche produzione, vendita, marketing, public relations, supporto agli utenti e quant'altro. Attraverso le diverse sfaccettature della rete, da quella interna alle extranet e al web, il sistema informativo supporta e in qualche modo integra tutte le attività dell'azienda. Di pari passo, coloro che interagiscono con l'azienda, dai dirigenti ai clienti, dai fornitori agli impiegati, hanno tutti imparato a usare un computer. In alcuni casi la transizione non è completa e potranno passare diversi anni prima che lo diventi. L'importante è che in altri casi sia già così, di modo ché il percorso già tracciato divenga via via più agevole da percorrere.
Parlando di azienda ci riferiamo al concetto, non a un singolo ente giuridico. Il comparto ICT, gli utenti del sistema, i programmatori esterni possono essere legati tramite una miriade di soggetti diversi, software house, ditte individuali, liberi professionisti, selezionatori di personale. A supporto di questo modello di gestione, il Ministero dell'Innovazione ha previsto una Borsa Continua Nazionale del Lavoro in Rete[3], nelle parole del comunicato: un sistema telematico, aperto e trasparente, imperniato su una rete di nodi regionali ove far incontrare domanda ed offerta di occupazione.
Come sempre quando si parla di sistemi telematici, un settore specifico dove questi funzionano particolarmente bene è quello che riguarda lo sviluppo software. È facile prevedere che la richiesta di collaboratori possa essere così specifica e precisa da poter individuare le risorse adatte in modo univoco, quasi del tutto automatico e nel rispetto della pianificazione. Basta conoscere con esattezza che lavoro si vuole realizzare e quali sono i candidati adatti.
Una prospettiva vantaggiosa per tutti. Mettiamo a fuoco qualche dettaglio.
Un computer è molto più complesso, per esempio, di un telefono. Questo non permette di utilizzarlo come una scatola nera, ignorandone i principi di funzionamento. Se da una parte diventa sempre più agevole configurare l'utilizzo delle risorse hardware, dall'altra parte non è possibile trascendere dall'architettura del sistema, che tende a divenire sempre più complessa. Un paragone migliore potrebbe essere l'automobile, che non si può guidare senza conoscere la rete stradale, la segnaletica e il codice. Il punto centrale è che l'architettura del sistema aziendale dev'essere conosciuta da tutti gli utenti, secondo il loro ruolo.
Un singolo ufficio o una divisione devono poter proporre modifiche o aggiunte al sistema. Il compito dell'ICT è dare supporto tecnologico a queste esigenze, analizzarne l'impatto, formalizzarne le specifiche, implementarle e custodirle. Quando l'esigenza dell'utente rende necessario lo sviluppo di nuove procedure, risulta naturale definire un progetto adatto allo scopo. Si osservi che questo modus operandi è la conseguenza dell'installazione di pacchetti estremamente configurabili, fino a ritornare alla programmazione con linguaggi e/o tecnologie più evolute. Nettamente diverso dall'uso precedente di programmare in house, gli è pure vagamente affine, come dopo aver compiuto un intero giro di una spirale.
Ovviamente, il disegno delle nuove procedure sarà ispirato ai soliti criteri di orientamento agli oggetti e riutilizzabilità del software. Componente per componente, il disegno dovrà poter esser discusso con sviluppatori esterni che avranno tanta più facilità a comprenderlo quanto più questo sarà generico e riutilizzabile. In alcuni casi l'azienda dev'essere gelosa delle proprie procedure, tipicamente se queste comprendono segreti del mestiere che non devono finire in mano alla concorrenza. In tali casi è più efficace progettare una funzione in modo che il segreto risieda nei dati e non debba essere rivelato nemmeno al programmatore, piuttosto che stipulare un non disclosure agreement con lo stesso. Può essere istruttivo considerare alcuni principi[4]:
- Per garantire il libero accesso all'informazione risulta utile che la codifica dei dati non sia legata a un unico fornitore.
- Per assicurare la permanenza dei dati è bene che l'utilizzazione e il mantenimento del software non dipendano dalla buona volontà del fornitore o dalle condizioni di monopolio da esso imposte. Per questo motivo può essere preferibile un sistema la cui evoluzione possa essere garantita dalla disponibilità del codice sorgente.
- Ai fini della sicurezza e dell'affidabilità, conviene fare affidamento su software utilizzato e analizzato dalla più ampia base di utenti possibile. Anche su questo punto la conoscenza del codice sorgente facilita la scoperta e l'eliminazione tanto dei bug di programma quanto di eventuali parti malevole o codici spia.
L'atteggiamento corretto è quindi open source non solo nella scelta del software esistente, ma anche nella produzione di nuove procedure. Banalizzando, l'open source non è altro che un modo pratico per gestire i sorgenti. Rendendoli disponibili a chiunque, si constatata che non succede che qualcuno ne prelevi una copia di nascosto. Correzioni e aggiornamenti rendono dispendioso riscrivere le modifiche apportate a una copia privata. Chi ha esigenza di modificare un sorgente, fa meglio a convincere l'autore della bontà delle proprie ragioni. L'autore o il manutentore di quel sorgente, di converso, fanno bene a dare ascolto agli utenti competenti. Anche se si tratta di concorrenti. Ne guadagna la qualità del software, elemento comune tra le parti.
La scelta open source non è incompatibile con ambienti in cui, per convenienza o per abitudine, si utilizzano sistemi proprietari. Anzi, è probabile che nel lungo periodo gli stessi grandi produttori di software proprietario, finiscano col convertirsi a produrre software open source, dato che la Storia non va all'indietro. Piuttosto, è importante capire bene la natura del cambiamento per comportarsi nel modo adeguato. Non è vero che ci sia un forte vantaggio economico, quanto viene risparmiato sulle licenze va investito in risorse umane. È vero che c'è un sensibile miglioramento qualitativo, ma è richiesta una maggiore attenzione, in particolare, proprio nella scelta delle risorse umane.
Note:
-
L'articolo sulla
legge Biagi riporta numerosi riferimenti, tra cui anche la fonte ufficiale.
Secondo l'art. 4, comma c.3, per il caso del Co.Co.Co. il criterio che il governo adotterà sarà orientato al principio della riconduzione della fattispecie a uno o più progetti o programmi di lavoro o fasi di esso.
su
-
La cattedrale e il bazaar è l'articolo, comparso nel '98, in seguito al quale Netscape Communications, Inc. decise di rendere open source il codice sorgente di Navigator, giusto prima del suo declino in quella fase della guerra dei browser.
su
-
Ministro per l'Innovazione e le Tecnologie - Comunicato del 06/06/2003
su
-
Risposta del Congressista Villanueva a Microsoft
I punti nel testo sono liberamente tratti dalle considerazioni per l'implementazione di un sistema informativo dello Stato.
su