Interface-Variant Dynamics in Software Ecosystems: Resolver-Induced Selection and Adoption in Package Graphs

Resumen Técnico: Dinámicas de Variantes de Interfaz en Ecosistemas de Software

Planteamiento del Problema
El artículo aborda una brecha en la investigación de compatibilidad, que típicamente trata los cambios de interfaz como decisiones locales entre un único escritor (proveedor) y un lector (consumidor). Sin embargo, en las pilas de software distribuidas, estas decisiones están estructuradas por población. Cuando un proveedor introduce una variante de contrato (por ejemplo, un cambio en un protobuf, IDL o esquema JSON), el resultado no es binario, sino que está mediado a través de un grafo complejo de consumidores, dependencias transitivas y reglas de resolución de gestores de paquetes. La pregunta de ingeniería central es si una variante introducida localmente puede propagarse a través de un grafo de paquetes cliente-proveedor bajo las reglas de actualización específicas del ecosistema, o si es suprimida por conflictos del resolvedor. Los autores enmarcan esto como un problema de teoría de grafos evolutiva, donde la adopción de paquetes es un proceso de imitación en un grafo finito, pero enfatizan la necesidad de una "disciplina de identificabilidad" para asegurar que los estimadores de selección no se limiten a reetiquetar los datos que se les pide probar.

Metodología
El estudio emplea una auditoría de múltiples etapas a través de cuatro ecosistemas principales: npm, Maven Central, PyPI y crates.io.

1. Calibración e Instrumentación: Los autores establecen primero un instrumento de compatibilidad local confiable. Calibran contra tres referencias independientes: transiciones observadas de OpenTelemetry protobuf (verificadas con buf), casos de conformidad sintética de Buf-WIRE, y transiciones de IDL de ROS 2 (evaluadas con un verificador de estilo DDS-XTypes). Esto asegura que las etiquetas de "aceptar" y "rechazar" tengan un alto valor predictivo antes de ser utilizadas en afirmaciones poblacionales.
2. Sondas del Resolvedor y Estimación de Selección ($s$): La métrica central es un coeficiente de selección específico del ecosistema, $s_e$. Los autores ejecutan más de 2,100 sondas de resolución de gestores de paquetes sobre bordes de "último-rechazado" (donde una restricción del consumidor rechaza la última versión del proveedor). Miden la probabilidad de que una sonda de rechazo limpio aún se resuelva exitosamente ($\hat{r}^-$) frente a una sonda aceptada por el verificador ($\hat{r}^+$). El coeficiente de selección se calcula como $s_e = \log(\hat{r}^- / \hat{r}^+)$. Esto mide la viabilidad relativa logarítmica de un borde de frontera bajo el resolvedor del ecosistema.
3. Evaluación de Fijación hacia Adelante: Utilizando el $s_e$ medido, los autores ejecutan simulaciones de Monte Carlo de un proceso de absorción de comparación por pares sobre los grafos de paquetes observados. Calculan la probabilidad de fijación $\rho(s_e, G_e)$ y la comparan contra un benchmark neutral ($1/N$). Esto se trata explícitamente como una evaluación hacia adelante del $s$ medido, no como evidencia independiente.
4. Validación de Adopción: Para probar si el modelo de población se sostiene frente a la realidad histórica, los autores minan historiales de registros con marcas de tiempo (2,995 observaciones de lanzamientos de consumidores). Distinguen entre:
   • Diagnósticos próximos al verificador: Probar si la dirección de asignabilidad (favorecida por el proveedor vs. el consumidor) predice las brechas de adopción.
   • Predicción temporal libre de verificador: Probar si las características del canal del resolvedor (edad, resultado del resolvedor, penalización del ecosistema) predicen futuros cambios de "bloqueado-a-admitido" sin reutilizar el estado del verificador como la respuesta.

Contribuciones Clave

1. Instrumento de Asignabilidad Direccional Calibrado: Una herramienta para interfaces generadas que utiliza puertas del lado de la aceptación en lugar de etiquetas de compatibilidad no probadas, validada contra múltiples estándares externos.
2. Estimador de Selección del Resolvedor Específico del Ecosistema: Una medida cuantitativa ($s$) derivada directamente de las probabilidades de ejecución reales del gestor de paquetes, en lugar de ser asignada por vocabulario.
3. Diagnósticos de Fijación y Topología: Un análisis de grafos a escala de registro donde la fijación y los efectos de la topología ($\Delta\rho$) se reportan como consecuencias calibradas del $s$ medido, distinguiéndolos de una validación independiente.
4. Auditoría de Adopción con Datos Reservados: Una auditoría rigurosa de historiales de registros que incluye pruebas de permutación de dirección, predicciones de cambios temporales libres de verificador y comprobaciones de consistencia jerárquica entre las penalizaciones del resolvedor y las brechas de adopción.

Resultados

• Selección del Resolvedor: El estudio encuentra una selección negativa significativa (supresión) en Maven ($s \approx -1.29$), PyPI ($s \approx -2.19$) y npm ($s \approx -0.13$), lo que indica que los límites de versiones mixtas reducen drásticamente la resolución exitosa. Se encuentra que Cargo es casi neutral ($s \approx -0.007$).
• Fijación: La evaluación hacia adelante muestra que, una vez medido el $s$, la desviación del benchmark neutral $1/N$ es una consecuencia mecánica de un proceso no neutral. Los resultados sitúan las penalizaciones del resolvedor en la escala del grafo del registro, pero no prueban independientemente la hipótesis de la población.
• Señal Derivada del Verificador: Existe una fuerte señal en la dirección derivada del verificador. Los modelos que utilizan la dirección del verificador reducen significativamente el Error Absoluto Medio (MAE) en la predicción de brechas de adopción (0.07 vs. 0.43 para la mediana nula, $p=0.002$).
• Predicción Libre de Verificador: La prueba más estricta —predecir futuros cambios de admisión sin usar el estado del verificador— no muestra que las características del canal del resolvedor predigan de forma independiente la adopción futura. El modelo del canal del resolvedor (Brier 0.28, AUC 0.51) no supera a una línea base basada solo en la edad (Brier 0.24, AUC 0.54).
• Consistencia: Un modelo jerárquico muestra una pendiente de acoplamiento positiva entre las penalizaciones del resolvedor y las estimaciones de adopción de la dirección del verificador, pero la heterogeneidad residual sigue siendo grande. Factores como la recencia del mantenimiento (proveedores activos vs. obsoletos) confunden significativamente las frecuencias de adopción.

Significancia y Reivindicaciones
El artículo no pretende haber validado independientemente que las historias de adopción de software sigan un canal de selección evolutiva específico. En su lugar, presenta una auditoría de estimador reproducible. Su significancia radica en:

• Definir el Límite de la Identificabilidad: Demuestra explícitamente dónde la evidencia del resolvedor se convierte en entrada de la población y dónde los datos actuales del registro fallan en cerrar el ciclo.
• Distinguir Señal de Reetiquetado: Separa la "fijación" (una evaluación hacia adelante de un parámetro medido) de la "evidencia" (validación independiente), evitando la confusión de ambos conceptos.
• Utilidad Diagnóstica: Confirma que la dirección derivada del verificador conlleva una señal real de adopción, pero también identifica el "punto de falla": el bucle del resolvedor hacia la adopción es medible y diagnosticable, pero aún no está cerrado por la instantánea actual de los datos. El trabajo convierte la evolución de las interfaces de un ejercicio de reetiquetado descriptivo en un pipeline de estimación falsable, mientras reporta honestamente las limitaciones de los datos actuales para predecir la adopción futura basándose únicamente en la mecánica del resolvedor.