La actividad de desarrollo responde a la primera pregunta que cualquiera plantea sobre una dependencia de código abierto: ¿se está escribiendo código activamente? Lee el historial de push y de commits del repositorio durante el último año y premia la recencia, el ritmo y el volumen — en ese orden de peso.
- Categoría: Vitalidad (60 % dentro de la categoría)
- Peso en el índice general: 12.6%
- Clave de la métrica:
development_activity
Cómo se calcula el valor
| Componente | Peso | Criterios |
|---|---|---|
| Recencia de push | 36 | los mismos umbrales que v0.9.0, escalados a 36 puntos |
| Cadencia de commits | 36 | proporción de las últimas 52 semanas con al menos un commit, × el factor de autoría humana |
| Volumen de commits | 18 | escala logarítmica; aproximadamente 100 commits al año obtienen la puntuación completa, × el factor de autoría humana |
| OpenSSF Scorecard: Maintained | 10 | resultado 0–10 de Scorecard, escalado a 10 puntos |
El valor es la suma ponderada, redondeada y acotada a 1–100, y se corresponde con una banda de calificación. Los componentes sin datos se excluyen y los pesos restantes se renormalizan (véase el índice de salud).
Maintained es evidencia compartida, no un sustituto del historial de commits propio del escáner: también sigue siendo un componente pleno de la postura de seguridad. Si Scorecard no está disponible o marca la comprobación como n/a, este componente se excluye.
El factor de autoría humana
La cadencia y el volumen cuentan commits, y un commit hecho por un robot cuenta exactamente igual que uno hecho por quien mantiene el proyecto. Un repositorio cuyo bot de dependencias abre y fusiona una actualización cada semana se lee, por tanto, como uno en desarrollo continuo.
Se comprueba la autoría de los 100 commits más recientes, y los dos componentes que cuentan commits se multiplican por la proporción humana de esa ventana, alcanzando la puntuación completa a partir del 40%.
Deben cumplirse dos condiciones a la vez. Una proporción humana baja, por sí sola, solo significa que un proyecto automatiza mucho, cosa que los mejor mantenidos suelen hacer — una herramienta con 59.000 estrellas hace pasar aproximadamente tres cuartas partes de sus commits por un bot de dependencias, y un registro de paquetes cuyo producto son los saltos de versión automatizados llega aún más alto. Ambos tienen commits humanos de hace días. Por eso el descuento exige además que ninguna persona haya hecho un commit en más de 90 días: es el silencio, no la automatización, lo que marca a un proyecto como sostenido por sus robots.
El intervalo se mide dentro de la propia ventana de commits — el commit más reciente frente al más reciente humano —, de modo que un informe almacenado siempre se recalcula al mismo valor en lugar de derivar al envejecer.
No aporta peso aditivo propio — puede bajar un valor, nunca subirlo — y se omite por completo cuando la muestra de commits no está disponible o es menor de 20 commits, para no inferir nada a partir de evidencia insuficiente. Solo se reconoce la automatización que lleva identidad de GitHub App; un bot que opera bajo una cuenta de usuario corriente sigue contando como persona.
Por qué la cadencia pesa más que el volumen
Un repositorio con un commit cada semana durante un año es evidencia más fiable de mantenimiento que el mismo número de commits aterrizados en una sola ráfaga. La cadencia mide la atención sostenida; el volumen usa escala logarítmica precisamente para que el recuento de commits no pueda inflarse hasta un valor alto — la diferencia entre 100 y 1000 commits anuales es pequeña por diseño.
Cómo leer el resultado
- La recencia domina el cambio a corto plazo. Un proyecto que se detiene seis meses pierde primero el componente de recencia; el componente de cadencia decae después a medida que se acumulan semanas inactivas.
- El software genuinamente terminado existe. Una biblioteca estable y funcionalmente completa puede leerse baja aquí sin dejar de ser segura de usar — por eso la actividad de desarrollo es una métrica dentro de un índice ponderado, no un veredicto. Conviene leerla en cruce con la disciplina de versiones y la capacidad de respuesta.
- Monorepos y espejos: la actividad se lee del repositorio inspeccionado; el trabajo que ocurre en otro repositorio no cuenta.
Cómo mejorar el valor
- Integrar el trabajo de mantenimiento de forma continua en lugar de acumularlo en ramas de larga vida.
- Mantener al menos un latido semanal de cambios reales allí donde el proyecto necesita mantenimiento genuino — las actualizaciones de dependencias y las correcciones de errores cuentan.
- Evitar la actividad vacía: la escala logarítmica del volumen hace que la inflación sintética de commits sea casi inútil.
Relacionado: disciplina de versiones · Vitalidad