Pesquisa de site

8 ideias para medir o uso de software de código aberto


Quer saber como coletar métricas de uso para seu projeto de software de código aberto? Considere os prós e os contras de usar essas alternativas.

Aqueles de nós que apoiam comunidades de projetos de código aberto são frequentemente questionados sobre métricas de uso – e muito. O objetivo dessas métricas geralmente é demonstrar a importância do software medida pela sua base de usuários e conhecimento. Normalmente queremos saber: quantas pessoas usam o software, quantas instalações existem e quantas vidas estão sendo tocadas.

Para resumir uma longa história: não podemos responder diretamente a estas perguntas.

Lamento desapontá-lo se você esperava uma solução definitiva. Ninguém tem as respostas perfeitas para perguntas sobre métricas de uso. Pelo menos, não há respostas precisas.

A boa notícia é que existem aproximações e métricas alternativas que podem satisfazer sua sede de conhecimento sobre o uso do software, pelo menos parcialmente. Este artigo explora essas alternativas, incluindo seus benefícios e deficiências.

Transferências

Ao visitar sites que oferecem software, muitas vezes você pode ver quantas vezes o software foi baixado. Um exemplo que vem à mente é o Firefox, que costumava ter um contador de downloads. Era um número impressionante e dava a impressão de que o Firefox era um navegador popular – o que foi por um tempo.

No entanto, o comportamento individual pode impactar diretamente na precisão desse número. Por exemplo, quando uma pessoa limpa sua máquina regularmente, cada reconstrução gera um download separado. Para dar conta dessa realidade, é necessário que haja uma maneira de subtrair algumas dezenas (talvez centenas) de downloads do número por causa daquela pessoa.

Os downloads não apenas podem superestimar o uso, mas também subestimar o uso. Por exemplo, um administrador de sistema pode baixar uma nova versão do Firefox uma vez para uma unidade flash e depois instalá-la em centenas de dispositivos.

As métricas de download são fáceis de coletar porque você pode registrar cada solicitação de download no servidor. O problema é que você não sabe o que acontece com o software depois de baixado. A pessoa conseguiu usar o software conforme previsto? Ou a pessoa teve problemas e abandonou o software?

Para projetos de código aberto, você pode considerar uma variedade de métricas de download, como o número de binários baixados de:

  • o site do projeto
  • gerenciadores de pacotes como npm, PyPi e Maven
  • repositórios de código como GitHub, GitLab e Gitee

Você também pode estar interessado em baixar o código-fonte porque os projetos downstream provavelmente usarão esse formato (leia também Como medir o impacto do seu projeto de código aberto). As métricas de download relevantes incluem:

  • O número de clones (downloads de código-fonte) de repositórios de código como GitHub, GitLab e Gitee
  • O número de arquivos (tar, zip) baixados do site
  • O número de downloads de código-fonte por meio de gerenciadores de pacotes como npm, PyPi e Maven

As métricas de download do código-fonte são uma medida ainda menos confiável do que os downloads binários (embora não haja pesquisas para demonstrar isso). Imagine que um desenvolvedor deseja usar a versão mais recente do seu código-fonte e configurou seu pipeline de construção para sempre clonar seu repositório para cada construção. Agora imagine que um processo de construção automatizado estava falhando e tentando construir novamente, clonando constantemente seu repositório. Você também pode imaginar um cenário em que a métrica seja menor do que o esperado – digamos que o repositório esteja armazenado em cache em algum lugar e os downloads sejam atendidos pelo cache.

[Leitura relacionada 5 métricas para monitorar em sua comunidade de código aberto]

Concluindo, as métricas de download são bons substitutos para detectar tendências e fornecer contexto sobre o uso atual. Não podemos definir especificamente como um download se traduz em uso. Mas podemos dizer que um aumento nos downloads é um indicador de mais usuários potenciais. Por exemplo, se você anunciar seu software e perceber que o número de downloads é maior durante a campanha, seria justo presumir que o anúncio levou mais pessoas a baixar o software. A origem e os metadados do download também podem fornecer contexto adicional para padrões de uso. Quais versões do seu software ainda estão em uso? Quais sistemas operacionais ou versões específicas de idioma são mais populares? Isso ajuda a comunidade a priorizar quais plataformas apoiar e testar.

Problemas

Como um projeto de código aberto, você provavelmente possui um rastreador de problemas. Quando alguém abre um problema, dois objetivos comuns são relatar um bug ou solicitar um recurso. O autor do problema provavelmente usou seu software. Como usuário, eles teriam encontrado um bug ou identificado a necessidade de um novo recurso.

Obviamente, a maioria dos usuários não dá um passo extra para registrar um problema. Os autores das edições são usuários dedicados e somos gratos por eles. Além disso, ao abrir um problema, eles se tornaram contribuidores não-código. Eles podem se tornar contribuidores de código. Uma regra prática é que para cada 10.000 usuários, você pode ter 100 que abrem um problema e um que contribui com código. Dependendo do tipo de usuário, essas proporções podem ser diferentes.

Com relação às métricas, você pode contar o número de autores de problemas como uma estimativa de limite inferior para uso. As métricas relacionadas podem incluir:

  • O número de autores da edição
  • O número de autores de fascículos ativos (abriram um fascículo nos últimos 6 meses)
  • O número de autores de problemas que também contribuem com código
  • O número de questões abertas
  • O número de comentários sobre o problema escritos

Listas de discussão de usuários, fóruns e sites de perguntas e respostas

Muitos projetos de código aberto têm listas de discussão para usuários, um fórum e presença em um site de perguntas e respostas, como o Stack Overflow. Semelhante aos autores dos problemas, as pessoas que postam ali podem ser consideradas a ponta do iceberg dos usuários. Métricas sobre o quão ativa uma comunidade é nessas listas de e-mail, fóruns e sites de perguntas e respostas também podem ser usadas como proxy para aumentar ou diminuir a base de usuários. As métricas relacionadas podem se concentrar na atividade nesses locais, incluindo:

  • O número de assinantes da lista de discussão de usuários
  • O número de usuários do fórum
  • O número de perguntas feitas
  • O número de respostas fornecidas
  • O número de mensagens criadas

Recurso de chamada residencial

Para obter contagens precisas de usuários, uma ideia é fazer com que seu software reporte quando estiver em uso.

Isso pode ser assustador. Imagine um administrador de sistema cujo firewall reporta uma conexão inesperada ao seu servidor. O relatório não apenas nunca chegará até você (foi bloqueado), mas seu software poderá ser banido para uso futuro.

Maneiras responsáveis de ter um recurso de call home é um serviço opcional para procurar atualizações e informar ao usuário para usar a versão mais recente. Outro recurso opcional pode se concentrar na telemetria de uso, onde você pergunta ao usuário se o seu software pode, anonimamente, relatar como o software é usado. Quando implementada cuidadosamente, esta abordagem pode permitir que os usuários ajudem a melhorar o software pelo seu estilo de uso. Um usuário pode ter a opinião: "Muitas vezes não permito esse compartilhamento de informações de uso, mas para alguns softwares eu permito porque espero que os desenvolvedores o tornem melhor para mim no longo prazo."

Estrelas e garfos

Estrelas e garfos são recursos em plataformas de codificação social como GitHub, GitLab e Gitee. Os usuários dessas plataformas podem estrelar um projeto. Por que eles estrelam projetos? A documentação do GitHub explica: “Você pode marcar repositórios e tópicos com estrela para acompanhar os projetos que achar interessantes e descobrir conteúdo relacionado em seu feed de notícias”. Marcar com estrela equivale a marcar como favorito e também fornece uma maneira de mostrar apreço ao mantenedor do repositório. As estrelas têm sido usadas como um indicador da popularidade de um projeto. Quando um projeto tem um grande anúncio que atrai bastante atenção, a contagem de estrelas tende a aumentar. A métrica estrela não indica o uso do software.

Os garfos nessas plataformas de codificação social são clones de um repositório. Os não mantenedores podem fazer alterações em seu fork e enviá-los para revisão por meio de uma solicitação pull. Os garfos refletem mais o tamanho da comunidade do que as estrelas. Os desenvolvedores também podem bifurcar um projeto para salvar uma cópia que possam acessar mesmo depois que o repositório original tiver desaparecido. Devido ao uso de forks no fluxo de trabalho de contribuição, a métrica é um bom indicador para a comunidade de desenvolvedores. Os forks normalmente não indicam o uso por não desenvolvedores porque os não desenvolvedores geralmente não criam bifurcações.

Mídia social

As plataformas de mídia social oferecem locais de encontro para pessoas com interesses comuns, incluindo Facebook, Instagram, LinkedIn, Reddit, Twitter e muito mais. Utilizando uma estratégia de mídia social, projetos de código aberto podem atrair pessoas com interesse e afinidade para seus projetos, através da criação de respectivos espaços de encontro nessas plataformas. Através destes canais de mídia social, os projetos de código aberto podem compartilhar notícias e atualizações e destacar colaboradores e usuários. Eles também podem ser usados para conhecer pessoas que de outra forma não interagiriam com seu projeto.

Hesitamos em sugerir as seguintes métricas porque elas não têm uma conexão clara com o uso real do seu software e muitas vezes exigem análise de sentimentos positivos, negativos e neutros. As pessoas podem ficar entusiasmadas com o seu projeto por diversos motivos e querer segui-lo sem realmente usá-lo. Porém, assim como outras métricas já discutidas, mostrar que você consegue atrair multidões nos espaços das redes sociais é um indicador do interesse geral pelo seu projeto. As métricas para diferentes plataformas de mídia social podem incluir:

  • O número de seguidores ou assinantes
  • O número de mensagens
  • O número de autores de mensagens ativas
  • O número de curtidas, compartilhamentos, reações e outras interações

Análise e documentação da web

O tráfego do site também é uma métrica útil. Essa métrica é mais influenciada por suas atividades de divulgação e marketing do que pelo número de usuários. No entanto, temos um ás na manga: nossa documentação de usuário, tutoriais, manuais e documentação de API. Podemos ver quais tópicos em nosso site chamam a atenção, inclusive a documentação. O número de visitantes da documentação provavelmente aumentaria com o aumento do número de usuários discretos do software. Podemos, portanto, detectar o interesse geral no projeto entre os visitantes do site e, mais especificamente, observar as tendências dos usuários observando os visitantes da documentação. As métricas podem incluir:

  • O número de visitantes do site
  • O número de visitantes de documentação
  • O tempo que os visitantes passam em seu site ou na documentação

Eventos

As métricas de eventos estarão disponíveis se você estiver hospedando eventos em torno do seu projeto. Esta é uma ótima maneira de construir uma comunidade. Quantas pessoas enviam resumos para falar em seus eventos? Quantas pessoas comparecem aos seus eventos? Isso pode ser interessante tanto para eventos presenciais quanto virtuais. É claro que a forma como você anuncia seu evento influencia fortemente o número de pessoas que comparecem. Além disso, você pode co-localizar seu evento com um evento maior, onde as pessoas viajam de qualquer maneira e, portanto, estão na cidade e podem participar facilmente do seu evento. Contanto que você use uma estratégia de evento consistente, você pode argumentar que um aumento nas inscrições de palestrantes e nas inscrições de participantes é indicativo de aumento de popularidade e base de usuários.

Você não precisa organizar seu próprio evento para coletar métricas esclarecedoras. Se você organizar palestras sobre seu projeto em eventos de código aberto, poderá medir quantas pessoas comparecerão à sua sessão focadas no seu projeto. Em eventos como o FOSDEM, algumas palestras são focadas especificamente em atualizações ou anúncios de projetos de código aberto e as salas ficam lotadas (como quase todas as sessões do FOSDEM).

Métricas que você pode considerar:

  • O número de participantes em seu evento centrado no projeto
  • O número de palestras enviadas para o seu evento centrado no projeto
  • O número de participantes em suas palestras centradas no projeto

Conclusão sobre a aproximação do uso de software de código aberto

Conforme ilustramos, existem muitas métricas que podem indicar tendências em torno do uso do seu software, e todas são imperfeitas. Na maioria dos casos, essas métricas podem ser fortemente influenciadas pelo comportamento individual, pelo design do sistema e pelo ruído. Como tal, sugerimos que nunca utilize nenhuma destas métricas isoladamente, dada a relativa incerteza de cada uma. Mas se você coletar um conjunto de métricas de diversas fontes, deverá ser capaz de detectar tendências de comportamento e uso. Se você tiver meios para comparar o mesmo conjunto de métricas em vários projetos de código aberto com pontos em comum — como funcionalidades semelhantes, fortes interdependências, hospedados na mesma base e outras características — você poderá melhorar seu senso de linhas de base comportamentais.

Observe que nesta visão geral também optamos por destacar métricas que avaliam o uso direto. Como a maioria dos softwares depende de vários outros pacotes de software, seríamos negligentes se não mencionássemos que o uso e o comportamento também podem ser fortemente impactados pelo uso indireto como parte de uma cadeia de dependência. Como tal, recomendamos incorporar a contagem de dependências upstream e downstream como outra camada de contexto na sua análise.

Para encerrar, como detentor de dados e métricas, encorajamos você a reconhecer o poder e a responsabilidade que tem para com seus stakeholders. Qualquer métrica publicada tem o potencial de influenciar o comportamento. É uma prática recomendada sempre compartilhar seu contexto – bases, fontes, estimativas e outras informações contextuais críticas – pois isso ajudará outras pessoas a interpretar seus resultados.

Agradecemos à Comunidade CHAOSS pela conversa esclarecedora na CHAOSScon EU 2022 em Dublin, Irlanda, que gerou a ideia para esta postagem no blog, e aos membros da Comunidade CHAOSS que revisaram e ajudaram a melhorar este artigo.

Artigos relacionados: