¿Qué viene después del código abierto?
El futuro del código abierto no es el que imaginábamos hace cinco años. Las licencias copyleft perdieron terreno frente a Apache y MIT, los mantenedores están quemados, la IA generativa metió ruido legal en todas partes, y las empresas redescubrieron que el open source es solo parte de un negocio híbrido mucho más complejo. Según análisis de RedMonk sobre licencias en 2026, estamos ante un cambio estructural profundo que redefine qué significa “código abierto” en 2026.
En 30 segundos
- Las licencias permisivas (Apache, MIT) superan a copyleft (GPL) desde 2022, con ~30% de adopción en Apache y crecimiento sostenido.
- El 53% de empresas elige open source por reducción de costos, pero el 70% de ellas pagará soporte empresarial o servicios (no código gratis).
- La IA generativa entrenada en código abierto abrió preguntas legales sin respuesta: ¿quién posee lo que genera un modelo?
- Nuevos modelos de negocio van del open source puro a dual licensing, soft licensing y servicios en la nube.
- El 2026 marca un giro ideológico: open source como infraestructura regulada + talento profesional, no como hobby comunitario.
El código abierto es software cuyo código fuente está disponible públicamente para modificar y redistribuir bajo licencias específicas que definen qué se puede y qué no se puede hacer. Pero “código abierto” hoy no es más sinónimo de “gratis” ni de “sin restricciones”: el término cubre un espectro que va desde GPL puramente copyleft hasta licencias tan permisivas que casi parecen privativo con ingredientes abiertos.
El boom del open source y sus limitaciones actuales
Hace unos años, el open source era la panacea. “Si es gratis y cualquiera puede contribuir, tiene que ser mejor”, era el argumento. Y bueno, en muchos casos funcionó: Linux, Apache, PostgreSQL, Node.js. Las empresas economizaban, compartían riesgo de desarrollo, reclutaban talento. Según el blog oficial de GitHub sobre 2026, el 53% de las empresas sigue eligiendo open source básicamente por reducción de costos.
Pero el limón se exprimió. Hoy el problema es brutal: los mantenedores están quemados. Uno o dos desarrolladores mantienen librerías críticas en las que dependen millones de líneas de código en el mundo, todo mientras trabajan en su casa y reciben cero pesos. La calidad se resiente.
El 2025 fue el año del “AI slop” invadiendo repositorios (bots que generar código mediocre, prs automatizadas que nadie revisaba, ruido que asfixia a los proyectos genuinos). Y seguridad, olvídate: vulnerabilidades descubiertas años después porque nadie auditaba nada. Hay librerías open source que usás en producción cuyo último commit es de 2019. Sí, en serio.
El gran cambio: licencias permisivas deplazan copyleft
Acá viene lo que explica todo lo que cambió desde 2022. GPL y sus hermanas copyleft (AGPL, LGPL) tenían un principio noble: si usás código bajo GPL, tu código también tiene que ser GPL. Compartir, colaborar, el software debe ser libre. El problema es que las empresas odiaban esto. ¿Por qué? Porque no querían open sourcear su propia propiedad intelectual solo por usar una librería.
Entonces pasó algo lógico: migraron masivamente a Apache 2.0 y MIT. Licencias permisivas que dicen “usá esto como quieras, en privado o comercialmente, sin obligaciones”. El efecto fue demoledor para copyleft. En 2022, Apache ya pasaba el 30% de adopción entre proyectos nuevos, y la curva de GPL se desplomaba. Los datos de OpenLogic sobre tendencias en open source confirman que esta tendencia se aceleró en 2026.
Ejemplos concretos: Redis cambió de licencia en 2024 (ya no BSD, ahora Elastic License), Elastic hizo lo mismo (no AGPL, ahora Elastic License con restricciones comerciales). Meta lanzó Llama bajo una licencia específica que prohíbe entrenamiento de IA competidora. Todos pragmatismo, ninguno idealismo. Si te preguntas por qué: porque las empresas descubrieron que distribuir código gratis bajo GPL no es un modelo de negocio sostenible.
IA generativa y la crisis legal del open source
Esto es lo que mantiene despierto a cualquier equipo legal serio. Ponele que alguien usó código open source bajo GPL para entrenar un modelo de IA, y ese modelo genera código nuevo. ¿De quién es ese código generado? ¿Hereda la licencia GPL? ¿O el modelo es libre porque la GPL no cubre artefactos derivados de IA? La verdad es que nadie sabe. Lo explicamos a fondo en ejecutar agentes sin dependencias externas.
GitHub Copilot fue el primer detonante. “Entrenamos con código open source”, dijeron, “así que nos debe obligación de transparencia”, reclamaron mantenedores. Juicio, controversia, todo un caos. Llama y Mistral vinieron después y directamente metieron restricciones: “no podés usar esto para entrenar otro modelo que nos compita”. Explicable, pero también medio contradictorio para quien dice defender lo abierto.
Ahora estamos en un limbo legal sin respuesta clara. El software abierto entrenó LLMs. Los LLMs generan código. Ese código, ¿a quién le pertenece? ¿Qué licencia tiene? ¿Puedo distribuirlo bajo cualquier licencia que quiera? Los proyectos grandes (Linux Foundation, Apache Software Foundation) están tratando de meter orden, pero no hay consenso todavía.
Nuevos modelos de negocio: más allá de GPL gratuito
Acá es donde empezá a ver el futuro. Las empresas que mantienen open source grande se dieron cuenta de que el modelo “código gratis + esperar donaciones” no escala.
El primero que se validó fue dual licensing: código abierto bajo copyleft para uso no comercial, pero si querés usarlo en empresa, pagás licencia propietaria. MySQL fue el pionero, Elastic lo adoptó, Redis también. Funciona porque los usuarios individuales obtienen lo gratis, las corporaciones pagan.
El segundo es soft licensing: código visible pero con restricciones. No es GPL, no es MIT. Es “podés ver, podés usar, pero no podés ofrecer servicios cloud competidor” (como hace Elastic ahora). O “podés usarlo, pero el uso comercial requiere licencia empresarial” (como Jetbrains). Ambigua, pero pragmática.
El tercero es directo: servicios premium + soporte. Código abierto 100%, pero la mayoría de usuarios va a pagar por hosting gestionado, soporte 24/7, training, y consultoría. Según datos de la industria, el 70% de las empresas que usan open source en producción pagan por algún tipo de soporte o servicios relacionados. Ese es el dinero verdadero. Más contexto en consideraciones de privacidad en plataformas.
Infraestructura y cumplimiento regulatorio como prioridad
Aquí hubo un giro conceptual importante. Open source pasó de “libertad del desarrollador” a “infraestructura crítica”. La DORA en Europa, las regulaciones de cadena de suministro de software en EE.UU., la presión de gobiernos pidiendo auditoría de código abierto por temas de seguridad nacional. De repente, el open source no es un hobby de nerds. Es infraestructura de estado.
Eso es un cambio de paradigma enorme. Ya no alcanza “es gratis, así que lo usamos”. Ahora las empresas grandes (y gobiernos) dicen “necesitamos saber exactamente qué versión usamos, quién lo mantiene, qué vulnerabilidades tiene, qué licencia es”. La trazabilidad, auditoría, compliance y responsabilidad son no negociables. Ubuntu observa que esta tendencia regulatoria se aceleró en 2026.
Linux Foundation y Core Infrastructure Initiative están financiando directamente proyectos críticos no porque sean revolucionarios, sino porque la infraestructura global depende de ellos. 2026 es el año donde eso se aceleró. Presupuestos que antes iban a “desarrollar propio” ahora van a “financiar proyectos open source críticos” porque es más barato, más rápido, y menos riesgoso que hacer todo from scratch.
El futuro híbrido: open source + servicios cloud comerciales
El modelo que se está validando es tan simple que casi lo pasás por alto: código abierto + servicios nube pagos. The New Stack identificó esto como tendencia dominante: el open source es el moat, el diferenciador competitivo. Vos desarrollás el código abierto (reclutas colaboradores, construís comunidad), pero lo que cobrás es el servicio alojado en tu nube.
Ejemplo real: HashiCorp (Terraform, Consul). Código abierto bajo licencia BSL (Business Source License). Si lo querés en la nube pública, pagás. Si lo querés en tu infra privada, es gratis. Otro: Grafana. Código abierto, pero el servicio SaaS (hosting, backups, escalabilidad) sale dinero. El patrón es consistente.
Para startups, esto es un golazo. Conseguís tracción rápido (código abierto, usuarios crecen), conseguís datos de adopción (quién lo usa, cuán activamente), y te lo monetizás después con la nube o soporte. Es más inteligente que vender licencias perpetuas como hace años.
El talento técnico como activo más valioso
Está pasando algo que medio no vemos pero que es crítico: el futuro del open source depende de si hay desarrolladores dispuestos a mantenerlo. La crisis de mantenedores es real. Hay 1 persona manteniendo librerías que usan 10 millones de desarrolladores. Ese ratio no es sostenible.
El 2025 fue el año donde la comunidad se dio cuenta: al meter IA en los repos, los PRs aumentaron 3x pero el signal-to-noise fue terrible, más trabajo para mantenedores, no menos. Entonces Linux Foundation empezó a hacer grants directos a mantenedores. “Te vamos a pagar un sueldo porque tu proyecto es crítico”. No es caridad, es inversión en infraestructura. Cubrimos ese tema en detalle en herramientas de IA descentralizadas.
Mirá: si hay dinero en el flujo (grants, licencias duales, servicios, dual licensing), empieza a haber especialistas. No voluntarios quemados trabajando de noche. Profesionales que se despiertan a las 9, abren su laptop, trabajan en open source 8 horas, y cobran un sueldo. Eso es 2026: open source como profesión, no como hobby.
| Modelo | Licencia típica | Uso comercial | Restricción principal | Cómo se monetiza |
|---|---|---|---|---|
| Puramente abierto | MIT, Apache 2.0 | Sí, ilimitado | Ninguna | Donaciones, soporte |
| Copyleft tradicional | GPL v3 | Sí, si derivado es GPL | Deben liberar cambios | Dual licensing |
| Dual licensing | GPL + propietaria | Pagado (propietaria) | Gratis bajo GPL solamente | Licencias empresariales |
| Soft licensing | Elastic, BSL | Restringido (no cloud competidor) | Uso cloud requiere pago | SaaS + licencias empresariales |
| Código abierto + SaaS | MIT/Apache + ToS | Sí, si hosting es tuyo | Servicios nube pagos | Cloud hosted + premium tiers |
Errores comunes al elegir open source en 2026
Asumir que “open source = seguro por definición”
No. Open source significa que el código es visible. Eso aumenta las chances de encontrar vulnerabilidades, sí. Pero no significa que nadie las audite. Un proyecto mantenido por 1 persona, sin fondos, sin CI/CD robusto, puede estar plagado de agujeros de seguridad. Visible ≠ seguro. Lo seguro es tener recursos para mantenerlo bien.
Pensar que el costo es solo el código
El costo verdadero es la integración, el mantenimiento, el soporte cuando se rompe a las 3 de la mañana. Si usás una librería open source en producción y el mantenedor no resuelve un bug crítico en 6 meses, vos tenés que o pagar a alguien para que lo arregle o forkear y mantenerlo propio. Ese costo, agregado, puede ser mayor al de una solución comercial completa.
Creer que podés mantener un fork grande sin dolor
Claro, técnicamente sí. Pero mantener activamente un fork cuesta. Si el upstream sigue evolucionando, vos tenés que mergear cambios constantemente. Si diverge mucho, te perdes beneficios, correcciones de seguridad, nuevas features. La deuda técnica de un fork muerto crece exponencialmente.
Preguntas Frecuentes
¿Las licencias copyleft como GPL están desapareciendo?
Está perdiendo mercado frente a permisivas, sí. De 30% en 2022 a datos de 2026 sugieren que GPL está alrededor del 20-25%. Pero “desaparecer” es fuerte. Sigue siendo hegemónica en infraestructura crítica (Linux kernel, GCC, etc.) y en proyectos que defienden la filosofía de libertad. Lo que pasó es que las empresas que necesitaban flexibilidad migraron a Apache/MIT, así que el peso de copyleft en “nuevos proyectos” bajó considerablemente.
¿Se puede ganar dinero con un proyecto open source?
Totalmente. Los modelos que funcionan son: dual licensing (código abierto + licencia paga), servicios SaaS (código abierto + hosting gestionado pagado), soporte empresarial (el código es gratis, el soporte sale dinero), y grants de instituciones. No va a hacer rico a nadie, pero si mantenés algo suficientemente valioso, hay ingresos reales. Lo que NO funciona es esperar donaciones de usuarios. Te puede servir nuestra cobertura de alternativas a las plataformas dominantes.
¿Cómo afecta la IA generativa al código abierto?
De dos formas. Una positiva: herramientas como Copilot te ayudan a escribir código más rápido, incluso aprendiendo patterns de open source. Una negativa: el entrenamiento de LLMs con código abierto plantea preguntas de propiedad intelectual sin respuesta clara (si el modelo genera código, ¿quién lo posee?). Para 2026, la tendencia es que las licencias se vuelvan más restrictivas con respecto a IA (no podés entrenar competidores). Es un cambio ideológico.
¿Qué licencia debo elegir para mi proyecto open source nuevo?
Depende del objetivo. Si querés máxima adopción y no te importa quién lo use, MIT o Apache 2.0 (permisivas). Si querés que los derivados también sean libres, GPL. Si es un negocio y querés monetizar SaaS, algo como BSL (Business Source License) o dual licensing. Pero honestamente, si es un hobby sin presión de monetización, MIT es lo más simple: “hacé lo que quieras, sin garantía de nada”.
¿Es viable mantener un proyecto open source grande?
Depende de tu definición de viable. Sin financiamiento externo, es cada vez más difícil. Tienes que elegir: dedicarle 4-5 horas semanales sueltas (insostenible a largo plazo, el proyecto se muere lentamente), o pagarle a alguien para que lo haga (dinero de dónde). El cambio de 2026 es que proyectos grandes buscan financiamiento institucional activamente. Si tienes algo crítico, hay grants. Si es pequeño o nicho, acepta que va a crecer lentamente y reclutar colaboradores es difícil.
Qué está confirmado y qué no en 2026
Confirmado
- Apache y MIT superan a GPL en adopción entre proyectos nuevos (confirmado por múltiples reportes de 2025-2026).
- El 53% de empresas usa open source por reducción de costos (dato del State of Open Source 2025).
- Dual licensing y SaaS + open source son modelos viables y en crecimiento (Redis, Elastic, HashiCorp, Grafana todos usan variantes).
- Crisis de mantenedores es real y acelerada por AI slop en 2025 (reportado por múltiples fuentes).
- Regulación de cadena de suministro de software es política activa en EU y EE.UU. (DORA, regulaciones de seguridad nacional).
Pendiente / Ambiguo
- Ownership legal de código generado por LLMs entrenado en código abierto (sin resolución clara, solo debates y propuestas).
- Licencia estándar para proyectos open source + IA (hay propuestas, no hay consenso de industria todavía).
- Cuánto dinero real fluye de grants institucionales hacia mantenedores (algunos datos, pero no transparencia completa).
- Si el modelo SaaS + open source será suficiente para sostener infraestructura crítica de largo plazo (en prueba, parecería funcionar pero es temprano).
Conclusión
El futuro del código abierto no es ni puro idealismo ni capitalismo puro. Es híbrido. Código abierto como herramienta de negocio, como infraestructura regulada, como talento profesional. Las licencias evolucionan, los modelos se pragmatizan, y la idea de que “open source es libre = gratis” desapareció.
Lo que importa ahora es entender que open source es solo una parte de una estrategia más grande. Puede ser tu moat (diferenciador competitivo), tu reclutador de talento, tu herramienta de investigación, o tu servicio de pago con cloud. Pero no es un fin en sí mismo. Eso es el cambio de 2026: del purismo ideológico a la pragmática del negocio.
Si vos mantenés algo open source, la pregunta ya no es “¿cómo sostengo esto gratis?”. Es “¿cómo monetizo esto sin alienar a mi comunidad?”. Y esa pregunta tiene respuesta ahora. Hay modelos que funcionan. Hay ejemplos. Hay dinero fluyendo. Aprovechá.
