Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering

Imagina el internet como una biblioteca gigante y caótica donde cualquiera puede construir un estante y llamarlo biblioteca. Este es el mundo del Software de Código Abierto (OSS, por sus siglas en inglés), un enorme patio de juegos digital donde millones de personas —desde estudiantes probando nuevas ideas de programación hasta desarrolladores profesionales construyendo la próxima gran aplicación— almacenan sus proyectos. Los investigadores, que son como detectives tratando de resolver misterios sobre cómo funciona el software, aman visitar esta biblioteca. Escudriñan los estantes, observando cuántas personas le dieron "me gusta" a un proyecto (estrellas), cuántas veces la gente cambió los libros (commits) y cuántas personas ayudaron a escribirlos. Estas pistas les ayudan a comprender los secretos de la ingeniería de software. Pero aquí está el truco: la biblioteca es tan grande que está llena de cajas vacías, maniquíes de prueba y garabatos a medio terminar. Para encontrar los libros "reales", los investigadores suelen desechar cualquier cosa que no parezca popular o activa. Utilizan reglas como: "Si un proyecto no tiene al menos 10 estrellas, es solo ruido, así que desechémoslo".

Pero, ¿qué pasaría si esas reglas estuvieran desechando las historias más interesantes? ¿Qué pasaría si, en nuestro afán por limpiar la biblioteca, accidentalmente ocultáramos el hecho de que la mayoría de los libros están en realidad abandonados, o que solo terminamos leyendo los escritos por los mismos pocos autores famosos? Esta es la gran pregunta que los investigadores Mohit Kaushik y Jyoti Bawa se están planteando. Les preocupa que los mismos filtros que los científicos usan para que sus datos sean "limpios" puedan estar haciendo que sus hallazgos sean "sucios" al ocultar la realidad verdadera y desordenada de cómo viven y mueren los proyectos de software.

El Gran Filtro: ¿Limpiar los Datos o Esconder la Verdad?

En este estudio, los autores decidieron jugar un juego de "¿Qué pasaría si...?" con una enorme pila de datos. Observaron 1.57 millones de repositorios de software de una plataforma llamada SEART. Piensa en este conjunto de datos como un cubo gigante de piezas de LEGO mezcladas. Algunas son enormes y coloridos castillos; otras son diminutos ladrillos rojos individuales; y muchas son solo piezas rotas que nadie terminó nunca.

Normalmente, los investigadores miran este cubo y dicen: "Bien, solo queremos los grandes castillos terminados. Desechemos cualquier cosa con menos de 10 estrellas (me gusta) o menos de 10 commits (cambios)". Los autores probaron qué sucede cuando aplican estas reglas estrictas, como subir el volumen de un filtro hasta que se vuelve muy fuerte.

El Costo Oculto de la "Popularidad"
Cuando los investigadores aplicaron un "filtro de popularidad" (buscando solo proyectos con más estrellas), descubrieron algo sorprendente. A medida que elevaban el umbral de estrellas de 10 a 1,000, el proyecto "promedio" en su muestra no solo se volvió ligeramente mejor; se hizo 7 veces más grande. Los proyectos se volvieron más antiguos, tenían más personas trabajando en ellos y tenían mucha más probabilidad de tener una licencia formal (como un libro de reglas).

Pero aquí está el giro: al perseguir los proyectos populares, perdieron completamente de vista la realidad. En su cubo original, sin filtrar, el 73.42% de los proyectos estaban en realidad inactivos o "abandonados". Sin embargo, a medida que filtraban por popularidad, este número disminuyó. Para cuando solo observaron los proyectos súper populares (más de 1,000 estrellas), los datos hacían parecer que solo el 50.65% estaban abandonados. El filtro no solo eliminó el ruido; ocultó el hecho de que la mayoría de los proyectos fallan o son dejados atrás. Es como si solo le preguntaras a las personas más exitosas de una ciudad sobre sus empleos, y luego concluyeras que "el desempleo es bajo" porque nunca hablaste con las personas que perdieron sus trabajos.

La Trampa de la "Actividad"
Los autores también probaron "filtros de actividad", que mantienen solo los proyectos con un alto número de commits (cambios). Esto fue aún más extremo. Cuando filtraron por alta actividad, ¡el tamaño promedio del proyecto creció 18 veces! Estos filtros también cambiaron la "personalidad" del software. Por ejemplo, los proyectos que usaban el lenguaje C++ eran comunes en los grupos de umbral bajo, pero desaparecieron de los 5 principales cuando el filtro se volvió estricto. Mientras tanto, TypeScript y Go se volvieron mucho más comunes en las listas filtradas.

El estudio sugiere que estos filtros no son neutrales. Actúan como un tamiz que solo deja pasar tipos específicos de proyectos: proyectos de infraestructura más antiguos, enormes y bien financiados. Expulsan los proyectos más pequeños, nuevos o experimentales, incluso si esos proyectos más pequeños son reales y activos.

El Fraude de la Relación
Quizás el hallazgo más lúdico (y peligroso) trata sobre cómo estos filtros alteran las relaciones entre diferentes cosas. Imagina que estás tratando de averiguar si "trabajar duro" (commits) conduce a "ser popular" (estrellas). En el mundo real y desordenado (los datos base), estas dos cosas están solo débilmente conectadas. Pero cuando los investigadores aplicaron sus filtros, la conexión de repente pareció súper fuerte.

Por ejemplo, el vínculo entre "commits" y "tamaño del proyecto" saltó de un moderado 0.466 a un muy fuerte 0.808 en el grupo filtrado por actividad. Los autores explican que esto no es porque los proyectos hayan cambiado realmente, sino porque el filtro forzó que se vieran de esa manera. Al mantener solo los proyectos grandes y ocupados, el filtro hizo que pareciera que "los proyectos grandes siempre tienen muchos commits", cuando en realidad, la relación es mucho más complicada. Es como si solo estudiaras a los jugadores de baloncesto más altos y concluyeras que "la altura es lo único que importa en los deportes", ignorando a todos los demás.

El Veredicto: No Deseches el Ruido Simplemente

Los autores concluyen que, si bien necesitamos limpiar nuestros datos, no podemos usar reglas arbitrarias como "10 estrellas" o "500 commits" sin pensar. Estas reglas son como un martillo romo: destrozan el "ruido", pero también destrozan la verdad. Crean una imagen distorsionada donde los proyectos de software parecen más exitosos, más antiguos y más uniformes de lo que realmente son.

En lugar de filtrar ciegamente, los autores sugieren que los investigadores utilicen el muestreo estratificado. Imagina tomar una cucharada del cubo de LEGO que tenga una mezcla justa de grandes castillos, casas pequeñas y piezas rotas, en lugar de solo elegir los castillos más grandes. También instan a los científicos a repensar qué cuenta como "ruido". Tal vez un proyecto con cero estrellas no es solo un experimento fallido; tal vez es una joya oculta que aún no ha sido descubierta.

En resumen, este artículo nos advierte que, en nuestra prisa por encontrar los datos "perfectos", podríamos estar construyendo un castillo de naipes que se ve perfecto por fuera, pero que colapsa en el momento en que intentamos comprender el mundo real y desordenado del software. Los autores no dicen que debamos dejar de filtrar por completo, pero sugieren enfáticamente que dejemos de usar estas reglas de "talla única" y comencemos a ser más cuidadosos con lo que estamos desechando.