Auditei 25 dos meus repositórios de código aberto. As estrelas mentiram.

Um amigo me perguntou ontem como está o lado de código aberto do estúdio. Eu verifiquei o GitHub. O repositório principal tinha cinco estrelas. A maioria tinha zero. Eu quase respondi "sim, um começo lento, nada para ver ainda."

Então eu realmente analisei os números. 3.681 instalações npm no mês passado em 15 pacotes. 254 instalações PyPI em uma biblioteca com seis dias de idade. 12 forks. De 30 a 40 visitantes únicos por semana nos cinco principais repositórios. Usuários reais abrindo problemas reais são zero, o que significa que ou nada está quebrado ou ninguém está reclamando ainda, e as contagens de instalação dizem que é a segunda opção.

Então eu me sentei e auditei todos os 25 repositórios públicos em uma sessão. Aqui está o que eu encontrei, o que eu consertei e por que as estrelas do GitHub são basicamente o número errado a se olhar quando você está cinco semanas enviando.

A configuração

Há cinco semanas, comecei a enviar o trabalho do StudioMeyer MCP para repositórios públicos. Memória, CRM, GEO, Crew e uma pilha crescente de pilares de fundação sob o guarda-chuva da MCP Factory. Ferramentas de teste para a especificação do Protocolo de Contexto do Modelo, middleware de segurança em TypeScript e Python, um sidecar Rust contra envenenamento de mercado, templates n8n, alguns repositórios de ferramentas. Vinte e cinco repositórios públicos na organização studiomeyer-io no momento em que fiz a auditoria de hoje. Principalmente TypeScript, um crate Rust, um pacote Python, duas coleções de templates n8n.

A pergunta da auditoria era simples: as pessoas estão realmente usando essas coisas?

Método

Eu puxei quatro fontes de dados em paralelo e as juntei por repositório:

1. API do GitHub para estrelas, forks, observadores, problemas abertos, pull requests abertos, último push, licença, estado arquivado.
2. registro npm + npm-stat para contagens de downloads da última semana e do último mês e versão publicada atual, por pacote.
3. API crates.io para o único crate Rust, com a contagem de downloads dos últimos 90 dias e divisões por versão recente.
4. PyPI + pypistats para o único pacote Python, com os números do último mês e do último dia.

Então, para cada repositório, verifiquei as últimas três execuções do GitHub Actions, listei os alertas de segurança do Dependabot abertos, olhei as contagens de tráfego do GitHub (visualizações e clones, últimos 14 dias) e puxei todos os problemas abertos e fechados, além de PRs.

O processo todo levou cerca de trinta minutos. Estou mantendo a receita no meu sistema de memória para que eu possa executá-la novamente a cada trimestre sem pensar.

O que as estrelas disseram vs. o que os downloads disseram

O topo da lista por estrelas:

Se você parar aqui, concluiria que o trabalho não foi bem recebido. Uma média de pouco mais de uma estrela por repositório. Vários pacotes principais do MCP com zero estrelas e zero forks.

O topo da mesma lista por downloads npm nos últimos 30 dias:

Isso resulta em 3.681 instalações em 15 pacotes em 30 dias, além de 254 instalações PyPI na versão Python do ai-shield (com seis dias de idade na hora da auditoria) e 25 instalações cargo no crate Rust mcp-armor (também com seis dias de idade).

Os pacotes que enviei mais recentemente, mcp-studiomeyer-agents e mcp-stdio-shellguard, conseguiram cerca de 100 a 150 instalações na primeira semana sem nenhuma postagem no Reddit, nenhuma submissão no HN, nenhum e-mail em massa. Eles foram lançados, registrados no índice do Registro MCP, foram encontrados na busca do npm e as pessoas simplesmente os instalaram.

Estrelas e downloads não são a mesma métrica. Estrelas precisam que alguém faça login, clique e não receba nada em troca. Downloads precisam que alguém leia sobre uma ferramenta e execute npm install. A segunda opção está muito mais próxima do uso real.

Problemas, PRs, tráfego

Problemas fechados em todos os 25 repositórios: quatro. ai-shield teve dois, mcp-video teve um, local-memory-mcp teve um. Problemas abertos: zero, exceto por um ticket cosmético no mcp-academy de um tempo atrás. Isso me diz que ou as bibliotecas são estáveis o suficiente para que nada esteja quebrando para os usuários, ou ninguém está reclamando sobre bugs ainda. Provavelmente ambos, com peso maior para o primeiro, pois os conjuntos de testes são grandes e a superfície de dependência é pequena para a maioria desses pacotes.

Pull requests durante o período: 31 mescladas. A maioria são do Dependabot. Algumas são correções reais. ai-shield recebeu duas PRs reais, mcp-personal-suite recebeu nove. O fluxo do Dependabot está fazendo trabalho real em segundo plano, mantendo os arquivos de bloqueio atualizados.

Tráfego do GitHub nos últimos 14 dias, apenas visitantes únicos para que os números sejam honestos:

Trinta visitantes únicos em um repositório ao longo de duas semanas não é viral, mas também não está morto. Multiplique pelo número de repositórios e a página da organização está recebendo atenção real.

Então, a correção real

A auditoria revelou um repositório com trabalho real e alguns problemas cosméticos.

mcp-academy tinha sete alertas de segurança do Dependabot abertos. Dois de alta severidade em torno do fast-uri, quatro médios em torno da injeção de CSS do hono e vazamento de cache e bypass de bodyLimit, um baixo em torno da validação JWT do hono. Eu verifiquei o arquivo de bloqueio via API de conteúdos do GitHub e decodifiquei o base64. Ambas as dependências transitivas já estavam na versão corrigida. A varredura do Dependabot ainda não havia se propagado. Eu dispensei todos os oito alertas (um era para ip-address, também já corrigido) com a razão fix_started e um comentário mostrando o estado do arquivo de bloqueio. Também havia uma PR aberta do Dependabot aumentando o fast-uri de 3.1.0 para 3.1.2. Eu a mesclei. O HEAD do master agora é 74bf554 com zero alertas abertos.

mcp-personal-suite teve uma etapa de CI falhando em npm audit --audit-level=high. A mesma causa raiz que a do academy: tran