La capa de mods para todo el software open source

Documento de tesis y visión de producto

Resumen ejecutivo

La IA está haciendo que modificar software deje de ser una capacidad exclusiva de los ingenieros. Personas de producto, customer success, operaciones o cualquier disciplina con conocimiento del problema ya empiezan a producir cambios mediante agentes de programación.

Sin embargo, esa nueva capacidad choca con una infraestructura y unas formas de gobierno diseñadas para otro mundo. Para modificar un proyecto existente todavía hay que comprender repositorios, forks, ramas, issues, pull requests, entornos, compilaciones, pruebas, despliegues y actualizaciones. En proyectos open source aparece además una barrera adicional: el usuario depende de la velocidad, las prioridades y la prudencia legítima de sus mantenedores.

La tesis central es:

La IA va a generar capacidad de modificación mucho más rápido de lo que los proyectos de software podrán absorberla mediante sus canales tradicionales.

La oportunidad consiste en crear una plataforma que convierta proyectos open source existentes en bases modificables mediante IA. El usuario podría solicitar una mejora, probarla en una versión realista, iterar conversacionalmente y utilizar su propia versión desplegada y alojada por la plataforma —o empaquetada para su propia infraestructura—, sin aprender Git, operar servidores ni asumir la responsabilidad de mantener un fork.

Las modificaciones podrían guardarse como mods instalables y reutilizables. No formarían una única “Community Edition” gobernada centralmente. Cada usuario u organización elegiría su propia combinación de capacidades.

La definición más compacta del producto sería:

Una plataforma que proporciona extensibilidad sintética a proyectos open source: mantiene una capa compatible con upstream y permite convertir necesidades expresadas en lenguaje natural en mods probados, desplegables y compartibles.

Visto desde el usuario, esto es la promesa original del open source, por fin cumplida. La licencia siempre concedió el derecho a modificar el software; lo que faltaba no era el permiso sino la capacidad. Clonar el repositorio, comprender la arquitectura, sostener un fork durante años: durante treinta años la libertad de modificar ha sido real jurídicamente e inalcanzable en la práctica para casi todo el mundo. La IA acorta esa distancia, y este producto la convierte en infraestructura.

El entregable no es código: es la aplicación del usuario en funcionamiento, con sus mods activos, desplegada y alojada por la plataforma —o empaquetada e instalable en su propia infraestructura— y mantenida frente a las versiones de upstream.

El producto opera en dos niveles. Un modo abierto permite desplegar una instancia funcional de cualquier repositorio compatible y modificarla, best-effort y sin garantías de mantenimiento: expresa la misión en el producto y genera telemetría sobre qué quiere modificar la gente realmente. Un catálogo certificado reúne los proyectos con adaptador mantenido, trenes de release y garantías contractuales: concentra la confianza y el negocio.

1. Situación actual

1.1. Crear código está dejando de ser la principal barrera

Los modelos frontera ya son capaces de:

• comprender repositorios existentes;
• realizar cambios en múltiples archivos;
• utilizar herramientas y terminales;
• ejecutar builds y tests;
• observar errores y reparar sus propias implementaciones;
• preparar despliegues y pull requests.

Estas capacidades todavía son imperfectas, especialmente en arquitecturas grandes o mal documentadas, pero su progreso está siendo muy rápido.

Como consecuencia, dentro de las empresas tecnológicas ya aparecen personas no dedicadas a ingeniería que abren pull requests o realizan pequeños cambios con IA. Todavía suele haber un ingeniero revisando y aceptando el resultado, pero la producción material del código está empezando a desplazarse.

1.2. El cuello de botella se desplaza hacia la validación

En este nuevo escenario, el problema principal deja de ser escribir la modificación. Pasa a ser:

• conseguir que el proyecto funcione localmente;
• crear un entorno realista de prueba;
• comprobar que el cambio resuelve el problema;
• evitar regresiones;
• empaquetarlo;
• desplegarlo;
• mantenerlo cuando cambie el proyecto original.

La persona que solicita el cambio puede no entender la arquitectura, pero frecuentemente sabe evaluarlo mejor que el programador.

Una bióloga puede no saber modificar un algoritmo de procesamiento de imágenes, pero sí sabe que una medición falla cuando existe poco contraste y puede comprobar si la nueva versión produce un resultado científicamente correcto.

La división del trabajo futura puede ser:

• La persona aporta intención, contexto de dominio y criterio de validación.
• La IA aporta ingeniería, implementación e iteración.
• La plataforma aporta entornos, pruebas, despliegue, seguridad y continuidad.

1.3. El open source es accesible jurídicamente, pero no operativamente

Que el código esté disponible no significa que un usuario pueda modificar el producto de forma práctica.

Hoy, para cambiar un proyecto open source, normalmente hay que:

1. Encontrar y clonar el repositorio correcto.
2. Comprender su arquitectura.
3. Instalar dependencias.
4. Configurar servicios y variables.
5. Crear un fork o una rama.
6. Implementar el cambio.
7. Ejecutar pruebas.
8. Compilar o empaquetar.
9. Desplegar o instalar una versión personalizada.
10. Mantenerla frente a futuros releases.

Incluso para un ingeniero, este proceso puede ser incómodo. Para una persona no técnica es directamente inaccesible.

1.4. El modelo de contribución presupone una única versión canónica

Actualmente, cambiar software ajeno se interpreta normalmente como una propuesta a sus propietarios:

Necesito una funcionalidad → abro una issue → alguien decide si la acepta → se implementa → quizá aparece en una futura versión.

Ese mecanismo es razonable cuando el objetivo es mejorar una única versión que debe funcionar para todo el mundo. Pero no todas las necesidades válidas deben incorporarse a upstream.

Un mantenedor puede rechazar una funcionalidad porque:

• solo interesa a pocos usuarios;
• aumenta la superficie de mantenimiento;
• no encaja con la visión del proyecto;
• introduce dependencias o riesgos;
• complica la interfaz;
• exige soporte permanente;
• entra en conflicto con otra necesidad igualmente válida.

La visión alternativa es:

Necesito una funcionalidad → la describo → la IA la implementa → la pruebo → utilizo mi versión.

Contribuir el cambio upstream seguiría siendo posible, pero dejaría de ser una condición para poder utilizarlo.

1.5. La desigual adopción de IA crea una ventana de oportunidad

Las capacidades de IA no se repartirán de forma homogénea entre los proyectos.

Algunos tendrán equipos grandes y agentes avanzados. Otros estarán mantenidos por una sola persona, serán deliberadamente conservadores, se encontrarán en modo mantenimiento o estarán prácticamente abandonados.

Esto producirá una asimetría:

• Muchos usuarios serán capaces de generar cambios.
• Pocos mantenedores tendrán capacidad o incentivos para revisarlos.
• La cantidad de modificaciones posibles crecerá más rápido que la capacidad de incorporarlas a las versiones oficiales.

La oportunidad no depende únicamente de que algunos mantenedores adopten tarde la IA. Incluso si todos la utilizaran perfectamente, una única versión canónica nunca podría contener todas las modificaciones particulares, experimentales o incompatibles que desean sus usuarios.

1.6. De qué estamos hablando realmente

Alrededor de cada proyecto open source relevante existe un mercado fragmentado de empresas, partners y consultoras que lo instalan, integran, personalizan y mantienen para cada cliente. Buena parte de ese trabajo no consiste en crear software desde cero, sino en aplicar cambios acotados y comprobables sobre una arquitectura que ya existe. Por eso, la personalización de software parece una de las primeras capas de los servicios de desarrollo que los agentes podrán automatizar de principio a fin.

El mercado mundial de servicios open source se situó alrededor de los 35–41 mil millones de dólares en 2025, según distintas estimaciones de TechSci Research, Mordor Intelligence y Fortune Business Insights. No existe una categoría contable limpia llamada “modificaciones”: el trabajo aparece repartido entre consultoría, implementación, integración, desarrollo y mantenimiento. Como hipótesis interna, el cambio directo de código podría representar aproximadamente un 15–30% de ese mercado —unos 6–12 mil millones de dólares—, mientras que la superficie completa que aborda el producto —personalización, integración, despliegue y mantenimiento de variantes— podría representar un 60–80% —unos 23–32 mil millones—. Son rangos de trabajo, no cifras publicadas por una fuente de mercado.

La oportunidad comercial consiste en productizar esa economía de servicios: construir una empresa universal de personalización de open source, operada por agentes. A diferencia de una consultora, cada encargo dejaría activos reutilizables —adaptadores, mods, tests e historial de compatibilidad— que reducen el coste del siguiente cambio. La consultoría vende horas; la plataforma convierte cada personalización en software acumulativo.

Estas cifras top-down deben leerse con dos correcciones. Primera: cuando el software sustituye a los servicios, el revenue se comprime típicamente 5–20× —el proyecto de 50.000 € se convierte en una suscripción de 200 €/mes—. Esa compresión es exactamente la propuesta de valor, y significa que capturar “el 80% del trabajo” puede representar el 5–15% de los dólares. Segunda: el sizing accionable es bottom-up —instalaciones self-hosted de las aplicaciones del catálogo, estimables mediante pulls de Docker, bases instaladas de los hosters gestionados y telemetría de los propios proyectos, × tasa de adopción × ARPU; más organizaciones que ya mantienen forks internos de esas aplicaciones × ACV—, con el primer segmento nombrado.

2. Capabilities tecnológicas necesarias

La plataforma tendría que resolver siete capacidades principales.

2.1. Convertir un repositorio en un producto operativo

Dado un repositorio, el sistema debe descubrir:

• cómo instalarlo;
• qué servicios necesita;
• cómo configurar su base de datos;
• cómo ejecutar tests;
• cómo compilarlo;
• cómo crear datos de ejemplo;
• cómo desplegarlo o empaquetarlo;
• cómo observar errores y comportamiento.

El resultado no es simplemente código comprendido por una IA. Es una aplicación reproducible que puede probarse y ejecutarse.

2.2. Comprender dónde introducir modificaciones

Muchos proyectos no disponen de una arquitectura de plugins. La IA debe encontrar los puntos adecuados para intervenir:

• componentes y estilos en frontend;
• funciones y servicios en backend;
• algoritmos sustituibles;
• modelos y migraciones de datos;
• integraciones externas;
• eventos y procesos internos;
• configuración y permisos.

En algunos proyectos bastará con utilizar interfaces existentes. En otros será necesario mantener un pequeño fork adaptador que introduzca hooks y estabilice los puntos de extensión.

A esta capacidad se le puede llamar extensibilidad sintética: hacer que un proyecto se comporte como si fuera extensible, aunque nunca fuera diseñado para ello.

2.3. Convertir una intención en un mod

Una petición como “añade integración con Santander” tiene que transformarse en algo más rico que un diff.

Un mod podría contener:

• descripción de la intención;
• código;
• dependencias;
• configuración necesaria;
• permisos;
• migraciones;
• tests;
• ejemplos y fixtures;
• versiones compatibles;
• conflictos conocidos;
• criterios de validación aportados por el usuario.

El mod sería una unidad de capacidad reproducible, comprobable y potencialmente compartible.

El componente más valioso del mod no es el código sino la especificación ejecutable: los criterios informales del usuario convertidos, durante la creación, en tests no tautológicos, fixtures con datos realistas y casos dorados que él mismo confirma. La capacidad de programar mejora sola en los modelos frontera y llega a todos por igual; la intención capturada en forma comprobable es lo único que ningún modelo puede regenerar. Sin esa especificación, revalidar un mod frente a nuevas versiones es adivinación; con ella, es ingeniería. Elicitar esa especificación —ayudar al usuario a formularla mediante conversación— es producto núcleo, no un paso auxiliar.

2.4. Proporcionar un ciclo conversacional de prueba

El flujo debe estar diseñado para usuarios no técnicos:

1. El usuario explica qué necesita.
2. La plataforma le ayuda a convertir esa necesidad en criterios de aceptación comprobables: ejemplos, casos límite, resultados esperados.
3. La IA implementa una primera versión.
4. La plataforma crea una preview o versión instalable.
5. El usuario la prueba con datos o casos realistas.
6. Explica qué funciona y qué no.
7. La IA corrige el cambio.
8. El usuario lo acepta y lo instala; sus criterios quedan guardados como los tests del mod.

Git, builds, logs y despliegues pueden existir por debajo, pero no deberían formar parte del modelo mental necesario para usar el producto.

2.5. Componer mods de forma segura

Desde la experiencia del usuario, un mod puede parecerse a una feature flag:

Activar “Integración con Santander”.

Por debajo puede implicar aplicar código, instalar dependencias, ejecutar una migración y producir una nueva build.

El sistema debe controlar:

• orden de aplicación;
• dependencias entre mods;
• conflictos de código;
• incompatibilidades funcionales;
• migraciones;
• permisos y secretos;
• regresiones emergentes al combinar varios cambios.

Este es uno de los problemas técnicos más difíciles. Una colección de modificaciones independientes no garantiza que cualquier combinación sea válida.

2.6. Mantener la compatibilidad con upstream

Cuando aparece una nueva versión oficial, la plataforma debe:

1. Actualizar el adaptador común.
2. Comprender los cambios de upstream.
3. Volver a aplicar o materializar los mods.
4. Ejecutar sus pruebas e invariantes.
5. Reparar automáticamente los que fallen.
6. Informar de los que necesiten intervención.
7. Desplegar progresivamente la nueva combinación.

Actualizar el fork principal absorberá parte del cambio, pero no será suficiente. Cada mod necesita conservar su intención y sus pruebas para poder comprobar que continúa funcionando semánticamente.

Operativamente, esto se organiza como trenes de release, al estilo de las distribuciones: la plataforma no persigue cada versión de upstream en tiempo real, sino que anuncia soporte por lotes programados. A cada tren solo suben los mods con instalaciones activas; un mod sin usuarios se congela en su última versión validada, como el orphaning de Debian. La experiencia de actualización de una variante queda determinada por el más lento de sus mods —el min() que conoce cualquier jugador de Minecraft—, y debe diseñarse con tiers y trenes LTS en lugar de descubrirse. Los parches de seguridad viajan por una vía rápida independiente: un CVE de upstream se backportea a las versiones soportadas sin esperar a la revalidación del resto del catálogo.

2.7. Gestionar seguridad, licencias y procedencia

La plataforma debe conocer, para cada combinación:

• licencia del proyecto upstream;
• licencia de cada mod;
• obligación de publicar código;
• compatibilidad entre licencias;
• procedencia del código generado o incorporado;
• vulnerabilidades introducidas;
• permisos solicitados;
• acceso a datos y secretos;
• identidad y reputación del autor.

La licencia debe convertirse en una propiedad calculada del build, no en una revisión legal improvisada al final.

3. Tecnología que ya existe

No hace falta inventar todos los componentes. La oportunidad aparece porque muchas piezas ya funcionan por separado.

3.1. Agentes de programación

Los agentes actuales pueden explorar repositorios, modificar múltiples archivos, ejecutar comandos, observar errores y repetir el ciclo hasta conseguir una build o unos tests satisfactorios.

Lo que falta no es la capacidad elemental de producir un cambio, sino convertirla en un sistema fiable para múltiples proyectos, usuarios y versiones.

3.2. Entornos reproducibles y despliegue automatizado

Contenedores, CI/CD, infraestructura declarativa y plataformas de despliegue ya permiten:

• levantar entornos efímeros;
• crear previews por rama;
• ejecutar tests;
• gestionar bases de datos;
• desplegar aplicaciones web;
• empaquetar aplicaciones;
• hacer rollback.

La plataforma tendría que inferir y unificar estas operaciones para cada proyecto compatible.

3.3. Productos que demuestran partes de la experiencia

Replit demuestra que un usuario puede importar un repositorio, modificarlo mediante un agente y desplegarlo. Sin embargo, trata el resultado fundamentalmente como un proyecto independiente, no como una variante que conserva una relación semántica permanente con upstream y con un catálogo de mods.

Hatchable se aproxima a la experiencia de copiar, modificar y desplegar: un catálogo de apps hechas por creadores sobre su propio stack, copia dura a la cuenta del usuario con infraestructura aislada, y modificación mediante la IA que el usuario ya paga —Claude, Cursor o ChatGPT conectados vía MCP—. No trabaja con repositorios arbitrarios, no conserva relación con upstream y sus licencias de marketplace son propietarias; pero demuestra dos cosas útiles: que la UX de “copiar y pedir cambios” tiene demanda comprobable, y que la inferencia de la creación puede apoyarse en la suscripción de IA del propio usuario.

Cohere ha mostrado que agentes especializados pueden detectar cambios upstream, resolver conflictos, ejecutar evaluaciones y reparar un fork hasta dejarlo operativo.

PostHog Self-Driving demuestra otro componente: observar señales reales del producto, investigar la codebase, implementar una mejora, crear una PR y medir posteriormente su impacto —cobrando por pull request y con revisión humana antes del merge—. Opera sobre el código del propio cliente, no como capa sobre software ajeno.

Herramientas como Frontman muestran que es posible colocar una capa de modificación conversacional directamente sobre la aplicación en ejecución —clicar un elemento y describir el cambio—, hoy limitada a frameworks frontend concretos y, recientemente, a sitios WordPress existentes.

Otras señales del mapa: Forkbase es un concepto en alfa —un marketplace de apps iOS forkeables y operables por agentes, con visión de linaje de forks y royalties de remix—, la formulación pública más parecida a esta, todavía en fase de pitch. Los generadores greenfield siguen sin resolver brownfield real: Lovable, en el mejor de los casos, solo importa repos React/Vite recientes. Los vendors open source absorben y encierran la personalización con IA donde hay dinero: Odoo 19 incorpora agentes nativos y campos de IA en Studio bajo licencia exclusiva de Enterprise. Y la maquinaria de mantenimiento de forks se está comoditizando en abierto: Cohere ha liberado sus skills y existen servidores MCP de paridad con upstream. Ninguna de estas piezas une la cadena completa.

A fecha de agosto de 2026, no hemos identificado un producto que una todas estas piezas alrededor del modelo:

Upstream → adaptador mantenido → mods reutilizables → variantes por usuario → despliegues → mantenimiento continuo.

3.4. Qué puede hacerse hoy

Hoy ya parece viable construir el producto para un catálogo limitado de proyectos que cumplan condiciones como:

• aplicación web o desktop bien empaquetada;
• licencia clara;
• tests razonables;
• Docker o proceso de instalación reproducible;
• arquitectura comprensible;
• tamaño moderado;
• comunidad con necesidades visibles.

Lo que todavía no parece razonable es prometer compatibilidad universal y mantenimiento totalmente autónomo para cualquier repositorio.

4. Definición de la solución

La solución es una capa de modding asistida por IA para software open source existente.

Su arquitectura conceptual tendría cuatro niveles:

Upstream

El repositorio y las releases oficiales continúan bajo el gobierno de sus mantenedores.

Adaptador del proyecto

Una capa mantenida por la plataforma conoce cómo instalar, probar, desplegar y modificar ese proyecto. Puede materializarse como un fork ligero, una colección de hooks, recetas de build o una combinación de mecanismos.

Su función no es decidir cómo debería ser una “versión comunitaria”. Su función es convertir el proyecto en una base operativamente modificable.

Mods

Cada mod representa una capacidad independiente:

• integración con un banco;
• modo oscuro;
• cambio en un algoritmo;
• soporte para un formato científico;
• autenticación corporativa;
• nuevo gráfico;
• modificación de un workflow.

Los mods pueden ser públicos, privados, gratuitos o comerciales, siempre que sus licencias sean compatibles.

Variante

La versión utilizada por una persona u organización es:

Release upstream + adaptador compatible + selección de mods + configuración privada.

No tiene por qué existir una única versión comunitaria. Lo compartido es el sistema de adaptación y el catálogo de capacidades; la aplicación final puede ser diferente para cada usuario.

Dos niveles de operación

Sobre esta arquitectura, el producto distingue dos niveles.

El modo abierto permite apuntar la plataforma a cualquier repositorio compatible y obtener la experiencia completa de creación —instancia, preview, ciclo conversacional— con la etiqueta honesta de “sin mantenimiento garantizado”. Es barato de ofrecer, porque envuelve lo que los agentes ya saben hacer; expresa la misión en el producto; y genera la telemetría que importa: qué aplicaciones intenta modificar la gente realmente.

El catálogo certificado contiene los proyectos con adaptador mantenido, trenes de release, revalidación de mods y garantías firmables. Empieza pequeño y crece por señal de demanda del modo abierto, no por opinión.

5. Experiencia de producto

La experiencia ideal elimina el vocabulario de ingeniería.

Descubrimiento

El usuario encuentra una aplicación open source dentro del catálogo o proporciona un repositorio compatible.

Instalación

La plataforma crea una instancia funcional con datos de ejemplo o importa los datos del usuario.

Petición

El usuario describe una necesidad:

“La herramienta de medición falla cuando la planta tiene poco contraste respecto al fondo.”

Implementación

La IA investiga la aplicación, encuentra el punto de intervención y genera una modificación.

Validación

El usuario recibe una preview realista, utiliza sus propios casos y conversa con la IA hasta validar el comportamiento.

Instalación del mod

El cambio queda guardado como una capacidad activable. El sistema genera una variante estable y la despliega o empaqueta.

Publicación o privacidad

En Community, el mod puede publicarse junto con sus tests y documentación sanitizada. En Enterprise puede permanecer dentro de la organización, dentro de los límites de la licencia upstream.

Mantenimiento

Cuando cambia upstream, la plataforma comprueba y repara el adaptador y los mods, y permite probar la nueva combinación antes de actualizar producción.

6. Visión de producto

En la versión final del producto, cualquier persona puede elegir una aplicación open source, desplegar una instancia funcional y modificarla mediante una conversación.

El usuario no necesita conocer repositorios, ramas, builds ni despliegues. Describe lo que quiere, recibe una versión realista, la prueba con sus propios casos y continúa iterando hasta aceptarla. El cambio queda encapsulado como un mod mantenible que puede permanecer privado o publicarse en un catálogo.

Cada proyecto compatible dispone de un adaptador que conserva la relación con upstream. Cada persona u organización utiliza una variante compuesta por la versión oficial, los mods que ha elegido y su configuración privada. Cuando upstream cambia, la plataforma vuelve a validar esa combinación, repara automáticamente lo que puede y solicita intervención solo cuando no puede demostrar que la intención original sigue cumpliéndose.

Alrededor de cada proyecto existe un ecosistema de capacidades: mods públicos y privados, compatibilidad conocida, autores y validadores reputados, combinaciones recomendadas y peticiones financiables. Los cambios populares pueden terminar incorporándose upstream, pero no necesitan ser aceptados por los mantenedores para resultar útiles.

La visión final es:

Cualquier persona puede convertir una necesidad legítima en una versión funcional del software que ya utiliza, sin pedir permiso, aprender Git ni convertirse en mantenedora del proyecto.

7. Modelo de negocio

Community: pagar contribuyendo

La versión Community ofrece acceso gratuito o subvencionado a cambio de que los mods creados sean públicos.

Puede incluir:

• catálogo público;
• generación limitada;
• previews y despliegues personales;
• publicación del código del mod;
• tests y documentación públicos;
• mantenimiento compartido.

Datos, secretos, credenciales y contenido del usuario permanecen siempre privados.

La inferencia de la creación en Community puede apoyarse en la suscripción de IA que el usuario ya paga —Claude, ChatGPT o Cursor conectados a la plataforma—, de modo que el tier gratuito no subvenciona generación. Lo que Community no cubre es la revalidación perpetua: los mods públicos viajan en los trenes de release mientras tengan instalaciones activas, y se congelan en su última versión validada cuando dejan de tenerlas.

Enterprise: pagar por privacidad y garantías

Enterprise permite:

• mods no publicados;
• workspaces y catálogos internos;
• despliegues aislados;
• integración con repositorios privados;
• SSO, permisos y auditoría;
• políticas de seguridad;
• soporte y SLA;
• validaciones personalizadas;
• despliegue en infraestructura del cliente;
• mantenimiento garantizado de combinaciones concretas.

La promesa debe formularse como “modificaciones no publicadas” y no siempre como “código privativo”. Licencias como GPL o AGPL pueden conceder derechos sobre el código a sus destinatarios aunque la plataforma no lo publique globalmente.

Las garantías contractuales se limitan a propiedades verificables mecánicamente: la variante construye y arranca, sus migraciones son reversibles, sus tests declarados pasan y los parches de seguridad de upstream están backporteados. La preservación semántica de la intención se ofrece como best-effort explícito, nunca como SLA. Dentro de lo firmable, la oferta enterprise más demostrada del espacio es el mantenimiento de seguridad de variantes modificadas —incluso congeladas en versiones antiguas—: la categoría que Ubuntu Pro, TuxCare o HeroDevs han probado vendible.

Personal y empresarial

La misma infraestructura sirve para dos formas de uso:

• Software personal: individuos que adaptan herramientas open source a necesidades de productividad, investigación, automatización o creación. El valor principal es la personalización inmediata sin fricción técnica.
• Software empresarial: organizaciones que necesitan privacidad, integración con sistemas internos, gobernanza, seguridad y garantías de mantenimiento.

Modelo económico

Una estructura posible combina:

• suscripción por organización o usuario;
• cuota por aplicación gestionada;
• consumo de agentes y builds;
• infraestructura y despliegues;
• nivel de mantenimiento o SLA;
• comisión sobre mods comerciales, más adelante.

El valor no debería medirse principalmente por asiento de desarrollador, porque la tesis consiste precisamente en ampliar el acceso más allá de ingeniería.

Flywheel

El modo abierto alimenta la entrada: la telemetría de qué aplicaciones intenta modificar la gente decide qué proyectos se certifican a continuación.

1. Los usuarios Community crean mods públicos.
2. El catálogo hace que nuevos usuarios encuentren el producto.
3. Esos usuarios prueban y mejoran los mods.
4. La plataforma acumula datos de compatibilidad y reparación.
5. Las empresas consumen el catálogo público.
6. Pagan por privacidad, seguridad y garantías.
7. Parte de sus mejoras genéricas puede volver voluntariamente a la comunidad.

Moat

El principal activo no sería el modelo de IA, que puede commoditizarse. Sería el grafo acumulado de:

• proyectos;
• releases;
• recetas de instalación;
• puntos de extensión;
• mods;
• dependencias;
• conflictos;
• tests;
• resultados de builds;
• reparaciones históricas;
• compatibilidad;
• patrones de uso.

Cada modificación hace que el sistema comprenda mejor cómo evolucionar ese proyecto y otros parecidos.

A ese grafo se suma un activo de marca concreto y construible: ser el firmante de confianza de los mods —proveniencia verificada, builds reproducibles, cadena de suministro auditable—, el papel que Docker Official Images o F-Droid desempeñan en sus ecosistemas. La arquitectura es copiable el día que se entiende; el grafo acumulado y la confianza ganada, no.

8. Growth hacks

8.1. Convertir GitHub Issues en software ejecutable

Las issues públicas contienen demanda explícita y estructurada. La plataforma puede identificar aquellas que:

• llevan tiempo abiertas;
• tienen reacciones o comentarios;
• describen un resultado comprobable;
• son suficientemente acotadas;
• no han sido priorizadas por el mantenedor.

El flujo de growth sería:

1. Seleccionar una issue relevante.
2. Generar una implementación como mod.
3. Ejecutar tests.
4. Crear una preview pública.
5. Publicar una página explicando el cambio.
6. Permitir instalar esa versión con un clic.
7. Ofrecer el resultado al proyecto original como PR cuando tenga sentido.

La unidad de marketing no sería una promesa, sino software funcionando:

“Esta issue lleva dos años abierta. Aquí puedes probar una versión que ya la resuelve.”

Debe evitarse automatizar comentarios promocionales o generar ruido en repositorios. Solo debería contactarse al proyecto cuando exista una solución real, útil y correctamente atribuida.

La selección de objetivos importa tanto como la ejecución. Las issues adecuadas pertenecen a proyectos abandonados, en modo mantenimiento o propiedad de corporaciones, donde la frustración del usuario pesa más que la simpatía por el mantenedor. Resolver públicamente el backlog de un mantenedor individual y activo produce el efecto contrario; y el canal de distribución de este producto —Hacker News, GitHub, la comunidad developer— es la misma población que decide quién es el villano de esa historia.

8.2. Catálogo de mods y búsqueda long tail

Cada mod resuelve una búsqueda muy específica:

• “PostHog con integración Looker”.
• “Herramienta de facturación con integración con Banco Santander”.
• “Aplicación científica con medición de bajo contraste”.
• “GetNao con dashboards”.
• “Proyecto X con SSO”.
• “Proyecto Y con modo oscuro”.

Estas páginas tienen valor si contienen:

• una implementación real;
• capturas o demo;
• versiones compatibles;
• tests;
• instrucciones de instalación;
• historial de mantenimiento;
• botón de despliegue.

El objetivo no sería producir SEO programático vacío, sino indexar una oferta real de software modificable.

8.3. Compartir el resultado

Cada versión pública puede incluir:

• página del mod;
• preview;
• botón “Instalar en mi versión”;
• repositorio o código;
• badge de compatibilidad;
• enlace al proyecto original;
• autor y validadores;
• historial de builds.

Esto convierte cada modificación en una posible puerta de entrada al producto.

8.4. Colaboración con mantenedores

Los mantenedores pueden beneficiarse si la plataforma:

• reduce issues repetidas;
• genera implementaciones y tests;
• identifica demanda real;
• permite graduar mods populares a upstream;
• deriva contribuciones útiles;
• respeta atribución y marcas;
• permite reclamar y administrar la página de su proyecto;
• comparte ingresos cuando corresponda.

La narrativa no debe ser “los mantenedores son lentos”. Debe ser:

“La versión oficial no puede absorber todas las necesidades. Esta capa permite experimentarlas sin transferir inmediatamente su coste y riesgo a upstream.”

Esta relación debe ser política operativa con presupuesto, no narrativa: porcentaje de ingresos por proyecto que se paga de verdad desde el primer euro, páginas reclamables y administrables por sus mantenedores, opt-out que se honra sin fricción y renombrado sistemático conforme a las políticas de marca de cada proyecto. La ola de relicenciamientos de 2018–2024 demuestra que el TAM de esta plataforma es contraíble por sus propios objetivos: una cláusula de licencia basta para sacar un proyecto del catálogo. La única defensa duradera es que a los mantenedores les convenga que la capa exista.

8.5. Bounties y demanda agregada

Los usuarios podrían solicitar o financiar mods. Varias personas interesadas en la misma capacidad pueden agregar demanda hasta justificar su desarrollo y mantenimiento.

Esto transforma las issues en un mercado de necesidades verificables.

9. Analogías

Analogías en una frase

Estas formulaciones no describen el producto por completo, pero permiten explicarlo rápidamente desde distintos ángulos:

• Proton for extensibility. Igual que Proton hace que juegos nunca diseñados para Linux corran en Linux, esta capa hace que software nunca diseñado para modificarse se comporte como si fuera extensible. Proton por debajo, Workshop por encima.
• Steam Workshop for open-source software. Una base oficial y un catálogo de mods que cada usuario puede combinar e instalar. La diferencia es que la IA crea también la arquitectura de modding cuando el proyecto original no la tiene.
• Replit standing on the shoulders of giants. La experiencia conversacional de crear y desplegar software, pero empezando sobre aplicaciones maduras en lugar de partir de una página en blanco.
• The universal open-source consultancy, run by agents. Una única plataforma capaz de instalar, integrar, personalizar y mantener cualquier proyecto compatible, convirtiendo trabajo de consultoría en software reutilizable.
• An app store for software that never had an app store. Un catálogo de capacidades para productos que nunca fueron diseñados para aceptar plugins.
• Feature flags for code you do not own. Desde la experiencia del usuario, modificar una aplicación se parece a activar capacidades; por debajo, la plataforma transforma, prueba, compila y mantiene código.
• A personalized Linux distribution for every application. Upstream aporta la base; la plataforma empaqueta, combina y mantiene una distribución distinta para cada persona u organización.

Proton

Es la analogía más precisa estructuralmente.

Proton hace que software que nunca fue diseñado para correr en Linux se comporte como si lo fuera: portabilidad sintética, mantenida por un tercero —Valve— porque el upstream —los estudios— no tenía incentivos para hacer los ports. El camino “convencer al desarrollador” se intentó durante años y fracasó; la capa ganó tan claramente que hoy muchos estudios ni publican build nativa. Es una década de evidencia de la asimetría descrita en la sección 1.5.

Su historia contiene además el patrón de lanzamiento: en 2018, una whitelist de juegos soportados más un checkbox para intentar cualquier otro bajo responsabilidad del usuario; después ProtonDB como telemetría comunitaria de compatibilidad; y la certificación Deck Verified como UX de primera clase solo cuando llegó una audiencia no técnica. Nadie interpretó la whitelist inicial como falta de ambición: el checkbox era la misión presente en el producto; la lista, la credibilidad. Y contiene el moat: el valor de Proton no es Wine, que es abierto y copiable, sino el grafo acumulado de rarezas por título, parches específicos y años de trabajo financiado de forma sostenida.

Dos diferencias honestas. Valve ya poseía la tienda —distribución y capital para financiar una capa horizontal sin que fuera negocio en sí misma—; aquí el catálogo certificado debe ser a la vez la prueba de confianza y la cuña de ingresos. Y Proton no toca el código del juego: reimplementa la plataforma debajo de un binario intacto, mientras que esta capa modifica el código mismo de un objetivo que se mueve, lo que la hace más invasiva y más frágil por release. Siempre existirá, además, una columna Borked: proyectos cuya arquitectura o licencia resiste estructuralmente la capa.

Mods de videojuegos

Es la analogía más intuitiva.

Un juego conserva una base oficial, mientras su comunidad crea mapas, reglas, interfaces y nuevas capacidades. Cada jugador elige qué instalar. Steam Workshop aporta descubrimiento, instalación y actualización.

La diferencia fundamental es que los videojuegos suelen ofrecer alguna arquitectura de modding. Aquí, la IA debe descubrir o crear esos puntos de extensión incluso cuando el proyecto original no los proporciona.

La ambición puede expresarse como:

Un Steam Workshop para software open source, donde la IA construye también la arquitectura de modding.

Community Editions y forks comunitarios

Una Community Edition tradicional suele ser una edición gratuita controlada por la misma empresa. Un fork comunitario clásico aparece cuando un grupo rompe con el proyecto original y asume su mantenimiento.

Este producto no pretende crear una versión comunitaria canónica.

El adaptador común sigue upstream; los mods contienen las decisiones particulares. El fork deja de representar un cisma y pasa a ser una operación normal de personalización.

Distribuciones Linux

Una distribución toma multitud de proyectos upstream y se responsabiliza de empaquetarlos, integrarlos, actualizarlos y hacerlos funcionar conjuntamente.

Esta plataforma realizaría algo parecido a escala de cada aplicación:

• sigue upstream;
• normaliza instalación y despliegue;
• aplica una capa de compatibilidad;
• mantiene variantes;
• distribuye capacidades adicionales.

Extensiones de navegador

Las extensiones permiten cambiar la experiencia de un producto sin esperar a que su propietario incorpore cada necesidad.

La diferencia es que aquí los mods podrían afectar también backend, datos, algoritmos, integraciones y empaquetado, no solo la interfaz visible.

GitHub público y privado

GitHub demostró un modelo sencillo de entender:

• el trabajo público beneficia al ecosistema;
• la privacidad tiene valor económico.

Aplicado aquí:

• Community crea mods públicos a cambio del uso de la infraestructura.
• Enterprise paga para mantener sus modificaciones dentro de la organización.

App stores y marketplaces

Un catálogo de mods aporta descubrimiento, reputación, instalación y distribución. Sin embargo, el objetivo no es solo vender plugins escritos manualmente. La plataforma permite que cualquier necesidad se convierta primero en un mod mediante IA.

10. Qué no es este producto

No es simplemente:

• un IDE con IA;
• un generador de aplicaciones desde cero;
• una plataforma de hosting;
• un bot que abre pull requests;
• un servicio tradicional de mantenimiento de forks;
• una tienda de plugins preexistentes;
• una única Community Edition de cada proyecto;
• una capa limitada al frontend.

La diferencia está en mantener la relación entre cuatro elementos:

Proyecto original + intención del usuario + mod verificable + versión operativa.

11. Riesgos principales

Compatibilidad universal

Los repositorios varían enormemente en lenguaje, arquitectura, documentación, tests, build y requisitos operativos. El producto deberá comenzar con un catálogo seleccionado.

Explosión combinatoria

Dos mods que funcionan por separado pueden fallar al combinarse. Será necesario limitar, probar y puntuar combinaciones.

Deriva semántica silenciosa

Los tests que sintetiza el mismo agente que escribió el mod tienden a ser tautológicos: codifican la implementación, no la intención. La reparación automática combinada con invariantes débiles produce mods que pasan sus pruebas y ya no hacen lo que el usuario quería — el fallo invisible hasta que cuesta datos o dinero. La mitigación es la especificación ejecutable elicitada del usuario en la creación (sección 2.3); su calidad debe medirse, no asumirse.

Rotura correlacionada del adaptador

El adaptador es una API que upstream no sabe que existe. Cuando un refactor interno la rompe, todos los mods que cuelgan de ese hook fallan a la vez. El gating por trenes de release convierte el incendio en proceso, pero el adaptador permanece en el camino crítico de cada versión.

Seguridad

Un usuario puede validar que una funcionalidad hace lo esperado sin detectar vulnerabilidades, pérdida de datos o accesos indebidos. La plataforma necesitará sandboxing, análisis, permisos explícitos y una cadena de suministro verificable.

Licencias y marcas

No todos los proyectos permiten los mismos tipos de modificación, distribución o uso de marca. Cada build necesitará una evaluación automática de obligaciones. El precedente 2018–2024 añade un riesgo específico: el relicenciamiento defensivo. Un proyecto puede excluir servicios automatizados de modificación con una cláusula, a coste cero para él; la relación con mantenedores (8.4) es la única mitigación real.

Economía de agentes

Si cada cambio exige horas de inferencia, revisión humana e infraestructura, el producto puede convertirse en una consultora encubierta. La reutilización de adaptadores, mods, tests y reparaciones es esencial para mejorar los márgenes. El coste dominante no es la creación sino la revalidación perpetua del catálogo; el mantenimiento dirigido por demanda —solo viajan en el tren los mods con instalaciones activas— es la condición de solvencia.

Relación con upstream

Un posicionamiento hostil hacia los mantenedores dañaría la distribución. La plataforma debe presentar los mods como un complemento a su gobierno, no como un intento de apropiarse del proyecto.

Validación por usuarios noveles

La experiencia debe ayudar a formular criterios de aceptación y reconocer cuándo una prueba es insuficiente. “El usuario lo ha probado” no puede ser la única garantía.

Secuenciación

El producto completo contiene tres negocios: infraestructura de adaptadores, producto conversacional y marketplace. Vercel, Cloudflare o Replit son hoy muchas empresas, pero todas empezaron ganando una sola cuña. Intentar los tres frentes simultáneamente en etapa seed diluye la ejecución; la cuña abre las otras dos, y el orden es una decisión, no un detalle.

12. Tesis final

La apuesta no es únicamente que los modelos frontera escribirán más código.

La apuesta completa es:

1. Modificar codebases existentes será cada vez más barato y accesible.
2. La fiabilidad procederá de ciclos de implementación, ejecución, observación y reparación.
3. La capacidad de generar cambios crecerá más rápido que la capacidad de los proyectos para incorporarlos.
4. Una única versión canónica no puede satisfacer todas las necesidades válidas.
5. Las modificaciones podrán convertirse en unidades reutilizables y distribuibles.
6. Los usuarios podrán validar cambios gracias a su conocimiento del problema, aunque no conozcan la arquitectura.
7. Hará falta una nueva capa que convierta la divergencia en algo seguro, reversible y mantenible.

La oportunidad empresarial consiste en construir esa capa.

El software del futuro no se entregará únicamente como una versión cerrada y común para todos. Se entregará como una base funcional acompañada de una capacidad permanente de adaptación.

Dicho de otro modo: el open source concedió el derecho a modificar. Esta capa entrega la capacidad.

La empresa que consiga que cualquier proyecto existente pueda modificarse, probarse, desplegarse y mantenerse como un conjunto de mods habrá convertido el desarrollo asistido por IA en algo más grande que una herramienta para programadores: lo habrá convertido en una nueva forma de distribuir software.