Hace poco hablamos sobre las acciones que fueron tomadas por parte de GitHub en la cuenta de Marak Squires, el autor principal de Faker.js quien corrompió y eliminó la biblioteca a principios de enero, a lo que GitHub tomo algunas medidas que dividieron a la comunidad.
Pero ahora está nuevamente el proyecto en la web como un proyecto comunitario, ya que se creó un repositorio de GitHub para el nuevo paquete faker.js y se reunió un equipo de ocho supervisores para administrar el proyecto de código abierto en el futuro.
Además, también se ha creado una cuenta pública de Twitter para comunicarse con la comunidad de bibliotecas de JavaScript. Mientras tanto, se puede volver a acceder al perfil de Squires que aparentemente había sido suspendido por GitHub.
A menudo escuchamos que es difícil recaudar fondos para el desarrollo de proyectos de código abierto hasta el punto de que se dice que «el código abierto es un destino que no genera dinero».
El desarrollador de la biblioteca de código abierto faker.js recientemente hizo todo lo posible para destruir faker.js que había desarrollado debido a la dificultad de la monetización. En una de las publicaciones de GitHub del desarrollador de noviembre de 2020, afirmó que ya no quiere hacer un trabajo gratuito. “Con el debido respeto, ya no apoyaré a Fortune 500 (y otras empresas más pequeñas) con mi trabajo gratuito”, dijo.
«Toma esto como una oportunidad para enviarme un contrato anual de seis cifras o bifurcar el proyecto y hacer que alguien más trabaje en él». 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 eso. Squires presentó un compromiso con colors.js que agrega un nuevo módulo de bandera estadounidense, además de implementar la versión 6.6.6 de faker.js, lo que desencadena el mismo giro destructivo de los eventos.
Las versiones saboteadas hacen que las aplicaciones produzcan incesantemente letras y símbolos extraños, comenzando con tres líneas de texto que dicen «LIBERTY LIBERTY LIBERTY». Los usuarios obviamente entendieron que las bibliotecas acababan de ser comprometidas, pero estaban lejos de imaginar que la persona detrás del compromiso era el propio Squires.
Para tener una idea del alcance del daño, la biblioteca colors.js ha tenido más de 20 millones de descargas semanales solo en npm y se dice que hay casi 19,000 proyectos que dependen de ella.
Por su parte, faker.js contaba con más de 2,8 millones de descargas semanales en npm y más de 2.500 usuarios. En respuesta al gesto de Squires, faker.js se ha convertido en un proyecto comunitario.
Facker.js, que solo existía en GitHub hasta que Squires lo eliminó a principios de este mes, ahora tiene un sitio web que dice que el desarrollo de la biblioteca ahora estará a cargo de un nuevo equipo de ocho personas. En el sitio web también hay una referencia a la eliminación por parte de Squires. Según el nuevo equipo, «Squires le ha jugado una mala pasada a la comunidad».
“Project Faker fue administrado por Marak Squires, un entusiasta y profesional de Node que se enojó y actuó de manera maliciosa el 4 de enero de 2022. Se eliminó el paquete y se abandonó el proyecto. Ahora hemos transformado Faker en un proyecto controlado por la comunidad, actualmente administrado por ocho ingenieros de una variedad de orígenes y empresas”, dice el nuevo sitio web faker.js. Squires no comentó sobre esas declaraciones en Twitter. Anunció que solucionó el error de Zaglo en la biblioteca de JavaScript colors.js, pero no pudo cargarlo en el administrador de paquetes npm.
Desde la eliminación de faker.js a principios de enero de 2022, la comunidad y otros programadores interesados han estado discutiendo activamente el tema. Algunos usuarios, por un lado, muestran comprensión por la acción de Squires de eliminar faker.js, pero continúan expresando su descontento con esta acción.
De hecho, a pesar de los estragos causados, el símbolo del humilde desarrollador de código abierto que se opone a las grandes y ricas empresas que se benefician de él resonó enormemente en las discusiones en foros especializados. Además, el papel de GitHub en este asunto también está en duda.
Algunos no están de acuerdo con el hecho de que GitHub bloqueó la cuenta de Squires.
“Hay una cosa que me hace llorar y reír. ¿Dónde estaba la garantía de calidad? ¿Actualiza automáticamente los paquetes y no ejecuta pruebas de regresión antes de lanzar una nueva versión de su software? Es vergonzoso”, agregó. Varias personas sintieron que la suspensión de la cuenta de Squires no era razonable ya que era su propio código.
Más tarde, GitHub decidió restaurar la cuenta de Squires, que ahora parece estar accesible. De todos modos, el comportamiento de Squires volvió a plantear el tema de los proyectos de «excesiva dependencia» de las bibliotecas de terceros.
Fuente: https://fakerjs.dev/
Lo que aún no entiendo es cómo no han creado un «github» basado en la cadena de bloques cuyos miembros colaboren en la financiación de los proyectos cada vez que se verifique la calidad de la versión de un proyecto. Donde el prestigio de los colaboradores (miembros activos) que verifican un proyecto depende del nivel de errores detectables en un proyecto, haciendo que ganen más o menos de la crypto, por ejemplo, el proyecto saboteado en el que se ha comprobado que el código no hace lo que debería de acuerdo a la función del proyecto sería muy grave, un miembro que descargue el proyecto y seguidamente marque que lo ha verificado sin realmente haberlo hecho, bajará su prestigio y consecuentemente sus futuras ganancias como verificador bajen en la medida que sus pares vayan reportando. Es lo que humildemente se me ocurre.
Los programas de código abierto/software libre fueron creados para satisfacer, en primer lugar, una necesidad del desarrollador, y por el alcance que tiene el código termina beneficiando a todos.
El mismo desarrollador es el que se encarga de que su propio software funcione en lo más básico para lo que fue creado, y a medida que pasa el tiempo le va agregando/mejorando las partes que son necesarias para que el software se convierta en seguro y así evitar que un mal uso del mismo o una situación inesperada en el sistema operativo genere un mal funcionamiento.
Todo eso es la razón por la cuál no existó una entidad que verifique el código, ese código funcionaba, y los que lo usaron obtuvieron ganancias al instante, confiaron en el desarrollador porque saben que por naturaleza es el desarrollador el que más quiere que su software funcione bien.
El desarrollador llegó a un punto en el que consideró que no era justo que ellos obtengan ganancias y no la compartan con él, y se los hizo saber.
Las empresas que decidieran financiar a una entidad para que verifiquen códigos quedarían en evidencia, en primer lugar porque estarían demostrando que obtuvieron ganancias por ese software, y en segundo lugar porque estarían demostrando que nunca estuvieron dispuestos a pagarles a los desarrolladores principales, ya que partes de esas ganancias irían a parar a otras entidades, en definitiva lo que dicen es: lo tuyo es mio, lo mio es mio, y lo de todos es mio.