Mantenimiento, señales de abandono

La comprobación Maintained mira la actividad reciente: commits e incidencias. Su puntuación más alta exige al menos un commit por semana durante los 90 días previos. Pero una biblioteca estable y terminada también tiene poca actividad, así que hay que mirar el historial completo y no solo el número.

Abre colaligera/commits.txt. La serie por mes cuenta una historia; la fecha exacta del último commit es la pieza que usarás en las reglas de seguimiento.

Los commits pueden quedarse en la rama principal sin llegar a una versión. Lo que tú instalas es un lanzamiento. Si pasa un año sin uno, las correcciones que existan no te llegan, y una vulnerabilidad corregida «en la rama» sigue en tu servicio.

Con la fecha de corte de la revisión (2026-10-06) y la fecha del último lanzamiento, calcula los días transcurridos. Cuenta con el calendario real de los meses.

Una lista de incidencias sin respuesta es la señal más difícil de disimular. Las dudas sin atender son una molestia; las incidencias de seguridad sin atender son el criterio para decidir. Una persona que informó de una vulnerabilidad de forma responsable y no recibió ni un acuse de recibo suele dejar de intentarlo.

Abre colaligera/incidencias.txt y localiza la incidencia de la etiqueta de seguridad.

Scorecard no concluye sobre proyectos muy jóvenes: si el repositorio tiene menos de 90 días, la comprobación de mantenimiento no puede medir nada fiable. Un proyecto nuevo con una puntuación baja o sin ella no está abandonado: no ha tenido tiempo de demostrar nada. Eso no lo hace candidato fácil, pero es otra conversación.

Abre otros/proyecto-nuevo.txt, la ficha de fechaslocal.

Una cosa es no adoptar una biblioteca y otra encontrar que una ya adoptada va camino del abandono. Aquí hay más que perder: dos servicios dependen de colaligera, tiene una vulnerabilidad reportada sin atender y su último commit es de hace meses. Eliminarla de golpe rompería servicios; ignorarla acumula riesgo.