Com’è finita la faccenda di faker.js? Come doveva finire: con un fork!

7

Dubito fortemente che quanti seguono il blog abbiano bisogno di un riassunto delle puntate precedenti, ma per essere più completi possibile, eccolo qua: Marak Squires ha introdotto volutamente un loop infinito nelle librerie che sviluppava, faker.js e colors.js, utilizzate da decine di migliaia di progetti. La ragione a suo dire era di protesta contro le grandi corporation (ed il fatto che lui di fatto non venisse pagato quanto ritenesse opportuno), ed il risultato che ha ottenuto è stato quello di vedersi bloccare l’account GitHub con relativa eliminazione del codice malevolo (auto)introdotto.

Il caso specifico che racconta questa vicenda è piuttosto comune nel mondo open-source: un solo maintainer (Squires) per un singolo progetto (faker.js) che però regge un ecosistema immenso di applicazioni. Da qui il potere esagerato che ne deriva, tanto che con una singola patch è stato creato un disservizio distribuito.

Ci siamo interrogati molto nei commenti sulle ragioni del gesto e sui provvedimenti presi da GitHub, sulla tutela dell’utilizzatore e sul senso stesso dell’open-source. Sviluppare software open-source significa offrire gratuitamente il prodotto del proprio lavoro a chiunque lo voglia utilizzare, auspicando per dei contributi, imponendo il mantenimento della condizione del software, ma sostanzialmente lasciando liberi tutti di adoperare quanto fatto, senza se e senza ma.

Ecco perché nel leggere la presentazione de nuovo corso di Faker, ci sembra di capire che le cose siano finalmente andate a posto:

We’re now turning Faker into a community-controlled project currently maintained by eight engineers from various backgrounds and companies.

Stiamo portando Faker ad essere un progetto controllato dalla community, mantenuto da otto ingegneri provenienti da storie ed aziende diverse.

Chi sono queste otto persone? Loro:

Ed insieme hanno fatto quello che era necessario per tutelare gli utenti della libreria ed insieme la community che ruota intorno al progetto: un fork. Uno cioè dei principi alla base dell’open-source.

Non possiamo quindi che concordare con quanto scritto dagli autori in chiusura della presentazione:

We believe that we have acted in the way that is best for the community.

Crediamo di aver agito nella maniera migliore per la community

Amen.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

7 risposte a “Com’è finita la faccenda di faker.js? Come doveva finire: con un fork!”

  1. Avatar xan
    xan

    la parte che non mi è chiara di questa storia è questa: con una singola patch è stato creato un disservizio distribuito.

    non dovrebbe aver rilasciato una nuova release ed i vari progetti aver aggiornato la release da importare?

  2. Avatar Marco Bonfiglio
    Marco Bonfiglio

    Sì, ma sono meccanismi ormai automatici e piuttosto rapidi.

    Con i sistemi di CI (Continuous Integration) tanto in voga oggigiorno, ad ogni update del codice (su GitHub) corrisponde una build automatica del software (su NPM). Inoltre, in progetti con linguaggio interpretato/script, specie JavaScript come questo, non c’è praticamente differenza tra l’update di codice e il rilascio di software, essendo esso stesso quel codice.

    A loro volta le aziende, col loro CI, controllano ad ogni build (scatenata da un aggiornamento del loro codice) se c’è un aggiornamento delle dipendenze: nel caso ci sia una versione superiore disponibile (grazie al meccanismo descritto sopra), si scarica la nuova versione e la si mette in cache (per non scaricarla ex-novo ogni volta).

    Il tempo di propagazione è molto ridotto, quindi, e la patch malevola, sebbene non finita nei prodotti finali, è arrivata almeno agli sviluppatori. Che han visto bloccato il loro lavoro: ecco il disservizio. E siccome le aziende sono parecchie, pure diffuso.

  3. Avatar xan
    xan

    quindi non cè distinzione tra nigtly build e release stabili ? lo chiedo perchè nel mondo java/android si

  4. Avatar Marco Bonfiglio
    Marco Bonfiglio

    C’è, ma in questo caso la versione “segnalata” dallo sviluppatore era di release stabile, e la catena di build automatiche si è messa in moto.
    Per ripristinare la situazione, infatti, non è bastato sospendere il sorgente del codice, ma anche NPM è dovuto intervenire per “riavvolgere” le versioni. Dal nostro primo articolo:

    Aggiungiamo anche il fatto che NPM.js ha riportato la libreria all’ultima versione funzionante dei due package, in completa autonomia e senza interrogarlo.

    Poi, come sempre, dipende dallo sviluppatore scegliere a cosa fare riferimento, ma una delle comodità delle CI (in genere) è proprio quella di poter indicare il nome della dipendenza senza dover specificare la versione: sceglierà l’ultima stabile disponibile. Bacata, o no…

  5. Avatar xan
    xan

    a ok , mi mancava la parte : “la versione “segnalata” dallo sviluppatore era di release stabile”

    quindi non ha solo fatto un commit, ma ha rilasciato una release stabile con il commit farlocco, è un po diverso no?

  6. Avatar Marco Bonfiglio
    Marco Bonfiglio

    Ho usato la parola “segnalata” tra virgolette proprio perché non mi risulta ci sia differenza.
    Il file package.json ha una voce chiamata ‘version’, e con quel commit è stata portata da 6.6.6 a 6.6.7, sul branch master. Ognuno ha le sue convenzioni, ma questo può essere considerato un rilascio a tutti gli effetti, se per esempio portasse avanti gli sviluppi su un altro branch e facesse solo il commit di rilascio su master.
    Non possiamo verificare perché la pagina del progetto è stata ripristinata senza la history dei commit, e non sono uno sviluppatore Javascript che lavora con questa libreria (non sono proprio sviluppatore a dire il vero), quindi non so dirti se in passato era questo il suo modus operandi.

    Però, giusto come controprova che sia questo il meccanismo – automatico e rapido -, il nuovo progetto di cui raccontiamo in questo articolo ha il suo package.json con versione “6.0.0-alpha.5” – sicuramente non una release stabile. Eppure, su NPM, è già presente la build relativa a questo commit, di 22 ore fa. La consideri release? La consideri stabile? Non lo so, ma se un tuo progetto includesse la libreria “@faker-js/faker” sarebbe proprio questa ad essere scaricata, perché l’ultima disponibile.

  7. Avatar xan
    xan

    non so come funziona npm ma su maven arrivano sia le versioni stable che non, e di default viene scaricata l’ultima stable, se vuoi l’ultima anche tenendo conto delle non stable devi specificarlo manualmente.

    per questo chiedevo.

    da sviluppatore android/java in ogni caso trovo assurdo che per ogni commit venga generata una release che finisca nei repository. nel mondo java CI genera build interne che vengono usate solo per eseguire le batterie di test, sta poi ad una mano umana promuovere la release per mandarla nei repository maven

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *