El debate semántico puede explicar la salida de Bitcoin Core de Wladimir van der Laan
El 7 de septiembre, el desarrollador de Bitcoin Core, Wladimir van der Laan, tuiteó que podría haber “renunciado a las monedas” todas juntas. Más tarde, confirmó a Cointelegraph que, de hecho, se estaba tomando un descanso de sus deberes como desarrollador de Bitcoin Core y como uno de los custodios del repositorio Github del proyecto. Uno de los factores que lo llevó a esta decisión fue una tormenta de Twitter que se prolongó durante días y fue provocada por el cambio de nombre de una variable que especifica una lista de caracteres que no pueden aparecer en nombres de archivos por restricciones del sistema operativo.
Fuente: repositorio Github de Bitcoin.
¿Cómo podría algo tan aparentemente inocuo llevar a una tormenta de Twitter, que a su vez, llevó a la salida temporal de un desarrollador que ha estado trabajando en Bitcoin desde 2014?
La variable en cuestión es un parámetro que originalmente se llamaba “FILE_CHAR_BLACKLIST”. El 9 de junio, el usuario de Github, TrentZ, propuso que se lo cambiara por un nombre que, en su opinión, fuera más apropiado: FILE_CHAR_BLOCKLIST. La motivación señalada fue que algunos desarrolladores podrían sentirse ofendidos por el uso de “negro” en el nombre de archivo original como una forma de denotar un resultado negativo, mientras que el uso alternativo de “blanco” haría referencia a una conclusión positiva. No hubo consenso en ese momento sobre este cambio, pero después de un tiempo, la discusión se apagó.
La conversación sobre el uso de “blanco” y “negro” en referencia a las variables “bueno” y “malo”, respectivamente, no es exclusiva de la comunidad blockchain. En abril de 2020, el Centro Nacional de Seguridad Cibernética del Reino Unido anunció que comenzaría a usar “Permitir” y “Denegar” en lugar de lo que algunos ven como un lenguaje divisivo arraigado en el colorismo. Del mismo modo, el gigante de IT Cisco Systems también anunció que su división de seguridad usaría el nuevo esquema de nombres en su código.
Hace dos días, otro colaborador de Bitcoin llamado Verretor propuso otro cambio en el nombre de esta variable, esta vez cambiando “FILE_CHAR_BLOCKLIST” a “FILE_CHARS_DISALLOWED”. Parece que su propuesta no estaba motivada por connotaciones positivas o negativas, en cambio, creía que el nombre actual era ambiguo:
“Blocklist es ambiguo. Podría significar una lista de bloques. Ejemplo: ‘blocknotify’ en el mismo archivo se refiere a bloques de Bitcoin”.
Fue entonces cuando se desató el infierno cuando el debate que comenzó en Github migró a Twitter. Un lado del debate enfatizó la necesidad de que la comunidad de Bitcoin sea más inclusiva comenzando con el código, mientras que el otro lado creía que este era un caso de politización de temas que no son de naturaleza política. Otro desarrollador de Bitcoin Core, Luke Dashjr, explicó por qué todas las propuestas anteriores eran ambiguas y presentó la suya propia:
“No se trata de bloquear nada, por lo que la lista de bloqueo es técnicamente incorrecta. La ‘lista negra’ también tiene problemas reales de ambigüedad. Lo que hace esta lista es enumerar los caracteres para excluir de los nombres de archivo, porque se sabe que el sistema operativo (o nuestras bibliotecas) no los admiten en los nombres de archivo. ‘Creo que FILE_CHAR_EXCLUDE está bien'”.
El CEO de Blockstream, Adam Back, le dijo a Cointelegraph que encuentra la situación irónica, considerando que la batalla surgió por una variable que aparece en el código de prueba:
“Hay una triple ironía de que se le haya puesto mal el nombre, ni siquiera es una lista negra, es una lista de letras que no pueden aparecer en los nombres de archivo del sistema operativo. Y está en algún código de prueba, por lo que ni siquiera está en el binario de Bitcoin“.
Ahora parece que se ha alcanzado un compromiso razonable. La propuesta de Dashjr nunca se formalizó, dejándonos con FILE_CHARS_DISALLOWED, al cierre de esta edición.
Sigue leyendo:
