Arquitectura de Doble Cara de Jano: cómo afrontar la carrera de la Reina Roja en la economía de la información

Instituto de Investigación Aplicada en Teoría de Redes

ID del documento: P3-011

Versión: 1.0

Noviembre de 2025

Resumen

Las aplicaciones de plataforma conservan su poder mediante la asimetría de información: crean interfaces separadas para distintas clases de usuarios mientras ocultan las relaciones entre ellas [es decir, DoorDash Dasher (para repartidores), DoorDash Order Manager (para restaurantes) y la app de cliente de DoorDash (para consumidores)]. Proponemos las "Aplicaciones de Doble Cara de Jano" (JFA, por sus siglas en inglés): un marco que reemplaza las interfaces aisladas por arquitecturas transparentes y multirrol en las que todos los participantes acceden a la información completa del sistema. Inspirándonos en el concepto del Estado "de doble cara de Jano" de Acemoglu y Robinson en The Narrow Corridor, y aplicando la teoría contemporánea de la metacomunicación, las JFA permiten que las comunidades operen plataformas de coordinación de forma cooperativa y sin asimetría de información. Esto hace posible una gobernanza democrática a escala de plataforma.

1. 1. El problema: la asimetría de información como característica arquitectónica

1.1 Teoría contemporánea de la metacomunicación: el fundamento arquitectónico

La teoría de la comunicación moderna ha evolucionado considerablemente más allá de los marcos de mediados del siglo XX, pero las ideas fundamentales sobre cómo la comunicación construye relaciones de poder siguen siendo centrales. Apoyándose en la obra fundacional de Watzlawick, Bavelas y Jackson (1967) sobre la pragmática de la comunicación humana, los estudiosos contemporáneos subrayan que toda comunicación opera en múltiples niveles simultáneos:

Distinción contenido/relación:

Toda comunicación conlleva ambas cosas:

• Dimensión de contenido: la información literal que transmite el mensaje

• Dimensión de relación: metainformación sobre la relación entre los comunicantes que determina cómo deben interpretar el contenido los receptores

La dimensión de relación enmarca el contenido: aporta el contexto interpretativo a través del cual los receptores entienden toda la información. El mismo mensaje de contenido significa algo completamente distinto cuando lo comunican pares frente a cuando lo comunican partes situadas jerárquicamente. La dimensión de relación es metacomunicativa: es comunicación sobre cómo interpretar la comunicación.

Estructuras de relación simétricas frente a complementarias:

Los sistemas de comunicación construyen dos tipos fundamentales de relaciones:

• Relaciones simétricas: basadas en la igualdad, donde los participantes tienen un acceso equivalente a la información y al poder de decisión

• Relaciones complementarias: basadas en la diferencia, donde una parte ocupa una posición superior y la otra una posición subordinada

Las relaciones complementarias no son problemáticas en sí mismas: las relaciones mentor-estudiante, experto-novato o cuidador-receptor cumplen funciones importantes. Sin embargo, cuando las relaciones complementarias se vuelven rígidas e inmutables, generan patologías de la comunicación en las que la parte subordinada no puede cuestionar la propia estructura de la relación.

Idea arquitectónica: los sistemas de comunicación no se limitan a transmitir contenido: construyen e imponen estructuras de relación a través de qué información ponen a disposición de qué participantes. Cuando una plataforma concede un acceso asimétrico a la información de nivel de sistema (economía, algoritmos, datos comparativos), impone arquitectónicamente una relación complementaria en la que el operador de la plataforma ocupa la posición superior permanente.

Los participantes de la plataforma no pueden cuestionar esta estructura porque carecen de acceso al nivel metacomunicativo: la propia información que define la relación. Esto crea lo que los estudiosos contemporáneos denominan "paradoja estructural": la plataforma dice a los participantes que son agentes independientes o socios valiosos (nivel de contenido), mientras que la arquitectura comunica simultáneamente su posición subordinada (nivel de relación) al retener la información del sistema.

1.2 Verificación estructural

Las plataformas contemporáneas estructuran tarifas y pagos en múltiples categorías con un lenguaje que enfatiza la variabilidad y la discrecionalidad. La documentación de tarifas suele incluir frases como "puede aplicarse", "sujeto a cambios", "varía según la ubicación" y "depende de la demanda": un lenguaje que impide la verificación incluso en principio.

El problema fundamental: ningún participante puede verificar las afirmaciones ni comprender la transacción completa. Considere lo que cada clase de participante ve en realidad:

El consumidor que inicia una transacción ve:
├─ Coste base: [amount]
├─ Tarifa de servicio: [variable by undisclosed factors]
├─ Tarifa de coordinación: [percentage that "may increase"]
├─ [Potentially] Cargos adicionales según el contexto
└─ Total: desconocido hasta una fase avanzada del proceso, varía entre transacciones

El consumidor no puede saber:
• Cuánto recibe el proveedor del servicio
• Cómo reciben su remuneración otras partes interesadas
• Qué factores determinan las tarifas variables
• Si las estructuras de tarifas han cambiado desde transacciones anteriores
• Cómo se distribuye el valor entre entidades locales y entidades de la plataforma

El proveedor del servicio ve:
├─ Oferta de tarea: [compensation for specified work]
├─ [After acceptance] Detalles completos de la transacción

El proveedor del servicio no puede saber:
• El pago total del consumidor
• Cómo calculó la plataforma la remuneración
• Qué porción representa las distintas categorías de pago
• Cómo afecta a la economía la remuneración de otras partes interesadas
• Si los importes de las ofertas se ajustan según los patrones de aceptación

Otras partes interesadas ven:
├─ Notificación de la transacción
├─ Su porción: [percentage or fixed amount]

Estas partes interesadas no pueden saber:
• Los flujos de pago completos
• Por qué su remuneración tiene una estructura específica
• Cuáles son realmente los costes operativos de la plataforma
• Si otros participantes comprenden la economía
• Cómo verificar las afirmaciones de la plataforma sobre las estructuras de costes

La característica arquitectónica: los diseñadores incorporaron esta opacidad en interfaces de aplicación separadas. Cada clase de participante recibe exactamente la información suficiente para cumplir su función e insuficiente para verificar las afirmaciones de la plataforma, negociar colectivamente o construir alternativas.

La información oculta funciona como la dimensión de relación (metacomunicación): clasifica cómo deben interpretar el contenido los receptores. La retención sistemática de la economía del sistema por parte de la plataforma comunica la estructura de la relación: "Ocupas una posición subordinada en la que debes confiar en cálculos no divulgados." La arquitectura impone relaciones complementarias en las que la verificación resulta estructuralmente imposible.

Los proveedores de servicios no pueden "asumir el rol del otro" (Mead, 1934): no pueden ver cómo experimentan la misma transacción los consumidores u otras partes interesadas. La arquitectura impide la comprensión compartida necesaria para reconocer intereses comunes y coordinar la acción colectiva.

La Arquitectura de Doble Cara de Jano transforma esto por completo:

Todos los participantes ven el mismo desglose de la transacción:

Pago del consumidor: [total amount]
├─ Coste principal: [amount] → El destinatario A recibe: [amount]
├─ Prestación del servicio: [amount] → El destinatario B recibe: [amount]
├─ Operaciones de la plataforma: [percentage] → Cubre los costes operativos
│   ├─ Infraestructura: [amount]
│   ├─ Procesamiento de transacciones: [amount]
│   ├─ Desarrollo: [amount]
│   └─ Gastos generales: [amount]
└─ Propina opcional: [amount] → El destinatario B recibe: [amount]

La plataforma hace visible para todos el desglose de operaciones:
• Infraestructura mensual: [fixed cost serving transaction volume]
• Procesamiento de transacciones: [per-transaction cost]
• Cooperativa de desarrollo: [transparent labor costs]
• Seguros y reservas: [shared cost basis]

Transparencia algorítmica:
• Lógica de emparejamiento: [documented, deterministic]
• No existen factores de precios variables ocultos
• Estructura de costes operativos plana
• La plataforma publica todos los métodos de cálculo

Gobernanza democrática:
• Cualquier participante puede proponer cambiar las estructuras de costes
• Votaciones periódicas con modelización financiera completa
• Todos los costes de la plataforma son auditables en tiempo real
• Los miembros deciden colectivamente la asignación del excedente

La transformación: pasar de relaciones complementarias (jerárquicas, sin verificación posible) a relaciones simétricas (iguales, con verificación incorporada). Los participantes pueden alternar entre roles y verificar todas las afirmaciones porque la arquitectura ofrece acceso completo a la información a todas las partes. La dimensión de relación pasa de "confía en nuestra autoridad" a "sois pares en el gobierno de esta infraestructura".

Ventaja económica: la comunidad puede redistribuir el valor retenido en las transacciones mediante la gobernanza democrática como: mayor remuneración para los proveedores de servicios, menores costes para los consumidores, mejor calidad en todo el sistema o reinversión comunitaria. El valor circula localmente en lugar de extraerse hacia accionistas lejanos.

1.3 ¿Por qué "de Doble Cara de Jano"?

En The Narrow Corridor (2019), Daron Acemoglu y James Robinson describen el Estado como inherentemente "de doble cara de Jano": permite la acción colectiva al tiempo que puede convertirse en un instrumento de opresión. Como la deidad romana Jano, que miraba en dos direcciones, el Estado debe ser a la vez poderoso (para coordinar) y responsable (para evitar la tiranía).

La libertad existe cuando la capacidad del Estado y la capacidad de la sociedad para frenar el poder evolucionan juntas. Cuando el poder evoluciona más rápido que la capacidad de control, la libertad se erosiona.

La misma dinámica se aplica a las plataformas digitales: las plataformas actuales coordinan la actividad económica (cara que habilita) mientras extraen valor mediante la asimetría de información (cara explotadora). El reto arquitectónico: ¿cómo construir plataformas que conserven el poder coordinador y eliminen la capacidad explotadora?

Las Aplicaciones de Doble Cara de Jano son plataformas que se orientan simultáneamente hacia múltiples roles de usuario manteniendo una transparencia completa para todos los participantes: lo bastante poderosas para coordinar, lo bastante transparentes para evitar la captura.

2. Arquitectura de Doble Cara de Jano: principios fundamentales

2.1 Cuatro transformaciones arquitectónicas

1. Interfaz unificada multirrol Todas las clases de usuarios acceden a la misma aplicación con vistas adecuadas a su rol, no a apps aisladas separadas. Los usuarios pueden cambiar de rol con un solo clic.

2. Transparencia total de la información El sistema hace visibles para todos los participantes los datos de nivel de sistema (algoritmos de emparejamiento, estructuras de precios, economía de la plataforma). No existe acceso privilegiado a la información.

3. Asignación reversible de roles (capacidad prosumidor) Los usuarios pueden alternar entre varios roles u ocuparlos simultáneamente: consumidor, productor, proveedor de servicios, inversor, gobernante de la plataforma.

4. Gobernanza democrática integrada La transparencia permite tomar decisiones informadas. Todos los participantes votan sobre las reglas de la plataforma, las estructuras de tarifas y las políticas con una comprensión completa de sus implicaciones.

2.2 El cambio de metacomunicación

Toda arquitectura de plataforma comunica en múltiples niveles de forma simultánea:

Nivel 1 — Funcionalidad explícita: "Este elemento de la interfaz ejecuta esta acción"

Nivel 2 — Relaciones implícitas: las interfaces separadas comunican "Sois clases distintas con derechos distintos"

Nivel 3 — Estructura de poder: la información oculta comunica "Los operadores de la plataforma toman las decisiones"

Nivel 4 — Naturaleza del sistema: el código propietario comunica "Esto es un producto que usas, no una infraestructura que gobiernas"

Las interfaces de plataforma no se limitan a transmitir información: construyen y mantienen relaciones de poder entre las clases de participantes. La metacomunicación (la comunicación sobre cómo interpretar la comunicación) moldea la comprensión de los sistemas sociales.

Los participantes desarrollan su comprensión imaginando cómo los perciben los demás y cómo perciben el sistema. Cuando las plataformas crean interfaces separadas, los participantes no pueden entender cómo experimentan el sistema otras clases de usuarios, lo que impide la comprensión compartida necesaria para la acción colectiva.

Ejemplo concreto de transformación metacomunicativa:

Cuando un proveedor de servicios en una plataforma tradicional ve "Tarea disponible", el mensaje explícito (Nivel 1) es funcional. Pero la negativa de la interfaz a mostrar la economía completa de la transacción hasta después del compromiso comunica (Nivel 3): "La plataforma controla el acceso a la información en función de tu cumplimiento." El proveedor no puede ver las perspectivas de otros participantes, y otros participantes no pueden ver las limitaciones del proveedor. Nadie puede verificar la afirmación de la plataforma de que el emparejamiento es óptimo.

En una aplicación de Doble Cara de Jano, la misma tarea muestra información completa: todos los importes de remuneración, todas las estructuras de tarifas, las asignaciones a los destinatarios y la justificación del emparejamiento.

La metacomunicación cambia por completo:

• Nivel 2: "Sois pares con información completa" (no subordinados con acceso controlado)

• Nivel 3: "Podéis verificar afirmaciones y coordinar alternativas" (no "confía en nuestra autoridad")

• Nivel 4: "Esto es una infraestructura que gobernáis colectivamente" (no "este es nuestro sistema propietario")

El proveedor de servicios ahora comprende las experiencias de otros participantes, los flujos de valor completos y los gastos generales de la plataforma. Esta comprensión compartida permite "asumir el rol del otro": los participantes pueden imaginar las perspectivas ajenas porque la arquitectura las hace mutuamente visibles.

Las Aplicaciones de Doble Cara de Jano transforman los cuatro niveles:

Nivel 1: interfaces específicas por rol + información del sistema transparente Nivel 2: la app unificada comunica "Sois participantes en un sistema compartido" Nivel 3: la información distribuida comunica "Todos los participantes contribuyen a la toma de decisiones" Nivel 4: el código abierto AGPL-3 comunica "Esto es una infraestructura que gobernáis colectivamente"

La transformación arquitectónica no solo cambia el flujo de información, sino lo que el propio flujo de información comunica sobre la relación de los participantes con la plataforma. Por eso la propiedad cooperativa sin transformación arquitectónica tiene dificultades para alcanzar su potencial democrático: la metacomunicación de la asimetría de información mantiene la concentración de poder con independencia de la estructura formal de propiedad.

3. Implementación mediante desarrollo de sala limpia

Los municipios que buscan desplegar cooperativas de plataforma se enfrentan a un problema práctico: las plataformas de coordinación que sus habitantes necesitan —transporte compartido, reparto, vivienda, servicios de cuidado— solo existen como aplicaciones corporativas propietarias. Copiar sin más esas plataformas infringiría la ley de derechos de autor. Construir desde cero exige duplicar años de trabajo de desarrollo y de refinamiento de la experiencia de usuario.

La ingeniería inversa de sala limpia resuelve este dilema. Es una metodología legal para recrear funcionalidades de software sin acceder al código fuente original ni copiarlo. El proceso funciona separando estrictamente la observación de la implementación: un equipo documenta lo que hace la aplicación (funciones y comportamientos observables), mientras que un equipo completamente independiente construye una nueva implementación basándose únicamente en esas especificaciones, sin ver jamás el código original. Los tribunales han respaldado de forma constante esta metodología como generadora de una obra legalmente independiente.

Para las cooperativas de plataforma, el desarrollo de sala limpia funciona como un método de renovación: permite a los municipios recrear aplicaciones de coordinación esenciales que aún no existen en el dominio público, publicarlas bajo AGPL-3 como bienes comunes permanentes y añadir las funciones de transparencia que convierten las plataformas extractivas en infraestructura democrática. Cada implementación exitosa fortalece todo el movimiento cooperativo en lugar de crear nuevos silos propietarios.

Esta metodología protege a las cooperativas frente a impugnaciones legales que podrían destruir las plataformas antes de que alcancen escala, al tiempo que impide el cercamiento corporativo de las herramientas desarrolladas por la comunidad.

3.1 Marco legal

La ingeniería inversa de sala limpia crea implementaciones legalmente independientes:

Paso 1 — Equipo de especificación: documenta la funcionalidad observable, sin detalles de implementación

Paso 2 — Revisión de derechos de autor: verifica que las especificaciones no contengan elementos propietarios

Paso 3 — Equipo de implementación: construye solo a partir de las especificaciones, sin ver jamás el código original

Paso 4 — Expansión de Doble Cara de Jano: añade la interfaz multirrol y las herramientas de transparencia y gobernanza

Esta metodología garantiza el cumplimiento legal a la vez que permite la transformación arquitectónica de la asimetría de información a la transparencia.

Consideraciones sobre patentes

Aunque la metodología de sala limpia aborda las preocupaciones de derechos de autor, no protege intrínsecamente contra la infracción de patentes. Las patentes protegen la funcionalidad (lo que hace el sistema) en lugar de la expresión (cómo escriben el código los desarrolladores), lo que significa que una implementación de sala limpia aún puede infringir patentes si reproduce métodos patentados.

Patentes habituales en plataformas:

• Algoritmos de emparejamiento (p. ej., métodos de optimización para emparejar proveedores de servicios con consumidores)

• Mecanismos de precios dinámicos (precios de sobredemanda, ajuste de tarifas según la demanda)

• Sistemas de reputación y valoración (metodologías de puntuación específicas)

• Optimización de rutas y coordinación logística

• Sistemas de seguimiento y notificación en tiempo real

Estrategias de mitigación:

1. Análisis del panorama de patentes: antes de iniciar el desarrollo, los equipos realizan búsquedas exhaustivas de patentes en las jurisdicciones pertinentes para identificar patentes existentes que cubran la funcionalidad objetivo. Herramientas como Google Patents, la base de datos de la USPTO y las búsquedas profesionales de patentes pueden detectar conflictos potenciales.

2. Desarrollo de diseño alternativo: cuando los equipos identifican patentes, implementan métodos alternativos que logran resultados similares mediante enfoques técnicos distintos. Por ejemplo:

   • Si alguien patentó el emparejamiento por proximidad con criterios de optimización específicos, los desarrolladores usan objetivos de optimización distintos (minimización del impacto ambiental, equilibrio de la carga de trabajo)

   • Si alguien patentó algoritmos de precios dinámicos, los desarrolladores implementan estructuras de precios transparentes, de tarifa fija o determinadas democráticamente

   • Si alguien patentó métodos específicos de puntuación de reputación, los desarrolladores crean marcos de evaluación alternativos

3. Publicación defensiva: los equipos documentan y divulgan públicamente los métodos de coordinación, los enfoques algorítmicos y los mecanismos de gobernanza novedosos que desarrollan para las JFA. Esto crea estado de la técnica que impide que otros patenten más tarde estos métodos y establece libertad de operación.

4. Participación en consorcios de patentes: las cooperativas pueden formar consorcios de patentes o unirse a los existentes (como Open Invention Network para software), donde los miembros se otorgan licencias cruzadas de patentes, creando zonas libres de patentes para el desarrollo de plataformas cooperativas.

5. Consideraciones geográficas: los derechos de patente son territoriales: una patente concedida en un país no se aplica en otros. Los equipos pueden reducir el riesgo mediante despliegues iniciales en jurisdicciones con menos patentes pertinentes o con disposiciones de uso legítimo más sólidas.

6. Diferenciación funcional: las diferencias arquitectónicas fundamentales de las JFA (interfaces multirrol, transparencia total, gobernanza democrática) suelen exigir enfoques de implementación funcionalmente distintos que, de forma natural, evitan infringir los métodos patentados específicos creados por los diseñadores para sistemas opacos y jerárquicos.

Ventaja de las JFA:

Los requisitos de transparencia en realidad favorecen la elusión de patentes. Cuando toda la lógica algorítmica debe documentarse y aprobarse democráticamente, las plataformas desarrollan de forma natural métodos de coordinación más simples y explicables, en lugar de algoritmos propietarios complejos que podrían estar patentados. Los procesos de gobernanza democrática tienden a reglas de emparejamiento transparentes (proximidad geográfica, cola cronológica, preferencia de los miembros) en lugar de funciones de optimización opacas.

Además, la expansión arquitectónica hacia la transparencia multirrol suele requerir implementaciones técnicas novedosas que constituyen métodos genuinamente distintos, no meras reproducciones de enfoques existentes. El paso de la asimetría de información a la simetría exige estructuras de datos, arquitecturas de interfaz y mecanismos de coordinación diferentes.

Evaluación de riesgos:

El riesgo de patentes varía significativamente según:

• Tipo de plataforma: las plataformas de logística y emparejamiento se enfrentan a una mayor densidad de patentes que las de procesamiento de pagos o las de tipo mercado

• Jurisdicción: EE. UU. tiene más patentes relacionadas con plataformas que la mayoría de las demás jurisdicciones

• Particularidades de la implementación: los enfoques novedosos de transparencia y gobernanza democrática tienen menos probabilidad de entrar en conflicto con patentes existentes creadas por los diseñadores para plataformas extractivas

Enfoque recomendado:

Para cada implementación de una JFA:

1. Los equipos realizan búsquedas de patentes específicas para el tipo de plataforma concreto y su funcionalidad central

2. Los equipos documentan las decisiones de diseño que demuestran el desarrollo independiente y la diferenciación funcional

3. Los equipos priorizan métodos de coordinación transparentes y gobernados democráticamente que difieren de los algoritmos de optimización patentados

4. Los equipos recurren a asesoría en patentes para implementaciones de alto riesgo (especialmente en los ámbitos de logística y precios dinámicos)

5. Los equipos aportan innovaciones a las bases de datos de publicación defensiva

Este enfoque de varias capas aborda las preocupaciones sobre patentes a la vez que mantiene los objetivos de transformación arquitectónica centrales para las JFA.

3.2 Desarrollo Jano

La sala limpia tradicional reproduce la funcionalidad existente:

• Interfaz del consumidor → interfaz del consumidor (equivalente)

• Interfaz del proveedor → interfaz del proveedor (equivalente)

• Interfaz de la parte interesada → interfaz de la parte interesada (equivalente)

• Resultado: múltiples interfaces separadas, la misma asimetría de información

La sala limpia de las JFA expande la funcionalidad de forma arquitectónica:

• Múltiples interfaces aisladas → plataforma unificada con cambio de rol

• Lógica del sistema oculta → algoritmos y economía transparentes

• Clases de usuarios separadas → fluidez prosumidor

• Control centralizado → gobernanza democrática distribuida

• Resultado: una sola aplicación, transparencia total, capacidad cooperativa

La expansión no infringe los derechos de autor porque crea funcionalidad que no existía en el sistema original.

3.3 AGPL-3 como protección estructural

NTARI publica todas las implementaciones de sala limpia bajo AGPL-3 (Licencia Pública General Affero de GNU) para impedir su recaptura:

Protecciones clave:

• Copyleft de red: los desarrolladores deben publicar bajo AGPL-3 las modificaciones de los servicios de red

• Compartición vírica: incorporar código AGPL-3 obliga a publicar toda la plataforma bajo AGPL-3

• Bienes comunes irrevocables: el código permanece en los bienes comunes de forma permanente

Para las cooperativas:

• Impide la adquisición y el cercamiento corporativos

• Permite la federación (varios municipios comparten la base de código)

• Desalienta la competencia corporativa (no se puede incorporar sin abrir toda la plataforma)

• Protege la inversión de la comunidad en los bienes comunes

AGPL-3 crea un "sistema inmunitario" frente a la captura corporativa: una protección arquitectónica para la infraestructura democrática.

4. Definiciones específicas de las JFA

Más allá de las prácticas estándar de desarrollo de código abierto, las JFA requieren cuatro características arquitectónicas que las distinguen de las plataformas convencionales:

4.1 Identidad unificada multirrol

Los sistemas JFA deben mantener modelos de datos unificados que admitan la ocupación simultánea de roles. Una única identidad de usuario permite ostentar varios roles (consumidor, proveedor, parte interesada, gobernante) sin cuentas separadas. Todos los permisos y vistas relacionados con los roles derivan de esa única identidad. El cambio de rol debe requerir una sola interacción (un clic o toque), sin cierre de sesión ni reautenticación. La interfaz debe indicar claramente el rol actual y hacer que todos los roles disponibles sean accesibles de inmediato.

Por qué importa: las plataformas convencionales separan arquitectónicamente las clases de usuarios para mantener la asimetría de información. La identidad unificada permite "asumir el rol del otro" (Mead, 1934): los participantes pueden experimentar el sistema desde múltiples perspectivas, construyendo la comprensión compartida necesaria para la coordinación democrática tal como la conciben los defensores del cooperativismo de plataforma (Scholz y Schneider, 2016).

4.2 Transparencia total de las transacciones

Los registros de transacciones deben captar y exponer desgloses económicos completos visibles para todos los participantes en tiempo real:

• Todos los flujos de valor (a todos los destinatarios, importes y justificación)

• Estructuras de tarifas completas (qué cubre cada tarifa, métodos de cálculo)

• Costes operativos de la plataforma (infraestructura, procesamiento, desarrollo, reservas)

• Algoritmo de emparejamiento utilizado (número de versión, justificación legible por humanos, alternativas consideradas)

Cada transacción se vincula a su documentación algorítmica. Las estructuras de costes de la plataforma se actualizan en tiempo real y permanecen visibles para todos los participantes. Toda la información de nivel de sistema debe ser accesible a través de API públicas (autenticadas, pero universalmente disponibles para los miembros).

Por qué importa: la transparencia elimina la imposibilidad arquitectónica de la verificación. Cuando los participantes pueden verificar todas las afirmaciones, la asimetría de información ya no puede mantener la concentración de poder.

4.3 Gobernanza democrática integrada

Las capacidades de gobernanza deben integrarse dentro de las interfaces funcionales, no aislarse en sistemas administrativos separados:

• Los sistemas de propuestas incluyen modelización del impacto financiero integrada y visible para todos los miembros

• Mecanismos de votación accesibles desde cualquier vista de rol

• El estado y los resultados de la implementación se rastrean y son públicamente visibles

• Todos los algoritmos de emparejamiento y coordinación se aprueban mediante procesos de gobernanza democrática

• Las decisiones algorítmicas se registran para su revisión por la gobernanza y la mejora del sistema

Por qué importa: separar la gobernanza de las operaciones mantiene la estructura de relación complementaria. Integrar la gobernanza en las interfaces funcionales comunica "tú gobiernas esta infraestructura" en cada interacción.

4.4 Arquitectura de federación

La arquitectura técnica debe admitir la federación: múltiples instancias independientes que comparten estándares de protocolo y, opcionalmente, datos:

• Las instancias locales conservan plena autonomía a la vez que se benefician de los efectos de red

• Los estándares de protocolo permiten la coordinación entre instancias sin control centralizado

• Los protocolos abiertos publicados bajo AGPL-3 impiden el cercamiento

• La interoperabilidad impide que las dinámicas de "el ganador se lo lleva todo" recreen monopolios

Por qué importa: la federación permite que las redes cooperativas alcancen escala a la vez que impide la consolidación del poder. Esta es la respuesta arquitectónica a "las cooperativas de plataforma no pueden competir a escala": no compiten individualmente, se federan.

5. Agenda de investigación

5.1 Preguntas críticas

Económicas:

• ¿Qué efecto multiplicador local real se produce cuando el valor permanece dentro de las comunidades?

• ¿Cómo se comparan los costes cooperativos de captación de clientes con los de las plataformas financiadas por capital riesgo?

• ¿Qué diferencias de eficiencia operativa surgen de la transparencia?

• ¿Cómo afecta la gobernanza democrática a la velocidad de adaptación de la plataforma?

De gobernanza:

• ¿Qué tasas de participación logran los miembros en la gobernanza democrática?

• ¿Cómo afecta la transparencia a la calidad de la gobernanza y a la satisfacción de los miembros?

• ¿Qué estructuras de toma de decisiones funcionan mejor en distintas escalas?

• ¿Cómo coordinan la gobernanza las plataformas federadas entre localidades?

Técnicas:

• ¿Qué funciones de transparencia usan y valoran realmente los miembros?

• ¿Cómo pueden las plataformas federadas mantener la coordinación sin control centralizado?

• ¿Qué barreras técnicas impiden o facilitan la adopción?

• ¿Cómo afecta el desarrollo de código abierto a la seguridad y la fiabilidad de la plataforma?

Sociales:

• ¿Cómo afecta la propiedad cooperativa a la dignidad y la satisfacción de los participantes?

• ¿Qué factores culturales facilitan o inhiben la adopción?

• ¿Cómo transitan las comunidades de plataformas extractivas a cooperativas?

• ¿Qué marcos educativos apoyan la gobernanza democrática de plataformas?

6. Conclusión: establecer la libertad de información

El capitalismo de plataforma extrae un valor sustancial mediante decisiones arquitectónicas que crean asimetría de información. La propiedad cooperativa por sí sola no puede resolver esto: las plataformas propiedad de sus miembros con interfaces aisladas siguen concentrando poder mediante el control de la información. La libertad depende de mantener el equilibrio entre la capacidad de coordinación y la capacidad de control. Cuando las plataformas evolucionan más rápido que la comprensión de los participantes, la libertad se erosiona hacia el autoritarismo algorítmico. Las instituciones democráticas deben evolucionar a la velocidad de la tecnología de plataforma o la libertad disminuye.

Las Aplicaciones de Doble Cara de Jano ofrecen la alternativa arquitectónica: plataformas transparentes y multirrol donde la simetría de información permite una gobernanza democrática genuina. La capacidad técnica existe. Los marcos legales están establecidos. El argumento económico es claro. Lo que queda es construir las primeras implementaciones, demostrar el modelo y catalizar la transición del capitalismo de plataforma a la cooperación de plataforma.

El desarrollo de sala limpia de Aplicaciones de Doble Cara de Jano de NTARI bajo AGPL-3 crea bienes comunes permanentes: infraestructura que las comunidades pueden desplegar, modificar y gobernar democráticamente sin temor al cercamiento. Los municipios pueden facilitar la transición mediante financiación inicial, preferencias en la contratación pública y claridad regulatoria. Las cooperativas pueden adoptar plantillas replicables, y los primeros en adoptarlas aceleran la transición de todo el movimiento. Los desarrolladores pueden innovar en transparencia arquitectónica, implementando infraestructura democrática que no existe en las plataformas propietarias. El objetivo no son mejores aplicaciones, sino una arquitectura económica fundamentalmente distinta que distribuya el poder en lugar de concentrarlo.

Como Jano, que mira simultáneamente al pasado y al futuro, las Aplicaciones de Doble Cara de Jano miran a la coordinación y a la rendición de cuentas: lo bastante poderosas para organizar una actividad económica compleja, lo bastante transparentes para evitar la captura y la extracción. Esta es la infraestructura del corredor estrecho. Esta es la libertad a escala de plataforma.

Referencias

Acemoglu, D., & Robinson, J. A. (2019). The Narrow Corridor: States, Societies, and the Fate of Liberty. Penguin Press.

Mead, G. H. (1934). Mind, Self, and Society: From the Standpoint of a Social Behaviorist. University of Chicago Press.

Scholz, T., & Schneider, N. (Eds.). (2016). Ours to Hack and to Own: The Rise of Platform Cooperativism, A New Vision for the Future of Work and a Fairer Internet. OR Books.

Watzlawick, P., Bavelas, J. B., & Jackson, D. D. (1967). Pragmatics of Human Communication: A Study of Interactional Patterns, Pathologies, and Paradoxes. W.W. Norton & Company.

Contacto: info@ntari.org

"Cuando el trabajo esté hecho y su objetivo cumplido, el pueblo dirá: 'Lo hicimos nosotros mismos.'" — Tao Te Ching, 17

"La libertad no surge del vacío... Es el resultado de una lucha continua por equilibrar el poder entre el Estado y la sociedad." — Acemoglu y Robinson