Qual é a vida dos criadores de bibliotecas populares de código aberto? Claro, é bom quando o resultado do seu trabalho ajuda muitas pessoas ao redor do mundo. Mas você se vê sobrecarregado com tarefas que nem são seu trabalho principal? Como lidar com isso? Com que ousadia alguém pode delegar autoridade?
Michelle Weststrate está bem ciente de tudo isso: sua biblioteca
MobX tem mais de 17.000 estrelas no github, o número de seus colaboradores há muito tempo excede cem. E logo Michelle virá à Rússia para falar no HolyJS, para que os membros do comitê de programa da conferência (Dmitry
DmitryMakhnev Makhnev e Evgeny
bunopus Kot) lhe perguntem em detalhes: sobre o código aberto em geral, especificamente sobre MobX e sobre as conferências.
Eugene: Você pode falar um pouco de si mesmo para aqueles que não o conhecem?"Sim, claro." Meu nome é Michelle Weststrate (que é difícil demais para a maioria das pessoas pronunciar), sou da Holanda. Na maioria das vezes, eles me conhecem do meu trabalho no MobX ou no
immer . Eu trabalho para Mendix. Criamos software que produz software: uma plataforma de desenvolvimento de aplicativos que muitas empresas de consultoria usam. Automatizamos um grande número de seguradoras bancárias e sistemas similares. Eu faço o lado técnico - ou seja, o que eu gosto. E cerca de dois anos atrás, eu me envolvi no mundo do código aberto, a partir desse momento, eu estava ativo tanto na comunidade React quanto na comunidade JS em geral.
Eugene: O que exatamente você faz em Mendix, existem consultores técnicos?Sim. Eu tenho vários papéis diferentes lá, e o principal é Tehlid. Em essência, isso significa que sou responsável pela seleção de soluções técnicas para uma de nossas
"tribos" . Portanto, estou trabalhando em um produto que é um ambiente para aplicativos móveis. Trabalhamos com quatro equipes e, principalmente, tomo as decisões arquitetônicas e tecnológicas certas. Além disso, ainda estou programando. Esta é uma parte do meu trabalho.
E o outro é a participação na comunidade de código aberto. Esta é uma atividade "bidirecional". Por um lado, estamos fazendo coisas técnicas interessantes que quero compartilhar em conferências e falo por conta própria ou incentivo os colegas a falar. Por outro lado, o contrário é bom em visitas frequentes a conferências: você encontra algo que pode ser útil para nós, depois o estudamos e o incluímos em nossa pilha.
Eugene: O Evangelismo OSS é mencionado na sua descrição do Twitter. O que é e por que é importante para você?- A primeira razão pela qual isso é importante: descobri que se você traduz seu desenvolvimento em código aberto, não economiza tempo, mas ajuda muito nos testes e melhora a qualidade. Porque uma biblioteca como MobX é usada em condições muito diferentes. E acho que, nesse sentido, o código aberto oferece uma vantagem que é muito difícil obter de outra maneira.
E a segunda: acredito que nossos desenvolvimentos de "baixo nível" não definem a empresa; então, por que não compartilhá-los? Quero dizer, uma empresa é mais ou menos competitiva por um produto feito com base em suas tecnologias - e não essas tecnologias por si só. E todos se beneficiam da colaboração, isso permite que o desenvolvimento como um todo acelere.
Eugene: Às vezes eles dizem que o código aberto "não monetário" é realmente um prazer muito caro. Projetos como o Linux exigem muito dinheiro de gigantes como Oracle e Microsoft. É isso mesmo? Uma comunidade de código aberto pode existir sem grandes fornecedores e dinheiro?Acho que depende da situação específica. Existem pequenas bibliotecas que poderiam existir assim. Mas projetos como o kernel do Linux ou o React Native mencionado acima são tão complexos e tantas pessoas dependem deles que precisam de um modelo financeiro confiável. Nesse caso, sem grandes patrocinadores, seria muito difícil. Mas não acho que isso seja um problema. Eu acho que é mais importante que as empresas aprendam a assumir responsabilidades do que aprendemos sem elas.
Eugene: Por exemplo, se o Facebook vier até você e disser “Vamos comprar a MobX ou patrociná-la para que o desenvolvimento fique sob a nossa marca”?- Bem, na verdade, eles já patrocinam! É engraçado, mas o Facebook é um dos patrocinadores da MobX
no Open Collective . Então, de certa forma, isso já aconteceu. Na minha opinião, o Open Collective é um ótimo exemplo de como podemos melhorar a posição financeira do código aberto. Ele permite que as empresas patrocinem o desenvolvimento de uma maneira que lhes convenha, porque existe uma abordagem financeiramente séria, com faturas e similares.
Na Mendix, eu basicamente paguei muito para trabalhar no MobX, então não estou interessado em mudar para o Facebook completamente. Entendo que isso pode interessar a outra pessoa, mas não vejo problema nisso. Na minha opinião, se a licença permanecer de código aberto, não há nada errado com o fato de o produto ficar sob a marca do principal patrocinador. É como assistir futebol na TV: se todo mundo pode ver o jogo, não há muita diferença no logotipo das camisetas.
Eugene: Se uma grande empresa patrocina a biblioteca, ela não pode dizer "Como pagamos tanto, por favor, faça isso conosco"?"Eu não encontrei isso, pelo menos, para que isso se torne um problema." Se não me engano, o webpack usa esse modelo, é possível pagar por recursos lá. Portanto, há algum risco, mas acho que é responsabilidade dos mantenedores garantir que o projeto permaneça fiel à sua filosofia. Mas, dentro dessa filosofia, é provável que haja muito espaço para manobras. Além disso, em código aberto, se de repente algo der errado, pelo menos a possibilidade de bifurcação permanece.
Eugene: O desenvolvimento de software de código aberto é como uma curva: primeiro você cria uma biblioteca que ninguém mais precisa, depois as pessoas começam a usá-lo, depois ganha milhares de estrelas no github e assim por diante. Quando um projeto de código aberto se torna popular, pode demorar muito tempo. Quanto você gasta no MobX?- Recentemente, não muito. MobX é bastante estável no momento. Passamos muito no passado, é claro. Foi muito diferente. Acho que durante os primeiros dois anos foram algumas noites por semana e houve muitos outros pequenos momentos em que você simplesmente responde questões ou questões menores no Twitter. Essas pequenas coisas não são sentidas como um investimento significativo de tempo, mas acho que no total elas aumentam significativamente. No entanto, é muito difícil de medir. É assim que se verifica o correio comercial - você verifica o problema e envia rapidamente uma resposta.
Eugene: Como ser produtivo em uma situação em que você é desenvolvedor, criou uma biblioteca, tornou-se popular e requer cada vez mais tempo? Você tem sorte, você tem a oportunidade de fazê-lo durante o horário de trabalho. Mas se você já tem um emprego e um hobby, e o projeto se torna mais popular?- Bem, quando comecei a trabalhar no MobX, também era apenas no meu tempo livre, o trabalho foi adicionado quando o projeto alcançou popularidade. Mas eu tenho algumas dicas. Percebi que existem várias regras que me ajudaram.
Primeiro: acompanhe a relevância da documentação. Se você recebeu a mesma pergunta três ou quatro vezes, registre a resposta na documentação. Porque, em última análise, você economiza tempo.
Segundo: seja muito exigente sobre qual problema você aceita. No início, assim que você for informado sobre um erro, tente reproduzir o problema com base na descrição disponível. E, em alguns casos, você acha que isso é impossível e o tempo já foi gasto. Portanto, agora exijo algo que possa ser executado diretamente do problema, seja um código na sandbox ou uma solicitação de recebimento com testes de unidade. Algo que me permite determinar onde está o problema - na biblioteca ou no lado do usuário. Isso é muito importante, pois permite economizar tempo e garantir que o autor da edição esteja pronto para investir seu tempo. Alguns dizem: "Não tenho tempo para ajudar a reproduzir o bug" e sinto: "Bem, então não tenho tempo para ajudar a resolver seu problema". Afinal, uma pessoa provavelmente é paga pelo trabalho em que usa minha biblioteca - por que então devo investir meu tempo livre no problema dele? Em geral, essa seletividade ajuda, embora faça você se sentir um pouco menos responsável, porque deseja ajudar a todos. Mas descobri que "ajudar a todos" é simplesmente irreal.
E, no entanto, como trabalho com várias bibliotecas, não respondo a todos os problemas instantaneamente, mas “pulo” de uma biblioteca para outra: trabalho nela vários dias por vez e depois passo para a próxima. E posso responder em questão de minutos se você escreveu sobre o que estou fazendo agora, mas não posso responder por dias se a sua vez ainda não chegar. Isso me ajuda a alternar contextos com menos frequência.
Todas essas dicas ajudam quando sua biblioteca começa a ganhar popularidade.
Eugene: Quando o criador da biblioteca popular responde: "Não consigo reproduzir, escreva um teste de unidade", isso não faz as pessoas sentirem que "ele é arrogante e não quer ajudar"?- Me deparei com esse efeito, mas muito raramente. Eu acho que geralmente o usuário entende que os mantenedores estão bastante ocupados e que o problema com alta probabilidade está do seu lado. Acho que se você usar o filtro Lodash e tiver um problema, haverá um sentimento involuntário "provavelmente, algo está errado comigo, porque todo mundo usa o Lodash". Portanto, a maioria das pessoas entende que deve ter cuidado nas questões.
Eugene: Quando a biblioteca se torna popular e requer mais tempo, quanto vale compartilhar seu papel de colaborador, dando direitos a outros membros da comunidade?- Essa é uma ótima idéia, geralmente concedo os direitos de um colaborador assim que vejo várias solicitações de recebimento de uma pessoa (ou mesmo uma solicitação de recebimento, se for grande). Na minha opinião, isso funciona muito bem. Por exemplo, na árvore de estado do MobX, a maior parte do trabalho agora é feita por outras pessoas, não eu. E há outras partes da base de código que as pessoas entendem melhor que eu, e é ótimo que tudo tenha chegado a esse estado. Para o MobX “básico”, isso não é necessário, porque tudo já foi resolvido lá, os algoritmos não mudaram nos últimos dois anos, portanto, o trabalho de suporte é pequeno. Mas no caso da MobX-state-tree, eu escolhi deliberadamente aquelas pessoas que criam muitas bibliotecas de usuários e lhes dei os direitos do mantenedor. Afinal, se você usar ativamente a biblioteca em seu trabalho diário, encontrará padrões ou problemas comuns que eu perdi. E também, penso, isso dá aos desenvolvedores motivação e um senso de confiabilidade - porque eles podem ajudar a biblioteca a trabalhar com o que eles enfrentam.
Eugene: Ao mesmo tempo, não há sensação de que a biblioteca, quando criança, está sendo espancada? Talvez você não concorde em como exatamente as outras pessoas o desenvolvem?- Às vezes acontece um pouco. Mas acho que isso é normal. Você fez uma grande analogia com as crianças: com o tempo, elas crescem, completam 18 anos e, em seguida, você precisa deixá-las ir, porque é hora de encontrar o seu próprio caminho. Eu acho que, até certo ponto, também com bibliotecas de código aberto. Se tiverem sucesso, você começará a enfrentar situações mais difíceis. Você começa a lidar com casos com os quais eu geralmente não gostaria de lidar. O código não será mais o código bonito, limpo e minimalista que eu originalmente queria. Isso é inevitável.
A MobX tem um ótimo exemplo disso: eu originalmente escrevi para o TypeScript, onde os decoradores são muito simples, e as pessoas começaram a usá-lo com o Babel, onde há uma implementação completamente diferente. E, no final, algumas partes da base de código são muito desagradáveis porque estão tentando determinar se você está usando TypeScript ou Babel. Parece horrível e parece horrível. Mas isso faz parte do trabalho. Não é necessário amá-lo, mas é necessário garantir que tudo funcione bem em todos os lugares. E, nesse sentido, seu filho pode seguir uma direção em que você não pensou, mas isso é normal, porque, em última análise, é importante que as pessoas possam usar o projeto com sucesso.
Eugene: O desenvolvimento está mudando, muito está se tornando mais fácil do que há 10 a 20 anos atrás. O que você acha da situação atual do código aberto em conexão com essas mudanças e o que você espera do futuro? As grandes empresas tornarão a alimentar a todos, ou, inversamente, os entusiastas?- Esta é uma pergunta difícil. Não tenho certeza se haverá grandes mudanças. E há mudanças nas duas direções ao mesmo tempo. Estou particularmente impressionado com o Facebook e a Microsoft - quanto eles estão abrindo agora e até que ponto permitem que desenvolvedores de terceiros façam uma contribuição. O React Native é um exemplo particularmente impressionante, em que grande parte do trabalho não vem do Facebook. Por outro lado, para um solitário, provavelmente nunca foi tão fácil participar de um projeto de código aberto ou criar o seu, como é agora. As ferramentas estão se tornando mais padronizadas, temos ótimos IDEs on-line, como
CodeSandbox e
Gitpod . Eu tenho trabalhado com o Gitpod nas últimas semanas, e isso é ótimo: posso verificar solicitações de recebimento sem nem mesmo fazer nada localmente. Você pode simplesmente executar no Docker em um navegador e desenvolver lá. Então, eu não sei quais serão as mudanças.
Eugene: Oito anos atrás, quando eu era desenvolvedor de C ++, não havia uma comunidade de código aberto como agora. E agora no mundo da web e do JavaScript, vejo que o código aberto está se desenvolvendo cada vez mais rápido. Esse crescimento continuará?Acho que o movimento continuará. Um dos motivos, na minha opinião, é o seguinte: empresas e desenvolvedores estão cada vez mais entendendo que o código aberto não é apenas útil para quem o desenvolve ou o utiliza, mas também ajuda a encontrar funcionários. Observando a participação de uma pessoa no código aberto, você pode entender mais sobre ela do que se entrevistá-la o dia todo. A maneira como ele responde à questão ou a inicia mostra muito. Eu acho que desenvolvedores e empresas estão se tornando cada vez mais conscientes da importância disso.
Eugene: Então você acha que o desenvolvimento de uma biblioteca de código aberto pode ajudar com uma entrevista?Exatamente. Se você é uma empresa e possui bibliotecas que não estão totalmente vinculadas à sua API, isso é ótimo, porque as pessoas vão participar - e elas podem ser exatamente o que você precisa. E se você contratar um de seus colaboradores, será mais fácil para eles ingressar e entenderá melhor o que esperar. Eu acho que, apenas por esse motivo, muitas coisas interessantes foram abertas.
Dmitry: Falamos sobre código aberto em geral, vamos seguir especificamente para o MobX. Como e por que você começou a fazer isso inicialmente?Boa pergunta. Nós da Mendix há muito tempo temos um aplicativo do Windows escrito em C #. Alguns anos atrás, decidimos portá-lo para a web e começamos a descobrir qual pilha usar. A reação estava apenas começando, Angular já existia há algum tempo, Ember era bastante popular. E rapidamente, nos apaixonamos pelo React por causa de seu modelo de componente e sua camada de abstração proposta.
Porém, descobrimos que tínhamos um problema de desempenho; a atualização completa do DOM era bastante cara, mesmo no caso do React. Em C #, atualizamos constantemente o modelo e redesenhamos toda a tela, e ninguém otimizou nada, porque tudo funcionava muito rapidamente, portanto não era necessário "abordar a renderização de maneira inteligente". Mas aqui descobrimos que, no caso do DOM, você não pode redesenhar tudo 60 vezes por segundo. Então pensamos em como fazê-lo efetivamente. Pensamos na abordagem imutável, mas, no nosso caso, ela não se encaixava por várias razões. Um deles é com que dados trabalhamos e como foram renderizados. A mesma informação foi renderizada em vários lugares. Nossos dados são muito difíceis de normalizar. E em segundo lugar, parecia que você ainda precisava lidar com muitos detalhes. Por exemplo, você precisaria escrever seletores para os dados que está renderizando.
Mas e se você quiser escrever o mesmo código simples que o nosso código C #, "renderize algo" antes e não quiser se preocupar com como isso mudará no futuro? Se você não quiser dizer aos componentes "Então, pegue essa parte dos dados daqui, mas daqui em diante, e então poderá renderizar alguma coisa"? Começamos a estudar quais tecnologias estão atualmente disponíveis e rapidamente chegamos ao paradigma usado em Knockout, Meteor e (pelo menos conceitualmente) até em Angular. Onde você não quer dizer o relacionamento entre dependências e componentes de dados ou o que deve ser renderizado quando.
Comecei a entender por que as pessoas frequentemente odeiam essas abordagens, principalmente quando o aplicativo cresce. E, na maioria das vezes, as pessoas estão preocupadas com a falta de previsibilidade e "depuração", que algo pode ser feito com muita frequência, ou raramente, ou na ordem errada. E eu decidi que podemos fazer melhor. Podemos nos empenhar pelo mesmo objetivo, mas com uma abordagem mais inteligente da implementação. E assim MobX apareceu. Ele não captura apenas o relacionamento entre observações e observáveis, mas cria um gráfico de dependência inteiro, para que você possa ter certeza de que todos os observadores são executados na ordem mais eficiente. Na programação reativa, existe o conceito de "falha" - e, portanto, aqui isso não pode ocorrer. Em geral, uma já existente foi usada aqui, mas com uma tentativa de torná-la mais previsível.
Dmitry: Ou seja, se eu gosto de algum tipo de abordagem, mas as bibliotecas existentes não são boas o suficiente, você pode simplesmente aceitar e fazer melhor, e isso pode se tornar popular?Sim, exatamente! Então, escrevi inicialmente para nossos propósitos internos e depois fui para o ReactEurope. Parece ser 2015, e houve muita conversa sobre os padrões de fluxo. Então as guerras do fluxo começaram. E senti que as pessoas colocam muita energia em um problema que já resolvemos.
E então pensei: "preciso me abrir". E funcionou. Provavelmente porque não era “outra implementação do Flux”, mas algo completamente diferente. Tem sido útil para muitas pessoas.Eugene: A ideia original do MobX era simples, mas agora há muitos códigos e recursos. Existe uma sensação de que tudo é muito complicado?— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 ,
Proxy .
: Proxy. - , . ?— , , Proxy - , . . Chrome 8, , .
: . , jQuery -, , - . Redux MobX. ?— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .
, , React UI. . , - UI .
: ? , ?— , . , immutable values. , , immer — , immutable states JS. , state management. ,
, , . , , , GraphQL, , . …
: -, MobX?— , , , . . : , to-do list . , , todo. , - , todo- , . . , .
: . . , - . , ?— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .
: ( , ) , , Medium YouTube. ?— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .
Eugene: Ótimo conselho. Você estará na Rússia pela primeira vez - o que você espera de Moscou e da conferência?- Eu definitivamente quero olhar para Moscou e definitivamente ficarei chocado com isso. E também notei que existem muitos usuários de MobX na Rússia. Eu vejo isso no rastreador, em confirmações. Por isso, espero encontrar muitos usuários MobX na conferência.Você pode ver Michelle e fazer perguntas para ele no HolyJS 2018 Moscow , que será realizado de 24 a 25 de novembro . Lá ele vai falar mais sobre gestão do estado. Veja uma descrição dos relatórios da conferência em seu site .