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

Imagine a internet como uma biblioteca gigante e caótica onde qualquer pessoa pode construir uma estante e chamá-la de biblioteca. Este é o mundo do Software de Código Aberto (OSS), um enorme parquinho digital onde milhões de pessoas — desde estudantes testando novas ideias de programação até desenvolvedores profissionais construindo o próximo grande aplicativo — armazenam seus projetos. Pesquisadores, que são como detetives tentando resolver mistérios sobre como o software funciona, adoram visitar esta biblioteca. Eles vasculham as prateleiras, observando quantas pessoas "curtiram" um projeto (estrelas), quantas vezes as pessoas alteraram os livros (commits) e quantas pessoas ajudaram a escrevê-los. Essas pistas os ajudam a entender os segredos da engenharia de software. Mas aqui está o problema: a biblioteca é tão grande que está cheia de caixas vazias, manequins de teste e rabiscos inacabados. Para encontrar os livros "reais", os pesquisadores geralmente jogam fora tudo o que não parece popular ou movimentado o suficiente. Eles usam regras como: "Se um projeto não tem pelo menos 10 estrelas, é apenas ruído, então vamos descartá-lo".

Mas e se essas regras estiverem jogando fora as histórias mais interessantes? E se, em nosso desespero para limpar a biblioteca, acabemos acidentalmente escondendo o fato de que a maioria dos livros é, na verdade, abandonada, ou que acabamos lendo apenas os escritos pelos mesmos poucos autores famosos? Esta é a grande questão que os pesquisadores Mohit Kaushik e Jyoti Bawa estão fazendo. Eles estão preocupados que os próprios filtros que os cientistas usam para tornar seus dados "limpos" possam estar tornando suas descobertas "sujas" ao esconder a realidade verdadeira e caótica de como os projetos de software realmente vivem e morrem.

O Grande Filtro: Limpando os Dados ou Escondendo a Verdade?

Neste estudo, os autores decidiram jogar um jogo de "E se?" com uma pilha massiva de dados. Eles analisaram 1,57 milhão de repositórios de software de uma plataforma chamada SEART. Pense neste conjunto de dados como um balde gigante de peças de LEGO misturadas. Algumas são conjuntos de castelos enormes e coloridos; outras são apenas pequenos tijolos vermelhos; e muitas são apenas peças quebradas que ninguém jamais terminou.

Normalmente, os pesquisadores olham para este balde e dizem: "Ok, só queremos os grandes castelos terminados. Vamos jogar fora qualquer coisa com menos de 10 estrelas (curtidas) ou menos de 10 commits (alterações)". Os autores testaram o que acontece quando aplicam essas regras estritas, como aumentar o volume de um filtro até que ele fique muito alto.

O Custo Escondido da "Popularidade"
Quando os pesquisadores aplicaram um "filtro de popularidade" (olhando apenas para projetos com mais estrelas), descobriram algo surpreendente. Ao aumentarem o limite de estrelas de 10 para 1.000, o projeto "médio" em sua amostra não ficou apenas ligeiramente melhor; ele ficou 7 vezes maior. Os projetos tornaram-se mais antigos, tinham mais pessoas trabalhando neles e eram muito mais propensos a ter uma licença formal (como um livro de regras).

Mas aqui está a reviravolta: ao perseguir os projetos populares, eles perderam completamente a visão da realidade. Em seu balde original, sem filtros, 73,42% dos projetos estavam, na verdade, inativos ou "abandonados". No entanto, conforme filtraram pela popularidade, esse número caiu. No momento em que passaram a olhar apenas para os projetos superpopulares (1.000+ estrelas), os dados faziam parecer que apenas 50,65% estavam abandonados. O filtro não removeu apenas o ruído; ele escondeu o fato de que a maioria dos projetos realmente falha ou é deixada para trás. É como se você perguntasse apenas às pessoas de maior sucesso em uma cidade sobre seus empregos e, então, concluísse que "o desemprego é baixo" porque você nunca falou com as pessoas que perderam seus empregos.

A Armadilha da "Atividade"
Os autores também testaram "filtros de atividade", que mantêm apenas projetos com um alto número de commits (alterações). Isso foi ainda mais extremo. Quando filtraram por alta atividade, o tamanho médio do projeto cresceu 18 vezes! Esses filtros também mudaram a "personalidade" do software. Por exemplo, projetos usando a linguagem C++ eram comuns nos grupos de limiar inferior, mas desapareceram do top 5 quando o filtro tornou-se rigoroso. Enquanto isso, TypeScript e Go tornaram-se muito mais comuns nas listas filtradas.

O estudo sugere que esses filtros não são neutros. Eles agem como um peneira que só deixa passar tipos específicos de projetos: projetos de infraestrutura mais antigos, gigantes e bem financiados. Eles expulsam os projetos menores, mais novos ou mais experimentais, mesmo que esses projetos menores sejam reais e ativos.

A Bagunça das Relações
Talvez a descoberta mais lúdica (e perigosa) seja sobre como esses filtros bagunçam as relações entre diferentes coisas. Imagine que você está tentando descobrir se "trabalhar duro" (commits) leva a "ser popular" (estrelas). No mundo real e caótico (os dados de base), essas duas coisas estão apenas fracamente conectadas. Mas quando os pesquisadores aplicaram seus filtros, a conexão subitamente pareceu super forte.

Por exemplo, o vínculo entre "commits" e "tamanho do projeto" saltou de um moderado 0,466 para um fortíssimo 0,808 no grupo filtrado por atividade. Os autores explicam que isso não acontece porque os projetos realmente mudaram; é porque o filtro forçou que eles parecessem assim. Ao manter apenas os projetos grandes e ocupados, o filtro fez parecer que "projetos grandes sempre têm muitos commits", quando, na realidade, a relação é muito mais complicada. É como se você estudasse apenas os jogadores de basquete mais altos e concluísse que "a altura é a única coisa que importa nos esportes", ignorando todos os outros.

O Veredito: Não Jogue Fora o Ruído Assim Nada Mais

Os autores concluem que, embora precisemos limpar nossos dados, não podemos simplesmente usar regras arbitrárias como "10 estrelas" ou "500 commits" sem pensar. Essas regras são como um martelo bruto: elas esmagam o "ruído", mas também esmagam a verdade. Elas criam uma imagem distorcida onde os projetos de software parecem mais bem-sucedidos, mais antigos e mais uniformes do que realmente são.

Em vez de filtrar cegamente, os autores sugerem que os pesquisadores utilizem a amostragem estratificada. Imagine pegar uma concha do balde de LEGO que tenha uma mistura justa de grandes castelos, pequenas casas e peças quebradas, em vez de apenas escolher os maiores castelos. Eles também instam os cientistas a repensar o que conta como "ruído". Talvez um projeto com zero estrelas não seja apenas um experimento fracassado; talvez seja uma joia escondida que ainda não foi descoberta.

Em suma, este artigo nos alerta que, em nossa pressa para encontrar os dados "perfeitos", podemos estar construindo uma casa de cartas que parece perfeita por fora, mas que desmorona no momento em que tentamos entender o mundo real e caótico do software. Os autores não dizem que devemos parar de filtrar inteiramente, mas sugerem fortemente que paremos de usar essas regras de "tamanho único" e comecemos a ser mais cuidadosos com o que estamos jogando fora.