Opensource in azienda: come gestirlo

Il cloud, la virtualizzazione, i microservizi: qualsiasi approccio moderno alla creazione e alla gestione delle applicazioni in azienda si porta dietro componenti opensource, se non intere piattaforme.

Un esempio? Prendete OpenStack, la base della gran parte delle implementazioni di cloud privato: "dentro" ci sono una quarantina di progetti specifici, anche se poi quelli principali sono meno di una decina.

E DevOps? Sembra logico affidarsi ai progetti che vanno per la maggiore come supporto per la programmazione "agile", anche qui l'offerta è decisamente ampia.

Nulla di nuovo, in fondo. Una volta le imprese guardavano all'open source come a un mondo privo delle tutele del software commerciale, da anni si sono "convertite" ed è difficile immaginare sviluppi lato software e cloud che siano completamente astratti dal software libero.

Che è stato accettato come una grande risorsa. Ma il rischio in alcuni casi è esagerare in senso positivo e non considerare alcuni aspetti di cui soprattutto le grandi aziende dovrebbero invece tenere conto.

Il problema è che quando l'adozione dell'open source supera una determinata soglia, peraltro abbastanza semplice da toccare nelle organizzazioni complesse, le attività di sviluppo rischiano di perdere la visibilità su quello che effettivamente stanno adottando e sulle interrelazioni delle varie componenti "open" tra di loro.

Le statistiche variano, ma si stima comunque che in un moderno progetto di sviluppo software mediamente la larga maggioranza delle componenti usate sia di terze parti.

Opensource e questione sicurezza

Molte grandi realtà che non nascono come software house ma hanno oggi una attività di sviluppo interno molto importante, come ad esempio le banche, non hanno l'abitudine di tracciare con precisione un inventario delle componenti software che adottano e delle loro dipendenze.

Per questo può capitare che si consideri di stare utilizzando un particolare elemento opensource senza tenere presente che esso dipende da altri e questi a loro volta da altri ancora.

Il rapporto tra software conosciuti, che quindi si manutengono e si "patchano" all'occorrenza, e quelli sconosciuti ma indirettamente in uso può anche essere facilmente di uno a dieci. E non tutti sono manutenuti con la stessa attenzione.

Open source e complessità: alcuni moduli di una implementazione OpenStack
Opensource e complessità: alcuni moduli di una implementazione OpenStack

Il punto critico in questo senso è la sicurezza. Non perché l'open source in sé sia meno sicuro del software commerciale (di solito è il contrario) ma perché non si può operare per garantire la sicurezza di ciò che non si sa nemmeno di stare usando.

Una adeguata attività di tracciamento del software in uso (direttamente e indirettamente) dà invece una visione corretta del proprio parco software e permette di intervenire quando necessario. Le piattaforme in questo senso non mancano e spesso possono essere integrate anche negli ambienti di sviluppo e versioning che gli sviluppatori e i loro manager già utilizzano.

Il nodo delle licenze opensource

Una volta era uno di principali punti di scontro tra fautori del software libero o commerciale: la corretta gestione delle licenze opensource. Oggi ci si pensa molto meno perché l'open source è un dato di fatto e perché quella polemica è datata, per le aziende però il problema è rimasto: adottare componenti open source significa anche adeguarsi alle loro licenze. E quindi, come minimo, comprenderle.

A dire il vero la gran parte dei progetti open source di interesse oggi per le aziende è coperta da licenze che non pongono particolari ostacoli allo sviluppo interno.

Le licenze Apache, Mozilla o CDDL appartengono a questa categoria: i moduli he le adottano possono essere usati senza problemi anche per progetti commerciali, basta soddisfare alcuni requisiti semplici come non modificare il codice o indicare chiaramente a chi fa capo.

Il confronto tra alcune licenze Open Source
Il confronto tra alcune licenze opensource

Molte altre licenze rendono invece i relativi progetti opensource di fatto inutilizzabili per le imprese. Rientrano in questa categoria i progetti le cui licenze ad esempio impongono la pubblicazione del codice delle applicazioni che li usano oppure vietano esplicitamente l'utilizzo commerciale.

Come per la questione sicurezza a cui abbiamo accennato, anche in questo caso sia problema non va visto solo limitatamente a un componente specifico ma a cascata: tra i moduli da cui quel componente dipende, ce n'è qualcuno coperto da una licenza che ne impedisce l'uso aziendale?

Non è una questione di dettaglio. La casistica delle aziende portate in tribunale per una violazione delle licenze open source non dà indicazioni sempre coerenti, esiste però una tendenza a considerarle comunque in qualche modo vincolanti legalmente.

Anche se il proprio dipartimento software non crea applicazioni commerciali in senso proprio, meglio evitare qualsiasi ordine di problemi e impegnarsi in una gestione più dettagliata dei propri software.

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato sulle novità tecnologiche iscriviti alla newsletter gratuita.

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here