Casi todas las empresas que desarrollan software ya usan código abierto, lo sepan o no. Basta abrir el package.json o el requirements.txt de cualquier proyecto. La pregunta no es si usarlo, sino cómo hacerlo con orden. Una estrategia de código abierto responde tres cosas: qué usamos, a qué contribuimos y qué publicamos.
Paso 1: saber qué usas
No se puede gestionar lo que no se conoce. El primer paso es un inventario:
- Lista las dependencias de cada proyecto, incluidas las indirectas. Los gestores de paquetes las exponen (
npm ls,pip freeze,composer show), y herramientas como Syft o Trivy generan un SBOM (software bill of materials) completo. - Registra la licencia de cada una.
- Identifica las críticas: las que, si fallan o desaparecen, detienen el negocio.
Este inventario sirve después para seguridad (saber si te afecta una vulnerabilidad nueva), para temas legales y para decidir dónde invertir.
Paso 2: una política de licencias simple
La mayoría de las empresas resuelve esto con un semáforo:
| Categoría | Licencias típicas | Regla |
|---|---|---|
| Verde | MIT, BSD, Apache 2.0, ISC | Uso libre. |
| Amarillo | LGPL, MPL 2.0 | Uso permitido; revisar si se modifica o distribuye. |
| Rojo | GPL, AGPL, licencias no aprobadas por la OSI | Consultar antes de usar en productos que se distribuyen o se ofrecen como servicio. |
Lo importante es que la regla sea clara y fácil de aplicar. Una política de veinte páginas que nadie lee no protege a nadie. Se puede automatizar en la integración continua para que un pull request con una licencia roja quede marcado.
Paso 3: decidir cómo contribuir
Si dependes de un proyecto, te conviene que esté sano. Hay varias formas de ayudar, de menor a mayor compromiso:
- Reportar bien los errores que encuentras.
- Enviar los arreglos que ya hiciste internamente, en vez de mantener un parche propio para siempre. Mantener un fork privado es caro: cada actualización del proyecto original obliga a reaplicar tus cambios.
- Dar tiempo de trabajo a tus desarrolladores para mantener dependencias críticas.
- Financiar a los mantenedores o a la fundación del proyecto.
Para que esto funcione hace falta una regla interna clara: qué pueden contribuir los empleados sin pedir permiso, con qué cuenta, y si la empresa firma los acuerdos de contribución (CLA) que algunos proyectos exigen.
Paso 4: decidir qué publicar
No todo vale la pena. Buenos candidatos:
- Herramientas internas que no son ventaja competitiva.
- Bibliotecas para integrarse con tu producto: si tus clientes las usan, te conviene que sean abiertas.
- Formatos o protocolos que quieres que se conviertan en estándar.
Malos candidatos: el núcleo de lo que vendes, código que nadie va a mantener y código con dependencias o datos que no puedes liberar. En este artículo hay más detalle sobre cuándo publicar.
Cada proyecto publicado necesita un responsable con tiempo asignado. Publicar y abandonar daña la reputación más que no publicar.
Paso 5: elegir el modelo de negocio, si lo hay
Si el código abierto es parte de lo que vendes, hay modelos probados:
- Soporte y suscripción: el software es libre; la garantía, las actualizaciones certificadas y la atención se cobran.
- Open core: el núcleo es libre; funciones para empresas (autenticación corporativa, auditoría, alta disponibilidad) son comerciales.
- Servicio gestionado: tú operas el software y el cliente paga por no tener que hacerlo.
- Licenciamiento dual: GPL para la comunidad, licencia comercial para quien no quiere cumplir el copyleft.
Cada modelo tiene tensiones. En open core, por ejemplo, siempre habrá discusión sobre qué funciones van en cada lado.
Paso 6: alguien a cargo
Las empresas grandes crean una OSPO (Open Source Program Office), un equipo dedicado a todo lo anterior. En una empresa chica no hace falta un equipo: basta una persona con tiempo asignado que mantenga el inventario, aplique la política de licencias y sea el punto de contacto para contribuir y publicar.
Para partir esta semana
- Genera el SBOM de tu proyecto principal.
- Escribe la política de licencias en una página.
- Elige una dependencia crítica y revisa qué tan sana está.
Con eso ya tienes más estrategia que la mayoría.
Preguntas frecuentes
¿Qué es una OSPO? Es una Open Source Program Office, un equipo que gestiona cómo una empresa usa, contribuye y publica código abierto. En una empresa chica basta una persona con tiempo asignado.
¿Qué es un SBOM? Es la lista completa de componentes de un software (software bill of materials), incluidas las dependencias indirectas. Herramientas como Syft o Trivy lo generan automáticamente.
¿Qué licencias de código abierto se pueden usar en un producto comercial? Las permisivas, como MIT, BSD, Apache 2.0 e ISC, se usan con pocas condiciones. La GPL y la AGPL exigen revisar el caso antes de usarlas en productos que se distribuyen o se ofrecen como servicio; lo detallamos en ¿puedo usar código GPL en un producto comercial?.
¿Cómo gana dinero una empresa con código abierto? Con soporte y suscripción, open core, servicio gestionado o licenciamiento dual. En todos el código es libre y lo que se cobra es la garantía, las funciones empresariales, la operación o una licencia distinta.
¿Qué es un CLA en código abierto? Es un acuerdo de contribución que algunos proyectos piden firmar antes de aceptar código. Una empresa debe decidir si sus empleados pueden firmarlos al contribuir.