The State of Open Science in Software Engineering Research: A Case Study of ICSE Artifacts
Este estudo avalia 100 pacotes de replicação do ICSE (2015-2024), revelando que apenas 40% eram totalmente executáveis e, destes, apenas 35% reproduziram os resultados originais, evidenciando uma lacuna crítica entre disponibilidade, executabilidade e reprodutibilidade que exige diretrizes aprimoradas para a ciência aberta em Engenharia de Software.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que a ciência da computação é como uma grande comunidade de cozinheiros. Quando um chef cria uma receita incrível (um novo software ou descoberta científica), a "ciência aberta" diz que ele deve compartilhar a receita com todo mundo. A ideia é que, se você tiver a receita, pode tentar cozinhar o prato em sua própria cozinha para ver se fica tão bom quanto o original.
Este artigo é como um grande teste de sabor feito por três pesquisadores da Universidade de Saskatchewan. Eles pegaram 100 "receitas" (pacotes de replicação) de um dos maiores congressos de engenharia de software do mundo (o ICSE) e tentaram cozinhar cada uma delas para ver o que acontecia.
Aqui está o resumo do que eles descobriram, usando analogias do dia a dia:
1. O Problema: A Receita vs. O Prato Real
Muitos pesquisadores dizem: "Aqui está meu código, experimentem!" (Disponibilidade). Mas a pergunta real é: "Eles conseguem realmente fazer o prato funcionar na minha cozinha?" (Executabilidade e Reprodutibilidade).
Os pesquisadores descobriram que, embora a maioria dos autores compartilhe a receita, muitas vezes ela está incompleta ou confusa.
2. O Que Eles Fizeram (O Teste)
Eles gastaram cerca de 650 horas (o equivalente a um ano inteiro de trabalho de uma pessoa) tentando rodar esses 100 códigos em computadores limpos e isolados. Eles agiram como "detetives de software", tentando seguir as instruções dos autores originais.
3. Os Resultados Surpreendentes
- Apenas 40% funcionaram: De cada 100 receitas, apenas 40 conseguiram ser "cozinhadas" até o fim. As outras 60 deram errado de alguma forma.
- O esforço foi enorme: Mesmo nas 40 que funcionaram, a maioria exigiu muito trabalho extra.
- Apenas 32,5% funcionaram "direto da caixa" (sem precisar de ajustes).
- Para os outros, os pesquisadores tiveram que:
- Trocar ingredientes (atualizar bibliotecas).
- Corrigir medidas (ajustar caminhos de arquivos).
- Reescrever partes da receita (mudar o código).
- Às vezes, tiveram que gastar horas tentando descobrir por que o fogão não acendia (problemas de ambiente).
- O Prato Final não era igual: Mesmo quando conseguiam fazer o código rodar, apenas 35% dos resultados finais eram iguais aos que os autores originais afirmaram ter obtido. É como tentar fazer um bolo e, no final, ele ter um gosto totalmente diferente do que o livro de receitas prometia.
4. Por Que Tudo Isso Dá Errado? (Os Obstáculos)
Os pesquisadores identificaram três grandes "vilões" que impedem o sucesso:
- A Cozinha Diferente (Problemas de Ambiente): O autor original usou um computador específico com um sistema operacional antigo e uma placa de vídeo potente. O pesquisador que tenta replicar usa um computador moderno e diferente. Sem instruções claras de como adaptar a receita para a nova cozinha, o prato queima.
- A Receita Mal Escrita (Documentação): Muitas vezes, faltam passos. "Adicione o açúcar" está escrito, mas não diz quanto açúcar, nem quando adicioná-lo. Ou pior: a receita diz "use o ingrediente secreto", mas não diz qual é.
- Ingredientes Expirados (Código Desatualizado): O código foi escrito há 5 anos. As ferramentas que ele usa hoje não existem mais ou mudaram completamente. É como tentar usar uma receita de 1990 que pede um tipo de farinha que ninguém mais fabrica.
5. A Solução Proposta (As 3 Regras de Ouro)
Para consertar isso, os autores sugerem três regras simples para os cientistas que compartilham seus códigos:
- Regra 1: Escreva uma Receita Completa. Não basta jogar os ingredientes na mesa. É preciso listar: qual cozinha (sistema operacional) usar, quais utensílios (ferramentas) são necessários, o passo a passo exato e como saber se o prato ficou bom (validação).
- Regra 2: Teste em uma Cozinha Limpa. Antes de publicar, o autor deve testar a receita em um computador que não seja o dele. Se funcionar lá, significa que a receita é boa e não depende de "segredos" que só o autor conhece.
- Regra 3: Entregue a "Caixa de Ferramentas" e o "Manual". O ideal é entregar o código fonte (para quem quer entender como funciona) E uma "caixa fechada" (um container/Docker) que já vem com tudo configurado pronto para usar. Assim, qualquer pessoa pode abrir a caixa e cozinhar, independentemente de qual cozinha ela tenha.
Conclusão
O estudo mostra que, embora a comunidade de software esteja compartilhando cada vez mais seus trabalhos (o que é ótimo), a qualidade prática desses compartilhamentos ainda é baixa.
Muitas vezes, o código é como um carro que parece novo por fora, mas não tem motor por dentro. Para que a ciência seja verdadeiramente "aberta" e útil, não basta apenas colocar o código na internet; é preciso garantir que ele possa ser usado, verificado e reutilizado por qualquer pessoa, sem que ela precise virar um mecânico especialista para consertá-lo.
Os autores criaram um guia prático para ajudar pesquisadores e organizadores de conferências a fazerem isso, garantindo que o futuro da ciência seja mais transparente e confiável.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.