Faker.js se tornou um projeto controlado pela comunidade

Faz pouco conversamos sobre as ações que foram tomadas por GitHub na conta Marak Squires, o principal autor do Faker.js que corrompeu e removeu a biblioteca no início de janeiro, levando o GitHub a tomar algumas medidas que dividiram a comunidade.

Mas agora o projeto está de volta na web como um projeto comunitário, como um repositório GitHub para o novo pacote faker.js foi criado e uma equipe de oito supervisores foi montada para gerenciar o projeto de código aberto daqui para frente.

Além disso, uma conta pública no Twitter também foi criada para se comunicar com a comunidade de bibliotecas JavaScript. Enquanto isso, o perfil de Squires que aparentemente havia sido suspenso pelo GitHub pode ser acessado novamente.

Artigo relacionado:
GitHub decidiu restaurar a conta de desenvolvedor Faker.js

Muitas vezes ouvimos isso é difícil arrecadar fundos para o desenvolvimento de projetos de código aberto a ponto de se dizer que “open source é um destino que não gera dinheiro”.

O desenvolvedor da biblioteca open source faker.js recentemente fez todo o possível para destruir faker.js que ele havia desenvolvido devido à dificuldade de monetização. Em uma das postagens do desenvolvedor no GitHub de novembro de 2020, Ele afirmou que não quer mais trabalhar de graça. “Com todo o respeito, não apoiarei mais a Fortune 500 (e outras empresas menores) com meu trabalho gratuito”, disse ele.

"Aproveite isso como uma oportunidade para me enviar um contrato anual de seis dígitos ou dividir o projeto e ter outra pessoa trabalhando nele." Probablemente no tuvo una respuesta favorable a su solicitud, lo que lo llevó a principios de enero a corromper dos de las bibliotecas que él mismo diseñó, facker.js y «colors.js», causando que esto perjudique a millones de proyectos que dependen en isso. Squires enviou um commit para colors.js que adiciona um novo módulo de bandeira americana, além de implementar a versão 6.6.6 do faker.js, que aciona a mesma reviravolta destrutiva dos eventos.

Versões sabotadas fazem com que aplicativos produzam letras e símbolos incessantemente estranhos, começando com três linhas de texto que diziam "LIBERTY LIBERTY LIBERTY". Os usuários obviamente entenderam que as bibliotecas tinham acabado de ser comprometidas, mas estavam longe de imaginar que a pessoa por trás do comprometimento era o próprio Squires.

Para se ter uma ideia da extensão do dano, a biblioteca colors.js tem teve mais de 20 milhões de downloads semanais apenas no npm e diz-se que há quase 19,000 projetos que dependem dele.

Por sua parte, o faker.js teve mais de 2,8 milhões downloads semanais no npm e mais de 2.500 usuários. Em resposta ao gesto de Squires, o faker.js se tornou um projeto comunitário.

O Facker.js, que existia apenas no GitHub até que a Squires o removeu no início deste mês, agora tem um site que diz que o desenvolvimento da biblioteca será tratado por uma nova equipe de oito pessoas. No site também há uma referência à remoção pela Squires. De acordo com a nova equipe, "Squires pregou uma peça na comunidade".

“O Projeto Faker foi gerenciado por Marak Squires, um entusiasta e profissional do Node que se irritou e agiu maliciosamente em 4 de janeiro de 2022. O pacote foi removido e o projeto foi abandonado. Agora transformamos o Faker em um projeto controlado pela comunidade, atualmente gerenciado por oito engenheiros de diversas origens e empresas”, diz o novo site faker.js. Squires não comentou essas declarações no Twitter. Anunciou que corrigiu o bug do Zaglo na biblioteca JavaScript colors.js, mas falhou ao carregá-lo no gerenciador de pacotes npm.

Desde a remoção do faker.js no início de janeiro de 2022, a comunidade e outros programadores interessados ​​têm discutido ativamente o assunto. Alguns usuários, por um lado, mostram compreensão pela ação da Squires de remover o faker.js, mas continuam expressando seu descontentamento com essa ação.

De fato, apesar do estrago feito, o símbolo do humilde desenvolvedor de código aberto que se opõe às grandes e ricas empresas que lucram com isso repercutiu enormemente nas discussões em fóruns especializados. Além disso, o papel do GitHub nesse assunto também está em questão.

Alguns discordam do fato de o GitHub ter bloqueado a conta de Squires.

“Há uma coisa que me faz chorar e rir. Onde estava a garantia de qualidade? Você atualiza pacotes automaticamente e executa testes de regressão antes de lançar uma nova versão do seu software? É constrangedor", acrescentou. Várias pessoas acharam que a suspensão da conta de Squires não era razoável, pois era seu próprio código.

Mais tarde, o GitHub decidiu restaurar a conta de Squires, que agora parece estar acessível. Independentemente disso, o comportamento de Squires levantou a questão dos projetos "excesso de confiança" em bibliotecas de terceiros novamente.

fonte: https://fakerjs.dev/


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: AB Internet Networks 2008 SL
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   Miguel Rodrigues dito

    O que ainda não entendo é por que eles não criaram um "github" baseado em blockchain cujos membros ajudam a financiar projetos toda vez que a versão de um projeto é verificada em qualidade. Onde o prestígio dos colaboradores (membros ativos) que checam um projeto depende do nível de bugs detectáveis ​​em um projeto, fazendo com que ganhem mais ou menos com a criptomoeda, por exemplo o projeto sabotado onde o código foi checado não faz o que deveria de acordo com a função do projeto seria muito grave, um membro que fizer o download do projeto e depois marcar que o verificou sem de fato o ter feito, diminuirá seu prestígio e, consequentemente, seus ganhos futuros como verificador diminuirão na medida em que que seus pares vão relatar. É o que humildemente me ocorre.

    1.    Walter dito

      Programas de software livre/open source foram criados para satisfazer, em primeiro lugar, uma necessidade do desenvolvedor e, devido ao escopo do código, acaba beneficiando a todos.

      O mesmo desenvolvedor é aquele que cuida para que seu próprio software funcione no mais básico para o que foi criado, e com o passar do tempo vai acrescentando/melhorando as partes que são necessárias para que o software se torne seguro e assim por diante. uso indevido dele ou uma situação inesperada no sistema operacional cause um mau funcionamento.

      Tudo isso é a razão pela qual não havia nenhuma entidade que verificasse o código, esse código funcionava, e quem o usava lucrava instantaneamente, confiava no desenvolvedor porque sabe que por natureza é o desenvolvedor que mais quer que seu software funcione bem.

      O desenvolvedor chegou a um ponto em que sentiu que não era justo para eles obter lucro e não compartilhá-lo com ele, e ele os informou.

      As empresas que decidissem financiar uma entidade para verificar o código estariam expostas, primeiro porque estariam mostrando que tiveram lucro com aquele software, e segundo porque estariam mostrando que nunca estavam dispostas a pagar os principais desenvolvedores, já que partes do esses lucros iriam para outras entidades, afinal o que eles dizem é: o que é seu é meu, o que é meu é meu, e o que é de todos é meu.