- À medida que envelhece o grupo de pessoas que realmente mantém o código central do PostgreSQL, lançado em 1986, surge uma questão de sustentabilidade: quem continuará esse trabalho daqui a 20 anos?
- Em 2022, 192 desenvolvedores lideraram pelo menos um commit; 66% do código novo foi escrito por 14 pessoas, e 90% por 40 pessoas, em uma estrutura concentrada em poucos
- A idade média da comunidade central de desenvolvimento é de cerca de 50 anos, e Tom Lane, aos 68, ainda atua como eixo central do projeto
- Em vez de contratar os principais talentos já estabelecidos, a Neon investe deliberadamente na formação da próxima geração, contratando juniores e desenvolvendo-os de contributors para committers e maintainers
- Para a manutenção contínua do projeto, são necessários intencionalidade, financiamento e interesse próprio esclarecido (enlightened self interest)
O envelhecimento do PostgreSQL e o problema da força de manutenção
- Lançado em 1986, o PostgreSQL tornou-se a escolha padrão em uma parte significativa do desenvolvimento de software moderno, mas, após tanto tempo desde seu lançamento, surge a questão da continuidade das pessoas que de fato constroem o banco de dados
- A pergunta é por quanto tempo essas pessoas continuarão fazendo o trabalho pesado (heavy lifting) de manter uma base de código de alto perfil da qual tanta gente depende
- O Postgres é, ao mesmo tempo, um pequeno grupo fortemente coeso e um projeto
Estatísticas de contribuidores de 2022
- Robert Haas, chief database scientist da EnterpriseDB e committer do Postgres, publicou números em seu artigo periódico sobre contribuições, "Who Contributed to PostgreSQL Development in 2022?"
- Em 2022, 192 pessoas foram autoras principais (principal author) de pelo menos um commit do PostgreSQL
- 66% das novas linhas de código foram escritas por uma de 14 pessoas
- 90% das novas linhas de código foram escritas por uma de 40 pessoas
Estrutura etária da comunidade central
- A comunidade central de desenvolvimento envelheceu um pouco, com idade média em torno de 50 anos
- Tom Lane, da Crunchy Data, tem 68 anos e ainda atua como o eixo central (fulcrum) do projeto Postgres
Governança aberta e a pergunta para daqui a 20 anos
- A governança aberta (Open governance) do Postgres é uma base confiável e, em um momento em que mudanças unilaterais em licenças comerciais de open source (rugpull) são frequentes, é um exemplo revigorante
- Do ponto de vista da sustentabilidade do open source, supondo que o Postgres ainda esteja forte daqui a 20 anos, levanta-se a pergunta: quem fará esse trabalho em 2043?
Discussão com a Neon e Nikita Shamgunov
- Em uma conversa com Nikita Shamgunov, CEO da Neon, foi discutido o envelhecimento de projetos tecnológicos e sua relação com a sustentabilidade dos projetos
-
Sobre a Neon
- A Neon é um banco de dados Postgres totalmente gerenciado, otimizado para apps serverless, que separa armazenamento e computação e adota o princípio de design de que "o banco de dados é uma URL"
- Oferece suporte a branching para deploys de preview, o que possibilitou uma parceria com a Vercel
- Seu objetivo é tornar isso "fácil, moderno e com API zero config"
- Tem 62 funcionários, US$ 108 milhões ($108m) em investimentos acumulados e concorre com empresas como a Supabase
-
Diferença entre committer e contributor
- Shamgunov: "A camada de committers do Postgres está na casa dos 50, 60 e 40 anos; há poucos na casa dos 30"
- Tornar-se committer exige muito esforço, mas para se tornar contributor basta escrever bom código
Investimento na formação da próxima geração de committers
- A Neon investe deliberadamente na próxima geração de contributors, committers e maintainers
- A escolha natural de muitas empresas é contratar os principais talentos existentes, em vez de formar novos talentos
- Shamgunov: "Discutimos se deveríamos procurar e contratar mais committers do Postgres, mas não estava claro se esse era o melhor uso do capital"
- "É melhor formar gente nova, e dessa forma podemos continuar ampliando a equipe do Postgres"
- Shamgunov enfatiza que contratar e treinar juniores para se tornarem committers e, depois, maintainers é importante para a evolução contínua do engine do Postgres
Licença e interesse próprio esclarecido
- A IP da Neon atualmente está sob uma licença permissiva (permissive license), mas Shamgunov não é um fundamentalista do open source
- No futuro, a Neon tem o direito de fazer relicenciamento (relicense), como Redis, MongoDB e Elastic, e migrar para termos mais restritivos
- No entanto, o código já contribuído ao Postgres não seria afetado por essa decisão
- Ter maintainers centrais do Postgres dentro da empresa é um exemplo de interesse próprio esclarecido (enlightened self interest): um mecanismo que mantém a empresa honesta, enquanto a comunidade e a base de código central se beneficiam independentemente de qualquer decisão tomada
A universalidade do envelhecimento de coortes
- O envelhecimento de coortes não é um problema exclusivo do Postgres; como no caso do Y2K (bug do ano 2000), comunidades e ecossistemas envelhecem, e isso pode gerar problemas em termos de tecnologia, força de trabalho e renovação geracional
- A IBM é um caso de sucesso ao atrair desenvolvedores jovens para o mundo dos mainframes por meio de programas universitários de formação profissional, entre outras iniciativas
- Também existem muitos projetos com milhões de usuários, mantidos por apenas uma ou duas pessoas, sem patrocínio corporativo como o de projetos como Postgres ou Kubernetes
Conclusão — a intencionalidade da manutenção
- O Postgres não tem nenhuma dificuldade em atrair novos usuários; é uma plataforma extremamente popular que até desenvolvedores de 22 anos hoje escolhem como padrão
- No entanto, para garantir a manutenção contínua do projeto, são necessários intencionalidade (intentionality), financiamento e interesse próprio esclarecido
Divulgação (Disclosure)
- A Neon não é cliente da RedMonk; Crunchy Data, IBM e Vercel são clientes da RedMonk, e este artigo foi publicado de forma independente, sem relação com vínculos comerciais
1 comentários
Comentários no Hacker News
Tenho 46 anos, mas quero fazer parte da próxima geração, e certamente deve haver gente mais jovem também
Minha última apresentação na PGCon foi sobre as lacunas que é preciso conhecer para hackear o Postgres, especialmente a etapa do executor e as tentativas de preencher o TupleTableSlot
Não sou a pessoa mais indicada, mas às vezes quem está aprendendo entende melhor do que o aprendiz precisa
Há algum tempo, também escrevi o sumário de um livro sobre como contribuir para o Postgres, e acho que venderia pelo menos 10 cópias
Talvez uma série online fosse melhor; de um jeito ou de outro, fico curioso se haveria pessoas interessadas
Hoje o Postgres é mais um hobby para mim, mas, se houver algum lugar procurando alguém para trabalhar em tempo integral com contribuições open source para o Postgres, eu estaria disposto a conversar
Uma boa parte da próxima geração atual também entrou no Postgres relativamente tarde
Tom também falaria de si mesmo com modéstia, mas ele passou alguns anos trabalhando com imagens e, depois de participar de alguma forma dos processos de criação de tiff, jpg e png, descobriu o Postgres e começou a trabalhar nele
Ele produz bastante conteúdo sobre como começar a contribuir para o Postgres e também é aberto a conversar com outros entusiastas de PG
Pode ser possível colaborar ou receber conselhos: https://www.youtube.com/watch?v=rihfAnd_leM
Dá para contatá-lo pelo e-mail x4mmm@.ru ou pelo Twitter @x4mmmmmm
Com a barreira de participação ficando mais baixa, espero ver mais gente se aposentando cedo e participando de open source
Algumas editoras permitem que leitores de acesso antecipado relatem erros: https://nostarch.com/early-access-program
É tão interessante que meu objetivo é conseguir uma aposentadoria antecipada para hackear o Postgres em tempo integral
Tem de tudo ali: redes, armazenamento, dados, algoritmos etc.
Sinceramente, C é o menor dos problemas; o Postgres tem um bom estilo de código e é bastante consistente
O difícil é a complexidade da estrutura interna, e uma comunidade pequena também pode afetar a velocidade com que se consegue ajuda
Fico me perguntando se, no futuro, bases de código em C terão dificuldade para encontrar mantenedores
O Postgres tem suporte comercial e inércia, mas parece faltar um caminho de entrada para desenvolvedores C experientes
C ainda é uma linguagem viva, não faltam usuários ativos, e a curva de aprendizado não é tão íngreme para quem faz programação de sistemas em outra linguagem
Para desenvolvedores web e de aplicações hoje, pode parecer intimidador porque existe uma cortina opaca entre eles e a arquitetura dos sistemas de baixo nível, mas programadores de sistemas que usam C++ ou Rust já trabalham atrás dessa cortina, só que com luvas mais grossas
Muitos deles já tiveram contato com C, nem que fosse em formação ou experimentação no passado, e, se isso virar uma responsabilidade profissional, podem estudar de forma deliberada e se adaptar às armadilhas perigosas
Há argumentos contra escolher C para novos projetos de sistemas, mas, tirando a questão da falta de programadores de sistemas em si, não parece haver motivo imediato para grande preocupação em encontrar mantenedores para código existente
Não medi cientificamente, mas a média de habilidade em C dos novos contribuidores parece mais baixa do que antes; claro, isso pode ser só minha barba grisalha falando
Até agora, as pessoas vêm “aprendendo no trabalho”, mas não está claro o tamanho dessa lacuna
Em algum momento, acho que teremos de facilitar o uso de outras linguagens em partes do sistema, por exemplo em implementações de tipos de dados dentro do core, mas, na prática, isso ainda parece um pouco distante
A parte difícil é ter o conhecimento correto do domínio, e leva bastante tempo para se familiarizar com o sistema como um todo
Conheço poucos desenvolvedores experientes de Rust ou C++ que também não sejam proficientes em C
Mas tenho curiosidade sobre quando mais bases de código em C começarão a destacar módulos e substituí-los por Rust
Isso já está acontecendo no Linux, no curl, em projetos C++ como o Chrome, em vários produtos da MS, no Amazon S3 etc.
A resistência mais explícita que conheço é a do OpenBSD, porque eles querem manter pequeno o bootstrap e o toolchain da instalação padrão
Até o sistema de tipos do TypeScript é bem mais complexo do que C
Ou talvez eu só esteja revelando minha ignorância sobre o quanto C é complexa
Tenho pensado bastante sobre esse tema
A comunidade há muito tempo passa por ciclos de crescimento e retração, e vou dizer algumas coisas com a intenção de compartilhar um pouco mais sobre a comunidade do PG
Durante alguns anos não houve nenhum novo committer e, mais recentemente, a equipe tem tentado adicionar novos committers de forma mais deliberada e remover pessoas que não participam mais
Cerca de 15 anos atrás houve um período em que um bom número de pessoas jovens recebeu permissão de commit, e me lembro de três que tinham menos de 25 anos, talvez todos menos de 22
Uma delas pouco depois saiu da comunidade Postgres, outra ficou discretamente ocupada com outras coisas por mais de 10 anos e depois voltou, e outra continuou participando ativamente
Acho que havia um certo desconforto com pessoas que desapareciam depois de receber permissão de commit, então a adição de novas pessoas desacelerou por alguns anos
Em resumo, isso significa que é difícil receber permissão de commit no Postgres logo depois de se formar na faculdade
Um dado interessante, mas difícil de coletar, é com que idade as pessoas se tornam committers do Postgres
Não me surpreenderia se, em média, a idade em que se recebe permissão de commit ficasse perto dos 45 anos
Muitos contribuidores chegam ao Postgres depois de trabalhar em outros sistemas, ou só passam a considerar contribuir depois de acumular certa experiência, porque enviar patches para uma lista de discussão parece intimidador
A história do primeiro commit dessa pessoa é excelente
Ao testar o comportamento de SQL no Materialize, ela tentou verificar se os dois sistemas tratavam funções de interval da mesma forma e, de maneira meticulosa, experimentou coisas como
select interval '0.5 months 2147483647 days';Dá para testar diretamente no dbfiddle: https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Em vez de erro, o Postgres retornava um valor incorreto,
{"days":-2147483634}, e o motivo pode ser lido aqui: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Então, naturalmente, isso foi corrigido no Postgres e, graças a isso, nas versões 15 ou superiores o caso é tratado corretamente: https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
Eu gosto tanto do Postgres que até fiz uma tatuagem de PG, mas os dois caminhos para contribuir não são fáceis
Mesmo tentando contribuir no tempo livre como um usuário qualquer, não há muitos tickets do tipo “boa primeira issue”, e é difícil começar sem conhecer pelo menos um pouco do contexto e das razões históricas por trás de várias partes da arquitetura do PG
Receber revisão de patch de pessoas como Tom ou Andres também pode ser intimidador
Entrar como desenvolvedor em uma empresa paga de PG, como EDB, PG Pros ou Crunchy, também se aproxima de um problema de ovo e galinha
É difícil ser contratado como júnior sem experiência prévia em hacking de PG, mas o próprio caminho para ganhar essa experiência também não é fácil
Se não fosse minha empresa atual, eu gostaria de trabalhar em algum lugar que faz trabalho com PG, mas não há muitos caminhos de entrada realistas
Para 10 pessoas que se tornaram committers recentemente, usei alguns comandos git como os abaixo para comparar quando o nome apareceu pela primeira vez em uma mensagem de commit e quando fizeram o primeiro commit como committer
O tempo médio de participação, comparando apenas mês/ano, foi de cerca de 8,9 anos, e o caso mais curto ainda foi de cerca de 6,5 anos
Uma análise melhor seria possível, mas o objetivo era ter uma noção aproximada
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1Talvez naquela época fosse mais acessível para alguém de 22 anos e fosse possível entender uma parte maior do sistema
Além disso, naquela época C era uma linguagem padrão, mas hoje desenvolvedores jovens têm mais chance de programar em Rust do que em C
Eu não fazia ideia de que houve uma concentração de pessoas que receberam permissão de commit com menos de 22 anos
Sou um novo contribuidor que começou a contribuir com o Postgres há 5 meses e faço 27 anos no fim deste mês.
Ainda não fiz muitas contribuições valiosas, mas tenho alguns commits e, daqui para frente, quero facilitar a compilação de extensões do Postgres com Meson e, se possível, também eliminar rapidamente o build com autotools.
Talvez em breve vocês também me vejam nos repositórios do pgbouncer ou do pgvector.
O que me levou a contribuir foi o cansaço com a empresa de consultoria de software onde trabalhei por 3 anos.
Eu sempre quis viver como alguém da área de software de sistemas open source, e encontrei uma vaga na Micron para trabalhar em um mecanismo de armazenamento open source.
Para ser sincero, tive sorte, mas a descrição da vaga parecia ter sido escrita para mim, então me candidatei, e trabalhei feliz nesse projeto por 2,5 anos.
Infelizmente, no fim de fevereiro a Micron demitiu toda a equipe, e depois recebi uma proposta da MongoDB para trabalhar nos drivers C/C++, mas ela foi retirada.
Depois disso, passei a me apoiar mais na minha rede de contatos, e uma pessoa que eu conhecia do #mesonbuild no Libera.Chat/Matrix trabalhava com Postgres; perguntei se havia alguma vaga relacionada a Postgres que combinasse com meu histórico.
Ele me disse que a Neon estava contratando, e eu me candidatei à equipe de mecanismo de armazenamento, mas na primeira entrevista a pessoa que viria a ser meu gerente avaliou que eu me encaixaria melhor na nova equipe de Postgres que estavam montando, isto é, a equipe que contribui para o Postgres upstream.
Sou muito grato à Neon por ter me dado essa oportunidade.
O tema deste texto é interessante porque tinha acabado de surgir durante uma conversa com outros jovens contribuidores do Postgres na PGConf NYC.
É difícil conseguir que até patches pequenos sejam revisados e, quanto mais conhecido seu nome fica na comunidade, mais reviews você parece receber, criando um problema circular.
A estrutura das listas de e-mail do Postgres também não é boa: é preciso beber direto da mangueira de incêndio chamada pgsql-hackers, enquanto a LKML é dividida em vários subsistemas.
Forjas de código modernas têm o valor de permitir assinar tags específicas de PRs/issues, mas hoje não há esse tipo de mecanismo na pgsql-hackers.
Adicionar um item ao commitfest também é um pouco trabalhoso; para passar pelo CI completo do Postgres é preciso colocá-lo no commitfest e, mesmo depois disso, você precisa verificar por conta própria ou esperar que um committer avise para olhar uma falha no CI.
Relatos de bugs também vão para a lista pgsql-bugs, e o Postgres não tem um equivalente ao bugzilla do Linux.
Patches são enviados como anexos de e-mail e não necessariamente no formato git-format-patch, enquanto a LKML, pelo que parece, usa exclusivamente git-send-email.
No geral, as ferramentas da comunidade de contribuidores do Postgres parecem servir melhor a pessoas que estão profundamente imersas nela há mais de 15 anos.
Não quero transformar isto em um texto de “vamos usar GitHub/GitLab”; na verdade, acho que e-mail é superior para discutir patches, mas as ferramentas em torno das listas de e-mail poderiam melhorar.
Tudo é separado demais, e acho que o SourceHut fez um bom trabalho ao tornar o desenvolvimento baseado em listas de e-mail mais acessível para contribuidores do dia a dia.
Issues, listas de e-mail, CI/CD e repositórios ficam todos conectados, em vez de divididos em serviços separados como acontece hoje no Postgres.
Este comentário em si poderia virar um post de blog separado algum dia, mas vou parar por aqui.
Se você está começando a contribuir com o Postgres, acho que podemos trocar experiências; é só me mandar e-mail em tristan neon.tech ou tristan partin.io.
Outro contribuidor do Postgres achou que poderia ser útil um encontro mensal entre contribuidores que não são committers para falar sobre patches em andamento ou já publicados e receber revisão de pares.
Tristan provavelmente poderia liderar um encontro online.
Melanie Plageman também tinha interesse em uma ideia dessas, e chegamos a discutir brevemente diferentes formatos de office hours.
Isso parece ter potencial para virar um bom texto, e também parece ser algo que a comunidade Postgres poderia melhorar com relativa facilidade em termos de organização e processo.
Mas tenho menos certeza sobre a parte de “reconhecimento do nome”, e parece haver uma grande evasão também na outra ponta.
É verdade que a pgsql-hackers parece uma mangueira de incêndio, e acho que isso piorou muito nos últimos anos.
É possível ativar o CI no repositório sem colocar no commitfest: https://github.com/postgres/postgres/blob/master/src/tools/c...
É o mesmo CI que roda para os itens do commitfest.
Eu realmente odeio que relatos de bugs vão para uma lista de e-mail, e eu também continuo deixando passar.
Também acho que o bugzilla do kernel é bem inútil, mas não seria difícil fazer melhor do que isso.
Também não acho bom o tratamento de patches no estilo da LKML, especialmente porque cada revisão de um patchset cria uma nova thread, o que não torna o acompanhamento muito fácil.
Mesmo tendo participado do desenvolvimento por cerca de 15 anos, eu não diria que as ferramentas atuais funcionam particularmente bem.
O processo de desenvolvimento evoluiu até certo ponto nesse período, mas não ao nível necessário.
Mudar uma comunidade com tantos “barbas grisalhas” como a comunidade PG exige muito esforço; não é impossível, mas não é fácil.
Pessoalmente, detesto fortemente usar GitHub ou GitLab para trabalhos complexos, mas acho que deveríamos aceitar PRs/MRs por meio de um dos dois para facilitar a vida de novos contribuidores.
Só que isso não é algo que dependa apenas da minha decisão.
Acho que não haveria mais do que 2 ou 3 pessoas contrárias à ideia de que e-mail é superior para discutir patches, mas que precisamos melhorar as ferramentas ao redor.
O problema é que muita gente prefere gastar tempo hackeando o Postgres em vez de trabalhar em ferramentas ou integrações do processo de desenvolvimento.
Trabalhei um pouco com Postgres com a ajuda do pgrx, e posso recomendá-lo como plataforma para construir soluções de dados.
O canal da CMU também foi uma ótima fonte: https://www.youtube.com/@CMUDatabaseGroup
Por exemplo, mesmo que você queira escrever um novo handler de Table Access Method, o SDK pg-sys do core tem bindings relacionados a TableAM, mas não há documentação nem exemplos de como usá-los em Rust
Hoje em dia, a maioria das pessoas que entra em TI só pensa em dinheiro, e dá para observar que já não há tantas pessoas realmente entusiasmadas
É muito triste, e parece que muitos projetos open source estão morrendo por causa disso
É aquele esquema de apenas “copiar e colar do Stack Overflow e receber salário”, sem contribuir de volta nem ajudar
Não estou dizendo que todo mundo seja assim, mas, pela proporção que observei de perto e conversando enquanto trabalhava em várias empresas, era algo como 19:1
Para constar, eu termino o trabalho rápido demais em relação ao padrão e muitas vezes perco tempo esperando reuniões, então trabalho em duas empresas todos os dias
Também fiz muitos trabalhos paralelos para fazer coisas interessantes, e muitas vezes fiz de graça para testar hardware novo ou experimentar
As cláusulas de cessão de invenções e de atividades externas nos contratos aumentam a barreira para contribuir
Concordo que o Postgres não está tendo dificuldade para atrair novos usuários
Eu também uso Postgres em vários apps self-hosted
Mas, em aplicações PHP, acabo continuando com o MariaDB quando ele é o banco de dados padrão ou o único disponível
Em resumo, parece dizer que a base de contribuidores do PostgreSQL está envelhecendo, e que a Neon está ampliando a base de desenvolvedores ao contratar e treinar juniors em vez de recorrer aos committers existentes
Como programador sem experiência em C/C++, mas interessado, acho que uma série de vídeos explicando o código em detalhes ajudaria muito a começar a contribuir