"¿Mi Software a Medida No Es Todo a Medida?"
Un cliente me llamó el año pasado, un poco inquieto. Acababa de leer una factura de un desarrollador anterior donde aparecía una librería que no reconocía, y una búsqueda rápida le dijo que era "código abierto". Su primera pregunta fue directa: "¿Pagué precio completo por algo que ustedes consiguieron gratis?"
Es una pregunta válida, y me la hacen seguido en distintas versiones. La respuesta honesta es esta: sí, la mayoría del software a medida se construye en parte con piezas gratuitas hechas por la comunidad. Y no, eso no es malo. Así se construye casi todo el software moderno, incluso el de empresas mucho más grandes que la mía. El verdadero problema no es si esas piezas son gratis. Es si alguien les presta atención después de que su aplicación sale al aire.
Qué Significa Realmente "Código Abierto"
Piense en construir software como construir una casa. Un desarrollador no forja sus propios clavos ni fabrica su propia madera. Compra piezas estándar a proveedores y dedica su tiempo a lo que hace que su casa sea suya: la distribución, los muebles a medida, los detalles que solo usted pidió.
Los componentes de código abierto son esas piezas estándar. Son fragmentos de código ya construidos, escritos por programadores individuales o equipos pequeños, y compartidos públicamente para que cualquiera los use gratis. Una pantalla de inicio de sesión, una forma de procesar una tarjeta de crédito, un selector de calendario, una función que redimensiona una imagen: alguien ya escribió buen código para eso, y no tiene sentido escribirlo de cero cada vez.
Esto no es una práctica marginal. Investigaciones independientes de la industria, que analizan miles de proyectos comerciales reales, encontraron que el código abierto representa aproximadamente tres cuartas partes del código promedio de una aplicación, y que una app típica contiene varios cientos de componentes de código abierto distintos. Su software "a medida" casi seguro tiene docenas, quizás cientos, de estas piezas gratuitas adentro. Eso es normal. Lo que importa es qué pasa después.
La Licencia Es la Letra Chica Que Sí Importa
Cada componente de código abierto viene con una licencia, un documento legal corto que dice qué se puede hacer con ese código. Dos de las más comunes valen la pena conocer en términos simples.
Las licencias tipo MIT son las permisivas. Básicamente dicen: use esto como quiera, véndalo dentro de sus productos, manténgalo privado, solo deje una pequeña nota de crédito en algún lado. La mayoría del software de negocios se apoya en estas porque no generan obligaciones que afecten su producto.
Las licencias tipo GPL funcionan distinto. Dicen: si usted construye sobre este código y entrega su producto a otros, puede que tenga que liberar el código fuente de su propio producto bajo los mismos términos abiertos. Para una empresa que vende software propietario, eso puede ser un problema serio. Imagine invertir dos años y dinero real en construir un producto, solo para enterarse de que una pieza obliga legalmente a entregarle el plano a sus competidores.
Por eso la licencia bajo la que viene un componente importa tanto como lo que ese componente hace. Un desarrollador que elige componentes sin revisar la licencia está tomando una decisión legal en su nombre, se dé cuenta o no.
El Riesgo Real: Que No Haya Nadie Cuidándolo
Aquí está la parte que la mayoría de los dueños de negocio nunca escucha. Mucho código abierto lo mantienen voluntarios, a veces una sola persona, trabajando en su tiempo libre y sin cobrar. La mayoría de las veces eso funciona bien. A veces no.
En 2021, una herramienta gratuita de registro de eventos llamada Log4j, usada por miles de aplicaciones, resultó tener una falla tan grave que puso en riesgo a una enorme parte de los servidores de internet casi de la noche a la mañana, porque ese pequeño componente gratuito estaba escondido dentro de miles de aplicaciones más grandes. En 2024, investigadores de seguridad descubrieron que una herramienta de compresión crítica, mantenida durante años por un solo voluntario agotado, había sido saboteada deliberadamente por un atacante que pasó casi dos años ganándose pacientemente la confianza de ese mantenedor antes de esconder una puerta trasera.
Ninguna de estas dos herramientas estaba mal escrita. Ambas eran gratuitas, útiles y confiadas por casi todo el mundo. La falla fue que casi nadie vigilaba quién las mantenía o si seguían recibiendo parches. Ese es el riesgo real del código abierto: no el código en sí, sino los componentes que quedan sin mantenimiento, sin parches o sin revisión una vez que quedan enterrados dentro de su aplicación.
Cómo un Desarrollador Responsable Maneja Esto Por Usted
Un buen desarrollador no evita el código abierto. Eso significaría reinventar miles de problemas ya resueltos y cobrarle a usted por ese privilegio. En cambio, lo maneja como un buen contratista maneja los materiales de construcción: elige proveedores con buena trayectoria, revisa el papeleo y sigue de cerca lo que ya instaló.
En la práctica, eso significa elegir componentes mantenidos activamente y usados ampliamente, revisar la licencia antes de que se acerque a su producto, y usar herramientas que detectan problemas de seguridad conocidos en esos componentes para que los parches lleguen antes de que se conviertan en su emergencia. Esto es distinto de quién es dueño legal del código a medida que usted encargó, que trata sobre sus derechos sobre el código que su desarrollador escribió para usted. También es distinto de depender de un solo proveedor de software, que trata sobre una sola empresa controlando toda su plataforma. Esto se trata de las docenas de ingredientes pequeños y gratuitos mezclados en la receta, y de si alguien sigue revisando la despensa.
Gratis No Es el Problema. Ignorado Sí.
Volviendo a mi cliente: después de explicarle todo esto, ya no estaba molesto. Entendió que los componentes de código abierto habían mantenido su proyecto accesible y nos habían dejado enfocar su presupuesto en las funciones que realmente hacen que su negocio se diferencie de la competencia. Lo que quería después no era menos código abierto. Quería saber que alguien lo estaba vigilando, lo cual, honestamente, es algo razonable de pedir para cualquier dueño de negocio.
Si no está seguro de qué hay dentro del software que hace funcionar su negocio, o si alguien lo está vigilando, esa es una conversación que vale la pena tener antes de que se convierta en un problema en lugar de una pregunta.