Open source é uma pessoa só

• Reportagens recentes levantaram críticas ao uso de software open source criado por um desenvolvedor russo
• Na prática, a grande maioria de quase todos os projetos open source é operada por um único mantenedor individual
• Não só no NPM, mas em vários ecossistemas, há muitos casos em que um único mantenedor cuida de pacotes populares
• O problema dessa estrutura é a sobrecarga excessiva sobre uma única pessoa e o risco para a cadeia de suprimentos
• A essência do problema não é a nacionalidade, e sim a falta real de recursos e apoio

---

Introdução: open source e a polêmica recente

• O The Register publicou uma matéria questionando a dependência do Departamento de Defesa dos EUA no uso de um utilitário open source criado por um desenvolvedor russo
• Esse desenvolvedor open source está sendo alvo de críticas injustas
• O conteúdo da matéria interpreta mal a realidade do open source, e este texto aponta os limites desse tipo de abordagem

A realidade do open source: a estrutura de “uma pessoa”

• Segundo os dados, quase todos os projetos open source são mantidos por uma única pessoa
• No projeto ecosyste.ms, cerca de 11,8 milhões de projetos open source estão catalogados nos dados
  • Desses, cerca de 7 milhões têm um único mantenedor
  • Os cerca de 4 milhões de projetos restantes têm número de mantenedores desconhecido, mas estima-se que muitos deles também tenham apenas uma pessoa
  • Só uma parcela muito pequena de projetos tem centenas de mantenedores

Nem mesmo projetos populares são exceção

• Muita gente pensa que “projetos open source importantes ou populares devem ser mantidos por várias pessoas”, mas, na prática, ecossistemas importantes como o NPM não são diferentes
• Existem mais de 4 milhões de projetos com mantenedor único dentro do ecossistema NPM
• Mesmo entre os pacotes NPM com mais de 1 milhão de downloads por mês, cerca de metade é operada por um único mantenedor
  • Se o número de downloads sobe para 1 bilhão, há alguma diferença, mas ainda assim continuam existindo pacotes com apenas 1 mantenedor
• As pessoas reais que operam esses 4 milhões de projetos com mantenedor único no NPM são cerca de 900 mil (ou seja, uma mesma pessoa responde por vários projetos)

A essência do problema: não é o país, é a falta de recursos

• A escala econômica do open source é uma base de trilhões de dólares (segundo estudo de Harvard, US$ 8,8 trilhões)
• A maioria dos projetos com mantenedor único carece de recursos, e há risco para a cadeia de suprimentos
• O maior risco não é o país, mas sim “um único mantenedor” trabalhando demais e sem receber compensação adequada
• Não é solução que a mídia e outros atores passem a mirar mantenedores individuais

Conclusão e pontos de ação

• A causa do problema atual está na estrutura de mantenedor único, e focar em países não faz sentido
• Demonizar ou tentar detectar mantenedores individuais não é uma solução
• Trata-se de um problema complexo, para o qual não há solução imediata
  • A discussão relacionada também já foi abordada no podcast Hobbyist Maintainers with Thomas DePierre
• Em vez de apontar e culpar mantenedores individuais, é preciso pensar no problema estrutural e em formas de apoio

[GN⁺]

Comentários no Hacker News

• Parece haver muito mal-entendido na comunidade de software sobre essa questão; na prática, risco de cadeia de suprimentos me parece mais um problema de governança do que de software ou engenharia
  Mesmo sem má intenção de ninguém, um projeto pode acabar tendo risco de cadeia de suprimentos, e cada pessoa que avalia esse risco tem uma perspectiva de segurança e critérios diferentes
  O DoD (Departamento de Defesa dos EUA) enxerga risco de um jeito totalmente diferente do de um desenvolvedor comum, e muitos projetos de uma pessoa só viram risco simplesmente por terem apenas uma pessoa responsável
  Quando o “bus factor” é 1, isso por si só já é um risco de cadeia de suprimentos
  A maioria das pessoas não pensa em cenário de guerra ao escolher um pacote, mas os militares podem muito bem levar isso em conta
  Se uma guerra acontecer, até projetos open source normalmente geridos de forma autônoma podem ter sua situação mudada de forma brusca
  De fato, muitos países em tempos de guerra exigem por lei cooperação de empresas privadas ou projetos pessoais, então há lugares (como o DoD) que contabilizam até esse tipo de coisa como risco de segurança

  • Pessoal, queria que todo mundo repetisse em voz alta: façam vendor dos pacotes! Façam vendor!
  • Mesmo assim, é triste ver que continua a propaganda exagerada do tipo “um desenvolvedor solo também pode em breve criar uma empresa de software bilionária”
  • Se fosse o DoD, imagino que eles simplesmente não usariam o pacote se não estivessem prontos para ler linha por linha de todo o código, travar as atualizações e aplicar patches por conta própria se necessário
    Em cenário de guerra, eles não operariam na lógica de “tomara que houvesse ao menos mais uma pessoa em quem não confiamos nem um pouco”

• Havia um dado dizendo que existem 4 milhões de projetos de uma pessoa só no NPM e cerca de 900 mil pessoas mantendo esses projetos, e fiquei me perguntando se esse era mesmo o ponto importante

  • Não foi dito de forma explícita, mas acho que o sentido era mais ou menos este
    Ou seja, a maior parte do valor econômico do open source (que Harvard estimou em 8,8 trilhões de dólares) é criada por “projetos de uma pessoa só”, e nenhuma dessas pessoas recebe suporte adequado de recursos
    Na conversa sobre risco de cadeia de suprimentos, o que é realmente perigoso é o mantenedor solo mal pago e sobrecarregado
    Em que país essa pessoa mora, sinceramente, não me parece tão importante assim

• Fiquei curioso se existem estatísticas sobre o que acontece quando um mantenedor solo sofre um acidente de repente ou abandona o projeto
  Com tanto dado assim, parece algo que valeria pesquisar
  Queria saber se outro desenvolvedor assume o projeto, se ele é substituído por outro semelhante, ou se simplesmente desaparece por completo

  • Depende do caso
    Na prática, é bem mais comum do que acidente de ônibus o caso de “o mantenedor perdeu o interesse ou ficou sem tempo e largou”
    Nessas horas, os cenários mais comuns são
    1. alguém faz um fork e esse fork acaba substituindo o original
    2. um projeto novo com a mesma função ganha popularidade e substitui o antigo
    3. o mantenedor original passa a gestão do projeto para outra pessoa
    4. ninguém mantém, mas ele continua sendo usado, e quando surge problema cada um resolve no seu próprio fork, sem que esses forks virem a tendência principal
       A força do open source é que, mesmo que o autor desapareça, enlouqueça ou mude a licença, alguém ainda pode fazer um fork e preservar o projeto
       Já software comercial, se o criador — seja empresa ou pessoa — some ou muda o conteúdo, acabou
       No máximo dá para procurar um produto substituto
  • Eu veria com certeza uma série de episódios sobre o processo de bibliotecas/ferramentas/apps/sites open source populares passando de um mantenedor para outro
    Esse também é o motivo de eu não tocar a Netflix
  • Pela minha experiência, já vi os três casos acontecerem de verdade
    No fim, isso depende do número de usuários, da complexidade da base de código e da existência de alternativas
  • O exemplo mais parecido que me vem à cabeça é Hans Reiser/Reiserfs
    É uma história muito mais estranha do que simplesmente “foi atropelado por um ônibus”, e no fim o projeto desapareceu
  • O que as pessoas ignoram é que, se o código é open source, no pior dos casos sempre dá para fazer um fork, mesmo que leve tempo

• Mesmo em projetos mantidos por duas ou mais pessoas, na prática a maior parte dos commits costuma acabar ficando nas mãos de uma só

  • Por isso, no meu site pessoal eu evitei usar 11ty e escolhi Jekyll
    Link relacionado: https://github.com/11ty/eleventy/graphs/contributors

• É uma pena que, mesmo fazendo só uma checagem de atividade, já daria para perceber na hora que metade dos projetos tinha 0 mantenedores

  • Às vezes o software chega a um ponto em que parece “perfeito” e já não precisa mais de manutenção
    Quer dizer que ele pode simplesmente ficar lá sem precisar de limpeza, tuning ou ajustes
    Muitas vezes o problema são as atualizações, não o projeto em si

• O que mais me preocupa é o fato de o DoD usar node
  Dá uma sensação ruim pensar que uma plataforma como npm tem uma superfície de ataque grande demais

  • Aí surge a dúvida do porquê
    O DoD é uma das maiores organizações do mundo, então também deve ter um monte de tarefas como enviar newsletters ou páginas web para reservar visitas a bases de escoteiros
    Para esse tipo de coisa, usar node não me parece problema
    Esses sistemas operam separados de sistemas principais como lançamento de mísseis, e não seria um grande desastre se uma simples página de inscrição para evento fosse comprometida
  • Como o DoD é gigantesco, imagino que use praticamente todas as plataformas importantes

• Acho que muitos projetos de uma pessoa só no GitHub são, na verdade, só experimentos pessoais ou brincadeiras tipo “hello world”
  Não sei como é no npm, mas no PyPI também tem exemplos assim de sobra
  Cliquei em “browse projects” e apareceu isso: https://pypi.org/project/helloworld-eduardo/
  Por mais bêbado que alguém esteja, não vai achar que isso serve para usar em produção

• O DoD é muito bom em, quando consegue algo de graça, convencer todo mundo de que “isso beneficia a todos” e no fim entregar o trabalho para terceirizados pagos

  • Se você lembrar do cavalo de Troia, fica claro que nem tudo que é de graça é sempre bom

• Disseram que existe um “pacote com mantenedor solo e mais de 1 bilhão de downloads”, e fiquei curioso para saber a que pacote isso se refere

• Ouvi muita coisa boa sobre o trabalho feito por um cara chamado Linus, e acho que já usei bastante coisa dele na prática
  Como ele é de um país que faz fronteira com a Rússia, isso também me faz pensar se esse tipo de fator deveria ser levado em conta
  Estou há décadas fazendo desenvolvimento open source, quase sempre sozinho ou às vezes montando uma equipe voluntária
  Quem já trabalhou com equipe voluntária sabe que isso realmente não é fácil
  Claro que não é absolutamente impossível, mas não funciona tão bem com tanta frequência quanto costumamos imaginar
  Quando funciona, geralmente é porque existe um “BDFL (ditador benevolente)” ou porque todo mundo está alinhado em torno de um objetivo comum
  No meu caso, quase sempre foi mais o segundo caso

  • (Off-topic) Dizem que os pais do Linus também eram politicamente ativos, e que o próprio Linus participou quando criança de um grupo juvenil comunista, parecido com escoteiros
    O pai dele também passou alguns anos em Moscou
  • Linux é um projeto com uma grande quantidade de mantenedores e suporte, então é totalmente diferente de um projeto de uma pessoa só desenvolvido apenas pelo Linus