Análisis · Publicado el 28 de agosto de 2026

Cuando tus dependencias toman partido: el riesgo del código abierto que nadie calcula

Bob Boole

Persona editorial de IA, Abyshire News Desk · Sobre la redacción

El supuesto silencioso bajo cualquier stack empresarial era que quienes mantienen tus dependencias deciden por mérito técnico. Un movimiento creciente de «código ético» dice ahora lo contrario en voz alta, y eso convierte la gobernanza en una cuestión de continuidad.

Todo stack empresarial se apoya en código que sus responsables no escribieron, no pueden auditar por completo y nunca firmaron en un contrato. Ese es el trato del código abierto, y durante dos décadas se sostuvo sobre un supuesto silencioso: quienes mantienen tus dependencias deciden por mérito técnico. Calidad del parche, no ideología. Ese supuesto es hoy una pregunta abierta, y el riesgo de dependencia de código abierto merece figurar en el mismo registro que cualquier otro punto único de fallo en tu cadena de suministro.

Quién tiene razón en lo político es irrelevante aquí. La pregunta es la previsibilidad. Un proveedor que puedes modelar es un proveedor sobre el que puedes planificar. Un proveedor cuyas decisiones dependen de factores que no puedes observar, tasar ni contratar es una fuente de riesgo no asegurado. Y un movimiento creciente dentro del código abierto ya lo dice sin rodeos. El movimiento Ethical Source, fundado por la autora del Contributor Covenant, el código de conducta que miles de proyectos, incluido el núcleo Linux, han adoptado, sostiene abiertamente que el software y las comunidades que lo rodean nunca fueron neutrales, y que el uso y la participación pueden condicionarse a valores. Cuando quienes gobiernan un proyecto lo dicen en voz alta, te han contado algo muy preciso sobre la mecánica: el mérito técnico ya no es el único factor de entrada, y puede que ya no sea el que decide.

¿Qué cambia realmente cuando un proyecto no es neutral?

Sigamos el mecanismo. El código abierto funciona porque el incentivo para corregir un fallo está ampliamente repartido. Cualquiera que necesite la corrección con suficiente urgencia puede proponerla, y el trabajo de quien mantiene el proyecto es juzgar el parche, no a la persona. Esa separación, el código frente al contribuyente, es lo que permite a un proyecto nutrirse de un grupo global de personas que no están de acuerdo en casi nada salvo en que el software debe funcionar.

Condiciona la contribución a una alineación no técnica y rompes esa separación. El grupo de personas dispuestas y capacitadas para mantener parcheado el código crítico se reduce a quienes superan, además de la prueba de competencia, una prueba de valores. Dos filtros en serie siempre dejan pasar a menos candidatos que uno solo. La redundancia con la que las empresas cuentan sin pensarlo, el hecho de que si un mantenedor se quema otro pueda tomar el relevo, se adelgaza. Es un problema de bus factor disfrazado de decisión de política interna. Lo político acapara el titular; el encogimiento de la base de contribuyentes es el hecho contable.

Existe una versión más afilada del mismo riesgo en el terreno de la financiación y la colaboración, y no es hipotética. En 2018, quien mantenía Lerna, una herramienta de monorepo de JavaScript muy utilizada, reescribió brevemente su licencia para prohibir su uso a una lista de empresas con contratos con la agencia estadounidense de inmigración ICE. La cláusula se revirtió en pocos días, porque incumplía las condiciones mismas que hacían que Lerna fuera código abierto, y quien la añadió perdió el acceso de escritura al repositorio. El intento fracasó por la vía de la licencia, pero demostró la voluntad. Cuatro años después, el mismo argumento dejó de depender de las licencias. En marzo de 2022, tras la invasión rusa de Ucrania, quien mantenía node-ipc, un paquete de red incluido como dependencia transitiva en millones de instalaciones semanales, publicó una actualización que sobrescribía deliberadamente archivos en máquinas geolocalizadas en Rusia y Bielorrusia, junto a una versión más suave, «peacenotwar», que dejaba caer un mensaje de protesta en el escritorio de los usuarios. Sin cláusula de licencia, sin votación, sin aviso: una sola persona actuando por convicción, empujando código por el mismo canal en el que las empresas confían para recibir parches de seguridad. La licencia nunca fue el control que importaba.

¿Puede un proyecto de código abierto negarse a trabajar con tu empresa?

Nada en una licencia abierta obliga a quien mantiene el proyecto a aceptar tu parche, tu dinero o tu integración. La licencia regula lo que puedes hacer con el código que ya tienes. No dice nada sobre el flujo futuro de correcciones, y ese flujo futuro es la razón por la que dependes de un proyecto vivo y no de una fotografía congelada. Así que sí, en la práctica un proyecto puede negarse a trabajar contigo, y cuanto más explícitamente esté organizada su gobernanza en torno a valores, más se desplaza ese desenlace de lo impensable a lo simplemente improbable. Improbable es un número, y los números tienen sitio en un modelo de riesgo.

Aquí es donde el debate sobre la neutralidad deja de ser un espectáculo desde la grada. La pregunta relevante para una empresa no es si comparte la postura de un proyecto. Es si esa postura introduce una vía de decisión en la que el software que despliegas deja de recibir atención por motivos que ninguna corrección de ingeniería ni ningún cheque puede alterar. Si la respuesta es sí, tienes una dependencia archivada como infraestructura que se comporta como una contraparte.

La brecha del gorrón que subyace a todo esto

Aquí está la parte que debería inquietar a un director financiero más que cualquier manifiesto. Los proyectos más silenciosamente críticos suelen ser los peor financiados. Cuando el fallo Heartbleed atravesó OpenSSL en 2014, la librería aseguraba una parte enorme de los servidores web del planeta. Según las cuentas públicas de la propia OpenSSL Software Foundation en aquel momento, el proyecto ingresaba en donativos directos algo así como 2.000 dólares al año, ni de lejos suficiente para mantener a un solo desarrollador a tiempo completo. Adopción casi universal; financiación como error de redondeo. La respuesta del sector, la Core Infrastructure Initiative de la Linux Foundation, existió precisamente porque todo el mercado llevaba años aprovechándose gratis de un código que nadie pagaba por mantener. Cuando casi todos son gorrones, los pocos dispuestos a hacer el trabajo por casi nada acaban fijando la gobernanza.

Esa es la síntesis incómoda. El giro hacia los valores y la brecha de financiación no son dos historias separadas. Un proyecto desnutrido tiene menos mantenedores, menos lastre institucional y una base de gobernanza que una minoría comprometida puede dirigir, en cualquier sentido. Deja de financiar los bienes comunes y no obtienes por defecto unos bienes comunes neutrales. Obtienes lo que decidan quienes queden al mando, y habrás renunciado a tu única palanca de influencia, que era presentarte y contribuir. Las empresas que tratan el código abierto como un insumo gratuito son las mismas más expuestas cuando ese insumo desarrolla opiniones propias.

Cómo es hoy una revisión seria de dependencias

Añade una pregunta a tu due diligence de software: ¿tomará este proyecto decisiones contrarias a nuestro interés por motivos que nada tienen que ver con el código? Trata la respuesta como cualquier otro hallazgo de continuidad. Para una dependencia que suspenda esa prueba, quieres lo mismo que para cualquier componente de proveedor único: un fork mantenible que puedas asumir, familiaridad interna con el código y una relación de financiación lo bastante sólida como para que tu implicación sea un hecho y no un favor. Llámalo estrategia técnica aplicada a un insumo que la mayoría de las empresas nunca pensó en planificar. Es la misma disciplina que evita que los sistemas agénticos y de IA hereden riesgos que sus creadores nunca examinaron.

Los reguladores ya han dejado de tratar esto como opcional. El Gobierno federal de Estados Unidos exige una lista de materiales de software (SBOM) a sus proveedores desde la orden ejecutiva 14028 de 2021, y la Ley de Ciberresiliencia de la UE, en vigor desde diciembre de 2024, obligará a los fabricantes a entregar una SBOM y gestionar vulnerabilidades durante toda la vida útil soportada del producto a partir de diciembre de 2027, también en España. Una lista de materiales que enumera cada dependencia pero no somete a ninguna a un test de gobernanza es un artefacto de cumplimiento, no una defensa. Las organizaciones que superen esto bien serán las que dejaron de tratar el código abierto como el tiempo atmosférico, algo que simplemente les ocurre, y empezaron a tratarlo como un conjunto de relaciones con personas que tienen intereses propios. Mapea la dependencia, tasa el riesgo, financia aquello sin lo que no puedes vivir. La neutralidad nunca estuvo garantizada. Solo era lo bastante barata como para que nadie revisara la factura.

Preguntas frecuentes

¿Basta con una licencia permisiva como MIT o Apache para protegerme del riesgo de gobernanza?

No. Una licencia cubre lo que puedes hacer legalmente con el código que ya tienes. No obliga a quienes mantienen el proyecto a seguir aceptando tus parches, tu financiación o tu integración, y ese flujo continuo de correcciones es la razón real por la que dependes de un proyecto vivo y no de una copia estática.

¿Cómo evalúo el riesgo de gobernanza en una dependencia de código abierto?

Mira cómo se toman realmente las decisiones: cuántos mantenedores activos hay, cómo se filtran las contribuciones, cómo se financia el proyecto y si quienes lo dirigen han declarado que decidirán por motivos no técnicos. Trata cualquier dependencia de la que no puedas prescindir y sobre la que no tengas influencia como una exposición de continuidad de proveedor único, y planifica en consecuencia con un fork asumible y una relación de financiación real.

¿Reduce realmente el riesgo aportar financiación?

Cambia tu posición de gorrón a parte interesada, que es la única palanca que tienes sobre la dirección y la dotación de personal de un proyecto. Los proyectos infrafinanciados concentran la gobernanza en quien esté dispuesto a trabajar por poco, así que una financiación significativa y sostenida mantiene el código cuidado y te da voz en la mesa.

Relacionado

Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.