Todas las herramientas del sector responden a la pregunta con un solo número — días desde el último commit — y todas se equivocan con los mismos proyectos. Una biblioteca pequeña y completa que no ha necesitado cambios en tres años no está abandonada. Está terminada. Declararla muerta le cuesta al registro su credibilidad justo en el software que más confianza merece.
Por eso el silencio nunca es aquí el hallazgo. La evaluación se apoya en otra proposición:
El abandono es una obligación incumplida, no la ausencia de ruido.
Un proyecto contrae obligaciones cuando llega trabajo desde fuera: un pull request que pide revisión, una incidencia que pide respuesta, una corrección publicada para una vulnerabilidad en algo que distribuye. Un proyecto silencioso sin tales demandas no debe nada a nadie y no puede estar fallándole a nadie. Un proyecto silencioso con quince pull requests que nadie ha mirado en dos años, y un aviso de hace un año cuyo parche salió esa misma semana, no está descansando.
- Categoría: Vitalidad (0% dentro de la categoría)
- Efecto: un multiplicador sobre la calificación general y, en los estados más graves, un techo
- Clave de la métrica:
abandonment
Qué lee la evaluación
Declarado. Quien mantiene el proyecto lo ha dicho. La marca de archivado de GitHub, o una obsolescencia en el registro que cubra todos los paquetes que publica el repositorio. Nada se infiere y nada necesita corroboración: el registro cita a su sujeto.
Sequía. Mucho tiempo sin un commit humano. Deliberadamente no la actualidad del último push, que cuenta la subida de versión de un bot de dependencias como señal de vida: proyectos cuya única actividad de un año fueron actualizaciones automáticas declaran un último push de días. La autoría se lee commit a commit y se excluyen los autores automatizados. La sequía es una condición necesaria y nunca un hallazgo por sí sola.
Obligaciones incumplidas. Las señales corroborantes: pull requests sin respuesta, incidencias sin respuesta, una corrección publicada sin aplicar, publicaciones detenidas, integración continua averiada, un único responsable ausente, u OpenSSF Scorecard informando de forma independiente que el proyecto carece de mantenimiento. Cada una es un deber que el proyecto visiblemente no atiende.
Salvaguardas. Evidencia de que alguien sigue ahí, o de que no se le pide nada: un responsable que aún contesta, nada abierto que responder, una publicación dentro del año, ninguna dependencia afectada. Dos salvaguardas mantienen el resultado por debajo de un hallazgo por muchas obligaciones que se activen, porque ambas lecturas — alguien responde y nadie pregunta — explican por completo el silencio.
Qué significan los estados
| Estado | Significado |
|---|---|
maintained | El trabajo humano es reciente; sin hallazgo |
unverified | La evidencia recogida no puede responder a la pregunta |
dormant | Silencioso pero explicado — sostenido por salvaguardas, o nada se debe |
abandoned | Sequía más obligaciones incumplidas, sin contestar |
declared | Se archivó el proyecto o se marcaron sus paquetes como obsoletos |
Todo lo que los datos no pueden responder queda como unverified y no le cuesta nada al repositorio. Un análisis sin autenticación no lee ni la muestra de commits ni las colas del gestor de incidencias, así que no puede concluir nada: se registra como ausencia de evidencia, no como evidencia de ausencia.
Cómo leer el resultado
- La alerta nombra su evidencia. La duración de la sequía aparece junto a las obligaciones, para que el hallazgo pueda comprobarse en lugar de creerse.
- La sequía puede ser un mínimo. La muestra de commits está acotada; cuando no contiene ningún commit humano, el intervalo real es anterior a la ventana y se informa como al menos esa duración.
- Un hallazgo no es un juicio sobre quienes mantienen el proyecto. Los proyectos se abandonan por razones corrientes: cambian los trabajos, se desplaza el interés, la gente enferma. El registro afirma lo que encontraría quien lo use, no por qué.
- Aquí la automatización ni salva ni condena a un proyecto. Los commits de bots quedan fuera del cálculo de la sequía, de modo que un repositorio que un bot de dependencias mantiene templado se lee tan silencioso como realmente está. Una automatización intensa junto a trabajo humano reciente no es señal alguna — véase actividad de desarrollo.
Cómo mejorar
- Responda lo que está abierto, o ciérrelo. Una cola sin respuesta es la contribución individual más fuerte a un hallazgo.
- Aplique las correcciones de seguridad publicadas para las dependencias, o indique por qué no le afectan.
- Si el proyecto está terminado y no abandonado, dígalo: archivarlo o marcar sus paquetes como obsoletos sustituye una inferencia por un hecho.
Relacionado: actividad de desarrollo · resiliencia de mantenimiento · Vitalidad