Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

O software moderno raramente é construído do zero. Em vez disso, ele é montado como uma estrutura massiva feita de partes pré-fabricadas, onde cada parte é um pequeno pedaço de código escrito por outra pessoa. No mundo do JavaScript, o sistema que mantém essas partes unidas é chamado de npm, um armazém digital onde desenvolvedores baixam esses pacotes de código para construir desde sites até aplicativos móveis. A maioria dessas partes é mantida por voluntários que trabalham nelas em seu tempo livre. Quando um voluntário para de trabalhar em uma parte, esse pedaço de código torna-se dormente. Ele não quebra imediatamente, mas para de receber atualizações, correções de erros ou patches de segurança. Isso cria um risco oculto: se uma parte amplamente utilizada para de ser atualizada, os milhares de projetos que dependem dela ficam com um componente que não pode ser reparado se algo der errado. A questão não é apenas se essas partes param de ser atualizadas, mas quantos deles estão realmente dormentes, quantas pessoas os estão usando e se as pessoas que os utilizam sabem que devem parar de usá-los.

Um pesquisador chamado Revanth Krishna Maddula propôs-se a examinar as partes mais populares neste sistema. Ele analisou quase dezesseis mil pacotes que são baixados pelo menos um milhão de vezes por semana. Estes são os componentes centrais do ecossistema JavaScript, as partes que detêm o maior peso. Ao estudar o histórico completo desses pacotes até outubro de 2026, ele quis ver quantos pararam de lançar novas versões, quantas pessoas ainda os estavam usando e como o sistema reagia quando uma parte silenciava. O estudo focou em uma definição específica de dormência: um pacote que não havia publicado uma versão estável e finalizada nos últimos dois anos. Esse intervalo de tempo foi escolhido para distinguir entre partes que estão simplesmente concluídas e partes que foram abandonadas.

As descobertas revelam que a dormência é muito mais comum do que muitos poderiam esperar. Ao final do período de estudo, quase trinta e cinco por cento desses principais pacotes não haviam lançado uma nova versão em dois anos. Esse silêncio não se limitou a ferramentas obscuras ou raramente usadas; ele atingiu o próprio coração do sistema. Entre os cem pacotes mais baixados, vinte e seis por cento estavam dormentes. Na verdade, alguns desses pacotes silenciosos não eram atualizados há mais de oito anos. Apesar dessa atividade generalizada, o silêncio era quase sempre ininterrupto. Quando o pesquisador verificou as notas públicas anexadas a esses pacotes, conhecidas como arquivos README, descobriu que apenas cerca de três por cento dos pacotes dormentes declaravam explicitamente que não estavam mais sendo mantidos. Na maioria das vezes, o código simplesmente parava de mudar, deixando os usuários adivinharem se o projeto estava concluído ou esquecido.

O perigo desse silêncio é que as partes ativas do sistema estão profundamente conectadas a essas partes dormentes. O estudo mapeou as relações entre os pacotes e descobriu que mais de um quarto dos pacotes mantidos ativamente dependiam diretamente de pelo menos um pacote dormente. Alguns desses pacotes silenciosos eram tão centrais que eram alcançáveis através de cadeias de dependências de mais de mil outros pacotes de alto tráfego. Muitos destes eram ferramentas pequenas e simples que poderiam ter sido concluídas anos atrás, mas outros eram módulos substanciais que formavam a base para grande parte das ferramentas de software. O problema é que os usuários não conseguem distinguir facilmente entre uma ferramenta que está terminada e uma que foi abandonada, porque o sistema não oferece um sinal claro para distinguir as duas.

Quando uma dependência fica dormente, as pessoas que a utilizam geralmente não reagem rapidamente. O estudo rastreou quanto tempo os usuários levavam para remover uma dependência de um pacote que havia parado de ser atualizado. Ao longo de um período de dois anos, os usuários removeram apenas cerca de vinte e sete por cento de suas dependências de pacotes dormentes. Essa taxa foi apenas ligeiramente superior à taxa de remoção de dependências de pacotes ativos, sugerindo que o mero fato de um pacote ter parado de ser atualizado não era suficiente para motivar uma ação. Os pesquisadores testaram se diferentes tipos de avisos alteravam esse comportamento. Eles descobriram que uma nota na documentação do projeto não teve efeito detectável sobre se os usuários removiam o pacote ou não. O único sinal que realmente causou ação nos usuários foi um aviso oficial de depreciação emitido pelo próprio registro. Quando um pacote dormente foi formalmente marcado como depreciado pelo sistema, os usuários removeram as dependências dele a uma taxa de sessenta e cinco por cento. Este aviso oficial, que aparece para os desenvolvedes quando eles instalam o software, foi o único mecanismo que conseguiu com sucesso estimular o ecossistema a se afastar do código silencioso.

Existe também uma dimensão de segurança. Embora a maioria dos pacotes dormentes não tivesse falhas de segurança conhecidas em suas versões mais recentes, aqueles que tinham estavam em uma posição precária. O estudo descobriu que um pequeno número de pacotes dormentes carregava vulnerabilidades conhecidas que não poderiam mais ser corrigidas por seus mantenedores originais. Como o código não estava mais sendo atualizado, essas falhas não podiam ser corrigidas pelo topo. Os usuários que dependiam desses pacotes tinham que removê-los, substituí-los por outras ferramentas ou corrigir as brechas de segurança eles mesmos. Esta situação destaca uma lacuna crítica no sistema: quando uma parte amplamente utilizada deixa de ser mantida, a responsabilidade por sua segurança passa inteiramente para as pessoas que a utilizam, muitas vezes sem o conhecimento delas.

O estudo conclui que a dormência é um estado normal e silencioso para uma grande parte do ecossistema de software. Não é necessariamente um defeito se uma pequena ferramenta está concluída, mas a falta de comunicação torna impossível para os usuários saberem a diferença. A pesquisa sugere que o sistema atual depende demais de os usuários adivinharem o status de suas ferramentas. A maneira mais eficaz de gerenciar este risco é para os mantenedores utilizarem o mecanismo oficial de depreciação quando pararem de trabalhar em um pacote, idealmente apontando os usuários para um substituto. Para que o ecossistema permaneça saudável, o registro precisa tornar a dormência e a depreciação mais visíveis, garantindo que o sinal chegue aos desenvolvedores que precisam vê-lo antes que um pacote silencioso se torne um problema.