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: 13.2 % — la métrica de repositorio con mayor peso individual
- 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 |
| Volumen de commits | 18 | escala logarítmica; aproximadamente 100 commits al año obtienen la puntuación completa |
| 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.
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