Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

El software moderno rara vez se construye desde cero. En su lugar, se ensambla como una estructura masiva hecha de partes prefabricadas, donde cada parte es un pequeño fragmento de código escrito por alguien más. En el mundo de JavaScript, el sistema que mantiene unidas estas partes se llama npm, un almacén digital donde los desarrolladores descargan estos paquetes de código para construir desde sitios web hasta aplicaciones móviles. La mayoría de estas partes son mantenidas por voluntarios que trabajan en ellas en su tiempo libre. Cuando un voluntario deja de trabajar en una parte, ese fragmento de código queda latente. No se rompe inmediatamente, pero deja de recibir actualizaciones, correcciones de errores o parches de seguridad. Esto crea un riesgo oculto: si una parte muy utilizada deja de actualizarse, los miles de proyectos que dependen de ella quedan con un componente que no puede ser reparado si algo sale mal. La pregunta no es solo si estas partes dejan de actualizarse, sino cuántas de ellas están realmente latentes, cuántas personas las están usando y si las personas que las usan saben que deben dejar de utilizarlas.

Un investigador llamado Revanth Krishna Maddula se propuso examinar las partes más populares de este sistema. Analizó casi dieciséis mil paquetes que se descargan al menos un millón de veces cada semana. Estos son los componentes centrales del ecosistema de JavaScript, las partes que tienen mayor peso. Al estudiar el historial completo de estos paquetes hasta octubre de 2026, quería ver cuántos habían dejado de lanzar nuevas versiones, cuántas personas los seguían usando y cómo reaccionaba el sistema cuando una parte quedaba en silencio. El estudio se centró en una definición específica de latencia: un paquete que no había publicado una versión estable y terminada en los últimos dos años. Este periodo de tiempo se eligió para distinguir entre las partes que simplemente están terminadas y las partes que han sido abandonadas.

Los hallazgos revelan que la latencia es mucho más común de lo que muchos podrían esperar. Al final del periodo de estudio, casi el treinta y cinco por ciento de estos paquetes principales no habían lanzado una nueva versión en dos años. Este silencio no se limitó a herramientas oscuras o poco utilizadas; llegó al corazón mismo del sistema. Entre los cien paquetes más descargados, el veintiséis por ciento estaban latentes. De hecho, algunos de estos paquetes silenciosos no habían sido actualizados durante más de ocho años. A pesar de esta actividad generalizada, el silencio casi siempre fue absoluto. Cuando el investigador revisó las notas públicas adjuntas a estos paquetes, conocidas como archivos README, encontró que solo alrededor del tres por ciento de los paquetes latentes declaraban explícitamente que ya no estaban siendo mantenidos. La mayoría de las veces, el código simplemente dejó de cambiar, dejando a los usuarios adivinar si el proyecto estaba terminado o en el olvido.

El peligro de este silencio es que las partes activas del sistema están profundamente conectadas con estas partes latentes. El estudio mapeó las relaciones entre los paquetes y encontró que más de una cuarta parte de los paquetes mantenidos activamente dependían directamente de al menos un paquete latente. Algunos de estos paquetes silenciosos eran tan centrales que eran alcanzables a través de cadenas de dependencias desde más de mil otros paquetes de alto tráfico. Muchos de estos eran herramientas pequeñas y simples que podrían haberse completado hace años, pero otros eran módulos sustanciales que formaban la base de gran parte de las herramientas de software. El problema es que los usuarios no pueden distinguir fácilmente entre una herramienta que está terminada y una que ha sido abandonada, porque el sistema no ofrece una señal clara para distinguir ambas.

Cuando una dependencia entra en estado de latencia, las personas que la utilizan no suelen reaccionar con rapidez. El estudio rastreó cuánto tiempo tardaron los usuarios en eliminar una dependencia de un paquete que había dejado de actualizarse. Durante un periodo de dos años, los usuarios eliminaron solo alrededor del veintisiete por ciento de sus dependencias de paquetes latentes. Esta tasa fue solo ligeramente superior a la tasa con la que eliminaban las dependencias de paquetes activos, lo que sugiere que el mero hecho de que un paquete hubiera dejado de actualizarse no era suficiente para motivar una acción. Los investigadores probaron si diferentes tipos de advertencias cambiaban este comportamiento. Encontraron que una nota en la documentación del proyecto no tuvo un efecto detectable en si los usuarios eliminaban el paquete. La única señal que causó de manera fiable que los usuarios actuaran fue un aviso de depreciación oficial emitido por el propio registro. Cuando un paquete latente fue marcado formalmente como depreciado por el sistema, los usuarios eliminaron las dependencias de él a una tasa del sesenta y cinco por ciento. Esta advertencia oficial, que aparece ante los desarrolladores cuando instalan el software, fue el único mecanismo que logró con éxito impulsar al ecosistema a alejarse del código silencioso.

También existe una dimensión de seguridad. Aunque la mayoría de los paquetes latentes no tenían fallos de seguridad conocidos en sus últimas versiones, aquellos que sí los tenían estaban en una posición precaria. El estudio encontró que un pequeño número de paquetes latentes portaban vulnerabilidades conocidas que ya no podían ser corregidas por sus mantenedores originales. Debido a que el código ya no se actualizaba, estos fallos no podían ser parcheados desde la cima. Los usuarios que dependían de estos paquetes tenían que eliminarlos, reemplazarlos con otras herramientas o reparar los fallos de seguridad ellos mismos. Esta situación resalta una brecha crítica en el sistema: cuando una parte ampliamente utilizada deja de ser mantenida, la responsabilidad de su seguridad recae enteramente en las personas que la utilizan, a menudo sin su conocimiento.

El estudio concluye que la latencia es un estado normal y silencioso para una gran parte del ecosistema de software. No es necesariamente un defecto si una pequeña herramienta está terminada, pero la falta de comunicación hace imposible que los usuarios distingan la diferencia. La investigación sugiere que el sistema actual depende demasiado de que los usuarios adivinen el estado de sus herramientas. La forma más eficaz de gestionar este riesgo es que los mantenedores utilicen el mecanismo oficial de depreciación cuando dejen de trabajar en un paquete, idealmente señalando a los usuarios hacia un reemplazo. Para que el ecosistema siga siendo saludable, el registro debe hacer que la latencia y la depreciación sean más visibles, asegurando que la señal llegue a los desarrolladores que necesitan verla antes de que un paquete silencioso se convierta en un problema.