O ‘trabalho invisível’ no ecossistema open source — metade não é registrada
Autores: John Meluso (Cornell Univ.), Amanda Casari & Katie McLaughlin (Google LLC), Milo Z. Trujillo (Northeastern Univ.)
Publicação: janeiro de 2024, pré-publicação de artigo da ACM
Original: arXiv:2401.06889v2
Resumo
Software open source (OSS) não se resume a escrever código. Gestão de comunidade, redação de documentação, organização de eventos, gestão financeira, relatórios de bugs, moderação de conteúdo e muitas outras atividades não relacionadas à programação tornam possível a manutenção e a evolução dos projetos. No entanto, essas atividades em sua maioria permanecem como “trabalho invisível (invisible labor)”.
Este estudo conjunto de Cornell, Google e Northeastern mostra que cerca de metade (50%) do trabalho em open source é invisível e que dois terços das tarefas (cerca de 66%) não são conhecidos por outras pessoas. Mais da metade dos respondentes afirmou que uma parte significativa do trabalho que realiza não é reconhecida nem recompensada.
Visão geral do estudo
- Método da pesquisa: questionário aplicado entre janeiro e junho de 2022 com 142 desenvolvedores OSS do mundo todo
- Forma de investigação: aplicação da técnica cognitiva de ancoragem (anchoring), desenhada para que os participantes avaliassem por conta própria o quanto seu trabalho era “visível” ou “reconhecido”
- Perguntas centrais:
- Quão comum é o trabalho invisível no ecossistema open source?
- Quais fatores reforçam essa “invisibilidade”?
Principais resultados
- Compensação (Compensation): apenas metade dos respondentes disse ter recebido “crédito (credit)” pelo trabalho realizado.
- Visibilidade (Visibility): cerca de 2/3 do trabalho é invisível ou conhecido apenas por poucas pessoas.
- Fatores da invisibilidade:
- Atividades fora do código não são registradas automaticamente pelos sistemas (ex.: gráficos do GitHub refletem apenas programação)
- Fatores sociais (gênero, região, estrutura organizacional etc.) geram diferenças no reconhecimento
- Desequilíbrio nos sistemas de recompensa — existe “agradecimento”, mas não oportunidades concretas nem remuneração
Efeito cognitivo: quando se fala primeiro em “visibilidade”, ela parece maior
Curiosamente, as respostas variaram conforme a ordem do questionário (pensar primeiro em “visibilidade” ou primeiro em “invisibilidade”).
Participantes levados a recordar primeiro a “visibilidade” avaliaram seu trabalho como mais “visível” e atribuíram menor importância ao “crédito”.
Já os participantes levados a pensar primeiro na “invisibilidade” responderam que seu trabalho era menos conhecido e deram mais importância ao reconhecimento.
Isso sugere que o efeito de ancoragem (anchoring effect) também influencia a avaliação do trabalho em open source.
As vozes diretas dos participantes
“Ninguém reconhece revisão de código nem documentação.”
“Muitas vezes meu nome é escrito errado, ou simplesmente fica de fora.”
“Contribuições para a comunidade não são reconhecidas, enquanto apenas commits de código são vistos como ‘contribuição’.”
“As estatísticas de ferramentas automatizadas distorcem o esforço real.”
Os pesquisadores chamam essas reações de “cross-purpose attribution” e explicam que, quando a motivação individual (diversão, reconhecimento, pertencimento, carreira etc.) entra em conflito com o sistema de recompensas da comunidade, o “trabalho invisível” se intensifica.
Implicações do estudo
-
“Aberto” não significa necessariamente “visível”.
Mesmo com o código público, as pessoas e os processos por trás dele são facilmente esquecidos. -
Recompensa não é só dinheiro.
Ter o nome citado ou o histórico de contribuição registrado também é uma forma importante de “recompensa”. -
Responsabilidade no design das plataformas.
Plataformas importantes como o GitHub deveriam exibir de forma quantitativa atividades além do código (gestão de issues, tradução, operação de comunidade etc.). -
Necessidade de dar visibilidade a contribuições diversas.
É preciso adotar sistemas de classificação de contribuições como o CRediT (padrão de contribuição de pesquisadores), para reconhecer com clareza contribuições em áreas não ligadas ao desenvolvimento, como documentação técnica e operação de comunidade.
Conclusão
Este estudo traz para a superfície o “trabalho fora do código” ao discutir a sustentabilidade do open source.
“Público” não garante “justiça”. Ele lembra que o verdadeiro “open” do open source deve se apoiar não só no código, mas também na transparência social que torna visíveis todas as contribuições.
4 comentários
Até na empresa... T^T
Há trabalho demais, incidental e invisível, que não entra na divisão oficial de tarefas e acaba virando projeto pessoal
(quando existem muitas tarefas tão pequenas que dá vontade de perguntar “isso é mesmo trabalho?”, ou quando elas se repetem muitas vezes)
Naturalmente, também não contratam mais gente para esse tipo de tarefa, então o uso de IA para essas coisinhas acabou aumentando
Acho que uma das razões pelas quais os trabalhadores coreanos usam tanta IA talvez seja o forte desejo de resolver esse trabalho invisível além do JD; no exterior, pelo menos, tendem a detalhar melhor o JD e tentar segui-lo)
Na prática, agora parece que, por mais trabalho que você faça, ele será reconhecido como se tivesse sido feito por IA.
Acho que, na verdade, isso não é tanto um problema de código aberto, mas algo que se aplica a qualquer organização. Há muitas contribuições que acabam ficando invisíveis.