Ed eccoci qui in questo mio nuovo post, che volevo pubblicare da tempo, ma che per qualche motivo, che sinceramente non capisco neppure io, ho sempre rimandato. E quindi oggi, rimedio pubblicando finalmente questo articolo.
Come avrai potuto leggere dal titolo o vedere dalla miniatura di questo articolo, oggi andremo a parlare di pubblicazione del codice sorgente. Argomento per molti scontato, e quindi di facile risposta. Infatti per molti utenti è facile risponde con un bel “Ma è ovvio, conviene sempre” oppure con un bel “Ma è ovvio, non conviene quasi mai“. Molto spesso si danno questo tipo di risposta, senza analizzare ogni singola problematica, o molto più semplicemente senza comprendere ogni singolo problema che ci potrebbe essere nella scelta. Infatti entrambe le scelte, ovvero la decisione di pubblicare o non rendere pubblico il sorgente di un proprio programma che si è realizzato, non sempre è così semplice ed entrambe le decisioni portano a determinati vantaggi e svantaggi.
Andiamoli ad analizzare insieme
Iniziamo con il suddividere le applicazioni in due tipologie differenti. Lo so, ce ne sono tante di tipologie di software, ma per ragioni di praticità, le andremo a classificare in due macro gruppi.
- Applicazioni client side
- Applicazioni server side
Applicazioni client side
Iniziamo ad analizzare la prima categoria. Le applicazioni client side, sono tutte le applicazioni che girano, vengono eseguite (per dirlo in una terminologia più corretta), nei dispositivi dell’utente. Quindi nello smartphone, tablet, pc e qualsiasi altro dispositivo. Quando andate a scaricarvi un’app dallo store del vostro device o quando andate a scaricare e quindi, molto probabilmente, anche installare (dico probabilmente dato che alcune applicazioni non richiedono installazione), un’applicazione da un determinato sito internet, andate ad utilizzare un’applicazione che funzionerà solo nel vostro dispositivo.
Quell’applicazione sarà più o meno al sicuro da attacchi informatici a seconda della vostra esperienza con il computer in termini di sicurezza e da come usate il computer. Quindi dipende da quali siti guardate e da come li guardate. Dipende da che dispositivi connettete al computer (chiavette, hdd esterni ecc…) e così via.
Anche se voi prendete un virus o quell’applicazione viene in un qualche modo violata, vi basterà reinstallarla o nei casi più gravi formattare il computer e reinstallare Windows da 0 (Windows o qualsiasi altro sistema operativo che usate) per risolvere il problema.
Applicazioni server side
Un applicazione server side è un po’ diversa. Infatti questo tipo di applicazione innanzi tutto, come dice il nome della categoria, funziona solo su un server. Server che viene contattato da centinaia, o migliaia di persone, per vederne i suoi contenuti. L’applicazione che funziona nel server deve fornire i contenuti richiesti (se è un blog o un sito internet), o se è un altro tipo di piattaforma o applicazione, deve fornire quel determinato servizio. Molto spesso i server sono pensati per memorizzare grandi quantità di dati.
Ora non so se tutto questo vi ha fatto comprendere la situazione, per quanto riguarda le applicazioni server side. Se non è così, vediamo di fare un punto della situazione.
Mettiamo che un programmatore realizzi un’applicazione che è in grado di memorizzare file e dati degli utenti. Ad esempio un cloud. Un cloud come può essere SharekFile, ad esempio. Possiamo ben capire che se un’applicazione simile dovesse essere violata, chi ci rimette sono centinaia di utenti, che si ritrovano all’improvviso i loro dati, magari sensibili, in giro per la rete. E di riflesso il problema gira contro il programmatore, che molto probabilmente dovrà rispondere penalmente di questa cosa, dato che era lui il responsabile dei dati di tutta questa utenza.
Quindi il problema di un programmatore o di un team, che deve gestire un applicazione web, che quindi gira in un server, è molto grande. E in caso di problemi non può dire “formatto tutto e risolvo la cosa”. In questo caso si devono prevenire in un qualche modo, tutti i possibili problemi di sicurezza.
Quindi…
Come avrete potuto notare, fino ad ora, i due tipi di applicazioni sono molto diversi tra di loro. In realtà si potrebbe espandere il ragionamento spiegando tutti i tipi di applicazioni che ci possono essere lato client, e lo stesso per il lato server. Ma per non complicare troppo l’articolo, ci fermiamo qui con la definizione dei tipi di applicazioni. Andiamo quindi ad analizzare tutti i problemi nel pubblicare il sorgente di entrambi i tipi di progetti. Ovviamente andremo anche ad analizzarne i pregi.
Prima però… in cosa consiste pubblicare il sorgente di un programma?
Lo so, questa può sembrare una domanda scontata. Ma non la è per tutti. Infatti alcune persone non hanno ben chiaro questo concetto, che voglio approfondire in questa parte dell’articolo, per rendere a tutti più chiaro l’argomento.
Pubblicare il sorgente di un software significa in parole povere rendere nota, pubblica, la sua struttura, il suo funzionamento interno e rendere pubblica la “ricetta” dell’applicazione stessa. Questa può essere usata da un team per migliorare il programma. In molti programmi open source, dove il sorgente delle stesse è pubblico, troviamo diverse persone che hanno contribuito a risolvere dei problemi. Infatti uno dei vantaggi più grandi nel rendere il sorgente pubblico, è quello che se il programma è seguito da una community coesa, ci possono essere tante persone che danno una mano a trovare e a risolvere un bug, anche in tempi molto brevi. Troviamo molti programmi che presentavano dei bug che sono stati risolti in tempi record, anche nel giro di un’ora dalla segnalazione, grazie all’ambiente open source.
Questi tempi di sviluppo non possono esistere nei software proprietari, dove l’unico ente che risolve i problemi di un applicazione è l’azienda o il team che ha prodotto quella stessa applicazione.
Pubblicare il codice sorgente di un programma consiste anche nel condividere, come dicevamo prima, il suo funzionamento con gli utenti, che potranno vedere effettivamente come il programma gestisce ed elabora i dati, se invia le informazioni per scopi commerciali a delle aziende o se i dati incamerati rimangono solo di proprietà dell’utente. E’ possibile quindi vedere tante cose. E questo non è un male.
Ma ci sono anche degli svantaggi, che andiamo ad analizzare. Intanto quello che mi interessa è che ognuno ha capito correttamente cosa significa condividere il sorgente di un qualsivoglia software.
Pregi e difetti nel condividere il sorgente
Credo che ormai i pregi nel condividere un sorgente li hai già compresi. Infatti li abbiamo descritti in modo veramente molto completo precedentemente, in questo stesso post.
Credo che anche difetti, o contro, come li vuoi chiamare, li hai potuti comprendere, ma dato che non li abbiamo ancora descritti, ecco che rimediamo subito.
Il primo contro è il fatto che pubblicando il sorgente software, si possa comprendere il funzionamento dello stesso. Lo so abbiamo detto che è un pregio, ma in realtà è anche un difetto. Infatti questo tipo di informazione potrebbe e molte volte è così, potrebbe essere usata da persone con intenzioni non proprio buone, per comprenderne il funzionamento, per comprendere tutti i suoi sistemi di sicurezza, magari capire si ci sono dei bug, e raccolte tutte queste informazioni, procedere ad un vero attacco hacking. Ora, mettiamo che stiamo parlando di un’applicazione server side che deve gestire grandi quantità di dati. Mettiamo che questa app viene violata, per questo motivo. A chi va la colpa e la responsabilità? Beh ovviamente non certo a chi ha hackerato la piattaforma, per lo meno non subito. Ovviamente la colpa e i danni da pagare agli utenti, ricadono sulle spalle di chi ha sviluppato quella determinata applicazione. In termini giuridici funziona così. E non c’è molto da fare in questo.
Ovviamente chi ci rimette di più sono anche tutti gli utenti che da un giorno all’altro si ritrovano i propri dati in mano a delle persone che essenzialmente possono farci quello che vogliono. Quindi possono venderli, usarli per danneggiare delle persone. Possono farci quello che vogliono.
Certo non sto dicendo che la colpa di questo problema è solo per via del sorgente reso pubblico. Ma di certo potrebbe essere una causa, da non sottovalutare, durante la decisione.
Un secondo tipo di problema potrebbe essere che condividendo il codice sorgente, si mette a disposizione di qualunque persona la possibilità di copiare il tuo algoritmo, il tuo progetto, metterlo a proprio nome, e quindi prendersene il merito. Ovviamente poi può venderne anche l’idea. E se il progetto non è ancora stato brevettato, il proprietario originale può fare ben poco per riuscire a riprendersi il merito del proprio lavoro. Certo qualcuno dice di affidarsi alla Creative Commons License, una licenza che dovrebbe aiutare un proprietario di un qualsiasi contenuto (post, software o altro) a mantenere la sua proprietà su di esso, ma diciamo che questo metodo non ha un peso legale e giuridico come invece avrebbe un brevetto vero e proprio.
Una volta che la propria idea viene brevettata (azione che comporta un’ingente spesa economica, per lo meno in Italia, all’estero non lo so quanto potrebbe costare, o per lo meno non lo so di preciso e quindi per non dire imprecisioni, non approfondisco l’argomento), il secondo problema viene risolto, ma il primo, riguardante la sicurezza, non si risolve minimamente. Resta ed è un fattore che ripeto: va preso in considerazione, prima di decidere se rendere pubblico o meno il sorgente della propria applicazione.
È ancora facile prendere questa decisione?
Da quanto avrai potuto leggere da questo mio post (ti consiglio di approfondire l’argomento da fonti esterne, per avere un quadro generale o un quadro approfondito dell’argomento, molto più completo), prendere la decisione di rendere pubblico il sorgente di un’applicazione o renderlo privato non è poi così facile. Molta gente, come dicevo all’inizio, ritiene facile rispondere a questa domanda. Ma facile non è. Non lo è sia che si decide di rendere privato il sorgente, perché si rinuncia così a tutta una serie di vantaggi che abbiamo descritto, sia per chi decide di rendere pubblico il sorgente, che è vero ha tutta una serie di vantaggi, ma allo stesso tempo ha tutta una serie di svantaggi, che come nel caso precedente, deve tenero conto.
Quindi d’ora in poi, prima di muovere critiche verso chi sceglie di privatizzare o rendere di dominio pubblico il sorgente di un’app, e quindi se renderla open source o meno, pensaci su. E anche bene, per capire effettivamente il motivo della scelta di quel determinato team o sviluppatore singolo, indipendente.
In conclusione
Spero che questo mio articolo ti sia piaciuto e ti abbia suscitato dell’interesse mentre lo hai letto. Se è così sono veramente molto contento.
Con questo è tutto! Ti aspetto al mio prossimo post, ciao!
