Democracia

Ansel debería gestionarse de forma democrática y justa para todas las personas involucradas.

Definir una organización cooperativa más allá del código de código abierto

Se asume que las personas desarrolladoras y usuarias que llegan aquí comparten un interés común : quieren libertad en la forma de editar sus fotos, ahora y en el futuro. Es decir :

• tener un control técnico suficiente sobre el contenido y las propiedades de sus imágenes,
• estar libres de capitalistas que puedan :
  • aumentar el precio de su aplicación en beneficio exclusivo de los accionistas,
  • explotar las fotos de los clientes para entrenar modelos de IA sin consentimiento,
  • liquidar aplicaciones sin liberar el código fuente,
• tener derecho a decidir sobre los contornos y la implementación de dicha libertad.

El ADN de Ansel es más técnico y detallado que el de la mayoría de los editores de fotos RAW, sin dejar de dar importancia a la facilidad de uso siempre que es posible, sobre todo en las tareas típicas centradas en el escritorio (interacciones con dispositivos de entrada y archivos, paradigmas de interfaz gráfica, etc.). Ansel no es Darktable  ni ART  porque su visión de lo que debería ser un buen software de retoque de imágenes es bastante diferente.

Ansel se distribuye bajo la licencia GNU/GPL , lo que lo convierte en software libre/de código abierto. Aunque esto da una sensación (equivocada) de disponibilidad a largo plazo, la realidad es que su disponibilidad a largo plazo depende únicamente de la voluntad y la capacidad de algunas personas desarrolladoras para realizar el (tedioso) mantenimiento cotidiano que lo mantiene funcionando, que sigue dando soporte a nuevas cámaras, etc., lo cual es una tarea infravalorada porque no produce notas de versión ni conferencias espectaculares.

Peor aún, la así llamada “libertad” que otorga la licencia GNU/GPL afecta únicamente al código fuente : es la libertad del ingeniero. Las licencias de código abierto renuncian esencialmente a la propiedad intelectual sobre el código, lo que significa que los ingenieros pueden estudiarlo y modificarlo, y luego compartir sus modificaciones. Dado que menos del 6 % de la población mundial¹ es realmente capaz de escribir código, este es un derecho solo para una minoría privilegiada. En cuanto a los usuarios, bueno, la licencia GPL es bastante clara :

Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA;

Esta declaración excluye esencialmente a los usuarios finales de la transacción : no tienen más derecho que ejecutar el código tal cual, y en particular ningún derecho a obtener soporte y correcciones de errores, y mucho menos a que el software se adapte a sus necesidades. Si aun así se proporciona algún soporte, es a discreción de las personas desarrolladoras, y los usuarios deberían estar eternamente agradecidos por ello. Esto se abusa en las así llamadas “comunidades de código abierto” (es decir, “foros de software”) para acallar e invalidar cualquier queja de los usuarios : simplemente no pueden quejarse, ya que están usando trabajo gratuito, aun cuando el marketing de los proyectos de código abierto a menudo se deshace en elogios sobre la idoneidad “profesional” de esas aplicaciones. Pero… se hicieron promesas, se pronunció la palabra “pro” pero no se cumplió, así que hay una inconsistencia engañosa en algún punto.

Incluso renunciando a toda responsabilidad hacia los usuarios, muchos proyectos aún intentan convertirlos, si no en clientes, al menos en donantes. Lo cual se enfrenta a un triste estado de las cosas : 350 años de capitalismo han podrido nuestros cerebros hasta hacernos pensar que las aplicaciones de código abierto eran el competidor más barato del software propietario. Los usuarios simplemente se quedan sentados esperando a que los proyectos entreguen un producto antes de decidir si se molestarán en donar. Esto es como empezar a financiar la NASA después de que se haya lanzado el primer cohete para demostrar que el proyecto sí puede cumplir : es imposible. Hay que pagar el trabajo incluso antes de que haya un producto que vender. Y cuando el producto se lanza, proyectos como Wikipedia todavía tienen dificultades para conseguir menos de 3 $/año del 2 % de su base de usuarios.

Las aplicaciones de código abierto son competidoras de las aplicaciones propietarias igual que los hospitales públicos son competidores de las clínicas privadas : no lo son. Por un lado, tenemos un proyecto socialista nacido de la creencia de que todo el mundo tiene derecho a la atención sanitaria, y si no puede pagarla, nos las arreglaremos encontrando dinero extra dentro de la comunidad. Por el otro lado, tenemos accionistas que intentan obtener beneficios, contratando cirujanos que intentan pagar su casa en Malibú y su colección de Porsche. ¿Cómo van a ser competidores ? Un servicio público es una manera de asegurar que las personas tengan recursos para ejercer sus derechos, porque la libertad es solo teórica hasta que tienes los medios para hacer uso realmente de tus derechos. Una empresa privada que vende bienes o servicios es una manera de ganar dinero a partir de inversiones. La diferencia es política. También es económica, ya que no tener a los accionistas en la nómina hace que el producto final sea de todos modos más asequible.

El punto ciego del movimiento del “Software Libre” fue evitar reflexionar sobre el contexto y la estructura de trabajo en la que ese software ocurre, se desarrolla y se mantiene. Esto puede rastrearse hasta la cultura hacker , que es individualista por naturaleza y compatible con el capitalismo por interpósita persona, a través de la tecnofilia  y el tecnosolucionismo . “Compartir tal cual” (tu trabajo, tu código, tus hacks) se confundió con “hacerse cargo de” (las necesidades, limitaciones y desafíos de otras personas) y se alimentó con narrativas cuasihagiográficas. Cuando tienes un martillo, todo parece un clavo : cuando lo único que sabes es código, el código es la solución a todo, e intentar envolverlo en filosofía y política (no revolucionaria) para definir la “libertad del código” sigue sin captar el panorama general, que es la explotación del trabajo de todos por parte de una clase social pequeña pero poderosa y capaz de reproducirse a sí misma. Mientras que el 6 % de la población mundial sabía escribir código en 2021, la proporción que siquiera podía permitirse un ordenador personal en los años 1980, cuando nació el movimiento del Software Libre, era mucho menor. Las minorías privilegiadas siempre son ciegas a sus privilegios : así es como se las identifica. No supieron ver que el Software libre no era más que el fruto de esos privilegios. Es libertad solo para quienes pueden permitírsela. Y el hecho de que la etiqueta de precio no lleve un signo de dólar es lo que lo hace perverso. Sigue teniendo una etiqueta de precio.

El movimiento del Software Libre fue concebido para encajar en este capitalismo individualista, de libre empresa y mercado liberal, e hizo que todo el mundo pensara que bastaba con dejar que cada cual iniciara su propio proyecto o lo bifurcara a partir de otros. Después, el darwinismo social  pondría las cosas en su sitio. Sí, pero… ¿quién paga el trabajo ? Peor aún, dado que el capitalismo da valor al trabajo únicamente cuando su producto se vende en un mercado liberal, y ese valor está indexado a la escasez del producto, ¿cómo se supone exactamente que vamos a convencer a los usuarios de que algo desmaterializado, descargable infinitamente y gratis, tiene algún valor ? Muchos proyectos de código abierto han probado muchas estrategias distintas para financiar su trabajo; todas son precarias y están mermadas porque siguen queriendo encajar una estructura de trabajo que es comunista por naturaleza dentro de un marco capitalista (más sobre esto abajo).

Si bien las organizaciones sin ánimo de lucro pueden funcionar para proyectos humanitarios, donde los donantes nunca serán los destinatarios del trabajo, en los proyectos de software las donaciones son interesadas, porque los donantes son usuarios. Esto alimenta un comportamiento propio del consumidor, en el que consumidores pasivos (y en cierto modo oprimidos) esperan los bienes entregados por una minoría de élite de miembros de la junta que dan las órdenes. Esas organizaciones sin ánimo de lucro siguen siendo de gestión privada, y el público no tiene otro derecho que el de dejar de donar si no se siente escuchado. La junta de la Linux Foundation  está compuesta casi exclusivamente por ejecutivos de fabricantes de hardware y de las GAFAM , la junta de la Free Software Foundation  está compuesta por científicos y técnicos informáticos. No hay ahí ninguna representación de los usuarios, hay estructuras jerárquicas verticales de “los que saben” sobre “los que necesitan”, que perpetúan el mismo tipo de dominación que el capitalismo, menos los beneficios.

Esto se justifica por el hecho de que las licencias de código abierto eximen a las personas desarrolladoras de toda forma de responsabilidad (garantía) hacia los usuarios, lo que la convierte en una transacción unidireccional que aparentemente da todo el poder de decisión a las personas desarrolladoras. Pero todo eso es, por supuesto, un constructo, y no una conclusión inevitable. Por el otro extremo, dado que el dogma capitalista está tan profundamente impregnado en los cerebros de los usuarios, el código fuente lleva un software a un mercado libre, desmaterializado y no escaso que anula toda noción de valor capitalista, lo que hace que a los usuarios les parezca aceptable obtener el producto del trabajo sin contribuir : otra transacción unidireccional. Mientras tanto, algunas personas desarrolladoras se queman y se agotan para brindar un soporte razonable a los usuarios, sin obtener un ingreso razonable por su trabajo (explotado), tal vez con la esperanza de que acabe siendo rentable a la larga, una vez que “triunfen”. O bien las personas desarrolladoras aceptan la regla tácita del código abierto (debería ser solo un pasatiempo/dedicación a tiempo parcial), lo que inevitablemente frena el código abierto, como un hermano condenado a la pobreza del software propietario. O, finalmente, algunas empresas de código abierto como Automattic  o RedHat  empiezan a volverse cada vez más agresivamente codiciosas con el tiempo, enfrentándose a la reacción de sus comunidades. Esto no es sostenible, para ninguna de las partes implicadas.

Necesitamos convertir esas dos transacciones unidireccionales paralelas en un círculo. Así es como :

1. Ninguna tecnología puede existir fuera de la sociedad que la produce. La tecnología necesita ciencia. La ciencia necesita investigación. La investigación necesita estructuras donde pueda llevarse a cabo libremente. La sociedad es el entorno donde todo eso ocurre, así como el sistema de apoyo que lo hace posible.
2. Ninguna tecnología puede existir sin trabajo. Si el producto del trabajo escapa al sistema capitalista (mercado liberal basado en la escasez y en la competencia), entonces el trabajo que lo produce también debería escapar de él.
3. Ninguna tecnología de propiedad privada servirá al bien común y al interés público. Las tecnologías, no solo los dispositivos, deberían pertenecer a sus usuarios, no solo a quienes las fabrican.
4. El trabajo es la única riqueza. Los trabajadores deberían beneficiarse de su trabajo, se venda en un mercado liberal o no : debería pagarse pase lo que pase. El trabajo debería realizarse en un entorno seguro y justo. Es una responsabilidad colectiva y social hacer que eso ocurra, porque el producto del trabajo sirve al bien común y al interés público. El trabajo que no sirve a estos debería simplemente detenerse.
5. Las tecnologías que pertenecen a sus usuarios abren el camino a un nuevo tipo de producción : la colaboración entre fabricantes y usuarios, en lugar de la competencia entre fabricantes y guerras corporativas por ganar mercados convenciendo a los clientes de la superioridad de algún producto (haciendo pagar la publicidad a los usuarios al final…). Pero el capitalismo no sabe cómo vender el producto de la cooperación, porque ya no hay un comprador o vendedor separado, solo una comunidad de personas que trabajan juntas hacia algo : satisfacer sus necesidades, convertir sus derechos teóricos en libertad real creando el contexto para ejercerlos.
6. Existe una responsabilidad mutua de los fabricantes hacia los usuarios (satisfacer sus necesidades mediante/con la tecnología), y de los usuarios hacia los fabricantes (darles un entorno de trabajo seguro y justo y condiciones materiales de vida). Esto es lo más básico de una comunidad²…
7. El código abierto que conduce a la verdadera libertad solo puede darse dentro de una estructura cooperativa . Que es un comunismo antiguo, probado y ya en funcionamiento, donde la empresa (por lo tanto el proyecto de código abierto en su conjunto) pertenece a sus clientes y a sus trabajadores, que comparten los poderes de voto. Esto va mucho más allá de una mera renuncia a la propiedad intelectual (licencia de código abierto/libre).

Una cooperativa es una forma de romper esta dicotomía entre “nosotros” y “ellos”, fabricantes frente a usuarios, que alimenta el resentimiento mutuo : las personas desarrolladoras son los dictadores que toman la aplicación como su parque de recreo personal, a quienes los usuarios siempre deberían estar agradecidos por más que la destrocen, los usuarios son las molestas sanguijuelas que no paran de plantear incidencias crípticas y peticiones de funciones, mientras donan demasiado poco.

En una cooperativa, tanto los fabricantes como los usuarios son miembros-accionistas. Todos son propietarios del proyecto, todos tienen un voto en la asamblea general. El proyecto consiste en hacer que la edición de fotos sea libre en un futuro previsible, bajo una visión unificada de lo que es la edición de fotos (cuán técnica y detallada debería ser frente a cuán fácil y sencilla de usar). Para cumplir ese objetivo intervienen muchos medios, como la educación, la promoción, la documentación y, obviamente, una aplicación de software. El proyecto es más que un simple producto final, que puede tardar algún tiempo en aparecer y estar listo : el proyecto es todo lo que está por encima y alrededor, es un objetivo y todos los medios para hacerlo realidad.

La responsabilidad de los miembros es asegurar un presupuesto anual para cubrir todos los costes del proyecto, muy probablemente a partir de las cuotas anuales de los miembros. A partir de ese presupuesto, en la asamblea general se decide una determinada cantidad de horas de trabajo a una determinada tarifa por hora. Cómo se gastará ese presupuesto (qué tipo de tareas, hardware, herramientas, etc.) también se decide en la asamblea general. Para las tareas técnicas, como el desarrollo de software, se tratará de las orientaciones de alto nivel (como mejorar el enmascaramiento, el flujo de trabajo por lotes, etc.) y no de los detalles de implementación o del diseño concreto, que se adaptan mal a los procesos democráticos. Las personas desarrolladoras podrían impulsar tareas orientadas al backend (como reescribir o refactorizar la deuda técnica, para reducir el coste de mantenimiento a largo plazo), los usuarios podrían impulsar tareas orientadas a funciones (como dar soporte a nuevas funciones de cámaras, formatos de imagen, etc.) : el propósito de la asamblea general es deliberar y jerarquizar las prioridades.

Las tareas acordadas serán entonces abordadas por trabajadores remunerados en orden de prioridad hasta que se agote el presupuesto de trabajo. Esto no se limita al trabajo tecnológico y de desarrollo, sino que se aplica a cualquier tipo de trabajo acordado previamente. Cuando se agote el presupuesto, los trabajadores informarán de dónde se detuvieron en la lista de tareas, qué pudieron terminar, qué no pudieron y qué recursos faltaron para terminar. La asamblea general decidirá entonces si es posible y deseable invertir más recursos para terminar, o trasladar las tareas restantes al presupuesto anual siguiente. Esto da a los trabajadores visibilidad sobre sus ingresos anuales sin fomentar el exceso de compromiso ni el agotamiento.

Los usuarios pueden formar paneles para trabajar con las personas desarrolladoras en la comprensión de los problemas concretos que se enfrentan, probar y validar soluciones dentro de un proceso de diseño. Cualquier usuario puede convertirse en trabajador y empezar a percibir ingresos por su trabajo en tareas acordadas, previa aprobación de la asamblea general.

Esto hace que sea responsabilidad de todos asegurar que se reúnan los recursos para avanzar, y dar a los trabajadores lo que necesitan para trabajar dignamente, de forma segura, sin ser explotados. Ninguna cantidad de trabajo debería ser gratuita, sea cual sea la tarea. El trabajo no debería limitarse a la programación u otras tareas técnicas.

Los límites de la democracia

La democracia por voto consiste esencialmente en expresar la voluntad de la mayoría, que es conocida por oprimir a las minorías. Por lo tanto, no es perfecta. Las minorías podrían plantear preocupaciones razonables y legítimas, solo que no serán compartidas por la mayoría. Vienen a la mente las personas con discapacidad : algunos detalles de diseño pueden hacer que toda la aplicación sea completamente inutilizable para ellas, aun cuando no tengan el número necesario para imponer sus puntos de vista en una votación. Por el otro extremo, no es posible acomodar las necesidades peculiares de todos y cada uno sin crear monstruos. Esto debe evaluarse y arbitrarse cuidadosamente.

La responsabilidad de la mayoría es, por tanto, identificar quiénes son las minorías estructurales, es decir, qué propiedades unen a esas minorías (condición de salud, origen social, educación, nivel de ingresos, etc.). Si una minoría plantea un problema que le resulta bloqueante debido a una de las propiedades que la definen, debería haber una manera de eludir o reponderar el voto de la mayoría. Esto queda por definir, pero la forma más sencilla de abarcarlo es durante las deliberaciones, que dependen de la empatía y la comprensión de la mayoría.

Otro problema de cualquier grupo social es el pensamiento de grupo , porque todo grupo social tiende a degradarse en un club con el tiempo. El pensamiento de grupo se da cuando los individuos no se sienten libres de plantear problemas que van en contra del (supuesto) consenso del grupo, por miedo a las repercusiones respecto a su lugar y su percepción dentro del grupo. Esas repercusiones pueden ser muy sutiles y a la vez muy reales. Se vuelve perjudicial cuando los individuos empiezan a apoyar decisiones, dentro del grupo, que no habrían apoyado por su cuenta : este es el punto de inflexión en el que se pierde la racionalidad individual. Para evitarlo, se puede usar el voto anónimo, pero no se aplica a las deliberaciones, donde necesariamente hay un orador. Hay una cultura de disensión sana que construir, mantener y fomentar. Una forma de resolver este problema es designar aleatoriamente un “abogado del diablo” para cada sesión, cuyo trabajo será estar en desacuerdo constantemente y exponer los argumentos correspondientes.

Cabe esperar que cualquier comunidad basada en un interés compartido por la fotografía y el software libre esté sesgada a favor de hombres ricos, cultos, con conocimientos informáticos y angloparlantes. Habrá que hacer un esfuerzo consciente para intentar incluir a mujeres, personas con menos formación, ciudadanos no occidentales, etc. Combinado con la democracia por voto y el pensamiento de grupo, puede ser realmente perjudicial partir de un grupo tan socialmente homogéneo, si no se gestiona con cuidado. Este será un desafío diario del que todos deben ser conscientes. También alimentará el sesgo del superviviente , donde los marginados no están aquí para dar su opinión sobre por qué no se unieron, no participaron o no se sintieron bienvenidos, y los marginados necesitarán un cuidado extra para ser alcanzados y acogidos.³ No se puede tolerar ninguna cantidad de racismo o sexismo en un entorno así, ni siquiera como broma, porque eso haría que la mayoría se riera a costa de las minorías en un contexto del que ya están filtradas de entrada.

La democracia es también un proceso lento. Pueden ocurrir cosas que necesiten una decisión rápida, como una brecha de seguridad en el servidor del proyecto o en las cuentas de redes sociales, o cualquier problema legal apremiante. Alguien debería ser elegido para mandatos de corta duración a fin de poder tomar rápidamente esas decisiones en nombre de la comunidad.

Los límites de los expertos frente a los legos

Al igual que los médicos o los abogados, las personas desarrolladoras tienen competencias y experiencia especializadas, que les darán una especie de poder e incluso carisma sobre los legos. Este poder puede abusarse para oprimir a la mayoría aprovechando su falta de conocimiento en beneficio del opresor. Esta relación siempre será asimétrica, y eso hay que reconocerlo. Además, habrá que consultar a las personas desarrolladoras durante las deliberaciones en la asamblea general, para evaluar la viabilidad de las tareas y los recursos necesarios, antes de que se produzcan las votaciones.

Al igual que los médicos, abogados, etc., las personas desarrolladoras deberían mantener una especie de código ético acorde con su poder simbólico, entre el cual :

1. el deber de informar honestamente, en la medida de sus conocimientos, y de explicar de forma sencilla lo que puede explicarse de forma sencilla,
2. el deber de proceder debidamente y con la diligencia debida al investigar y desarrollar soluciones,
3. el compromiso de trabajar en el mejor interés de la comunidad.

Por el otro extremo, las personas desarrolladoras (o cualquier otro experto) podrían ser percibidas por los legos como magos omniscientes y omnipotentes, que entonces podrían pedirles demasiado. Aunque el software es un medio bastante maleable, siguen existiendo restricciones técnicas no negociables que se aplican, y no todo lo que es técnicamente posible puede ser posible en las circunstancias actuales con los recursos actuales.

Habrá que entender ambas posturas para evitar que crezca el resentimiento mutuo.

Los límites de la colaboración

Todo el mundo es diseñador.

Todo trabajo del que no sabes nada parece fácil de hacer. Diseñar y construir objetos técnicos es uno de ellos. Incluso resulta emocionante contribuir a ello. Pero un software que van a usar como herramienta miles de usuarios distintos de ti mismo no es lo mismo que tu propia mesita de noche.

Se debería dar la bienvenida a los usuarios para que participen en la definición del problema : partir de uno o varios usuarios que tienen un problema concreto en un flujo de trabajo concreto, ver si no se puede resolver ya con las herramientas actuales y quizá algo de educación, y si no, intentar sondear cuántos usuarios comparten el mismo problema. Si el problema no es exactamente el mismo para todos, intentar encontrar una expresión común del problema que permita generalizarlo.

Una vez definido el problema comienza el proceso de diseño, que sigue pasos formales para evitar precipitarse hacia la primera solución (y muy probablemente no óptima) porque, de nuevo, la intuición humana es mejor para construir mesitas de noche que herramientas usadas por miles. Pero seguir el proceso no es suficiente.

La psicología y las ciencias cognitivas convergen hacia un consenso : el mejor tamaño para los equipos de trabajo está entre 4 y 7 miembros. A partir de 8 miembros, la productividad empieza a caer drásticamente.⁴⁵⁶ Para un equipo de 4 miembros, hay 6 canales de comunicación interpersonal, mientras que para 8 miembros hay 28 canales de comunicación. Esto hace difícil llevar un seguimiento cognitivo de todos los involucrados, de quién está a cargo de qué, procesar las señales no verbales, lo que crea una sobrecarga de comunicación. Por encima de 9 miembros, empiezan a formarse clanes, la política se mezcla en el proceso, y aparece la holgazanería social .⁴⁵

Esto significa que el trabajo debería dividirse en equipos de trabajo que tengan cada uno no más de 6 a 7 miembros, aun cuando pueda resultar emocionante para la comunidad en general interesarse por todo. La comunicación es el punto de inflexión aquí : necesitas justo la cantidad adecuada de ella, ni más ni menos, de lo contrario satura cognitivamente a los miembros del equipo y obstaculiza la propia comunicación. Ahí, es el trabajo en sí el que se resiente.