Récemment nous avons parlé des actions qui ont été entreprises par GitHub sur le compte Marak Squires, l'auteur principal de Faker.js qui a corrompu et supprimé la bibliothèque début janvier, incitant GitHub à prendre des mesures qui ont divisé la communauté.
Mais maintenant, le projet est de retour sur le Web en tant que projet communautaire, car un référentiel GitHub pour le nouveau package faker.js a été créé et une équipe de huit superviseurs a été constituée pour gérer le projet open source à l'avenir.
En outre, un compte Twitter public a également été créé pour communiquer avec la communauté de bibliothèques JavaScript. En attendant, le profil de Squires qui avait apparemment été suspendu par GitHub est à nouveau accessible.
On entend souvent ça il est difficile de lever des fonds pour le développement de projets open source au point qu'on dit que "l'open source est une destination qui ne génère pas d'argent".
Le développeur de la bibliothèque open source faker.js a récemment fait tout son possible pour détruire faker.js qu'il avait développé en raison de la difficulté de monétisation. Dans l'un des messages GitHub du développeur de novembre 2020, Il a déclaré qu'il ne voulait plus faire de travail gratuit. "Avec tout le respect que je vous dois, je ne soutiendrai plus le Fortune 500 (et d'autres petites entreprises) avec mon travail gratuit", a-t-il déclaré.
"Profitez de cette occasion pour m'envoyer un contrat annuel à six chiffres ou pour forger le projet et demander à quelqu'un d'autre de travailler dessus." Il n'a probablement pas obtenu de réponse favorable à sa demande, ce qui l'a conduit début janvier à corrompre deux des bibliothèques qu'il avait lui-même conçues, facker.js et "colors.js", ce qui a nui à des millions de projets qui en dépendent. cette. Squires a soumis un commit à colors.js qui ajoute un nouveau module de drapeau américain, ainsi que la mise en œuvre de la version 6.6.6 de faker.js, qui déclenche la même tournure destructrice des événements.
Les versions sabotées font que les applications produisent sans cesse des lettres et des symboles étrangers, en commençant par trois lignes de texte indiquant "LIBERTY LIBERTY LIBERTY". Les utilisateurs comprenaient évidemment que les bibliothèques venaient d'être compromises, mais ils étaient loin d'imaginer que la personne à l'origine de la compromission était Squires lui-même.
Pour avoir une idée de l'étendue des dégâts, la bibliothèque colors.js a avait plus de 20 millions de téléchargements hebdomadaires sur npm seul et on dit qu'il y a près de 19,000 XNUMX projets qui en dépendent.
Pour sa part, faker.js comptait plus de 2,8 millions téléchargements hebdomadaires sur npm et plus de 2.500 XNUMX utilisateurs. En réponse au geste de Squires, faker.js est devenu un projet communautaire.
Facker.js, qui n'existait que sur GitHub jusqu'à ce que Squires le supprime plus tôt ce mois-ci, a maintenant un site Web qui indique que le développement de la bibliothèque sera désormais géré par une nouvelle équipe de huit personnes. Sur le site Web, il y a aussi une référence à la suppression par Squires. Selon la nouvelle équipe, "Squires a joué un tour à la communauté".
"Le projet Faker a été géré par Marak Squires, un passionné et professionnel de Node qui s'est mis en colère et a agi de manière malveillante le 4 janvier 2022. Le package a été supprimé et le projet a été abandonné. Nous avons maintenant transformé Faker en un projet contrôlé par la communauté, actuellement géré par huit ingénieurs d'horizons et d'entreprises variés », explique le nouveau site Web faker.js. Squires n'a pas commenté ces déclarations sur Twitter. A annoncé avoir corrigé le bogue Zaglo dans la bibliothèque JavaScript colors.js, mais n'a pas réussi à le charger dans le gestionnaire de packages npm.
Depuis la suppression de faker.js début janvier 2022, la communauté et d'autres programmeurs intéressés ont activement discuté de la question. Certains utilisateurs, d'une part, montrent de la compréhension pour l'action de Squires visant à supprimer faker.js, mais continuent d'exprimer leur mécontentement face à cette action.
En effet, malgré les ravages provoqués, le symbole de l'humble développeur open source qui s'oppose aux grandes et riches entreprises qui en profitent a énormément résonné dans les discussions des forums spécialisés. De plus, le rôle de GitHub dans cette affaire est également remis en question.
Certains contestent le fait que GitHub ait verrouillé le compte de Squires.
"Il y a une chose qui me fait pleurer et rire. Où était la garantie de qualité ? Mettez-vous automatiquement à jour les packages et exécutez-vous des tests de régression avant de publier une nouvelle version de votre logiciel ? C'est gênant", a-t-il ajouté. Plusieurs personnes ont estimé que la suspension du compte de Squires était déraisonnable car il s'agissait de son propre code.
GitHub a ensuite décidé de restaurer le compte de Squires, qui semble désormais accessible. Quoi qu'il en soit, le comportement de Squires a de nouveau soulevé le problème de la "dépendance excessive" des projets vis-à-vis des bibliothèques tierces.
source: https://fakerjs.dev/
Ce que je ne comprends toujours pas, c'est pourquoi ils n'ont pas créé de "github" basé sur la blockchain dont les membres aident à financer des projets chaque fois que la qualité d'une version d'un projet est vérifiée. Là où le prestige des collaborateurs (membres actifs) qui vérifient un projet dépend du niveau de bugs détectables dans un projet, leur faisant gagner plus ou moins de la crypto, par exemple le projet saboté où le code a été vérifié ne fait pas ce qu'il devrait selon la fonction du projet serait très grave, un membre qui télécharge le projet et marque ensuite qu'il l'a vérifié sans l'avoir fait, baissera son prestige et par conséquent ses revenus futurs en tant que vérificateur diminueront d'autant que ses pairs rapportent. C'est ce qui me vient humblement à l'esprit.
Les logiciels open source/libres ont été créés pour satisfaire, en premier lieu, le besoin d'un développeur, et en raison de la portée du code, il finit par profiter à tout le monde.
Le même développeur est celui qui veille à ce que son propre logiciel fonctionne au plus basique pour ce pour quoi il a été créé, et au fur et à mesure du temps il ajoute/améliore les parties qui sont nécessaires pour que le logiciel devienne sûr et ainsi de suite. une mauvaise utilisation de celui-ci ou une situation inattendue dans le système d'exploitation de provoquer un dysfonctionnement.
Tout cela est la raison pour laquelle il n'y avait aucune entité qui a vérifié le code, ce code a fonctionné, et ceux qui l'ont utilisé en ont profité instantanément, ils ont fait confiance au développeur car ils savent que par nature c'est le développeur qui veut le plus que son logiciel fonctionne bien.
Le développeur est arrivé à un point où il a estimé qu'il n'était pas juste pour eux de faire un profit et de ne pas le partager avec lui, et il leur a fait savoir.
Les entreprises qui décideraient de financer une entité pour vérifier le code seraient exposées, premièrement parce qu'elles montreraient qu'elles ont réalisé un profit sur ce logiciel, et deuxièmement parce qu'elles montreraient qu'elles n'ont jamais été disposées à payer les principaux développeurs, puisque certaines parties de ces bénéfices iraient à d'autres entités, en fin de compte ce qu'ils disent est : ce qui est à vous est à moi, ce qui est à moi est à moi et ce qui appartient à tout le monde est à moi.