Proteste e sabotaggi del software Open Source (con Daniele Scasciafratte)

In generale, tutti noi siamo un po’ abituati a pensare al mondo dell’open source come ad una sorta di ecosistema di migliaia e migliaia di software, librerie e strumenti che sono fondamentalmente gratuiti e sempre disponibili. Per questo motivo, a volte in veste di sviluppatori, altre volte in quelle di semplici utilizzatori, tendiamo a fare ampio uso di tutto questo codice e a darlo essenzialmente per scontato. In alcuni casi poi, con il tempo, questi componenti sono diventati addirittura elementi alla base di moltissime realtà professionali, dal piccolo software fino alla codebase di prodotti di aziende anche molto grandi. E pertanto, volenti o nolenti, i loro sviluppatori, che a volte si riducono semplicemente ad un piccolo team o addirittura un singolo sviluppatore indipendente, si sono ritrovati ad avere nelle proprie mani un potere e una responsabilità notevoli. E proprio sfruttando questa sorta di posizione privilegiata, alcuni di loro di recente hanno deciso di mandare dei messaggi, creando però al contempo una serie di problemi all’interno delle comunità di sviluppatori. Oggi quindi parliamo di sabotaggio di software e lo facciamo con un ospite d’eccezione, come al solito però dopo la sigla. Negli ultimi mesi ci sono stati un paio di episodi nel mondo delle librerie open source e in particolare in quello di NPM che oserei definire perlomeno preoccupanti. NPM, per chi non dovesse essere pratico di programmazione Java, non è altro che un gestore di pacchetti al pari di come lo è Composer per il PHP o Apt per le distribuzioni Linux basate su Debian. In pratica permette di scaricare e installare librerie e componenti all’interno dei propri progetti software, e questo semplicemente lanciando un comando. Di fatto si tratta di quel concetto di dipendenza in software del quale abbiamo già parlato nell’episodio sulla dependency confusion, quindi se non l’hai già fatto ti consiglio di recuperarlo per farti un’idea più approfondita dell’argomento. Ma cosa è successo di tanto grave? Beh, in pratica alcuni sviluppatori di pacchetti piuttosto importanti hanno deciso di sabotare le loro stesse librerie per mandare forti messaggi ai propri utilizzatori. Nel primo dei due casi, che risale all'8 gennaio di quest’anno, Marak Skires, che sicuramente non si pronuncerà così, ha pubblicato delle versioni aggiornate delle proprie librerie chiamate Colors e Faker, nelle quali ha appositamente inserito dei bug studiati per bloccare e mandare in crash i progetti che le utilizzavano. Al momento dell’installazione, infatti, in tutti i progetti appariva la scritta Liberty, ripetuta tre volte, seguita poi da una serie infinita di caratteri incomprensibili. Lo stesso Skires ha dichiarato Queste donazioni hanno contribuito a impedire che lo sviluppo di Faker si bloccasse completamente, ma non sono sostenibili. Mi piace lavorare su Faker, ma non posso nemmeno permettermi di lavorare gratuitamente. Come la maggior parte di noi, ho persone che dipendono da me e ho delle bollette da pagare. Non volendo arrendermi, ho deciso che la migliore linea d’azione era cercare di monetizzare il progetto Faker per garantire un futuro sostenibile. Le motivazioni del gesto, quindi, sono chiare e a prima vista sembrerebbero anche condivisibili. Per un certo periodo anche io ho provato a mantenere un piccolo progetto open e conosco i problemi, ma la bravata di Skires ha causato problemi ben più gravi. Le stime, infatti, dicono che le due librerie sabotate cubano più di 20 milioni di download settimanali e servono a far funzionare oltre 20.000 progetti. E qualcosa di molto simile si è ripetuto anche il 7 marzo di quest’anno, quando Brandon Nozaki Miller ha inserito in un aggiornamento del proprio pacchetto Node IPC un codice che geolocalizzava gli indirizzi IP di chi lo installava e cancellava tutti i file degli utilizzatori che risultavano collegati da Russia e Bielorussia. Chiaramente, in questo caso, il messaggio era contro l’invasione russa dell’Ucraina, ma ciò non toglie che comunque il gesto ha diffuso il panico nella comunità degli sviluppatori, i quali inizialmente hanno ipotizzato attacchi di tipo supply chain, cioè quelli che prendono di mira un componente intermedio del software invece di colpire direttamente l’obiettivo finale. In entrambi i casi, comunque, è stato necessario un intervento che potremmo definire dall’alto, cioè da parte dei gestori delle piattaforme dei pacchetti, che hanno dovuto ripristinare le versioni precedenti e sospendere temporaneamente gli account degli sviluppatori. E dato che non è la prima volta che si verificano eventi del genere, qui con noi oggi, per aiutarci a fare un po’ di chiarezza in questo fenomeno crescente, c’è Daniele Scasciafratte, anche conosciuto come MTE90, esperto sviluppatore fullstack e membro attivo della comunità open source italiana. Ciao Daniele, benvenuto, e ti chiedo di iniziare subito raccontandoci un po’ chi sei e qual’è il tuo rapporto con il mondo dell’open source. Ciao a tutti, è la prima volta che appaiono in un podcast di altri, ci intende oltre il mio quindi mi trovo dall’altra parte della barricata e fa un po’ strano. Nella vita ho una web agency e mi occupo di un po’ di tutto, inclusa la sistemistica, e la mia formazione non è accademica, è avvenuta negli scorsi 16 anni grazie all’open source. Sono attivo in Mozilla Italia dal 2013 e per Mozilla ho ricoperto due roli internazionali come volontario, ho partecipato anche a eventi interni dei dipendenti, poi sono nella comunità WordPress dal 2015, sono tra i coorganizzatori dei meetup di Roma Eterni, che speriamo di riprendere adesso che è finito lo stato di emergenza, e contribuisco al core di WordPress oltre a vari progetti della comunità. Poi dal 2021, cioè dall’anno scorso, sono nel direttivo dell’associazione Italia Linuxosity, che è quella che dirige e gestisce tutti i Linux User Group in Italia, e sono tra i fondatori del Linux User Group della mia città di Lieti dal 2018, poi tra l’altro che gira, e per concludere ho scritto un libro gratuito open source in inglese proprio su come contribuire all’open source in modo corretto. Perfetto. Daniele, raccontavo poco fa che in questi ultimi mesi si sono verificati un paio di eventi che hanno generato un certo panico in alcune community open source, ce ne vuoi parlare? Ci vuoi raccontare cos’è successo? Non so quanti di voi abbiano mai contribuito a un progetto FOSS, oppure che sono dei maintainer di un progetto usato da altri o creato da altri, il problema è il tempo che si dedica in questa attività, perché, ad esempio, nella mia vita ho ricevuto donazioni ad alcuni dei miei progetti, ma parliamo a stima, così a occhio, che forse siamo sui 200 euro in dieci anni, e capite che sono pochi. Daniel Stenberg è l’autore di Curl, sul, non so qual è il modo migliore di pronunciarlo, che si dice che è il secondo progetto open source più utilizzato al mondo dopo Linux, quindi diciamo che è bello e importante, e spiega a lui nel suo blog il concetto della piramide a livello di open source, che cos’è? Praticamente gli spiega com’è diviso, ovvero più il progetto è di basso livello, tipo sistema operativo o librerie, impatta sempre più persone, ed è più complicato gestirlo, quindi ci si occupa principalmente di manutenzione perché è un argomento delicato, mentre più il progetto riguarda interfacce o servizi web, è più facile farci soldi a rilasci più frequenti e linguaggi più semplici, e questo si trova in cima alla piramide, mentre la parte di sistema operativo si trova sotto, e quindi questo si vede nel mondo JavaScript, in cui è successo tre volte negli scorsi anni questa situazione, con l’Eftpad che fu un pacchetto che era stupidissimo, serviva a togliere del test dello spazio a sinistra della stringa, e che era una dipendenza in molti pacchetti che poi a loro volta erano dipendenze di altri, e quindi venne rimosso dallo sviluppatore, e quindi ci fu un macello perché andava tutto in crash praticamente, perché non c’era questa libreria di 5 righe, potremmo dire, però parliamo di qualche anno fa, invece recentemente, nello scorso anno, è successo due volte con Colors e Fager dello stesso autore, che da un momento all’altro lui ha scapociato, potremmo dire, ovvero ha deciso di lamentarsi pubblicamente del fatto che delle aziende grandi utilizzano i suoi progetti, ma lui non ci guadagna un euro, e quindi decise di metterci un avviso, all’inizio feceva crashare perché aveva scritto male il codice, aveva fatto una release, poi aveva fatto un’altra, sistemando doveva mettere un avviso eccetera, e questo ha creato dei problemi di nuovo a cascata, e l’ultimissima è successo un mese fa, è del pacchetto Pis, praticamente una dipendenza di un altro pacchetto Node e PC, che è a base di molti altri, che praticamente verificava se tu eri con un indirizzo IP russo o bielorusso, e ti cancellava dei file, o ti brasava tutto l’hard disk. Ecco, questi sono degli impatti, cioè hanno un alto impatto, però è limitato al mondo degli sviluppatori perché sono delle librerie, e gli ambienti di produzione sono difficilmente impattati da queste cose che avvengono in un momento, perché diciamo c’è un flusso quando vengono effettuati questi rilasci, quindi diciamo che in questi casi si sono intervenuti subito per il problema e sistemandolo, però questi maintainer hanno sabotato in un modo o nell’altro i loro stessi progetti, chi togliendo il pacchetto, chi modificandolo, o chi proprio cancellava tutto. Ecco, quindi è un comportamento che possiamo dire sbagliato. Beh sì, probabilmente non è il modo migliore di comportarsi, comunque a beneficio di chi ci ascolta aggiungo solo che FOSS è acronimo di Free and Open Source Software e include tutti quei software il cui codice è liberamente disponibile e riutilizzabile, dico bene? Sì esatto, è la differenza tra Open Source e Free Software, con quella sigla si intende un software che copre entrambi gli aspetti, ovvero FOSS. Praticamente Open Source è solo software, mentre nel Free Software c’è anche la parte etica, come ad esempio Open Source non vuol dire che è gratuito de facto, ma che puoi pagare per avere il codice, mentre Free Software vuol dire che sei libero da subito di avercelo, di farci quello che vuoi. Quindi filosoficamente parlando il FOSS è ancora più libero dell’OSS che sta per Open Source Software, FOSS sta per Free Open Source Software. Quindi se non si capisce questa piccola differenza si butta tutto in cacciara come quello che è successo, infatti tutti si stupiscono dei fatti di quello che è successo, perché non c’è proprio una conoscenza di base. Chiarissimo, quindi al di là degli intenti effettivi degli sviluppatori che sicuramente saranno nobili o perlomeno condivisibili, mi sembra chiaro che questa non sia la maniera corretta di agire. Secondo te quali erano gli effetti sperati in questi due episodi e quali invece sono gli effetti realmente ottenuti? Non è la maniera corretta per niente, le quattro libertà sono chiare e semplici, tra cui chiunque deve poterlo usare e modificare, il che ci pone sull’etica. Gli effetti realmente ottenuti sono fastidi e intatta nel marchio inteso come globale del concetto di Open Source, facendolo regredire a 20 anni fa quando era visto solo come qualcosa del mondo amatoriale, non ci puoi fare business con Open Source, oppure non puoi utilizzare roba Open Source e farci cambiare un’azienda, quindi crea un problema di fondo. Quindi non stiamo parlando di progetti personali per mandarci un messaggino quando i bitcoin si alzano, è qualcosa che colpisce troppi contesti, ad esempio molti progetti hanno messo degli avvisi quando si utilizzano riguardo la guerra che conosciamo tutti insomma, proprio c’è un avviso di stare da una certa parte per fare sensibilizzazione, il punto è che questo comportamento di questi sviluppatori che hanno fatto questo casino era per mandare un messaggio, però volevano essere sicuri che tutti e che nessuno potessero perderselo, cioè deve essere evidente che tu l’hai visto, quindi non si possono paragonare a dei terroristi da questo punto di vista, perché anche loro non vogliono mandare un messaggio e essere sicuri che tutti se ne accorgono, ma più degli inconscienti letteralmente che questi non si rendono conto dell’effetto delle proprie azioni brutalmente, quindi non si tratta di un bug sfuccido ma di qualcosa di interintenzionale, cioè che per me si può paragonare a quando viene messa una vector appositamente, quindi è inutile fare dei hipster con le live di programmazione se poi non si ha un’etica, questo è quello che manca, chi ha a che fare con il pubblico, quindi io che rilascio qualcosa che poi qualcun altro utilizza, deve comportarsi in un modo corretto, preciso come richiesto ad esempio sui social network quando si rappresentanti di comunità e gruppi, cioè tu sei colpevole se tu non lo utilizzi nel modo più consono per il ruolo che ricopri. Hai parlato di quattro libertà, immagino tu ti riferisca alle quattro libertà fondamentali definite dalla Free Software Foundation, ce le vuoi spiegare? Sono le quattro libertà definite dall’Open Source Initiative che è la fondazione che definisce se una licenza è open source, le cosiddette OSI, ovvero la libertà di eseguire il programma per qualsiasi scopo, di studiarlo e modificarlo, di distribuirlo senza limiti, di migliorare il programma e di condividere queste modifiche per tutti. La Free Software Foundation, compresa anche la versione europea che è basata in Germania, ma c’è anche qualcuno in italiano, invece porta avanti le battaglie riguardo proprio l’etica, quindi ad esempio sui DRM per gli ebook o sui film, oppure sull’accesso dei dati e la privacy, oppure contro l’obsolescenza programmata dei dispositivi. Ad esempio la Free Software Foundation Europe ha lanciato da qualche mese la campagna Upcycling Android, che è pensata per insegnarti a riciclare il tuo vecchio smartphone, quindi quando il smartphone non riceve più gli aggiornamenti perché il produttore ha deciso così, ma lo smartphone è ancora buono, funziona eccetera, di metterci una versione di Android più moderna. Quindi invece di avercelo come ce l’ho io, come ce l’abbiamo un po’ tutti, a prendere la polvere in un cassetto, si possono riutilizzare e aumentare la vita a discapio di quello che dice il produttore. Un’altra campagna che ha fatto anche lei, che è molto più famosa, è chiamata Public Money, Public Code, quindi già dal nome capite qual è il concetto. Quindi ecco, un conto è il progetto, un altro è il mondo intorno e l’etica. Questa è la differenza. Molto interessante. Poco fa ci hai fatto presente che non è la prima volta che accade una cosa del genere, ma almeno per il momento il fenomeno sembra abbastanza legato alla comunità del JavaScript. Credi che si tratti di un caso o che sia dovuto alla tipologia di community o di tecnologia? Ad esempio al fatto che il mondo JavaScript fa un enorme uso di dipendenze. Mi pare infatti di ricordare uno studio di un paio di anni fa che posizionava la tecnologia basata su JavaScript tra quelle che in assoluto fanno più uso del concetto di dipendenza. Non sono riuscito a trovare casi simili in altri linguaggi e questo per una domanda sull’etica di questi sviluppatori e conoscenze del termine open source e delle licenze. Il mondo JavaScript è esploso proprio, letteralmente con moltissimi programmatori che di open source non sanno proprio niente, se non che si scarica da GitHub e ciao a tutti. Ricordo anni fa quando ci furono le sanzioni verso l’Iran. Un utilizzatore di Asterisk, che è il software open source più utilizzato al mondo per fare i centralini VoIP, quindi internet, che è prodotto da un’azienda americana, lo contattò perché l’utilizzava in Iran. In Iran c’erano delle sanzioni e quindi veniva detto di non utilizzarlo perché c’erano proprio le sanzioni, però la licenza non comprende questa cosa, quindi il contesto è diverso ma ci pongono proprio delle domande sull’azione di tutto quanto. Ad esempio in uno abbiamo un singolo che senza preavviso agisce in modo sconsiderato, perché questo è quello che è successo, verso chi utilizzava il suo strumento in modo cosciente o meno, quindi come uno che guida per strada e che può essere anche una dipendenza, perché quindi uno non lo sa che ci sta nel mezzo quel pacchetto, in un altro che si tenta di applicare delle leggi che però non coincidono con la licenza del progetto. Quindi diciamo che c’è proprio una differenza di contesto, anche se il problema è simile, come è successo con il caso di ICE, che è l’agenzia americana per l’immigrazione e che utilizzava software FOSS e quindi è stata una ribellione in America da questo punto di vista, e nacquero delle licenze che però imponevano di utilizzare questi progetti in modo positivo, che non urtasse nessuno, che è lo stesso problema che ha avuto IBM quando anni fa si scontrò con la licenza di JavaScript Int, l’antenato di ESLint, che era una licenza stupidissima di tre righe, proprio che non anche ci si preoccupava più di tanto, però IBM a livello illegale non gli andava bene, cioè voleva una chiarezza, perché diceva che la licenza la doveva utilizzare per cose buone, punto. Però a livello legale, come si definisce se una cosa è buona? Come la intendi? Cioè, c’è molte sfaccettature, quindi come fai a definire se io potrei utilizzare questo progetto per qualcosa che può urtare qualcuno? Perché ogni discriminazione, ogni scelta, ogni decisione è una discriminazione verso qualche altra cosa, quindi quella scelta può, ad esempio io mando delle notifiche in tempo reale, però per qualche motivo certe volte non lo faccio. Questa può rientrare nel concetto della licenza perché sto urtando l’utente, non sto fornendo un servizio al 100%, può avere una rigaduta sulla licenza, ad esempio. Ecco, io JavaScript lo utilizzo dai tempi di XHTML, l’ho visto evolversi e onestamente a me non mi piace per niente, non mi piace più. Ne ho scritto male, ma non tanto del linguaggio, ma dei sviluppatori e dell’ecosistema che c’è intorno, perché effettivamente ha dei problemi. Quindi anni fa ci si lamentava di scatole chiuse con linguaggi tipo .NET, io ricordo che ero ragazzino, cominciai a lavorare con questo linguaggio, ma parliamo del 2006, quindi ci si trovava con questo framework, tu non sapevi che funzionava quello che c’era dentro, lo utilizzavi e pace. Però è come se a un ingegnere meccanico gli chiedi di fare un motore, ma lui non ha le basi, non sa come mai è stato scelto quel materiale rispetto ad un altro, e questo possiamo dire che è un errore fatale. Bene Daniele, direi che la tua idea è abbastanza chiara, ma dicevamo all’inizio che tu sei esperto nello sviluppo open source, partecipi a progetti importanti come Firefox e Wordpress, allora ti voglio chiedere qual è secondo te il modo corretto per uno sviluppatore di approcciarsi a questo mondo? Voglio dire, a costo di essere anche un po’ provocatorio, se io sviluppo qualcosa e lo rilascio open source, di fatto sto regalando il mio tempo, probabilmente ne regalerò altro in futuro per il mantenimento, era la motivazione di uno dei due episodi di cui abbiamo parlato, come deve fare i conti uno sviluppatore con questo fatto? Io faccio un ragionamento di due tipi, volontariato e passione. In volontariato ci si trova nel mondo ad esempio della croce rossa, dove si può avere un rimborso tipo della benzina per dirne una, ma mai un vero stipendio. Certo ci sta poi il tipo che lavora per la croce rossa, ma sono ruoli specifici diciamo, e come è normale nel mondo fosso open source di trovare fondazioni che con le stesse donazioni che ricevono pagano dei dipendenti, oppure aziende che utilizzano le tecnologie queste qui e contribuiscono a tempo pieno con dei dipendenti, cioè quel dipendente lui nel lavoro deve lavorare su quello, oppure quando gli serve fanno quello che gli serve e contribuiscono. Nel mondo di javascript questo è difficile perché manca la cultura e la sensibilità, perché non hanno l’etica, non sono passati diciamo verso un processo di formazione in cui hanno capito cosa significa fare open source, oppure si trovano come dipendenti di un’azienda e quindi utilizzano i software senza esserne consapevoli a loro volta di quello che stanno utilizzando. Quindi si può dire che in questi contesti è l’azienda stessa che non contribuisce a certi progetti perché potrebbero non saperlo oppure ne fanno così tanti e decidono di dare priorità ad alcuni, come abbiamo detto prima nella piramide. E sul tema della passione faccio il paragone con il calcio, parte che è uno sport che a me non mi piace per niente proprio per via del suo ecosistema, come è anche in questo di javascript. Io preferisco essere il giocatore in campo che stare sul bordocampo a sbraitare, perché la differenza è una posizione attiva e positiva che fa qualcosa di effettivo, mentre il secondo è passivo e influisce solo nel fattore promozionale che per quanto è importante è come il meme di quello che lavora mentre altri sette operai lo guardano e che gli dicono cosa fare. Ecco quindi lo si fa per la gloria? Sì. Lo si fa perché piace? Sì. Ottengo un rimborso o uno stipendio? Molto meglio. Non ho mai detto io a uno sviluppatore che il suo progetto ha un bug e come l’ho sistemato? Ti meriti delle botte, nel senso che devi essere, cioè te le stai cercando proprio. Vorrei che un oggetto facesse una certa cosa, un progetto scusatemi, facesse una certa cosa, fallo o chiedi aiuto su come farlo. Questa è la mia filosofia, la persona deve essere il cambiamento. I movimenti diciamo rivoluzionari o che cambiano le cose, possiamo dirla così, vengono solo se ci sono degli esempi politicitivi e con il tempo. Questa è la base del concetto di opensource per me. Bene Daniele, io ti ringrazio per essere stato qui con noi. Vuoi ricordare a chi ci ascolta dove ti può trovare sul web e quali sono i tuoi contatti? Daniele.tech è il mio sito con tutti i link, quindi troverete sul sito il menu con tutti i miei social, tra cui anche il podcast e il libro di prima. Quindi potete ritrovarmi ovunque, come mi ha scritto Valerio su Telegram, vi potete trovare su tutti i social di questo mondo. Il mio nickname è MT90, quindi vi trovate uguale lì senza problemi. Quindi ecco, ci vediamo, alla prossima volta! Assolutamente, grazie e alla prossima! Dunque, il problema sembra essere di tipo culturale. Da una parte abbiamo un modo di sviluppare software sempre più interconnesso e interdipendente, dall’altra abbiamo sempre più sviluppatori e componenti opensource disponibili. La possibilità che uno sviluppatore indipendente sbrocchi, per usare le parole di Daniele, e faccia danni, come abbiamo visto, sono più che concrete. In generale, potremmo dire che è il rischio di dipendere da un qualcosa. Un giorno questo qualcosa potrebbe venire in qualche modo meno. E quindi dovremmo rinunciare a qualsiasi dipendenza nel nostro software? Certo, io non sono un fan dell’utilizzo indiscriminato delle dipendenze, se hai ascoltato l’episodio sulla Dependency Confusion lo saprai, ma d’altro canto nemmeno credo sia corretto reinventare la ruota in ogni singolo progetto che si sviluppa. Direi piuttosto che il segreto, un po’ come in tutte le cose, è farci attenzione e provare a stare, diciamo, nel mezzo. Soffermarsi un attimo a chiedersi ma mi serve proprio questo pacchetto, magari qualche volta produrrà una risposta negativa. Semplicemente perché useremo l'1% di quel pacchetto oppure perché si tratta di qualcosa di così semplice che possiamo pensare di integrare direttamente o scrivere in autonomia? Dipende dal contesto, è ovvio, ma se non ci poniamo mai attenzione nemmeno riusciremo a cogliere mai le occasioni che ci si presenteranno davanti. Nel primo caso di cui abbiamo parlato poi, quello di gennaio, sembra anche esserci una questione di etica professionale. Aziende che fatturano magari anche tanto utilizzando software open source spesso dimenticano di contribuire anche minimamente agli stessi progetti che gli permettono di lavorare. Ma in realtà siamo proprio sicuri che sia questo un comportamento intenzionale? Come diceva Daniele, magari un’azienda sceglie semplicemente di indirizzare le proprie risorse su un progetto open source tralasciandone evidentemente un altro. Oppure, se ci riflettiamo un attimo, in linea generale diciamo che chi utilizza attivamente le librerie open source all’interno di un’azienda, spesso in quella stessa azienda non è la stessa persona che poi prende decisione su come spendere i soldi. Come ha riportato lo stesso Squeers infatti nella sua dichiarazione alcune donazioni da sviluppatori indipendenti arrivano e probabilmente questo dipende dal fatto che quando sei indipendente o sei piccolo la figura dello sviluppatore e dell’amministratore spesso o coincidono o perlomeno sono più vicine rispetto ad esempio ad una multinazionale. Forse una possibile soluzione potrebbe essere una sorta di movimento che parte dal basso dagli sviluppatori stessi all’interno dell’azienda, i quali potrebbero far presente quanto lavoro si risparmia utilizzando il pacchetto X piuttosto che quello Y invece di doversi riscrivere tutte le funzionalità da soli. Addirittura qualche tempo fa ricordo di aver sentito parlare di una proposta per far pagare un piccolo contributo per download. Superata una certa soia mensile o settimanale con il gestore di pacchetti l’utente avrebbe dovuto pagare una piccola commissione ma un meccanismo del genere presupporrebbe tutta una serie di modifiche tecniche non indifferenti al sistema di gestione delle dipendenze e non so in realtà quanto questo sarebbe realmente fattibile. Se riflettiamo invece sul secondo caso di cui abbiamo parlato, cioè quello di marzo, la questione è palesemente di tipo politico oltre che etico. Certamente la motivazione del gesto, cioè una protesta contro la guerra in Ucraina, è un qualcosa di molto importante, soprattutto per noi europei, ma questo basta a giustificare il sabotaggio di sviluppatori russi. D’altro canto però posso anche capire chi vuole in qualche modo far sentire la propria voce riguardo qualcosa che ritiene sbagliato o importante e pertanto decide di usare quei propri mezzi che ha a disposizione. Insomma tutto questo per dire che come al solito la questione è complicata ed io non mi sento certo la persona che ha tutte le risposte. Tuttavia una cosa credo di saperla e cioè che è importante porsi le domande e soprattutto farlo nel modo migliore possibile. Bene, io spero di averti come al solito condiviso qualche ragionamento e qualche informazione interessante. Voglio sapere tu come la pensi su questa storia. Sul sito di Pensieri in Codice trovi tutti i miei contatti e ancora meglio il link al gruppo Telegram dove possiamo discutere insieme con gli altri membri della community. Prima di lasciarti ti ricordo che Pensieri in Codice è un podcast indipendente interamente prodotto da me nel mio tempo libero e con le mie risorse personali. Quindi se apprezzi quello che faccio e se sei arrivato fin qui immagino che l’apprezzi, sul sito pensieriincodice.it mi raccomando con due i trovi tutti i metodi per inviarmi il tuo contributo. In tal modo mi aiuterai a coprire i costi di attrezzature e abbonamenti mensili. Se non ti sei già iscritto ricorda di farlo per non perderti nessun episodio. Trovi Pensieri in Codice su tutte le maggiori app e piattaforme di podcast. Io ora ti ringrazio per l’ascolto, ti do appuntamento al prossimo episodio e ti ricordo che un informatico risolve problemi, a volte anche usando il computer.