23 proyectos que sostienen internet: el riesgo oculto de tu startup

¿Quién mantiene el código que sostiene tu startup?

Una tira de cómic viral en internet muestra una torre etiquetada como "toda la infraestructura digital moderna" sostenida por un único bloque pequeño titulado "un proyecto que alguien aleatorio en Nebraska lleva manteniendo sin recompensa desde 2003". La imagen se comparte cada vez que algo se rompe en internet. Pero ¿qué tan cerca de la realidad está?

Un análisis exhaustivo descargó el historial completo de 23 proyectos de software que teléfonos, navegadores y servidores dependen para funcionar, y contó quiénes realizaron cambios entre octubre de 2025 y octubre de 2026. El resultado es inquietante: la mayoría de estos proyectos tienen uno o dos personas haciendo el trabajo regular.

Estos no son proyectos secundarios. Son las piezas que sostienen tu stack tecnológico diario:

• SQLite: en cada teléfono Android, iPhone, Mac, Windows y navegador principal. Se estima que hay más de un billón de bases de datos SQLite en uso.
• curl: transfiere datos para teléfonos, autos, televisores y Windows. Reporta más de veinte mil millones de instalaciones en dispositivos móviles, vehículos, electrodomésticos y equipos médicos.
• xz-utils: herramienta de compresión presente en casi todos los servidores Linux y dentro de cada iPhone.
• tz database: gestiona las zonas horarias en Android y iPhones, mantenida por solo dos voluntarios.

El problema no es teórico. En diciembre de 2021, la vulnerabilidad log4j expuso aplicaciones desde Twitter hasta Minecraft, ambas rastreadas a equipos diminutos de voluntarios manteniendo código del que miles de empresas se benefician gratuitamente. La brecha de xz-utils en marzo de 2024 lo confirmó con mayor fuerza.

El caso xz: cuando un solo punto de falla casi destruye la autenticación SSH

La historia de xz-utils es el ejemplo más claro de este riesgo sistémico. Lasse Collin, un desarrollador finlandés que trabaja en esto como hobby no remunerado, era prácticamente el único responsable de mantener esta biblioteca de compresión esencial.

En 2023, un contribuyente llamado Jia Tan comenzó enviando correcciones útiles. Lasse le otorgó más acceso al proyecto. En febrero de 2024, las versiones liberadas por Jia Tan contenían una puerta trasera oculta en la biblioteca liblzma.so que permitía a cualquier atacante con una clave privada especial saltarse la autenticación SSH y ejecutar comandos como root en sistemas afectados.

La puerta trasera fue descubierta por accidente el 29 de marzo de 2024 por Andres Freund, ingeniero de Microsoft, porque sus inicios de sesión usaban más tiempo de procesador del esperado. Si no hubiera notado ese síntoma, el daño habría sido incalculable.

Lo que sigue es aún más preocupante. Investigadores de Binarly descubrieron que al menos 35 imágenes de Linux con la puerta trasera de xz permanecían disponibles en Docker Hub en 2026. Estas imágenes comprometidas infectan transitivamente cualquier sistema que las use como base en pipelines CI/CD.

"Es bueno tener en cuenta que este es un proyecto de hobby no remunerado", escribió Lasse Collin en junio de 2022, explicando que su capacidad de cuidar del proyecto estaba "limitada principalmente por problemas de salud mental a largo plazo".

Proyectos abandonados vs. proyectos financiados: dos realidades distintas

No todos los proyectos enfrentan el mismo nivel de riesgo. El análisis revela una división clara entre aquellos que sobreviven con patrocinio y los que dependen exclusivamente de la buena voluntad.

Los mejor financiados:

• sudo (Todd C. Miller): Después de que The Register publicara su pedido de patrocinio en febrero de 2026, el presupuesto alcanzó aproximadamente US$61,700 anuales mediante Open Collective, con 30 patrocinadores en GitHub. Todd ha mantenido sudo desde principios de los 90, más tiempo del que Linux existe.
• curl (Daniel Stenberg): Recibe alrededor de US$89,700 anuales por Open Collective y €195,000 del fondo público alemán para código abierto. Daniel trabaja a tiempo completo gracias a empresas que pagan por soporte. Tiene 64 patrocinadores en GitHub.

Los sin financiamiento visible:

• tz database (Paul Eggert): Sin página de patrocinio. Mantiene el archivo de zonas horarias desde 2012 junto con Tim Parenti.
• xz-utils (Lasse Collin): Sin página de patrocinio.
• core-js (Denis Pushkarev): Sin financiamiento formal. Pushkarev agregó un mensaje pidiendo ayuda en cada instalación tras un accidente automovilista fatal en 2019, fue encarcelado en enero de 2020 y liberado tempranamente.
• zlib (Mark Adler y Jean-loup Gailly): No aparece en ninguna lista pública de financiamiento verificada.

Cuando Nick Wellnhofer, mantenedor de libxml2, anunció en septiembre de 2025 que renunciaba, el proyecto quedó sin responsable. libxml2 lee XML —el formato detrás de documentos, feeds y configuraciones— y está instalado en 5.600 millones de teléfonos y computadoras. Dos voluntarios tomaron el relevo en diciembre de 2025, pero el vacío de tres meses dejó una ventana de seguridad sin mantenimiento.

Qué está haciendo el gobierno alemán para cambiar el modelo

La respuesta institucional más estructurada viene de Alemania. En 2022, el Fondo Tecnológico Soberano (Sovereign Tech Fund) comenzó bajo el Ministerio Federal de Economía y Acción Climática, alojado por SPRIND. Firma contratos de mantenimiento con proyectos de código abierto, comenzando en €50.000 y durando desde varios meses hasta años.

En noviembre de 2024, el fondo creció a la Agencia Tecnológica Soberana (Sovereign Tech Agency). Su portafolio ahora cubre más de cien proyectos, con programas hermanos dirigidos a desarrolladores y trabajo de seguridad.

Un estudio publicado en julio de 2026 por Laia Domenech Burin, científica de datos de la agencia, mide el impacto real del dinero público en proyectos financiados. La metodología comparó doce proyectos financiados con sesenta y dos similares no financiados, usando datos desde 2015.

Los resultados son claros:

• Los commits aumentaron aproximadamente un 144% sobre lo que habría ocurrido sin financiamiento.
• Las nuevas issues subieron más del doble.
• Los change requests se movieron en rangos similares.

Pero tres métricas se mantuvieron planas: el número de contribuyentes apenas cambió, la frecuencia de releases se mantuvo estable y el conteo de issues cerrados no mejoró. El dinero acelera a los mantenedores existentes, pero no atrae nuevos colaboradores.

"Las métricas son una brújula: indican la dirección, pero no el destino", escribe Domenech Burin.

Cuatro proyectos financiados están en el centro del estudio: el Python Package Index, curl, herramientas Fortran y RubyGems. curl solo reportó más de veinte mil millones de instalaciones cruzando teléfonos, autos, televisores y dispositivos médicos.

También existe el fondo Alpha-Omega, que distribuyó casi US$6 millones en 2025, principalmente a ingenieros de seguridad en fundaciones como Python y Ruby. Ambos modelos dan dinero a organizaciones que pueden solicitarlo y reportar sobre él.

Qué significa esto para tu startup

Si estás construyendo una empresa basada en tecnología, estas dependencias no son abstractas. Cada library que importas, cada container que pulls de Docker Hub y cada package manager que ejecuta contiene el mismo riesgo concentrado en manos de uno o dos voluntarios.

Riesgo operativo directo: Cuando un mantenedor se retira, queda incapacitado o es comprometido socialmente (como ocurrió con xz), tu stack entero pierde su capa de soporte de seguridad. No hay SLA, no hay equipo de respuesta, no hay contrato de nivel de servicio.

Riesgo de supply chain: La puerta trasera de x-utils demostró que un atacante paciente puede infiltrarse durante años en un proyecto pequeño antes de activar su payload. Docker Hub todavía alberga imágenes infectadas en 2026, lo que significa que cualquier pipeline CI/CD que use esas imágenes como base hereda la vulnerabilidad.

Acciones concretas que puedes implementar hoy:

1. Audita tus dependencias críticas. Identifica qué libraries de código abierto sostienen tu producción. Prioriza aquellas con menos de tres contribuyentes activos. Usa herramientas como npm audit, pip-audit o cargo audit regularmente, pero no te confíes: estas herramientas detectan vulnerabilidades conocidas, no riesgos de abandono.

2. Contribuye financieramente o directamente. Si tu startup usa curl, sudo, libxml2 o cualquier proyecto similar, considera patrocinarlo vía GitHub Sponsors u Open Collective. No es filantropía: es seguro que tu proveedor de infraestructura siga existiendo. Incluso US$50 mensuales hacen diferencia para proyectos que operan con presupuestos mínimos.

3. Planifica escenarios de maintainer gone. Para cada dependencia crítica, identifica quién es el mantenedor actual y si hay backups documentados. En el caso de libxml2, el proyecto estuvo sin responsable durante tres meses. Tu startup no puede permitirse ese tipo de ventana. Documenta alternativas y ten planes de contingencia.

4. Exige transparencia de supply chain a tus proveedores. Si contratas servicios cloud o SaaS, pregunta cómo gestionan sus dependencias de código abierto. Un proveedor que no sabe cuántos contribuyentes activos tiene su libcurl podría estar operando con el mismo riesgo concentrado.

La tendencia de financiamiento institucional (Sovereign Tech Agency, Alpha-Omega fund) es positiva, pero llega tarde y a proyectos específicos. Mientras tanto, la responsabilidad recae en quienes usan el software: las empresas que se benefician deben invertir en mantener las piezas que sostienen su negocio.

El modelo actual —donde gigantes tecnológicos y startups consumen código escrito por voluntarios en su tiempo libre— es insostenible. La crisis de x-utils no fue un evento aislado; fue una advertencia. Y mientras el ecosistema busca soluciones estructurales, cada founder debe asumir que su infraestructura depende de personas reales, no de garantías corporativas.

Fuentes

• People Holding Up the Internet
• Docker Hub still hosts dozens of Linux images with the XZ backdoor
• What public money does to open-source projects