El autoritarismo del código: por qué los BDFL no existen

¿Qué es el "authoritarianism of code"?

Zed Shaw sostiene en su ensayo Authoritarianism of Code que el autoritarismo está tan internalizado en el desarrollo de software que hasta las personas más anti-autoritaristas terminan replicándolo sin darse cuenta. La definición que propone es directa: cualquier deferencia a la autoridad que se da o se toma sin el consentimiento informado y entusiasta de todos los involucrados.

En otras palabras: si obedeces a alguien —o exiges que te obedezcan— sin que la otra parte sepa exactamente a qué está diciendo que sí, eso es autoritarismo. No importa si la causa es noble ni si las intenciones son buenas.

¿Por qué el open source es especialmente vulnerable?

Shaw señala que la cultura del software gira alrededor de figuras como el BDFL (Benevolent Dictator for Life): el fundador o mantenedor original que decide el rumbo del proyecto. El término suena a broma, pero Shaw argumenta que no existe tal cosa: la "dictadura benevolente" sigue siendo una dictadura.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La vulnerabilidad está en cómo se construyen las comunidades: líderes con poder de veto sobre contribuciones, reglas opacas sobre qué constituye una buena propuesta, y castigos desproporcionados para disidentes. Todo esto se acepta con una deferencia que pocas veces se cuestiona.

Los cuatro componentes del autoritarismo según Shaw

1. Deferencia a la autoridad. Se manifiesta como creer lo que dice alguien con poder incluso frente a evidencia en contra, permitir que los líderes rompan las reglas que aplican a todos, perdonarles sus errores y atacar a quienes los cuestionan.

2. Dada o tomada. El autoritarismo se esconde en el liderazgo pero se observa en la comunidad. Una comunidad puede ser autoritaria aunque sus líderes no actúen como tales, y viceversa. Shaw lo llama duck-typing autoritario: si la comunidad actúa como un grupo autoritario, la organización lo es.

3. Consentimiento informado y entusiasta. Las personas deben saber todo —incluidas las reglas secretas, los acuerdos ocultos y los castigos posibles— antes de dar su consentimiento. Si no pueden votar sobre las reglas o sobre quién las aplica, nunca hubo consentimiento real.

4. "Todos los involucrados". La definición de "todos" cambia según conveniencia: cuando se buscan nuevos miembros "todos" es el mundo; cuando se reparten responsabilidades "todos" son los líderes y la comunidad; cuando hay que proteger el poder "todos" se reduce al círculo íntimo. Shaw propone que "todos" incluya siempre a quienes se intenta atraer al proyecto.

El caso que Shaw usa como evidencia: la comunidad Python

El autor documenta con detalle dos incidentes en la conferencia PyCon para mostrar la deferencia autoritaria en acción.

PyCon 2012 — "One Eyed Snake". Shaw describe que Steve Holden, entonces figura de la Python Software Foundation (PSF), recorrió la conferencia pidiendo a varias mujeres que tocaran un objeto al que había quitado un ojo —bajo un slang inglés evidente para "pene"—. Pese a que existía un Código de Conduct que él mismo había votado y defendido, no fue expulsado, no perdió su cargo ni sus contratos para dirigir PyCon y DjangoCon, y fue puesto a cargo de formación en diversidad.

PyCon 2013 — Dongle Incident. Casi al revés: dos asistentes bromearon en privado sobre "dongles" grandes y "fork her repo" durante una charla. Adria Richards, que estaba sentada delante, reportó el incidente y tuiteó una foto. La organización de PyCon los expulsó de inmediato; uno perdió su trabajo en cuestión de horas. Richards, en cambio, fue despedida por SendGrid después de una campaña de acoso en su contra, según reportó NBC News y The Atlantic en marzo de 2013.

Shaw contrasta ambos casos en una tabla: el líder con poder y violación reiterada recibió ascenso; los asistentes sin poder con un chiste aislado perdieron el empleo. Para él, eso es deferencia a la autoridad: la comunidad permite que los líderes violen las reglas que aplica con mano dura a todos los demás.

¿Por qué importa esto a tu startup?

Aunque el ensayo está centrado en open source, la estructura que describe Shaw se repite en muchos equipos y comunidades de fundadores. Las preguntas que vale la pena hacerse:

¿Quién decide las reglas de tu organización y cómo se aprueban? Si tu cultura o tu código de conducta lo escribe un grupo cerrado y luego se aplica de forma selectiva, estás replicando el patrón.
¿Tus "líderes benevolentes" tienen reglas distintas? Muchos fundadores escriben manifiestos y luego se otorgan excepciones. La comunidad lo nota, aunque no lo diga.
¿Castigas más fuerte a los outsiders que a tu círculo cercano? Eso es deferencia a la autoridad en la práctica.

Acciones concretas que puedes tomar esta semana

Audita quién votó tus reglas internas. Si no las aprobó la gente que las vive, no son reglas — son edictos. Documenta el proceso y hazlo público.
Separa la regla del castigo. Castigos proporcionales, iguales para fundadores y empleados, son la mejor defensa contra el autoritarismo. Si tu CEO puede saltarse la política de RR.HH., el resto lo va a notar.
Pregunta antes de exigir. Cualquiera que se una a tu equipo —incluidos usuarios, contribuidores de open source o clientes— merece saber exactamente a qué está diciendo que sí. Si hay reglas no escritas, escríbelas.

Conclusión

El ensayo de Shaw es un recordatorio incómodo: la cultura importa tanto como el código. Las comunidades técnicas, y por extensión las startups, sobreviven o mueren según cómo tratan a las personas en los márgenes, no a las que ya están en el centro. Lo que el open source lleva décadas enseñando —con errores visibles— es que la única defensa real contra el autoritarismo interno es el consentimiento informado, las reglas iguales para todos y la voluntad de abandonar proyectos que no los respeten.