Immagine in evidenza: Ken Suarez –Toys at Work series
Internet, per come lo conosciamo oggi, è composto da migliaia di componenti digitali che, assemblate tra di loro, danno forma ogni volta ad applicazioni e piattaforme diverse. Possiamo pensarle come dei mattoncini Lego: le unità fondamentali sono spesso le stesse, ma combinarle in modo diverso permette di generare strumenti e spazi digitali diversi.
Molti di questi mattoncini sono sviluppati direttamente dalle aziende e dalle organizzazioni che costruiscono applicazioni per il web. Altrettanti di questi mattoncini, però, vengono sviluppati da programmatori che non lavorano per grandi aziende e che rilasciano il proprio lavoro come open source, permettendo (eventualmente) a chiunque di contribuire a questi progetti.
Questi mattoncini open source sono stati descritti come le “strade e i ponti” del mondo digitale dalla ricercatrice e scrittrice Nadia Eghbal in una ricerca pubblicata per la Ford Foundation: si tratta di elementi fondamentali per il funzionamento di sistemi digitali complessi. La loro presenza e il loro funzionamento sono alla base del nostro uso quotidiano di internet.
È un fenomeno che affonda le sue radici nella storia dell’evoluzione di internet e in generale della programmazione. E che è stato riassunto con straordinaria efficacia dalla serie di web-comic xkcd.
Nonostante la loro importanza, però, i mattoncini open source dipendono spesso dal lavoro e dalla volontà di singoli programmatori che a titolo volontario impegnano il loro tempo per aggiornare, riparare e ampliare questi progetti. Le grandi aziende che utilizzano queste librerie gratuite, anche quando sono incluse in applicazioni e servizi a pagamento, il più delle volte non prevedono delle risorse per seguire la manutenzione di questi pezzi di software. Il risultato è che, sempre più spesso, il funzionamento e la sicurezza di librerie essenziali per piattaforme digitali gigantesche dipendono da pochissimi programmatori che lavorano gratuitamente.
Nella pratica, questa dinamica sta facendo emergere dei significativi problemi di sicurezza e compatibilità e, soprattutto, tende a mettere in secondo piano il riconoscimento e la remunerazione del lavoro svolto dai programmatori open source. Nella teoria, però, l’approccio open source dovrebbe poter garantire una vera e propria “mente alveare” in grado di contribuire all’innovazione del software attraverso un approccio orizzontale e decentralizzato.
La cattedrale e il bazaar
La teoria dietro a questo circolo virtuoso è descritta per la prima volta nel 1997 grazie al saggio La cattedrale e il bazaar dell’informatico e blogger Eric Steven Raymond. Nel saggio, Raymond mette nero su bianco alcune riflessioni derivanti dalla sua osservazione del processo di sviluppo del kernel di Linux e dalla sua partecipazione allo sviluppo di un progetto open-source chiamato fetchmail. Il saggio traccia i contorni di due distinti approcci allo sviluppo di software gratuito:
- il modello a cattedrale, per cui il codice sorgente di un dato software viene reso disponibile pubblicamente ad ogni aggiornamento, ma il codice sviluppato tra un aggiornamento e l’altro è disponibile solo al gruppo di sviluppatori che stanno seguendo il progetto;
- il modello a bazaar, per cui sia il codice sorgente che i progressivi aggiornamenti sono pubblicamente disponibili su internet — secondo Raymond, questo approccio è stato utilizzato per la prima volta da Linus Torvalds durante lo sviluppo del kernel di Linux.
La teoria di Raymond è chiara: “dato un numero sufficiente di occhi, tutti i bug vengono a galla” — maggiore è lo spazio disponibile per collettivizzare lo sviluppo, maggiore sarà la sua efficacia e velocità, minore sarà la possibilità di non individuare bug o di non risolvere problemi di sviluppo. Quello a bazaar è un modello che prima dell’esperienza dello sviluppo del kernel di Linux non sembrava adatto a progetti complessi e – come sapientemente indicato dalla stessa pagina Wikipedia su questa teoria – è la differenza che intercorre tra un’enciclopedia commerciale (scritta con un modello a cattedrale) e Wikipedia (scritta con un modello a bazaar).
La realtà, ovviamente, presenta più sfumature di così: nel corso degli anni la complessità dei software è cresciuta a dismisura e i modelli orizzontali come quello di Wikipedia hanno saputo mostrare le loro potenzialità, ma anche i loro limiti. I rapporti di potere descritti dalla metafora della cattedrale e del bazaar, però, rimangono attuali e urgenti e raccontano il dilemma alla base del rapporto tra l’infrastruttura di internet e il codice open-source: chi mantiene queste librerie utilizzate ovunque? Come possiamo assicurarci che questa manutenzione, spesso svolta a titolo volontario, continui a essere fatta? E, soprattutto, cosa succede quando non viene più svolta e la legittimità di questi progetti viene messa in discussione?
La Open Source Initiative (OSI) e OpenLogic by Perforce hanno unito le forze per condurre uno studio globale circa lo stato di salute dei software open source. In sole sei settimane, hanno raccolto 2.660 analisi da ogni angolo del mondo da aziende di ogni dimensione a rappresentanza di 15 diverse industrie.
Per semplicità, ecco i 10 punti principali del report:
- il 77% dei rispondenti allo studio hanno incrementato l’uso di software open source nelle loro organizzazioni negli ultimi 12 mesi, e il 36,5% ha dichiarato di aver incrementato questo uso in modo significativo.
- il 79% dei rispondenti allo studio promuovono organizzazioni open source.
- La prima ragione per usare software open source è la possibilità di accedere ad applicazioni innovative, facendo così passare la riduzione dei costi al secondo posto. La sicurezza e la disponibilità di patch sono altre ragioni in cima alla classifica.
- La prima barriera nell’adottare software open source è l’assenza di competenze interne per testarlo, utilizzarlo, integrarlo e supportarlo.
- La prima sfida per supportare il software open source in ogni industria riguarda l’esperienza e le competenze del personale.
- Il più alto incremento nell’uso riguarda gli strumenti di DevOps open source. Gli strumenti CI/CD cloud-native hanno visto un rilevante incremento nell’uso.
- Le nuove tecnologie più desiderate sono i container e Kubernetes. Solo il 18% dei rispondenti allo studio usa già Kubernetes, il 39% ha una strategia per il cloud e il 29% ha una strategia per la containerizzazione.
- Nella percentuale più alta tra tutti i tipi di organizzazione, il 41% delle piccole organizzazioni ha una strategia per l’open source.
- Le industrie bancarie, assicurative e relative ai servizi finanziari hanno il più alto numero di progetti Innersource.
- Solo il 13% delle organizzazioni ha un dipartimento legale con dimestichezza rispetto alle licenze open source.
L’open source è ovunque
È fondamentale essere consapevoli della centralità attuale del codice open source. Non si tratta di una nicchia per appassionati, ma di uno dei pilastri portanti dell’infrastruttura informatica globale contemporanea. Senza le librerie open source (e la filosofia con la quale sono state sviluppate), oggi internet avrebbe un aspetto profondamente diverso.
Un chiaro esempio è WebKit, un noto motore di rendering delle pagine web utilizzato nei browser. Nato a giugno del 2001 come derivazione di un altro prodotto open-source, è stato successivamente utilizzato come base di partenza per altri componenti e prodotti, tra cui numerosi altri browser.
Nel 2013, Google ha annunciato un’ulteriore derivazione, chiamata Blink, utilizzata in Google Chrome.
Non parliamo soltanto di prodotti e servizi orientati ai consumatori come i browser: tantissime tecnologie server, come Apache o Nginx, application server come Tomcat e database management system come PostgreSQL, MariaDB, sono tutti sviluppati in modalità open source. Interi, giganteschi raccoglitori di software come Github, Gitlab e Bitbucket ospitano e distribuiscono librerie di codice open source utilizzabili e modificabili da chiunque.
Come poche righe di codice hanno generato disastri
Le cronache di disastri generalizzati collegati alla mancata manutenzione o al “pensionamento” di queste librerie open source sono tante e nel corso del tempo si sono stratificate costruendo una narrazione contigua di questo fenomeno. Un esempio è quanto avvenuto il 22 marzo 2016. Utenti e sviluppatori di software per il web si stanno svegliando in tutto il mondo per essere accolti da una serie di strani malfunzionamenti apparentemente comuni a tantissime piattaforme diverse. I log di errore riportano un colpevole: non è possibile recuperare la libreria ‘left-pad’, un elemento dell’infrastruttura di moltissime piattaforme consistente di appena 11 righe di codice.
Questo errore impedisce la compilazione completa del codice in cui è ospitato e interrompe le operazioni di manutenzione e aggiornamento dei software in tutto il mondo. In questo caso, l’effetto farfalla si è sviluppato così: left-pad è un pacchetto di codice utilizzato da sviluppatrici e sviluppatori di tutto il mondo per sveltire un’operazione base di programmazione. Questo pacchetto viene utilizzato nella scrittura di codice per evitare ai programmatori di dover scrivere più volte le 11 righe di codice che left-pad contiene, e l’intero software svolge un’operazione talmente basilare da risultare utilizzato nelle applicazioni più disparate. Quindi: left-pad è un piccolo mattone di software, utilizzato per costruire altri mattoni di software che a loro volta servono per costruire altri software che vengono poi utilizzati dalle piattaforme più grandi attualmente in circolazione — da Netflix, a Facebook, passando per Airbnb. Esiste quindi un’importante relazione di dipendenza tra il funzionamento dei siti che visitiamo ogni giorno e il funzionamento di, in questo caso, left-pad.
Quindi, chi si assicura che left-pad funzioni e sia sempre aggiornato correttamente, nonostante la sua semplicità? Nientedimeno che il padre di left-pad: Azer Koçulu è uno sviluppatore (al tempo) ventottenne e nel tempo libero ha creato il pacchetto left-pad, oltre che molti altri. Da sempre, come tante altre sviluppatrici e sviluppatori, porta avanti questa attività di manutenzione e controllo del pacchetto a titolo puramente volontario, mettendo a disposizione di colleghe, colleghi e aziende gigantesche tutti i suoi pacchetti. Trattandosi di una libreria open source, anche altri sviluppatori possono intervenire per prestare attività di manutenzione, ma il più delle volte questa responsabilità cade sul creatore del pacchetto e pochi altri volontari.
Il 20 marzo 2016, Koçulu scrive in una mail: “Penso di avere il diritto di cancellare tutta la mia roba”. È indirizzata a NPM, la piattaforma utilizzata da sviluppatori di tutto il mondo per distribuire pacchetti come left-pad. Poco dopo, Koçulu cancellerà effettivamente i suoi pacchetti da NPM, creando un serissimo problema di dipendenza nei software che li utilizzavano, di fatto rompendoli temporaneamente. In un attimo, il castello di mattoncini crolla: tutti i software che, in qualche modo, utilizzavano left-pad per funzionare vengono privati di un pezzo fondamentale.
Un sintomo tecnico di un problema politico
In questo caso, il crollo non è avvenuto per una folata di vento, ma per una presa di posizione profondamente politica da parte di Koçulu. L’11 marzo, pochi giorni prima della cancellazione di tutti i pacchetti, lo sviluppatore riceve una mail da parte di Bob Stratton, un consulente brevetti e marchi per Kik, una piattaforma di messaggistica istantanea. La richiesta è semplice: nel suo portfolio di pacchetti su NPM, Koçulu ne ha uno chiamato kik che viene utilizzato dagli sviluppatori per impostare rapidamente dei template di programmazione: il pacchetto è open-source e distribuito gratuitamente — Stratton vuole che Koçulu chiami il suo pacchetto in qualche altro modo, perché kik è il nome della piattaforma di messaggistica per cui lavora e che sta per lanciare un pacchetto omonimo su NPM.
La vicenda è all’ordine del giorno nelle dispute per proprietà intellettuale, ma prende una piega diversa quando Stratton riporta la richiesta ad NPM stessa che si schiera dalla parte di Kik e risponde a Koçulu: “In questo caso, crediamo che la maggior parte degli utenti che potrebbero imbattersi nel pacchetto kik, penserebbero comprensibilmente che sia collegato a kik.com; in questo senso, trasferire la proprietà dei nomi di questi pacchetti [npm-kik e npm-kik-starter, ndr] ci permette di risolvere questa confusione,” spiega laconicamente in una mail Isaac Schlueter, fondatore di NPM.
La risposta di Koçulu è altrettanto laconica e delusa: una piattaforma come NPM, che deve la sua notorietà anche al lavoro degli sviluppatori open-source, non esita a schierarsi con una grande azienda come Kik, di fatto tradendo il rapporto di fiducia con la comunità open-source. “Sono molto deluso dalla tua decisione. Ti conosco da anni e non mi sarei mai immaginato che avresti preso le parti degli avvocati specializzati in brevetti che lavorano per le grandi aziende e minacciano i collaboratori della comunità open-source,” scrive Koçulu nella sua mail a Schlueter, “[…] voglio che, oltre a questo pacchetto, siano cancellati tutti i miei moduli e il mio account. Non voglio più essere parte di NPM. Se non lo fate voi, ditemi come posso farlo velocemente. Penso di avere il diritto di cancellare tutta la mia roba da NPM.”
Koçulu, quindi, procede a ritirare tutti i suoi pacchetti da NPM eliminando dei mattoni fondamentali per migliaia e migliaia di software in tutto il mondo. Poche ore dopo il ritiro, la comunità globale di utenti e sviluppatori web si rende conto delle proporzioni del problema. Meno di 24 ore dopo lo scambio di email tra Koçulu, Kik ed NPM e il conseguente ritiro dei pacchetti, NPM è costretta ad esporsi pubblicamente annunciando l’annullamento della cancellazione di left-pad, per tutelare gli interessi collettivi della comunità di NPM.
Il problema politico è evidente: l’infrastruttura digitale contemporanea si fonda (anche) sul lavoro svolto e distribuito gratuitamente dagli sviluppatori open-source. Un lavoro volontario in nome di una filosofia condivisa dalla comunità open source. “Il fondamentale atto di amicizia tra i programmatori è la condivisione dei programmi,” scriveva nel 1985 Richard Stallman nel manifesto GNU, un progetto nato nel 1984 per progettare un sistema operativo completo utilizzando esclusivamente software libero (in gran parte sovrapponibile al mondo dell’open source, ma non del tutto). I prodotti di questo lavoro, come left-pad, sono diventati nel tempo delle componenti fondamentali del mondo della programmazione e vengono naturalmente inclusi anche in prodotti commercializzati privatamente. La domanda inevasa è quella raccontata dal caso di left-pad: come si tutelano gli interessi di questi sviluppatori e manutentori? Come si riconosce la loro importanza? Come si ricompensa il loro lavoro?
Una serie di bombe a orologeria
L’approccio open source favorisce il riuso del codice e permette a più sviluppatori di analizzare e mantenere molteplici componenti software. Il problema sorge nel momento in cui l’utilizzo e il funzionamento di queste librerie viene dato per scontato, finendo per far passare in secondo piano il fatto che la manutenzione di queste librerie venga svolta da volontari. Una ricerca di Synopsis che ha analizzato 1.250 infrastrutture software nel 2019, ha rilevato nell’82% di casi la presenza di componenti open source non aggiornate da più di 4 anni. Il punto, quindi, è prevedere le conseguenze del riuso di queste librerie e organizzarne la manutenzione, anche e soprattutto quando vengono incluse in prodotti commerciali dalla grandissima distribuzione.
Il caso di left-pad non è il primo e non è l’unico. A dicembre 2021, il mondo dello sviluppo è stato scosso nelle fondamenta a causa della scoperta di una vulnerabilità zero-day critica in Apache log4j, una libreria open source Java utilizzata per registrare le attività svolte da programmi informatici. Come nel caso di left-pad, log4j è utilizzata in migliaia di software ed è mantenuta da sviluppatori open-source in modo volontario. Questa vulnerabilità ha richiesto un intervento sistemico e immediato in tutto il mondo perché permetteva ad eventuali aggressori di eseguire istruzioni arbitrarie sui server affetti. Anche in questo caso, la responsabilità indiretta grava sulla mancata organizzazione di processi e condizioni chiare per la dei manutenzione di una libreria open source enormemente utilizzata.
Va anche detto, tuttavia, che la natura open source di Log4j ha consentito una pronta reazione alla minaccia data da questa vulnerabilità. Infatti, ancora prima che la soluzione al problema venisse fornita dal progetto Apache, la comunità open source ha potuto sviluppare delle efficaci tecniche di mitigazione. Inoltre, l’approccio open source ha permesso di scoprire ulteriori vulnerabilità gravi, proprio per il fatto che tutta la comunità stava attivamente analizzando il problema.
Sostenere chi si prende cura del codice open
Insomma il problema è evidente, sistemico e perlopiù irrisolto. Esiste un rilevante disequilibrio tra il lavoro offerto a titolo volontario da parte degli sviluppatori e i profitti generati dai software venduti che funzionano anche grazie ai pacchetti open-source. È ormai chiaro che questo problema di riconoscimento del lavoro non produca soltanto profonda insoddisfazione e risentimento (come nel caso di Koçulu) negli sviluppatori, ma ponga anche le premesse perfette per dei problemi di sicurezza critici spesso difficilmente monitorabili. Da anni, interi ecosistemi di programmazione stanno cercando di elaborare soluzioni efficaci, ma lo scioglimento definitivo di questo nodo è ancora lontano — e non è detto che possa consistere in una soluzione unica, globale e capillare.
Il punto fondamentale della questione è che il codice sorgente delle piattaforme che utilizziamo tutti i giorni deve essere analizzato, monitorato e aggiornato per migliorarlo e, soprattutto, per risolvere i problemi di sicurezza. Quando è una grande azienda a dover svolgere questi compiti, i suoi programmatori possono disporre di strumenti e risorse che permettono loro di reggere il ritmo delle crescenti minacce di sicurezza. Quando, però, gli stessi compiti e responsabilità sono accentrate su singoli sviluppatori che mantengono una data libreria open source nel tempo libero, allora i rischi diventano più evidenti.
È per questo motivo che è necessario sperimentare modelli, approcci e strategie per organizzare la manutenzione dell’infrastruttura open source, uno dei pilastri fondamentali degli spazi digitali contemporanei. Per esempio: la Apache Software Foundation, nata nel 1999, organizza, coordina e raccoglie fondi per quasi 50.000 programmatori che contribuiscono allo sviluppo e alla manutenzione di oltre 350 progetti open-source. In questo caso, una comunità di programmatori che ruotano attorno a una categoria specifica di programmi si raccoglie attorno ad una fondazione che si intesta la responsabilità di prendersi cura della comunità di cui è riferimento. Si tratta di un caso lodevole e virtuoso, che però non è realistico adattare per tutte le situazioni possibili relative alla manutenzione del software open-source.
La Mozilla Foundation, grazie all’approccio open source adottato per lo sviluppo del suo browser Firefox, ha lentamente imposto un nuovo paradigma di collaborazione anche per progetti di alto profilo. Altri giganti, come Red Hat, hanno adottato e promuovono l’approccio open source come – semplicemente – una modalità di lavoro più efficace delle altre.
Ancora, dopo la scoperta di Heartbleed, un bug rinvenuto nel 2014 nelle librerie OpenSSL (utilizzate per assicurare comunicazioni sicure online) che permetteva di trafugare facilmente informazioni sensibili, la Linux Foundation ha inaugurato la Core Infrastructure Initiative, un programma di monitoraggio e finanziamenti pensato per tutelare le librerie di codice open source essenziali per il funzionamento di internet.
Il programma della Linux Foundation si è evoluto negli anni successivi nella Open Source Security Foundation (OpenSSF), nata nel 2020, per organizzare il lavoro necessario a migliorare la sicurezza dei software open source: voluta da grandi corporation come Github, Google, IBM, JPMorgan Chase, Microsoft, Intel, Okta e Uber, è uno dei primi tentativi di unire industrie diverse per prendersi cura del codice open source. Nel corso degli ultimi mesi, dopo il disastro di log4j, Google Cloud ha annunciato la formazione di un team di sviluppatori dedicato proprio alla manutenzione del codice open source.
Ma spesso, la comunità di sviluppo open-source si muove più velocemente della capacità di organizzarla e coordinarla. È per questo motivo che piattaforme come Github hanno creato programmi come Github Sponsors: un sistema attraverso il quale gli utenti di Github possono donare denaro direttamente agli sviluppatori che si prendono cura dei pacchetti che la comunità di Github utilizza. Anche in questo caso l’esempio è virtuoso, ma approcci di questo tipo spesso devono fare i conti con le proporzioni disequilibrate tra utenti che vogliono e possono donare e sviluppatori bisognosi. In altri casi ancora, il lavoro di manutenzione di codice open-source viene supportato da altri programmi (come Copilot, sempre di Github) che forniscono strumenti di supporto alla programmazione agli sviluppatori.
Ci sono anche casi rilevanti in Italia: a maggio 2022, il programmatore italiano Filippo Valsorda, dopo aver lavorato come crittografo per Cloudflare e il team Go di Google, ha annunciato pubblicamente il ritiro dai suoi incarichi full-time per dedicarsi alla progettazione di nuovi modi per remunerare gli sviluppatori open-source e, più in generale, per cercare di professionalizzare la figura del manutentore di codice open-source.
“Il ruolo del manutentore open-source è reale e necessario, è una magnifica aberrazione ma non è una forma sostenibile di lavoro. Deve diventare una professione,” spiega Valsorda a Guerre di Rete. “Diventare una professione significa che ci devono essere dei modi per iniziare a fare quel mestiere e interagire con le grandi aziende in un modo che sia comprensibile dalle organizzazioni e dalle burocrazie con cui hai a che fare. È ora che queste forme di lavoro si rendano leggibili e che questi professionisti diano una struttura al lavoro, letteralmente mandando dei gran PDF: quello di presentazione, del preventivo, della fattura, e così possono arrivare anche a chiedere dei gran soldi.”
Valsorda continua, puntualizzando i possibili rischi di questo approccio, “In molti quando faccio questo discorso mi chiedono che interesse dovrebbe avere una grande azienda a pagare un servizio che, fino ad oggi, ho ottenuto gratuitamente — in pieno stile tragedy of the commons. Io non sono convinto che sia così: le grandi aziende non sono nel business di fare beneficenza, ma sono in quello di limitare i rischi in cui potrebbero incorrere. Se dai ad un’azienda la possibilità di contenere il rischio di dover sostituire una libreria fondamentale per la sua infrastruttura, o di continuare ad aggiornare dei pezzi di codice che richiedono costante attenzione, quell’azienda è interessata. Il software è come qualsiasi altra infrastruttura: decade, si usura, non rimane immobile nel tempo.”
“Non credo che ci sia un’incompatibilità fondamentale tra il mondo corporate della programmazione e quello open-source, anzi,” prosegue Valsorda, indicando quello che ritiene essere il cuore del problema: “manca l’infrastruttura per metterli in contatto dal punto di vista professionale. I manutentori non hanno ancora sviluppato una consapevolezza professionale, come è successo per tante altre professioni — ma deve succedere: anche un ingegnere civile o un avvocato non sono nel business del ‘mandare le fatture’, ma devono imparare a farlo per poter lavorare, per rendere il loro lavoro una professione. Per fare si che ciò succeda servono strumenti, suite di gestione, piattaforme dedicate, che semplicemente non ci sono ancora. La parte interessante di questo discorso è che siamo di fronte alla nascita di una professione, e quindi ci sono da decidere le procedure e le convenzioni che la renderanno tale — io sto lavorando a questo.”
Il bisogno descritto da Filippo Valsorda è evidente, tanto che oltre 2 anni fa l’hacker Marcello Salvati, conosciuto online come byt3bl33d3r, ha lanciato Porchetta Industries, una “piattaforma centralizzata per le organizzazioni che desiderano supportare gli sviluppatori open-source.”
“Facciamo da intermediari tra aziende Fortune 100, aziende di consulenza per sicurezza informatica, e i creatori di tool open-source per la sicurezza informatica,” spiega Salvati a Guerre di Rete.
“Stiamo cercando di cambiare l’insostenibile ecosistema attuale. Le aziende di consulenza utilizzano questi tool open-source senza dare niente in cambio agli sviluppatori. Succede anche a me: se dai un’occhiata a CrackMapExec, un tool che ho sviluppato, potrai vedere come praticamente tutti i contributi arrivino da singoli utenti che non hanno nulla a che fare con le aziende. Oltre che non dare nulla in cambio in termini di codice, non lo fanno nemmeno in termini economici, anche quando sono tool che diventano standard dell’intera industria,” continua Salvati.
Che spiega: “Noi lavoriamo così: gli sviluppatori si associano con noi, noi chiediamo alle grandi aziende un abbonamento — per ora sono 10 dollari al mese a seconda di quanti utenti vogliono accedere alla piattaforma. In cambio, consegniamo privatamente alle aziende degli aggiornamenti per i tool che poi rendiamo pubblici dopo 6 o 7 mesi, per contribuire alla comunità open-source. Il denaro che raccogliamo lo distribuiamo agli sviluppatori. Non si tratta però soltanto di organizzare un gruppo di sviluppatori open-source: molte piattaforme che offrono funzioni di supporto analoghe alla nostra non rilasciano una fattura o ricevuta una volta effettuata la donazione allo sviluppatore, e per questo motivo il donatore non potrà chiedere un rimborso all’azienda per cui lavora. Invece noi permettiamo a tutti i donatori di ottenere una fattura o ricevuta responsabile.”
Porchetta Industries è un esempio di come è possibile iniziare a progettare delle piattaforma di organizzazione e remunerazione per gli sviluppatori open-source e recentemente hanno pubblicato il loro primo transparency report, in cui è possibile consultare i numeri che hanno generato durante la loro attività.
In conclusione, il “castello di carte” che descrive il rapporto di dipendenza tra le grandi piattaforme e i pacchetti di software su cui si sorreggono è simile a quello che lega le grandi aziende tecnologiche agli sviluppatori open-source esterni che mantengono questi stessi pacchetti. Si tratta di un ecosistema complesso, con migliaia di attori diversi con desideri e bisogni diversi. Progettare degli approcci per prendersi cura di chi mantiene il codice open-source, però, non è soltanto un buon proposito ma una vera e propria urgenza per l’intero mondo della sicurezza informatica.
