A Nuvem é uma Prisão. O Movimento de Software Local-First Pode nos Libertar?
A Nuvem é uma Prisão. Software Local-First nos Liberta?
Há alguns anos, o fórum de discussão Hacker News, onde engenheiros decidem coletivamente o que outros engenheiros devem ler, desenvolveu uma peculiaridade. Uma nova frase havia entrado no léxico dos programadores e parecia impulsionar os links para o topo da página com tanta força que, para alguns, as classificações poderiam parecer manipuladas. A frase – “software local-first” – tinha um toque artesanal, do tipo “da fazenda para a mesa”, ao mesmo tempo familiar e apontando para algo novo. Talvez alguns engenheiros a tenham descartado como um mero termo de marketing. Mas outros, enquanto passavam suas tardes de trabalho, pareciam ver isso como a solução para um problema que eles sentiam há muito tempo: O software que eles estavam escrevendo estava quebrado.
Um dos primeiros links do Hacker News se referia a um white paper publicado em 2019, coescrito por um cientista da computação então na Universidade de Cambridge chamado Martin Kleppmann e um grupo de desenvolvedores de código aberto em um “laboratório de pesquisa industrial” independente chamado Ink & Switch. Kleppmann e os outros eram ex-alunos de startups de tecnologia bem-sucedidas que fizeram o que as startups de tecnologia bem-sucedidas geralmente devem fazer: serem adquiridas. Eles haviam entrado em suas maiores compradoras e saído arrependidos, desapontados com certos aspectos de sua indústria. Havia mais desenvolvedores de software do que nunca, mas eles não estavam codificando experiências melhores para seus colegas ou usuários. Eles estavam codificando para a nuvem.
A lamentação não era exatamente nova. Um slogan impresso em adesivos de para-choques, camisetas e garrafas de água no Vale do Silício há muito tempo zomba da indústria local com a afirmação “Não há nuvem. Há apenas o computador de outra pessoa.” Essa “outra pessoa” sendo uma corporação. Venha para a Sand Hill Road com uma ideia para um aplicativo voltado para o consumidor e existem duas maneiras de obter um cheque grande o suficiente para ser mencionado no TechCrunch: Monetizar os dados de seus usuários para revenda ou publicidade, ou cobrar uma taxa para acessar esses dados. Qualquer que seja o modelo de negócio baseado em nuvem que você escolha – “Senador, nós exibimos anúncios” ou “Pague-nos ou então” – é imperativo que os dados passem pelos seus próprios servidores.
O white paper local-first (“manifesto” pode ser o termo mais apropriado) apontou para um terceiro caminho. A beleza da nuvem, para o usuário médio, é que ela é acessível de muitos dispositivos e permite colaboração entre muitas pessoas em salas e continentes diferentes. Os autores propuseram manter tudo isso, mas com um software essencialmente sem nuvem. A palavra “local” no nome refere-se ao seu computador pessoal. “First” significa que seu computador tem prioridade sobre “o de outra pessoa”. Se eu e você quisermos trabalhar em um documento juntos, não precisaríamos mais depender de algum centro de dados do Google no deserto alto do Oregon para manter a cópia principal. Em vez disso, teríamos cada um cópias armazenadas localmente nos discos rígidos de nossos dispositivos. Eu poderia editar minha cópia offline e você poderia editar a sua, e os dois arquivos reconciliariam nossas alterações sempre que se conectassem, seja uma vez por minuto ou uma vez por semana.
Para construir produtos assim, seriam necessárias formas fundamentalmente diferentes de estruturar dados. Matemática diferente. O resultado desse esforço? Software menos ruim. Livres de se preocupar com backends, servidores e taxas exorbitantes de computação em nuvem, startups e desenvolvedores independentes poderiam pular o financiamento de VC com cordas anexadas e buscar aplicativos mais interessantes. Além disso, eles poderiam aproveitar as melhorias de hardware que os desenvolvedores em nuvem muitas vezes perdiam. Quando um aplicativo é baseado em nuvem, seu desempenho é limitado pela velocidade de sua conexão com o servidor central e quão rapidamente esse servidor pode responder. Com um aplicativo local-first, o dispositivo do usuário executa todo o código. Quanto melhor for o seu laptop ou smartphone, mais o aplicativo poderá fazer.
- A Best Buy está praticamente dando este HP Chromebook hoje | ENBLE
- Este monitor Dell de 27 polegadas 4K pode ser seu por $300 hoje | E...
- Esta atualização pode estender a vida do seu Chromebook por anos | ...
Para um desenvolvedor, as tendências opostas de máquinas aceleradas e tempos de carregamento estagnados são bastante bobas. Ofensivas, na verdade. Você também deveria se sentir ofendido, porque significa que você tem perdido algo. A nuvem parece celestial, até que não seja. Você não percebeu, ultimamente, enquanto os cintos se apertam no Vale do Silício, que sua própria internet pessoal parece menos abundante do que antes? Que certas coisas estão ficando um pouco mais caras ou menos convenientes? Um custo mensal para manter todas as suas fotos armazenadas ou fazer backup do seu telefone. Um upgrade premium para permitir que vários usuários editem o mesmo arquivo. Um jogo de vídeo que requer uma assinatura e fica lento quando você está prestes a vencer.
O jornalista e autor de ficção científica Cory Doctorow usa o termo “enshitificação” para descrever como o capitalismo de plataforma desperdiça tecnologia útil. Uma nova plataforma, cheia de capital de risco, é inicialmente boa para seus usuários. Então, os anunciantes vêm atrás de seu público e a plataforma também é boa para eles. Em seguida, ainda faminta por lucros, ela envenena o poço. Ela começa a interferir nas características que você valoriza até que você fique cansado. Isso é “como as plataformas morrem”, escreve Doctorow. A lógica de negócios fria abre esse caminho triste, mas escolhas tecnológicas o pavimentam.
Talvez isso esteja bem. Talvez o processo seja regenerativo, como um incêndio florestal limpando a vegetação rasteira. Isso abre caminho para que novas plataformas voltem a ser boas para nós, pelo menos por um tempo. Mas e se algo diferente pudesse se estabelecer? E se mudar as entranhas do software, invisível para a maioria de nós, pudesse ajudar a tecnologia a sair da merda?
Kleppmann e eu estamos suspensos a três andares acima do estacionamento do City Museum em St. Louis, um antigo fábrica de sapatos convertida em parque arquitetônico e ferro-velho. É hora de fechar, e os guardas querem que a gente desça e saia. No entanto, Kleppmann está mirando no ponto mais alto da estrutura, um jato de negócios vazio da década de 1960, acessível por um tubo com inclinação acentuada feito de malha de corrente. Ele veste um suéter azul royal que instantaneamente o identifica como europeu, seu cabelo laranja-marrom frisado preso em um rabo de cavalo apertado. Enquanto ele desliza para dentro da fuselagem, imagino que estou perseguindo uma raposa.
A noite no museu é a parte favorita de Kleppmann do Strange Loop, que pode ser sua conferência de desenvolvedores favorita. É um evento que mescla alegria e estranheza com praticidade – sua combinação ideal. Kleppmann é talvez mais conhecido por um livro chamado Designing Data-Intensive Applications, que explica os fundamentos de mover grandes quantidades de dados em sistemas de computador vastos. Um guia de sobrevivência peculiar para o desenvolvedor moderno, ele vendeu mais de 200.000 cópias – o suficiente para lhe conferir status de celebridade nesta comunidade. Fãs param Kleppmann perto da boca aberta de uma escultura de baleia em tamanho real e quando ele emerge de um escorregador de cinco andares, agradecendo-o por ajudá-los a conseguir seus primeiros empregos em software.
As sementes do manifesto local-first podem ser encontradas em uma pequena caixa na página 174 do livro de Kleppmann. Ela descreve algo chamado tipo de dados replicados sem conflito, ou CRDT, que ele define como uma “família de estruturas de dados” que permite que muitas pessoas colaborem em um arquivo e “resolvam automaticamente conflitos de maneiras sensatas”. No livro, Kleppmann observa que a implementação de algoritmos CRDT ainda é “jovem”.
Em termos de computação, no entanto, os próprios CRDTs eram antigos. Eles foram co-desenvolvidos por um teórico francês da computação chamado Marc Shapiro cerca de duas décadas atrás, quando a revolução em nuvem ainda estava em seus estágios iniciais. Shapiro, que aderia a muitos dos ideais do movimento peer-to-peer, começou a temer para onde a computação em nuvem poderia levar a web. Embora o protocolo da internet em si permanecesse aberto e descentralizado, o que estava sendo construído em cima dele estava se movendo em direção monopolista. As empresas de tecnologia estavam construindo belos jardins para atrair usuários e, em seguida, construindo muros para impedi-los de sair.
Uma área que eles ainda não haviam conquistado totalmente, no entanto, era a colaboração online. A conectividade não era boa o suficiente na época. Shapiro e seu colega Nuno Preguiça se perguntaram: as pessoas tinham que estar online para colaborar online? Ou eles poderiam trabalhar offline e colaborar peer-to-peer?
Conceitualmente, não era tão difícil imaginar: criar muitas réplicas do mesmo arquivo, cada uma das quais se ajusta automaticamente a um estado idêntico aos seus pares, como átomos em emaranhamento quântico. Se você editar sua réplica primeiro e depois receber minhas alterações, ou se eu editar minha réplica e depois receber suas alterações, o algoritmo produz o mesmo resultado para ambos. Em termos matemáticos, essa é a propriedade “comutativa” (de fato, é o que o “C” em CRDT inicialmente significava).
Como o algoritmo deve fazer isso? Na maioria dos casos, a resposta é simples. Se eu adicionar um parágrafo e você remover outro, a ordem não importa. Mas suponha que nós dois mexemos na mesma palavra; você acha que ela deveria ser roxa e eu acho que deveria ser malva. O que impede o resultado de ser purmaupleve? Diferentes CRDTs resolvem isso com regras diferentes destinadas a preservar a intenção dos vários colaboradores. Eles podem depender de carimbos de data/hora para ordenar os novos elementos, ou talvez tenham algum meio de codificar a relação de cada elemento com os elementos ao seu redor, preservando alguma noção de palavras ou frases. As possibilidades são numerosas.
Esses truques para preservar a ordem também podem tornar o CRDT terrivelmente ineficiente. É muitos dados para acompanhar. Portanto, a outra tarefa ao projetar um CRDT é a de edição: decidir a quantidade mínima de informações que as réplicas precisam enviar umas às outras para produzir um resultado harmonioso e como empacotar essas mudanças de forma eficiente.
Shapiro e Preguiça inicialmente publicaram seu algoritmo CRDT como um relatório técnico. Shapiro pensou em criar uma empresa focada em edição colaborativa. “Alguns meses depois, boom, o Google Docs é lançado”, ele me diz. O novo software usava um processo mais antigo para mesclar alterações chamado transformação operacional, ou OT, e ainda se baseava em um servidor central do Google. Shapiro acreditava ter inventado algo mais teoricamente sólido – uma base estável para software verdadeiramente peer-to-peer. Mas quando Kleppmann encontrou seu artigo anos depois, poucas pessoas estavam usando o software.
Kleppmann cresceu na Alemanha brincando com computadores e sua viola. Depois de uma breve flerte com uma carreira na composição (ideias de “o que era bom e o que era lixo” não concordavam com ele), ele seguiu a clássica trajetória de carreira de um técnico: ele cofundou uma startup (chamada Rapportive, que integrava dados de perfis de mídias sociais em contatos de e-mail); ele se mudou para a Baía de São Francisco (mais perto de investidores e gigantes das mídias sociais); sua startup foi adquirida por um gigante da tecnologia (LinkedIn). Kleppmann durou alguns anos antes de sair para assumir uma posição de pesquisa em Cambridge.
O novo emprego deu a Kleppmann o que ele há muito queria: um retorno à criatividade. Ele tinha flexibilidade para explorar abordagens mais incomuns de programação, incluindo projetos que podem não ter um retorno imediato. Ele explica seu trabalho com uma analogia emprestada de sua esposa, uma professora de química do ensino médio. Se você pensar em bytes individuais de dados como átomos, então as estruturas de dados são como moléculas. Para qualquer novo programador, o próximo passo depois de “olá, mundo” é aprender essas estruturas – listas, árvores, hashes e grafos, para citar algumas categorias amplas. O que Kleppmann queria descobrir eram arranjos atômicos estranhos que pudessem permitir diferentes tipos de aplicativos.
Ele descreve o artigo de Shapiro como “um despertar”. Nos CRDTs, Kleppmann viu a base técnica para uma nova classe de software que ninguém estava fornecendo. Mas os algoritmos eram na maioria das vezes inúteis para programadores profissionais. Eles eram muito ineficientes e não tinham as ferramentas típicas que os desenvolvedores realmente usam para criar aplicativos. Kleppmann percebeu que teria que facilitar a vida dos desenvolvedores locais, conduzindo a ideia de um conjunto de provas matemáticas a um código pronto para produção. Ele começou a codificar uma implementação de código aberto dos CRDTs, que ele chamou de Automerge, que as pessoas poderiam usar livremente para construir aplicativos.
Eu vi o resultado desse esforço alguns anos depois, pouco depois que o manifesto local-first quebrou o Hacker News. Conheci Peter van Hardenberg, um dos coautores de Kleppmann, em um café em São Francisco. Ele era, como Kleppmann, reiniciando após uma longa jornada pela nuvem, primeiro como parte da equipe fundadora do Heroku, que ajudou outras startups a iniciar seus serviços na nuvem, e depois dentro de sua adquirente, Salesforce. Ele queria me mostrar um aplicativo chamado Pushpin, concebido como um quadro de cortiça digital.
Van Hardenberg abriu um projeto em branco em seu iPad. Carreguei uma réplica do mesmo arquivo no meu laptop. Começamos a mexer, adicionando imagens e caixas de texto aos nossos próprios arquivos e, em seguida, permitindo que eles se mesclassem. Às vezes, isso funcionava perfeitamente; outras vezes, as alterações paravam de carregar ou os pixels arrastavam com a latência da era da conexão discada. Pushpin parecia um brinquedo, o tipo de aplicativo que um par de estudantes brilhantes de Stanford poderiam codificar na sala comum, com visões de uma rodada de investimento e, mais tarde, guarda em constrangimento.
Mas van Hardenberg estava longe de estar constrangido. O alicerce técnico estava sendo estabelecido, ele acreditava, para versões local-first do Slack, Discord, Google Docs, Photoshop. Aplicativos de design melhores, calendários, orçamentos. Programas mais complexos também, se pudessem tornar o Automerge muito mais eficiente. Havia a possibilidade de criptografia privada de ponta a ponta para todos esses aplicativos colaborativos, pois nenhum servidor atrapalharia. Havia limites técnicos para CRDTs e muitos aplicativos que a nuvem atenderia muito melhor. Mas para ele, o protótipo parecia uma revolução. Não havia um servidor entre nós. E ainda funcionava. Na maioria das vezes. Éramos dois pares se comunicando, como os primeiros construtores da internet pretendiam.
A visão de Van Hardenberg era um pouco mais fácil de ver quando nos encontramos novamente em St. Louis. Os gigantes da tecnologia estavam escorregando. As ações do Meta estavam no menor nível em sete anos. O Twitter estava no meio de uma aquisição hostil por Elon Musk. Kleppmann estava passando algumas horas por semana como consultor técnico da Bluesky, originada pelo Twitter como um experimento descentralizado e agora repentinamente lançada aos holofotes, pronta para se tornar sua concorrente. Seu design “federado” prometia dar às pessoas a opção de deixar servidores e serviços que as tratavam mal. A Bluesky não estava usando CRDTs, que seriam muito lentos para coordenar os feeds de milhões de usuários de mídias sociais, mas o objetivo era semelhante: um relacionamento melhor com “o computador de outra pessoa”. Alternativas de computação estavam novamente na moda.
Dentre elas, CRDTs. O Strange Loop estava cheio de apresentações sobre local-first – uma surpresa para Kleppmann e van Hardenberg, que até recentemente acompanhavam cada projeto por meio de alertas do Google e boca a boca. CRDTs também estavam surgindo no mundo mais amplo. Desenvolvedores do The Washington Post os usaram para construir uma ferramenta para organizar artigos na página inicial. Pessoas que mexiam no código que roda o aplicativo Notas da Apple perceberam os CRDTs. O Jupyter Notebooks, um popular aplicativo de ciência de dados, restaurou suas ferramentas de colaboração usando CRDTs depois que o Google se livrou do serviço de nuvem no qual dependia anteriormente.
Entre os palestrantes do Strange Loop estava uma desenvolvedora canadense chamada Brooklyn Zelenka, cofundadora de uma empresa chamada Fission. Quando ela leu o manifesto local-first, ela lembra, “eu pensei, essa é uma ótima frase. Antes disso, tínhamos essas frases estranhas, como ‘independência de localização’ ou ‘dados de propriedade do usuário’.” Zelenka estava interessada nas ideias do Web3 – o nome adotado pelos aplicativos “descentralizados” que usam tecnologia blockchain e criptomoedas – mas achou sua cultura “agressiva”, o que ela atribuiu ao foco no dinheiro “tão claramente, o tempo todo”. Foi bom estar entrando cedo no local-first. “Tudo é de baixo alcance agora”, disse Zelenka para mim.
A trajetória dela era comum. Crypto “trouxe todas as piores pessoas”, disse van Hardenberg para mim durante o almoço na conferência, mas também falou sobre muitos dos mesmos princípios do local-first. Em sua opinião, simplesmente usa a abordagem errada, prometendo aos usuários descentralização e independência, mas os prendendo a incentivos financeiros especulativos. Também é o oposto do offline-first: blockchains complicados, controlados por quem acumula mais recursos, mediam cada interação. Ainda assim, a crypto ofereceu uma lição sobre como o hype pode impulsionar a criação de novos produtos. Van Hardenberg observou o grande número de programadores entediados e insatisfeitos na Meta e no Google que pularam do barco no auge da bolha crypto.
O local-first, ele pensou, poderia eventualmente despertar a mesma empolgação, mas com software que fosse realmente bom. O que era necessário, disse van Hardenberg, era uma grande “saída” que traria “sinais de riqueza visível” para algum grupo sortudo de desenvolvedores local-first e ajudaria a atrair mais talento e recursos. O crescimento também era assustador. Até agora, Van Hardenberg e Kleppmann haviam evitado o financiamento de capital de risco para o Automerge em si, temendo que isso os obrigasse a adotar qualquer variedade de modelos de negócios que “contradizem totalmente os valores do local-first”, como Kleppmann me disse. Mas, em algum momento, eles perceberam que o crescimento também seria necessário. Eles esperavam que o software falasse por si mesmo. “Os VCs adoram uma replataforma”, disse van Hardenberg.
Alguns meses após a conferência, “local first” voltou a ser tendência no Hacker News. Um comentarista chamou os CRDTs de a espada “matadora de dragões” que permitiria que aplicativos local-first competissem com a nuvem. Outro lamentou que cada post técnico interessante sobre CRDTs se transformasse em uma “discussão política estranha sobre descentralização”.
Apesar de muitos movimentos em direção à descentralização da tecnologia, o tesouro do dragão de ouro continua crescendo. Um problema é a percepção de que princípios vêm em detrimento da conveniência. Por mais gratificante e virtuoso que seja construir sua própria mesa de café, também é difícil. Eventualmente você se cansa e compra sua próxima peça de mobília na Amazon. O mesmo acontece com o gerenciamento de seus dados. “É muito mais fácil ser preguiçoso e deixar a Apple ou o Google fazerem isso por você”, disse Shapiro para mim. Quando perguntei a ele como era usar a internet moderna seguindo seus princípios, ele disse que simplesmente se abstém de tecnologia o máximo que pode. “É um terrível desperdício de tempo”, ele me disse.
Fiquei curioso se o termo “local first” incomodava Shapiro de alguma forma, se ele o considerava uma rebranding indesejada de sua criação técnica. Fiquei surpreso quando ele me disse que amava. Ele achava que havia algo de mágico na frase. Talvez a revolução precise ser um pouco sorrateira para desferir um golpe: atrair desenvolvedores com as possibilidades técnicas, chamar isso de “movimento” para atrair jornalistas obcecados por política (oi). Talvez também precise chegar no momento certo, quando as plataformas de Big Tech parecem prontas para desmoronar, revelando os recursos perdidos e os abusos sofridos em troca de conveniência.
Kleppmann não estava exigindo um retorno ao analógico ou a destruição de todos os servidores em nuvem, que fazem muitas coisas úteis. A espada não era uma assassina, mas uma ferramenta para criar algo melhor – e ele mesmo diria que ela ainda precisa ser afiada. Quando perguntei a ele se eu poderia experimentar um novo editor de texto baseado em CRDT em que ele estava trabalhando, sua expressão usual de calma e atenção se transformou brevemente em alarme. Claro, teoricamente eu poderia usar o protótipo que está postado online, já que é de código aberto – “mas por favor não faça isso”, ele me disse. Ele me avisaria quando o local-first estivesse pronto.
Diga-nos o que você achou deste artigo. Envie uma carta para o editor em [email protected].
