Métricas de repositorio

Autenticidad del crecimiento

Cómo inspect.software examina el historial diario de estrellas y forks de un repositorio en busca de un crecimiento que la atención orgánica no produce, y qué hace al respecto la Política de crecimiento inorgánico.

Metodología v1.13.0Actualizado el 2026-07-21

Una estrella de GitHub es la señal de confianza más leída del código abierto. También es la única que no tiene emisor. Las estrellas se venden abiertamente, al por mayor y por unos céntimos cada una, junto con forks, observadores y seguidores, y nada en la cifra misma distingue lo comprado de lo ganado.

Toda evaluación que cuente estrellas hereda ese problema. La autenticidad del crecimiento es la parte de la metodología que lo aborda: el historial diario de estrellas y forks recopilado para cada informe se examina en busca de un crecimiento cuya forma la atención orgánica no produce y, allí donde ese crecimiento se confirma, los datos de entrada que pueden comprarse se descuentan en lugar de darse por buenos.

El resultado responde a una pregunta estrecha:

¿El historial de popularidad de este repositorio parece algo que ocurrió o algo que se entregó?

No responde a quién lo hizo ni a si alguien pagó por ello. Todo hallazgo recogido aquí es una afirmación sobre el momento en que se produjeron eventos públicos, y nada más.

Por qué el calendario lo delata

La atención que un proyecto se gana llega a través de personas, y las personas son irregulares. Un lanzamiento, una portada de Hacker News, una charla en una conferencia o una mención en un boletín producen un pico desigual hora a hora, que trae forks junto con estrellas porque algunos lectores abren el código, y que decae a lo largo de la semana siguiente a medida que el enlace circula y luego deja de hacerlo.

La atención entregada no tiene ninguna de esas propiedades. Llega siguiendo un calendario, desde cuentas que nunca miran el repositorio, y termina en el momento en que se completa el pedido. El contador no puede distinguirlo. El historial sí.

Qué se mide

El informe busca primero días de pico: días en los que el repositorio ganó al menos 25 estrellas y, a la vez, al menos doce veces su propia tasa mediana de los días con actividad. Los días de pico consecutivos se fusionan en una única ventana.

Un pico nunca constituye por sí solo un hallazgo. Los proyectos reales tienen picos, y una metodología que tratara todo repunte como sospechoso señalaría cualquier lanzamiento exitoso. Una ventana solo se confirma cuando al menos dos señales independientes la corroboran:

SeñalQué observa
Concentración de estrellasLos cinco días de mayor actividad concentran el 80% o más de todas las estrellas recopiladas. Medida en 502 repositorios corrientes, la mediana sitúa el 6,9% de sus estrellas en sus cinco días de mayor actividad, y ninguno llegó al 80%. Esta señal se refiere al historial completo y no a un pico concreto, de modo que corrobora todas las ventanas.
Cadencia planaA lo largo de tres días o más, las adiciones diarias apenas variaron. Un público es desigual; un calendario de entrega no lo es.
Sin respuesta en forksLa proporción de forks por estrella de la ventana cayó por debajo de una cuarta parte de la proporción de largo plazo del propio repositorio: atención que nunca tocó el código.
Sin decaimientoLos siete días posteriores al pico sumaron un 5% de este o menos. Los picos reales tienen cola; un pedido completado se detiene en seco.
Sin ninguna versión publicadaEl proyecto no ha publicado jamás una versión. Es deliberadamente débil: hay muchos proyectos legítimos que no publican nada. Una forma anterior de esta señal tomaba como evidencia que un pico llegara antes de la primera versión de un proyecto, y produjo todos los falsos positivos de la primera medición de control: publicar, atraer atención y publicar una versión más tarde es como funcionan los proyectos corrientes.

Los cuatro estados

EstadoSignificadoEfecto
OrgánicoEl historial es coherente con una acumulación orgánica.ninguno
Sin verificarEl historial recopilado no permite responder a la pregunta.ninguno
AnómaloUna ventana confirmada.estrellas y forks descontados un 40%
Muy anómaloDos o más ventanas confirmadas, o una con tres señales.estrellas y forks descontados un 70%

El descuento se aplica a los componentes de estrellas y forks de la popularidad — los dos datos de entrada que un proveedor puede vender. Los observadores quedan intactos, porque no forman parte de aquello que la anomalía acredita, y ninguna otra categoría se mueve en absoluto. La popularidad representa el 7,2% del índice general, de modo que el efecto aritmético es deliberadamente pequeño. El hallazgo es el producto; el ajuste solo evita que el informe afirme algo que tiene motivos para poner en duda.

No existe ajuste al alza. Un historial limpio no puede elevar una puntuación, exactamente igual que un resultado jurisdiccional limpio no puede elevar la postura de seguridad.

Qué significa «sin verificar» y qué no

Un repositorio se lee como sin verificar cuando no tiene historial de estrellas recopilado, cuando reúne menos de 100 estrellas o cuando la ventana recopilada abarca menos de 60 días. No conlleva penalización de ningún tipo.

Es el caso más común, y responde a un límite de la evidencia más que a un veredicto. La recopilación del historial está acotada — el informe capta una ventana reciente de eventos de estrellas y forks, no toda la vida de un proyecto grande —, de modo que cualquier manipulación anterior a esa ventana resulta sencillamente invisible aquí. Sin verificar significa que la pregunta no admitía respuesta. Nunca significa que la respuesta fuera limpia.

Cómo interpretar el resultado

  • Un hallazgo se refiere a un patrón, no a una persona. Las estrellas puede comprarlas un competidor, un promotor, un propietario anterior del repositorio o alguien a quien los mantenedores nunca conocieron. Nada en esta evaluación identifica quién actuó, y nada en ella implica que lo hicieran los mantenedores.
  • Un hallazgo no convierte al software en malo. Convierte en poco fiable una pieza de evidencia sobre el software. La evidencia de ingeniería, gobernanza y seguridad del resto del informe no se ve afectada y se sostiene por sí sola.
  • La ausencia de un hallazgo no es un certificado. Una compra lenta y distribuida a lo largo de meses no produce picos, y esta evaluación no la verá.

Cómo mejorar el valor

Nada de lo que se haga en un repositorio puede mejorar este resultado, y esa es precisamente la idea: la evaluación lee un historial que ya ha ocurrido. Un proyecto cuyo crecimiento fue genuino ya se lee como orgánico.

Relacionado: popularidad · comunidad y adopción · señales, no garantías

Dónde se ha encontrado

25 repositorios del registro público presentan este hallazgo.

Ver los 25 en el catálogo