Melhore a sustentabilidade da comunidade de código aberto acompanhando essas duas métricas

Concentrar-se em métricas relacionadas à propriedade e aos incentivos da comunidade pode aumentar suas chances de construir um projeto de código aberto sustentável.

No início de 2020, escrevi um artigo sobre três métricas para monitorar e medir atividades presenciais e off-line de construção de comunidade. Mal sabia eu (ou o mundo) que atividades presenciais off-line de qualquer tipo logo se tornariam inviáveis no futuro próximo.

Então, comecei a pensar: com os projetos de código aberto sendo on-line por padrão, e com todo o resto se movendo on-line e virtual, o que os criadores de tecnologias de código aberto devem medir à medida que continuamos neste mundo COVID e (espero que em breve) pós-COVID?

Há muitas métricas que você pode acompanhar — estrelas, garfos, pull requests (PRs), solicitações de mesclagem (MRs), contagens de contribuidores etc. —mas mais dados não significa necessariamente mais clareza insights. Já compartilhei anteriormente meu ceticismo sobre o valor dessas métricas de nível superficial, especialmente ao avaliar a saúde e a sustentabilidade de um projeto de código aberto.

Neste artigo, proponho duas métricas de segunda ordem para rastrear, medir e otimizar continuamente para construir uma comunidade de código aberto forte e autossustentável:

Análises dos revisores de PR ou MR
Tabelas de classificação de diferentes interações da comunidade

Por que essas métricas?

O objetivo de longo prazo de qualquer esforço de construção de comunidade de código aberto é atingir um ponto crítico onde o projeto possa sobreviver além do envolvimento diário inicial dos criadores ou mantenedores. É uma meta especialmente importante se você também estiver construindo uma empresa comercial de software de código aberto (COSS) em torno dessa tecnologia de código aberto, seja ela autoinicializada ou apoiada por capital de risco. Eventualmente, sua empresa terá que desviar recursos e o poder das pessoas para criar serviços comerciais ou recursos pagos.

É um objetivo elevado que poucos projetos alcançam. Enquanto isso, o esgotamento do mantenedor é um problema real. O exemplo mais recente e de maior destaque é o criador do Redis, Salvatore Sanfilippo, que compartilhou suas dificuldades como mantenedor de código aberto no ano passado e deixou o cargo de CEO do Redis Labs no início deste ano. Os mantenedores de vários projetos, grandes ou pequenos, enfrentam desafios semelhantes todos os dias.

Concentrar-se nas duas métricas acima, especialmente no início de sua jornada de código aberto, pode aumentar suas chances de construir algo sustentável porque elas iluminam dois elementos importantes que impulsionam a sustentabilidade: propriedade e incentivo .

Dividindo revisores de PR/MR=Propriedade

Rastrear quem na sua comunidade está revisando ativamente as contribuições é um bom indicador de propriedade. No início, você, o criador, faz a maior parte da revisão, mas isso será insustentável com o tempo. Ser intencional ao construir sua comunidade para que mais pessoas tenham o conhecimento contextual, confiança e atitude acolhedora para revisar PRs/MRs recebidos (que devem aumentar em frequência à medida que seu projeto ganha força) é crucial para o longo prazo. sustentabilidade a prazo.

Há um elemento semelhante ao atendimento ao cliente na revisão das contribuições, que pode se deteriorar se não houver um número suficiente de pessoas que se sintam responsáveis por fazê-lo. E um dos piores sinais que você pode dar a um recém-chegado entusiasmado é um PR ou MR deixado sem supervisão por duas ou mais semanas.

Placares de interação com a comunidade=Incentivo

Acompanhar algumas interações voltadas para a comunidade e possivelmente gamificá-las dentro da sua comunidade com recompensas pode ajudar a impulsionar os incentivos e comportamentos corretos entre os membros da comunidade com todos os níveis de experiência. Algumas das interações que você pode rastrear são o número de PRs/MRs arquivados, comentários, reações e avaliações (que têm alguma sobreposição com as reações). Essas interações podem ter valores e qualidades diferentes, mas o objetivo maior aqui é entender quem está fazendo o quê, quem é bom em fazer o quê e promover intencionalmente mais comportamentos baseados nos pontos fortes e nos interesses das pessoas.

Talvez algumas pessoas sejam ótimas em fornecer comentários úteis, mas (ainda) não tenham contexto suficiente para revisar um PR/MR. Seria bom identificar quem eles são e fornecer-lhes mais informações para que um dia possam se tornar revisores. Talvez algumas pessoas estejam superempenhadas em monitorar o projeto, como mostram suas reações frequentes, mas não se sintam confortáveis em contribuir com comentários e sugestões. Seria bom saber quem eles são e ajudá-los a obter mais contexto sobre o funcionamento interno do projeto, para que possam agregar mais valor a uma comunidade com a qual claramente se preocupam.

Como usar as métricas

Então, como você pode rastrear e ler essas métricas? Ilustrarei com um exemplo comparando dois projetos de código aberto: Kong, um gateway de API, e Apache Pulsar, um sistema de mensagens pub-sub.

Em maio de 2020, usei o Apache Superset, uma ferramenta de visualização de dados de código aberto, junto com um tutorial escrito por Max Beauchemin, um dos criadores do projeto, para rastrear e visualizar alguns dados do Kong, Apache Pulsar e alguns outros projetos. Usando o tutorial, rastreei dados de dois anos (de maio de 2018 a maio de 2020) para ver as mudanças ao longo do tempo. (Observação: o tutorial é um exemplo dos próprios dados do Superset com alguma ligação codificada com seu histórico dentro do Airbnb e Lyft, portanto, para usá-lo, você precisará fazer alguma personalização do JSON do painel para fazê-lo funcionar de forma mais geral.)

Duas advertências: primeiro, os dados foram coletados pela última vez em maio, então certamente parecerão diferentes hoje. Em segundo lugar, os projetos foram de código aberto em momentos diferentes e esta comparação não constitui um julgamento sobre o estado atual ou o potencial de qualquer um dos projetos. (O primeiro commit de Kong foi em novembro de 2014, e o de Pulsar foi em setembro de 2016. Claro, ambos foram trabalhados em privado antes de serem de código aberto.) Algumas das diferenças que você vê podem ser simplesmente devido à passagem do tempo e ao esforço da comunidade que paga. desligado em horários diferentes; a construção de uma comunidade é um trabalho longo e persistente.

Métricas do revisor de relações públicas

Os dois gráficos a seguir mostram as análises de relações públicas de Kong e Pulsar pelo identificador do GitHub:

Com base nesses dados, observo que Kong tem um equilíbrio melhor de pessoas revisando PRs do que Pulsar. Esse equilíbrio foi alcançado ao longo do tempo, à medida que o projeto Kong crescia em maturidade. A coisa mais importante a notar é que nenhum dos criadores de Kong, Aghi nem Marco, estão nem perto de serem os principais revisores. Isso é bom! Eles certamente o fizeram durante os primeiros dias, mas seu envolvimento tornou-se menos visível à medida que o projeto amadurecia, como deveria.

Sendo um projeto mais jovem, o Pulsar ainda não está no mesmo nível, mas está a caminho de alcançar esse equilíbrio. Sijie, Jia e Penghui estão fazendo a maior parte da revisão por enquanto; todos os três são membros do comitê de gerenciamento de projetos e lideram a SteamNative, empresa COSS da Pulsar. Outros grandes players, incluindo o Splunk (especialmente depois de adquirir o Streamlio), também contribuem para o projeto, o que é um bom indicador antecedente de eventualmente alcançar o equilíbrio.

Um fator que estou ignorando intencionalmente é a diferença no processo de governança de um projeto da Apache Software Foundation e de um projeto não-ASF, o que impactaria a velocidade e o procedimento para um contribuidor se tornar um revisor ou mantenedor. A esse respeito, esta comparação não é 100% igual.

Métricas de interação com a comunidade

A seguir estão dois gráficos de classificação que mostram as interações da comunidade de Kong e Pulsar pelo GitHub nos 90 dias desde a coleta de dados mais recente (aproximadamente de março a maio de 2020):

Essas tabelas de classificação refletem o mesmo “nível de equilíbrio” mostrado no gráfico anterior, o que faz sentido. A conclusão mais interessante é quem está fazendo que tipo de interação, quanta interação está acontecendo e quem parece estar fazendo tudo (Sijie!).

No que diz respeito à construção da estrutura de incentivos correta, essa visão do tipo tabela de classificação pode ajudá-lo a ter uma noção de onde vêm as interações e que tipo de recompensa ou sistema motivacional você deseja projetar para acelerar comportamentos positivos.

Esses dados também são úteis para a gestão interna e para a construção de comunidades externas. Como observadores atentos podem perceber, muitos dos líderes nesses gráficos são funcionários das empresas COSS dos projetos, Kong Inc. e StreamNative. É bastante comum que colaboradores ativos da comunidade (ou entusiastas) se tornem funcionários da empresa que comercializa o projeto. Independentemente de onde essas pessoas estejam empregadas, para promover um projeto sustentável além dos seus criadores iniciais (o que por sua vez influenciaria a sustentabilidade da empresa COSS), seria necessário medir, acompanhar e incentivar os mesmos comportamentos.

Além disso, estou ciente de que o gráfico do Pulsar não tem uma coluna de "reações", o que pode ser porque não havia muitos dados de reação que merecessem uma entrada entre os 10 primeiros ou devido à minha própria configuração incorreta do gráfico. Peço desculpas por esta inconsistência.

Dicas para impulsionar a sustentabilidade equilibrada

Não importa quão bonitos sejam os gráficos, os dados não contam toda a história. E não importa o quão bem-sucedido seja um projeto específico, sua experiência não deve ser padronizada e aplicada diretamente a um projeto diferente. Dito isso, gostaria de compartilhar algumas dicas práticas que vi funcionarem e que podem ajudá-lo a melhorar essas duas métricas ao longo do tempo:

Forneça documentação de alta qualidade: em um artigo anterior, concentrei-me na documentação e recomendo que você leia. O ponto mais importante é: a documentação de um projeto recebe a maior quantidade de tráfego. É o lugar onde as pessoas decidem se continuam aprendendo sobre seu projeto ou seguem em frente. Você nunca quer dar às pessoas um motivo para seguir em frente. Geralmente, recomendo gastar de 10% a 20% do seu tempo escrevendo documentação. Colocando em contexto: se você estiver trabalhando em seu projeto em tempo integral, será cerca de meio dia a um dia inteiro por semana.
Faça com que o guia do seu colaborador seja um documento vivo: Todo projeto tem um documento CONTRIBUTING.MD (ou uma variação dele). Mas os projetos que crescem e amadurecem tornam esse documento o melhor possível e o atualizam, atualizam e refinam continuamente. Por que? Porque é para lá que vão as pessoas que têm entusiasmo em participar do projeto. Se o guia for claro, sucinto e prático, você receberá contribuições rapidamente. Se estiver desatualizado, complicado e sem acesso fácil (por exemplo, problemas de iniciante, bugs simples, etc.), então esse entusiasmo irá para outro lugar. Faça do seu CONTRIBUTING.MD um recurso matador.
Estabeleça diretrizes de qualidade claras: existe uma "contribuição barulhenta" - PRs/MRs de baixa qualidade que exigem mais energia do que vale a pena revisar (e muitas vezes rejeitam ). Porém, a responsabilidade de comunicar ao público o que é ou não uma “contribuição de qualidade” é sua, o criador ou mantenedor, porque você tem de longe o maior contexto e conhecimento institucional sobre o projeto. Deixe suas expectativas claras e não comprometa a qualidade. Torne-o uma seção de destaque do seu CONTRIBUTING.MD ou um documento separado para dar mais visibilidade. Combine-o com o roteiro do seu projeto, que de qualquer maneira deve fazer parte da sua documentação pública, para que seus novos colaboradores saibam o que se espera deles e por quê.

Espero que isso forneça alguns insights úteis sobre as duas métricas de segunda ordem que são importantes ao construir uma comunidade sustentável de código aberto e alguns itens acionáveis que você pode usar para rastreá-las e melhorá-las.

Este artigo foi publicado originalmente na COSS Media e foi republicado com permissão.