Postado por Salvatore Sanfilippo, desenvolvedor e mantenedor do Redis Database Engine gratuitoAlguns meses atrás, eu fui escrito pelo mantenedor de um projeto de código aberto do sistema com uma comunidade bastante grande e ativa. Ele escreveu que há muitos anos luta para apoiar seu projeto, mas está passando por um sério estresse psicológico. Eu pedi conselhos. Respondi que mal podia dar conselhos, mas prometi escrever um post sobre o que penso sobre isso.
Várias semanas se passaram, eu comecei a escrever este post várias vezes e parei porque não tinha tempo para refletir sobre isso completamente. Agora, ao que parece, concluí a auto-análise de minhas fraquezas, dificuldades e desejo de liberdade. Esses sentimentos inevitavelmente abraçam a mente humana quando se concentra em alguma tarefa, e um aspecto negativo se manifesta por um longo tempo. Obviamente, apoiar o projeto Open Source também traz muita alegria e prazer. Os últimos dez anos da minha vida profissional certamente serão lembrados por muito tempo. Estes são bons anos, embora não sejam os melhores (foi ainda mais divertido durante o lançamento). Mas aqui vou me concentrar no lado negativo. Basta ter em mente que existem pontos positivos.
Avalanche de pedidos
Não acredito em "ação rápida", "pensamento rápido", "vitória ao longo do tempo" e coisas do gênero. Não gosto do mundo superficial com a falta de concentração e atenção em que vivemos por causa das redes sociais, salas de bate-papo, e-mail e uma programação cheia de eventos. Nos primeiros anos de Redis, eu ainda tinha muito tempo. Quando a carta chegou, eu pude me concentrar calmamente no que o autor estava tentando dizer. Lembro-me da parte relevante do código Redis e, depois de considerar cuidadosamente o problema, finalmente expressei meus pensamentos reais. Acredito que é assim que a maioria das pessoas deve trabalhar, não importa qual seja o seu trabalho.
Quando um projeto de software atinge popularidade, como o Redis, e a comunicação entre as pessoas é tão simplificada quanto nas ferramentas sociais modernas, tudo muda. Os usuários tratam você como uma entidade inanimada, e o número de mensagens, perguntas, solicitações e sugestões está crescendo exponencialmente. Mas, ao mesmo tempo, na comunidade Redis (embora me pareça que isso seja um problema comum), o número de pessoas que são capazes de responder habilmente a essas perguntas está crescendo muito lentamente. Um congestionamento óbvio é criado. A maioria das pessoas é muito pragmática sobre esse problema. Encerramos o ingresso se o iniciante não responder à nossa pergunta dentro de duas semanas. Feche todos os tickets com palavras vagas. E outras opções para limpeza mecânica do fluxo. Mas a realidade é que leva tempo para processar bem as revisões. Caso contrário, você simplesmente finge que o projeto tem poucos tickets abertos. Seria bom ter muitos recursos para contratar especialistas em tempo integral remunerados para dar suporte a cada subsistema Redis por um dia inteiro, mas, na realidade, isso não é viável.
Então o que está acontecendo? Você começa a priorizar mais: o que considerar e o que não. E você se sente uma merda, ignorando tantas perguntas e tantas pessoas, e colaboradores acreditam que você não se importa com o trabalho deles. Esta é uma situação difícil. Normalmente, no final, apenas problemas críticos são resolvidos no final. Tudo o que é novo é ignorado, porque novas funções ainda não se tornaram básicas e quem deseja aumentar a base de código recebe mais solicitações e problemas de pull? Você pode estar começando a escrever um código mais confuso do que o normal. Quanto mais confuso o código, mais difícil é rastrear a causa raiz no caso de um erro crítico.
Alteração de função
Devido à avalanche de solicitações descritas acima, seu trabalho também está mudando repentinamente. Redis se tornou popular porque eu meio que sei como criar e escrever código. E agora, em vez disso, lido principalmente com a solução de problemas e solicitações de recebimento. E constantemente parece que eu mesmo escreveria um código melhor do que nessas solicitações pull. Embora, às vezes, o código seja melhor do que eu próprio, porque existem melhores programadores na comunidade Redis. Mas a
maioria é simplesmente escrita para resolver um problema específico. Embora eu sempre represente o sistema como um todo, porque o trabalho há muitos anos. Mas não há mais tempo para fazer isso. Assim, grandes novas funções são menos organicamente integradas no código principal. O que há para fazer? Às vezes, passo várias semanas em tickets e recebo solicitações porque codifico ou desenho: esse é um trabalho que eu realmente amo e gosto. Mas isso, por sua vez, aumenta a pressão psicológica, porque eu ignoro todos.
Para fazer o que eu amo e saber fazer bem, você precisa se sentir uma merda.
Tempo
Existem dois problemas de trabalho longo em um projeto, pelo menos para mim.
Em primeiro lugar, antes da Redis, eu
nunca trabalhava sem descanso todos os dias úteis. Eu poderia trabalhar por semana, parar por dois, depois trabalhar por um mês, desaparecer por dois meses. Sempre. As pessoas precisam recarregar, obter novas energias e idéias, ser criativas. E a programação de alto nível é um trabalho criativo. O próprio Redis viveu assim nos primeiros dois anos, ou seja, quando se desenvolveu na velocidade máxima. Porque a exaustão total do meu trabalho quando quero trabalhar é maior do que quando tenho que trabalhar todos os dias de maneira sustentável.
Quando eu trabalhava sozinho, eu podia pagar um horário gratuito. Assim que comecei a receber dinheiro do Redis Labs, minha ética não o permitia mais. Eu tive que me forçar a trabalhar em um horário normal. Esta é uma luta séria comigo mesma, que venho travando há muitos anos. Além disso, tenho certeza de que, por causa disso, a qualidade e o volume do trabalho diminuíram, mas não há nada a ser feito: tudo está organizado neste mundo. Não encontrei uma maneira de resolver esse problema. Eu poderia dizer ao Redis Labs que quero voltar à minha agenda antiga, mas não faz sentido, porque no momento estou “reportando” para a comunidade e não para a empresa.
Outro problema é que muito trabalho em um projeto também é uma coisa difícil, mentalmente. No passado, eu mudava o projeto especificamente a cada seis meses. Eu faço a mesma coisa há dez anos. Para manter minha mente, iniciei subprojetos dentro do Redis. Depois de criar um cluster, o outro - armazenamento em disco (agora abandonado), HyerLogLogs, etc. Basicamente, essas coisas são úteis para o projeto, mas, em essência, são outra coisa. Mas, no final, você sempre retorna à mesma página com tickets, solicitações de recebimento e faz a mesma coisa todos os dias: "A réplica é desconectada devido a um tempo limite" e assim por diante. Bem, vamos lidar com isso mais uma vez.
Medo
Eu sempre tive medo de perder a liderança tecnológica no projeto. Não porque eu não seja bom em projetar e desenvolver Redis, mas porque sei que meus caminhos não correspondem ao que um grande número de usuários deseja e ao que a maioria das pessoas em TI considera um bom software. Portanto, preciso equilibrar constantemente o que considero um bom design, um conjunto de funções, velocidade de desenvolvimento (lenta), tamanho do projeto (mínimo) e o que devo distribuir para a maioria dos usuários. Felizmente, há uma porcentagem de usuários Redis que entendem muito bem o Redis, então, pelo menos, recebo algumas palavras de suporte de tempos em tempos.
Desacordo
Algumas pessoas são idiotas completas. Eles estão por toda parte, é natural. Na minha opinião, há muito mais pessoas boas em programação do que em outras áreas. Mas sempre há uma porcentagem de idiotas absolutos. Como líder do popular projeto OSS, você terá que lidar com eles de qualquer maneira. Talvez essa seja uma das coisas mais estressantes com que lidei durante o desenvolvimento do Redis.
Futilidade
Às vezes, parece-me que mesmo o software mais excelente nunca dura para sempre, como uma obra-prima da literatura. Observe que isso não se deve à sua qualidade, mas como um efeito colateral de sua função utilitária ... É útil na prática. É por isso que algo mais útil virá para substituí-lo. Eu gostaria de ter tempo para outras aulas. Portanto, às vezes parece que todo o meu trabalho, no final, é inútil. Nós projetamos e escrevemos sistemas, mas novos aparecerão. Em geral, pelo menos um programador aplicado, e não um teórico com "grandes idéias", é capaz de deixar algum rastro? De tempos em tempos, acho que tive a oportunidade de trabalhar em grandes idéias, mas me concentrei em escrever o software, em vez de pensar nele. Portanto, não pude usar meu potencial nesse sentido. É o oposto da síndrome do impostor: desculpe-me por ser mais modesta.
No entanto, pude trabalhar por muitos anos, fazendo o que realmente amava, o que me dava amigos, reconhecimento, dinheiro. Isso não quer dizer que foi um mau negócio. No entanto, entendo perfeitamente que as pessoas enfrentam grandes desafios assim que seu projeto se torna popular. Este artigo é dedicado a eles.