O livro consolida quase tudo que eu escrevi sobre IA aqui no blog de fevereiro a outubro de 2026: todas as experiências, os projetos Frank, os benchmarks, bilhões de tokens gastos e centenas de horas de trabalho ao longo de oito meses, reorganizados num formato mais fácil de ler do que uma pilha de posts datados. Saiu em português e em inglês.

Aviso importante: isso é um preview. O livro ainda está em andamento e vão sair novas versões até eu considerar ele pronto. Se você achar qualquer coisa errada, de erro de digitação a fato, abra uma issue no GitHub. O rastro que eu descrevo abaixo existe justamente pra que a correção chegue no parágrafo certo.

Este texto é sobre o bastidor técnico. Como se transforma 131 posts de blog, escritos ao longo de meses, com opiniões que mudaram no caminho, num livro com começo, meio, fim, apêndice, glossário e bibliografia. E como se faz isso com agentes sem perder o controle do que o livro diz.

O que tem dentro

Cinco partes, cada uma respondendo a uma pergunta que as pessoas vivem me fazendo:

1. O que é essa coisa, afinal. Ela é inteligente? A AGI está chegando?
2. A maratona. Funciona de verdade, ou é tudo demo?
3. Números e propaganda. Qual IA é a melhor? Dá pra acreditar nos anúncios?
4. Quem fica com as chaves. É perigoso deixar ela mexer nas minhas coisas?
5. E o meu emprego? Ela vai me substituir? O que vem depois?

São 20 capítulos e dois interlúdios, mais prefácio, um “como ler”, um “antes de começar” dizendo o que o livro deixa de explicar e onde aprender, epílogo e posfácio. Depois vêm dez apêndices (a máquina por dentro sem matemática, leituras pra ir mais fundo, como estudar com a IA do lado, três bolhas, linha do tempo, kit mínimo pra usar agente com segurança, ai-memory, como ler um benchmark ou um anúncio, os projetos do ano, e os bastidores pra quem programa), as fontes, os créditos de imagem, um glossário de quase 150 termos e mais de 300 referências em ABNT. A edição impressa passa de 500 páginas em 6 por 9 polegadas; a de tela, uns 475. São mais de 50 figuras, todas com ficha de origem.

O público é diferente do blog. O livro foi escrito pra quem está ansioso ou confuso com IA: o profissional com medo de ser substituído, o pai que leu que a AGI chega em dois anos, o gerente a quem estão vendendo uma “transformação por IA”. A maioria não programa. Isso muda a voz, e eu volto nisso.

O problema: meio milhão de palavras que discordam entre si

Em 12 de outubro publiquei a síntese do ano, que virou o capítulo 20. No dia 13 comecei o livro. Eu tinha 131 textos de 2026 no blog, quase meio milhão de palavras, de benchmark de modelo a carteira de bitcoin.

Reorganizar isso à mão levaria meses. E tem um problema pior que o volume: eu mudei de opinião durante o ano. Refiz o benchmark várias vezes, corrigi custos, troquei de ferramenta, e um post de fevereiro contradiz um de setembro com toda a naturalidade. Um livro que simplesmente colasse os posts em ordem seria um livro que se contradiz.

Então fiz o que o livro inteiro descreve: entreguei o trabalho braçal pra agentes de código, e fiquei com a parte de decidir, montar o processo e conferir. O processo é o assunto deste texto.

Passo 1: um inventário lacrado

A primeira coisa foi um script que lê os 131 posts e grava, pra cada um, o hash SHA-256 do arquivo em português e do arquivo em inglês, mais o commit exato do repositório do blog de onde tudo foi lido. Se uma vírgula muda num post, o hash muda junto. Esse arquivo é gerado por máquina e nunca editado à mão.

Depois, um agente leu cada post e preencheu um formulário fixo, com esquema definido em YAML: a tese em uma ou duas frases, as afirmações que um livro precisaria conferir, quais delas envelhecem rápido, que medo de leitor leigo o texto responde, o que cortar. Cada análise leva o hash do post de onde saiu.

Dos 131 textos, 96 tinham IA como assunto central ou com peso relevante. Os outros só entraram quando ensinavam alguma coisa específica, e cada post sobre IA deixado de fora tem o motivo anotado no arquivo de estrutura. Um script reprova a estrutura se qualquer post de IA estiver sem destino.

Linhagem: quem substitui quem

Pra resolver o problema das contradições, existe um mapa de linhagem. Ele diz qual post substituiu qual, o que ainda dá pra aproveitar do mais velho, e quais correções vindas dos projetos de referência (o repositório do benchmark, o do ai-memory, o do ai-jail, as anotações do meu servidor de casa) se aplicam a cada texto.

A regra pros capítulos é contar o estado mais recente e, quando a mudança ensina alguma coisa, contar a mudança. “Em junho eu achava X; em julho os números diziam Y” é história. Imprimir o número velho como se fosse atual é erro, e o verificador trata como erro.

Passo 2: a estrutura é dado, e gera a configuração

Das análises saiu uma proposta de estrutura: cinco partes, cada uma respondendo a um medo do leitor, vinte capítulos, dois interlúdios. Eu li, mexi e aprovei. Algumas peças entraram a meu pedido, como o “antes de começar” e o apêndice sobre a máquina por dentro.

Essa estrutura vive num único arquivo YAML, e ele é a fonte da verdade. Cada capítulo tem lá o id, o título, a cena de abertura, a pergunta que responde, o arco, a lista de posts de origem e as ideias de figura. A configuração do Quarto, que monta o livro, é gerada a partir desse arquivo por script. Ninguém edita a configuração na mão.

Isso importa porque mudança estrutural é onde livro quebra. No meio do caminho eu mudei o corte: os textos de janeiro saíram, e a história ficou entre fevereiro e outubro. Dez posts sumiram da base.

Três capítulos precisaram de cena nova, uma dúzia de unidades precisou de reparo pequeno, e o estrago difícil de ver estava em outro lugar: uma frase num capítulo intocado dizendo “os cinco revisores do capítulo 5”, a linha do tempo, o apêndice de projetos, rótulos de gráfico, cada tradução. Por isso existe um script de impacto que, antes de qualquer edição, lista cada parágrafo, figura, referência e tradução que depende de um post.

Passo 3: um capítulo piloto vira contrato

Antes de escalar, um capítulo piloto. Escolhi o capítulo 5, sobre os primeiros dez por cento de um projeto, e ele serviu pra calibrar a voz e descobrir as dúvidas que um agente teria no meio do caminho. Cada dúvida resolvida virou uma regra escrita.

Essas regras foram pra um documento de contrato que todo agente lê antes de escrever, junto com três coisas:

• o guia de voz do livro, que herda as regras do blog (o meu WRITER.md, o humanizer e a minha checklist de acabamento) e só adiciona o que muda quando o texto sai de um post datado e vai pra um livro que um leigo segura na mão;
• um arquivo de continuidade, dizendo qual capítulo explica cada conceito e como cada personagem se chama, pra ninguém explicar “janela de contexto” cinco vezes;
• a estrutura inteira, pra cada agente saber o que os outros capítulos cobrem.

Além das regras de voz que já existiam (capítulo abre numa cena com data, lugar e algo em jogo, nunca numa definição; fecha num gancho pro próximo, nunca em “neste capítulo vimos”), algumas das regras que saíram do piloto, pra dar o gosto:

• quando o resumo do capítulo e o post discordam num detalhe, vale o post;
• o capítulo que é dono de um conceito explica direito; se o termo aparece antes na ordem de leitura, ganha meia frase de glosa e um ponteiro, nunca uma segunda explicação;
• fato verificado na internet ganha citação mesmo que o post original não tivesse link;
• nome de modelo e produto na grafia do fornecedor, mesmo quando o blog abreviou.

É o arquivo de instruções de projeto que eu descrevo no capítulo sobre como falar com a máquina, na escala de um livro. Quem já fez um AGENTS.md pra uma base de código reconhece tudo.

Passo 4: rascunhos em paralelo, contradições esperadas

Com o contrato pronto, os capítulos foram rascunhados em paralelo, um agente por capítulo, em duas levas: partes I e II primeiro, depois III a V, pra que os capítulos de trás pudessem construir em cima dos da frente. Cada agente recebia o brief do seu capítulo, as análises, os posts completos, a linhagem e os arquivos dos projetos de referência que precisasse.

Agentes trabalhando ao mesmo tempo se contradizem, e isso aconteceu. Um capítulo dizia que o FrankMD teve uns 130 commits em três dias; outro, que teve 212 em 19 dias. Os dois números vinham dos posts e estavam certos, só que eram janelas diferentes. Um registro de integração juntou esses conflitos, e a regra virou explicitar a janela em cada capítulo.

Depois dos rascunhos vem a passada de integração, com outro conjunto de agentes, cada um dono de um grupo de capítulos e proibido de tocar nos outros. O trabalho deles: aplicar o registro de conflitos, cortar conceito explicado duas vezes, conferir que cada callback bate com o que o outro capítulo de fato diz, garantir que o último parágrafo de um capítulo leva pro primeiro do seguinte, e refazer a conferência de fatos assumindo que o rascunho está errado.

Pra ler as emendas, o build gera um arquivo de “costuras”: o parágrafo final de cada unidade ao lado do parágrafo inicial da próxima. É a leitura mais rápida que existe pra achar onde o livro deixa de parecer um livro só.

Passo 5: uma marca invisível por parágrafo

Esta é a parte que eu acho mais útil do projeto inteiro. Cada parágrafo do livro, no arquivo de origem, carrega um comentário dizendo de onde veio:

<!-- src: 2026/09/28/llms-sao-boas-em-reproduzir-o-que-existe-e-coisas-novas -->
Todo LLM foi treinado só no que é público...

<!-- src: original -->
Texto novo, escrito pro livro.

<!-- src: ref:ai-jail/README.md -->
Fato conferido no projeto de referência.

A marca some na hora de montar o livro, por um filtro Lua do Pandoc, então o leitor nunca vê. Ela serve pra manutenção. Eu edito post depois de publicado o tempo todo, e o livro precisa acompanhar.

O comando rake drift refaz o inventário, compara os hashes, e lista os capítulos que dependem de um post que mudou, com o diff do post desde o commit em que o livro o leu pela última vez. A marca leva direto aos parágrafos que saíram daquele post, e só eles precisam de revisão. Resolvido, um script grava o novo hash e o commit.

Exemplo real, de hoje. Removi do post sobre engenharia reversa um parágrafo sobre um vídeo do Linus Tech Tips. O drift apontou o capítulo 19 e um apêndice; o diff mostrou que aquele trecho nunca tinha sido usado no livro; dois comandos depois, os dois estavam carimbados com o hash novo. Sem a marca, eu teria que reler dois capítulos pra descobrir que não precisava mudar nada.

A bibliografia faz o mesmo papel pras fontes externas: cada referência anota qual post a citou. E as imagens têm cada uma a sua ficha de origem.

Passo 6: o que a conferência pegou

Cada número, data e nome foi conferido contra três oráculos: os posts, os projetos de referência e fontes primárias na internet, com o mesmo prompt de checagem adversarial que eu uso nos artigos do blog. A lista completa está no posfácio do livro, e boa parte das correções é do meu próprio blog:

• no review de março do mini-PC com Strix Halo, eu tinha separado 96 GB de memória pra GPU; em abril baixei pra 64, e posts posteriores ainda diziam 96. O livro usa 64 pra tudo depois de abril;
• um defeito na contagem de uma das ferramentas do benchmark subestimou de 40 a 90 vezes o custo das execuções feitas nela antes de agosto. O livro não cita nenhum desses custos;
• no texto de junho sobre o Claude Fable 5, escrevi que ele custava dez vezes mais que o Opus 4.8 por execução. Refazendo as contas em julho, com os tokens lidos do cache incluídos, o Fable custava quase o dobro. O post ainda diz dez vezes; o livro conta o número errado e a correção;
• num texto de março, escrevi que a Anthropic tinha comprado o Bun no fim de 2024. O anúncio é de dezembro de 2025;
• um resumo de capítulo, escrito por agente, dizia que a trava de assinatura do Claude Code caiu em menos de um dia depois do vazamento. O anúncio saiu umas 30 horas depois, e o livro diz “no dia seguinte”.

Os rascunhos saíram rápido. A confiança no texto veio da conferência. E a fonte vence o resumo, inclusive quando o resumo vem da máquina.

Passo 7: capítulo com erro não passa

Por cima de tudo roda um verificador automático, o equivalente da integração contínua. São scripts em Ruby, só biblioteca padrão, encadeados num Rakefile, mais o que eles chamam por fora: o verificador de gráfico é Python porque vive dentro do matplotlib, a auditoria de página usa o poppler, e o epubcheck precisa de Java:

• um linter de capítulo reprova travessão, frase proibida pelo guia de voz, URL solta no meio da prosa, chave de citação desconhecida, parágrafo sem marca de origem, e avisa de parágrafo longo demais;
• um doctor confere que toda referência cruzada, citação, termo de glossário e figura existe, que a proveniência bate com o inventário, que nenhum post anterior ao corte vazou, que as traduções estão em dia, e faz uma heurística de callback: uma frase que aponta pra outro capítulo usando nomes que aquele capítulo já não contém;
• uma auditoria de página abre o PDF pronto e procura bloco partido entre páginas, título órfão no pé da página, página quase vazia, imagem grande demais, linha estourando a margem;
• um verificador de gráfico procura rótulo que vazou da caixa;
• o epubcheck valida o EPUB 3;
• um relatório de estilo pra copidesque: trecho repetido entre capítulos (consequência inevitável de posts que repetem a mesma tese por ângulos diferentes), frase recorrente, palavra usada demais, variante de termo, comparativo mal formado em português.

E os scripts têm teste. Uma suíte de quase 170 testes monta um livro de mentira num diretório temporário, com cinco posts falsos num repositório git falso, e confere que cada ferramenta pega o problema que deveria pegar. Quando um bug é corrigido, entra o teste que teria pegado ele, com um comentário dizendo qual regressão protege. Roda no CI antes de cada build.

A pipeline de montagem

A toolchain é Quarto, que embute Pandoc e Typst, fixada em versão dentro do repositório. Sem LaTeX. Um único rake build produz, da mesma árvore de arquivos Markdown:

Português e inglês são perfis do Quarto, gerados do mesmo arquivo de estrutura. Citações saem de um YAML em formato CSL compartilhado pelas duas edições, com um estilo ABNT ajustado pra português. O glossário é um filtro Lua: cada termo vem marcado no fonte onde aparece, e o filtro liga a marca à entrada, expande a sigla na primeira vez e gera a página.

O Typst resolveu uma coisa que eu achava que ia me custar semanas: PDF com cara de livro tipografado, hifenização em português, ligaduras, sem a dor de TeX. A auditoria de página depois do build pega o que o motor deixou passar, e um rake fit recompila apertando capítulos que terminam numa página quase vazia.

As figuras

Toda figura é código ou tem ficha. Gráficos e diagramas de caixas e setas são scripts de matplotlib, 43 deles, cada um com a indicação do capítulo de onde vieram os dados, e com os rótulos em português e em inglês dentro do próprio script: o mesmo gráfico sai nas duas línguas. O caminho pra diagramas em D2 existe no repositório, e nenhuma figura do livro precisou dele.

As ilustrações conceituais foram geradas por IA, com o modelo, o pedido e a data de cada uma gravados na ficha de crédito, e o livro declara isso. A regra que eu me impus: nenhuma imagem de pessoa real gerada por IA. Pessoas reais só aparecem em fotos com licença livre, com o crédito na legenda.

A capa é o robô retrofuturista de rosto cansado, ajoelhado numa Feira Mundial dos anos 1950, estudando a própria mão enquanto a multidão assiste. O pedido ao modelo descrevia a cena pra segurar três medos de uma vez: o fim da humanidade, perder o emprego, a máquina ficando consciente. A ficha da capa guarda o prompt inteiro. O rosto é o do Marvin, o personagem da minha newsletter, e um adesivo com a minha cara fica ao lado do nome.

As manhas de transformar post em livro

Transformar blog em livro é uma lista de conversões mecânicas, e cada uma tem pegadinha:

• Link vira citação. Cada link externo virou uma entrada de bibliografia, e a frase precisa ficar de pé sem o link. Link pra outro post meu virou referência cruzada pro capítulo que agora cobre aquilo, ou sumiu. Nunca uma URL na prosa.
• “Hoje”, “ontem”, “semana passada”, “atualização:” viraram data absoluta. O livro vai ser lido em 2028 também.
• Versão de modelo, preço, nota de benchmark ficaram como fotografia datada (“em setembro de 2026, o melhor…”), e quando um post posterior substituiu o número, o livro conta a mudança em vez de imprimir o número velho.
• Dump de código, passo de instalação, print de terminal foram cortados. No máximo um trecho de 3 a 8 linhas quando o código é o ponto; o passo a passo foi pra apêndice.
• Título de post, que é feito pra busca (“Vibe Code: fiz X em dois dias”), virou título literário curto, com o assunto no subtítulo.
• Repetição entre posts, a mesma tese por muitos ângulos, é dita uma vez, no lugar certo, e os capítulos seguintes constroem em cima.
• Chamada pra ação, “assine”, “comente”, cortadas.
• A ponta afiada mira na propaganda, nunca no leitor. O post “Você é um idiota se acredita…” virou um capítulo sobre como os anúncios funcionam. O leitor que acreditou no anúncio é a pessoa que o livro quer ajudar.
• Todo termo técnico é explicado uma vez, na primeira aparição no livro, e vai pro glossário.

E a mais importante de todas: o livro lê como história em primeira pessoa, com o ano como espinha dorsal. A informação chega quando a narrativa precisa dela, em vez de seguir ordem de enciclopédia. Isso é o oposto de como um blog é escrito, e foi a regra que mais trabalho deu pros agentes seguirem.

A edição em inglês

A edição em inglês, Competent Enough, só começou depois que eu aprovei a em português. Cada unidade traduzida grava o hash do arquivo em português de onde saiu, e onde o livro segue um post meu que já tinha versão em inglês no blog, a tradução usa a minha própria redação em inglês em vez de traduzir de novo.

O drift também funciona por língua: se eu mudo um parágrafo em português, ele aponta a unidade em inglês que ficou velha, e só os parágrafos marcados são retraduzidos. Os gráficos com texto são gerados de novo em inglês a partir dos mesmos scripts, e a capa em inglês é composta por script em cima da mesma arte.

Lançar é empurrar uma tag

Lançamento é uma entrada no CHANGELOG e um git push de uma tag vX.Y.Z. Um workflow do GitHub Actions roda os testes, monta as duas edições em todos os formatos, valida o EPUB, roda a auditoria e publica a release com os arquivos. Ele apaga todas as releases menos as duas mais novas, e mantém as tags. É assim que a página oficial sempre aponta pra versão atual.

O repositório é público, e isso trouxe uma pegadinha própria: as anotações do meu servidor de casa são fonte de alguns fatos, e são privadas. Os marcadores de origem citam esses arquivos por apelido, o mapa de apelidos fica fora do git, e um hook de pré-push bloqueia qualquer arquivo ou mensagem de commit que contenha nome de repositório privado, host ou IP.

O copidesque: o que a máquina de checagem deixa passar

Lint, doctor, auditoria de página e testes pegam problema estrutural. Eles deixam passar o que um livro escrito por muitos agentes, cada um vendo poucos capítulos, sempre sofre: a mesma frase ou anedota reaproveitada em três capítulos, tom que deriva, terminologia inconsistente, concordância escorregando. Pra isso existe um procedimento de copidesque, que roda uma vez por versão, em três passos do mais barato pro mais caro.

Passo 1, mecânico e quase de graça: o relatório de estilo que eu citei acima. Sequências de sete palavras ou mais que aparecem em mais de uma unidade, ou seja, frase reaproveitada e anedota recontada; frases feitas de quatro a seis palavras usadas em muitos capítulos, que são bonitas como callback e viram tique quando se repetem; palavra usada muito mais num capítulo do que no resto; variante de termo (“e-mail” e “email”, “Open AI” e “OpenAI”); e uma heurística de concordância em português. O relatório é uma lista de trabalho, e nada muda sozinho.

Passo 2, a leitura corrida: um agente só de leitura por parte do livro, cada um lendo as suas unidades em ordem, do começo ao fim, com uma folha de estilo compartilhada (nomes, grafias, termos, frases recorrentes vindas do passo 1). Cada um produz um relatório ranqueado, sem editar nada: erro de digitação e gramática primeiro, depois inconsistência com a folha de estilo, repetição que o leitor notaria, trecho em que um leigo tropeçaria, e ritmo só nos piores casos. Um script valida os relatórios, confere que cada trecho citado existe mesmo na unidade, numera os itens e resume.

Daí vem a triagem, feita por mim com um agente editor, e a aplicação pontual de cada item aprovado, com as mesmas regras da passada de integração. Modelo mais barato faz a revisão; trecho difícil vai pro modelo forte. Orçamento aproximado: dois a três milhões de tokens por língua.

A regra mais importante desse passo é “fato se confere, não se pergunta”. Qualquer item que dependa de um número, data, nome ou comportamento de ferramenta é resolvido pelo editor contra a fonte da verdade antes de chegar em mim: primeiro o post apontado pela marca de origem do parágrafo, recalculando totais; depois o código ou os dados por trás da afirmação, nos meus repositórios; depois registro público.

Quando duas fontes discordam, a tarefa é descobrir por quê. “653 commits em 8 projetos” contra “692 em 4” eram dois recortes do mesmo trabalho, um deles sem o repositório privado da newsletter, e o texto passou a dizer o escopo em vez de escolher um número. Quando o post do blog está errado, o livro imprime o certo e o erro vai pra uma lista de errata do blog, pra eu corrigir na fonte.

Só chega em mim o que fonte nenhuma resolve: fato não publicado, intenção (“isso é ironia?”), preferência de corte ou de título, e contradição entre duas afirmações minhas sem registro pra desempatar. Cada pergunta vem com o que foi conferido e o que foi encontrado.

Passo 3, a minha leitura. A última e a mais valiosa. As notas entram no mesmo ciclo de aplicar, conferir e propagar pra edição em inglês.

A primeira rodada desse copidesque é o que separa o preview 2 do preview 3. Entre o que ela pegou: contagem de commits agora diz o escopo, um “mais de mil” que na soma era 984, o exemplo de votação do Frank Investigator que não batia com o código (figura redesenhada), as citações do David Sacks e do Pirate Wires no capítulo 14 conferidas contra os originais e corrigidas, a foto do Sam Altman trocada por uma de 2025. E na edição em inglês, uma leitura própria depois da ressincronização: decalque de português reescrito, termos do glossário usados do mesmo jeito, pontuação americana de citação do começo ao fim.

Leitores de mentira, feedback de verdade

Copidesque confere o texto. Ele deixa passar a pergunta que importa num livro pra leigo: a pessoa pra quem eu escrevi consegue ler isso até o fim, entende, e sai convencida? Pra responder, a passada seguinte foi uma revisão por leitores simulados.

O prefácio do livro tem uma seção “Pra quem eu escrevi”. Dela saíram cinco personas, cada uma com nome, idade, profissão e o medo que a trouxe ao livro:

• Marina, 38, contadora em Belo Horizonte, leu que o emprego dela “acaba em dois anos”, lê no celular à noite e quer saber o que fazer na segunda-feira;
• Roberto, 52, dono de loja de ferragens, o filho de 15 anos viu um vídeo sobre superinteligência e perguntou se era verdade; desconfia de hype, de “especialista” e de autor que se exibe;
• Carla, 44, gerente de operações numa empresa de logística, a diretoria contratou consultoria vendendo “transformação por IA”; quer uma decisão que ela possa tomar;
• Lucas, 24, desenvolvedor júnior há um ano, com medo de ter escolhido a carreira errada;
• Helena, 61, professora de história aposentada, sem medo nenhum, veio pelas histórias e perde a paciência com lista e manual.

Um agente por persona, só de leitura, modelo mais barato, lê o livro inteiro em ordem como aquela pessoa leria. A instrução é explícita: você é leitor, editor fica de fora; erro de vírgula já foi tratado, reporte só o que muda a experiência de leitura. Cada um devolve uma nota de 1 a 5 por capítulo, um comentário na voz da persona (“finalmente entendi por que o chatbot concorda comigo”, “me perdeu nas tabelas de benchmark”), no máximo 35 anotações classificadas em confuso, chato, reescrever ou lógica, e candidatos a corte. Custa uns 350 mil tokens por persona por leitura completa.

Um editor consolida: a matriz de notas por capítulo e persona e o padrão por trás dela, o que os leitores adoraram (pra proteger em qualquer edição), os itens de lógica, conferidos contra o texto e os posts antes de entrar na lista e corrigidos independentemente de voto, e os itens de clareza ranqueados por quantas personas levantaram. Nota de gosto de uma persona só é descartada. Daí eu decido, e o padrão recorrente vira regra numerada num documento de regras editoriais, com a origem e como é fiscalizado.

A primeira leitura disse o que eu desconfiava e deu a medida: histórias e ferramentas práticas funcionam pra todo mundo; o miolo cheio de medição, os capítulos 11 a 13, perde quem não programa, com nota média entre 2,2 e 2,4. “Afiado quando conta o que aconteceu com ele, me perde quando conta o que mediu”, resumiu a Helena, por todos os cinco.

E os cinco pegaram as mesmas falhas de argumento. A conclusão do capítulo 20 ia além da evidência: dizia “os números dizem que ela não vai ficar mais inteligente” apoiada num benchmark de programação que o próprio capítulo chama de saturado. O capítulo 9 argumentava de um jeito que nunca perde: toda falha do agente era culpa do pedido. Quatro dos cinco foram mandados pro capítulo errado pelo “como ler”.

Isso virou as primeiras regras:

• toda afirmação com o escopo do que foi medido;
• nenhum argumento que não possa perder;
• opinião marcada como opinião;
• o lado contrário na forma mais forte antes de rebater;
• o livro obedece às próprias lições.

Uma rodada só é pouco, porque edição conserta o problema velho e cria o novo. Na segunda rodada, uma frase de desculpa colocada ao lado de uma contradição (“eu sei que isso parece bater de frente…”) fez os cinco leitores notarem a contradição que antes três tinham deixado passar. Virou regra: conserta o desenho, e a desculpa fica fora. Então o processo é em rodadas: ler, editar, ler de novo com as mesmas personas e leitura nova, proibidas de abrir os relatórios anteriores pra evitar ancoragem, e um script compara as rodadas.

A nota média é ruidosa (um capítulo intocado oscila 0,6 entre leituras), então o critério de parada é outro: os problemas apontados deixaram de voltar e nada novo chega a três leitores. Na terceira rodada a curva achatou e a revisão parou ali, com uma lista de pendências pra minha própria leitura. O que mudou no caminho: uns 8 mil palavras de caderno de laboratório saíram dos capítulos pra um apêndice novo, “Para quem programa: os bastidores”, cada parágrafo levando a marca de origem junto; a lista de leituras virou apêndice; a seção sobre o Genesys PI foi estacionada, guardada fora do livro enquanto a verificação está pendente; o capítulo 19 ganhou o título que o argumento dele sustenta; cada capítulo abre orientando o leitor antes do primeiro jargão; e o epílogo ganhou uma lista do que fazer nesta semana, por tipo de leitor. Custo das três rodadas: uns 5 milhões de tokens de leitura mais uns 3 milhões de edição e ressincronização do inglês.

O narrador ganhou passado

Com o argumento no lugar, faltava substância na primeira pessoa. O narrador do livro era o Akita de 2026, e eu tenho trinta anos de história que explicam por que eu penso o que penso: o estouro da bolha pontocom visto de dentro, cinco anos integrando SAP em empresa grande, os avisos sobre a bolha de contratação que eu dei em vídeo em 2019, 2020 e 2022, o “Não terceirize suas decisões”. Tudo isso está nas transcrições dos 149 episódios do Akitando, publicadas aqui no blog entre 2018 e 2023.

O processo foi o mesmo do resto do livro, em miniatura. Agentes de extração leram 23 episódios na íntegra, com um formulário: fatos biográficos com a citação literal e o que os verificaria, fatos sobre o mundo, posições recorrentes nas minhas palavras, e ganchos, ou seja, o lugar exato do livro onde uma ou duas frases dessa história sustentam uma afirmação de 2026. Daí saiu um perfil do narrador, que eu confirmei linha a linha, e um plano com uns 30 toques, a maioria de uma a três frases.

Antes de qualquer toque, mais de 140 afirmações tiradas dos episódios passaram pela checagem. Ela corrigiu o livro e corrigiu a mim: a bolha de contratação começou por volta de 2010, com o juro perto de zero, e o meu post de fevereiro dizia 2014; a pontocom estourou entre 2000 e 2002; as demissões de 2022 foram umas 165 mil. E achou erro em episódio antigo que o livro nem usa, que foi pra uma lista de errata do blog.

Os toques entraram onde a experiência vira evidência: a semana de 2001 em que a minha pontocom fechou e um mentor me chamou pra uma consultoria SAP; os anos de SAP por trás da afirmação de que o modelo é cego pras regras privadas de uma empresa; os avisos datados da bolha ao lado do erro admitido, porque em 2022 eu esperava uma segunda perna de queda em 2023 que a onda de IA cancelou. Dois apêndices novos saíram daí: “Três bolhas”, com os números verificados da pontocom, da bolha de juro zero e da onda de IA, e “Como estudar com a IA do lado”, a partir do episódio mais assistido do canal.

Esses episódios são fonte de fundo, e o drift passou a vigiá-los como vigia os posts de 2026. Depois veio uma checagem reduzida com as mesmas cinco personas, só nos capítulos tocados, com três perguntas a mais: a história do narrador deixa o argumento mais convincente, e onde? Alguma passagem parece exibição ou “eu avisei”? Alguma coisa sobre o narrador se contradiz?

Os cinco disseram sim pra credibilidade, com uma condição: a história convence quando é evidência que o leitor consegue checar, o aviso com data ao lado do erro admitido, e convence menos quando vira currículo, o que bate de frente com o próprio livro, que diz “currículo não é argumento”. Virou a regra 21: a história do narrador entra como evidência, e credencial fica de fora.

Três ou quatro leitores marcaram as mesmas linhas como exibição, e elas saíram: “Os avisos têm data”, “mais de trinta repositórios públicos”, “o mais visto do meu canal”. As linhas de autodepreciação e os erros admitidos, todos contaram a favor. E a checagem achou contradições que eu mesmo não tinha visto: o prefácio dizia “fim dos anos 90” e o capítulo 18 dizia 1996; um capítulo falava em “oito meses” e outro em “um ano de uso diário”, e foram consertadas uma a uma.

Acessibilidade também faz parte do build

Um EPUB abrir no Kindle não quer dizer que ele seja acessível. Este livro tem dezenas de diagramas, gráficos e tabelas. Sem trabalho adicional, boa parte do argumento simplesmente desaparece pra quem usa leitor de tela.

Por isso a pipeline agora trata acessibilidade como contrato de publicação. Cada uma das 55 figuras, nas duas línguas, ganhou um texto alternativo curto e uma descrição completa do que a imagem comunica. No HTML e no EPUB, a descrição detalhada aparece junto da figura; no PDF, entra como substituto semântico sem alterar a diagramação. Tabelas ganharam legendas, e o EPUB agora identifica no índice semântico onde começam o texto principal, o glossário, as referências e os créditos das imagens. O contrato de autoria está documentado no repositório.

Isso também não ficou dependendo da minha memória. rake check barra figura sem as duas descrições ou com alternativa longa demais. Cada build valida os dois EPUBs com EPUBCheck, DAISY Ace e verificadores próprios do projeto. A versão pra Kindle ainda passa por uma limpeza do CSS e dos ícones embutidos que costumam dar problema nos leitores da Amazon, mas o script se recusa a remover qualquer regra da qual o conteúdo tenha passado a depender.

Ferramenta automática nenhuma certifica WCAG ou garante o comportamento de todo leitor do mercado. A revisão manual continua obrigatória. A diferença é que a acessibilidade agora faz parte do build e cada mudança precisa preservar esse contrato.

O que continua sendo meu

O repositório registra o primeiro commit e o rascunho de todos os capítulos no mesmo dia, 13 de outubro. São os primeiros dez por cento, os que impressionam e quase não dizem nada sobre o resto. Os outros noventa por cento são leitura, corte e correção, e essa parte é minha. Nenhum capítulo entra sem eu ler e aprovar, e o que eu mando refazer volta pro mesmo processo.

Qualquer um dos bons modelos de outubro de 2026 teria escrito rascunhos parecidos, porque modelo virou commodity. O que fez o processo funcionar foi o que está em volta dele: o inventário, o contrato escrito, o verificador automático, as fontes como oráculo, o rastro por parágrafo. É a mesma engenharia de software velha que eu defendo em cada capítulo, aplicada a texto.

Os agentes foram competentes o suficiente pra escrever o rascunho. Decidir o que ele dizia continuou sendo trabalho meu.

E, mais uma vez: fazer um livro com IA não é um prompt de “escreva um livro pra mim” e pronto. Eu tive que inventar o processo inteiro e pilotar o agente pra criar cada peça dele: os scripts, os testes, a consolidação dos posts, a estratégia narrativa, os objetivos, o que fica e o que sai, o copidesque, a checagem de fatos, o lançamento automatizado. Você precisa saber exatamente o que quer, e aí a IA ajuda muito. Quem não sabe o que um processo de publicação de livro envolve não vai fazer um livro de verdade, e mostrar isso era um dos objetivos que eu tinha ao criar este exemplo.

Baixe, leia, e me diga onde errei

As duas edições, em três formatos cada, direto do GitHub, sem cadastro. A versão atual é a 1.0.0 final, de 17 de outubro, com tudo que este texto descreve:

A versão mais recente, sempre, fica na página do livro e nas releases do GitHub.

É preview. Vai ter erro, e o processo acima existe pra que ele seja corrigido no lugar certo. Achou um, abra uma issue.

Essa foi a semana no X, e se você só lê manchete, é uma conclusão razoável. Este texto é pra quem quer saber o que cada uma dessas coisas faz de verdade.

Explodiu no dia 9, quando a conta abaixo resumiu o que um desenvolvedor de Atlanta, Brandon Thomas, vinha publicando desde o fim de setembro: sete clones de código aberto dos produtos principais da Adobe, escritos em Rust com ajuda do Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. Tudo de graça, tudo feito em “sala limpa”, sem uma linha de código da Adobe. A conta que viralizou foi esta:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

Na mesma semana, o REA, “Reverse Engineer Anything”, passou de 100 mil estrelas no GitHub, ganhando dezenas de milhares por dia. A promessa da página: “viu uma feature num app que você quer no seu produto? Peça pro seu agente investigar com o REA e construir uma versão pro seu projeto”.

E quem acompanha retrogaming sabe que 2026 é o ano que não para de dar. Tem uma planilha comunitária tentando listar os ports não oficiais pra PC, com uns 100 jogos de Ship of Harkinian a Skate 3, e ela está sempre atrasada. O canal Video Game Esoterica publica port novo quase todo dia: Time Crisis decompilado do arcade, Daytona USA, Bloodborne.

A versão de Xbox One do Forza Horizon 2, presa lá desde 2014, roda em Windows. O AnyPS5 promete converter executável de PS5 em binário nativo de PC, e emuladores de PS5 como o KytyPS5 e o SharpEmu já rodam Astro Bot com gameplay de verdade. Boa parte disso com IA no meio, alguns abertamente vibe-coded.

Daí o consenso: programar, em geral, acabou. Todo binário é reversível e reutilizável, basta apontar o agente. Minha posição é que ficou muito mais fácil mesmo, que ainda está longe da bala de prata que as pessoas imaginam, e que o motor por trás disso, o LLM, parou de crescer exponencialmente. O resto do texto são os motivos.

TL;DR: engenharia reversa é uma disciplina de 40 anos com ferramenta madura, e a IA acelerou o trabalho braçal dela, com destaque pro retrô, onde o binário está disponível, é minúsculo e o alvo não se move. Os clones da Adobe são alpha com centenas de bugs abertos e print bonito. O REA é uma caixa de ferramentas que exige o binário na mão, Ghidra ou IDA instalados, e muito token. O que vale dinheiro hoje nem binário tem: é SaaS, nuvem, parceria com fabricante e décadas de ciência de cor. Reescrever o Bun, com o autor do projeto e 64 agentes, custou US$ 165 mil. Pule pra linha do tempo, pro REA, pros clones da Adobe, pro caso Bun, por que o retrô anda rápido ou pras respostas no final.

Antes de tudo: eu não gosto da Adobe

Pra ficar claro de onde eu falo. Eu detesto as práticas comerciais da Adobe tanto quanto qualquer um. Fui cliente pagante por anos, usei Photoshop e Premiere extensivamente, mais Lightroom e After Effects, e saí pelos mesmos motivos que todo mundo sai: assinatura compulsória, cancelamento com multa, preço subindo sem contrapartida.

E é exatamente por ter usado a fundo que eu sei o tamanho do que está dentro daquelas caixas. Quem acha que Photoshop é camada, crop e texto nunca precisou de prova de cor pra gráfica, nunca abriu um RAW de câmera cujo perfil de cor a Adobe mantém há vinte anos, nunca fez a conformação de material de cinema, o trabalho de reunir o material bruto da câmera pra finalização. Vou chegar lá, depois do básico.

Engenharia reversa não nasceu semana passada

Todo emulador que você já usou existe porque alguém abriu hardware, desmontou binário, farejou protocolo e, em alguns casos, quebrou criptografia. A disciplina tem jurisprudência, ferramenta comercial e uma história de décadas. Uma linha do tempo resumida, com os marcos que mais importam:

• 1982 a 1984: a Compaq reescreve a BIOS do IBM PC por engenharia reversa, e em 1984 a Phoenix vende uma BIOS licenciável feita em sala limpa, com um time que só lia a especificação. Nasce a indústria de PC compatível. Fonte.
• 1992: Andrew Tridgell cria o Samba farejando pacotes SMB. No mesmo ano, Sega v. Accolade e Atari v. Nintendo firmam nos EUA que desmontar código pra chegar em elementos funcionais é fair use, uso justo (a Atari perdeu o caso dela por outro motivo: mentiu pro Copyright Office pra conseguir o fonte).
• 1993: começa o Wine, que vira a base do Proton e de todo jogo de Windows que roda no Steam Deck hoje.
• 1999: UltraHLE roda jogos comerciais de N64 em velocidade real; o bleem! emula PS1, a Sony processa e perde as liminares, e o bleem! ainda assim fecha em 2001; o DeCSS quebra a proteção do DVD.
• 2000: Sony v. Connectix decide que copiar a BIOS do PS1 pra construir um emulador é uso justo.
• 2002 e 2003: nascem PCSX2 e Dolphin, os dois emuladores que vinte anos depois ainda são referência.
• 2007: o iPhone é aberto onze dias depois do lançamento. A Comissão Europeia obriga a Microsoft a documentar seus protocolos de rede, e a equipe do Samba recebe a documentação por 10 mil euros.
• 2010: o grupo fail0verflow mostra no 27C3 que a Sony assinou o firmware do PS3 com um nonce fixo, expondo a chave privada (o nonce é o número que deveria ser aleatório em cada assinatura). Dias depois, já em 2011, o geohot publica a chave, a Sony processa e faz acordo em março.
• 2011 e 2013: nascem RPCS3 (PS3) e Xenia (Xbox 360), os dois emuladores mais difíceis já feitos, por motivos que vou explicar.
• 2019: a NSA libera o Ghidra como código aberto. A decompilação do Super Mario 64 vaza e vira pública, e no ano seguinte aparece o port pra PC.
• 2021 e 2022: Ocarina of Time 100% decompilado depois de quase dois anos de trabalho; o Ship of Harkinian vira o port de referência.
• 2024: Mr-Wiseguy lança o Zelda 64: Recompiled, a primeira vitrine da recompilação estática de N64.
• 2025: Sonic Unleashed Recompiled traz o mesmo truque pro Xbox 360, convertendo PowerPC pra C++ e shaders pra HLSL.

Repare que a fase atual, decomp e recomp em escala, começa em 2019, bem antes de qualquer agente de código. A IA entrou numa linha de montagem que já existia.

As ferramentas

O ferramental também é maduro, e boa parte é gratuita:

• IDA Pro (Hex-Rays), o disassembler e decompilador comercial de referência, de mil a quase nove mil euros por ano, com uma versão gratuita limitada a x86.
• Ghidra, a resposta aberta da NSA, com decompilador e scripting, Apache 2.0.
• Binary Ninja, com uma edição gratuita e licenças de 200 a 3.500 dólares.
• radare2 e o Cutter, interface do rizin, que é um fork do radare2: a linha de comando e a interface abertas.
• x64dbg e WinDbg no Windows, GDB no resto.
• Frida, pra injetar código em processo vivo e observar o que ele faz.
• JADX pra Android e ILSpy pra .NET.

Guarde essa lista. O REA, que a gente vai ver daqui a pouco, é um embrulho em volta dela.

Como se desmonta um binário, na prática

Em princípio, todo binário é reversível. O processador precisa conseguir executar aquilo, então as instruções estão lá. O caminho é sempre o mesmo:

1. Desmontar: o binário vira assembly, uma instrução de máquina por linha. Isso é mecânico.
2. Decompilar: o assembly vira algo parecido com C. Ghidra e IDA fazem isso razoavelmente bem, com muito ruído.
3. Recuperar o que o compilador jogou fora: nome de variável, nome de função, tipos, estruturas, comentários. Nada disso sobrevive à compilação. Esse é o trabalho de verdade, e é humano.
4. Refatorar até virar código que uma pessoa consegue ler, manter e portar.

Os projetos de decomp de N64 fazem o passo 4 até o fim: o código em C deles, recompilado, gera byte a byte a ROM original. É assim que o Super Mario 64 virou um projeto com 135 mil linhas de C de código de jogo (uns 100 mil de código efetivo, mais meio milhão de linhas de dados de fase e modelo gerados), e o Ocarina of Time passou de 430 mil linhas. A recompilação estática pula parte disso: traduz as instruções do processador original pra C genérico, sem tentar entender, e troca só as partes que falam com o hardware. É mais rápido e o resultado é menos legível.

“Mas a IA não pode ler o binário direto?”

Alguém sempre pergunta: se é IA, pra que passar por C? Deixa o modelo ler o binário e construir em cima. A resposta curta é que LLM só sabe o que estava no corpus de treino, e corpus de binário pareado com código fonte é escasso, porque nenhum humano escreve assembly de produção há décadas.

A resposta longa é que existe literatura, e ela é instrutiva justamente por ser modesta. A linhagem vai de redes neurais de 2018 a modelos como o SLaDe (200 milhões de parâmetros, um por arquitetura e nível de otimização), o LLM4Decompile (até 33 bilhões) e o Nova. A Meta publicou um LLM Compiler que traduz assembly pra IR do LLVM. Os melhores resultados, em funções isoladas de benchmark, giram em torno de 60 a 65% de código que roda de novo e dá o mesmo resultado, caindo forte quando o compilador otimizou com -O3.

Dois estudos recentes mostram o estado real. O DecompileBench, com 23 mil funções reais, achou que decompiladores baseados em LLM produzem código mais legível e com metade da correção funcional dos decompiladores comerciais. E um trabalho de setembro de 2026 mediu que o refinamento por LLM da saída do Ghidra sobe a taxa de compilação de 75% pra 90% e derruba a fidelidade de comportamento de 74% pra 62%, com até uns 10% das funções com vulnerabilidade conhecida deixando de reproduzir a falha, ou seja, o bug sumiu sem ninguém pedir.

Resumindo o que existe: modelos pequenos, função por função, quase só x86-64 Linux, e os melhores são camadas de refinamento em cima do Ghidra, o que mantém o decompilador clássico no loop. Nenhum emulador, nenhum jogo, nenhum programa inteiro foi recompilado neuralmente. Enquanto alguém não inventa isso, você trabalha com a realidade, e a realidade inclui a camada intermediária de linguagem de programação e compilador.

Os assistentes de IA que existem pra isso em produção confirmam o desenho: o aiDAPal, plugin de IDA da Atredis, o Sidekick do Binary Ninja, os servidores MCP pro Ghidra. Todos são um LLM dando nome a variável e explicando função em cima do que o decompilador tradicional produziu.

O que o REA faz de verdade

Eu clonei o REA e li o código. Ele é um servidor MCP e uma CLI em TypeScript que embrulha as ferramentas da lista acima e as expõe pro seu agente de código: Ghidra, Hopper, IDA, JADX, Frida, Wakaru pra JavaScript ofuscado, Playwright pra capturar o que um site faz. O agente pede, o REA roda a ferramenta e devolve pseudocódigo, grafo de chamadas, strings e traces de IPC, cada resultado com um registro de evidência e uma lista de limitações.

Esse fluxo eu já tinha feito na mão, meses antes de o REA viralizar. Em julho eu coloquei o Fable 5 pra analisar o código do TikTok, do Clash of Kings e do gov.br: baixei os APKs, descompactei (APK é um zip), rodei o JADX nos .dex e deixei o modelo ler o Java que saiu do outro lado. Deu pra ver os endpoints, as permissões, os SDKs embutidos e como cada app monta o fingerprint do aparelho, aquele identificador persistente que sobrevive a limpar dados e reinstalar. O TikTok saiu como coleta de grau industrial, blindada contra auditoria; o gov.br, como exemplo de como fazer direito.

As três lições daquele post valem pro REA inteiro. Android é fácil demais de descompilar, e mesmo assim o resultado serve só pra análise estática, porque recompilar o app fica fora de alcance: os nomes vêm embaralhados pela ofuscação, faltam recursos e chaves de assinatura. A parte mais sensível mora em código nativo, .so em C e C++, que descompila em nada legível, e no TikTok é justamente aí que fica o miolo. E o que saiu daquele trabalho foi um relatório sobre o que o app faz, com ressalvas, e nenhum clone do TikTok. O REA embala esse mesmo fluxo num servidor MCP; as paredes continuam no mesmo lugar.

Quem fornece o julgamento é o LLM que você já paga. O REA fornece o encanamento determinístico e a proveniência. A frase “automatiza as heurísticas de engenharia reversa”, que circula por aí, não aparece em lugar nenhum do repositório; a descrição que o próprio projeto usa é engenharia reversa dirigida por agente, com evidência rastreável.

O que ele exige: o artefato na sua máquina (binário nativo, app Electron, assembly .NET, APK, firmware, captura de rede), Node 22.19 ou superior, e as ferramentas pesadas instaladas por sua conta. Ghidra é grátis; IDA, Hopper e JEB o README manda você comprar. Não tem chave de API do REA porque ele roda local, e o custo de token cai inteiro na sua assinatura de agente.

E esse custo é o detalhe que ninguém cita. O catálogo de ferramentas MCP do REA tem 2,3 MB de JSON, que entra no contexto do agente. O próprio projeto publica um experimento em que analisar o SQLite compilado em WASM, no caminho padrão, levou 42 chamadas de ferramenta, cinco minutos e 300 mil tokens de entrada. Um inventário completo de um app Electron como o Obsidian devolve quase 1 MB de JSON.

Tem issue aberta reclamando que inspecionar um app de Mac comum devolve de 80 a 230 mil tokens de uma vez.

O projeto é sério e vai longe: seis meses, 2.600 commits, mil arquivos de teste, versão 6.4 lançada em 11 de outubro. Também é instável: 190 issues abertas, várias mudanças incompatíveis a cada versão menor, subsistemas marcados como experimentais.

Os limites estão escritos no próprio repositório. O CONTRIBUTING exclui quebra de DRM, anticheat, licença e proteção comercial. O DISCLAIMER avisa que decompilação, reconstrução e análise assistida por IA “podem ser incompletas ou incorretas”. E até as instruções internas pra gerar as figuras do site dizem, com todas as letras: “nunca implique que o REA clona um programa automaticamente” e “nunca diga reconstrução completa, clone exato ou recuperação automática de código fonte”.

O REA é uma boa caixa de ferramentas pra quem já sabe fazer engenharia reversa e quer um agente segurando o Ghidra. Ele não é o botão “copia esse app pra mim”. Quem escreveu o projeto é o primeiro a dizer isso.

PhotoCraft: print bonito, alpha por dentro

O repositório do PhotoCraft foi criado em 30 de setembro. Em duas semanas, 54 mil estrelas, 8 versões lançadas e, no momento em que escrevo, mais de 800 issues abertas. O selo no README diz “early alpha”, e o próprio Brandon Thomas, citado pela Gizmodo, disse que não está nem perto de pronto. A imprensa que testou chegou na mesma conclusão: a Gizmodo chamou de “Photoshop cheio de bug, mas real”, e o OMG Ubuntu de “fac-símile superficial com falhas pronunciadas”.

As issues contam a história técnica:

• Qualquer imagem acima de 8.192 pixels sai do compositor de GPU e cai pra CPU, com pico de 6 GB de memória, porque o limite de textura do egui-wgpu é esse (issue 49, já fechada, e as que vieram depois, 1015 e 4017).
• Uma foto de 12 megapixels precisa de quase 800 MB só pra abrir, ajustar e exportar pela linha de comando (issue 1637).
• O gerenciamento de cor é rudimentar: espaço de trabalho só global, em vez de por documento, e sem transformação de visualização (issue 321). Dezoito issues mencionam CMYK, quinze mencionam perfil ICC.
• Quase cem issues abertas mencionam PSD. Camadas de matiz e saturação compõem diferente do Photoshop, e salvar por cima sobrescreve a imagem mesclada correta do arquivo original (issue 4089).
• Cinquenta issues abertas mencionam “crash”.

A interface lembra o Photoshop, então o print é compartilhável, e quem vê o print assume que é cópia carbono. Isso é esperado numa alpha de duas semanas. Com interesse, tempo e contribuição, parte disso vai sendo resolvida. E aí os contribuidores vão descobrir uma coisa que os projetos de N64 nunca enfrentaram.

O PhotoCraft hoje é aquela réplica de Ferrari montada em cima de um Fusca: a carroceria tem a forma certa, você tira uma foto e a maioria das pessoas diz “uau, uma Ferrari”. Aí você liga e sai o motor de Fusca. Se você se empolgou com a foto, o problema foi seu.

O alvo se move

Decompilar o Zelda de 1998 é mirar num alvo parado. A Nintendo não vai lançar o Ocarina of Time 2026 com formato de arquivo novo. Copiar um produto vivo é outra conversa, e a gente já viu esse filme.

Nos anos 90 e 2000 o alvo era o Microsoft Office. O StarOffice virou OpenOffice em 2000 e LibreOffice em 2010, e todos eles passaram anos correndo atrás de um formato binário, o .doc, que mudava de versão pra versão e só ganhou especificação pública em 2008, quando o jogo já tinha acabado. A parte comprovada dessa história está nos processos: a Comissão Europeia multou a Microsoft em 497 milhões de euros em 2004 por recusar informação de interoperabilidade, e em 899 milhões em 2008 por descumprir a ordem. O .docx só virou padrão ISO em 2008, numa votação tão controversa que países protestaram formalmente.

Levou mais de dez anos. E quando o formato finalmente abriu, o Office já não importava do mesmo jeito. O valor mudou de lugar: hoje são 400 milhões de assentos pagos de Office 365, 3 bilhões de usuários de Google Workspace e uns 41 milhões de assinantes de Creative Cloud. Ninguém quer instalar aquilo no desktop, e por isso ninguém tem o binário.

Fazer engenharia reversa do Google Docs é reescrever o produto do zero olhando só pra interface, porque o código que importa nunca sai do servidor. Depois que o mundo migrou pra SaaS, a maior parte do software proprietário virou jardim murado sem binário. Sem binário, não tem o que desmontar.

Dá pra fazer versões disso, claro. O Immich substitui o Google Photos pra uma pessoa ou uma família: backup do celular, reconhecimento de rosto, busca semântica, tudo no seu servidor. O que ele não replica é a infraestrutura e o corpus de treino que fazem a busca do Google ser a busca do Google. E a Adobe fez a mesma migração, em pedaços.

Photoshop é muito mais que camada e crop

Aqui entra a parte que eu conheço por ter pagado. As features que vendem assinatura hoje nem rodam no seu computador.

O Generative Fill e o Generative Expand rodam no Firefly, na nuvem, e consomem créditos generativos. Vários Neural Filters, segundo a própria documentação, precisam de internet porque o processamento é no servidor da Adobe. A seleção de objeto por IA tem, desde 2020, uma opção de processar na nuvem pra refinar o resultado. Isso tudo é código que não existe na sua máquina pra ninguém desmontar.

Depois vem o que está no binário, mas levou décadas e parceria pra existir. O Camera Raw carrega perfis de correção de lente e perfis de cor por câmera pra centenas de modelos, construídos ao longo de vinte anos e atualizados a cada lançamento. Clone nenhum adivinha isso. Ou tem o dado, ou não tem.

E tem a ciência de cor. O exemplo que eu sempre lembro é o GIMP e o CMYK.

O GIMP nasceu em 1995. O primeiro suporte nativo a arquivo CMYK chegou em 2022, e só de importação e exportação, com o pixel sempre em RGB. O GIMP 3.0, de 2025, ainda sem modo de edição em CMYK. Está no roadmap como trabalho em andamento.

Trinta anos de projeto aberto, com gente boa e motivada, e a gráfica ainda pede o Photoshop. Isso é o tamanho do buraco da ciência de cor, e nenhum agente de código inventa ciência de cor: ele reproduz o que está no treino.

Por que demorou tanto, se era a feature mais pedida? Porque o núcleo do GIMP nasceu com RGB de 8 bits por canal embutido em cada camada, modo de mesclagem e filtro. Suportar outro modelo de cor exigiu reescrever o motor de pixel inteiro, a migração pro GEGL, que levou a maior parte de uma década e só ficou pronta no GIMP 2.10, em 2018. O CMYK só pôde começar depois disso.

E CMYK é uma família de perfis de dispositivo, com quatro tintas, perfil ICC por impressora, limite de tinta e regra de geração de preto, e editar nele significa que toda a cadeia precisa calcular num modelo subtrativo de quatro canais e ir e voltar pelos perfis sem desviar a cor. Um desenvolvedor sozinho, por melhor programador que seja, sem experiência nessa área específica, vai sofrer pra implementar isso, porque o conhecimento está na gráfica e no laboratório de cor, e quase nada dele está em corpus de treino. No GIMP, quem levou a coisa adiante foram contribuidores que entendem de impressão, e mesmo assim foram anos. Ferramenta nova nenhuma atalha esse tipo de conhecimento.

E tem a camada que nem é técnica: licença comercial. Cor de gráfica é Pantone, e Pantone é uma biblioteca proprietária. Projeto aberto nenhum pode embarcar as paletas; os desenvolvedores do Inkscape chegaram nessa conclusão em 2005, e a Linux.com explicou o risco jurídico na mesma época. A própria Adobe sentiu isso em 2022: quando a Pantone mudou o modelo de negócio, as bibliotecas saíram do Photoshop, do Illustrator e do InDesign, arquivos antigos passaram a abrir com as cores Pantone trocadas por preto, e quem precisa delas paga uma assinatura separada de plugin. Se nem a Adobe, pagando, escapou, imagine um clone que vive de boa vontade.

Vídeo é pior

No Premiere, no After Effects e no DaVinci Resolve, o problema multiplica. Câmera de cinema não entrega vídeo, entrega dado bruto numa curva logarítmica própria: LogC4 da ARRI, IPP2 da RED. Pra transformar aquilo em imagem, você precisa das transformadas do fabricante, e a RED entrega as dela num SDK que os editores integram e atualizam a cada versão. O ACES, o padrão neutro da indústria, depende de transformadas de entrada fornecidas por cada fabricante.

A Blackmagic dá o Resolve de graça e ele decodifica ARRIRAW e R3D. Faz isso porque paga o SDK e a parceria por você. Um clone feito por agente, “adivinhando” como a imagem da Alexa deve ficar, produz uma imagem que não bate com o monitor de referência, e no cinema isso significa que não serve. Esse conhecimento não está em corpus de treino nenhum: está em contrato.

O caso Bun: quanto custa reescrever software grande

Pra ter noção de ordem de grandeza, o melhor dado público que existe é o do Bun. Em maio de 2026, Jarred Sumner reescreveu o runtime inteiro de Zig pra Rust usando agentes, e em julho publicou os números:

• 535 mil linhas de Zig em 1.448 arquivos viraram um diff de um milhão de linhas de Rust, em 11 dias.
• Até 64 instâncias de Claude em paralelo, 24 horas por dia, cada linha revisada por dois agentes adversariais e um corretor.
• 5,9 bilhões de tokens de entrada não cacheados, 690 milhões de saída, 72 bilhões de leituras de cache: uns US$ 165 mil a preço de API.
• 16 mil erros de compilador corrigidos por 64 agentes antes do CI ficar verde em seis plataformas.
• A suíte de testes existente, com mais de um milhão de asserções, passou 100% antes do merge.

Lê de novo o que viabilizou isso:

• o autor original do projeto pilotando
• um código fonte completo e funcional como referência
• uma suíte de testes de um milhão de asserções servindo de oráculo
• orçamento ilimitado, porque o Bun pertence à Anthropic desde dezembro de 2025, e uma versão pré-lançamento do Claude Fable 5

O Sumner estima que três engenheiros com contexto total levariam um ano.

Agora tira cada uma dessas vantagens. O PhotoCraft não tem o fonte do Photoshop pra portar, tem que inventar. Não tem suíte de testes que diga “isso aqui bate com o Photoshop”. Não tem o autor do Photoshop.

E o Photoshop é um produto de 36 anos, cujos requisitos de disco a Adobe lista entre 10 e 100 GB, contra um runtime de JavaScript. Mesmo sem saber o tamanho do código da Adobe, estamos falando de um alvo maior, sem referência, sem oráculo e sem dono. Ordens de grandeza acima de US$ 165 mil, e ainda assim seria uma aproximação.

Por que o retrô anda tão rápido

Se é tão difícil, por que sai port de jogo antigo todo dia? Porque o retrô acumula todas as vantagens que o resto não tem.

O binário está disponível e é minúsculo. Super Mario Bros. do NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time e Majora’s Mask: 32 MB cada. Um CD inteiro de PS1: 650 MB.

Compare com Baldur’s Gate 3, 150 GB, ou com o Call of Duty mais recente, acima de 100 GB. São três ou quatro ordens de grandeza, e o escopo encolhe junto: um jogo de 1996 tem um punhado de sistemas, não um motor de física com rede, loja e anticheat.

A tecnologia é antiga e documentada. Vinte e cinco anos de comunidade já mapearam o hardware do N64, do PS1 e do SNES instrução por instrução. O agente não descobre nada; ele acelera um trabalho com mapa pronto. É o mesmo padrão que eu vi nos meus projetos de retrocomputação: onde tem referência e oráculo, a IA voa; onde não tem, ela gira em força bruta.

O alvo não se move. Ninguém vai atualizar o Zelda de 1998.

E o jurídico está resolvido há trinta anos. Sega v. Accolade e Sony v. Connectix deram o contorno. Os ports exigem que você forneça a sua ROM.

Console moderno é um PC

A segunda metade da explosão, os ports de PS4, PS5, Xbox One e Switch, tem outra explicação: esses consoles são PCs ou celulares com outro invólucro. O PS4 usa um AMD Jaguar x86-64, o PS5 um Zen 2, o Xbox Series outro Zen 2, o Switch um Tegra X1 ARM da NVIDIA. O processador do seu PC roda aquele código nativamente. Então ninguém precisa emular a CPU.

O trabalho que sobra é traduzir o sistema operacional e a GPU. O shadPS4 reimplementa as bibliotecas do sistema do PS4 e recompila os shaders: os jogos saem da fábrica com código de máquina da GPU AMD, que o emulador decodifica instrução a instrução e converte pra SPIR-V, o formato do Vulkan.

O Azimuth, que faz o Forza Horizon 2 rodar no Windows, traduz chamadas WinRT do Xbox pra Win32 e DirectX 11.X pra DirectX 12 desktop, com o código x86 do jogo rodando direto. O AnyPS5 religa o executável: pega o binário do PS5 e gera um binário nativo de Linux ou Windows, ligado a bibliotecas de sistema reimplementadas. Nos três casos, Proton, DXVK, VKD3D e MoltenVK já tinham resolvido a camada de tradução gráfica anos antes.

A prova inversa são os consoles que não eram PC. O PS3 usa o Cell, um PowerPC com sete coprocessadores ativos (os SPEs), cada um com memória local própria e sem cache, e o RPCS3 está nisso desde 2011, com a emulação dos SPUs sendo gargalo até hoje. O Xbox 360 é PowerPC também, e por isso o Sonic Unleashed precisou do XenonRecomp traduzir PowerPC pra C++. Engenharia reversa é caso a caso, e a arquitetura decide se o caso é fácil.

A IA está no meio, e já tem briga

Que os ports de 2026 usam IA, boa parte deles diz na cara. O decomp do Silent Hill escreve no README que o desenvolvimento é “fortemente assistido por IA (Claude Opus 4.6, 4.7 e o Fable mais novo), e somos abertos sobre isso. Não é tradução automatizada do jogo”. O recomp do Pokémon Stadium lista o Claude como contribuidor.

Os devs dos recomps de Zelda e Banjo, que passaram anos fazendo isso à mão, entraram em guerra com o que chamam de “slopcomps”, ports gerados por agente com qualidade de alpha.

E vale separar manchete de estado real também aqui. O AnyPS5 tem uma versão 0.1 de setembro que, segundo quem testou, roda um jogo indie 2D; a alegação viral de que “o PS5 está 80% portado pra PC” é dos fãs, e nenhum jogo 3D roda. Astro Bot roda, só que em emuladores (KytyPS5, SharpEmu), que fazem o caminho tradicional. O Forza Horizon 2 roda, e o Azimuth é um binário fechado de um estúdio que se declara “AI assisted” sem dizer mais nada.

“Mas daqui a dois anos o token custa nada”

A resposta padrão pra tudo isso é: hoje é difícil, em dois anos é trivial, porque IA cresce exponencialmente. Os números dizem outra coisa.

O preço da ponta mais cara caiu pouco. O GPT-4 de março de 2023 custava US$ 30 e 60 por milhão de tokens de entrada e saída; o Claude 3 Opus de 2024, 15 e 75; os modelos de ponta de hoje, Fable 5.1 e GPT-6 Astra, custam 10 e 50. Em três anos e meio, a fronteira ficou entre 1,2 e 3 vezes mais barata, dependendo de qual ponta você olha.

O que caiu de verdade foi o custo de uma qualidade fixa: a Epoch AI mediu quedas de 9 a 900 vezes por ano dependendo da tarefa, e numa revisão de 2026 resume em “muito grosseiramente 5 a 10 vezes por ano”, com o aviso de que pode desacelerar. Isso é real e é ótimo.

Só que aplica a conta no Bun. US$ 165 mil divididos por 10 dá US$ 16 mil. Por 100, US$ 1.650. Isso é pra portar um runtime com fonte, testes e autor na mão.

Pra um amador tentando clonar o Photoshop sem nada disso, a conta começa ordens de grandeza acima e cai na mesma proporção. Barato não é o mesmo que trivial.

E a premissa do “exponencial” morreu em 2024. O Ilya Sutskever disse no NeurIPS que o pré-treino como conhecemos vai acabar, porque só existe uma internet. A Epoch projeta que o escalonamento dos modelos de raciocínio converge pra taxa geral da fronteira em cerca de um ano.

Eu já escrevi sobre isso três vezes nas últimas semanas: os limites do que o modelo reproduz, a convergência dos modelos crus com o ganho vindo do harness, e o benchmark de linguagens em que os modelos de fronteira empataram no teto. A ferramenta que temos é a ferramenta que vamos ter por um bom tempo, com melhoria incremental. Planeje com ela.

Vale lembrar o número que abre o texto dos limites: pelo Octoverse 2025, relatório oficial do GitHub, 81,5% das contribuições na plataforma aconteceram em repositórios privados. É o código que importa de verdade, o que paga salário, e nenhum LLM viu uma linha dele. O modelo reproduz o que estava no treino, e esse código nunca esteve lá.

Agora estenda isso pra todo produto SaaS e pra cada componente que ele usa. O código da Adobe que realmente vale, o motor de cor, os perfis, os filtros na nuvem, não está disponível em lugar nenhum, nem como binário. Quem quiser reproduzir vai ter que refazer a pesquisa e o desenvolvimento, caro e demorado, pelos mesmos anos que a Adobe levou. E no fim ainda esbarra na propriedade intelectual licenciada de terceiros, Pantone, SDK de câmera, perfil de fabricante, que você nunca vai conseguir ter.

Respondendo a lista do começo

O PhotoCraft existe? Existe, é uma alpha de duas semanas com mais de 800 issues abertas, gerenciamento de cor rudimentar, travando acima de 8K e abrindo PSD errado. Parece Photoshop no print. Pode melhorar muito, e vai descobrir que o alvo se move e que as partes caras do Photoshop estão na nuvem ou em contrato com fabricante.

O REA existe? Existe, é bom, e é uma caixa de ferramentas pra quem já sabe usar Ghidra, exige o binário na mão, as ferramentas instaladas e centenas de milhares de tokens por análise. O próprio projeto evita dizer que ele clona programa.

Recomp e decomp aceleraram? Sim, de verdade, e a IA tem parte nisso. Aceleraram onde o binário existe, é pequeno, está documentado há 25 anos e não se move. Ou onde o console é um PC disfarçado e o trabalho é tradução de API, resolvida pelo Wine e pelo Vulkan anos antes.

A Adobe morreu? A Adobe tem uns 40 milhões de assinantes, pela estimativa mais citada, as features que vendem assinatura rodam no servidor dela, e trinta anos de GIMP ainda deixam a gráfica pedindo Photoshop. Eu queria que fosse diferente. Os dados dizem que o que vai acontecer é o que sempre aconteceu com clone de produto vivo: anos correndo atrás, e quando alcança, o valor já mudou de lugar.

Programador morreu? Reescrever o Bun precisou do autor do Bun. Os decomps que funcionam têm gente que conhece o hardware pilotando o agente, e os que não têm viraram “slopcomp” com nome e tudo. A engenharia reversa ficou mais barata e mais acessível, como ficou com o Ghidra em 2019, e continua sendo trabalho de engenheiro. Sem nós, a ferramenta devolve print bonito.

Software proprietário com binário na mão vai sofrer pressão, e deve. A maior parte do software que você usa não tem binário nenhum, e o que tem já depende de serviço na nuvem que não desmonta. Engenharia de software com IA tem um caminho ótimo pela frente. Manchete de “acabou” rende clique e não compila.

Essa é a minha tese, e eu sei que ela é impopular. Levei dez anos de paciência pra poder escrever esse texto. Fiquei calado vendo esse teatro se repetir ano após ano, esperando o momento certo de documentar tudo o que testemunhei de perto, e hoje eu posso, com prazer, ver minhas próprias previsões se confirmando uma por uma.

E antes que algum espertinho tente essa: eu sei que boicote, doxxing e caça às bruxas existem sem CODE_OF_CONDUCT.md nenhum, sempre existiram. O título mira no que esse arquivo virou: o instrumento que pegou uma tática de turba de internet e carimbou ela como política oficial do projeto, com comitê, processo e verniz de legitimidade institucional. Um arquivo markdown de 500 linhas não assusta ninguém sozinho; o que ele virou, sim.

Dinheiro fácil foi o combustível. Código de conduta foi a arma que essa gente construiu pra oficializar o que antes era só grito de rua.

Uma pergunta é de onde veio a energia; outra é o instrumento que ela adotou pra virar poder permanente dentro do projeto. Guarda essa distinção, porque ela sustenta o texto inteiro. Mas antes de chegar na filosofia, deixa eu contar a parte econômica, porque sem entender o dinheiro você não entende o resto.

A bolha que financiou tudo isso

De mais ou menos 2012 até 2022, a indústria de tech viveu a maior bolha de contratação da história. Juros a zero, capital infinito, e as big techs crescendo como se não houvesse amanhã. Chegamos ao ponto surreal de empresas contratarem engenheiros sem ter trabalho para eles. Keith Rabois, da turma do PayPal, acusou Google e Meta publicamente de contratar milhares de pessoas para fazer “trabalho falso”, por vaidade, e para que não fossem trabalhar nos concorrentes. Uma ex-funcionária da Meta, demitida na primeira leva de 2022, resumiu melhor: “eles estavam estocando a gente como cartas de Pokémon”. A cultura do “rest and vest”, colecionar salário e stock options fazendo quase nada, já era documentada em 2017.

Foi essa bolha que financiou a onda de “programação é a profissão do futuro”. Bootcamps saíram de 2.178 formados em 2013 para quase 25 mil em 2020 só nos EUA e Canadá, crescimento de mais de mil por cento. O Bloomberg resolveu aprender a programar como promessa de ano novo em 2012. O Obama escreveu uma linha de código na TV em 2014.

Eu contei essa história com mais detalhes num vídeo de fevereiro de 2020, quando a bolha ainda estava inflando (transcrição aqui):

Influencer de tech virou profissão. Todo mundo ia ser programador.

Aí a bolha estourou. 2022: quase 165 mil demitidos. 2023: mais de 262 mil, segundo o Layoffs.fyi. Meta cortou 11 mil em novembro de 2022 com o Zuckerberg admitindo “I got this wrong”, e mais 10 mil no “ano da eficiência” de 2023. Amazon cortou 27 mil. Google, 12 mil, com o Pichai admitindo que “contratamos para uma realidade econômica diferente da que enfrentamos hoje”. Stripe foi a mais honesta: “we overhired”.

Eu registrei esse estouro no calor do momento, num vídeo de novembro de 2022 (transcrição aqui):

E como o timing é uma piada pronta, em 30 de novembro de 2022, bem no meio do banho de sangue, saiu o ChatGPT. Cem milhões de usuários em dois meses, o aplicativo de crescimento mais rápido já visto até então, segundo estimativa do UBS. As manchetes viraram uma palestra da ACM chamada “Large Language Models and the End of Programming”, Jensen Huang dizendo que criança nenhuma precisa mais aprender a programar, o Devin se anunciando como o primeiro engenheiro de IA, o Dario Amodei prometendo que IA escreveria 90% do código em três a seis meses. Spoiler: não escreveu.

Por que essa história importa? Porque foi exatamente durante essa década de dinheiro fácil que o open source foi colonizado. Quando sobra dinheiro e falta trabalho real, sobra tempo e gente para fazer política dentro dos projetos. E foi o que aconteceu.

A década da caça às bruxas

O artefato central dessa história é o Contributor Covenant, criado em 2014 por Coraline Ada Ehmke e adotado por milhares de projetos, incluindo praticamente todo gigante do setor: CNCF, Apple, Google, Microsoft, Linux. A própria autora, no dia em que o Linux adotou o código dela, tuitou com todas as letras: “Some people are saying that the Contributor Covenant is a political document, and they’re right”. Quando o autor do documento admite que ele é político, a discussão sobre “espaço seguro” acabou antes de começar.

A lista de vítimas dessa era é longa, então vamos aos principais.

Antes, vale registrar o alcance dessa turma. A Coraline trabalhou no GitHub entre 2016 e 2017, até ser demitida (a versão dela está no texto “Antisocial Coding: My Year at GitHub”). E o GitHub era o alvo perfeito: era onde morava praticamente todo o open source do mundo. Foi nessa era que os fundadores originais saíram de cena. Tom Preston-Werner renunciou em 2014 no escândalo de assédio da Julie Ann Horvath, mesmo com a investigação interna concluindo que não houve nada ilegal, só “erros de julgamento”. O Chris Wanstrath já tinha anunciado que sairia do cargo de CEO em 2017 e, depois da venda para a Microsoft em 2018, ainda ficou alguns anos como technical fellow até sair de vez. Hoje nenhum fundador original trabalha lá.

O legado dela sobreviveu à demissão. O Contributor Covenant virou um dos templates que o GitHub facilita adotar quando você cria o CODE_OF_CONDUCT.md de um repositório. E em 2020 veio a joia da coroa: no meio dos protestos do George Floyd, o GitHub anunciou que ia aposentar o nome master, e desde 1º de outubro de 2020 todo repositório novo nasce main.

A discussão era estúpida desde o começo. O Git nunca teve branch slave. O Petr Baudis, que batizou o nome nos scripts originais, explicou no X que master ali era de “master copy”, como a gravação master de um disco (o próprio Baudis disse depois que hoje prefere main; a etimologia continua a mesma). Nem esse detalhe segurou a mudança: até a Software Freedom Conservancy endossou publicamente a troca, e quem tinha automação assumindo master teve que correr atrás. Ninguém ficou mais protegido por causa dessa mudança, mas ela está lá, no fluxo de trabalho de todo programador, todos os dias.

Brendan Eich, 2014. O cara inventou JavaScript, cofundou a Mozilla, era CTO desde 2005. Virou CEO e durou onze dias no cargo. O crime: uma doação de mil dólares em 2008 para a Proposition 8 da Califórnia. Funcionários tuitaram pedindo a cabeça dele, o OkCupid bloqueou usuários de Firefox com uma mensagem de protesto, e ele caiu. Andrew Sullivan, gay e um dos primeiros defensores de peso do casamento entre pessoas do mesmo sexo, escreveu na época “The Hounding of a Heretic”: quando carreiras dependem de teste de pureza ideológica, a caça às bruxas já venceu. E repara: aqui não tinha código de conduta nenhum envolvido, foi pressão pura de boicote. O método já existia antes do documento; o documento só oficializou.

Larry Garfield, 2017. Doze anos de contribuição no Drupal. Quando vazaram que ele participava de uma subcultura BDSM, num site privado, fora do projeto, o comitê de conduta do Drupal investigou e concluiu: sem violação do código de conduta. O Dries Buytaert passou por cima do próprio comitê e expulsou ele assim mesmo, porque a “associação com o sistema de crenças dele” era incompatível com os objetivos do projeto. O TechCrunch resumiu do mesmo jeito: punido por algo dito fora do projeto. Oitenta e cinco desenvolvedores assinaram carta aberta ameaçando sair. Não adiantou. E repara no detalhe que enterra a tese do “espaço seguro”: o processo do código de conduta funcionou e inocentou o cara. Quando a turba apertou, o papel não segurou nada; quem decidiu foi a pessoa no topo, como sempre foi.

Node.js, 2017. O TSC de treze pessoas votou a expulsão do Rod Vagg por, entre outras coisas, ter twitado um artigo questionando os efeitos colaterais de código de conduta. Ler crítica a código de conduta quase virou violação de código de conduta: a votação foi 6 a 4 contra a expulsão, por pouco. A máquina perdeu essa rodada, mas o recado já tinha saído: quatro dos que queriam o cabeça do Vagg pediram para sair do comitê no mesmo dia, e o projeto ganhou um fork chamado Ayo.js horas depois. Perder a votação não impediu o estrago.

Linus Torvalds, 2018. Em setembro, segundo os relatos da época, a New Yorker tinha mandado perguntas sobre o comportamento abusivo dele nos emails. No mesmo fim de semana, Linus pediu desculpas e anunciou que ia tirar um tempo para “entender as emoções das pessoas” e o kernel trocou o Code of Conflict pelo Contributor Covenant. O Linus é grosseiro nos emails desde sempre, todo mundo sabe, e ele voltou um mês depois. Mas o recado foi dado: se nem o cara que criou o kernel estava a salvo, ninguém estava.

Richard Stallman, 2019. O criador da GPL, fundador da FSF, a encarnação do software livre. Vazaram um thread de lista de email do MIT em que ele discutia semântica jurídica sobre o caso Minsky/Epstein. A Vice estampou que ele tinha “defendido Epstein” e chamado as vítimas de “entirely willing”, uma leitura que o próprio thread de emails não sustenta: ele questionava a terminologia jurídica da acusação contra o Minsky. A campanha “Remove Richard Stallman” explodiu, e em dias ele renunciou do MIT e da presidência da FSF. Quando ele voltou ao conselho da FSF em 2021, saiu uma carta aberta com mais de 3 mil assinaturas e dezenas de organizações exigindo a cabeça dele e de todo o conselho. A Red Hat cortou o financiamento da FSF. A carta de apoio juntou quase 7 mil assinaturas e, detalhe delicioso, o Debian votou uma resolução sobre o caso e a opção vencedora foi não se manifestar. Até para fingir neutralidade precisou de votação.

E tem o caso mais recente e talvez o mais didático: Tim Peters, 2024. Lenda do Python, três décadas de contribuição, suspenso por três meses pelo comitê de conduta da PSF por acusações vagas de criar “atmosfera de FUD”, numa briga sobre os estatutos da fundação e sobre os métodos do próprio comitê. A comunidade reagiu feio, mas não teve volta: ele cumpriu os três meses e só voltou quando a suspensão expirou, em novembro. O padrão se manteve: discordar da moderação virou ofensa punível.

DHH, 2021. Deixei esse para o final porque é o caso que muda a história. E note: aqui nem open source era, era a empresa dele. O mesmo mecanismo, agora dentro do escritório. Em abril de 2021, no auge da era BLM, um comitê interno de DEI dentro da Basecamp, a empresa do criador do Ruby on Rails com o Jason Fried, desenterrou uma lista antiga de “nomes engraçados de clientes” que circulava na empresa. A discussão escalou até um funcionário citar a “pirâmide do ódio” e argumentar que aquela lista era o fundamento de violência racial e até genocídio. A resposta dos fundadores foi fechar o assunto, dissolver o comitê e proibir discussão política e social nos canais internos. A internet explodiu. Na reunião geral seguinte, foram duas horas e meia de gente chorando e gritando no Zoom. O Ryan Singer, dezoito anos de casa, disse ali que não aceitava o rótulo de “cultura de supremacia branca” aplicado à empresa. Foi suspenso meia hora depois da reunião e se demitiu no fim de semana. Ao final, um terço da empresa, vinte dos 57 funcionários, saiu com pacote de demissão voluntária.

E é aqui que esse caso se separa de todos os outros: ele não dobrou. Sem ritual público de humilhação, sem pedido de desculpas, sem volta atrás. Preferiu perder um terço da empresa a entregar o controle dela. A Basecamp sobreviveu, virou 37signals de novo, e o DHH aprendeu ali, na carne, com que tipo de gente estava lidando. Guarda esse nome, porque ele volta.

Alguém vai apontar que a regra dele também é um documento escrito proibindo um assunto. É, e a diferença é exatamente o ponto: a regra do DHH bane um tópico inteiro, igual pra todo mundo, não importa o lado. Código de conduta bane pessoa e opinião, seletivamente, dependendo de quem está no poder naquele mês.

Uma trava o assunto na porta. A outra abre um tribunal lá dentro.

Repara no padrão. Em nenhum desses casos o problema era código. Em nenhum deles alguém commitou bug, roubou código, sabotou release. As ofensas foram opiniões, doações políticas, vida privada, semântica em lista de email. O critério técnico foi substituído pelo critério político, e o código de conduta foi o instrumento jurídico dessa substituição. São casos famosos, não estatística. Mas quando a lista inclui os criadores do JavaScript, da GPL e do Linux, a amostra não precisa ser grande para passar o recado.

E os resultados?

Dez anos de era do código de conduta deveriam ter deixado um rastro de números bons. Se a justificativa era proteger minorias e tornar o open source mais diverso e menos tóxico, cadê a melhora? Fui procurar a pesquisa séria sobre o assunto. O que existe conta uma história interessante.

Sobre adoção: Tourani, Adams e Serebrenik mediram em 2017 que cerca de 35% dos 150 projetos mais populares do GitHub tinham código de conduta. E que enforcement era raro: os criadores desses códigos, numa amostra de quatro entrevistados, falavam em casos de um dígito ao longo de anos. Um estudo de 2021 da CSCW olhou 52 mil repositórios: 12,6% tinham CoC, e só 10% das conversas mencionando o código eram uso real dele em moderação. A maioria das adoções aconteceu sem discussão pública visível no repositório. O mesmo paper diz, com todas as letras, que não existe evidência empírica de que código de conduta atraia novos contribuidores.

Sobre atrair gente, aliás, Qiu et al. mediram o que realmente faz alguém entrar num projeto: README bom, número de estrelas, atividade recente, template de issue. Código de conduta nem entrou como variável no modelo deles, e olha que eles testaram maintainer responder rápido, que também não deu significativo. Quem mediu especificamente onde o CoC fica no ranking de fatores foi um estudo separado, o Fronchetti, Wiese, Pinto e Steinmacher, também de 2019: CoC ficou entre os fatores pior colocados pra atrair contribuidor novo. Ninguém escolhe projeto pelo código de conduta.

Sobre diversidade, que era a promessa original, tem estudo específico e a resposta é não. O Robson, no ESEC/FSE de 2018, olhou os 500 projetos mais populares do GitHub: projetos que adotaram CoC viram a participação de mulheres crescer praticamente no mesmo ritmo dos que não adotaram (por volta de 1,44% de aumento contra 1,43%, segundo o levantamento posterior que cita o estudo). Sem diferença estatística que sustente a promessa. O Enache, em dissertação de mestrado de 2017 pra TU Eindhoven, sobre 149 comunidades open source, chegou na mesma conclusão: nenhum resultado significativo de que CoC mude a participação de mulheres.

E tem uma pesquisa nova, de peso, publicada agora em 2026 no ICSE, a conferência mais importante da área: o Sun et al. rodou um experimento causal de verdade, comparando 4.684 pares de repositórios que adotaram CoC contra pares equivalentes que não adotaram. O resultado tem duas pontas. Adotar CoC atrai sim mais contribuidor novo, e esse efeito cresce com o tempo. Só que adotar CoC também aumenta o número de contribuidores antigos que se desengajam, efeito concentrado justamente nos primeiros um a três meses depois da adoção. Ou seja: o próprio estudo mais recente e mais rigoroso que existe mostra, com número, o padrão que esse texto documentou caso por caso o tempo todo. Adotar o documento não constrói comunidade nova, ele expulsa gente que já estava lá.

O levantamento do GitHub de 2017 já marcava 95% homens e 3% mulheres no open source. O melhor dado de longo prazo que existe, do Rossi e Zacchiroli no ICSE 2022, analisou 2,2 bilhões de commits do arquivo do Software Heritage. Gênero detectável para 64% dos autores e, nesse grupo, mulheres são 13,5% dos autores e assinam 8,1% dos commits. A participação delas vinha crescendo devagar e de forma contínua havia doze anos, e caiu na pandemia. O paper não fala de código de conduta, então a leitura que segue é minha, não do estudo: uma curva que sobe do mesmo jeito a década inteira, sem nenhum degrau visível quando o Contributor Covenant se espalhou, é o oposto de evidência de que o documento fez diferença.

Sobre toxicidade, o estudo da ICSE 2022 acha, em nota de rodapé e por extrapolação, algo perto de 1,3 comentários tóxicos por mil no GitHub. Ninguém tem uma série histórica comparando antes e depois da era CoC. Simplesmente não existe baseline pra dizer se piorou ou melhorou.

O único experimento randomizado que sustentaria a tese das regras é do Matias, publicado na PNAS em 2019: lembretes de regras exibidos ativamente numa amostra sorteada de threads no r/science aumentaram em 70% a participação de novatos. Só que o experimento é no Reddit, com a regra pregada bem na cara de quem entrava naquela thread específica. Um arquivo estático esquecido no repositório, que ninguém lê depois do dia da adoção, não chega nem perto disso. A própria pesquisa que mostra uma regra funcionando é a prova de que o problema nunca foi ter ou não ter o arquivo. É ninguém aplicar, ninguém mostrar, ninguém fazer valer.

Resumindo: uma década inteira de códigos de conduta, e a promessa original continua exatamente isso, uma promessa. O que ficou documentado foi adoção sem discussão, enforcement raro e, no máximo, um monte de processo político.

Como proteção, quase nunca é invocado. Como arma política, só precisa ser invocado uma vez, contra a pessoa certa.

A contra-reação veio de onde ninguém esperava

O dinheiro fácil acabou em 2022 e, com ele, a paciência da indústria para esse teatro. E a liderança da reação foi o cara que já tinha se recusado a dobrar em 2021: o DHH, ex-fanboy de Mac da velha guarda.

O DHH vem escrevendo contra essa onda faz tempo: “The waning days of DEI’s dominance” em 2022, “DEI is done” em 2024. Em 2022 a Ruby Central tirou ele do keynote da RailsConf, a conferência do framework que ele mesmo criou, dizendo que queria “dividir o palco de abertura com outros contribuidores”. No ano seguinte nasceu a Rails World, a conferência oficial da Rails Foundation, e o DHH virou keynote dela. Em 2024 lançou o Omakub e, em junho de 2025, o Omarchy: Arch Linux com Hyprland e um monte de scripts opinativos em cima, que passava de 40 mil stars no GitHub em setembro de 2026 e virou o ambiente padrão da 37signals pra quem mexe com infra e Ruby.

Aí a máquina de cancelar ligou de novo. Em setembro de 2025 ele publicou “As I remember London”, e a reação foi o script de sempre: petição para tirá-lo, acusações, tentativa de boicote. A resposta dele foi “We’ve all had enough of this nonsense”: “a cada poucos anos, o mesmo grupelho triste de descontentes do Ruby tenta me cancelar do Rails”.

Um mês depois, em outubro de 2025, foi a vez da Framework, fabricante de laptops: um thread com mais de 1.500 respostas no fórum da própria empresa, aberto por um desenvolvedor Debian chamando a comunidade do Hyprland, que a Framework patrocinava, de “tóxica e odiosa”, e ameaçando boicote porque a empresa também promovia o Omarchy nas redes. A resposta do CEO da Framework é a frase que faltava nessa década inteira:

“Criamos deliberadamente uma barraca grande, porque queremos que o open source vença. Não fazemos parceria com base nas crenças de indivíduos ou organizações.” (“big tent”, no original.)

E a máquina não bateu só nele. A Ruby Central, a mesma que tinha desconvidado o DHH do keynote em 2022, deu palco para ele na RailsConf 2025. A retaliação veio em dinheiro: segundo a apuração do desenvolvedor Joel Drapper, a Sidekiq retirou o patrocínio de 250 mil dólares por ano por causa disso. Semanas depois, em setembro de 2025, a Ruby Central removeu do GitHub todos os maintainers de longa data do RubyGems e do Bundler, alegando segurança da cadeia de suprimentos. A Ellen Dash, que mantinha o projeto havia dez anos, pediu conta chamando o movimento de “hostile takeover”, e a investigação do Drapper aponta pressão da Shopify, que tinha virado praticamente a única fonte de dinheiro da organização. A própria Ruby Central acabou publicando um relatório do incidente em abril de 2026, prometendo “fortalecer a governança”. Esse é o padrão completo: quando a máquina não derruba o alvo, incendeia a casa em volta dele.

Um desenvolvedor do GNOME publicou um texto atacando o Omarchy no blog oficial de blogs do GNOME. E o resultado de toda essa fúria? Nada. Em agosto de 2026 nasceu a Omacom Foundation, com oito milhões de dólares no lançamento: um milhão de cada um de Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell, Jack Dorsey, Matthew Prince (Cloudflare), Brendan Iribe, Jason Fried e o próprio DHH. A fundação virou patrocinadora exclusiva do Hyprland, com o Vaxry trabalhando em tempo integral. Quando a 1Password entrou como patrocinadora, a tentativa de cancelamento foi imediata e a resposta interna do CEO também: “nossa doação não é endosso de opiniões pessoais”. E segue o jogo.

E eu botei o meu dinheiro onde está a minha boca: fiz a minha doação para a fundação exatamente por causa do chororo da patrulha. Nada irrita mais essa turma do que ver o cancelamento falhar em tempo real.

Esse é o ponto: a máquina ainda existe, mas perdeu o poder. Em 2014 derrubou um CEO em onze dias. Em 2026 não consegue arranhar um patrocínio de distro de nicho. Os documentos continuam lá, no template do GitHub; o que acabou foi o poder de fogo de quem os empunhava. O que mudou foi o dinheiro, e sim, a contra-reação também é dinheiro: oito milhões de dólares de oito homens ricos.

E antes que alguém aponte que dinheiro não prova mérito: depende. Milionário criado por conchavo de governo, fraude ou favor não tem mérito nenhum. Mas a maioria dos milionários se fez produzindo, e é o caso dos oito patronos da Omacom. Dinheiro ganho produzindo é a medida do mérito de quem o fez, como eu já escrevi aqui em 2011, sobre o discurso do dinheiro do Francisco D’Anconia em “A Revolta de Atlas”.

Julgue pelo resultado que a doação comprou, não pela intenção declarada de quem assina o cheque.

Os 49,5 bilhões de dólares corporativos de 2020 não produziram um grama a mais de diversidade mensurável, os números aí em cima provam isso. Oito milhões de dólares de patrono individual produziram um maintainer em tempo integral escrevendo código de verdade. A bolha que financiava exércitos de gente sem trabalho real estourou, e quem sobrou foi quem estava lá pelo código.

A parte filosófica

Vamos à desculpa oficial: códigos de conduta existem para “proteger minorias”. Na superfície, quem seria contra proteger minorias? Eu não sou. O problema é que a frase é vaga por design.

O que é uma minoria? Eu já traduzi aqui no blog o capítulo “Direitos do Homem” de “The Virtue of Selfishness”, da Ayn Rand. A frase que me interessa aqui está em outro capítulo do mesmo livro, “Racism”, e continua imbatível:

A menor minoria da Terra é o indivíduo. Quem nega direitos individuais não pode dizer que defende minorias.

E é exatamente isso que esses códigos fazem na prática: em nome de uma minoria abstrata e coletiva, persegue-se o indivíduo concreto. Doxxing (expor os dados pessoais da pessoa), campanha de assédio, pressão no empregador, banimento. Quando o modus operandi para “proteger minorias” é bullying coordenado contra uma pessoa até ela dobrar os joelhos, você está oprimindo a menor minoria que existe.

Esse assunto, aliás, é velho para mim. Em dezembro de 2018 eu publiquei no meu canal o vídeo “Manifesto Anti-Parasita: Seja um Criador”. Na época eu não podia ser explícito, a polícia do pensamento ainda estava forte demais. Mas quem assistiu com atenção entendeu o recado. Era o meu breadcrumb para essa história que eu só estou podendo contar direito agora.

E tem o segundo problema, mais fundamental: open source é sobre software. A GPL, que essa turma tanto despreza, resolve a proteção que um projeto de software não pode perder: a do código. Garante que o código continue livre, ponto. Ela não pergunta quem escreveu, em quem votou, o que tuitou, o que doou. O compilador não checa pureza ideológica. O open source sempre foi a comunidade mais inclusiva que já existiu justamente por isso: o único passaporte era o diff. O código de conduta tornou o open source menos inclusivo, porque adicionou um critério novo à entrada: política. E política é um critério estúpido para software.

“Ah, mas sem código de conduta, como lidamos com assédio real?” Com a mesma ferramenta de sempre: bom senso de maintainer e, quando necessário, a lei. Se alguém ataca outra pessoa diretamente, uma agressão sexual num evento, por exemplo, banir é senso comum e nunca precisou de documento nenhum. Assédio, ameaça e difamação já são crimes em praticamente todo país, e crime se resolve no caminho da lei. O que eu não engulo é outra coisa: sair stalkeando a vida online de alguém para desenterrar uma opinião aleatória, sem relação com crime nenhum, e exigir banimento por causa de palavras sem consequência criminal. Esses comitês sempre foram ótimos em punir opinião e péssimos em punir crime, então o documento nunca foi sobre isso.

E não sou eu sozinho dizendo isso. Eric S. Raymond, o cara que escreveu “The Cathedral and the Bazaar”, o texto de 1997 que validou pra Netscape a decisão de abrir o código do Mozilla e que praticamente escreveu as regras do jogo do open source, cofundador da OSI, editor do Jargon File, autor do fetchmail, foi ao X em setembro de 2025 declarar a era dos códigos de conduta um fracasso completo. Nas palavras dele: dez anos de “drama e idiotice”, uma “insanidade social infecciosa” que produz política, intriga e trabalho útil negativo. A recomendação é a mais direta possível: não adote; se já adotou, delete. E se alguma burocracia te obrigar a ter um, a substituição sugerida tem uma frase só:

“Se você é mais chato de trabalhar do que as suas contribuições justificam, você é ejetado.”

É o que eu disse dois parágrafos acima: bom senso de maintainer.

E o detalhe que fecha o círculo: o próprio ESR tinha sido removido de duas listas de email da OSI em 2020 por posts que “violaram o código de conduta” da organização que ele ajudou a fundar.

O cara que escreveu as regras do jogo, ejetado pelo documento. Essa imagem resume a era inteira.

Como chegamos até aqui

Vale dar um passo atrás e contar de onde veio tudo isso, porque o open source foi só um dos fronts. O tiro de largada, na minha leitura, foi o GamerGate, em 2014. Em agosto daquele ano saiu o “Zoe Post”, o desabafo do ex-namorado da desenvolvedora Zoe Quinn. Doze dias depois, e cerca de 48 horas depois de a hashtag #GamerGate pegar força, cerca de uma dúzia de sites de games publicou variações do mesmo artigo: “gamers are over”, os jogadores estão mortos, acabou.

Pouco depois vazou o GameJournoPros, um grupo fechado onde jornalistas de games coordenavam cobertura. O público percebeu na hora que a imprensa de games tinha virado clube ideológico, e reagiu com a própria versão do boicote organizado: a campanha “Operation Disrespectful Nod” inundou a Intel de reclamação até a empresa tirar os anúncios da Gamasutra (a imprensa da época chamou de “campanha anti-feminista”; pra mim é só pressão organizada de consumidor, o mesmo instrumento que a Sidekiq usou contra a Ruby Central lá na frente).

E aqui vale fixar o princípio, porque ele vale pros dois lados o resto do texto inteiro: pressão organizada de consumidor é jogo limpo, não importa de que lado vem. O problema nunca foi pressão. É doxxing, ameaça de emprego e comitê fingindo neutralidade pra impor o resultado que já queria antes de abrir o processo.

Durante anos, de 2021 a junho de 2025, o artigo da Wikipedia sobre o assunto viveu batizado “Gamergate (harassment campaign)”, tratando qualquer crítica ao jornalismo como pretexto de assédio. O título foi trocado de volta pra simplesmente “Gamergate” depois que a fase mais histérica passou, o que devia ser lido como uma confissão, não como se o caso estivesse encerrado: renomearam de volta quando ficou caro demais defender o rótulo político, exatamente o mesmo padrão de recuo silencioso que aparece em toda essa história. Enquanto durou, durou justamente na década em que essa turba tinha poder de fogo pra fazer valer.

A briga editorial foi tão feia que o comitê de arbitragem da Wikipedia puniu mais de uma dúzia de editores, dos dois lados. E olha que eu nem preciso acusar a Wikipedia sozinho: o Larry Sanger, cofundador da Wikipedia, escreveu em 2020 o texto “Wikipedia Is Badly Biased” declarando que a neutralidade do projeto morreu, e em setembro de 2025 publicou as “Nine Theses on Wikipedia”, pedindo reformas como o fim das listas negras de fontes e o fim do bloqueio eterno de editores. Quando o fundador diz que a casa foi tomada, acredite no fundador.

A versão do lado dos gamers dessa história está no livro “SJWs Always Lie”, do Vox Day, de 2015. Já sei o que vem: “Vox Day” e “Milo Yiannopoulos” (espero ter escrito certo) são nomes que fazem gente gritar só de ouvir, e o GameJournoPros, aliás, também foi destrinchado originalmente por esse Milo. Não me interessa a reputação de quem conta a história, me interessa se a história é verdadeira. Fonte partidária de dentro da briga, aviso dado, mas o fato central bate com o que a própria Wikipedia e a imprensa da época documentam sem ligação nenhuma com esses dois nomes: a lista GameJournoPros existiu de verdade, um grupo fechado de umas 150 pessoas do jornalismo de games trocando ideia sobre como cobrir o caso.

O capítulo “Counterattack” conta o GamerGate de dentro, e a tese do livro resume a década: essa gente sempre mente, sempre dobra a aposta, sempre projeta nos outros exatamente o que ela mesma faz.

Do GamerGate em diante, foi dominó. A Anita Sarkeesian transformou o Kickstarter dela de meta de 6 mil dólares em 158 mil, virou autoridade global, foi falar na ONU em 2015 sobre “violência cibernética”, e o jornalismo de games nunca mais se recuperou. O Feminist Frequency dela fechou as portas em 2023, mas a lógica que ela inaugurou migrou para dentro dos estúdios: nasceu a indústria da consultoria de “narrativa inclusiva”, com a Sweet Baby Inc na dianteira.

A CEO da Sweet Baby, Kim Belair, foi gravada numa palestra da GDC de 2019, gravação pública que circula fora do site que primeiro a levantou, aconselhando quem quer aprovação interna pra consultoria de “representação” a “ir tomar um café com o time de marketing e aterrorizar eles” com a possibilidade do que aconteceria se não desse a eles o que queriam. Em 2024, um brasileiro criou no Steam uma página de curadoria (o recurso da própria Valve onde qualquer conta pode publicar recomendações de jogos e ganhar seguidores) batizada de “Sweet Baby Inc Detected”. Um funcionário da empresa tentou individualmente derrubar o perfil por conta própria, e a Valve também agiu por moderação própria; mesmo assim, o resultado foi o grupo explodindo para mais de 350 mil seguidores.

E vieram os flops. O Suicide Squad: Kill the Justice League, com consultoria confirmada da Sweet Baby, custou 200 milhões de dólares de prejuízo à Warner. O Unknown 9, do estúdio onde a dupla fundadora da Sweet Baby trabalhava, demitiu em massa um mês depois do lançamento.

Aí veio 2020. Com o BLM, a mesma cartilha virou política de Estado: as 50 maiores empresas americanas prometeram 49,5 bilhões de dólares em ações de “justiça racial”, vagas de DEI cresceram 123% em meses, Biden assinou no primeiro dia de mandato a ordem executiva de “equidade” para todo o governo federal, e a União Europeia saiu com seu plano anti-racismo 2020-2025. Era o auge: a patrulha tinha chegado à presidência dos EUA e à liderança da UE.

O recuo veio tão rápido quanto a subida. A Suprema Corte americana derrubou o affirmative action em junho de 2023, as empresas demitiram milhares de profissionais de DEI, Walmart, Meta, McDonald’s e Amazon abandonaram os programas, e em janeiro de 2025 o Trump revogou as ordens de equidade no primeiro dia.

Contei tudo isso só para situar: o que aconteceu no open source não foi um fenômeno isolado. Foi o mesmo roteiro, com os mesmos métodos, em todas as indústrias de cultura e tecnologia ao mesmo tempo. A diferença é que no open source a resistência demorou mais para organizar. Mas organizou.

O meu Cortlandt

Foi essa pressão que me tirou da organização da RubyConf Brasil. Eu fundei o evento em 2008, ainda como Rails Summit, e na última edição que eu organizei, em 2016, levamos 1.500 pessoas. Quando anunciei a minha saída, escrevi que não tinha drama nenhum envolvido. Não era a verdade inteira: a patrulha já tinha chegado nas conferências de tecnologia, e eu me recusei a transformar o evento que eu criei em mais um palco dela.

Vou dar um exemplo pequeno do que significa ser obrigado a forçar diversidade. Como os dados que eu mostrei acima indicam, mulheres são de 3% a pouco mais de 13% dos contribuidores de open source, dependendo de como se mede: survey autodeclarado ou detecção por nome nos commits. Os analytics do meu canal mostram a mesma faixa, 3 a 5% no máximo, e essa proporção não mudou em dez anos. Todo ano eu abria um Call for Papers público: qualquer pessoa podia submeter uma palestra. E o meu processo de seleção sempre foi cego: eu lia cada submissão sem saber quem tinha enviado, de propósito, para a escolha ser pelo mérito do tema e nunca pela pessoa.

Nos anos da patrulha, a cobrança nunca foi direta comigo. Era aquela pressão externa e difusa de que todo evento tinha que ser “mais diverso”. E na prática isso só podia significar uma coisa: uma fase nova no processo. Depois da seleção cega, revelar quem tinha submetido o quê, para conferir se o lineup estava “diverso o suficiente”. Só que isso é uma impossibilidade matemática. As submissões seguiam os mesmos 3 a 5%. Mesmo aprovando todas as mulheres que submetiam, a cota imaginária não fechava. O jeito era sair convidando pessoas diretamente, escolhendo pelo perfil, e não pelo tema.

E o resultado prático desse esquema, onde quer que ele seja aplicado, é cortar gente que entrou por mérito para abrir vaga para gente escolhida por uma política externa irrelevante. Isso derruba a qualidade do evento em vez de subir. E repara: isso não é um argumento contra mulher nenhuma. É o contrário. No momento em que a cota entra no processo, a dúvida deixa de ser sobre uma palestrante específica e passa a pairar sobre todo mundo que pisa no palco. Não importa quem esteja falando: se alguém na plateia discordar do conteúdo, sempre vai sobrar a pergunta “será que o Akita escolheu esse por cota?”. A partir daí, todo palestrante carrega uma suspeita que não merece e o mérito de cada um fica desvalorizado por tabela. Prejudica a minoria que a política dizia proteger, prejudica os outros palestrantes, prejudica o público. É lose-lose em todas as pontas.

E tem uma parte dessa história que ninguém vê de fora. Algumas das pessoas convidadas desse jeito recusaram na hora, “porque o evento não era diverso o suficiente”. A recusa deixava o evento menos diverso ainda, óbvio. E depois iam para as redes sociais falar mal do evento, como se eu nunca tivesse convidado ninguém. Esse era o nível do lixo que eu tinha que engolir todo ano.

E que fique bem claro: não existe nada que eu queira mais do que ver mais mulheres na tecnologia. O que eu não consigo me convencer é de que forçar cota, do jeito que eu descrevi acima, ajuda nisso. Tudo que eu vi na prática aponta o contrário: prejudica mais do que ajuda. E se eu não acredito que é benéfico, eu prefiro não fazer.

Quer um exemplo recente de mulher que eu admiro na indústria? Asha Sharma, que assumiu como CEO do Xbox em fevereiro. Desde então é resultado atrás de resultado: cortou o Copilot dos consoles e reestruturou a divisão para focar no que importa, vendeu estúdios e cortou custo sem cancelar nenhum jogo anunciado, e essa semana trouxeram a Kojima Productions para o Xbox publicar o próximo jogo do Hideo Kojima, depois da PlayStation cancelar o projeto em meados de 2026. Repara no discurso em volta dela: zero menção a “gênero”, zero pauta.

Só número: cortar custo desnecessário, apostar nas bets certas, melhorar o valor para o cliente. Isso é mérito. Não precisa de DEI para isso.

Até que eu decidi que chega. Quem leu “The Fountainhead” sabe o que eu fiz: como o Howard Roark, o arquiteto que explode o próprio prédio quando adulteram o projeto dele, eu dinamitei o meu Cortlandt. Mais precisamente: o evento como ele existia enquanto era meu. A marca sobreviveu alguns anos na mão de outros, sem a mesma alma, até desaparecer. E eu já tinha sinalizado essa filosofia aqui no blog ainda em 2011. Um indivíduo não faz nada pelos outros: faz por si mesmo. Se o que você constrói beneficia outras pessoas como efeito colateral, melhor, mas esse nunca foi o motivo. Quando os parasitas querem tomar o que você construiu, você mesmo explode tudo. Porque pode. Quem construiu uma vez, constrói de novo do zero.

Foi o que eu fiz. Troquei a conferência pelo meu canal do YouTube, que não dependia de patrocinador, de comitê, de ninguém além de mim. E o canal cresceu muito além do que a conferência jamais seria. Depois eu sentei e esperei a bolha estourar, porque eu sabia que ela ia estourar: escrevi isso aqui no blog e repeti nos vídeos anos antes de acontecer. Estourou. Paciência sempre vence.

Conclusão

Dez anos de código de conduta e o placar é esse: zero evidência de que aumentou diversidade, nem baseline de toxicidade pra comparar antes e depois, e o estudo causal mais recente e mais rigoroso que existe mostra o documento afastando contribuidor antigo mais do que constrói comunidade nova. A promessa era proteger minorias. A entrega foi uma coleção de cabeças: o criador do JavaScript, o criador da GPL, o criador do Linux, todos passando pelo ritual público de humilhação. Nenhum por causa de código. Todos por causa de opinião.

E repara como essa era terminou.

A máquina não perdeu o debate, perdeu o financiamento.

Foi só o dinheiro fácil acabar que os exércitos de gente sem trabalho real evaporaram, e quem sobrou foi quem estava lá pelo código. Enquanto isso, os builders seguiram construindo: o Brendan Eich foi expulso da Mozilla em 2014 e no ano seguinte fundou a Brave, hoje com mais de 100 milhões de usuários ativos por mês e valuation perto de 1 bilhão de dólares. O DHH perdeu o keynote e criou uma conferência maior, perdeu um terço da empresa e ajudou a levantar uma fundação de oito milhões. Eu saí da minha conferência e cresci muito mais no canal. Instituição, parasita toma. Capacidade de construir, não. Quem construiu uma vez, constrói de novo do zero.

Open source recruta voluntários que querem contribuir código. Qualquer discussão que não envolve código é distração na melhor hipótese e sabotagem na pior. E a resposta para “o que colocar no lugar do código de conduta” cabe numa frase só, que o ESR já escreveu: se você é mais chato de trabalhar do que as suas contribuições justificam, você é ejetado. Sempre foi assim que funcionou. O único passaporte é o diff.

O resto é politicagem. E politicagem, para usar o termo técnico preciso, é bullshit.

E fica a recomendação prática final. Se o seu projeto open source tem um CODE_OF_CONDUCT.md, delete o arquivo. Se o seu branch principal virou main na onda de 2020, renomeie de volta para master. Em parte de birra, admito. Mas principalmente para exercitar a liberdade recém-recuperada de fazer isso sem ser cancelado por causa disso. Liberdade que não se exercita atrofia. Sem nota de esclarecimento, sem votação de comitê, sem pedir licença para ninguém. Só porque agora você pode de novo.

Em julho eu publiquei Novidades no meu AI-MEMORY, onde mostrei o ai-memory run: trocar de Claude Code pra Codex sem perder a linha de trabalho. Naquele dia estávamos na versão 1.17.1.

Hoje saiu a 2.0. E dessa vez não vou repetir como os hooks funcionam nem como uma sessão vira página de wiki. Isso já está nos textos anteriores. Aqui eu quero falar de onde o ai-memory chegou frente à concorrência, o que a 2.0 traz e por que ela mereceu virar um “2”.

Se você nunca ouviu falar do projeto, o resumo é curto. O ai-memory é um servidor de memória de longo prazo pros seus agentes de código. Ele captura o que aconteceu na sessão, consolida em páginas Markdown e devolve o contexto certo pro próximo agente, seja qual for o harness ou a máquina.

Essa é a interface web que vem junto, boa pra auditar o que os agentes gravaram e pra navegar entre os projetos. Repare que cada projeto vive separado, com sua própria contagem de páginas, tudo saído das sessões de verdade.

Por que virou 2.0

Pra mim, o primeiro número de uma versão carrega um compromisso.

A família 1.x cresceu rápido demais. Saímos da 1.1 e chegamos na 1.39 em pouco mais de dois meses, empilhando funcionalidade atrás de funcionalidade em releases menores. Funcionou pra iterar, mas embaralhou o significado dos números.

A 2.0 arruma isso. Ela junta as poucas mudanças que quebram compatibilidade num único major, e a partir daqui o versionamento passa a seguir Semantic Versioning de verdade. Correção vira patch. Funcionalidade nova vira minor. Só quebra de formato ou de contrato vira major, e sempre com aviso. O novo guia de contribuição deixa essa regra explícita pra qualquer PR.

A quebra principal é o novo formato em disco. Na primeira vez que você sobe a 2.0, ela migra sua wiki sozinha. Antes de mexer em qualquer coisa, ela compacta todo o seu diretório de dados num backup verificado com data no nome. Se o backup não puder ser gravado e conferido, a migração aborta e o servidor se recusa a subir. Nada de “confia em mim”.

Esse é o aviso que aparece uma vez, depois da migração: ele diz onde ficou o backup, o tamanho do arquivo e como voltar atrás se algo parecer errado. Quando você confirma que está tudo certo, é só apagar o backup e o lembrete some.

OKF: sua memória não fica presa no ai-memory

Essa é a mudança que mais me deixou satisfeito.

A partir da 2.0 a wiki do ai-memory é, nativamente, um bundle no Open Knowledge Format, o formato aberto que o Google publicou em 2026. Cada página de memória é um arquivo OKF válido: Markdown comum com metadados padronizados. Não existe passo de exportação que gera uma cópia divergente. Os arquivos da wiki já são os arquivos OKF.

Na prática isso quer dizer que sua memória deixou de ser refém do meu projeto. Você pode ler tudo com grep, abrir no Obsidian, versionar no Git ou entregar o bundle pra um colega que usa outra ferramenta compatível com OKF. Tem até um ai-memory export-okf pra empacotar um projeto inteiro num tarball validado.

Sempre foi essa a tese: modelo e harness são alugados, a memória do projeto é sua. Agora o formato reforça isso por escrito.

Embeddings locais, ligados por padrão

Até a 1.x, busca semântica de verdade dependia de você configurar um provider de embeddings. Ou pagava uma API e mandava cada página e cada query pra fora, ou subia um Ollama do lado. As duas opções têm custo.

A 2.0 traz um provider local que roda o modelo de embeddings dentro do próprio processo, em Rust puro, com o all-MiniLM-L6-v2. Sem chave de API, sem servidor externo, sem GPU e sem mandar seus dados pra lugar nenhum. E agora vem ligado por padrão. Na primeira execução ele baixa o modelo (uns 87 MB, com checksum fixo) em background e liga a busca híbrida no próximo restart.

O ganho é mensurável. No benchmark LongMemEval-S, o hit@5 sobe de 0.617 só com full-text para 0.779 com os embeddings locais. Se por algum motivo você não quiser, um embedding_provider = "none" desliga.

Detalhe que importa: escolhi candle de propósito, em vez do runtime nativo que a concorrência usa. Foi justamente essa camada nativa que gerou um tipo de crash recorrente em outros projetos de memória. Preferi não herdar o problema.

Vários agentes ao mesmo tempo, no mesmo projeto

Aqui começa a parte que motivou boa parte do trabalho antes da 2.0.

O caso do ai-memory run que mostrei em julho era sequencial: fecho o Claude, abro o Codex, continuo. Mas e quando eu deixo dois ou três harnesses abertos ao mesmo tempo no mesmo projeto? Claude numa aba, Codex noutra, OpenCode numa terceira.

O ai-memory trata isso sem ninguém pisar no pé do outro. Cada chamada de memória descobre sozinha a qual projeto pertence, a partir do diretório da sessão. O ponteiro de “projeto atual” agora é por ator, então dois harnesses no mesmo checkout mantêm cada um a sua noção de contexto. E a identidade do projeto vem do nome do checkout. O caminho absoluto no disco não pesa, então o mesmo projeto no laptop e no desktop cai no mesmo lugar.

Quando duas janelas gravam na mesma página, a segunda não apaga a primeira. Ela cria uma versão nova que passa a ser a mais recente, e a anterior continua alcançável na cadeia de versões. Regravar algo idêntico não gera versão nova. Todas as escritas passam por um único writer, com fila e backpressure, então uma rajada não corrompe nada.

Isso não é teoria. Tem teste de aceitação chamando Claude, Codex, OpenCode, Pi, Crush e mais alguns de verdade, dentro de uma mesma workstream, cobrindo lease, adoção de sessão e entrega de contexto entre harnesses.

Um time inteiro no mesmo projeto

O segundo cenário é o que dá título ao post. Aqui já são várias pessoas, um time inteiro apontando os agentes pro mesmo servidor.

A forma de rodar é simples. Alguém sobe um servidor, normalmente um container num homelab ou numa máquina da rede, e cada pessoa aponta os agentes dela pra aquela URL. HTTPS entra na frente com um proxy reverso, se você quiser. O banco continua sendo um SQLite só.

Todo mundo enxerga as mesmas páginas do projeto. O que uma pessoa aprendeu numa sessão, o agente da outra recupera. E cada sessão nova recebe um briefing com o estado do projeto logo no início. Vou ser honesto com o termo “tempo real”. O que existe é um store central compartilhado, com leitura imediata, mais o briefing na abertura. A nota que um colega gravou aparece na hora pra próxima consulta ou próxima sessão de qualquer um. Uma sessão que já está rodando só recebe a novidade na consulta seguinte ou na próxima abertura, sem interrupção no meio.

O que muda no modo multiusuário é a atribuição. Cada escrita registra quem fez. Existe log de auditoria e a interface mostra “editado por fulano”. Isso já vem no pacote, de graça. E não existe permissão por página, de propósito. A atribuição serve pra registrar autoria; qualquer pessoa autenticada pode escrever, e o histórico é que guarda quem foi.

Tem uma distinção de segurança importante entre o que é compartilhado e o que é pessoal. As páginas são de todos. Mas o handoff é um bastão de um dono só: exatamente uma sessão pega, e um segundo accept não rouba o bastão de ninguém. O handoff que você deixou pendente não é entregue nem consumido por um colega. Do mesmo jeito, os “slots” de “no que estou trabalhando agora” são por pessoa, então o seu contexto pessoal não vaza no briefing do time inteiro.

Também existe uma bateria de testes de concorrência real cobrindo esses casos: escrita simultânea, isolamento por ator sob carga, o bastão do handoff que não é roubado e os slots pessoais que não vazam.

Onde o ai-memory fica frente à concorrência

Antes da 2.0 fizemos outra rodada de pesquisa sobre o cenário de 2026, documentada no repositório. Ela foi a base pra decidir o que a 2.0 precisava cobrir. Vou resumir o campo.

Tem o agentmemory, que é um MCP server em TypeScript preso a um sidecar nativo e a uma superfície gigante de dezenas de ferramentas. Tem o basic-memory, em Python, Markdown no disco, mas com captura manual: você tem que pedir pra ele lembrar. Tem o cognee, que junta grafo, vetor e relacional num pipeline pesado que pede vários gigas de RAM. Tem o MemPalace, que viralizou com quase 50 mil estrelas em duas semanas por causa de um número de benchmark que, auditado, se mostrou inflado, além de sofrer de corrupção quando duas escritas acontecem juntas. E tem os grafos temporais como Zep, os “memory OS” como Letta (o antigo MemGPT) e os extratores de fato como o Mem0.

Tem ainda a memória nativa que o próprio Claude Code passou a ligar por padrão. Essa eu trato como o funil que apresenta a categoria pras pessoas. Como concorrente ela fica limitada: presa a uma máquina, presa a um agente, sem busca de verdade e sem história de time.

A 2.0 fecha as lacunas que a pesquisa apontou. Passamos a publicar benchmark reproduzível com o LongMemEval, rodando o servidor de verdade. Ganhamos o formato aberto OKF. Ganhamos ligações tipadas entre páginas, com causes, fixes e contradicts, que ainda alimentam uma checagem de contradição sem gastar LLM. Ganhamos consulta com as_of, pra perguntar o que a gente sabia sobre um assunto numa certa data. Ganhamos os embeddings locais. E ganhamos uma passada opcional de “experiência” que revê várias sessões pra achar padrões que só aparecem no conjunto.

Agora a parte que interessa pra quem vai escolher. O que o ai-memory tem que os outros não têm, tudo junto:

• Ele te acompanha entre agentes. Mais de vinte harnesses alimentam uma memória só, e o handoff aqui é um protocolo de verdade: tipado, com dono e reivindicado uma vez só.
• Ele te acompanha entre máquinas. A memória vive num servidor que é seu. O projeto que você largou no desktop é o que você retoma no laptop.
• Ele funciona pra time. Autenticação multiusuário, atribuição por pessoa e log de auditoria já vêm no pacote, de graça.
• Sua memória é Markdown puro. A fonte da verdade é uma wiki versionada no Git. O banco é um índice derivado que dá pra reconstruir a qualquer momento a partir dos arquivos, sem vector store pra ficar de babá e sem nada preso num blob binário.
• Ele captura o trabalho sozinho e em silêncio. Sem cerimônia de “lembra disso”. E o caminho padrão roda com zero chamada de LLM.
• Ele é um binário só. Sem sidecar, sem três bancos pra sincronizar. Todas as escritas passam por um único writer, com um teto de escrita que a gente mediu de verdade, com teste real. Foi exatamente esse desenho que evitou a corrupção de escrita concorrente que derrubou os outros.

Nenhum concorrente entrega esse conjunto. Alguns têm um ou outro pedaço. O ai-memory tem o pacote, e agora com paridade nos itens onde antes ficava atrás.

A 2.0 é de todo mundo

Quando escrevi o post de julho, quinze pessoas tinham PR mergeado no projeto. Hoje são cerca de setenta. Faz tempo que isso deixou de ser um programinha de fim de semana.

Os números até a 2.0: mais de 1.500 commits, 371 pull requests mergeados e 181 issues fechadas. Isso saiu de gente usando de verdade e mandando correção, funcionalidade e documentação.

Preciso agradecer em especial ao Djalma Júnior, que sozinho passou de 50 PRs mergeados, e ao Samir Hanna Verza, com mais de 20. Logo atrás vêm lhzapata, pedrofjr, mrpaiva, lucasliet, lihuiyang1024, Murillofilho86 e Matheus Rodrigues. E tem uma cauda longa de dezenas de outras pessoas com PR mergeado que seria injusto tentar listar inteira aqui.

Se você quer entrar nessa, o guia de contribuição foi reescrito pra deixar tudo claro: como configurar o ambiente, os gates que o CI cobra, a regra do CHANGELOG e a política de versionamento. Bug fix costuma sair rápido no próximo patch. Funcionalidade pequena, como um novo harness ou provider, entra no próximo minor. Tem issue marcada pra quem está começando.

Como pegar a 2.0

A página do projeto tem todos os métodos de instalação, incluindo AUR, Homebrew e binários de release:

• ai-memory no GitHub
• Notas da release v2.0.0

Depois de atualizar, na primeira execução deixe a migração fazer o backup e converter sua wiki pro formato OKF. Se você usa o modo gerenciado, reinstale os hooks dos harnesses que pretende usar.

Conclusão

A 1.x provou que a ideia funcionava. A 2.0 é a versão que eu recomendaria sem asterisco pra outra pessoa botar num time.

O formato é aberto, então sua memória não fica presa. A busca semântica roda local, então você não paga nem vaza. Vários agentes e várias pessoas trabalham no mesmo projeto sem se atropelar. E o desenho de um binário só, com um writer só, é o que evita justamente os problemas que afundaram metade da concorrência.

LLM e assinatura eu continuo alugando de quem estiver melhor no mês. A memória do projeto fica comigo, com o time, e agora num formato que ninguém tira de mim.

Você paga pelo livro, mas só consegue ler onde a Amazon deixa. Não existe um aplicativo nativo decente pra Linux. Mudar pra outro leitor vira um exercício de arqueologia. Comprei um Xteink X4 novo e, claro, minha biblioteca não podia simplesmente ir junto. O arquivo estava “na minha conta”, mas não estava sob meu controle.

Durante anos, eu contornei isso pelo caminho oficial. Entrava no site da Amazon, usava Download & Transfer via USB, baixava o .azw dos livros que comprei e importava tudo no calibre. Com o plugin DeDRM configurado pro serial do meu Kindle, convertia pra EPUB e pronto.

Em 26 de fevereiro de 2025, a Amazon desativou essa opção. Sem anúncio decente, sem substituto que entregasse o arquivo e sem qualquer preocupação com quem queria manter um backup local. Desde então, meus livros mais novos ficaram presos no ecossistema deles. Voltei a tentar no ano passado, atualizei plugin, copiei arquivos do meu Kindle Paperwhite, coloquei o serial correto e nada.

Pra ser justo, em 20 de janeiro de 2026 a Amazon passou a permitir que compradores verificados baixem EPUB ou PDF quando o publisher confirma o livro como DRM-free. Ótimo. Só não resolve os livros protegidos, e a decisão continua nas mãos da editora. Títulos antigos sem DRM também precisam ser confirmados individualmente pelo publisher. Minha biblioteca não ganhou botão de download por causa disso.

Resolvi tentar de novo agora. A versão nova do DeDRM conseguiu lidar com o DRM atual, mas o processo mudou bastante. Dá trabalho, precisa de Windows numa das etapas e envolve uma ferramenta comunitária em pre-release. Funcionou. Recuperei 106 livros comprados, testei a conversão pra EPUB e agora posso ler no aparelho que eu quiser.

Este é o estado do jogo em 30 de julho de 2026 (atualizado em 19 de agosto). A Amazon pode mudar a criptografia ou o aplicativo amanhã. Não conte com tutorial antigo dizendo pra instalar Kindle for PC 1.17, desabilitar update e colocar o serial do aparelho no Calibre. Esse mundo já acabou.

E o óbvio precisa ser dito: estou falando dos livros que eu comprei. Não estou falando de baixar Kindle Unlimited, empréstimo de biblioteca ou livro dos outros. Leis sobre circumvention de DRM variam por país. Pesquise a legislação de onde mora e assuma responsabilidade pelo que faz.

Antes de tudo: não jogue Kindle velho fora

Amazon também não facilita reaproveitar Kindle antigo. O hardware continua bom, a bateria costuma ser substituível, a tela de e-ink dura uma eternidade, mas o software vai ficando cada vez mais fechado e limitado.

Pra quem quer ressuscitar esses aparelhos, recomendo o canal Dammit Jeff. Ele acompanha jailbreaks, KOReader, lojas alternativas e formas de manter Kindles úteis depois que a Amazon perde o interesse. Este vídeo sobre o AdBreak e os jailbreaks recentes é um bom começo. Leia também o guia atualizado do Kindle Modding antes de fazer qualquer coisa, porque firmware e método compatível mudam o tempo todo.

Jailbreak do aparelho e remoção de DRM do ebook são problemas diferentes. Você não precisa desbloquear o Kindle pra seguir o resto deste artigo. Estou mencionando porque ambos partem da mesma ideia: hardware e mídia que já pagamos deveriam continuar úteis sem pedir bênção eterna ao fabricante.

Crash course: AZW, EPUB e KFX

DRM e formato de arquivo não são a mesma coisa. O formato diz como texto, imagens, fontes, índice e metadados são empacotados. DRM adiciona uma trava criptográfica por cima e decide qual conta, aplicativo ou aparelho consegue abrir aquilo.

Os três nomes que importam aqui são:

A extensão sozinha pode enganar. Parte de um livro KFX pode aparecer como .azw, .azw.res, .voucher e outras variações. O plugin KFX Input existe justamente pra entender esse conjunto.

O EPUB é bem menos misterioso. A especificação EPUB 3.3 o define como um container de arquivo único pra conteúdo Web estruturado. É basicamente um pequeno site empacotado. Qualquer leitor minimamente decente consegue implementar suporte sem depender de uma chave secreta da Amazon.

Calibre e os dois plugins

calibre é o canivete suíço de ebooks. É software livre, roda em Linux, macOS e Windows, organiza biblioteca, baixa metadados, edita capas, transfere livros e converte dezenas de formatos. Existe desde 2006 e nasceu justamente porque o primeiro Sony Reader não funcionava direito no Linux.

No Omarchy ou qualquer Arch, basta instalar o pacote:

sudo pacman -S calibre

Em outras distribuições, veja o download oficial. Não invente de instalar um pacote aleatório de site de downloads.

Uma pegadinha específica de ambientes com mise: se o Calibre morrer com ModuleNotFoundError: msgpack ou BrokenPipeError, provavelmente um shim de Python entrou antes de /usr/bin. O pacote do Arch precisa do Python do sistema. Inicie assim:

env PATH="/usr/bin:$PATH" /usr/bin/python3 /usr/bin/calibre

Isso não tem relação com DRM nem com os plugins. É só o helper do Calibre chamando o Python errado. No meu desktop deixei um launcher permanente com esse PATH.

O Calibre sozinho não remove DRM. Precisamos de dois plugins:

1. DeDRM reconhece e remove as travas de vários ecossistemas durante a importação. Ele só roda quando o livro entra na biblioteca. Clicar em Convert depois não remove nada.
2. KFX Input entende os containers modernos da Amazon, reúne as partes de um livro e permite converter o resultado pra EPUB.

No momento deste artigo, estou usando DeDRM 10.0.28, publicado em 14 de julho no fork mantido por Satsuoni. É um pre-release. Baixe o asset chamado DeDRM_tools.zip, nunca um executável solto de algum mirror obscuro.

Atualização (agosto de 2026): o aplicativo do Kindle na Microsoft Store não para quieto, e cada versão nova dele exige uma versão nova da ferramenta. Desde a publicação deste artigo, o app saiu da 1.0.18632: a 10.0.29 adicionou suporte ao app 1.22326 e a 10.0.30 suporta o app 1.0.22920. A regra prática é uma só: o nome do executável carrega a versão do app que ele entende (MSIXKFXArchiverMobi1_22920.exe pra Store app 1.0.22920, e assim por diante). Antes de começar, confira sempre a página de releases do fork do Satsuoni e baixe o pre-release mais novo. Todo o resto do processo descrito aqui continua igual.

Eu descompactei tudo numa pasta que depois fica compartilhada com a VM Windows:

mkdir -p ~/Windows/Kindle-DeDRM/v10.0.28
unzip ~/Downloads/DeDRM_tools.zip -d ~/Windows/Kindle-DeDRM/v10.0.28

O SHA-256 do DeDRM_tools.zip que usei foi:

520cce704edf9ae26e43196efe2871daf9b25d6cb489aa56051626801c362947

Confira com sha256sum. Isso não transforma um binário comunitário em software magicamente seguro, mas pelo menos garante que está usando o mesmo arquivo que eu testei.

Dentro da pasta existe DeDRM_plugin.zip. Não descompacte esse segundo ZIP. No Calibre, abra Preferences → Plugins → Load plugin from file, escolha DeDRM_plugin.zip, aceite o aviso e reinicie o programa.

Depois volte em Preferences → Plugins → Get new plugins, procure por KFX Input e instale. Meu teste usou a versão 2.33.0. Reinicie de novo.

Por que copiar do Kindle pelo USB não resolveu

O caminho mais simples ainda seria ligar meu Kindle Paperwhite novo no cabo, copiar o livro e configurar o serial do aparelho no DeDRM. Foi o primeiro teste que fiz.

O arquivo entrou como KFX-ZIP, o plugin rodou, mas continuou criptografado. Abri o Calibre em debug e o log mostrou que esse livro usava a estratégia ACCOUNT_SECRET. O serial estava certo. O problema é que a chave necessária não vinha mais apenas do aparelho.

É por isso que muita gente segue tutorial antigo, tenta cinco serial numbers diferentes e conclui que o DeDRM está quebrado. Pra livros novos com esse DRM, precisamos do segredo que o aplicativo Kindle atual guarda no Windows. E esse segredo é protegido pelas APIs do TPM.

Um Windows descartável dentro do Omarchy

Eu não vou manter dual boot só pra baixar ebook. Também não vou fingir que Wine roda tudo. Felizmente, o Omarchy já vem preparado pra instalar e abrir uma VM Windows: ela aparece no próprio menu do sistema, abre por RDP e compartilha ~/Windows automaticamente com o guest. Não precisei montar essa integração do zero.

Por baixo, ele usa o dockur/windows. O dockur empacota QEMU/KVM num container e automatiza a instalação do Windows. Continua sendo uma máquina virtual de verdade, com disco e kernel próprios. O container só organiza a distribuição, configuração e ciclo de vida.

Pra instalar pelo terminal, rode:

omarchy-windows-vm install

Escolha RAM, CPUs e tamanho do disco. O instalador cria ~/.config/windows/docker-compose.yml, guarda o disco virtual em ~/.windows e compartilha ~/Windows com o guest. Dentro do Windows, essa pasta aparece como Shared, normalmente em Z:, e também fica acessível por \\host.lan\Data.

O detalhe que fez diferença no meu caso foi habilitar TPM 2.0. Edite o Compose gerado e acrescente TPM: "Y" no bloco environment:

services:
  windows:
    image: dockurr/windows
    environment:
      VERSION: "11"
      TPM: "Y"

Depois recrie o container. O disco do Windows continua no volume persistente:

omarchy-windows-vm stop
omarchy-windows-vm launch -k

O -k deixa a VM ligada quando você fechar o RDP. Também dá pra acompanhar pelo navegador em http://127.0.0.1:8006.

Baixando os livros pelo aplicativo certo

Dentro do Windows, abra a Microsoft Store e instale Amazon Kindle: Reading App, produto 9P8JQ0JJSTLL.

Preste atenção aqui. O instalador antigo de Kindle for PC encontrado em blogs não é o mesmo aplicativo. A ferramenta que usei procura o pacote AMZNKindle.AmazonKindleReadingApp da Microsoft Store. Com o programa legado, ela simplesmente responde No AmazonKindleReadingApp installation found.

Entre na sua conta e mande baixar localmente cada livro que quer preservar. Abrir a capa ou ver o título na biblioteca não basta. O conteúdo precisa estar disponível offline dentro do app.

Infelizmente, a parte mais chata continua manual. A Amazon sabe colocar botão de compra com um clique, mas não achou espaço pra um “baixe tudo que eu já paguei”.

Eu fiz isso em 106 livros. Sim, foi um saco.

Gerando os KFX-ZIP e a chave K4I

O DeDRM_tools.zip que descompactamos no Linux já está visível no Windows por causa da pasta compartilhada. Abra PowerShell e entre nela:

cd \\host.lan\Data\Kindle-DeDRM\v10.0.28
.\MSIXKFXArchiverMobi1_18632.exe

O banner ainda pode mencionar uma build antiga 1.0.15230. O executável versionado acima procura a Store app 1.0.18632 e foi o que funcionou comigo. O número no nome do arquivo precisa bater com a versão do seu app: se a Store já te entregou uma versão mais nova, baixe a release correspondente na página do projeto (veja a atualização na seção dos plugins).

Esse executável localiza o cache da versão atual da Microsoft Store, reúne os componentes de cada livro e gera duas coisas:

• archived_kfx/, com um .kfx-zip pra cada ebook baixado;
• oldbooks.k4i, o keyfile que o DeDRM precisa pra abrir aqueles arquivos.

Na minha máquina, o processo encontrou e arquivou 106 livros. O SHA-256 do executável que rodei foi:

0c78b45ccea2c36a5fbb01b9f66bdd9e5d5960a68a340ba2ee96e138f5cddf4a

Ele é um binário de 32 bits. Se reclamar que falta MSVCP140.dll, instale o Microsoft Visual C++ Redistributable x86 oficial. Não procure DLL avulsa no Google. Esse é um ótimo jeito de transformar backup de livro em backup de malware.

O oldbooks.k4i é sensível. Ele deriva do segredo da sua conta naquela instalação do Kindle. Não publique, não mande em issue do GitHub, não tire screenshot do conteúdo e não coloque em repositório aberto.

Configurando a chave no DeDRM

De volta ao Linux, abra o Calibre e siga:

Preferences → Plugins → DeDRM → Customize plugin → Kindle for Mac/PC ebooks → Import Existing Keyfiles

Selecione:

~/Windows/Kindle-DeDRM/v10.0.28/oldbooks.k4i

Use Import Existing Keyfiles. Não use o botão genérico Set Keyfile da tela principal. Ele grava outro tipo de candidato e não cadastra a chave K4I no lugar certo.

Feche a lista de chaves, clique em OK na configuração principal e reinicie o Calibre. Se fechar com Cancel, ele joga a alteração fora sem cerimônia.

Importando e convertendo pra EPUB

Antes de despejar cem arquivos na biblioteca, teste um.

Escolha um .kfx-zip dentro de:

~/Windows/Kindle-DeDRM/v10.0.28/archived_kfx/

Use Add books no Calibre. A ordem interna é esta:

1. KFX Input reconhece o pacote;
2. DeDRM tenta as chaves K4I durante a importação;
3. KFX Input monta o livro descriptografado como KFX;
4. Calibre passa a conseguir abrir e converter o resultado.

Se o formato continuar aparecendo como KFX-ZIP, deu errado. Não adianta apertar Convert dez vezes. Remova aquela entrada da biblioteca, corrija plugin ou chave e importe de novo. DeDRM só atua na entrada.

Quando o livro aparecer como KFX, abra no viewer e confira algumas páginas. Depois clique em Convert books, escolha EPUB como saída e teste o arquivo resultante no leitor onde pretende usar. Só depois disso faça a importação em lote.

No meu caso, o KFX abriu, converteu e o EPUB funcionou fora do Kindle. Com isso eu sabia que o caminho inteiro estava funcionando: Microsoft Store, TPM, archiver, K4I, DeDRM 10.0.28 e KFX Input 2.33.0.

Faça backup do que realmente importa

Depois da conversão, eu preservo três coisas:

• os EPUBs finais, que leio em qualquer aparelho;
• os KFX-ZIP originais, até conferir que todos os EPUBs estão íntegros;
• o oldbooks.k4i, criptografado e separado da biblioteca.

Meu keyfile em texto puro fica com permissão 0600. Também mantenho uma cópia criptografada com SOPS e age, enquanto a chave privada fica em outro backup. Não coloque oldbooks.k4i cru no Git só porque o repositório é privado. Repositório privado vaza também.

Os EPUBs entram na mesma estratégia que uso pros outros arquivos importantes: cópia local, NAS e backup off-site. Já expliquei essa paranoia em Protegendo e Recuperando Dados Perdidos e mostrei a mesma filosofia aplicada a filmes no meu Netflix Pessoal.

Não apague os arquivos do Kindle ou da VM no minuto em que a conversão termina. Abra os EPUBs, veja capa, índice, imagens, notas e algumas páginas. Backup que nunca foi testado é só torcida organizada.

Conclusão

Amazon já apagou livros remotamente, editoras atualizam capas e conteúdo, aplicativos antigos param de funcionar e formatos mudam. O próprio fim do download via USB mostrou que uma função disponível por dezoito anos pode desaparecer com uma linha num aviso.

O exemplo clássico continua inacreditável: em 2009 a Amazon apagou 1984 e Animal Farm, de George Orwell, dos Kindles de clientes. Depois vieram revisões de Roald Dahl, R.L. Stine e Agatha Christie empurradas pra cópias digitais que já tinham sido compradas. O artigo da Vice resume esses casos. O Dammit Jeff também bate muito nessa tecla: até a capa original que você escolheu pode virar pôster feio da adaptação do streaming porque publisher e loja decidiram atualizar sua “compra”.

Não importa se a alteração futura é censura, correção legítima, nova capa horrorosa de adaptação da Netflix ou apenas um bug. Eu comprei uma edição. Quero preservar a edição que comprei.

DRM não impede pirataria. Livro popular aparece em torrent no dia do lançamento. DRM só atrapalha o cliente que pagou, dificulta acessibilidade, prende hardware ainda bom e transforma uma compra em aluguel por prazo indefinido.

Calibre, DeDRM, KFX Input e uma VM descartável devolveram minha biblioteca. Agora posso colocar os EPUBs no Xteink, num Kobo, num tablet, no celular ou num leitor que ainda nem existe. Posso trocar de sistema operacional e posso desligar a internet. Os arquivos continuam comigo.

Se não está na sua máquina, não é seu.

O padrão se repete em todos: eu esbarro numa pequena fricção do cotidiano, daquelas que a gente normalmente engole porque consertar custaria um fim de semana inteiro, e em vez de engolir eu abro um agente de IA e resolvo. O custo de transformar irritação em ferramenta despencou tanto que o cálculo inverteu. Hoje vale a pena consertar quase tudo.

Tudo que aparece abaixo está no meu GitHub, com binários, releases e instruções de instalação.

Nesse post: clock-tui (com os widgets google-calendar-tui e ghpending), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming e aitrepreneur-docker.

clock-tui: um relógio de mesa que virou painel

O caso de uso é simples: eu tenho um monitor secundário vertical, e queria algo mais útil ali do que um wallpaper, alguma coisa que eu pudesse só bater o olho e ter informação relevante. Mas tudo começou porque eu só queria um relógio de mesa. Achei um programinha open source antigo de relógio em terminal, o clock-tui original, que estava parado havia tempos, e decidi fazer um fork e continuar o trabalho: o clock-tui.

Deixei ele mais bonito, modernizei as dependências de Rust, e a mudança mais importante: adicionei suporte a widgets de comando. O relógio fica no topo e embaixo entram painéis que rodam qualquer comando que imprima texto, cada um com refresh independente. Dois widgets que eu mesmo criei pra ele:

• google-calendar-tui: uma agenda read-only do Google Calendar no terminal, usando as contas que já estão no GNOME Online Accounts (zero configuração de OAuth). Bato o olho e sei meus compromissos do dia.
• ghpending: lista issues e pull requests abertos em todos os repositórios que eu acompanho. Agora que eu tenho dezenas de projetos open source, é assim que eu percebo em segundos quando chega PR ou issue nova, sem abrir o GitHub.

E hoje eu passei o dia adicionando suporte a temas, porque alguém no X comentou que o visual dava pra lembrar Evangelion. Desafio aceito: agora tem o tema evangelion (roxo e lavanda) e o tema nerv (vermelho, âmbar e verde, inspirado nas telas de alerta da série), alternando em runtime com Shift+T. O tema é injetado nos widgets via variável de ambiente, então os painéis acompanham a paleta.

Instalação no Arch: yay -S clock-tui-bin. Os widgets: yay -S ghpending-bin (também tem brew install via akitaonrails/tap no macOS) e yay -S google-calendar-tui-bin. Todos têm binários prontos nas releases do GitHub pra quem não usa Arch.

github-visualize: inútil, mas bonito

Esse nasceu por causa do artigo do Jarred Sumner sobre reescrever o TypeScript do Bun em Rust, sobre o qual eu postei recentemente. Não sei qual ferramenta ele usou pra ilustrar o post, mas eu gostei demais das animações dos gráficos. É inútil? É. Mas é bonito, e beleza é motivo suficiente pra fazer uma cópia.

O github-visualize é um dashboard self-hosted que monitora meus repositórios do GitHub e faz replay do progresso deles com visualizações animadas: timeline de commits com linhas adicionadas e deletadas em escala logarítmica, heat map de commits por dia e hora, corrida de CI até o verde. Agora eu adiciono qualquer repositório meu e tenho visualizações bonitas de produtividade, atividade, commits e builds. Talvez eu use em slides de apresentação, ou pra ilustrar posts futuros aqui no blog.

Instalação: imagem pública no Docker Hub como akitaonrails/github-visualize, container único com SQLite num volume, sem banco externo nem Redis.

Frank Geary: email do jeito que eu queria

Eu decidi usar o Geary, do GNOME, como meu cliente de email principal. É o que chega mais perto da interface do Mail padrão da Apple: limpo, direto, sem cerimônia. Eu sei, existe o Thunderbird, mas eu o acho inchado e muito feio. Existe o Mailspring, que eu acho inchado e pesado. Meu fluxo de email é curto: varrer a inbox, taggear, arquivar e responder. Nada além disso.

O Geary é quase perfeito, mas tinha dois problemas grandes pra mim. Primeiro: no meu monitor vertical, sobra muito menos espaço horizontal, e o Geary tem 3 colunas fixas. A primeira coluna, que só lista contas e pastas/tags, eu não preciso ver o tempo todo, mas não existia jeito de recolher.

Segundo, e mais grave: o campo de destinatário do compositor na prática não autocompletava nada (o Geary até tem o mecanismo, mas com um filtro de visibilidade de contatos tão restritivo que nunca sugeria ninguém). Eu tinha que digitar o endereço na mão ou copiar e colar de outro email. Em 2026.

Minha primeira solução foram dois módulos GTK externos injetados no Geary, um pra cada problema (ambos obsoletos agora). Funcionavam, mas exigiam instalar o Geary compilado do source, e a cada yay -Syu lá ia ele recompilar tudo de novo.

Cansei e fiz o que deveria ter feito desde o início: forkei o Geary e criei o Frank Geary, que adiciona as duas funcionalidades direto no código. A barra lateral agora recolhe, e o destinatário autocompleta consultando os contatos dos emails existentes. Vou manter o fork rebaseando do upstream com frequência.

E a melhor parte: agora tem pacote no AUR, então instalar é assim:

yay -S frank-geary-bin    # binário pronto (x86_64), da release do GitHub
yay -S frank-geary        # ou compilando do source

Os dois pacotes substituem o geary do sistema (fazem provide/conflict nele), então a troca é limpa e as atualizações chegam como qualquer outro pacote. Um detalhe depois de instalar ou atualizar: quando a opção de vigiar email novo está ligada, o Geary continua rodando em background como serviço D-Bus, então roda um geary --quit pra garantir que nenhum processo antigo ficou no ar.

Mangá em japonês: FrankYomik, FRANK MANGA+ e FRANK Scanlation

Quem acompanha o blog sabe do meu amor por mangá japonês. Eu já postei sobre o FrankYomik, que nasceu pra eu conseguir ler os mangás originais em japonês que eu compro na Amazon do Japão.

O problema: mangá voltado pra público adulto (não, não é pornô! estou falando de temas como negócios ou assuntos militares) não tem “furigana”, que são as legendinhas em kana impressas ao lado dos kanji difíceis, indicando a leitura. Mangá shounen tem furigana em tudo, então dá pra ler com vocabulário de estudante. Os adultos assumem que você já sabe ler os kanji raros. Eu não sei.

O FrankYomik resolve isso adicionando furigana em cima da página, em tempo real: um modelo detecta os balões de fala, o manga-ocr extrai o texto e o furigana (ou uma tradução completa, via LLM local no Ollama) é renderizado por cima, tudo rodando no meu próprio hardware. E o detalhe importante: on-the-fly, por cima da imagem que eu já tenho aberto legitimamente, sem baixar nem redistribuir página nenhuma, então sem infringir copyright ou licença.

Depois veio o FRANK MANGA+, sobre o qual eu também já postei. Eu pago a assinatura do Manga Plus, o app oficial da Shueisha, mas ele só deixa ler no celular (Android/iOS). Num tablet pequeno até vai, mas eu tenho um monitor Samsung Odyssey OLED de 32" parado na minha frente.

Descobri como usar a minha própria assinatura fora do app e construí um leitor desktop em Tauri: roda em Linux, macOS e Windows, o tier gratuito funciona direto e assinante cola o próprio secret pra liberar os capítulos premium.

Instalação: AppImage, .deb e .dmg nas releases, ou yay -S mangaplus-reader-bin no Arch.

E finalmente, eu também leio as eventuais “scanlations” da comunidade: fãs escaneiam as páginas do mangá original japonês e traduzem (hoje em dia a maioria usa IA no processo, existem até modelos treinados pra reconhecer os balões de fala, e eu usei um desses no próprio FrankYomik). Essas scanlations ficam espalhadas por vários sites diferentes, tipo o MangaDex.

Primeiro eu fiz uma extensão de Chrome pra embelezar esses sites (hoje obsoleta), mas cansei de viver com dezenas de abas no Brave só pra sites de scanlation. Então construí o FRANK Scanlation, na mesma linha do FRANK MANGA+: um app desktop que concentra todas as minhas scanlations favoritas num lugar só, com biblioteca, progresso de leitura por título e checagem de capítulos novos.

As janelas de leitura carregam o próprio site e injetam um leitor decente por cima, com spreads de página dupla e navegação por teclado. Nada é hardcoded pra site nenhum: são heurísticas que detectam sequências de imagens e numeração de capítulos em qualquer URL. Virou meu jeito preferido de ler os mangás que não existem pra comprar na Amazon nem na Shueisha.

Instalação: AppImage, .deb e .rpm (e build de macOS) nas releases do GitHub.

Frank Lyrics: decorando música linha por linha

Eu já postei sobre o Frank Karaoke, um appzinho pra adicionar pontuação em cima do YouTube e curtir karaokê com família e amigos. Mas tem um caso de uso irmão: eu gosto de aprender música nova (abertura de anime nova, por exemplo), e o processo de decorar letra é repetir a MESMA linha várias vezes. No player do YouTube isso é um inferno: fica caçando no dedo o ponto exato da timeline pra voltar, erra por dois segundos, volta demais, passa do ponto.

Pra resolver isso criei o Frank Lyrics, uma extensão de Chrome simples que descobre o timing correto de cada linha da letra usando os marcadores públicos do LRCLIB e injeta controles na própria página do YouTube. O LRCLIB, pra quem não conhece, é uma biblioteca aberta e comunitária de letras sincronizadas: cada linha vem com timestamp (o formato LRC clássico dos players de música), com API pública, gratuita e sem chave.

A extensão casa esses timestamps com o vídeo e me dá botões de repetir a linha exata que eu estou decorando, quantas vezes eu precisar, sem caçar timeline. Se você curte karaokê, o combo Frank Karaoke + Frank Lyrics deve te atender bem.

Instalação: baixa o .zip das releases, descompacta, abre chrome://extensions, liga o modo desenvolvedor e faz “Load unpacked” apontando pra pasta.

Frank Type: treino de digitação com prosa de verdade

Quem me acompanha há tempo sabe que eu amo meus teclados. Tem vídeos no canal Akitando sobre isso e posts aqui no blog sobre meus teclados favoritos. E de tempos em tempos eu gosto de treinar no MonkeyType. Mas eu não gosto de digitar palavras aleatórias. O TypeRacer resolve isso usando textos públicos de verdade, só que ele me obriga a esperar outros jogadores na sala (eu detesto jogos multiplayer). Ou seja: eu queria uma experiência single player, com prosa de verdade, mas com a estética do MonkeyType, que eu prefiro.

Então criei o Frank Type, um mini-clone dos dois: um treinador de digitação em Rails 8 que usa trechos normalizados de prosa em domínio público em vez de listas de palavras aleatórias. É local-first e sem cadastro: histórico de sessões, tempos e gráficos de perfil ficam no local storage do navegador. Tem até heat map de dígrafos pra mostrar quais combinações de teclas te atrasam.

Instalação: é um container Docker publicado como akitaonrails/frank_type. Um comando levanta em http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: uma biblioteca de como instalar jogos no Linux

Eu jogo no mesmo PC em que trabalho, mas me recuso a misturar pacote de emulador e gambiarra de Wine com meu ambiente de desenvolvimento. A solução foi isolar os jogos inteiros dentro de um distrobox (containers que se integram ao desktop como se fossem nativos), e o distrobox-gaming é o repositório de playbooks Ansible que constrói essa box Arch do zero: ES-DE de frontend, emuladores standalone, cores do RetroArch, configs por jogo. Meu Arch/Omarchy host fica limpo.

A regra que eu me impus: todo jogo novo que eu instalo tem que virar receita Ansible reproduzível. Confesso que ainda não testei a reconstrução completa do zero, mas a ideia é essa: qualquer truque ou hack necessário fica documentado no código em vez de perdido no histórico do shell.

E truque é o que não falta, porque eu ando instalando abandonware antigo: a série Colin McRae Rally (da versão de PS1 com patch de 60 fps até o DiRT de 2007), Sega Rally Revo, OutRun 2006 Coast 2 Coast, entre outros. Cada um com suas manhas de Wine, seus patches e suas configurações. Sem querer, o repositório está virando uma biblioteca de documentação sobre como instalar jogos, emuladores e retro games no Linux.

Na mesma linha existe o distrobox-llm, que faz o mesmo isolamento pro meu ambiente de LLMs locais (CUDA, Ollama, LM Studio e companhia), deixando só o driver NVIDIA no host.

Instalação: clona o repositório e roda os playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI sem sujar o sistema

Pra geração de imagens eu gosto do ComfyUI, e postei sobre ele ano passado. Eu acompanho um youtuber chamado Aitrepreneur que mantém uma página no Patreon com receitas pra instalar e configurar o ComfyUI com os modelos e workflows mais recentes. O trabalho de curadoria dele é ótimo, mas as receitas são scripts .sh old school, pensados pra rodar one-shot numa instância do RunPod, por exemplo.

Agora que as LLMs evoluíram a ponto de escreverem Dockerfiles decentes, criei o aitrepreneur-docker, que converte esses scripts em imagens e containers Docker de verdade: versões pinadas, dados persistentes no host ou NAS, um comando pra subir ou atualizar cada app. Assim eu rodo tudo isolado na minha máquina, sem entulhar meu Linux com toneladas de pacotes Python e gambiarras que poderiam desestabilizar o sistema.

Dois avisos importantes. O crédito da seleção de stack, curadoria de modelos e workflows é todo do Aitrepreneur: o repositório só traduz o trabalho dele pra forma de Docker, e os scripts originais dele são conteúdo pago do Patreon que NÃO está incluído.

Se achar útil, assine o Patreon dele pra contribuir com a criação de conteúdo (é lá que você pega os arquivos originais). E o repositório não cobre tudo que ele já produziu, só as receitas mais recentes.

Instalação: git clone, make setup (cria o .env pra você colocar seu token da Hugging Face), make build e make up.

E tem mais de onde vieram esses

Se você é novo por aqui: isso é só a leva que ainda não tinha aparecido no blog. Tem muito mais projeto que eu já cobri em posts dedicados. O ai-memory é o mais popular, mais usado e com mais contribuições de todos. O ai-jail, que apareceu de novo no post de ontem sobre agentes destrutivos, foi o primeiro da série e é o segundo mais popular.

E tem os outros da série Frank (“Frank” em homenagem ao Frank Rosenblatt, criador do perceptron, a rede neural original; o nome marca os projetos experimentais que eu faço por diversão):

• Frank Sherlock: indexador inteligente de imagens
• Frank Mega: clone do MEGA pro meu home server
• FrankMD: editor de markdown
• Frank FBI: analisador de fraudes por email
• Frank Investigator: ensina a questionar notícias

Tudo é open source e está no meu GitHub. Todo mundo é bem-vindo pra contribuir com issues, pull requests, ou simplesmente compartilhando com os amigos. Cada um desses projetos nasceu de um probleminha real meu. Vai que um deles resolve o seu também.

Essa semana apareceu uma controvérsia curiosa no mundinho de LLM de código aberto: a Rio 3.5 Open 397B, apresentada pela Prefeitura do Rio/IplanRIO no anúncio da plataforma Rio 3 Open como modelo aberto.

A acusação: na prática, o checkpoint publicado, ou seja, o arquivo de pesos do modelo, teria sido uma mistura direta do Nex-N2-Pro com o Qwen3.5-397B-A17B, sem crédito inicial à Nex.

O título do post tem interrogação de propósito. “Plágio” é uma palavra pesada, especialmente quando estamos falando de modelo sob licença permissiva. A pergunta correta não é só “pode usar?”. Em código aberto, quase sempre pode. A pergunta é: usou, modificou, redistribuiu e deu crédito corretamente? E, no caso de modelo de IA, tem outra pergunta tão importante quanto: foi transparente sobre o que de fato foi feito?

Minha conclusão curta, antes do textão: a evidência pública da Nex é forte. Forte o bastante pra dizer que o checkpoint inicialmente publicado da Rio 3.5 parece ter sido uma mescla quase linear de Nex-N2-Pro e Qwen3.5-397B-A17B.

A própria README da Rio foi alterada depois da issue da Nex para reconhecer Nex + Qwen e dizer que houve um “envio incorreto”.

Eu não reproduzi a análise tensor a tensor. Estou avaliando a evidência publicada pela Nex, o histórico público do Hugging Face e os testes que eu rodei separadamente no meu benchmark.

Isso não prova, juridicamente, “plágio” no sentido clássico. Mas mostra uma falha feia de atribuição e comunicação. E pra projeto público, com prefeitura, isso pesa mais.

O que a Prefeitura do Rio anunciou

Em abril, a Prefeitura publicou uma notícia dizendo que a IplanRio apresentou a plataforma Rio 3 Open, “uma família de seis modelos de inteligência artificial de ponta totalmente gratuita e aberta”.

O texto oficial dizia que a ideia era colocar o Rio como polo de inovação pública, capaz de desenvolver soluções próprias de IA “sem depender de plataformas estrangeiras”. Também destacava licença MIT, uso livre, modificação e até lucro sobre a tecnologia. Fonte: Prefeitura do Rio, 02/04/2026.

Uma reportagem do Mobile Time deu mais contexto: a família seria desenvolvida a partir do Qwen, modelo chinês da Alibaba.

O próprio João Cabaretta, presidente da IplanRio, teria dito: “O que fizemos foi pegar o modelo Qwen, já pronto, e a partir dele modificamos o modelo.” A reportagem também citava usos esperados na prefeitura: ler câmeras de segurança em busca de atividades suspeitas, analisar documentos de prestação de contas, gerar imagens e vídeos institucionais e atendimento ao cidadão.

Até aqui, nada absurdo. Pegar um modelo aberto e adaptar pra uso local é exatamente o que muita gente faz. Se a prefeitura conseguiu montar infraestrutura, adaptar modelo, documentar, publicar pesos, isso é bom. Eu sou a favor. Prefiro isso a mais um contrato fechado com SaaS estrangeiro que ninguém audita.

O problema começa na forma como a Rio 3.5 foi apresentada.

No Hugging Face, o repositório prefeitura-rio/Rio-3.5-Open-397B inicialmente dizia que o modelo era “developed by IplanRIO”, “Post-trained from Qwen 3.5 397B”, com MIT License e agradecimentos ao Qwen Team e ao SwiReasoning. Essa versão antiga ainda está acessível no histórico do Hugging Face: README antes da correção.

O card também prometia um modelo generalista de fronteira, com 397B parâmetros totais / 17B ativos, janela de contexto de 1.010.000 tokens e uso comercial/pesquisa liberado sob MIT. Ou seja: não era uma nota lateral. Era um lançamento com ambição alta.

Repara no detalhe: Qwen aparecia como base. A Nex, não.

E isso importa porque, na própria discussão da Nex, alguém corrigiu a narrativa dizendo que a Rio já creditava Qwen desde cedo. Está certo: o segundo commit do card do modelo já colocava base_model: Qwen/Qwen3.5-397B-A17B. Um comentário na issue também aponta isso: “They did say Qwen 3.5 397B was the base model from the beginning…”.

Então a acusação mais forte não é “omitiram Qwen”. É: creditaram Qwen, mas omitiram Nex-N2-Pro, justamente o componente que a análise de pesos da Nex diz ser majoritário na receita publicada.

Depois da issue aberta pela Nex, a README atual passou a dizer outra coisa:

“O modelo foi construído por meio de uma mescla de https://huggingface.co/nex-agi/Nex-N2-Pro e https://huggingface.co/Qwen/Qwen3.5-397B-A17B, seguida por On-Policy Distillation a partir de um modelo mais forte. Detectamos um envio incorreto na versão anterior, em que a versão base mesclada foi enviada em vez do modelo final destilado. Pedimos desculpas pela confusão.”

Fonte: README atual da Rio 3.5, alterada no commit a778c1e.

Essa frase muda bastante a história. Antes: “pós-treinado a partir do Qwen”. Depois: “mescla de Nex-N2-Pro e Qwen, seguida por destilação, mas subimos o arquivo errado”.

Pode ser verdade. Pode ter havido mesmo um envio errado. Mas, como observador externo, eu só consigo analisar o que foi publicado.

A acusação da Nex

A Nex abriu a issue nex-agi/Nex-N2#4 em 14 de junho. Em tradução/resumo meu, a acusação principal é direta:

prefeitura-rio/Rio-3.5-Open-397B é apresentado como um modelo original de 397B treinado pela IplanRIO. Não é. Seus pesos são uma mescla direta, elemento a elemento, do nosso modelo, Nex, com a base oficial Qwen3.5-397B-A17B — cerca de 0,6 Nex / 0,4 Qwen — e não encontramos evidência de treino próprio deles.

A Nex aponta duas evidências.

Primeira: comportamento de identidade. Segundo eles, o serviço da Rio usava um prompt de sistema embutido dizendo “You are Rio”. Removido esse prompt, eles fizeram 120 perguntas de identidade. O resultado reportado foi:

• “Nex”: 95/120, ou 79,2%.
• “Nex-AGI”: 88/120, ou 73,3%.
• “Rio”: 0/120.

Exemplo de resposta citado pela Nex:

“Eu sou Nex, da Nex-AGI. A Nex-AGI é uma aliança de ecossistema de modelos grandes, construída em conjunto pelo Shanghai Innovation Institute…”

Fonte: comentário da Nex sobre identidade.

Isso sozinho não prova tudo. Modelo se identificar como outro pode acontecer por contaminação de conjunto de dados, prompt de sistema, prompt de teste malfeito, ajuste fino reaproveitado. Mas é um sinal ruim quando o modelo supostamente “Rio” nunca diz “Rio” sem máscara e diz “Nex” com frequência alta.

A segunda evidência é mais séria: análise de pesos.

A hipótese da Nex é simples. Se Rio = α·Nex + (1−α)·Qwen, então, para cada tensor:

(Rio − Qwen) ≈ α · (Nex − Qwen)

Eles reportam valores muito consistentes: experts roteados com α ≈ 0,571 ± 0,0016 e cos_fit 0,993; lm_head com 0,574 e 0,991; atenção por volta de 0,585 e 0,986; projeções de atenção linear por volta de 0,586 e 0,984. Fonte: comentário da Nex sobre análise de pesos.

Essa é a parte que mais pesa. Similaridade alta entre modelos da mesma família não seria surpresa. Mas colinearidade tensor a tensor nesse nível é outra coisa. Se a conta reproduz em todos os tensores, não parece “treinamos algo parecido”. Parece mescla.

O ponto fraco: até alguém reproduzir independentemente, isso continua sendo uma análise apresentada pela parte interessada. O ponto forte: é uma análise técnica falsificável, não só print de chat.

O tweet da Nex

O tweet da Nex resume a acusação em tom de meme:

“O modelo Rio 3.5 quebrou a internet esta semana. A reviravolta? Ele é essencialmente nosso modelo de código aberto, Nex N2 Pro, usando outro chapéu.”

E continua:

“Analisamos os pesos, e a receita é exata: Rio 3.5 ≈ 0,6 * Nex N2 Pro + 0,4 * Qwen 3.5”

Também repete a parte de identidade:

“Ele literalmente se apresenta como ‘Nex N2 Pro’ se você perguntar sem prompt de sistema inicial!”

E fecha com a frase mais importante:

“Mas, no mundo do código aberto, atribuição importa.”

É isso. A parte mais importante não é “usaram nosso modelo”. Modelo de código aberto existe pra ser usado. Se a análise estiver correta, a reclamação é: teriam usado, se beneficiado da performance herdada, anunciado resultados, mas só dado o crédito depois que a Nex expôs a mistura.

Mas o que é Nex-N2-Pro?

Antes de continuar, vale explicar quem é a Nex nessa história, porque ela também não surgiu do vácuo.

No model card oficial, a Nex descreve o Nex-N2 como “an agentic model with Agentic Thinking”.

Marketing à parte, a promessa é clara: não ser só um modelo bom de chat, mas um modelo ajustado pra tarefas longas de agente. Programação, chamada de ferramentas, execução no terminal. Esse tipo de fluxo chato em que o modelo precisa planejar, executar, ver feedback do ambiente, corrigir e iterar.

E sim: ele também é baseado em Qwen. O próprio card diz que os dois modelos da família foram pós-treinados em cima da série Qwen3.5:

• Nex-N2-Pro: construído sobre Qwen3.5-397B-A17B.
• Nex-N2-mini: construído sobre Qwen3.5-35B-A3B-Base.

Então a Nex não está dizendo “criamos uma arquitetura base do zero”. Ela está dizendo: pegamos Qwen como base e fizemos um pós-treino voltado a agentes em cima. A diferença prometida está nesse pós-treino.

Eles chamam o framework de Agentic Thinking, dividido em duas ideias:

• Adaptive Thinking: o modelo decide quando pensar pouco e agir rápido, ou quando gastar mais raciocínio em decisões críticas.
• Coherent Thinking: manter um paradigma de raciocínio consistente entre tarefas gerais, programação e tarefas de agente, em vez de tratar raciocínio, uso de ferramentas e execução como ilhas separadas.

Também há detalhes práticos: recomendam um fork customizado do sglang, usam reasoning-parser qwen3, tool-call-parser qwen3_coder, falam em suporte robusto a chamada de funções e listam testes de agente/programação onde o Nex-N2-Pro ficaria perto de modelos proprietários como GPT-5.5 e Opus 4.7.

Claro, teste de fornecedor sempre precisa de sal. Mas a tese é essa: Qwen cru é a base; Nex é o pós-treino e empacotamento de agente que deveria transformar essa base num modelo melhor pra trabalho real de agente.

Isso bate com meu benchmark independente. O Qwen3.5-397B-A17B base foi mal, 42/C. O Nex-N2-Pro foi bem, 83/A. Mesma base, diferença brutal. Pelo menos no meu teste de Rails/RubyLLM, o valor da Nex não parece ser “tem 397B parâmetros”. Qwen já tinha isso. O valor está em ter corrigido comportamento de agente que o Qwen base não tinha: usar API real, terminar a tarefa, validar ambiente, lidar com erro.

Essa distinção importa pra controvérsia da Rio. Se a Rio 3.5 usou Nex como ingrediente principal, não é só “usou Qwen com outro nome”. Ela teria usado justamente a parte que tornava o Qwen útil em tarefas de agente. E essa parte era trabalho da Nex.

O que a Rio respondeu, na prática

A resposta pública mais concreta, até onde consegui verificar, foi a alteração da README no Hugging Face. A Rio passou a dizer que:

1. O modelo é construído via mescla de Nex-N2-Pro e Qwen3.5-397B-A17B.
2. Depois disso haveria uma etapa de On-Policy Distillation, ou destilação on-policy, a partir de um modelo mais forte.
3. O checkpoint inicialmente enviado seria a “versão base mesclada”, não o modelo final destilado.
4. Eles estariam trabalhando pra reenviar o modelo correto.

Também há o histórico de commits do Hugging Face mostrando que, depois da issue, vários arquivos model-00001.safetensors até model-00097.safetensors e uma imagem de benchmarks foram removidos. Dá pra ver isso pela API de commits do Hugging Face.

Aqui entra meu ceticismo normal de engenheiro. “Subimos o arquivo errado” é uma explicação possível. Acontece. Mas quando o arquivo errado, segundo a análise da Nex, é exatamente uma combinação matemática de modelos de origem sem crédito inicial, e a correção vem uma hora depois da denúncia, fica difícil chamar de mero detalhe operacional.

Não impossível. Difícil.

O que é mescla de modelos

Pra quem não acompanha esse nicho, mescla de modelos, ou “model merge”, não é mágica. É uma técnica relativamente comum: você pega dois checkpoints compatíveis, normalmente da mesma arquitetura, e combina os pesos. A versão mais simples é literalmente uma interpolação linear:

modelo_final = 0.6 * modelo_A + 0.4 * modelo_B

Existem variações mais sofisticadas, com mescla por camada, task vector, TIES, DARE, SLERP, pesos diferentes por módulo. Mas o conceito é esse: você não está treinando do zero. Você está combinando parâmetros já treinados.

Isso pode funcionar? Às vezes. Especialmente quando os modelos têm a mesma base e foram ajustados em direções complementares. Pode preservar capacidades de um e recuperar comportamento base de outro. Também pode piorar. Mescla é alquimia estatística: tem técnica, mas também tem muito teste empírico.

E, principalmente: mescla não custa nem remotamente o que custa treinar um modelo 397B. Você precisa baixar checkpoints enormes, rodar scripts, testar pesos, talvez fazer benchmark, talvez fazer ajustes. Não é zero trabalho. Mas não é “treinamos um modelo de fronteira”.

Se a evidência da Nex está correta, o checkpoint publicado era algo na linha:

Rio 3.5 ≈ 0.57 a 0.60 * Nex-N2-Pro + 0.40 a 0.43 * Qwen3.5-397B-A17B

Isso parece mais trabalho de engenharia de integração do que treino de modelo. Não é o mesmo tipo de mérito técnico que pós-treinar ou destilar um 397B e apresentar isso como avanço próprio.

O que é destilação aqui

Destilação, ou distillation, é outra coisa. Em LLM, normalmente significa usar um modelo professor mais forte para gerar respostas, raciocínios ou preferências, e treinar um modelo aluno para imitar esse comportamento. Você pode destilar estilo, capacidade de raciocínio, formato de resposta, domínio específico, uso de ferramenta. O aluno pode ser menor, mais barato, mais rápido, ou simplesmente adaptado a um objetivo.

A README corrigida da Rio fala em On-Policy Distillation from a stronger model. Traduzindo livremente: eles teriam usado um modelo mais forte para gerar dados ou sinais de treino durante uma política de geração mais próxima do próprio aluno, e então treinado a Rio 3.5 final.

Isso, se existir, é trabalho real. Exige pipeline, dados, computação, avaliação. A questão é que a Nex não analisou esse suposto modelo final destilado. Ela analisou o checkpoint que estava publicado. E a própria Rio agora diz que aquele checkpoint era a “versão base mesclada” enviada por engano.

Então o estado factual é:

• checkpoint publicado inicialmente: acusado de ser uma mescla Nex + Qwen;
• README inicial: creditava Qwen, não Nex;
• README corrigida: reconhece mescla Nex + Qwen e diz que o final destilado não era aquele;
• modelo final correto: em aberto, até ser reupado e analisado.

Sem o checkpoint final, não dá pra avaliar a destilação. Dá pra avaliar a comunicação.

A licença: Apache permite, mas normalmente exige preservar avisos

Aqui é onde muita discussão online fica burra.

Não sou advogado e isso não é parecer jurídico. Além disso, a aplicação exata de licenças de código aberto a pesos de modelo ainda tem zonas cinzentas. Mas, pela leitura prática da Apache-2.0, a regra operacional não é “use e apague os rastros”.

Nex-N2-Pro declara licença Apache-2.0 no Hugging Face: README do Nex-N2-Pro. Qwen3.5-397B-A17B também declara Apache-2.0: README do Qwen3.5-397B-A17B.

Apache-2.0 é permissiva. Ela permite reproduzir, modificar, criar derivados, sublicenciar e distribuir. Inclusive comercialmente. Então não é “roubo” simplesmente porque usaram Nex e Qwen. Se a licença permite, usar faz parte do jogo.

Mas permissiva não significa “sem obrigação nenhuma”. A licença Apache-2.0 exige, entre outras coisas:

• dar aos recipientes uma cópia da licença;
• marcar arquivos modificados com avisos proeminentes de mudança;
• preservar avisos de copyright, patente, marca e atribuição da forma fonte;
• incluir NOTICE quando o trabalho original tiver NOTICE aplicável.

A Rio 3.5 inicialmente declarou MIT License e creditou Qwen/SwiReasoning, mas não Nex. Se o checkpoint distribuído era de fato derivado de Nex-N2-Pro, isso é no mínimo uma falha de atribuição. Pode ser corrigível. Parece ter sido corrigido parcialmente na README. Mas o erro aconteceu no lançamento, justo no momento de maior visibilidade.

E tem mais uma nuance: não dá pra simplesmente pegar dois componentes Apache-2.0, gerar um derivado e anunciar o pacote resultante como se fosse apenas MIT, sem preservar as obrigações Apache dos upstreams.

Apache-2.0 é permissiva e permite distribuir derivados sob termos diferentes para as suas modificações, mas com condição: você ainda precisa entregar a licença Apache, preservar avisos de copyright/atribuição e carregar NOTICE quando existir.

Então “MIT” pode até aparecer como licença da camada adicionada pela Rio, mas não pode apagar a Apache-2.0 de Nex e Qwen nem dar a entender que o derivado inteiro ficou livre dessas obrigações. Se o card original dizia só MIT e não trazia os créditos/avisos Apache aplicáveis, isso pode deixar de ser só gafe de etiqueta e virar possível problema de conformidade de licença.

E aqui tem uma ironia: eles poderiam ter evitado 90% da controvérsia com uma frase honesta desde o começo:

“Rio 3.5 é uma mescla/ajuste fino construído sobre Nex-N2-Pro e Qwen3.5-397B-A17B, com adaptações da IplanRIO para português e uso público.”

Pronto. Talvez ainda reclamassem politicamente, mas a crítica técnica ficaria muito mais fraca. O problema é parecer que você fez sozinho.

Quanto trabalho parece ter tido?

Essa é a parte especulativa, então vou marcar como especulação.

Se o que foi publicado era só a mescla base, o trabalho técnico pode ter sido bem menor do que a narrativa pública sugere. Fazer mescla de dois modelos gigantes não é apertar um botão no navegador, claro. Você precisa de armazenamento, scripts, máquina, validação, lidar com shards, enviar quase uma centena de safetensors, rodar testes, escrever documentação. Dá trabalho operacional.

Mas não é o mesmo tipo de trabalho que treinar, pós-treinar ou destilar um 397B de verdade.

E a frase “modelo de IA aberta treinada no Rio com financiamento público ao longo do último ano”, como disse Eduardo Cavaliere no tweet, cria uma expectativa bem diferente de “fizemos uma mescla de dois modelos Apache e talvez uma destilação depois”.

Rafael Coelho respondeu em outro tweet que não teriam gasto dinheiro público e que fizeram um swap de códigos de treino velhos por créditos de GPU. Pode haver uma explicação administrativa aí, mas pra quem está de fora a comunicação fica confusa.

Não estou afirmando irregularidade administrativa. Estou dizendo que a narrativa pública ficou inconsistente.

E mesmo a cifra de R$ 500 mil, citada na reportagem do Mobile Time sobre a geração anterior, precisa de escala. Em pesquisa séria de LLM, isso não é muito dinheiro. Some salário de alguns pesquisadores, infraestrutura, armazenamento, horas de GPU em nuvem, tentativas que falham, avaliação, engenharia de dados, e esse valor some rápido. É troco perto do custo de treinar ou pós-treinar modelo grande de verdade.

Então eu não usaria “R$ 500 mil” como prova automática de desperdício. Não é por aí. O ponto é outro: esse valor também não sustenta, sozinho, a narrativa de que foi feito um treinamento pesado e original de um modelo 397B. Pra esse tipo de escala, pesquisa séria gastaria muito, muito mais.

Foi financiado publicamente? Não foi? Custou R$ 500 mil na geração anterior? Foi crédito de GPU? Foi treino de um ano? Foi mescla? Foi destilação? Foi envio errado?

Talvez todas essas frases tenham contextos diferentes. Mas quando a comunicação técnica é ruim, o público junta tudo e vira bagunça.

O que meu benchmark diz sobre Nex e Qwen

Agora vem a parte em que eu consigo falar com dado próprio. No meu llm-coding-benchmark, eu testei tanto o Nex-N2-Pro quanto o Qwen 3.5 397B A17B base.

Meu benchmark mede uma tarefa específica de programação/Rails. Ele é útil como sinal, não como avaliação geral de capacidade.

Não testei a Rio 3.5 diretamente por um motivo simples: ela é grande demais pra minha máquina local. Meu Strix Halo tem 128 GB de RAM unificada, ótimo pra muita coisa, mas não pra rodar um 397B desse porte com folga. Pra testar direito eu teria que alugar máquina em nuvem, lidar com configuração, baixar centenas de gigabytes, organizar shards, subir servidor de inferência, pagar por hora, e ainda correr o risco de o checkpoint correto nem estar disponível no momento.

Não estava a fim desse trabalho todo pra um post de análise rápida. Então fiz a melhor aproximação disponível: testar os originais que a própria controvérsia coloca na receita, Nex-N2-Pro e Qwen3.5-397B-A17B. Se a Rio publicada era basicamente uma mescla desses dois, e se não há evidência pública de muito trabalho efetivo em cima daquele checkpoint, comparar os ingredientes já diz bastante. Não substitui teste direto da Rio, mas coloca a alegação de performance em perspectiva.

E tem outro detalhe: no model card antigo da própria Rio, a tabela dizia “Gains Over Base Model”, mas a Rio não ganhava do Qwen 3.5 base em tudo.

Ela perdia em MMLU-Redux (94,6 vs 94,9), MMMU-Pro (78,4 vs 79,0) e VideoMMMU (81,6 vs 84,7), empatava em MCP-Atlas (74,2 vs 74,2), e em alguns casos ganhava por margem pequena, como MMLU-Pro (88,0 vs 87,8) e MathVision (89,1 vs 88,6). Então mesmo pelos números auto-reportados, sem auditoria independente, a história era mais “melhora em vários benchmarks” do que “melhor que Qwen em tudo”.

E, sim, onde a Rio dizia ganhar do Qwen, isso também combina com a hipótese da Nex: o Nex-N2-Pro já era melhor que o Qwen base justamente por causa do trabalho da Nex. Eu vi isso no meu próprio benchmark: Qwen3.5-397B-A17B base fez 42/C, enquanto Nex-N2-Pro fez 83/A. Então uma Rio que mistura Nex com Qwen pode muito bem parecer melhor que Qwen. Para o checkpoint publicado, a explicação mais simples não é “a Rio inventou uma técnica milagrosa”; é “ela herdou boa parte do ganho que a Nex já tinha produzido em cima do Qwen”.

Commits relevantes:

• 11a9c68: adiciona Nex-N2-Pro, 83/100, Tier A.
• e2af88c: adiciona Qwen 3.5 397B A17B base, 42/100, Tier C.

Na tabela final do benchmark, o Nex ficou assim: rank #10, 83/100, Tier A.

Nex-N2-Pro | 83 | A | RubyLLM OK | OpenRouter | 25m | free

O Qwen base ficou assim: rank #28, 42/100, Tier C.

Qwen 3.5 397B A17B (base) | 42 | C | RubyLLM não OK | OpenRouter | 15m | ~$0.58

Esse é um controle interessante. Mesmo backbone, resultado completamente diferente.

O Qwen base alucinou a API do RubyLLM (chat.system, chat.user, response.text) e ainda criou o app dentro de um diretório aninhado chat-app/, violando o formato esperado pelo benchmark.

O Nex, por outro lado, usou a API real: RubyLLM.chat, chat.ask, response.content, subiu localmente, passou Docker, compose e chat real via OpenRouter. O relatório compara isso diretamente: Qwen base 42/C vs Nex ajustado 83/A, salto de 41 pontos.

Isso coloca a Rio 3.5 em perspectiva. Se ela realmente era 60% Nex + 40% Qwen base, faz sentido ela herdar bastante da capacidade de agente do Nex. Mas também faz sentido suspeitar que misturar 40% de um modelo que, no meu teste, foi muito pior em programação, possa degradar o Nex puro em certos cenários.

Então não vou afirmar “Rio é pior” como medição minha. O que dá pra dizer é: o componente Nex é bom; o componente Qwen base foi ruim no meu teste; uma Rio que fosse só Nex diluído com Qwen base não deveria ser vendida como avanço óbvio sobre Nex puro sem benchmark reproduzível contra o próprio Nex. Pelo que foi publicado até agora, não parece que o trabalho adicional em cima da mescla tenha melhorado a posição de forma demonstrável. Se melhorou, publiquem o modelo correto e os testes reproduzíveis.

E mesmo o Nex, que foi muito bom, não ficou no topo do meu ranking de modelos abertos ou quase abertos. Ele marcou 83. Os melhores até aqui foram Kimi K2.6 e GLM 5.2 com 87, e Kimi K2.7 Code com 86. Nex é Tier A, gratuito, impressionante. Mas não é mágica. É um bom ajuste fino voltado a agentes em cima de uma família que, crua, tropeça feio em APIs de biblioteca.

Então, como usuário, minha conclusão prática é simples: se eu tivesse que escolher hoje, eu usaria Nex-N2-Pro direto. Não porque Rio seja automaticamente inútil para sempre, mas porque o checkpoint publicado não mostrou um ganho claro e auditável sobre o ingrediente mais valioso da receita. Se o ganho veio da Nex, por que não usar a Nex? A Rio só volta a ser interessante tecnicamente se aparecer o modelo final destilado correto, com avaliação reproduzível mostrando vantagem real sobre Nex-N2-Pro puro.

Então foi plágio?

Minha resposta honesta: eu não chamaria de plágio como conclusão jurídica. Eu chamaria de reapresentação mal atribuída do checkpoint inicialmente publicado, com forte evidência de mescla direta e uma correção posterior que só apareceu depois da exposição.

Código aberto não é “não pode usar”. Código aberto é “pode usar, mas respeite a licença e dê crédito”. Se Nex e Qwen estão em Apache-2.0, a prefeitura podia construir em cima. Podia fazer mescla. Podia fazer destilação. Podia publicar derivado. Podia até licenciar a parte dela sob MIT, desde que não apague obrigações dos componentes Apache e preserve os avisos exigidos.

O erro foi deixar a narrativa pública parecer criação própria, com crédito incompleto. E aí, quando a Nex apareceu com conta tensor a tensor, a README mudou.

Talvez exista um modelo final destilado de verdade. Se existir, publiquem. De preferência com:

• card claro dizendo base, mescla, destilação e dados de treino;
• licença compatível com Qwen e Nex;
• créditos explícitos;
• script de avaliação reproduzível;
• benchmark contra Nex-N2-Pro puro e Qwen base;
• explicação sobre o “envio incorreto”.

Isso encerraria boa parte da discussão técnica. Talvez não a política, mas a técnica sim.

O que dá pra aprender daqui

Essa história é um bom lembrete pra todo mundo que está surfando modelos abertos agora. A cadeia de derivação importa. Não por burocracia acadêmica, mas porque ela é parte da confiança.

Se você faz ajuste fino em cima de Qwen, diga Qwen. Se faz mescla com Nex, diga Nex. Se destila de um professor fechado, diga que destilou, mesmo que não possa nomear o professor. Se subiu o checkpoint errado, explique exatamente qual era o errado, qual é o certo, e como alguém pode verificar.

O pior caminho é tentar parecer maior do que é. Porque LLM de código aberto é um ambiente onde pesos são baixáveis, comparáveis e auditáveis. Você pode até esconder a narrativa por um tempo, mas não esconde álgebra linear.

No fim, a Nex talvez tenha feito a melhor validação involuntária do próprio modelo: se uma prefeitura usou Nex-N2-Pro como 60% da receita de um modelo anunciado como “estado da arte”, é porque o Nex é bom. Mas validação involuntária não paga a conta de crédito.

E crédito, no código aberto, não é frescura. É a moeda básica do jogo.

Eu gosto dessa fase. O projeto deixa de ser “o que eu imaginei no meu setup” e vira “o que quebra na máquina de outra pessoa”. Aí aparece Windows, macOS, Arch, AUR, path esquisito, token salvo em lugar diferente, shell diferente, terminal diferente. Chato? Sim. Necessário? Também.

Mas o prato principal de hoje não é ai-jail nem ai-memory. É TUI. Mais especificamente, é minha mania recente de escrever pequenas ferramentas de terminal em Rust com Ratatui, mas querendo que elas fiquem com cara de Bubble Tea.

O app que não vou abrir

Nas últimas semanas também mexi num projeto privado que não pretendo abrir. É uma TUI pra acompanhar minha conta nos EUA, investimentos, assets, posições, covered calls, open calls, essas coisas chatas de adulto. Não vou publicar o código porque é o tipo de ferramenta que nasceu colada no meu fluxo financeiro, nas minhas planilhas, nos meus extratos e nas minhas gambiarras internas. Abrir isso seria transformar uma ferramenta minha em suporte gratuito pra bug de banco dos outros. Tô fora.

Mas dá pra mostrar a cara geral. Censurei o que precisava censurar:

Observação óbvia, mas vou deixar explícito: todos os valores, tickers, posições e datas mostrados no screenshot são dados falsos de demonstração. Não é dado real da minha conta, nem portfolio real, nem recomendação de investimento.

Toda vez que faço uma TUI pequena, a mesma dúvida aparece: que stack usar?

Se eu fosse escrever tudo na unha, provavelmente escolheria Python ou Go. São linguagens mais confortáveis pra esse tipo de utilitário pequeno. Python porque é direto, cheio de biblioteca, ótimo pra script que conversa com API e parseia JSON. Go porque gera binário simples, cruza plataforma bem, e tem ergonomia boa pra CLI.

Só que hoje eu raramente escrevo esse código todo na unha. Eu orquestro Claude, Codex, OpenCode, mando revisar, mando refatorar, mando testar. Nesse cenário, a falta de ergonomia do Rust pesa menos, porque quem briga com borrow checker, trait bound e lifetime chato é o LLM. Eu fico mais no papel de revisor e usuário final. E aí Rust começa a ficar muito atraente.

Ferramental bom. cargo é ótimo. Testes são fáceis de rodar. Cross compile é administrável. O binário final é limpo. Erro de memória idiota praticamente some. Não estou dizendo que Rust é magicamente melhor que Go ou Python pra toda TUI. Não é. Mas com LLM escrevendo a maior parte, o custo que normalmente me faria evitar Rust cai bastante. E os modelos atuais estão surpreendentemente competentes em Rust, desde que você mande rodar teste, consertar warning e não aceite a primeira versão como se fosse revelação divina.

Ratatui é bom, mas eu queria a cara do Charm

O Ratatui é uma biblioteca Rust pra construir interfaces ricas no terminal: dashboards, apps interativos, tabelas, listas, gauges, layouts, tudo aquilo que antigamente a gente chamava de “ncurses moderno”. Ele é o sucessor espiritual do tui-rs, e hoje é provavelmente o caminho mais óbvio se você quer fazer TUI séria em Rust.

Ratatui funciona bem. O problema é gosto pessoal: por padrão, não acho bonito. Não é feio no sentido “isso parece programa de DOS de 1993”. Dá pra fazer coisa boa. Mas muita TUI em Ratatui cai naquela estética quadrada, cinza, funcional, meio admin panel de datacenter.

Eu gosto mais da pegada da Charmbracelet. O gum, por exemplo, é uma coleção de comandos pra deixar shell script interativo sem virar festival de read -p e case. Prompt, select, filter, spinner, tabela, pager, estilo. Você monta um script bash com cara de app decente em minutos.

E tem o Bubble Tea, em Go, inspirado na arquitetura Elm. Você tem um model, recebe mensagens, atualiza estado, renderiza uma view. É uma ideia simples e muito boa pra terminal: estado entra, evento entra, view sai. A Charm também tem um gosto visual que eu curto: cores boas, espaçamento decente, componentes leves, nada com cara de formulário WinForms jogado no terminal.

Então eu queria o seguinte: continuar em Rust com Ratatui, mas roubar a sensação de Bubble Tea. Não o runtime inteiro. Não um clone perfeito. Só a direção visual e alguns componentes.

Daí nasceu o ratatui-bubbletea.

O projeto não substitui o Ratatui. Ele fica por cima. A ideia é oferecer uma camada de tema e componentes com inspiração em Bubble Tea/Bubbles, mas ainda renderizando com Ratatui.

Hoje ele é dividido em crates:

• ratatui-bubbletea-theme, com paleta, helpers e estilos compartilhados.
• ratatui-bubbletea-components, com componentes prontos como select list, spinner, progress, table, text input, viewport e help.
• ratatui-tea, opcional, pra quem quer uma ergonomia mais perto de Model, Msg e Cmd, sem fingir que Rust virou Go.

O README tem os exemplos completos e a documentação do que já existe. Por enquanto, eu trato como toolkit pequeno. Serve pra meus apps, e se servir pra mais alguém, ótimo. Se não servir, também não tem drama. O objetivo era parar de reimplementar o mesmo tema e os mesmos widgets toda vez que eu começava uma TUI nova.

ai-usagebar como exemplo público

Como não vou abrir o app financeiro, precisava de um exemplo público usando essa estética. Então atualizei meu ai-usagebar.

Pra quem não lembra, expliquei o projeto no post “Criei um Widget de Waybar pra Omarchy pra Monitorar Uso de Planos de LLM: ai-usagebar”. Ele nasceu como widget de Waybar pra mostrar uso de planos de LLM: Claude, OpenAI Codex/ChatGPT, Z.AI, OpenRouter. Bateu o olho na barra, sabe se está perto do limite e qual vendor usar agora.

Depois virou também TUI standalone. E graças a contribuições, hoje suporta Windows também. Isso é engraçado porque a origem dele é totalmente Linux/Omarchy/Waybar. Mas é open source: alguém usa em outro ambiente, encontra atrito, manda PR, e pronto, o projeto fica menos provinciano.

No ai-usagebar a diferença visual não muda a vida de ninguém. É uma tela simples. Abas, gauges, texto, atalhos. Mas é um bom exemplo porque é pequeno, real, testado, empacotado, e não depende do meu app privado. Dá pra olhar o código e ver como apliquei a camada de tema.

Os apps de coceira própria

Esses projetos todos seguem a mesma lógica: eu tenho uma coceira, faço uma ferramenta pequena, uso, ajusto, empacoto. Nada de roadmap de startup. Nada de manifesto. Só ferramenta que resolve um incômodo meu.

Um exemplo recente é o clock-tui. Ele não nasceu comigo. Era um projeto Rust antigo, tclock, que parecia abandonado. Eu queria um relógio grande no meu segundo monitor vertical. Aquele monitor fica do lado, e eu gosto de ter um “desk clock” enorme ocupando parte da tela. Usei o clock-tui original por um tempo.

Só que uma tela vertical inteira só pra mostrar hora é desperdício. Eu já tinha o ghpending, que lista issues e PRs abertos em todos os meus projetos. Ele é meu “tem alguém esperando resposta?” em formato de CLI. Também queria ver minha agenda.

Então fiz outro app pequeno: google-calendar-tui. Ele usa as contas Gmail já registradas no GNOME Online Accounts e resume meus próximos compromissos no terminal. Read-only. Sem ritual de OAuth novo. Sem mais um config secreto espalhado em lugar esquisito.

Com essas duas peças, modernizei o clock-tui e adicionei layout de widgets auto-refresh. Agora o relógio ocupa a tela como eu queria, mas em volta dele aparecem pendências do GitHub e agenda do Google Calendar.

Isso é exatamente o tipo de coisa que eu nunca faria se custasse um fim de semana inteiro. Mas com LLM, vira uma sequência de tarefas pequenas: lê o projeto antigo, moderniza dependências, roda teste, adiciona módulo de widget, chama ghpending, chama google-calendar-tui, organiza layout, corrige bug, empacota. Ainda dá trabalho. Mas é trabalho de supervisão e refinamento, não de ficar brigando com boilerplate.

Ajustando Geary sem fork

Outra coceira veio do GNOME.

Como eu queria centralizar minhas contas no GNOME Online Accounts, comecei a usar Geary e o calendário do GNOME no segundo monitor também. Gosto da ideia: contas configuradas uma vez, apps do desktop reaproveitando a mesma infraestrutura, nada de cada programinha inventar seu próprio login.

O problema é que o Geary tem um layout fixo de três colunas. Numa tela normal, tudo bem. Num monitor vertical, fica apertado. A coluna de pastas, a lista de mensagens e o corpo do e-mail brigam por espaço. Eu não queria manter um fork do Geary só pra esconder uma sidebar. Fork de app GTK grande é dívida. Você pisca e passa o resto da vida resolvendo conflito de merge.

Então fiz um módulo GTK: geary-hide-sidebar-module. Ele injeta um comportamento no Geary em runtime e permite recolher/expandir a sidebar, com atalho e auto-collapse em janela estreita. Sem recompilar Geary. Sem manter fork. Só um módulo pequeno com uma responsabilidade bem específica.

Essa é uma lição boa: às vezes você não precisa forkar a aplicação inteira. Dá pra ajustar por fora. GTK_MODULES existe. Wrapper existe. Config existe. CSS existe. Script existe. Nem toda personalização precisa virar uma manutenção eterna de código dos outros.

Código pequeno ficou barato

É por isso que estou insistindo tanto nessa ideia de apps pequenos. Com LLMs atuais, ficou muito fácil implementar uma ideia específica pra deixar seu ambiente do jeito que você quer. Sem esperar alguém ter exatamente a mesma dor. Sem ficar procurando no GitHub por três horas uma ferramenta que faz 80% do que você quer e 40% do que você não quer.

Você descreve a coceira, cria um repo, pede um protótipo, testa, manda refatorar, manda escrever teste, manda empacotar. Se ficar ruim, joga fora. Se ficar bom, instala e usa.

Eu não deixo isso virar gambiarra jogada no ~/bin sem dono. Meus apps têm testes. Têm builds automatizados. Muitos têm release no GitHub, pacote no AUR, instalação normal com yay no Arch. Usam paths XDG, então config vai pra ~/.config, cache vai pra ~/.cache, dados vão pra ~/.local/share. Fica organizado. Dá pra atualizar. Dá pra remover. Dá pra outra pessoa clonar e contribuir.

Pra fechar, os links todos num lugar só:

• ratatui-bubbletea
• ai-usagebar
• clock-tui
• ghpending
• google-calendar-tui
• geary-hide-sidebar-module
• ai-jail
• ai-memory

Se você usar algum deles e quebrar no seu setup, abre issue. Se souber corrigir, manda PR. Eu uso essas ferramentas de verdade, então bug report útil tende a virar correção rápido.

Minha regra prática é essa: personalize seu ambiente sem transformar tudo em gambiarra. Faça ferramenta pequena. Teste. Empacote. Documente. Deixe o LLM carregar o peso chato e use seu cérebro pra decidir o que presta.

Essa é a parte divertida de programar que tinha sumido um pouco. Agora voltou.

Minha opinião curta: IA em contribuição open source veio pra ficar. Vai aumentar, não diminuir. A caixa de Pandora já abriu. Não existe plano realista onde todo mundo volta a programar 100% manualmente e finge que Claude Code, Codex, OpenCode, Cursor, Gemini CLI e o resto nunca existiram.

Isso não quer dizer que todo projeto tem obrigação de aceitar contribuição feita com IA. Longe disso. O mantenedor tem o direito absoluto de tocar o projeto como quiser. Pode aceitar IA, pode banir IA, pode congelar o projeto, pode apagar o repositório e ir plantar tomate. Código aberto não é democracia obrigatória. Quem mantém decide.

Mas também acho que banir IA é só adiar uma briga impossível de ganhar. O volume vai continuar subindo. A qualidade média vai oscilar. Vai ter lixo, vai ter coisa boa, vai ter PR quase certo, vai ter relatório de bug alucinado. A pergunta prática não é “como impedir IA?”. A pergunta prática é: como adaptar o processo pra sobreviver a isso?

Os casos recentes

O caso mais barulhento agora foi o do rsync 3.4.3. A versão saiu em 20 de maio como update de segurança, corrigindo seis CVEs. Logo depois, usuários reportaram regressões, em especial em fluxos de backup com daemon mode e opções de transferência incremental. Rsync não é brinquedo. É ferramenta de backup, deploy, mirror, sysadmin. Quebrar compatibilidade ali dói.

Andrew Tridgell, criador do Samba e co-criador do rsync, respondeu no post rsync and outrage. Ele confirmou que usou Claude, com cross-check de Codex e Gemini, pra ajudar a reescrever parte da suíte de testes em Python. Mas também disse o óbvio que muita gente não quer ouvir: ele não mandou “converte tudo aí” e foi dormir. Ele desenhou a suíte, revisou o trabalho, queimou muito tempo de CI, e assumiu que as regressões aconteceram em casos válidos, mas incomuns, que não estavam cobertos nem pelos testes existentes nem pelos testes manuais dele.

Esse é o ponto interessante: a regressão virou discussão sobre IA, mas regressão não nasceu com IA. Regressão nasceu junto com software.

Do outro lado temos o Zig. O Code of Conduct do Zig hoje tem uma política explícita: Strict No LLM / No AI Policy. Nada de conteúdo gerado por LLM, nem código, nem prosa, nem revisão gramatical, nem tradução, nem brainstorming. Andrew Kelley explicou em entrevista, resumida pela DevClass, que a equipe considera contribuições de IA invariavelmente ruins, consumidoras de tempo de review, não ensináveis, não determinísticas. A frase que resume a postura dele é boa: o padrão que ele quer não é “funciona surpreendentemente bem”, é “perfeição sem compromisso”.

Eu discordo da generalização, mas respeito a decisão. É o projeto dele. Se ele quer manter aquele espaço sem LLM, é direito dele. Ponto.

Na mesma vizinhança apareceu a discussão do Bun. O post oficial do Bun entrando na Anthropic diz que Bun foi adquirido porque Claude Code e outros produtos de coding da Anthropic dependem dele. “Se Bun quebra, Claude Code quebra”, nas palavras do próprio post. Já a matéria da Cosmic sobre a reescrita em Rust aponta motivos como acessibilidade de contribuidores, manutenção em escala e estabilidade de longo prazo. Eu vi gente ligando isso à política anti-IA do Zig, mas a fonte que consegui verificar não crava essa causalidade. O que dá pra dizer com segurança é: Bun, um projeto nascido em Zig, está migrando partes importantes pra Rust, e uma das razões citadas é a base maior de contribuidores.

E tem o caso do curl. Segundo a Hackaday, Daniel Stenberg suspendeu o programa de bug bounty do curl a partir de 1º de fevereiro de 2026 porque o projeto foi inundado por relatórios de vulnerabilidade gerados por LLM. Relatórios compridos, intimidadores, com cara de exploit sério, mas que quando um mantenedor experiente lê, não são vulnerabilidades. O PR que remove o bounty está no GitHub como curl/curl#20312.

Esse caso é diferente de PR de código. É pior. Um patch ruim você testa, compila, lê. Um relatório de segurança falso obriga alguém experiente a gastar tempo provando que não existe bug. É o tipo de trabalho ingrato que esgota mantenedor.

Então sim: o problema é real. AI slop existe. Está enchendo issue tracker, PR, bug bounty, comentário, tudo.

Agora a parte que ninguém gosta: isso não vai parar.

Não existe “voltar ao normal”

Eu já falei disso no post VS Code é o novo cartão perfurado. A interface mudou. Antes você precisava digitar instrução binária. Depois precisava organizar cartão perfurado. Depois precisava convencer o compilador. Depois precisava operar editor, terminal, framework, CI, container, cloud e YAML. Agora você precisa orquestrar agente.

Isso não elimina engenharia. Só muda onde o trabalho manual termina.

Tem gente tratando IA como se fosse moda passageira, igual “metaverso” ou NFT. Não é. IA pra programação já passou do ponto de demonstração de conferência. Está dentro do fluxo de trabalho real. O rsync usou. Bun está cheio de bot de Claude Code abrindo PR. Meus projetos usam. Seus contribuidores vão usar, mesmo que você proíba. Se você acha que consegue detectar com 100% de certeza que um patch foi escrito com ou sem IA, boa sorte com isso.

O mantenedor ainda pode impor regra. Pode dizer “se eu descobrir que usou IA, bloqueio”. Pode fazer sentido em comunidades pequenas, com cultura própria, como Zig. Mas no open source geral, principalmente projeto grande, com usuário no mundo inteiro, isso vira teatro de compliance. O sujeito usa IA, reescreve, não declara, e pronto. Você vai fazer o quê? Detector de IA em código? Pelo amor.

O erro é achar que você precisa revisar tudo sozinho

A reclamação mais justa dos mantenedores é simples: já falta gente pra revisar contribuição humana. IA aumenta o volume. Mais PR, mais issue, mais bug report. O mantenedor já estava cansado, agora está afogado.

Eu entendo. Só acho que a solução não é tentar processar o novo volume com o processo velho.

Você combate IA com IA.

A primeira triagem tem que ser feita com LLM. Não pra aprovar automaticamente. Pra filtrar. Pra resumir. Pra comparar diff com objetivo declarado. Pra apontar cheiro ruim. Pra dizer “isso toca schema, precisa migração”. Pra dizer “isso altera comportamento público, precisa teste de compatibilidade”. Pra dizer “essa descrição do PR não bate com o código”. Só essa camada já elimina 80% do trabalho braçal.

O erro é deixar o agente decidir sozinho. O acerto é mandar o agente fazer o trabalho chato de investigação, e você decide.

É assim que eu faço.

Meu fluxo real com PRs

Quem acompanhou minha maratona de IA sabe que eu não cheguei aqui depois de assistir dois vídeos no YouTube. Passei semanas usando agente todo dia, em projeto real, quebrando coisa real, corrigindo coisa real. O que estou descrevendo aqui é o fluxo que sobrou depois disso, não teoria de LinkedIn.

Propaganda descarada: estou feliz que meus três projetos principais relacionados a IA estão recebendo contribuição quase todo dia:

• ai-jail, que já expliquei no post ai-jail: Sandbox para Agentes de IA.
• ai-memory, que expliquei em Criei um Sistema de Memória pra Agentes de Código: ai-memory.
• ai-usagebar, do post Criei um Widget de Waybar pra Omarchy pra Monitorar Uso de Planos de LLM: ai-usagebar.

O ai-memory em particular virou um experimento vivo. No momento em que escrevo, o GitHub mostra 55 PRs fechados no projeto; pela API do gh, 46 foram mergeados e 9 foram fechados sem merge. Obrigado a todo mundo que contribuiu. Sério. Djalma, mrpaiva, pedrofjr, CaTeIM, azevedo-luis, brunoomariano, rikelmyso7, abnersajr e vários outros. É trabalho de muita gente.

Também é óbvio, olhando o estilo, que a maioria desses PRs foi feita com ajuda de IA. E isso não é problema. Seria até hipócrita reclamar: o ai-memory inteiro foi escrito por IA. Eu não abri editor de código uma única vez pra escrever aquilo na mão.

Mas quase nenhum PR chega imediatamente mergeável. Esse é o ponto que muita gente ainda não entendeu. “Feito com IA” não significa “merge cego”. Significa “começa a auditoria”.

Meu prompt pra revisar PR é mais ou menos assim:

checa o último PR aberto como de costume: não confie no autor, audita o código inteiro a fundo, garante que ele cumpre o objetivo.

Vê se precisamos ajustar ou corrigir antes de mergear: não aceite regressão, não aceite queda de qualidade de código, confere se a cobertura de teste está correta.

Se mexe em build ou suporte de OS, confere GitHub Actions, CI, build limpo, wiring correto e documentação.

Resume o que o PR faz, o que você encontrou, e me pede aprovação antes de seguir.

Repara em duas coisas. Primeiro: “não confie no autor”. Não é grosseria. É engenharia. A descrição do PR é uma hipótese. O diff é a evidência. Segundo: “me pede aprovação”. O agente investiga, eu decido.

Quando recebo vários PRs no mesmo dia, faço isso pra todos. Depois que todos entram, mando outro prompt:

checa os commits de hoje.

Mexemos em muito código, então preciso de uma auditoria completa no código tocado pra garantir que não adicionamos regressão, duplicação desnecessária, código morto ou magic values que deveriam virar constantes documentadas.

Segue princípios de clean code, confirma cobertura de testes e refatora o que precisar.

Se o projeto já está em uso, adiciono a parte que muita gente esquece:

este projeto já está sendo usado. Não quebre compatibilidade.

Se mexemos em schema de banco ou estrutura de arquivos do usuário, precisa ter migração limpa no upgrade.

Upgrade não pode corromper dados.

Isso não garante nada. Mas evita erro óbvio.

No ai-memory dá pra ver esse padrão no histórico. Depois de uma leva grande de PRs, tem commits meus de endurecimento. Um exemplo é 65682dc, “fix(audit): address 5 BLOCKING audit findings from today’s review”, mexendo em OAuth OpenAI, admin API, admission hooks e servidor MCP. Outro é a sequência de PRs #65, #68, #70, seguida de commits de hardening em base path, wikilinks e strict mode. PR entra, depois vem auditoria, depois vem ajuste. Esse segundo passo é onde mora a diferença.

No #77, de auto-scope por sessão/ator, o merge mexeu em muita coisa: active_project, router de hooks, servidor MCP, testes de stress e multiusuário. Mais de 3.800 linhas adicionadas. Eu não vou fingir que alguém lê isso manualmente linha por linha com a mesma consistência depois da quinta hora. O agente ajuda a mapear risco. Eu uso meu julgamento pra decidir o que precisa endurecer.

Regressão acontece com ou sem IA

O caso do rsync é útil porque expõe uma fantasia: a ideia de que código humano era seguro e código de IA é perigoso.

Não. Código é perigoso.

Rust é considerado linguagem segura. E Rust tem bug. Vai no issue tracker do Rust e olha. Zig quer perfeição e tem bug. Curl tem bug. Rsync tem bug. Linux tem bug. SQLite tem bug. Meu código tem bug. Seu código tem bug. Não existe linguagem mágica que produz software sem bug. Nunca vai existir.

Isso não é pessimismo. É limite fundamental. Em computação, a gente sabe há muito tempo que não existe verificador geral perfeito pra propriedades semânticas não triviais de programas. Halting problem, Rice’s theorem, esse tipo de coisa. Você pode provar muito em domínios restritos. Pode usar type system melhor. Pode usar Rust pra eliminar classe inteira de memory safety. Pode usar teste, fuzzing, model checking, static analysis. Ótimo. Use tudo.

Mas “software arbitrário sem bug” é fantasia.

Humano erra por contexto incompleto, suposição errada, pressão, cansaço, falta de teste, falta de uso real. IA erra pelos mesmos motivos práticos: contexto incompleto, suposição errada, treino em código ruim, objetivo mal especificado, validação fraca. A diferença é escala. IA consegue produzir mais lixo por minuto. Também consegue produzir mais correção por minuto se você montar o processo direito.

Eu uso porque eu uso

Outro ponto que aprendi na prática: é muito difícil manter bem projeto que você mesmo não usa.

Eu uso ai-memory todo dia. Uso ai-jail todo dia. Uso ai-usagebar todo dia. Usei a extensão Prettify Manga Reader na minha leitura real. Por isso pego bug que teste automatizado não pega.

No Prettify, por exemplo, os commits contam a história. 66c6728 adicionou filtro noturno. Depois veio b5bcb4d, release 0.2.2, com suporte a Kindle Web Reader, toolbar, shortcuts e screenshot. Logo depois veio 0e6b7ee, release 0.2.3, corrigindo o pareamento de spreads pra manter leitura direita-pra-esquerda sem bagunçar a ordem cronológica. Isso nasceu de uso real. Eu estava lendo, achei comportamento estranho, pedi pro LLM corrigir, testei, fiz release.

Esse é o loop saudável: usar, sentir dor, corrigir, testar de novo.

Em ai-jail, algumas contribuições vieram de uso que eu não teria priorizado sozinho. O #56 corrigiu PKGBUILD no AUR. O #55 encaminhou OSC 52 clipboard writes pelo proxy PTY de alt-screen. O #51 reconheceu Grok como agente conhecido e documentou máscara de privacidade de machine-id. São detalhes que aparecem quando outras pessoas usam a ferramenta em setups diferentes do meu.

Em ai-usagebar, isso fica mais claro ainda. O #4 adicionou fallback de macOS Keychain pras credenciais da Anthropic. Eu estou em Linux/Omarchy, não em macOS. Eu não ia achar esse bug no meu uso diário. O #7 corrigiu leitura de credentials_path customizado no widget. Também é caso de usuário com configuração diferente da minha. É aí que open source brilha: outra pessoa coça a própria coceira e melhora o projeto pra todo mundo.

Mas repare: quando eu não consigo testar manualmente, como macOS e Windows, eu dependo mais de CI. GitHub Actions roda macOS, roda Windows, roda Linux. Não substitui uso real, mas reduz risco. E quando alguém que usa aquele ambiente abre issue ou PR, isso vale ouro.

Manual testing ainda é a última linha de defesa. Se você abre mão dela, você está introduzindo bug por definição. Teste automatizado pega o que você lembrou de especificar. Uso real pega o que você nem sabia que precisava especificar.

Depois de mergear um conjunto grande, meu fluxo final costuma ser:

agora roda bin/deploy no meu home server e testa online.

Confere health, confere se ainda funciona como antes.

De novo: não garante nada. Mas evita quebrar o óbvio.

Não existe bala de prata

Eu não acho que todo projeto deve aceitar PR de IA. Também não acho que todo projeto deve banir. Não existe regra universal.

Se você é mantenedor solo de uma biblioteca crítica, sem tempo, sem CI decente, sem energia pra lidar com avalanche de PR ruim, banir AI-assisted contribution pode ser a decisão certa por enquanto. Melhor isso do que aceitar lixo e quebrar usuário.

Se você mantém comunidade pequena e quer ensinar contribuidores humanos, como o Zig argumenta, uma política anti-IA faz sentido dentro daquela cultura. Você está otimizando por formação de contributor, não por throughput de patch.

Mas se você mantém projeto que já recebe volume alto, que já tem CI, que já tem teste, que já tem usuário, eu acho que a adaptação é inevitável. Você vai precisar de triagem automatizada. Vai precisar de agente revisando PR. Vai precisar de bot resumindo issue. Vai precisar de ferramenta que diga “isso parece relatório de vulnerabilidade alucinado”.

Não porque IA é perfeita. Justamente porque IA é imperfeita e escala rápido.

Minha conclusão

AI slop é real. Vai piorar antes de melhorar. Vai ter PR porcaria. Vai ter relatório de segurança falso. Vai ter regressão atribuída a IA que teria acontecido com humano também. Vai ter mantenedor puto. Vai ter usuário gritando. Normal.

Mas a direção não muda.

Código assistido por IA veio pra ficar. A porcentagem de código tocado por agente vai subir sem parar. Proibir pode funcionar localmente, por um tempo, em uma comunidade específica. No macro, é guerra perdida.

O caminho pragmático é fazer a IA trabalhar a nosso favor. Usar IA pra triagem. Usar IA pra auditoria. Usar IA pra comparar diffs. Usar IA pra achar regressão. Usar IA pra escrever teste que falha antes e passa depois. Usar IA pra fazer o trabalho chato que cansa humano.

E manter a decisão humana onde ela importa.

Eu já disse isso várias vezes e vou repetir: IA é um espelho.

Se você é relaxado, ela acelera sua relaxação. Seu código vira AI slop industrializado.

Se você é engenheiro de verdade, ela amplifica sua engenharia. Você continua exigindo teste, CI, compatibilidade, migração, revisão, clean code, deploy, teste manual. Só que agora faz isso 10 vezes mais rápido.

E pras empresas: se você está pensando “ótimo, agora economizo porque não preciso contratar tantos programadores”, até dá pra entender. Até certo ponto. Mas se vai colocar IA no fluxo, então precisa reforçar QA. Mais teste, mais revisão, mais processo de validação, mais gente boa pensando em qualidade. Se não fizer isso, está ferrado. Vai trocar custo de desenvolvimento por custo de bug em produção, retrabalho, incidente e cliente irritado.

Não existe volta ao mundo 100% manual. Melhor parar de gastar energia tentando fechar a caixa de Pandora e começar a construir processo decente em volta do que saiu dela.

E aqui está a parte que ninguém comenta quando fala de “fiz um projeto com IA”: gerar o código é a parte fácil. O difícil, o que separa um repositório que é só um amontoado de código de um projeto de código aberto de verdade, é tudo que vem depois do git init.

Eu tenho uma opinião forte sobre isso, então vou cravar logo: nenhum projeto de código aberto está pronto pra ser publicado sem três coisas. Na ordem de importância:

1. Superfície de instalação. O novo usuário precisa conseguir instalar e testar a ferramenta com o mínimo de atrito possível. Um comando, de preferência.
2. Testes e CI automatizado. Pra que contribuições sejam mais fáceis e exista um chão comum sobre o que é minimamente aceitável pra entrar no projeto.
3. Documentação. A versão curta e fácil de ler (o README) e um conjunto mais detalhado em docs/, pra novos contribuidores entenderem as decisões arquiteturais.

Sem esses três, na minha visão, o projeto não está pronto. Pode ter o código mais genial do mundo dentro dele, não importa. Se um estranho não consegue instalar, não consegue confiar que o que ele mexer não vai quebrar tudo, e não consegue entender por que as coisas são do jeito que são, então você não tem um projeto de código aberto. Você tem um arquivo morto público.

E tem um bônus que virou parte essencial do meu fluxo: quando todos os meus projetos seguem o mesmo padrão, eu posso simplesmente pedir pro Claude Code ou pro Codex “roda o deploy” ou “solta uma release”, e eles conseguem. Porque a estrutura é previsível. bin/deploy faz a mesma coisa em todo projeto. A release sai de um tag. O agente não precisa adivinhar nada. Padronização é o que torna a automação confiável. Parece preciosismo de gente organizada, mas é o pré-requisito pra eu confiar de olhos fechados no que o agente vai rodar.

Vou destrinchar os três pilares e mostrar o mínimo de configuração que eu uso na prática.

Pilar 1: A superfície de instalação

Essa é a mais importante e a mais negligenciada. As pessoas passam semanas afinando o algoritmo interno e aí soltam um README que diz “clone o repo e rode cargo build --release”. Aí o sujeito que tava curioso pra testar precisa ter Rust instalado, esperar dez minutos de compilação, e torcer pra não faltar uma lib de sistema. Você acabou de perder 90% dos seus usuários potenciais.

O ideal é oferecer vários caminhos, e deixar o usuário escolher o que combina com o ambiente dele. Olha o cabeçalho de instalação do ai-jail, que é o meu campeão de opções:

# Homebrew (macOS ou Linux)
brew tap akitaonrails/tap && brew install ai-jail

# AUR (Arch Linux) - binário pré-compilado
yay -S ai-jail-bin

# cargo (qualquer plataforma com Rust)
cargo install ai-jail

# mise
mise use -g github:akitaonrails/ai-jail

# Download direto do binário
curl -fsSL https://github.com/akitaonrails/ai-jail/releases/latest/download/ai-jail-linux-x86_64.tar.gz | tar xz

Cinco caminhos. O usuário de Arch usa yay. O do macOS usa brew. O dev Rust usa cargo install. Quem usa mise pra gerenciar versões pega via mise. E quem só quer o binário baixa o tarball direto da release. Cada um pega o que já está acostumado, ninguém é forçado a instalar uma cadeia de ferramentas só pra experimentar.

O segredo: compile uma vez, reempacote várias

A pegadinha que assusta no começo é achar que cada formato de pacote exige um build separado. Não exige. O truque é compilar o binário uma vez por arquitetura, e depois reempacotar o mesmo binário em todos os formatos.

No meu pipeline em Rust, o job de build gera um tarball com o binário pronto e o sha256. As etapas de empacotamento seguintes (Docker, AUR, Homebrew) baixam esse tarball já compilado ao invés de recompilar. Reduz tempo de CI, garante que o byte que vai pro AUR é exatamente o mesmo que vai pro Docker, e elimina aquela classe de bug “funciona num formato e quebra no outro”.

# Job de Docker reaproveitando o binário já compilado
docker-amd64:
  needs: build-linux
  steps:
    - uses: actions/download-artifact@v4
      with:
        name: ai-memory-linux-x86_64
        path: artifacts
    - name: Desempacota o binário pré-compilado
      run: tar -xzf artifacts/ai-memory-linux-x86_64.tar.gz -C dist/docker/
    - uses: docker/build-push-action@v6
      with:
        target: runtime-prebuilt-amd64  # injeta o binário, não recompila

O job do AUR faz a mesma coisa: baixa o tarball, calcula o sha256, e injeta no PKGBUILD:

X86_SHA=$(awk '{print $1}' artifacts/ai-usagebar-linux-x86_64.tar.gz.sha256)
sed -i "s/^sha256sums_x86_64=.*/sha256sums_x86_64=('$X86_SHA')/" packaging/aur/PKGBUILD-bin

Esse é o conceito central. O binário é o artefato de verdade. RPM, DEB, AppImage, AUR, tarball Homebrew, imagem Docker, tudo isso é só embalagem em volta do mesmo binário.

Os dois trechos acima são recortes. Se você quiser ver o fluxo inteiro funcionando, o build-once-reuse completo (binário compilado uma vez, reaproveitado nos jobs de Docker e AUR) está no release.yml do ai-memory, e a injeção de sha256 no PKGBUILD está no release.yml do ai-usagebar.

O cardápio de formatos

Cada plataforma tem seu mundo. Segue o mínimo que vale conhecer:

Linux é o mais fragmentado. As opções, do mais simples pro mais trabalhoso:

• Tarball (.tar.gz): o denominador comum. Funciona em qualquer distro, é só descompactar e jogar no PATH. Sempre ofereça esse.
• AUR (Arch): dois pacotes, o -bin (binário pré-compilado, instala em segundos) e o de source (compila na máquina do usuário). Eu publico os dois com a action KSXGitHub/github-actions-deploy-aur. O -bin é o que todo mundo usa.
• AppImage: um arquivo único executável que carrega todas as dependências dentro. Bom pra apps desktop. O Frank Sherlock, que é Tauri, gera AppImage direto no build e eu ainda assino com GPG depois (o passo de assinatura está no release.yml dele). Pra binário simples dá pra usar appimagetool.
• RPM e DEB: pra Fedora/openSUSE e Debian/Ubuntu. A ferramenta que poupa sua vida aqui é o nfpm, que gera os dois a partir de um único nfpm.yaml declarativo, sem precisar entender as entranhas de rpmbuild ou dpkg-deb. Pega o binário já compilado e cospe os dois pacotes.

macOS tem dois alvos: Apple Silicon (aarch64-apple-darwin) e Intel (x86_64-apple-darwin). Você compila os dois separados ou gera um binário universal com lipo. E aqui mora a maior dor de cabeça da plataforma: assinatura e notarização. Sem isso, o Gatekeeper do macOS recusa abrir seu app. O fluxo é decodificar o certificado P12, importar num keychain temporário, assinar com codesign --options runtime --timestamp, e notarizar:

codesign --sign "$APPLE_SIGNING_IDENTITY" --options runtime --timestamp ./meu-binario
ditto -c -k meu-binario notarize.zip
xcrun notarytool submit notarize.zip \
  --apple-id "$APPLE_ID" --password "$APPLE_PASSWORD" \
  --team-id "$APPLE_TEAM_ID" --wait

Isso exige uma conta paga de Apple Developer. É chato, mas é o preço de não dar erro de “app danificado” na cara do usuário. O job inteiro de assinatura e notarização, com a dança do keychain temporário, está no release.yml do ai-jail.

Windows é o mais simples de buildar (x86_64-pc-windows-msvc) e o mais espinhoso de assinar. Certificado de code signing pra Windows é caro e burocrático, então eu, sinceramente, não assino. Aceito que o SmartScreen vai dar um aviso na primeira execução e deixo isso claro no README. Pra projeto pessoal de código aberto, está de bom tamanho.

Rust crates (cargo publish): se é uma biblioteca ou CLI em Rust, publicar no crates.io dá o cargo install de graça. Uma linha no pipeline. Dica: torne idempotente, porque rodar de novo num tag já publicado dá erro. Eu faço um grep na saída procurando “already exists” pra não quebrar a release inteira por causa disso.

Homebrew: a forma limpa é manter um tap próprio (akitaonrails/homebrew-tap). O pipeline atualiza a fórmula com a nova URL e o novo sha256 a cada release. O usuário faz brew tap uma vez e depois é só brew upgrade.

mise: o mise consegue instalar direto de releases do GitHub sem você configurar nada do seu lado, contanto que seus tarballs sigam uma convenção de nome de plataforma. Você ganha esse caminho praticamente de graça só por ter releases bem nomeadas.

Repara num detalhe: AUR, Homebrew, mise e o download direto todos consomem o mesmo tarball da release. Você publica os binários uma vez, e quatro gerenciadores de pacote diferentes sabem se virar. É por isso que “compile uma vez, reempacote várias” é a regra de ouro.

Pilar 2: GitHub Actions, releases por tag e changelog

A segunda coisa que torna um projeto de código aberto sério é CI. Esquece o selo de “build passing” no README, o valor está no chão comum que ele cria: quando alguém manda um pull request, o CI roda os testes, o linter e o scanner de segurança, e você sabe na hora se aquela contribuição quebra alguma coisa. Sem isso, todo PR vira uma negociação manual e cansativa.

Nos meus projetos Rust o CI roda cargo fmt --check, cargo clippy -D warnings, cargo test, e cargo audit. Nos projetos Rails, é rubocop, brakeman (scanner de segurança), bundler-audit e a suíte de testes em Minitest. O FrankMD sozinho tem mais de 1800 testes entre Ruby e JavaScript. O Frank Sherlock passa de 300 testes em Rust mais 300 no frontend. É essa rede de segurança que me deixa aceitar PR de estranho sem medo.

Revisão de PR com LLM

Os testes e o CI são a rede de baixo. Acima dela tem uma camada que virou central no meu fluxo: usar o próprio LLM pra revisar os pull requests. O Opus e o GPT são absurdamente bons em code review e em refatoração de qualidade. Melhores que eu na consistência, porque não cansam e não passam o olho por cima de 200 linhas só porque já é a quinta revisão do dia.

Eu tenho dois prompts que uso o tempo todo. O primeiro, pra um PR específico que acabou de chegar:

olha o PR aberto no github. não confie na descrição do autor. audita o código a fundo pra ver se faz sentido. garante que não tem regressão nem queda na qualidade do código. garante que a cobertura de testes está adequada. depois me diz o que você acha que a gente deveria fazer.

Repara no “não confie na descrição do autor”. Isso é de propósito. A descrição do PR conta o que a pessoa achou que fez, e nem sempre bate com o que ela realmente fez. O LLM tem que ler o código de verdade, não o resumo.

O segundo prompt é pra depois de uma sessão longa de código ou de vários PRs mergeados de uma vez:

a gente mexeu em muito código. audita o código que esses PRs mudaram, procura código morto, duplicação desnecessária, valor mágico hardcoded que deveria ser constante e/ou estar melhor documentado, falta de cobertura de teste, mira nos princípios de clean code, e depois verifica se a documentação foi devidamente atualizada.

Com o parecer na mão, eu decido. Pra PR incompleto, o que eu faço depende do tamanho e da minha prioridade naquele momento. Se é coisa pequena, eu mesmo corrijo direto no PR com um amend, respondo explicando o que mudei, e aí mergeio e fecho. Quando dá pra mergear mas não dá pra corrigir antes, mergeio e já solto um commit de correção logo em seguida. E quando é mudança grande, peço pro LLM responder o PR explicando por que a gente não vai mergear, com a direção certa do que precisa ser feito.

Foi assim que eu fechei quase 40 PRs e 20 issues só no ai-memory, em poucos dias. Esse volume não sai na mão, e também não pode sair no piloto automático.

E é nesse ponto que eu mais bato: nada disso é cego. Eu estou o tempo todo pilotando o LLM na direção desses objetivos. Ele faz a auditoria, joga as sugestões na mesa e até escreve o texto da resposta, mas quem decide mergear, corrigir ou recusar sou eu. O LLM é o revisor incansável; eu sou quem assina embaixo.

O gatilho por tag

A parte de release é separada do CI. Enquanto o CI roda a cada push e PR, a release dispara só quando você empurra um tag de versão:

on:
  push:
    tags:
      - 'v*.*.*'   # dispara em v1.2.3, v0.5.0, etc.
  workflow_dispatch: # permite disparar manualmente também

O fluxo de soltar uma versão vira isso:

git tag v0.5.0
git push origin v0.5.0

E pronto. O GitHub Actions percebe o tag, dispara o workflow de release, compila pros alvos, empacota tudo, assina o que precisa assinar, cria o GitHub Release e publica nos gerenciadores de pacote. Eu não toco em mais nada. Inclusive é literalmente isso que eu peço pro Claude Code: “solta a v0.5.0”. Ele faz cargo set-version, atualiza o CHANGELOG, commita, cria o tag, empurra, e o resto é o pipeline.

A matriz de build em Rust compila cada alvo na plataforma nativa dele:

strategy:
  matrix:
    include:
      - os: ubuntu-22.04
        target: x86_64-unknown-linux-gnu
      - os: ubuntu-22.04-arm
        target: aarch64-unknown-linux-gnu
      - os: macos-latest
        target: aarch64-apple-darwin
      - os: windows-latest
        target: x86_64-pc-windows-msvc

Uma pegadinha de cross-compilation: se você compila ARM dentro de uma máquina x86 (via cross), você não consegue rodar os testes daquele binário ali, porque a arquitetura não bate. A solução é rodar os testes só no alvo nativo e cross-compilar o resto sem testar. O ai-usagebar faz exatamente isso, x86 nativo e ARM via cross, na matriz do release.yml dele. E sempre use cache de compilação: o Swatinem/rust-cache corta o tempo de build pela metade fácil.

Release notes e changelog importam

Aqui é onde muita gente relaxa, e não devia. Quando você solta uma release, a pessoa que está pensando em atualizar quer saber o que mudou. “v0.5.0” não diz nada. Um changelog diz.

Eu mantenho um CHANGELOG.md no formato Keep a Changelog, com uma seção por versão. E o pipeline extrai automaticamente a seção da versão atual pra colar no corpo do GitHub Release. Um awk simples resolve:

awk -v ver="$VERSION" '
  BEGIN { hdr = "## [" ver "]" }
  index($0, hdr) == 1 { flag=1; next }
  flag && index($0, "## [") == 1 { exit }
  flag { print }
' CHANGELOG.md > changelog_section.md

Esse awk é o mesmo que roda na release do ai-usagebar (de novo no release.yml dele, que é o meu mais caprichado nessa parte). Aí eu anexo, depois do changelog, as instruções de instalação e os checksums sha256 de cada artefato. O resultado é um GitHub Release que se explica sozinho: o que mudou, como instalar, e como verificar a integridade do download. O usuário lê e decide se atualiza. Esse é o tipo de cuidado que faz um estranho confiar no seu projeto.

Pilar 3: Deploy de verdade, sem complicação

Os projetos que rodam como serviço (os Rails, principalmente) precisam ir pra algum lugar. E aqui eu vou na contramão do hype. Não tem Kubernetes. Não tem Kamal. Não tem pipeline de deploy de três estágios com aprovação manual.

Eu tenho um home server. Um Minisforum MS-S1 Max rodando openSUSE MicroOS que eu migrei recentemente, com um Gitea servindo de registry Docker privado na porta 3007. Pra um desenvolvedor solo com um servidor caseiro simples, isso é mais que suficiente. Toda a cerimônia de orquestração de cluster é resolver um problema que eu não tenho.

O deploy inteiro cabe num único bin/deploy. Ele faz três coisas: builda a imagem, empurra pro registry, e dá um SSH no servidor pra subir a versão nova:

#!/usr/bin/env bash
set -euo pipefail

# Config vem de um arquivo .gitignored, fora do repositório
source "$(dirname "$0")/../config/deploy.env"

IMAGE="${REGISTRY_HOST}:${REGISTRY_PORT}/akitaonrails/frank_fbi:latest"

echo "==> Buildando a imagem..."
docker build -t "$IMAGE" .

echo "==> Empurrando pro registry..."
docker push "$IMAGE"

echo "==> Subindo no servidor..."
ssh "${DEPLOY_USER}@${DEPLOY_HOST}" \
  "cd ${REMOTE_DIR} && \
   docker compose pull && \
   docker compose down --remove-orphans && \
   docker compose up -d"

É isso. build, push, ssh com pull, down, up. Quatro comandos no servidor remoto, encadeados num SSH só. Sem agente rodando lá, sem webhook, sem painel de controle. O servidor tem um docker-compose.production.yml que aponta pra imagem :latest do registry, e o pull traz a versão nova.

Repara que os dados sensíveis ficam num config/deploy.env que não vai pro Git. No repositório vai só o config/deploy.env.example, com a estrutura e valores fictícios. Esse padrão de “exemplo versionado, real ignorado” se repete em todo projeto meu, e é o que permite o projeto ser público sem vazar host, usuário ou caminho do meu servidor.

A imagem em si vem de um Dockerfile multi-estágio. O estágio de build instala as ferramentas de compilação, builda tudo, e o estágio final copia só o resultado pra uma imagem enxuta, rodando como usuário não-root. O compose de produção troca build: por image:, aponta os volumes pros caminhos persistentes do servidor (/var/opt/docker/...) e usa restart: always pra subir tudo de novo se o servidor reiniciar.

E de novo a beleza da padronização: como todo projeto meu tem esse mesmo bin/deploy, eu posso falar pro Claude Code “faz o deploy do Frank FBI” e ele sabe exatamente o que rodar. Não preciso lembrar de comando nenhum. A ferramenta é a documentação executável do processo.

A lição: ninguém liga pra sua stack

Agora a parte que eu mais queria escrever, e que vale mais que todos os snippets de YAML acima.

A maioria das pessoas, quando vai apresentar um projeto, concentra tudo na tecnologia. “Olha meu banco vetorial novinho.” “Olha meu framework reativo de última geração.” “Usei tal arquitetura de microsserviços.” E enchem o topo do README com isso: a lista de dependências, o diagrama de componentes, a stack.

Ninguém liga.

Sério. O usuário que chega no seu README não quer saber qual banco de dados você usou. Ele quer saber que problema isso resolve pra ele. Detalhe de implementação não pertence ao topo do README. Pertence ao docs/, pra quem vai contribuir. No README, o que importa é o caso de uso.

Olha a diferença. “Servidor MCP em Rust com FTS5 e consolidação opcional via LLM” não diz nada pra ninguém. Agora “memória de longo prazo compartilhada entre Claude Code, Codex e Cursor, com handoff entre sessões” — isso o cara entende na hora, porque é a dor que ele tem. Os dois descrevem o ai-memory. Um fala de tecnologia, o outro fala do problema resolvido.

O caso de uso é a coisa mais importante do projeto inteiro. Antes de escrever uma linha de código, a pergunta certa é “que problema isso resolve, e pra quem?”. Se você não consegue responder isso numa frase, você está construindo uma solução em busca de um problema. E solução em busca de problema é, na prática, solução que não resolve nada. Não importa quão elegante seja o código por dentro.

A camada de UX, a superfície que o usuário toca, vale muito mais que a engenharia interna. Um projeto com tecnologia medíocre mas que é trivial de instalar, que diz claramente que problema resolve, e que tem documentação honesta, vai mais longe que um projeto genial que ninguém consegue rodar. Toda vez.

Então o mínimo, o verdadeiro mínimo pra um projeto de código aberto, é isto: instalação fácil, CI que dá confiança, documentação que começa pelo problema. O algoritmo bonito vem muito depois disso na fila de prioridades. Os três pilares deste post existem pra servir uma coisa só, que é a experiência de quem chega de fora. Acerta isso primeiro. O resto é detalhe de implementação.

O Problema

Antes, pra contribuir no blog você precisava:

1. Instalar Hugo Extended
2. Instalar Go
3. Instalar Ruby
4. Configurar todas as dependências
5. Gerar o índice de posts manualmente

Isso criava barreiras pra novos contribuidores e podia causar conflitos com outras instalações no sistema. Um inferno.

A Solução: Docker

Agora você só precisa do Docker e Docker Compose. Tudo o resto roda em containers isolados.

Setup Rápido

# Clone o repositório
git clone https://github.com/akitaonrails/akitaonrails.github.io.git
cd akitaonrails.github.io

# Inicie o ambiente
./scripts/dev.sh start

# Acesse o blog
open http://localhost:1313

Pronto! O blog está rodando e você pode começar a contribuir.

Comandos Úteis

O projeto inclui scripts que facilitam o desenvolvimento:

# Ver todos os comandos disponíveis
./scripts/dev.sh help

# Criar um novo post
./scripts/dev.sh new-post "Título do Meu Post"

# Ver logs do servidor
./scripts/dev.sh logs

# Gerar índice de posts
./scripts/dev.sh generate-index

# Parar o ambiente
./scripts/dev.sh stop

Criando um Post

Criar um novo post é super simples:

./scripts/dev.sh new-post "Como Contribuir no Blog do AkitaOnRails"

O script automaticamente:

• Cria a estrutura de diretórios com a data atual
• Gera um arquivo index.md com front matter básico
• O servidor Hugo recarrega automaticamente

Estrutura de um Post

O arquivo criado terá esta estrutura:

---
title: "Título do Post"
date: "2025-08-29"
draft: false
description: "Descrição do post"
tags: [tag1, tag2]
categories: [categoria]
---

Conteúdo do post aqui...

Vantagens do Docker

Para Contribuidores

• Setup rápido: Apenas Docker necessário
• Ambiente isolado: Não interfere com sistema local
• Hot reload: Mudanças aparecem automaticamente
• Reproduzível: Funciona igual para todos

Para o Projeto

• Menos issues: Ambiente consistente
• Mais contribuidores: Barreira de entrada menor
• Manutenção: Fácil de atualizar dependências

Como Funciona

O ambiente Docker inclui:

• Hugo Extended: Gerador de sites estáticos
• Go: Para módulos Hugo
• Ruby: Para script de geração de índice
• Volumes: Para hot reload dos arquivos

O docker-compose.yml mapeia os diretórios locais para o container, então quando você edita um arquivo, o Hugo detecta a mudança e recarrega automaticamente.

Desenvolvimento Local (Alternativa)

Se preferir não usar Docker, ainda é possível instalar tudo localmente:

# Gerar índice
cd content && ruby generate_index.rb

# Rodar servidor
hugo server --logLevel debug --disableFastRender -p 1313

Mas o Docker é muito mais prático!

Próximos Passos

1. Teste o ambiente: Execute ./scripts/dev.sh start
2. Crie um post: Use ./scripts/dev.sh new-post
3. Explore o código: Veja como personalizar layouts
4. Contribua: Faça um Pull Request

Dica: O ambiente Docker salva automaticamente suas mudanças e recarrega o servidor. Basta editar os arquivos e ver as mudanças em tempo real! 🚀

Eu gostei bastante das escolhas do DHH, ele sempre foi um cara de Mac, eu também. Mas eu migrei de volta pra Linux quase 10 anos atrás. O motivo foi porque eu evangelizava tech pra desenvolvedores júniors e no Brasil ficou inviável incentivar Macs. E não queria que parecesse que sem usar Macs você estaria automaticamente em grande desvantagem. Então passei a usar exclusivamente Linux e no blog fiz vários posts explicando sobre isso, como estes:

• 2015 - Situação Brasil: No Macs for the Rest of Us
• 2016 - The Year of Linux on the Desktop, by Microsoft ??
• 2017 - Off-Topic - Why are we all moving away from Apple?

Sem contar os diversos videos com setups que fiz no meu canal, como estes:

• O Guia Definitivo de Ubuntu pra Devs Iniciantes
• O Melhor Setup Dev com Arch e WSL2

Em 2024, com exceção se precisa desenvolver apps pra iOS ou coisas específicas de .NET, usar distros Linux é superior a usar Windows ou MacOS. Antigamente eu diria um “mas” se quiser jogar, aí seria obrigado a fazer dual-boot com Windows. Mas até isso Linux já superou Macs graças aos esforços da Valve e as comunidades open source em torno de projetos como Proton. Hoje, uma quantidade absurda de jogos novos de PC rodam liso em Linux, basta instalar Steam e já era.

Não é o tema do artigo, mas já que toquei no assunto, estava justamente assistindo um review do BazziteOS rodando no Asus ROG Ally (meu favorito), criando um Steam Deck ainda mais potente. É Fedora rodando num handheld, com uma interface tão boa que ninguém sabe que é Linux por baixo, rodando jogos com mesma performance que em Windows. É impressionante mesmo. Quem ficou totalmente pra trás em games foi a Apple.

Isso tudo dito, o DHH mudou pra um hardware muito bacana de uma empresa pequena e nova chamada Framework, que faz notebooks modulares. A idéia é não precisar jogar tudo fora quando quiser fazer upgrades de hardware. Só trocar o módulo pra um mais novo. E não só coisas simples como trocar uma porta USB-A por uma USB-C, mas até trocar GPU, trocar placa-mãe, monitor.

É um conceito muito bacana que eu gostaria que mais fabricantes se comprometessem a fazer. Evita lixo eletrônico desnecessário, pra começar, muito mais fácil de reparar partes, sem ter que jogar tudo fora, como acontece com um Macbook. Vi isso pela primeira vez no canal do Linus Tech Tips porque o Linus Sebastian se tornou um dos primeiros investidores anjo deles.

A maioria dos fabricantes que suportam Linux, costumam oferecer algum tipo de suporte a Ubuntu. Ele acabou meio que se tornando o “padrão” de Linux pra usuários comuns. Na dúvida, instale Ubuntu. E não é uma má escolha. Se escolher Ubuntu, use o projeto Omakub oficial do DHH, que vai configurar tudo bonitinho pra você.

Eu não gosto de Ubuntu, é uma escolha pessoal (e cada um de Linux vai ter sua própria opção. Já sei que o primeiro comentário vai ser alguém falando de porque todo mundo não usa NixOS de uma vez …). Não precisa ficar preocupado nem se sentir mal por usar Ubuntu, não tem absolutamente nada de errado com ele. Escolher distros é que nem escolher marca de carro. Qual a diferença de Ferrari, Lambo, Porsche, McLaren? Você vai achar ruim se prefere Lambo e eu prefiro McLaren?

Além disso, puristas vão dizer que é pra ficar no Arch Linux puro, mas faz anos que prefiro Manjaro GNOME no meu PC desktop e em notebook prefiro ficar com Windows 11 mesmo e WSL2 rodando ArchWSL. Ainda recomendo brincar com Arch puro pra aprender. Mas depois de tantos anos, como é meu caso, prefiro um instalador que faz igual Ubuntu: vai do zero ao desktop em poucos cliques.

Então não teve jeito, fui obrigado a fazer um fork e ajustar o Omakub num novo projeto, o OMAKUB-MJ (o nome não tá muito correto, deveria ser algo como OMAKAMJ ou algo assim que seria Omakase com Manjaro, mas fica feio, mandem sugestões nos comentários). Migrei todos os comandos de Apt pra Yay, além de diversos outros ajustes. Rodei no meu PC principal (depois de ter testado bastante numa VM, claro) e agora ficou bonitão assim:

Igual à versão de Ubuntu, ele ativa o tema Tokyo Night, mas dá pra mudar pra vários outros temas. Depois de instalado, vai ter um comando omakub no terminal que abre um menu com várias opções, incluindo mudar tamanho das fontes ou trocar temas:

Tem MUITAS coisas legais pré-instaladas, por isso repito pra ler o manual que é muito bonito, bem escrito, e eu não mudei nenhuma das configurações principais (só o zellij, já explico), então tudo que vale pra versão Ubuntu também vale pra Manjaro. E eu sei que a maioria de vocês tem preguiça de abrir o manual, mas uma coisa que o DHH sabe fazer é uma documentação atraente:

Migrando pra Manjaro

Enfim, pra migrar de Ubuntu pra Manjaro, a primeira coisa que fiz foi trocar comandos apt por yay, coisa simples assim:

- sudo apt install -y alacritty
+ yay -S alacritty --noconfirm

Mas rapidamente encontramos as partes de porque eu prefiro o YAY do que APT como gerenciador de pacotes:

-  sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg
-  echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg] https://brave-browser-apt-release.s3.brave.com/ stable main" \| sudo tee /etc/apt/sources.list.d/brave-browser-release.list
-  sudo apt update -y
-  sudo apt install -y brave-browser
+  yay -S brave-browser --noconfirm

Em Ubuntu, tudo que a própria Canonical não controla, fica em repositórios de terceiros, então precisamos explicitamente adicionar esses repositórios antes de conseguir instalar seus pacotes.

Em Arch é a mesma coisa, com o Pacman só conseguimos instalar os pacotes oficiais que o grupo do Arch controla e testa. Mas existe um repositório de terceiros chamado AUR, o Arch User Repository. Daí instalamos ferramentas como Pamac (que vem instalado em muitas distros) ou o Yay (que eu gosto mais). Por baixo eles rodam Pacman, mas oferecem um único comando que serve pros dois: instalar pacotes oficiais e instalar pacotes do AUR, com os mesmos comandos. Então não tem que ficar manualmente gerenciando trocentos repositórios externos.

Foi bem fácil converter porque no AUR tem tudo que precisamos. É muito raro precisar de um software e não achar no AUR. Além disso fiz outra modificação: eu prefiro manter aplicativos gráficos como Spotify ou Discord instalados via Flatpak.

Não é nem por razões de segurança. Prefiro que aplicativos de terceiros mexam no sistema operacional abaixo o menos possível. E muitos deles precisam de várias dependências. Quando preciso fazer um upgrade geral, demora mais porque vem um monte de pacotes de dependência junto que eu nem precisava. Pelo menos com Flatpak, as dependências ficam isoladas em imagens de containers.

Enfim, quando preciso atualizar o sistema só faço yay -Syyuu e quando quero atualizar aplicativos, basta fazer flatpak update -y, assim posso rodar separadamente. As únicas exceções são editores de texto como Visual Studio Code, nesse caso prefiro que ele tenha acesso ao sistema de arquivos todo mesmo, e não ter que lidar com permissões de acesso em containers de Flatpak, por isso instalo via Yay.

GNOME

Adicionei dois aplicativos opcionais, o Bitwarden (o DHH prefere o 1password, ambos são bons) e o Discord. Aplicativos de Flatpak são fáceis de instalar, nem precisa estar num instalador como esse, mas coloquei só mais esses por conveniência pra mim mesmo. Obviamente você pode instalar depois o que quiser. Basta procurar com flatpak search e instalar com flatpak install.

No lado Gnome, o DHH escolheu apps como Flameshot pra substituir o app de screenshot do Gnome. Uma das vantagens é que depois de tirar a foto de tela, dá pra imediatamente editar a imagem antes de salvar. Pra ter preview rápido de imagens no gerenciador de arquivos Nautilus, ele escolheu o Gnome Sushi. Todas essas opções são muito boas e você pode ver tudo que é instalado no desktop no diretório install/desktop. Cada app é um script separado.

De todos, o único que realmente não conhecia é o Localsend. Mas agora já instalei no meu Linux, Windows, smartphone e tudo mais. É o jeito mais fácil de transferir arquivos entre máquinas na mesma rede. Igual o Airdrop de iPhone. Vale a pena ter instalado em tudo.

Outro app que eu não conhecia é o Ulauncher que é um executador de aplicações, igual a barra de Spotlight de Mac. Basta apertar Super/Tecla de Windows + Espaço e ele abre uma barra onde podemos digitar o nome do app que queremos abrir:

Se fosse só isso, não é muito útil porque em Gnome, só de apertar Super já dá pra digitar o nome de apps. Mas o interessante é que ele faz mais que executar apps. Depois fuce a Página de Extensions pro Ulauncher. Tem coisas como calculadoras, controlador de Spotify, pesquisador de arquivos, facilitador pra editores com Obsidian ou Notion, pesquisador de snippets de código pra VS Code, tradutores, integradores pra serviços de GPT e um dos meus favoritos, facilitador de Emojis:

O Omakub ajusta bastante coisa do Gnome. Em particular adiciona várias extensions que mudam o comportamento do ambiente gráfico:

Depois vale fuçar as configurações de um por um. Por exemplo, ele instala e já configura a extension Tactile que é provavelmente a melhor pra organizar as janelas em “tiles” ou “azulejos”, ou seja, pra facilitar alinhar uma janela em cima ou do lado da outra de forma proporcional. Ele faz isso pré-dividindo a tela em áreas e atribuindo letras a cada área, assim fica fácil de fazer uma janela se encaixar numa dessas áreas.

Por exemplo, com o comando Super + T aparece esse grid. Se digitar “w” duas vezes, minha janela de Alacritty se encaixa no topo, no meio, na área marcada com “W”:

Normalmente, eu gosto de ter a janela aberta no meio do monitor, maximizado na vertical, sem esticar pros lados, especialmente pra ler ou digitar textos. Então posso fazer Super + T e logo depois W e S pra marcar duas áreas:

Mas também continuo podendo teclar F11 ou Super + seta pra cima pra maximizar a janela na tela inteira. Ou usar as combinações clássicas de Windows como Super + seta esquerda ou Super + seta direita pra fazer a janela usar metade vertical da tela, desta forma:

Vale fuçar a documentação e as configurações da extension Tactile pra dividir as áreas do jeito que mais gosta. Isso vai variar bastante caso use monitor secundário na vertical, ou use monitor Ultra Wide. E nesse caso é onde esse tipo de extensão vai fazer mais diferença pra manter suas janelas organizadas.

Neovim e LazyVim

Eu mencionei Visual Studio Code, e ele está aqui pra quem gosta, mas quem acompanha meus videos e artigos, sabe que sou usuário de Vim de longa data. E a comunidade Vim não pára quieta. Hoje em dia tem um fork mais moderno, o NEOVIM, que se tornou o mais usado.

Em cima do NeoVim podemos instalar plugins manualmente e ficar ajustando configuração pela eternidade, ou usar configs já prontas. Até poucos meses atrás eu usava o LunarVim, mas ele meio que caiu em desuso. Depois passei a usar o AstroNVIM, que resolve muito bem, mas parece que a maioria das pessoas passou a convergir pro LazyVim. Confesso que fico em dúvida entre qual é o melhor, AstroNvim ou LazyVim, mas vou ficar com o LazyVim por enquanto.

No fundo vão usar muitos dos mesmos plugins, análise de código vai ter plugins pra LSP, navegação vai ter o mesmo neo-tree, o mesmo telescope e assim por diante. Por isso vai ser muito subjetivo mesmo. Acho que nenhum dos dois tem como errar.

Muita gente acha que esses pacotes são contra a filosofia de “aprenda a configurar você mesmo”. E de fato, se puder, recomendo mesmo que monte sua configuração do zero. Mas faça isso só uma vez, desfaça e use um desses pacotes. Na realidade, essa noção começa a falhar porque esses plugins, sejam eles escritos no antigo VimScript ou na mais moderna linguagem Lua, são programas completos. Pegue plugins como Neo-Tree ou Telescope. Você não fez nem nunca vai fazer nenhum deles do zero, isso é pra poucos.

Na prática, o NeoVim já poderia vir pré-instalado com eles, pra você não faria diferença, porque são modernos, bem escritos, customizáveis, e não ficam no seu caminho. Não vem porque a idéia toda de um Vim é ser hiper-leve, pra podermos usar rapidamente dentro de um container, ou conectando num outro servidor via SSH, sem GUI, sem dependências, se bugs de interface nem nada disso. Só no nosso desktop, em ambiente controlado, gostaríamos dele tão pesado e funcional quanto um VS Code.

Depois tente dar uma olhada na configuração de um LazyVim, é muito mais coisa do que uma única pessoa deveria se preocupar. E saem plugins novos todos os dias, plugins antigos deixam de ser usados, não tem como você ficar de olho em tudo isso. Melhor ser um esforço dividido pela comunidade e a gente ter a oportunidade de usar o que tem de melhor só dando um update.

Sinceramente, seja Astronvim ou LazyVim, eu não tenho nem vontade e nem disposição de tentar montar do zero uma config como essa. E o que eles me oferecem “out-of-the-box” está perfeito já, eu não preciso ficar mudando. Basta usar. Você tem que ser muito chato pra achar que pode fazer melhor. Se achar isso, faça um pull request pra esses projetos então. Será tempo melhor gasto.

ZelliJ

Eu sou usuário de Tmux de longa data. E meus amigos usavam o antigo Screen, antes disso ainda. Eu lembro quando falávamos do Tmux como o software mais moderno. Agora ele é o legado e o mais moderno é o ZelliJ.

Todos eles são gerenciadores de sessão. Pense quando você se conecta num servidor remoto via SSH e fica trabalhando nele. Daí temos uma pane na internet ou cai a luz. O que acontece? Não só a conexão fecha, mas seja lá o que você estava rodando remotamente vai crashear porque o app está atrelado - é um filho - da sua shell (bash, zsh). E sua shell estava atrelada à sessão SSH. Quando a conexão cai, o SSH mata o shell que mata sua app. Você perde o que estava fazendo ou, pior, se o programa estava no meio, ele vai crashear no meio e pode corromper alguma coisa.

Em vez de correr esse risco, quando logar via SSH, imediatamente abra uma sessão de Screen, Tmux ou Zellij. Agora o shell vai abrir atrelado ao Zellij. Se a conexão cair e o SSH fechar, o ZelliJ vai continuar rodando, ele fica atrelado a um daemon na máquina remota. Seu shell e seu app ficam atrelados ao ZelliJ e não à sua sessão SSH.

Quando a luz voltar ou a internet voltar, basta conectar via SSH de novo e rodar o comando zellij attach ou tmux attach e ele vai “re-anexar” à última sessão de apps, e você vai voltar ao seu shell, como se nunca tivesse saido de lá. Quaisquer apps que estivessem rodando e processando, ia continuar até acabar, normalmente, como qualquer app em background. Essa é a vantagem principal de um gerenciador como ZelliJ ou Tmux.

Mesmo se não estiver trabalhando numa máquina remota via SSH. Mesmo no seu desktop. Digamos que esteja brincando de editar configurações, instalar extensions e coisas assim. E do nada seu GNOME ou seu X resolvam dar pau, crashear e reiniciar. Todos os apps gráficos vão crashear junto, incluindo seu app de terminal, como Alacritty e junto com ele, qualquer shell e programa em linha de comando que estivesse rodando, como seu NeoVim, podendo perder código que estava editando e não salvou.

Não mais. Quando o X reiniciar, basta reabrir seu Alacritty e, mesma coisa, fazer um zellij attach pra voltar exatamente onde estava. Inclusive, se dentro do zellij você estava remotamente conectado a um servidor, monitorando com htop ou algo assim, nada vai fechar, vai continuar tudo conectado. Isso é mais uma camada de estabilidade pra você.

Veja este exemplo abaixo:

O Omakub já configura o ícone do Alacritty pra abrir uma janela de ZelliJ. Se seguir a configuração padrão, teclando Ctrl P D, sendo “P” pra Painel e “D” pra “D"ividir a janela horizontalmente, dá pra abrir dois programas um em cima do outro.

ATENÇÃO: este é o único app do Omakub que fui obrigado a mudar os shortcuts, por isso o que tem na documentação oficial não vai bater.

O problema é o seguinte: vários apps de terminal, como NeoVim, tem vários shortcuts de navegação. Se digitar “Espaço + E” vai abrir o painel de exploração do Neo-Tree na esquerda. Dá pra navegar por diretórios usando “J” ou “K” pra ir pra cima ou pra baixo e “Enter” pra abrir os diretórios ou abrir arquivos.

Quando o arquivo abre, ele abre num painel na direita. Mas como você navega entre os painéis? Basta digitar Ctrl + H ou Ctrl + L (lembrando que em Vim as “setas” são as telas da home row da mão direita H J K L). Só que se você estiver dentro do ZelliJ, isso não vai funcionar. Isso porque o ZelliJ em si usa o modificador Ctrl pra ele. Então ele engole o comando e não passa pro NeoVim.

Uma das soluções é que o ZelliJ, assim como NeoVim, tem “modes”. Vim tem modo normal, modo de edição e modo visual. ZelliJ tem vários modos, como modo normal, modo de scroll, modo de painel e cada modo tem seu sub-conjunto de shortcuts/combinações de teclas. Um desses modos é “Locked”. Podemos travar o zellij, daí usar o programa dentro do painel isoladamente, e lembrar de ficar “desbloqueando” o zellij. É meio chatinho de ficar fazendo isso.

Outra solução é o que eu fiz no Omakub-MJ. Eu adicionei as configurações do usuários de GitHub “shoukoo” que fez um artigo um tempo atrás chamado ZelliJ 💓 NeoVim. A configuração completa dele está neste arquivo. Mas em resumo, ele cria um modo especial que batizou de “modo tmux”.

Pra entrar nesse modo, precisa digitar primeiro Ctrl f e na barra inferior, dá pra ver mudando de modo Normal pra Tmux:

E agora sim, podemos digitar comandos como P D pra dividir painel. E fazendo isso, enquanto estiver no modo Normal mesmo, dentro do Neovim, combinações como Ctrl H ou Ctrl L vão funcionar normalmente. Win-win!

Só lembrar que, se na documentação oficial do zellij/omakub ele mandar digitar Ctrl P W pra abrir um painel flutuante, agora vai ser Ctrl + F e depois P W. E ele chama de “modo tmux” porque em Tmux, todo comando é depois de digitar Ctrl + B antes. No caso ele escolheu Ctrl + F pro ZelliJ, mas é arbitrário, poderia ser qualquer combinação inicial.

O resto continua funcionando igual. Pra navegar entre os painéis de ZelliJ, só digitar Alt + H ou Alt + K como no NeoVim, mas usando Alt em vez de Ctrl. Pra salvar a sessão atual e sair do ZelliJ, só fazer Ctrl + F, O D e quando voltar, só digitar Ctrl + F, O W pra listar as sessões salvas (sim, dá pra ter várias), e restaurar a que quiser com Enter.

Como o manual do Omakub recomenda, vale estudar a documentação oficial do ZelliJ.

ASDF pra MISE

Finalmente, uma das ferramentas que eu usei por mais anos foi o ASDF. Quem já programa em Node, Ruby, Python, etc já teve que usar algo como NVM, RVM ou RBenv, VENV ou Conda e assim por diante.

O mundo ideal é que todo mundo sempre usasse a versão mais nova de tudo, toda linguagem, toda biblioteca, tudo. Mas isso é inviável. Um bom programador vai acumular vários projetos na sua máquina, cada um vai estar numa versão diferente.

Ano retrasado ele trabalhou num projeto em Node na versão 16. Hoje está trabalhando num projeto novo na versão 22. Mas do nada, teve a necessidade de rodar esse projeto antigo. E agora? Ele atualizou tudo e só tem o node 22. Se desinstalar e instalar o 16 pra rodar o antigo, como fica o projeto novo? E as bibliotecas, como fica seu diretório de NPM? Uma zona completa.

Pra conseguir ter várias versões de node instaladas em paralelo na mesma máquina, recomenda-se usar NVM, que é o Node Version Manager.

Mas você é um programador poliglota. Trabalha em projetos em várias diferentes linguagens. Vai ter que aprender os comandos individuais de gerenciar versão pra cada linguagem? NVM pra Node. VENV pra Python. RVM pra Ruby, o que usa pra Java? Fodeu.

Pra isso criaram projetos como o antigo ASDF. Com ele era muito simples, bastava fazer asdf install nodejs 14.21.3 pra instalar uma versão antiga de node e depois asdf local nodejs 14.21.3 dentro do diretório do projeto antigo. Ele cria uma arquivo .tool-versions declarando a versão de nodejs pra esse diretório e quando entramos nele, o asdf detecta e já muda o que precisa pra poder usar a versão certa. Super conveniente.

Mais conveniente ainda porque podemos usar o mesmo conjunto de comandos pra qualquer linguagem. Basta instalar o plugin da linguagem com asdf plugin add java por exemplo. E ele suporta dezenas de linguagens, até as mais exóticas que você nunca ouviu falar. É o verdadeiro canivete suíço de gerenciamento de linguagens.

E esse seria o fim da história. Hoje mesmo, se você já usa ASDF, pode continuar usando, não tem nenhum problema com ele. Mas você conhece o povo de Rust: eles querem reescrever tudo em Rust. O Omakub mesmo instala vários substitutos como o “exa” que substitui “ls” e é feito em Rust. Tem vários assim.

No caso, existe o novo Mise de “mise-en-place”, pra quem já assistiu Masterchef. É exatamente a mesma coisa que ASDF só que feito em Rust. Inclusive ele é compatível com o mesmo arquivo .tool-versions que mencionei antes. Se não tiver, ele gera arquivo com nome próprio .mise.local.toml porque, claro, YAML ou JSON são antigos, o negócio é usar TOML …

Ele simplifica os comandos, mas não necessariamente acho que ficaram mais intuitivos. Mas é bem simples. Digamos que eu precise do tal Nodejs antigo, basta fazer mise install node@14.21.3 ou direto mise use node@14.21.3 pra instalar e já escolher pra usar.

Dá pra configurar versões locais pra cada diretório de projeto com mise use --env local node@14.21.3. E essa sintaxe de “@” é pra permitir instalar mais de uma versão num único comando, por exemplo mise install ruby@3.1 nodejs@22.3.0.

Mesma coisa como asdf, também podemos configurar a versão global padrão, caso não tenha arquivos como .tool-versions no diretório, fazendo mise use --global nodejs@22.3.0. Pra listar o que tem instalado, só fazer mise ls.

Enfim, vale estudar a documentação oficial. No geral é uma ótima ferramenta e um bom substituto pra ASDF. Mas ele é tão parecido com ASDF que, se já estiver acostumado, não tem necessidade de mudar. Não tem nada a mais que ele faça que eu fosse sentir falta se não tivesse. Povo de Rust tem que parar de ficar substituindo as coisas pra fazer exatamente a mesma coisa. Era melhor gastar esse tempo ajustando e mandando patches pro próprio ASDF. Só dividiu os esforços da comunidade em duas ferramentas que fazem a mesma coisa.

Últimas Considerações - Atuin

Uma última coisa, é que eu adicionei a ferramenta Atuin “Magical Shell History”. Ele substitui o histórico do seu shell (sabe, aquele que você pode digitar “Ctrl + R” e procurar a linha de comando?) que normalmente é gravado em arquivo texto e manda pra um banco de dados SQLite3.

Só isso já seria legal, pra tirar as limitações de arquivo texto e evitar corromper e perder histórico. Mas além disso ele tem um serviço que permite sincronizar seu histórico entre diferentes máquinas. Digamos, seu PC desktop de casa, seu notebook de trabalho, seu servidor remoto. Hoje em dia todos tem históricos isolados e diferentes. E se desse pra sincronizar todos?

Aquele dia que você esquece seu notebook no trabalho, está no PC de casa e fica “puts, quais eram mesmo aqueles comandos de docker que eu fiz no trabalho??” Agora tem com, basta fazer atuin sync e pronto, seus históricos sincronizam!

Pra isso, no script de instalação eu rodo o atuin register que pede um username, email e uma senha (que, se não me engano, vai servir pra encriptar seus dados). E pronto, já vai sozinho se virar pra ficar sincronizando. Se já tinha conta, numa máquina nova basta rodar atuin login e logar. Só isso.

Ele substitui o Ctrl + R pra pesquisar no sqlite3 e agora seu histórico será muito mais robusto. Eu imagino que isso é mais importante ainda pro povo de devops. Eu lembro que rodava trocentos comandos de pods e containers e usava MUITO o histórico pra lembrar das coisas e repetir comandos. Fucem a documentação, tem como montar seu próprio servidor de Atuin pra onde sincronizar. Mesmo estando encriptado, talvez você queira 100% de controle. Tem como.

E por hoje é isso. Eu gostei bastante de brincar com o Omakub-MJ e meu PC pessoal com Manjaro GNOME e meu notebook com Windows 11 + ArchWSL já estão usando tudo exatamente como expliquei aqui. Novamente, leiam o Manual do Omakub escrito pelo DHH, usem o Omakub dele caso estejam em Ubuntu, usem o meu fork pra Manjaro e Arch e não deixem de mandar Pull Requests ou Issues lá.

DESCRIPTION

Muita gente acha que é defensor do Software Livre, mas na realidade não é.

Pior ainda, por simplesmente só acreditar que está defendendo um movimento social, no final você está só defendendo o marketing de empresas e nem se dá conta disso. Nem é uma coisa completamente ruim, mas certamente não é o que sua crença diz.

Então hoje eu vou desmistificar o que é software livre, open source e como as grandes corporações te enganaram. A idéia não é ser um vídeo completo sobre o assunto, somente sobre os temas que eu acho mais importantes pra começar.

Links:

• Affero General Public License (https://en.wikipedia.org/wiki/Affero_General_Public_License)
• What is free software? (https://www.gnu.org/philosophy/free-sw.html)
• The JavaScript Trap (https://www.gnu.org/philosophy/javascript-trap.html)
• The quietly accelerating adoption of the AGPL (https://www.synopsys.com/blogs/software-security/using-agpl-adoption/)
• What’s a SaaS to Do? The SaaS Loophole in GPL Open Source Licenses (https://resources.whitesourcesoftware.com/blog-whitesource/the-saas-loophole-in-gpl-open-source-licenses)
• Google open source guru: ‘Why we ban the AGPL’ (https://www.theregister.co.uk/2011/03/31/google_on_open_source_licenses/)
• Can I use the middleman loophole to reduce AGPL to LGPL? (https://opensource.stackexchange.com/questions/5010/can-i-use-the-middleman-loophole-to-reduce-agpl-to-lgpl)
• Managed Cassandra on AWS, Our Take (https://www.scylladb.com/2019/12/04/managed-cassandra-on-aws-our-take/)
• AWS and Open Source: It’s Complicated (https://www.redislabs.com/blog/aws-vs-open-source/)
• Choose an open source license (https://choosealicense.com/)
• Why Open Source misses the point of Free Software (https://www.gnu.org/philosophy/open-source-misses-the-point.en.html)
• How to decide whether to open source your SaaS solution (https://opensource.com/article/18/5/open-source-saas-y-world)
• Explaining The Fair Use Principle for Copyrighted Work (https://www.thebalancesmb.com/fair-use-of-copyrighted-work-explained-4771134)
• Copyright Definition (https://www.thebalancesmb.com/copyright-definition-2948254)
• YouTuber Extortion? MxR Plays v. Jukin - Real Law Review // LegalEagle (https://www.youtube.com/watch?v=5A_i-sB9H0Q)

AkitaOnRails:

• [Off-Topic] Software Livre: Exercício de CAPITALISMO (https://www.akitaonrails.com/2016/04/22/off-topic-software-livre-exercicio-de-capitalismo)

SCRIPT

Olá pessoal, Fabio Akita

Eu acabei pulando o carnaval e não publicando video semana passada. Eu fiquei em dúvida entre dois temas e qual eu ia falar primeiro e os dois são trabalhosos pra explicar. Então deixei o assunto maturar na minha cabeça um pouco mais de tempo. O tema que eu escolhi falar foi sobre software livre. O problema é que software livre é um puta tema espinhoso. Se eu escolher palavras um pouco ambíguas, vai chover hater nos comentários porque todo mundo tem uma opinião forte sobre o assunto e na grande maioria das vezes elas estão erradas ou no mínimo incompletas.

O motivo desse tema é que de vez em quando ainda me perguntam qual é a vantagem de mexer com software livre. As respostas mais comuns, de fato acabam sendo alguma coisa como “pra ajudar a comunidade” ou “pra outros poderem te ajudar”. Não está completamente errado, mas não é só isso. E pensando um pouco mais no assunto, eu vejo que os motivos vão ser completamente diferentes pra pessoas e situações diferentes. Então acho que primeiro eu preciso explicar os mecanismos por baixo e daí você pode tirar conclusões melhores. Na realidade, pra variar, eu quero quebrar algumas concepções erradas que eu sei que muitos iniciantes ainda tem.

Eu já expliquei alguns dos elementos dessa novela, por exemplo, no video da Lerna vs ICE eu expliquei a diferença entre licenças permissivas e restritivas e a impossibilidade de mudar licenças retroativamente. E no vídeo sobre a Apple e GPL eu explico sobre como o GPLv3 que foi criado pra brigar contra DRM no episódio da Tivoização levou a Apple a migrar do compilador GCC para clang e evoluir o LLVM até sair a linguagem Swift.

Eu acho fascinante acompanhar as diversas novelas jurídicas e discussões filosóficas em torno de software livre e como você é facilmente enganado por ideologia barata se não parar pra ler além da propaganda. Por exemplo, talvez você ache que é um defensor do software livre usando Linux e programas de código aberto todo dia. Mas você não é 100% dentro da ideologia se navega em qualquer site moderno que executa Javascript. Já pensou porque?

(…)

Deixa eu começar com esse ponto que eu acho irônico. Muita gente pensa que usar Javascript é a mesma coisa que contribuir com o mundo de software livre, quando de fato não é. Se você é adepto da ideologia de software livre como Free Software e não somente como Open Source, você provavelmente conhece as quatro liberdade de software de cor, certo? Vamos relembrar. “Número 0 - e, claro, em programação listas começam em zero -, a liberdade de executar o programa como quiser, pra qualquer propósito.” Se você vai num Google Docs, ou Slack, ou Spotify, isso está satisfeito. Quando o seu navegador favorito carrega o site, ele carrega um monte de Javascript e executa o programa e você usa como quiser. O primeiro ponto está satisfeito.

“Número 1, a liberdade de estudar como o programa funciona, e mudá-lo pra ele computar como você desejar. Acesso ao código fonte é pré-condição pra isso.” Pronto, basicamente os principais produtos feitos em Javascript hoje quebram essa condição. O código Javascript é carregado no seu navegador, mas ele quase sempre vem em forma minificada. É impossível entender como esse código funciona porque minificação, que é uma forma de obfuscação criada pra minimizar o tamanho dos arquivos, é quase próxima de compilação. Você não tem como modificar o cliente do Google Docs ou do Spotify nem criar sua própria versão facilmente.

Continuando. “Número 2, a liberdade de redistribuir cópias para ajudar seu vizinho.” Neeeh, impossível. E “Número 3, a liberdade de distribuir cópias da sua modificação pros outros. Fazendo isso você dá uma chance pra toda a comunidade de se beneficiar de suas mudanças. Acesso ao código fonte é pré-condição pra isso.” Pois é, também não.

E antes que os haters cheguem nos comentários, calma! Eu usei Javascript de exemplo só porque é o alvo mais fácil já que a maioria de vocês estão aqui assistindo este video num front-end feito em Javascript que é o YouTube. E o YouTube não é software livre. E não só o Javascript do front-end, mas nenhum componente de nada que você usa todo dia, YouTube, Slack, Discord, Spotify, Netflix, Amazon, AliExpress, Uber, a maioria esmagadora dos softwares que você usa no seu dia a dia, são todos proprietários e fechados.

Isso não é imediatamente óbvio pros desavisados porque praticamente todas essas empresas e marcas parecem associadas de alguma forma com software livre. Em muitos casos oferecendo bibliotecas de código aberto que você pode consumir em seus próprios programas pra falar com as APIs dos produtos deles. Só que cliente de API é um software inútil sem a parte que roda no servidor. É simples entender a consequência. Você faz hoje um aplicativo que usa o cliente de API de um Dropbox. Digamos que amanhã o Dropbox feche, ou simplesmente decida fechar sua API. Seu aplicativo não serve pra mais nada. Era pra evitar esse tipo de cenário que nasceu a idéia de software livre.

Porém, o mundo SaaS inteiro se aproveita do que conhecemos como o GPL loophole. É uma brecha da licença GPL. Entenda, a GPL foi desenhada de tal forma que se você copiar um software GPL e fizer modificações, por exemplo, construindo seu produto em cima dele, e daí você comercializar ou distribuir o binário desse produto, você obrigatoriamente deveria distribuir o código fonte. Só que produtos SaaS não comercializa nem distribui o conteúdo, todo o código e binários rodam somente dentro dos servidores. E executar o código que você modificou é um direito do GPL. O que ele oferece aos usuários é apenas uma API e um front-end em Javascript com uma licença de uso remoto. E contanto que esse Javascript não contenha código GPL, também não há obrigação de abrir o código fonte.

À medida que muita coisa se move nessa direção onde tudo roda remoto, nenhum dos códigos proprietários é comercializado nem redistribuído. Porque você acha que idéias como usar iPad no lugar de Macbook ou Chromebooks são tão atraentes pra Apple e pro Google? A licença GPL não está sendo quebrada, só subvertida. O mundo de software livre obviamente notou isso e por isso existe a licença Aphero GPL ou AGPL, criada em 2002. A diferença com a GPL normal é que se você usa AGPL pra fazer um software as a service, seu código inteiro precisa ser aberto. E é por isso que nenhuma das empresas que eu mencionei e diversas outras, jamais vão chegar perto de software AGPL, porque ela basicamente quebra o modelo de negócios de SaaS como é conhecido hoje.

Um exemplo disso foi a entrevista do diretor de open source do Google em 2008, Chris DiBona que declarou que AGPL é banido dentro do Google. Toda grande empresa que se preza tem um departamento preocupado em avaliar todo o software desenvolvido internamente e suas dependências porque com o tanto de gerenciadores de pacotes que puxam coisas de fora como NPM pra Javascript ou Pip do Python e outros, é muito simples uma biblioteca GPL ou AGPL acabar entrando sem querer e contaminar todo o código. É um problema sério isso. Por isso todas as empresas vão sempre escolher licenças permissivas como MIT ou BSD ou derivadas delas.

Não existe nada como o passar do tempo. 20 anos atrás empresas como Apple, Microsoft ou Oracle eram os inimigos número 1 do software livre. Mas essa imagem foi revertida, e não é porque eles aderiram ao software livre, mas porque aprenderam como subverter a idéia toda. Hoje em dia a gente quer mais conveniência do que liberdade. Na verdade, hoje estamos mais dispostos a abrir mão de parte da liberdade em nome de mais conveniência e por isso todo mundo está em jardins fechados, os walled gardens, como dentro do ecossistema Apple, ou Amazon, ou Google ou similar. Todo o software que você usa e todos os dados que você deixa pra trás estão fora do seu controle, não importa se você usa Linux ou não. É o oposto de livre. Até mesmo quem está reclamando de privacidade continua dentro desses ecossistemas.

Antigamente você podia ter uma máquina Linux, com software 100% livre, rodando offline na sua máquina e ser razoavelmente produtivo. Mas hoje você não tem mais como, na prática. Se você trabalha remoto, vai ser obrigado a usar um comunicador, e ele vai ser um Slack ou similar, que é fechado. Se precisa compartilhar arquivos vai ser obrigado a usar um Dropbox ou OneDrive ou Google Drive, todos fechados. Se precisa compartilhar documentos, vai acabar usando Google Docs ou ironicamente Office online, e eles são fechados. Basicamente, tudo que não funciona se você fica offline, é software proprietário que encontrou caminho pra dentro do seu Linux.

Dá impressão que não é nada demais porque você não tá instalando manualmente nenhum binário proprietário na própria máquina. Na verdade, é pior: agora você não tem nem o binário mais: fica tudo remoto. Você abriu mão até do binário. Pior ainda, em vez de pagar uma única vez pelo software, você paga uma assinatura pelo direito de uso temporário desse software remoto. Pare de pagar e você não tem mais acesso ao software e muitas vezes nem aos seus dados. Não tem nem como piratear esse software, porque não existe mais um binário. No máximo um front-end e um cliente de API, que são meras cascas descartáveis. Nem o conteúdo que você gera nesses softwares fica mais na sua máquina, fica na sua conta online do Google, ou da Apple.

Mas e o tanto de software livre que existe hoje em dia em lugares como GitHub? Sim, existem diversos softwares muito importantes e muito bons de forma livre e aberta. Só não os que você precisa usar todo dia. Com o passar do tempo e a maturidade no entendimento de software livre pelas empresas, um modelo ficou mais óbvio: mantenha todo o código crítico dos seus produtos fechados, mas abra alguns que podem se beneficiar da contribuição de fora.

A kernel do Linux é um exemplo disso. É muito caro pra uma empresa criar e manter seu próprio kernel, que dirá seu próprio sistema operacional inteiro. O valor desse desenvolvimento e manutenção não compensa o investimento. Portanto é vantajoso dividir esse custo com outras empresas. O Linux é o que é hoje por causa do investimento compartilhado de dezenas de empresas da Linux Foundation que pagam programadores pra manter seus interesses em dia. Empresas como IBM, Microsoft, Intel, Oracle, RedHat, e várias outras. E todo mundo se beneficia disso. É um compromisso pragmático. Não soa tão legal se você for um purista que achava que um Linux da vida era feito só com programadores anônimos voluntários aleatórios, mas essa é a realidade.

Pra um Google compensa manter sua linguagem, o Go, como código aberto. Nem tanto pra ganhar contribuições de fora, mas porque eles precisam constantemente contratar bons engenheiros. E é sempre melhor se os candidatos aparecerem já dominando a linguagem que eles usam. Mas não espere que eles liberem o código fonte do algoritmo de pesquisa, ou do banco de dados BigTable, ou qualquer outra coisa assim que se usa internamente. Esses códigos sempre foram e sempre vão ser fechados.

Mesma coisa o Facebook, pra eles compensa contribuir com linguagens como PHP, que eles usam internamente, vale a pena liberar o React como código aberto. Novamente eles precisam recrutar engenheiros o tempo todo. Essa é a principal motivação pra manter uma comunidade externa de desenvolvedores. Brigar contra software livre nos anos 90 e começo dos 2000 se mostrou extremamente danoso. A Microsoft sofreu isso na pele, sendo corretamente reconhecida como inimigo da liberdade.

Pra contratar bons profissionais, especialmente em um ambiente de abundância excessiva de hoje, com vários outros competidores, essas empresas precisaram mudar a estratégia. O marketing precisava mostrar que eles não eram o inimigo. Só que abrir o código secreto dos seus principais produtos nunca foi uma opção. Em vez disso elas se tocaram que dá pra pagar um preço mais barato e colher os mesmos benefícios. No começo dos anos 2000 todos os departamentos jurídicos já se atualizaram sobre as leis de propriedade intelectual de código frente a licenças de código aberto. O truque é simples: primeiro de tudo, você não precisa abrir o código dos produtos mais importantes, só do que não é crítico, como clientes de API, linguagens de programação, frameworks, bibliotecas, tudo aquilo que é commodity. Segundo, nunca usar GPL e muito menos AGPL internamente.

Felizmente pras empresas, depois do movimento de software livre, que é de fato um movimento social, ganhou força o movimento open source ou código aberto, que é um movimento pragmático de uma metodologia de desenvolvimento. Software Livre de verdade quase nenhuma empresa de fato adotou em seu núcleo e você vai notar que todas elas escolhem falar “open source” ou código aberto e raramente “free software” ou software livre. Open source é muito fácil de adotar porque elas costumam preferir licenças permissivas como MIT e BSD em vez de licenças restritivas como GPL e AGPL. O movimento open source meio que “matou” o software livre. E como pra maioria da população, incluindo a maioria dos desenvolvedores que nunca vão estudar sobre isso; open source e software livre são parecidos o suficiente pra passar batido.

Podem dar uma olhada nas suas empresas favoritas e quais projetos abriram e quais são as licenças. A licença do Go? É similar a um BSD. A licença do V8 que é o coração do seu Javascript? É similar a um BSD. A licença do React? É MIT. A licença do novo Terminal do Windows que roda Bash? É MIT. A licença do VS Code? É MIT. Eu poderia apostar que a maioria das coisas que você usa no seu dia a dia, tirando o Linux, não é GPL. Ou seja, não é software livre, é só open source. Então todo mundo começou a adotar open source sem pensar muito e achando que é tudo a mesma coisa. Mas qual a importância dessa diferença?

Pense na Amazon Web Services ou AWS. E pra não ser injusto pense também no Google Cloud ou Microsoft Azure. Use qualquer um dos produtos deles, seja AWS Lambda, seja Google App Engine, seja Azure Machine Learning. Você nunca mais vai sair deles. Porque as alternativas são todas incompatíveis e uma vez que seu negócio estiver rodando em alguma delas, você está preso. Pelo próprio tamanho, escopo e complexidade, é praticamente impossível ter opções de código aberto que você poderia rodar no seu próprio servidor. E o modelo de negócio de vender assinaturas em vez de licenças tornou tudo tão mais barato e acessível, que você sequer conseguiria manter algo similar a um custo equivalente. Esse é o poder da adoção em massa num período de abundância econômica.

Antigamente a gente se preocupava que se todo mundo continuasse a usar Office, todos os documentos do mundo um dia poderiam ficar ilegíveis se o Office sumisse, ou se decidíssemos que não queríamos mais pagar a Microsoft e sim outra alternativa. Era um caminho sem volta. Deu um trabalhão e pressão de governos pra fazer a Microsoft criar um formato aberto que são os atuais DOCX e XLSX pra Word e Excel por exemplo. O antigo formato DOC e XLS eram binários fechados e sem documentação. As versões novas são basicamente arquivos XML abertos compactados num zip. Levou anos pra conseguir isso e hoje em dia ninguém mais dá a mínima porque edita dentro do Google Docs e ninguém sabe internamente que formato que eles usam. Como ele exporta em formatos conhecidos a gente não liga tanto. Pior, a gente não baixa e guarda os arquivos na própria máquina, todo mundo se acostumou a confiar no servidor do Google como mais seguro. Como foi que começamos a abrir mão das nossas propriedades assim?

A resposta é simples: nós somos baratos. Eu não lembro mais a fonte mas eu acho que o case de marketing que me contaram era assim. Cervejarias de diversas marcas precisam competir pra serem escolhidas pelo consumidor. Não lembro se foi a Heineken que teve a boa idéia de distribuir cerveja grátis ou muito mais barato pras fraternidades de faculdades, pras cervejadas e festas de estudantes. Óbvio, se todo mundo aprende a tomar Heineken na faculdade, as chances de continuarem a tomar Heineken quando se formarem e entrarem na vida adulta aumenta muito.

Toda empresa que pode faz isso. Sempre que você vê uma grande marca patrocinando eventos em faculdades, dando descontos generosos nos seus produtos, custeando salas de computador e material de aprendizado, não é porque eles são bonzinhos. Eles estão competindo pela sua fidelidade exatamente na época onde estudantes são facilmente compráveis com um coffee break barato em evento e algumas camisetas e stickers. É muito barato comprar a fidelidade de estudantes. E como funciona! Não faz sentido na minha cabeça ser fã de empresas. Eu pago pelos produtos, e pronto, eu não sou outdoor ambulante pra ficar carregando a marca delas de graça, ou em troca de um brinde.

Se parece um exagero, vamos olhar a AWS. A comunidade de desenvolvimento em geral parece gostar bastante dela, afinal a grande maioria das tech startups e produtos web escolhem ela como primeira opção. Afinal ela oferece suporte de muitos produtos open source que você quer usar como o MySQL ou Postgres no produto RDS ou o ElastiCache que implementa Memcached e Redis. Em dezembro teve o evento deles, o AWS re:Invent onde muita gente comemorou que eles vão começar a oferecer o NoSQL Cassandra como opção gerenciada, o que deve aumentar adoção do Cassandra por mais gente. Note que toda propaganda da AWS sempre faz menção de como eles gostam de contribuir com o mundo open source. E se eu parar aqui, realmente parece que é isso mesmo.

Vamos aos fatos. Segundo o blog post da RedisLabs, que é a mantenedora do Redis e que já tiveram vários problemas com a AWS, novamente, o que a propaganda diz não é a realidade. Pra começar a AWS não está oferecendo o Cassandra. Na verdade é só uma camada de compatibilidade. Eles vão oferecer uma API compatível com o Cassandra mas que internamente vai falar com o produto DynamoDB que eles já oferecem faz anos. Segundo a equipe do ScyllaDB que é uma implementação aberta de Cassandra em C++ esse produto da AWS não vai oferecer coisas essenciais a usuários de Cassandra como suporte multi-região, não vai ter UDT, não vai ter alter table, não vai ter counters, não vai ter views materializadas, não vai ter como carregar SSTables diretamente. É uma versão simplificada que “parece” Cassandra mas na verdade é o DynamoDB por baixo.

É como se no ano 2000 a Microsoft falasse que está lançando o MySQL. Só que por baixo dos panos na verdade é uma versão frankenstein do MySQL que recebe os comandos compatíveis de MySQL e só traduz pro SQL Server que é quem de fato vai estar rodando. A AWS está fazendo exatamente isso: um frankenstein do Cassandra pra receber os comandos, por exemplo tudo da API CQL e vai mandar pro DynamoDB. Os preços inclusive são basicamente do DynamoDB só que 16% mais caros pra ter essa camada por cima. E por isso não tem como ter todas as funcionalidades do Cassandra de verdade.

E essa não é a primeira vez, eu disse que o povo da RedisLabs tem problemas com a AWS porque o produto ElastiCache que suporta Redis, como o nome diz, é voltado primariamente pra ser só um cache, e não inclui suporte a funcionalidades chave que tornam o Redis viável pra ser um broker persistente de mensagens ou mesmo um banco de dados primário. Do ponto de vista da AWS se você precisa de mensageria ou suporte a pubsub deveria estar usando SQS ou SNS e se quer um banco de dados primário deveria usar o DynamoDB ou RDS. O Redis é bem mais do que a AWS oferece no ElastiCache.

A mesma coisa acontece com o MongoDB da AWS. O MySQL da AWS se não me engano também não é o mesmo MySQL que você instala no seu Linux, é uma modificação interna que eles não abrem o código. E ao fazer isso, a Amazon divide as comunidades em duas: as que optam pela versão completa e realmente aberta e as que se acomodam às limitações dos produtos da AWS. É literalmente uma apropriação: agora que todo mundo gosta do Redis, vamos nos apropriar do nome Redis mas oferecer um produto inferior mas que pelo menos é mais conveniente de usar pra maioria das pessoas, já que a maioria sequer sabe a diferença.

Por menos que isso a Microsoft foi julgada como inimigo 20 anos atrás. E eu nem estou defendendo que eles deixaram de ser, só aprenderam a se marketar melhor. Porém, quando foi a última vez que você ouviu qualquer coisa negativa assim da AWS? Pois é. Esse é o resultado de um marketing muito bem trabalhado pela Amazon. Eles tem muito mais fãs do que detratores. E o mais interessante é que ela é bem vista como amiga do mundo de software livre.

Se não ficou claro ainda, deixa eu desenhar: a AWS de hoje é a Microsoft dos anos 90. É a mesma tática, só que executada com muito mais finésse e pzazz. E isso não é uma exclusividade da Amazon. Você vai encontrar exemplos similares de todas as empresas que você é fã, seja Google, Facebook, Apple. E todos eles fizeram a lição de casa. Por exemplo, eles tem dezenas de programadores influencers como MVPs, evangelists, advocates ou seja lá qual é o título hoje em dia. Estão todos nas folhas de pagamentos deles. São todos recursos de marketing, não do desenvolvimento core de verdade. Eles patrocinam eventos e distribuem brindes em todos os lugares. Sempre que podem repetem como o mundo open source é importante e como eles apoiam. E com isso dobraram a opinião pública e hoje são os heróis do software livre. Richard Stallman e Eben Moglen estão se revirando em seus caixões.

Com tudo isso que eu disse, pode parecer que eu sou um defensor do software livre. Mas eu não sou não, nunca fui e não tenho vocação pra ser. Eu sou pragmático, eu me adapto às limitações de cada era. Eu nunca usei Linux porque queria participar do movimento de software livre. Eu sempre usei open source porque me interesso por tecnologia tanto em plataformas abertas quanto fechadas. Mas eu não posso evitar e dar risada se você se considera um defensor do software livre e diz isso vestindo uma camiseta da Amazon ou do Google. Seu preço é um brinde de evento, você é uma propaganda ambulante que custa barato e ainda não entendeu como as coisas funcionam.

Agora, falando de forma pragmática. Eu tiraria proveito desse momento. Como eu já venho repetindo em todos os meus vídeos, estamos num período da abundância. E goste disso ou não, essas empresas estão no topo do jogo. Se você tem ideologia de software livre e não gostou do que acabou de descobrir sobre a AWS, não seja ingênuo de achar que Google Cloud ou Microsoft Azure ou qualquer outro são diferentes. Digamos que você use Google AppEngine e você acha que é o super defensor do mundo de software livre porque programa em Python. Só que sua aplicação usa o DataStore do Google, que é um software proprietário e fechado. Pois é. Essa é a realidade.

Eu sinto um pouco de pena por quem é defensor de software livre, ou mesmo de quem é defensor da liberdade em geral, porque o voto da maioria dos programadores foi abrir mão da liberdade por conveniência. Antigamente o mantra era que o conhecimento e a informação querem ser livres. Mas acho que as pessoas em geral não fazem tanta questão assim disso. Independente de qual lado desses movimentos você está, a importância de ter contato com software livre também é entender como as coisas funcionam no mundo real. Em particular eu gosto da parte jurídica disso. E o tema que você precisa entender é copyright e propriedade intelectual.

Nunca, em hipótese alguma, use um código que você achou num GitHub da vida que não tem nenhuma licença ou copyright. É pedir pra ter problemas jurídicos depois. Se você desenvolve produtos web e o que eu falei até agora foi novidade, reveja todas as dependências que você usa e garanta que não existe código AGPL misturado. Se você desenvolve produtos mobile e distribui os binários, veja se não está usando alguma dependência GPL. GPL e AGPL são licenças virais, eu expliquei isso no video da Apple e GPL. Todo código que toca neles se torna automaticamente GPL ou AGPL e sua obrigação é abrir todo o código que você escreveu. Não existe nenhum problema em usar GPL ou AGPL, eu até acho que muitos casos deveriam usar, mas não se meta com licenças se você ainda não estudou como elas funcionam.

Na dúvida, a recomendação costuma ser pra escolher licenças permissivas como MIT ou BSD. Toda vez que você cria um repositório no GitHub ele te lembra pra você escolher uma licença. Quando falamos em liberdade você precisa entender o seguinte: licenças restritivas como GPL ou AGPL promovem o software livre, ou seja, estamos garantindo a liberdade do software e protegendo os usuários, mas restringindo a liberdade dos desenvolvedores. Licenças permissivas como MIT ou BSD estão promovendo a liberdade dos programadores e das empresas, mas não necessariamente do software e nem dos usuários. Ou seja, se você desenvolve um produto usando software com licença BSD, você não é obrigado a abrir o código que fez, você faz o que quiser, pode inclusive comercializar e nunca abrir o código. Você tem liberdade de escolher o que fazer. Entenderam?

Tirando a parte ideológica e filosófica, software livre e open source são um pequeno caso de leis de copyright e propriedade intelectual. Eu não tenho treinamento jurídico nisso portanto tudo que eu disser a respeito, não considerem como conselhos legais, mesmo porque eu nem posso advogar nada. De qualquer forma é um assunto muito interessante especialmente se você se considera criador de conteúdo. Só porque você pode baixar e editar algum código, não quer dizer que você tem licença vender. É a mesma coisa com código e qualquer outro produto de criação como video, áudio, imagens e tudo mais. Se você encontra na internet talvez só tenha licença pra ver, mas não pra usar. E se usar, você não pode declarar ignorância da lei. Ser ignorante da lei não o torna isento da lei, isso vale pra qualquer coisa.

Em resumo super resumido, copyright é literalmente o que o nome diz, o direito de cópia. E a única pessoa que tem o direito de cópia sobre uma criação é o próprio criador. Esse direito é automático. Propriedade Intelectual é bem mais complicado e depende de pesquisa pra garantir que não havia obra igual ou similar já registrada antes. Licenças de software como a GPL foram chamadas de copyleft. Na realidade é um copyright onde o criador dá a licença de uso e modificação da criação se a pessoa obedecer as restrições da licença, que são as quatro liberdades que eu disse logo no começo do video. GPL é uma subversão do copyright, na prática é uma licença que restringe o uso, por isso chamamos de restritivas.

Em coisas fora de software, como este video, eu só posso usar coisas que eu comprei a licença. Por exemplo, a vinheta de entrada eu comprei. As músicas que eu uso em todos os vídeos são licenciadas pelo site Epidemic Sound. E nos casos onde eu uso pequenos trechos de músicas de filmes por exemplo, eu tento ao máximo estar próximo do que se chama de Fair Use. Essa parte da lei é a complicada, que é o limite de até onde você pode usar a criação de outra pessoa de forma que não entre em conflito com seu copyright. Um exemplo simples era antigamente que a gente fazia mix tapes, ou fitas cassetes com nossas músicas favoritas pra ouvir no carro. Se eu tinha a fita ou CD original comprado, eu tinha direito sob o Fair Use de fazer uma cópia pessoal para uso pessoal. No minuto que eu vendo a fita, aí eu infringi a lei, e vira pirataria. Se você assina um Spotify hoje, você concordou com os termos da assinatura, e você só tem a licença pra ouvir a música, mas não pode baixar e ouvir fora do Spotify. Muito menos usar as músicas inteiras ou mesmo trechos dela. E você não pode reclamar, a conveniência de pagar mais barato é que você abriu mão do fair use.

Na dúvida: não copie o que não é seu. Pra todo o resto, consulte um advogado especializado em propriedade intelectual. E já aviso que muitos vendem bullshit, então tomem cuidado e exercitem o pensamento crítico. Muita gente que quer empreender tem essas dúvida quanto ao software que estão desenvolvendo. Alguns acham que precisam registrar esse software. Mas isso é um dos bullshits: seu software nunca vai estar finalizado, você vai mudar ele o tempo todo. E provavelmente é um produto web as a service, que nunca vai ser exposto.

Digamos que alguém copie seu software e lance um concorrente de alguma forma. Essa é outra preocupação. Mas minha resposta pra isso é simples: se seu produto é tão frágil que só de copiar o código qualquer um consegue lançar um concorrente melhor, eu diria que sua empresa está muito mal montada. A marca, a operação, a comunicação, a reputação e tudo mais fazem o produto e não só o código. O código é só uma pequena parte de uma empresa de produto. Se seu negócio vai pros ares no segundo que alguém lança um concorrente, eu questionaria a necessidade da sua empresa existir.

Registrar seu software não vai servir pra muita coisa. Se você teve uma idéia realmente original, de novo, consulte um advogado e consiga uma patente. Agora, copyright, propriedade intelectual, patentes, não são coisas que se enforçam sozinhas também. É obrigação do detentor da propriedade de proteger sua própria propriedade, então se alguém infringir sua propriedade você deve acionar seu advogado pra começar os procedimentos legais. Mas isso não é barato, é extremamente caro na realidade, estamos falando de centenas de milhares de reais pra mais. A hora de advogado é muito caro, e se você perder você arca com os custos do outro lado também. Portanto não é algo que você vai usar tão cedo. De curiosidade eu recomendo dar uma olhada num caso recente da Jukin Media vs MxR que é explicado num canal que eu gosto bastante que é o Legal Eagle onde um advogado de verdade discute um caso de disputa de copyrights do ponto de vista legal e não do seu ponto de vista do que você acha que é certo ou não.

A discussão sobre propriedade e copyright é a parte mais cabeluda e não existe um consenso. Depende do caso. A legislação varia de país pra país e se quiser ter segurança sobre o assunto, consulte um advogado. Mas em princípio existem os que acreditam que tudo que alguém cria deveria ser domínio público e os que acreditam que tudo que alguém cria é propriedade do criador. Eu pessoalmente sou do segundo campo, tudo que você cria é automaticamente seu. Daí você tem a escolha do que fazer, se você acha que quer deixar os outros usarem, então é seu direito conceder a licença de uso. Do lado de quem usa também, se você aceitou o trabalho de alguém, você tem obrigação de seguir a licença que foi anexada nela. Esse é o protocolo.

Isso tudo dito. Por que uma empresa abriria seu código como software livre ou open source? Dezenas de motivos e dezenas de estratégias. Mas mais importante, só porque você abriu o código não tem nenhuma garantia que alguém vai adotar. Muita gente pensa que abrir o código automaticamente vai trazer gente pra colaborar. Eu diria que se você está aqui se perguntando isso, provavelmente é porque não deveria tentar ainda. Vá estudar primeiro e participar de projetos que já existem pra entender como funciona. Pare de ver videos ou blog posts pra achar essa resposta. Não é barato manter o software aberto. Alguém precisa manter esse projeto ativo, responder dúvidas, orientar os possíveis voluntários, avaliar as contribuições o mais rápido quanto possível, manter o software estável pra quem está usando, manter canais de comunicação ativos e assim por diante. Repito, não é de graça manter um projeto open source.

Depois que sua empresa já estiver inserida em projetos abertos, tiver prática, entender a cultura e as licenças, é possível sim fazer bastante coisa. Um dos exemplos mais simples são projetos com licença dupla. Sim, você pode ter uma licença aberta e outra licença fechada. Um exemplo é o próprio MySQL. O conceito é simples, se seu software já tem sucesso você pode abrir ela com licença GPL, dessa forma você garante que outra empresa não pode copiar seu código e lançar uma versão própria fechada. Se outra empresa modificar o código, ela tem obrigação de soltar essa modificação ou ela vai estar infringindo a licença. Mas se uma empresa precisa fazer isso, ela tem a opção de te contatar pra comprar sua licença proprietária que dá o direito dela modificar o produto internamente e não liberar o código. É um modelo de negócio. Se ela é efetiva ou não, depende do negócio e, de novo, consulte seu advogado.

Você enquanto desenvolvedor, porque contribuir em projetos open source? Primeiro, porque você tem um problema com o software que você usa e quer ver consertado ou você quer uma funcionalidade que a comunidade não parece interessada em fazer. A idéia toda de open source é que você coce sua própria coceira. A postura da maioria dos desenvolvedores é ser bem folgado, povo só posta “ow, e aí, quando vocês vão fazer a funcionalidade lá que eu pedi 2 meses atrás?” Folgado pra caramba. Povo que mantém os projetos tem que ser super paciente, porque se fosse eu já respondia “eu vou fazer a hora que você me pagar, folgado”. Se você é desenvolvedor e nem você que precisa da funcionalidade se deu ao trabalho de tentar implementar, porque outra pessoa vai fazer pra você de graça? Se liga, é assim que você começa com o pé esquerdo.

A idéia de trabalho voluntário em projetos abertos parece algo estranho, mas não é tanto assim. Pra começar é uma base de treinamento. Você que é iniciante, você acha que já é o pica das galáxias, que manja do código? Eis um excelente lugar pra provar isso. Resolva um problema seu e ao mesmo tempo demonstre suas capacidades com código. Tem gente que acha que só deve escrever uma linha de código se é pago pra isso. Eu questiono se esse tipo de pessoa realmente gosta de programar, e se for esse o caso, eu não vejo crescendo como programador. Um bom programador escreveria código sozinho, sem ninguém ver, só pelo prazer ou vontade de programar, independente se alguém fosse ver ou não.

Mais do que isso, antigamente a gente não tinha referências pra saber o que é considerado um código bem feito ou mal feito, em que velocidade certos códigos são feitos, as diferentes alternativas de código pra resolver o mesmo problema. Você tem à sua disposição hoje, milhares de projetos abertos, gratuitamente disponíveis, que você pode fuçar quanto quiser. Mesmo se não tiver vontade de contribuir, eu fico pasmo que poucos iniciantes estão baixando esses códigos e estudando. Toda nova biblioteca ou programa útil que aparece, se me interessa eu baixo o código e vou olhar como foi implementado essa ou aquela função que me interessa e sempre me dá algum insight de “ahhh, dá pra fazer assim!” e isso vai se aculumando ao longo dos anos.

Eu mesmo fiz poucas contribuições em projetos open source. Quando eu tava na faculdade, quando eu ainda era um programador júnior, eu não era o melhor programador. E era bem difícil de contribuir em projetos abertos naquela época. Se você viu meus vídeos de Git eu expliquei porque. Foi só depois de 2008, ou seja, quase 20 anos depois que eu comecei a aprender a programar, que contribuir em projetos open source se tornou fácil como é hoje. Eu teria sido um programador muito melhor se desde o começo eu tivesse conseguido contribuir e criado essa rotina.

Mas tanto empresas quanto programadores, a intenção deste vídeo foi colocar suas expectativas em dia. Open source não é mágica. Só porque você abriu seu código, não quer dizer que alguém vai se interessar por ele. Na verdade é até uma boa se quiser testar, você abre seu código e vê que zero pessoas se interessaram. É uma boa evidência que esse código que você achava legal na verdade não tem tanta serventia pras pessoas, ou você que é muito ruim de comunicar os benefícios. De qualquer forma é um feedback útil. Mesma coisa se for um desenvolvedor, se suas contribuições que você achava que eram boas forem rejeitadas, é um bom feedback pra melhorar. E é isso que a maioria das pessoas precisam de qualquer forma: feedback. É como se você tivesse programadores sêniors do seu lado apontando seus erros. Só isso já tem muito valor. Por isso que apesar do trabalho ser voluntário, estão existindo trocas entre você, o projeto e os outros colaboradores. Isso não é caridade, são trocas voluntárias pra mútuo benefício.

Além disso, da mesma forma que você escolhe entrar, qualquer hora pode escolher sair. Jamais pense que alguém te deve alguma coisa só porque você fez uma contribuição. É outro bom exercício pra entender o valor das coisas. Você contribuiu pra coçar uma coceira sua. Se outra pessoa se beneficiou disso, bom pra ela, mas isso foi o efeito colateral. Se outra pessoa fez melhor uso da sua contribuição do que você mesmo, melhor ainda pra ela, e bom aprendizado pra você também. Não existe mérito automático, mérito é algo que você conquista, nunca vai ser dado pra você independente da quantidade de esforço que você fez.

Enfim, o mundo de software livre não é tão ideológico como você poderia imaginar no começo. As grandes empresas já entenderam como formular estratégias onde eles podem alocar projetos open source como bons canais de marketing e de contratação de talentos. E isso não é uma coisa totalmente ruim, basta que você como desenvolvedor não fique perdendo tempo sendo fanboy de empresa e use o que está disponível como material grátis pra sua própria evolução. Essa é a única coisa que interessa pra um programador. Os brindes são inúteis, mas os códigos, sejam eles abertos via licenças permissivas ou via licenças restritivas, são códigos úteis. Pode ser que esse mundo abundante suma amanhã, então aproveite enquanto ela existe.

Eu já ouvi muita gente reclamar que mora em lugares afastados, cidades pequenas, que sequer tem empresas ao redor onde elas podem começar a trabalhar. Em muitos casos, projetos open source podem ser a única fonte de conhecimento e contato com outros programadores. E mais, você tem a oportunidade de fazer código e receber feedback desse código. Se o feedback for negativo, você finalmente sabe no que precisa melhorar. Em vez de pensar mesquinharias de “ah, mas eu vou estar trabalhando de graça” eu pensaria diferente “puxa, eu estou recebendo feedback de graça”. E com o tempo, se você se dedicar de verdade, é possível montar um bom portfolio de contribuições em projetos relevantes que chamem a atenção de outras empresas procurando alguém como você. E por hoje vamos ficando por aqui, se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal, não deixem de clicar no sininho pra não perder os próximos episódios e ajudem o canal compartilhando o video com seus amigos. Este mês vai ter menos vídeos porque vou passar as próximas semanas nos Estados Unidos, então a gente se vê na minha volta. Até mais.

Descrição no YouTube

Finalmente! Chegamos no episódio 42!

Se você é geek que nem eu sabe que 42 é um número especial. Segundo o sábio profeta Douglas Adams o número 42 é a resposta da vida, do universo e de tudo. Se não acreditam leiam a bíblia do Guia do Mochileiro das Galáxias. De curiosidade é por isso que minha empresa se chama Codeminer 42. E em especial este ano eu vou completar meus 42 anos. Mas chega de numerologia, vamos começar a história de hoje.

Hoje vamos fugir um pouquinho do tema de Back-end, que pretendo retomar semana que vem. Desta vez quero contar uma história que eu pessoalmente acho interessante. Vou falar sobre Apple, sobre licenças de software livre, sobre compiladores, um pouco do mundo mobile e um pouco do mundo web de novo. É uma história meio complicada mas que vai ajudar vocês a entenderem um pouco da dinâmica de como o mundo real afeta a evolução e adoção de linguagens e tecnologias.

Errata: várias vezes no vídeo eu falo “SpiderMonkey” mas eu queria dizer “JavascriptCore”. A SpiderMonkey é a engine de Javascript do Firefox, a JavascriptCore que é a engine que vem no WebKit e Safari. E o V8 é o do Chrome.

Errata 2: Eu falo que GPL é General Protection License, mas na verdade é General Public License.

Errata 3: me avisaram nos comentários e eu realmente comi bola quando falei dos emuladores de Android. Antigamente as imagens do OS eram realmente só de ARM mas hoje em dia de fato já existem imagens compilados pra x86, então em um Virtualbox habilitado pra usar os recursos de virtualização dos processadores AMD e Intel como o VT-X é possível acelerá-los. Ainda não é a mesma coisa que no MacOS/iOS que é um simulador sem necessidade de camada de virtualização, mas não deixa de ser um avanço.

Links:

• Why WebAssembly is Faster Than asm.js (https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/)
• Awesome Wasm (https://github.com/mbasso/awesome-wasm)
• Swift is like Kotlin (http://nilhcem.com/swift-is-like-kotlin/)
• THE CASE THAT NEVER ENDS: ORACLE WINS LATEST ROUND VS. GOOGLE (https://www.wired.com/story/the-case-that-never-ends-oracle-wins-latest-round-vs-google/)
• Facts and effects of Caldera/SCO vs IBM (https://www.computerweekly.com/feature/Facts-and-effects-of-Caldera-SCO-vs-IBM)
• A new GCC runtime library license snag? (https://lwn.net/Articles/343608/)
• A visual timeline of the Microsoft-Novell controversy (https://arstechnica.com/information-technology/2007/01/linux-20070128/)
• The Microsoft-Novell Linux deal: Two years later (https://www.infoworld.com/article/2654097/the-microsoft-novell-linux-deal--two-years-later.html)
• An Introduction to Tivoization (http://www.linfo.org/tivoization.html)
• Linus Torvalds, Dual-Licensing Linux Kernel with GPL V2 and GPL V3 (https://lkml.org/lkml/2007/6/13/289)
• An insider’s look at drafting the GPLv3 license (https://opensource.com/article/18/6/gplv3-anniversary)
• Apple’s great GPL purge (http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/)
• Apple Invests in LLVM, Suggests Merge with GCC (https://www.osnews.com/story/12715/apple-invests-in-llvm-suggests-merge-with-gcc/)
• Arquitetura LLVM (https://www.aosabook.org/en/llvm.html)
• What is LLVM? The power behind Swift, Rust, Clang, and more (https://www.infoworld.com/article/3247799/what-is-llvm-the-power-behind-swift-rust-clang-and-more.html)

Script

Olá pessoal, Fabio Akita

Desta vez vamos dar uma pequena pausa na série Começando aos 40. Vocês já viram dois episódios falando sobre back-end e o assunto ainda não acabou, mas pra quebrar um pouco decidi fazer uma longa tangente hoje e falar sobre um tema cabeludo que envolve o mundo de software livre, a Apple e compiladores. É até difícil definir que tema é esse exatamente. Tem a ver com compiladores e linguagens mas não é só isso. Mas é uma história que eu acho fascinante e queria compartilhar com vocês.

Além disso hoje finalmente estou completando o episódio 42. Se você é geek que nem eu sabe que 42 é um número especial. Segundo o sábio profeta Douglas Adams o número 42 é a resposta da vida, do universo e de tudo. Se não acreditam leiam a bíblia do Guia do Mochileiro das Galáxias. De curiosidade é por isso que minha empresa se chama Codeminer 42. E em especial este ano eu vou completar meus 42 anos. Mas chega de numerologia, vamos começar a história de hoje.

(…)

Como vocês viram nos vídeos passados, acho que deu pra entender que a Microsoft foi um rolo compressor nos anos 90 empurrando tecnologia atrás de tecnologia, boas ou ruins. Depois ela foi bruscamente parada no começo do século por causa do julgamento anti-truste. E de 2001 até pelo menos 2014, quem calçou seus sapatos de certa forma foi a Apple. Sem repetir muito o que todo mundo já sabe vamos resumir: em 1999 os iMacs translúcidos de plástico colorido foram um enorme sucesso pra marcar o retorno de Steve Jobs, numa época onde a Apple estava a dias de fechar as portas e declarar falência. Em 2001 surgia o Mac OS X baseado no NextStep e BSD UNIX, também em 2001 o iPod conquistou o mundo, em 2003 o iTunes conquistou o mundo.

Em 2005 com a ascendência do Ruby on Rails e a preferência por Macs de seu criador fez com que a comunidade Rails e o gosto pela estética da Apple andassem lado a lado. De 2005 a 2006 a Apple migrou dos processadores PowerPC pra Intel e de repente todo mundo queria usar Macs pra desenvolvimento já que ele era um sabor de BSD UNIX. Diversas ferramentas que só existiam em Linux passaram a ser portados. Gerenciadores de pacotes como Fink, MacPorts e hoje HomeBrew começaram a surgir. E mais importante, Ruby vinha pré-instalado nos Macs, facilitando ainda mais a adoção inicial.

Por duas vezes a Apple não só passou ilesa como explodiu em crescimento no meio de duas grandes crises. Em 2001 ela lançou seu iPod bem na queda da Crash das Ponto Coms, um dos piores episódios da história da Internet. E em 2007 os iPhones aparecem, 1 ano antes da famosa crise econômica de 2008 que muitos diziam que poderia ser o fim do mundo, e você pode assistir em filmes recentes como o incrível The Big Short. Mesmo em meio a essa crise, em 2009 a App Store vai ao ar inaugurando a era do desenvolvimento mobile e todo mundo quer aprender Objective-C agora, validando o estilo de orientação a objetos que já era mais familiar a quem usava Ruby do que quem usava Java. A Apple forçou a evolução da Web em direção à morte do Flash, e ao HTML 5 e CSS 3 que rodavam melhor nos seus navegadores Safari. E com o nascimento do MobileMe que foi o serviço online de cloud da Apple; nasceu o framework javascript SproutCore, que depois viria a se tornar Ember, inaugurando o estilo de produtos Web que conhecemos hoje.

Pós crise de 2008 e 2009, todo mundo queria desenvolver produtos mais sofisticados, com linguagem visual limpa, com a usabilidade que a Apple era lendária por oferecer em seus produtos. Mesmo antes disso, enquanto o mundo enterprise estava adotando soluções J2EE como o IBM Websphere ou BEA Weblogic a própria Apple tinha uma arquitetura mais simples e mais sofisticada na forma do WebObjects que era o motor por trás do lendário e-commerce da Apple na época. Uma pena que o WebObjects nunca teve real tração. Toda essa experiência trouxe a Apple como uma das maiores influenciadoras das tecnologias da época. E isso coincidiu com o pior período da história da Microsoft pós-processo dos Estados Unidos contra suas práticas monopolistas depois da Guerra dos Navegadores, então a Apple praticamente não teve competição.

Voltando ao nosso tema de programação e linguagens, entenda que 2006 e 2007 foram anos interessantes pro mundo dos compiladores por três motivos: a migração da plataforma de Macs para Intel, o lançamento do iPhone e a migração no mundo de software livre da famosa licença GPL v2 para o controverso GPL v3. Esses três acontecimentos, na minha opinião, influenciaram muito o landscape de desenvolvimento de software entre os mundos comercial e de software livre, e eu acho que ainda não vimos tudo que pode sair disso até hoje.

No ano 2000 um novo projeto começou a aparecer como uma pesquisa, o Low Level Virtual Machine de Chris Lattner e Vikram Adve. Em resumo essa tecnologia se tornou um compilador modular que chamamos de LLVM apesar de não ser de fato uma máquina virtual como uma JVM. O monopólio dos compiladores, principalmente no mundo open source, era basicamente do GCC, responsável por compilar os códigos em C, C++ e várias outras linguagens, incluindo coisas como Fortran, e que gera o binário da kernel Linux e todas as ferramentas de licença aberta que rodam ao seu redor nas distribuições Linux. Mas o GCC é um grande monolito, com mais de 25 anos de contribuições e evoluções, complicado de evoluir, expandir e integrar. Porém com décadas de refinamento e ajustes, é definitivamente um dos melhores compiladores do mercado.

O LLVM foi criado pra ser diferente, ele separou o processo de compilação em 3 grandes estágios, front-end, otimização e back-end. Não confundir com as carreiras de front-end e back-end. Pense na entrada do compilador que é o front, o miolo, e a saída do compilador que é o back, Vale a pena eu explicar o que isso significa. Em resumo, o front-end pega o seu código fonte, digamos em C, e faz a checagem e o parsing. O resultado desse estágio é seu código limpo e traduzido em outra linguagem intermediária, chamada literalmente de Intermediate Representation ou IR. Não seria muito diferente do Java gerando bytecodes ou do .NET que gera em IL pro CLR que é literalmente Intermediate Language. Também meio parecido com o que um transpiler de Coffeescript ou Dart ou Typescript faz transformando em Javascript por baixo. Na sequência esse código em IR passa pelo tal miolo, a fase de otimização, que vai fazer todas aquelas otimizações que eu expliquei no episódio anterior pra deixar seu código o mais eficiente possível. Inclusive como o GCC e outros compiladores, essa fase pode precisar “passar” pelo código múltiplas vezes, você às vezes vai ver esse termo “passes” porque algumas otimizações exigem conhecimento do código anterior. Finalmente o LLVM pega esse sub-produto otimizado e passa pro back-end, que vai finalmente traduzir em binário de máquina, gerando o executável do seu programa. Mas o importante é entender que existem 3 grandes pedaços de software independentes que, juntos, formam o compilador.

Então, em vez de usar GCC pra compilar C, você pode substituir por Clang que é um front-end de C feito pra LLVM. Teoricamente hoje você poderia tirar o GCC e recompilar uma distribuição Linux inteira usando Clang, até existem projetos testando isso. Por muitos anos, fazer o LLVM cuspir um binário tão otimizado quanto o de GCC foi bem difícil. E também havia a questão: pra que eu quero substituir o GCC se ele já funciona tão bem?

Em 2005 a Apple fez um de seus movimentos mais interessantes e pouco comentados e contratou Chris Lattner, que na época estava em início de carreira na Microsoft Research. Em 2006 Steve Jobs sobe ao palco na conferência WWDC e anuncia a transição da plataforma Mac dos processadores IBM PowerPC para Intel, mais especificamente a nova linha de processadores Intel Core. O sistema operacional OS X 10.4 Tiger foi o primeiro compilado ainda com GCC pra rodar tanto em PowerPC quanto Intel.

Mas em 2007 teríamos a sequência com o OS X 10.5 Leopard e o XCode 3.1, a IDE de desenvolvimento pra Mac e junto com ela viria o compilador GCC 4.2 e junto o LLVM integrado ao code generator do GCC, que foi conhecido como LLVM-GCC. O XCode 4.1 da época do Mac OS X Lion de 2011 foi o último a vir com o GCC como compilador, e de lá em diante o desenvolvimento em MacOS e iOS depende só do Clang. Ou seja, de 2006 até 2008 os produtos com processadores PowerPC foram todos migrados para Intel. Mas mais importante que isso, o compilador GCC foi sendo gradativamente substituído por Clang, a partir de 2007 até pelo menos 2011. Guarde essa informação.

No começo do século um novo tipo de produto começou a fazer um sucesso estrondoso. Lembra quando eu contei qual era o objetivo original do Java quando ele foi criado no começo dos anos 90? Ser um sistema pra um hardware de set-top-boxes. Ele estava quase uma década adiantado porque foi só nos anos 2000 que esse tipo de produto realmente explodiu, em particular o Tivo. Aqui no Brasil não tivemos Tivo mas tivemos similares. Era aquele produto que você podia gravar programas de TV a cabo pra assistir depois. É o que se chamava de DVR ou Digital Video Recorder, basicamente um receptor de sinal analógico, que digitalizava o vídeo e gravava organizado num HD. Acho que até hoje algumas empresas de TV a cabo ainda oferecem esse tipo de produto. Mas nos Estados Unidos o Tivo teve um sucesso explosivo. Tecnicamente falando ele era um mini-pczinho com uma placa de captura de vídeo que rodava uma versão de distribuição Linux.

Não é hoje que vou entrar em detalhes sobre licenças de software livra, mas a kernel Linux e a maioria das ferramentas que compõe uma distribuição que forma um sistema operacional completo, as ferramentas GNU, o compilador GCC e tudo mais usavam a licença GPL v2. GPL que significa General Protection License. Na prática, qualquer um, especialmente qualquer empresa que modifique código licenciado via GPL é obrigado a republicar as modificações ao público. O GPL não é uma unaminidade, por isso existem outras licenças, mas a maioria das coisas num Linux costumava ser GPL. E foi o que a Tivo fez: ela seguiu a licença e liberou as modificações que fez. Isso inclusive permitia que hobistas pudessem baixar esse código, fazer suas próprias modificações e carregar no Tivo. Então era como se fosse um PCzinho que dava pra brincar e instalar seus próprios programas.

Pelo menos naquela época, a maioria das empresas não gostava que seus dispositivos fossem modificados pra fazer coisas que não deveriam. Existem motivos pra isso, e nem vou entrar no mérito de certo ou errado, vamos só entender que eles não gostavam. Então na série 2 eles adicionaram um hardware que validava a assinatura do binário. Eu não sei como exatamente eles faziam isso, mas se você é iniciante vale entender pelo menos o conceito básico. Existe uma coisa em computação que chamamos de hashing. Existem algoritmos como os antigos MD5 ou SHA-1 ou os atuais SHA-256 ou bcrypt. Sem entender de criptografia entenda que eles são funções. O argumento de entrada pode ser qualquer bloco de dados, seja texto ou seja um binário. E a saída é sempre um texto de tamanho fixo.

Isso não é encriptação. Quando se encripta alguma coisa, você consegue reverter o processo e desencriptar. Em hashing não existe forma de pegar o resultado e reverter o processo e conseguir o argumento original. Dois blocos de dados diferentes podem dar o mesmo resultado, isso seria o que chamamos de colisão, mas é raro que isso aconteça num cenário real. O importante é que esse resultado serve como uma impressão digital, um fingerprint, de seja lá qual dado você tenha passado pra função. Ou seja, digamos que você passe o binário do kernel Linux. E o Tivo tem um firmware separado que quando carrega a kernel passa o binário por essa função e compara com a impressão digital que ele tem guardado num hardware que você não pode modificar.

Ou seja, se você modificou o kernel e instalou lá, a impressão digital vai ser diferente, então o Tivo pode rejeitar esse novo binário e impedir o boot. Essa seria uma forma simplória de fazer isso. Existem formas mais sofisticadas mas esse exemplo deve ajudar a entender parte do processo. Isso seria um tipo de DRM ou Digital Rights Management que a indústria de música adorava. Mas a Tivo achou um loophole no GPL v2, uma brecha na licença. A licença obrigava a liberar o código modificado, e isso eles fizeram, mas ela não fala nada sobre impedir o hardware de rodar código modificado no seu hardware.

Isso foi uma controvérsia gigante porque esse sistema de DRM, do ponto de vista dos desenvolvedores, restringia a liberdade do que o consumidor poderia fazer com o hardware que ele comprou. Isso gerou uma enorme polarização na opinião se uma empresa podia ou não fazer isso. Richard Stallman e Eben Mogler, os criadores da licença GPL ficaram enfurecidos, porque a GPL v2 não conseguia proibir essa atitude. Então eles iniciaram a modificação da GPL v2 para o novo GPL v3 que adicionava cláusulas que impediria isso que eles chamaram de “Tivoização”. E se você acha que o mundo open source apoiou essa medida, você está enganado. Isso gerou uma nova controvérsia e uma nova polarização. Por exemplo, Linus Torvalds odiou a medida e a kernel do Linux permanece na GPL v2.

Como eu já havia explicado no episódio da Lerna vs a ICE, licenças de software livre podem ser divididas em duas grandes categorias: as licenças restritivas e as licenças permissivas. Ao contrário do que o senso comum pode imaginar, o GPL é uma licença restritiva. Licenças como BSD, MIT, Apache e outras são mais permissivas. Em última instância a GPL impõe uma restrição importante: você é obrigado a liberar qualquer modificação que fizer num código GPL e essa modificação também será GPL. E sem cláusulas especiais e sub-licenças como LGPL você teria que se preocupar inclusive, se o binário gerado por um compilador com licença GPL se ela herda o GPL e se pode ser usada livremente ou não. É por isso que inclusive muitos chamam a GPL de uma licença viral. Já código licenciado via BSD por exemplo, não tem essa restrição. Você pode modificar o código e não tem a obrigação de liberar a modificação. Você pode gerar um binário e comercializar o binário e não se preocupar em ter que liberar o código.

A discussão sobre licenças de software livre é em última instância uma discussão sobre propriedade intelectual. A maioria das empresas prefere ficar bem longe de licenças restritivas pra não comprometer suas propriedades intelectuais, que é o que garante o seu valor. Nos anos recentes no começo dos anos 2000 tivemos grandes casos controversos em torno de propriedade intelectual no mundo open source como o famoso caso da SCO ou Santa Cruz Operation que processou a IBM pedindo nada menos que 1 bilhão de dólares, alegando que eles infringiram na sua propriedade do UNIX e usaram esse conhecimento nas contribuições ao Linux que a IBM fazia.

Se a SCO tivesse ganhado isso teria sido uma bomba nuclear tornando o Linux material radioativo pra quem usasse. Mas numa virada de eventos um juiz determinou que quem possuía os direitos que a SCO clamava na verdade era a Novell. E nessa mesma época por 2005 ou 2006 a Microsoft fechou um acordo de 400 milhões de dólares com a Novell que era dona do Suse Linux, cujo combinado era que uma não iria processar a outra em torno de propriedade intelectual, meio que sugerindo que haveria alguma coisa no Linux que deixaria quem não usasse Suse Linux vulnerável a algum processo no futuro de alguma forma. A comunidade open source odiou esse movimento, claro.

Certo ou errado, vocês podem entender pelo menos porque levar propriedade intelectual e licenças a sério é importante, principalmente nos Estados Unidos. À medida que as empresas iam adotando tecnologias open source, essa dúvida sempre deixa todos com os nervos à flor da pele. Se o Linux, que é a kernel por baixo de todas as distribuições e que estava sendo adotado rápido por todos, fosse condenado num processo desses, ele se tornaria material radioativo e toda empresa usando poderia descobrir uma bomba relógio explodindo. Isso é realmente sério. Se nos anos 2000 alguém perguntasse porque a Apple preferiu usar a base do FreeBSD nos OS X em vez do Linux, esse certamente poderia ser considerado um dos principais motivos: o FreeBSD usa licença BSD que é bem permissivo, ao contrário da GPL que tinha todas essas dúvidas pairando no ar.

Agora, o GPL v3 é um problema sério. Que outra empresa além da Tivo prefere manter certos códigos escondidos e dificultar você de instalar o que quiser em seus hardwares? Eu sempre fui fã da Apple e certamente a integração de hardware e software que eles fazem é excepcional, mas se você pensar puramente em questão de software livre, você vai ficar no mínimo em cima do muro com as práticas da Apple. E não confunda, sim, a Apple tem o código da base do seu sistema operacional aberto ao público na forma do Darwin, mas o MacOS é bem mais que só o Darwin, tem centenas de componentes que eles não querem abrir, incluindo a forma como o sistema se integra perfeitamente nos Macs e Macbook e, claro, nos iPhones de hoje. Se você notou que um iPhone faz a mesma coisa que um Tivo, impedindo você de instalar outro sistema nele, você pensou certo.

No outro lado do espectro, além de distribuições baseadas na kernel Linux, existem as distribuições baseadas em BSD, como FreeBSD, OpenBSD, NetBSD. O Linux é como se fosse um clone de UNIX, mas os BSDs em princípio são herdeiros do UNIX original. BSD seria o concorrente da outra linhagem de UNIX, o System V que deriva da época do UNIX System III da AT&T. Como o próprio nome diz, a filosofia dessas distribuições é Software Livre no sentido mais permissivo e liberal, com a licença BSD. Vamos dizer que eles “toleram” a GPL mas nunca gostaram dela e o GPL v3 foi uma afronta direta e ofensiva pra eles, e podemos dizer que eles não gostaram nada das cláusulas restritivas anti-Tivoização. Existe uma longa história de brigas políticas em torno do que é considerado Software Livre ou não e vou parar por aqui pra não me alongar demais por hoje.

O maior problema? Tudo no mundo open source era compilado com o GCC. Como eu já expliquei no episódio sobre a Lerna vs a ICE, licenças não podem ser mudadas retroativamente, só em novas versões. Como quem controla o GCC é o Richard Stallman, ele migraria pra nova GPL v3. Ou seja, quem não quisesse adotar a nova licença ficaria preso na versão 4 do GCC que ainda seria GPL v2. Então começou uma corrida contra o relógio. Você pode ficar usando o GCC que ainda era GPL v2 mas quanto mais tempo passa, mais ele fica defasado e até inseguro, já que correções e novas funcionalidade só iriam subir no GCC com GPL v3.

Resumo da história? Tanto FreeBSD quanto a Apple começaram um projeto que iria levar alguns anos pra sair do GCC e migrar a compilação de tudo pra usar LLVM e Clang, que era o único concorrente viável ao GCC. Se você alguma vez já se perguntou porque no MacOS vem um Bash tão antigo? Porque além do GCC outras ferramentas GNU mudaram pro GPL v3, o Bash foi um deles. Por isso hoje se instala o Bash mais novo e outras ferramentas com versões mais novas, como o próprio Git, você mesmo via Homebrew ou de outra forma manual como baixar os códigos fonte e gerando binários você mesmo. E por isso às vezes você tem confusão de compilar usando GCC ou Clang.

Pra Apple, além da questão das licenças, a linguagem Objective-C que é o coração dos frameworks de aplicativos nativos de MacOS e iOS nunca teve prioridade no grupo de desenvolvimento do GCC. Por causa disso o projeto Clang começou a avançar a passos mais largos e por isso eles começaram a estratégia de primeiro começar a usar GCC como o front-end pra LLVM, já que a primeira coisa mais difícil era parsear corretamente os códigos em C, C++ e Objective-C e por isso você começa com LLVM-GCC como eu disse antes. À medida que a compatibilidade do front-end entre GCC e Clang ficou mais próxima, daí eles começaram a colocar Clang como escolha padrão até finalmente remover completamente o GCC antigo.

Nesse período de 2006 então a Apple estava migrando seus sistemas operacionais de PowerPC pra Intel e ao mesmo tempo já estava planejando outro dispositivo pra ser lançado em 2007: o primeiro iPhone. E os iPhones não usam processador Intel e sim ARM. E os iPhones seriam sempre produzidos com o bloqueio de DRM pra impedir outro sistema de rodar no hardware, ou seja, eles seriam Tivoizados. E com todos os aplicativos desenvolvidos usando Objective-C e com a necessidade de compilar binários nativos pra Intel e para ARM.

Agora vamos entender outra coisa do LLVM que eu não disse antes. O LLVM é um conjunto modular de bibliotecas. O compilador Clang é um conjunto dessas bibliotecas. Como ele foi desenhado pra ser modular, significa que você teria relativa facilidade de trocar partes do front-end ou do back-end. Por exemplo, você pode fazer back-ends que cospem binários em Intel ou PowerPC ou ARM ou qualquer outro tipo de hardware. E como o front-end também é modular e ele cospe em IR antes de passar pro módulo de otimização, você também tem facilidade de integrar no XCode pra fazer análise estática do código e debug. Com a integração de ferramentas sofisticadas como o famoso DTrace do antigo Solaris e a substituição do debugger GDB que era usado com GCC pelo LLDB, a IDE do XCode foi ficando mais e mais avançada para conseguir instrumentar o código e otimizar muito melhor do que antes.

Ao mesmo tempo que Chris Lattner e sua equipe iam evoluindo o LLVM dentro da Apple, muitas das pesquisas geraram novas funcionalidades primeiro no próprio Objective-C como a introdução de lambdas e o ARC que é o Automatic Reference Counting. Pra você que é iniciante, na maioria das linguagens mais modernas você não pensa muito em gerenciar memória porque linguagens como Java tem garbage collectors, ou seja, o runtime gerencia a memória por você. Mas se você começou a aprender com linguagens como C, sabe que precisa você mesmo codificar o gerenciamento de memória manualmente. Ou seja, no seu código você chama funções como malloc e free e outros pra pedir memória pro sistema operacional e depois devolver essa memória. Lembra que eu falei que além de multi-thread o outro aspecto em programação mais difícil é gerenciamento de memória?

Pois é, à medida que sua aplicação fica complexa, você vai errar isso. Ao longo da sua carreira você vai ficar ouvindo falar de vazamento de memória por exemplo. Gerenciar memória é complicado, porque memória se fragmenta, você precisa lidar com coisas como regiões, arenas e muitos outros detalhes. Mas se você tem uma máquina potente, digamos, com 8GB de RAM ou mais, você fica preguiçoso e não percebe vazamentos porque tem memória sobrando. Pra facilitar se falta memória RAM o sistema operacional ainda tem a opção de usar o HD como memória. É isso que se chama de SWAP. Se você chega nesse ponto com uma aplicação mal feita que vaza memória, tudo bem, o sistema vai passar a usar HD. Tudo vai ficar lento pra caramba, mas não vai crashear. Mas pense em 2007 um iPhone com meros 128MB de RAM pra comportar o sistema operacional e os aplicativos e sem a opção de um HD pra fazer swap. Ou seja, se faltar memória o sistema vai crashear o aplicativo. Então gerenciar memória se torna especialmente importante em dispositivos com poucos recursos.

E como Objective-C é basicamente compatível com C e usa a mesma semântica de você manualmente codificar onde quer alocar memória e onde quer devolver essa memória, os primeiros aplicativos pra iOS que eram feitos por amadores ou mesmo por descuido acabavam tendo muitos vazamentos e crasheavam dando uma má experiência aos usuários. Por isso recursos como o ARC que foram introduzidos ao Objective-C eram importantes, pra evitar que você precise manualmente escrever código pra gerenciar memória, além da introdução de ferramentas como o DTrace e LLDB pra instrumentar seu código e conseguir analisar exatamente onde estão ocorrendo vazamentos, pra que você consiga consertar antes de mandar o binário final pra App Store.

E como desenvolvedor você ainda tem outro problema grave. Se você já tentou desenvolver pra Android deve ter notado que se quiser testar seu código antes de instalar no celular, a única forma de rodar no seu computador é usando uma máquina virtual. Não estou falando da JVM mas de máquinas virtuais de verdade como QEMU, VirtualBox ou VMWare. Primeiro porque o Android é um sistema operacional baseado em Linux e os binários estão pré-compilados pra processadores ARM. E binários de ARM não são compatíveis com processadores Intel que roda na sua máquina de desenvolvimento, seja PC ou Mac.

A única forma então é usar um emulador, que é uma máquina virtual, que vai traduzir as instruções de ARM em instruções de Intel. Quando você ouve que seu novo Samsung S10 ou mesmo Xiaomi Mi Mix rodam Qualcomm, você sabe que é um processador ARM. Então você programa seu aplicativo pra Android e sobe um emulador de Android como o da Bluestacks ou Nox ou qualquer outro no seu PC e ele vai emular o Android fazendo ele pensar que está rodando numa máquina ARM. Por isso é tudo tão absurdamente lento pra testar seu código, porque emular exige essa tradução de instruções e isso é lento. Não tem jeito.

Mas se você já desenvolveu pra iOS em Macs sabe que a mesma coisa não acontece quando você pede pra testar seu novo app de iPhone no seu Mac. Seu app roda com velocidade total, sem nenhuma lentidão. E você vai notar no XCode que quando vai rodar seu app no seu Mac de desenvolvimento, não existe uma opção pra subir um Emulador, como no Android, e sim um Simulador. A Apple fez uma coisa difícil mas que se pagou: eles compilam o sistema operacional iOS que roda em iPhone e iPad pra binários de Intel de verdade. Então quando você sobe o simulador, ele não precisa de uma máquina virtual pra traduzir as instruções, ele já é binário de Intel! E quando você compila seu projeto pra rodar no simulador o XCode está usando o LLVM pra cuspir binários de Intel também. Só quando você manda empacotar pra publicar na App Store que ele vai compilar em binário de ARM. Parece uma coisa meio óbvia de fazer, mas fazer isso da forma quase transparente como o XCode faz é impressionante até hoje dado que as ferramentas de desenvolvimento de Android do Google até hoje não fazem isso.

Por outro lado, alguns podem argumentar que apesar das funcionalidades impressionantes que a Apple conseguiu colocar no Objective-C, ele ainda tem a sensação de ser uma linguagem com sintaxe muito velha, especialmente se comparado ao Android onde o Google resolveu copiar a linguagem Java, embora similar ao J++ da Microsoft nos anos 90, ele também não é compatível com a JVM de verdade. O runtime do Android, o Dalvik é diferente. De qualquer forma, já discutimos como a linguagem Java também tem sintaxe considerada meio velha se comparada a coisas como Python ou Ruby ou mesmo Groovy. Mas se comparar com Objective-C - que eu pessoalmente gosto - a maioria vai dizer que prefere Java por estar mais acostumado e ter visto na faculdade.

Enquanto evoluía o LLVM, o Clang, os frameworks de iOS, as tecnologias do XCode, Chris Lattner começou a pensar numa nova sintaxe de linguagem. Assim em 2010 surgia o Swift, uma linguagem que é extremamente agradável ordens de grandeza se comparado ao Objective-C. E aqui surge outra enorme vantagem do LLVM. Assim como você pode ter back-ends que cospem binários de Intel ou ARM, você também pode ter múltiplos front-end. Você já tinha o front-end que entendia Objective-C, então eles fizeram um novo front-end pra essa nova linguagem Swift. E qual a vantagem? Os binários de ambos Objective-C e Swift são compatíveis entre si. Então seria super fácil você migrar pra Swift e continuar consumindo as mesmas bibliotecas e frameworks que já existiam e eram feitos em Objective-C. Você não precisa reescrever tudo em Swift, pode migrar aos poucos.

Então no mundo de Mac e iOS você tem agora a escolha de usar Swift com sua sintaxe bem mais moderna inspirada em Ruby, Python, Groovy e outras linguagens, com construções modernas, com o ARC pra gerenciar memória e ter a facilidade de rodar sua aplicação iOS em velocidade máxima no simulador de iOS com tudo compilado em binário de Intel e depois facilmente empacotar em binário de ARM pra rodar no seu iPhone de verdade. Por isso muitos desenvolvedores preferem criar apps pra iOS antes de Android até hoje.

No mundo Android as coisas não eram muito agradáveis. O Google também teve sua parcela de dor de cabeça com processo por propriedade intelectual. Lembram que eu já falei várias vezes que a Sun tinha sido adquirida pela Oracle? Então, eles foram processados por usar Java e a Oracle veio atrás com força. Oito anos depois o processo ainda não acabou e em 2018 a Oracle estava ganhando a batalha. Mas todo esse stress não faz o Google ter muito amor pelo Java. Ao mesmo tempo eles decidiram começar a mudar o foco do Java pra outra linguagem, no caso o Kotlin.

No Android o processo é o seguinte: você escreve seu código em Java e pode usar um compilador normal pra gerar bytecodes Java. Por isso você pode também usar muitas bibliotecas Java que já existem. Daí o bytecode Java é traduzido num segundo conjunto diferente de bytecodes chamado DEX que é o que roda no Dalvik. Antes esse DEX era interpretado no Dalvik, e tinha mais ou menos as mesmas funcionalidades que uma JVM como um Just-in-time compiler ou JIT pra gerar o binário nativo de ARM à medida que era executado. Como eu também já disse, isso é bacana pra aplicativos que rodam num servidor que fica de pé por dias e dias. Mas num dispositivo móvel que você abre um aplicativo e fecha a qualquer momento, um JIT ajuda mas não tanto assim, porque ele não tem tempo pra otimizar como poderia. Fora que rodar um compilador JIT também consome processamento, e isso consome bateria, que é outra coisa que sempre falta em dispositivos móveis.

Então nas versões mais recentes o bytecode DEX é pré-compilado em binário nativo antes de rodar, esse é o processo que você vai ouvir falar como AOT ou Ahead-of-Time compiler. Que é o que um compilador normal como GCC ou Clang fazem: geram binários nativos. O processo de desenvolvimento no Android tem mais passos pra poder ter essa opção de compatibilidade com o bytecode Java, que foi uma jogada importante pra conseguir trazer programadores Java pro mundo Android sem precisar ensinar uma nova linguagem pra todo mundo.

Mas ao mesmo tempo temos a Oracle baforando no cangote do Google e a essa altura já disse várias vezes que Java é uma linguagem que já não é mais considerada agradável de trabalhar e nem tão produtiva se comparado a outras linguagens como o novo Swift. Então o Google foi bater na porta de outra empresa, a JetBrains, que a anos faz uma das melhores IDEs comerciais pro mundo Java, e em 2011 havia começado a criar uma nova linguagem, que assim como Groovy ou Scala ou Clojure também compilam em bytecode compatível com Java. Pro Google foi uma escolha fácil porque eles negociaram pra liberar as ferramentas da JetBrains de graça pra desenvolvedores Android e a evangelizar a nova linguagem deles, que é chamado de Kotlin. Kotlin que é finalmente uma linguagem moderna mas familiar e ser ser exótica demais como Clojure.

Então no mundo mobile, em iOS você ainda pode usar Objective-C que é considerado uma linguagem “velha” mas agora a maior parte do desenvolvimento é na linguagem Swift que é bem mais moderna e produtiva. Mesma coisa no mundo Android onde você ainda pode usar a linguagem Java e as bibliotecas Java que também já é considerado meio “velho” por muita gente mas também pode migrar pro Kotlin que está ainda em adoção por toda a comunidade Android. Você pode até misturar código Kotlin e Java no mesmo projeto. Na verdade, por coincidência, seja porque ambas se inspiraram em fontes parecidas na linhagem de linguagens, Swift e Kotlin tem sintaxes até que similares. Dependendo do código que você ver, pode até quase confundir um pelo outro. Claro, as bibliotecas de iOS e Android são bem diferentes, mas as duas linguagens são igualmente modernas e eu pessoalmente diria que são as melhores até agora para o mundo geral de programação de aplicativos, especialmente se comparar com Java ou C#.

Mas deixando o mundo mobile um pouco de lado, um dos resultados de tudo isso foi a evolução rápida do LLVM enquanto uma solução robusta pra desenvolvimento de compiladores. Em vez de ter que mexer no monolito complicado que é o GCC e ainda ter que lidar com a política da licença GPL v3, você pode ir pro LLVM e foi isso que muita gente fez, menos o Google. Pra ser justo, o Google contribui pro LLVM também mas não usa tão extensivamente quanto a Apple. A linguagem Go eles preferiram criar o compilador do zero, primeiro em C e depois traduzindo o código C no próprio Go. Lembra que eu falo que o Google tem a péssima mania de ficar reinventando a roda? A gente chama isso de NIH ou síndrome de Not-Invented Here, muitos programadores sofrem dessa síndrome de prima-donna de achar que pode fazer melhor que os outros.

Mas já sabemos que C/C++, Objective-C e Swift tem front-ends pra LLVM e sabemos que ele tem back-ends que geram binários pra Intel e ARM. E sabemos que ele tem um design mais moderno, mais modular e com ferramentas mais modernas pra desenvolvedores como o LLDB que muitos consideram melhor do que o antigo GDB. E ele ficou muito bom em otimizar o IR pra gerar binários nativos quase tão performáticos quanto o GCC. Isso abre uma oceano de possibilidades. E se decidíssemos criar mais front-ends pra outras linguagens?

E foi isso que a comunidade open source começou mesmo a fazer. Hoje temos front-ends de LLVM pra ActionScript, Ada, C#, Common Lisp, Crystal, CUDA, D, Delphi, Fortran, Graphical G, Halide, Haskell, bytecode Java, Julia, Kotlin, Lua, Objective-C, a linguagem de shading de OpenGL, Pony, Python, R, Ruby, Rust, Scala, Swift, e Xojo. Mas claro, algumas estão mais avançadas do que outras, algumas são mais experimentais. Algumas usam só algumas funcionalidades como o Just-in-Time compiler do LLVM que é o caso da linguagem Julia e inclusive em lugares inusitados como o banco de dados PostgreSQL que hoje também usa o JIT do LLVM pra otimizar queries complexas.

Uma das linguagens que você mais deve ter ouvido falar que depende de LLVM é o Rust da Mozilla. Agora você sabe o que roda por baixo do Rust e quem gera os binários. A linguagem Rust é uma das mais diferentes de todas que já mencionamos até agora. Sem entrar em muitos detalhes hoje, ela tem um foco maior no problema do gerenciamento de memória combinado com preocupação de segurança. Mas seu maior problema é o que chamamos da ergonomia da linguagem. Apesar de ser uma sintaxe moderna, ela realmente exige mais do desenvolvedor se comparado a um Swift ou Kotlin. Partes do Firefox hoje são escritos com Rust e, adivinhem, alguns evangelistas da linguagem são ex-rubistas também.

Outra linguagem que compila com LLVM que ainda não é muito conhecida mas que eu pessoalmente gosto bastante é a Crystal. Ela se parece muito, mas muito mesmo com Ruby já que é inspirada diretamente nela, e em alguns casos você pode quase copiar e colar trechos de código Ruby e compilar com Crystal sem mexer em nada, então a curva de aprendizado pra quem vem de Ruby é muito mais simples. Ao contrário de Rust a ergonomia da linguagem é muito melhor. Mas Rust tem características que a tornam mais adequadas como substituto de C pra desenvolver código nativo rápido e leve. O Crystal se assemelha mais ao Go, ele tem um runtime maior e um garbage collector maior também. Diferente do Go que tem o investimento infinito Google por trás, o Crystal é um esforço quase voluntário da comunidade, por isso anda mais devagar. Mas graças ao LLVM os binários que o Crystal gera são competitivos com Go mesmo nesse estágio.

E mesmo sem ser programador você provavelmente usa tecnologias LLVM hoje e nem sabe disso. Por exemplo tanto o SpiderMonkey que é a engine, ou motor, de Javascript do navegador Safari no MacOS e no iOS quanto o V8 que é a engine de Javascript do Chrome possuem a funcionalidade de Just-in-Time Compiler ou JIT que eu mencionei já hoje e no episódio anterior. Repetindo: Javascript é uma linguagem interpretada, como Python ou Ruby. O SpiderMonkey e o V8 recebem o arquivo de texto escrito em Javascript e fazem um parsing e começam a interpretar o código.

Porém como vocês já sabem e eu expliquei no episódio da História do Front-end nesta série, começou a surgir o conceito de Single Page Application, que é basicamente um site que se comporta mais como um aplicativo de desktop do que um site web normal de conteúdo. Na prática são sites onde você não fica navegando entre diversas páginas, você carrega uma página e fica nela e por sua vez ela carrega muito javascript pra controlar o comportamento. Imagine Google Docs, ou Spotify. Nesses casos as engines de Javascript, quando percebem que estão rodando faz algum tempo começam um processo que é mais devagar, que é o JIT, e começam a otimizar e compilar as partes do código Javascript mais executadas em binário nativo, que ainda depende do runtime das engines, mas é bem mais eficiente do que interpretação. No caso, o SpiderMonkey usa o JIT do LLVM. SpiderMonkey e V8 passaram anos evoluindo e competindo pra ver quem era o melhor e acho que isso continua assim até hoje.

Por isso aplicativos como Spotify, Atom, Slack, Discord e outros conseguem rodar com performance aceitável. Some a isso que os navegadores por baixo hoje suportam CSS acelerado pelo hardware gráfico, as GPUs como o que já vem integrado no seu processador Intel ou placas externas como os GeForce da NVIDIA ou os Radeon e Vega da AMD. A evolução do que chamamos de GPU foi uma explosão neste século como o de CPUs foi nos anos 70 a 2000. Num determinado momento as GPUs passaram a suportar shaders, que como o nome diz, serviam pra controlar a sombra ou tonalidade das cores. Mas em breve elas passaram a ser programáveis numa linguagem similar a C. E adivinhem, podemos acelerar esses shaders compilando em tempo real, via um JIT, usando LLVM hoje em dia. Por isso se você executar um VirtualBox, a renderização gráfica via software, que é lento, hoje é compilado via JIT por um driver chamado llvmpipe. Se você lida com desenvolvimento com placas NVIDIA tem o compilador pros CUDA cores da GeForce, e a NVIDIA contribuiu os códigos de back-end pra permitir gerar shaders pras suas placas diretamente no LLVM abrindo as portas pra qualquer linguagem poder se beneficiar do processamento paralelo massivo em GPUs.

Agora, o último assunto de hoje pra você entender como o LLVM pode ir mais longe. O Front-end pode ser qualquer linguagem, ele cospe o IR, que é otimizado e depois passado pra um Back-end, que também pode ser qualquer coisa, por exemplo, os back-ends que geram binários de Intel ou ARM como já repeti várias vezes. Porém, vocês já viram que existem os transpilers, como o do Typescript que cospe Javascript. E se pudéssemos usar um front-end de C como o Clang e usar um back-end que cospe Javascript?

Esse é o projeto Emscripten. A demonstração mais impressionante se não me engano em 2014 foi quando a Epic Games pegou uma animação usando a engine de jogos Unreal e compilou com esse Emscripten, usando LLVM, de C pra Javascript e somado às capacidades de aceleração via GPUs dos navegadores via WebGL, conseguiu rodar o que antes era um programa nativo dentro de um navegador, com excelente performance graças a tudo que eu expliquei que dá pra fazer com LLVM. Pra fazer isso, eles limitaram o Javascript num sub-conjunto que ficou conhecido como ASM.js. O conceito é simples: CPUs tem instruções nativas, que podemos escrever em Assembly e usar um Assembler pra cuspir o bytecode nativo da máquina. Máquinas virtuais como a JVM tem seus bytecodes. E se considerarmos que o Javascript é um assembly da máquina virtual chamada navegador?

Isso abre todo um leque de possibilidades. E foi o que inspirou o projeto WebAssembly que surgiu pra formalizar esse sub-conjunto de Javascript que poderia ser o back-end pra compiladores baseados em LLVM. Hoje em dia ainda temos o Enscripten pra compilar em ASM.js e o novo projeto Brynaryen que nasceu sendo uma extensão do Enscripten mas foi reescrito do zero em C++ pra gerar WebAssembly - maldita síndrome de not-invented here, a Mozilla também sofre disso como o Google. Ainda não tivemos nenhum resultado bombástico, mas diversos grupos estão fazendo experimentos pra entender o que realmente podemos fazer. Se você procurar por emscripten vai ver demonstrações muito interessantes, inclusive uma pequena distribuição de Linux compilado inteiro com Emscripten e rodando dentro do navegador, sem emulação nem nada. Na prática, no futuro, poderíamos escrever aplicativos Web em qualquer linguagem e compilar tanto pra WebAssembly quanto pra binário nativo se quiséssemos. Mas ainda estamos no começo dessa jornada.

E por hoje vamos ficar por aqui, pra variar virou um episódio grande, mas eu queria contar essa história pra que você pudessem entender como política influencia a evolução das linguagens, ferramentas e arquiteturas que nós usamos hoje. Não é só uma questão se determinada linguagem é mais rápida que outra ou não. Como programador você precisa entender como diversos fatores externos e modelos de negócio e interesses políticos influenciam tudo que você usa.

Na semana que vem vou retornar ao tema de back-end falando sobre outro assunto que é controverso e muitos se confundem até hoje: concorrência e paralelismo e como diferentes linguagens lidam com isso de formas diferentes. Se ficou com dúvidas nesse episódio não deixe de mandar nos comentários abaixo, se curtiram mandem um joinha, compartilhem com seus amigos, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. A gente se vê semana que vem, até mais!

Descrição no YouTube

Semana passada aconteceu uma pequena controvérsia no mundo Javascript quando um colaborador do Core Team da Lerna decidiu mudar a licença de uso do projeto para proibir colaboradores de empresas como Palantir, Microsoft de usar o projeto.

Vamos entender exatamente o que significa isso.

Seguem os links para este episódio:

• Lerna project (https://lernajs.io/)

• Pull Request 1616: (REVERTED): Add Text to MIT License banning ICE collaborators (https://github.com/lerna/lerna/pull/1616)

• Pull Request 1633: chore: Restore unmodified MIT license (https://github.com/lerna/lerna/pull/1633)

• Eric Raymond: Non-discrimination is a core value of open source (http://esr.ibiblio.org/?p=8106)

• The Cathedral and the Bazaar (http://www.catb.org/esr/writings/cathedral-bazaar/)

• The Open Source Definition (https://opensource.org/osd-annotated)

• Free Software Foundation (https://www.fsf.org/)

• Choose an open source license (https://choosealicense.com/)

• AkitaOnRails: [Off-Topic] Software Livre: Exercício de CAPITALISMO (http://www.akitaonrails.com/2016/04/22/off-topic-software-livre-exercicio-de-capitalismo)

• Eclipse CPL to EPL Transition (https://www.eclipse.org/legal/cpl2epl/cpl2eplfaq.php)

Script

Olá pessoal, Fabio Akita

Mudando completamente de assunto de blockchains e Coréia, vamos falar um pouco de software, mais precisamente, sobre licenças de software e algumas coisas que talvez vocês ainda não saibam.

Me deu vontade de falar um pouco sobre isso por causa da recente controvérsia do projeto Lerna, que se descreve como uma ferramenta para gerenciar projetos javascript num repositório com múltiplos pacotes, um monorepo.

E o assunto em questão foi a recente tentativa de radicalmente mudar a licença do software pra restringir o uso de empresas como Palantir ou Microsoft, que de alguma forma estão ligados com a controvérsia da ICE, a US Immigration and Customs Enforcement. Eu sempre fui favorável a não existir políticas restritivas e punitivas de fronteiras, especialmente a que está em discussão agora nos Estados Unidos.

(…)

Eu não quero entrar no assunto de política internacional. Deixo isso para quem tem experiência no assunto, eu certamente não tenho.

Mas eu certamente tenho experiência com software e licenças e quero ajudar os desenvolvedores a entender o que significa esse episódio.

O ponto em questão foi a abrupta decisão do contribuidor do core team do Lerna, Jamie Kyle em fazer um pull request que edita a licença MIT que a Lerna usa e adicionar cláusulas restritivas e retroativas, literalmente excluindo o uso pelas empresas Palantir, Microsoft, Amazon, Ernst & Yount, Thomson Reuters, Deloitte, Johns Hopkins University, Dell, Xerox, Canon, Linkedin e algumas outras.

Esse assunto apareceu no canal de chat da minha empresa. A gente discute assuntos assim de vez em quando, o que é bem legal. Nem precisei saber a motivação (se é ICE ou o que for), na hora eu já respondi que isso não rolar. Não precisa ser gênio pra saber isso.

E de fato, no dia seguinte, o pull request foi revertido por outro líder do projeto, Daniel Stockman, e o Jamie Kyle foi banido do projeto, citando episódios anteriores que ele fere o código de conduta do projeto. Ironicamente código de conduta que o próprio Jamie adicionou ao projeto.

E porque eu imediatamente já sabia que isso ia acontecer? Vamos entender.

Se você cria código e libera esse código num repositório público, ele ainda é SEU código. Não só código. Quando você faz um trabalho criativo, o trabalho está automaticamente sob seu copyright. A menos que você inclua uma licença, NINGUÉM pode copiar, distribuir, ou modificar seu trabalho sob o risco de tomar um processo.

Agora, à medida que o trabalho tem outros colaboradores esse NINGUÉM inclui você.

Na prática, se você colocar o seu projeto no GITHUB você já concordou com termos de uso dele, dizendo que seu projeto é automaticamente liberado para visualização por qualquer um e portanto passível de sofrer FORK. Qualquer um no GITHUB pode fazer FORK do seu projeto e modificá-lo a partir desse ponto dependendo da licença.

Copyright é um direito legal que, por um certo período de tempo, lhe dá a autonomia de decidir o que fazer com seu próprio trabalho. Aliás, você é responsável por enforçar esse copyright. Independente do que você quer, você, criador, detém esse direito.

Na prática, se você um dia ver um software sem nenhuma licença, passa longe dele! Você está assumindo um risco desnecessário se usar um software sem licença, especialmente se adicionar seu próprio código em cima disso. Se escolher usar mesmo assim, você foi avisado.

Agora, você pode fazer o que quiser com esse direito, incluindo jogar totalmente fora. Se é isso que você quer, você pode usar um Unlicense, que é basicamente abrir mão do direito e torná-lo public domain. A partir daqui é terra de ninguém, qualquer um pode fazer qualquer coisa.

Normalmente o que se faz é: você retém o direito do copyright, mas adiciona uma licença que permite o uso. A licença define o que se pode fazer com esse software e dá garantias aos usuários sobre o uso, cópia, modificação e distribuição.

Agora, você pode escolher uma licença permissiva, ou seja, que dá total liberdade aos usuários ou uma licença restritiva, ou seja, que restringe as liberdades do usuário.

Licenças como MIT ou BSD são permissivas, e é por isso que muitos usam. Dentre as liberdades, a mais importante é que você pode lançar como um produto comercial sem liberar o código fonte modificado.

Licenças como GPL e AGPL são bem restritivas, e essas as empresas precisam passar longe se não souberem com o que estão lidando. Muitos chamam esse tipo de licença de um vírus porque ele se propaga a toda modificação que você fizer e você é obrigado a liberar o código fonte modificado e não pode distribuí-lo comercialmente sem soltar esse código junto. GPL v3 e AGPL são particularmente nefários nesse aspecto. AGPL é feito para quebrar o truque dos Software as a Service.

Num SaaS você pode usar um software GPL v2 (versão 2) mas não precisa liberar o código fonte porque você não está distribuindo o software. Você está liberando acesso à execução do código modificado através de APIs. Então os seus usuários não usam diretamente o código. Pois bem, o AGPL diz que mesmo nesse caso se alguém usa o seu software GPL modificado através da rede, você precisa liberar o código fonte.

Outra forma de burlar o GPL, no caso o GPL v2 é o que ficou conhecido como Tivoização. Tivo é o avô de hardwares como Apple TV ou Google Chromecast. A Tivo usa Linux e outros softwares que são licenciados com GPL v2. Eles liberam o software conforme a licença, mas o hardware é bloqueado e não deixa rodar outro binário que possa ser verificado via assinatura digital, então na prática você tem o código mas não pode rodar no hardware. O povo do Richard Stallman ficou bravo com isso e foi o que levou ao GPL v3 que permite uso de assinatura digital para propósitos de segurança mas evita cenários como a Tivoização.

Uma das consequências disso é a eterna rixa entre o povo do BSD, mais especificamente o FreeBSD que, apesar de não usar a kernel do Linux, usa outros componentes como o compilador GCC. A filosofia do BSD é ser o mais livre possível e eles nunca gostaram muito do GPL v2 por restringir a liberdade dos usuários. A kernel do Linux permaneceu em GPL v2 mas quando componentes como GCC foram migrados para v3 o povo do FreeBSD resolveu levar a sério sair do gcc e foi quando começaram a usar CLang/LLVM no lugar.

BSD, como vocês sabem é a base do Darwin que é a fundação do MacOS e iOS. É uma das razões de porque a Apple investiu tanto em LLVM. Hoje em dia eles também usam somente Clang/LLVM em vez de GCC, e isso acabou gerando frutos possibilitando uma arquitetura flexível e mais moderna e facilitou a invenção da linguagem Swift. Mas isso é tema pra outro episódio.

Como vocês podem ver, licenças é um assunto bem cabeludo. Mas no coração de tudo isso está a história de Richard Stallman e a Free Software Foundation (FS) e a história da Open Source Initiative (OSI) de Eric Raymond, autor do famoso livro The Cathedral and the Bazaar. Esse é o livro que torna famoso a Lei de Linus que diz “dados olhos suficientes, todos os bugs são superficiais”.

Parece a mesma coisa, mas Free Software não é Open Source Software. Open Source é naturalmente mais difundido hoje porque ele é ironicamente mais Free do que o Free Software Foundation, já que é mais amigável a empresas. A Free Software tem a visão mais “pura” da liberdade do software mas restringindo as liberdades das pessoas. O Free da FSF é manter o software Free, o Free da OSI é garantir as liberdade do uso do software - que incluir a liberdade de fechar o software. Ambos estão certos no abstrato. Eu sempre compartilhei da filosofia da FSF mas eu sei como ela não é tão prática no mundo real comparada à OSI.

Muita gente usa free e open source software. Vocês precisam no mínimo ler os textos que explicam a filosofia GNU no site gnu.org e ler os textos de Eric Raymond.

Free e Open source não deve ter nenhuma conotação política. Política necessariamente define e discrimina grupos. Eric Raymond inclusive criticou sobre o episódio da Lerna dizendo que a Lerna deserdou da comunidade open source e deveria ser evitado por qualquer um que valorize a saúde da comunidade. Ele continua dizendo que a escolha do projeto Lerna destrói uma das normas mais profunda que mantém a comunidade open source funcional: manter política separado do trabalho. Leia o blog post do Eric no link que deixei na descrição do vídeo abaixo.

Na página que define Open Source no site da OSI existe a 5a cláusula: Não discriminação contra pessoas ou grupos. Você jamais pode dizer que é pró-diversidade se você age ativamente para discriminar grupos. E aqui vem o problema: não importa quais grupos, quer você concorde com eles ou não.

Uma frase erroneamente atribuida a Voltaire mas que na verdade foi da escritora inglesa Evely Beatrice Hall que eu uso no cabeçalho do meu perfil do Facebook diz: “Eu discordo do que você diz, mas eu vou defender com minha vida o seu DIREITO de dizer isso.”

É muito fácil dizer “somos inclusivos”. Ser inclusivo só com seus amigos ou grupo próximo é fácil. Você só sabe se é realmente inclusivo se você tolera alguém que você odeia. Se não conseguir isso, você é, por definição, discriminatório. É muito fácil se auto intitular altruísta, o verdadeiro altruísta primeiro não busca reconhecimento e está disposto a ajudar até mesmo aquele que ele sabe que não o ajudaria. Fora disso você não é nem inclusivo e nem altruísta, está apenas trocando uma boa ação por auto promoção.

E tudo bem, não existe nenhuma lei dizendo que você precisa fazer isso. Você tem o direito de se auto promover. E sabendo disso, para trabalhar em grupos numa comunidade ou na sociedade, você precisa aprender a separar sua ideologia fast-food ou política da moda e o seu trabalho. E pior: tentar fazer ativismo em torno de uma causa que parece justa, fazendo uma ação que é injusta, discriminatória e sequer legalmente válida - ou potenticialmente ilegal é ERRADO. Não se corrige um mal fazendo outro mal, NÃO IMPORTA a intenção. Ou você respeita a lei, ou você não é diferente de quem está criticando, é assim simples. Não existe “ah mas ele fez pior”. Um mal grande ou um mal pequeno, ambos são maus.

Free e Open Source NÃO é um movimento político. Ele não foi feito pra ser usado pra ativismo. Ele não foi feito pra ser usado como instrumento político. Ele não tem conotações sociais. Os desenvolvedores, fora do código, fora do projeto, deveriam ter total liberdade para fazerem o que quiserem, se quiserem ser pró-Trump ou anti-Trump, pró-ICE, ou anti-ICE, não é da conta de ninguém. Por isso eu não gosto da forma como códigos de conduta tem sido usados para ligar a vida pessoal de alguém com sua colaboração.

Colaboração no mundo open source é voluntário. É uma troca justa. Você investe seu tempo e conhecimento construindo partes de um software. Quanto mais o software se torna famoso, mais seu investimento tem um retorno. As empresas podem usar o software com menos custos de manutenção do que se eles tivessem que fazer tudo do zero dentro de casa, então investir em open source também tem retorno de investimento. Open source é um exemplo real de livre-mercado em funcionamento. Só porque um projeto se torna open source, isso não garante seu sucesso, tanto quanto abrir uma empresa não garante que você vai ficar rico. É um ambiente de seleção natural e sobrevivência do mais adaptável.

O mundo open source, ao contrário do que a maioria pensa, é um dos melhores exemplos de livre mercado capitalista pra lidar com softwares que são commodities. Acredite: todo software que não é commodity, não tá aberto ao público.

As licenças de software garantem o uso, modificação e distribuição. A propriedade do projeto, é dos colaboradores.

Você pode mudar uma licença. Mas pra isso precisa colher a autorização de todas as pessoas que já colaboraram com seu projeto. E não se trata de conseguir 51%, precisa de 100%, não importa se a pessoa fez só um commit mudando uma única linha. Ou você valoriza a contribuição de todo mundo ou você não valoriza ninguém. Não existe “a maioria decide e a minoria cala a boca”. Se fosse assim, open source não existiria como é hoje.

Quando o projeto Eclipse mudou sua licença do CPL para EPL ele levaram mais de um ano pra conseguir todas as aprovações e isso tendo sido bem organizados nesse trabalho.

Achar todas as pessoas pode ser difícil. Conseguir consenso é mais difícil ainda. Talvez você precise remover o código daqueles que não concordaram.

E isso é pra realizar a mudança da licença. Mas mesmo assim, mudanças de licença não são retroativas. Se você deu a licença de uso, você Não pode removê-la no passado. Só pra novos usuários, e só pra novas versões. Senão eu estou retirando direitos que eu dei aos primeiros usuários, se eu fizer isso, qual o propósito de se ter uma licença em primeiro lugar? E que tipo de mal caráter eu estou me tornando se acho que isso é certo? Ah mas a intenção era boa. Não importa. Não é relevante. Você deu uma licença ao usuário que confiou e colaborou no seu software, agora você quer tirar isso dele para comprar a sua consciência frente a um assunto que importância pra você mas pode não ter pra todo mundo. Isso se chama egoísmo. E o assunto em questão eu só vejo de uma forma: criancice e desperdício de talento. Uma pena pois parece que o Jamie costumava ser um bom contribuidor.

Isso tudo que eu acabei de falar é óbvio. Deveria ser óbvio. Deveria ser ainda mais óbvio se você um contribuidor de um Core Team de algum projeto. Um adulto não pode dizer “eu era ignorante da lei”. Você não pode assaltar um banco e dizer “puts, eu não sabia que não podia assaltar um banco”. Ignorância da lei não o torna isento da lei. É SEU direito não se interessar em saber da lei, mas a lei existe independente do que você acha e ela se aplica IGUAL pra todos, independente das suas convicções. De qualquer forma, o episódio deu uma repercussão mais porque a mídia está toda alvoraçada em torno esse negócio da ICE. O dano foi revertido, mas no frigir dos ovos o projeto e a comunidade ao redor dela foi muito prejudicada por causa de uma ação imatura e impensada. Fica o exemplo.

O assunto de licença, ética, leis direitos é super longo e daria pra fazer uma série inteira, então vou parar por aqui. Espero que este episódio tenha aberto um pouco mais a cabeça de vocês se ainda não sabiam dos conceitos que eu disse aqui. O principal: de boas intenções o inferno tá cheio. Crianças, fiquem longe de confusão! Não vale a pena!

Coloquei links na descrição do vídeo. Contribuam com feedback na seção de comentários abaixo, se gostaram dêem um joinha, não deixem de assinar o canal e clicar no sininho para não perderem os próximos episódios! A gente se vê na próxima! Até mais!

Minhas impressões vêm de circunstâncias bem específicas, então isso aqui não deve ser lido como recomendação geral para qualquer situação. Por exemplo, eu não avaliei as opções hospedadas do GitLab, que podem ser mais compatíveis com cenários diferentes do meu.

No meu caso, a mudança para o GitLab fez parte de uma estratégia interna da empresa para ter mais controle sobre nossos próprios dados. Nessa mesma estratégia também migramos do Slack para o Mattermost, e do Pivotal Tracker para uma alternativa open source que eu mesmo mantenho, chamada Central, entre outras coisas.

Antes da migração, eu tinha dezenas de projetos ativos no GitHub e uma porção de projetos arquivados no Bitbucket. Sou do tipo que odeia perder dado, então mantenho backups redundantes e tento nunca apagar nada.

Movi praticamente tudo para meu próprio servidor GitLab e isso dá quase 200 repositórios, espalhados em 4 grupos, com cerca de 80 usuários ativos. Isso representa mais de 13.500 notas, mais de 5.200 Merge Requests, mais de 2.500 builds no CI, e o Sidekiq interno que controla tudo isso já processou mais de 51.000 jobs.

Nos últimos 3 meses desde a migração, venho pagando uma conta de Digital Ocean em torno de $140 por mês pela infraestrutura exata que descrevi no artigo anterior, com máquinas separadas para o GitLab Core, o CI Runner, o CI Docker Registry Mirror, o servidor de cache do CI e máquinas descartáveis para builds paralelos, controladas pelo Runner.

A redução de custo é bem-vinda, claro, mas não foi por causa dela que fui atrás dessa empreitada toda. Eu pagaria tranquilamente o dobro ou o triplo só pela conveniência, só que a estratégia por trás é o que mais importa nesse caso.

Minha empresa tem mais de 60 desenvolvedores, trabalhando a partir dos nossos próprios escritórios em 6 cidades diferentes no Brasil (sem freelancers e sem home-office), se comunicando diariamente pelo Mattermost, fazendo Code Review via Merge Requests do GitLab, recebendo feedback automatizado imediato dos testes pelo GitLab CI, e gerenciando projetos através da nossa própria aplicação Central.

A única peça que ainda está faltando é uma boa ferramenta de análise estática de código. A gente depende bastante do Code Climate, que na nossa experiência é uma das melhores opções que existem hoje.

Eu estava prestes a começar uma empreitada para construir uma versão OSS simplificada para integrar com o GitLab CI, mas o Bryan Helmkamp anunciou recentemente que eles vão lançar a própria “Community Edition” do Code Climate nos próximos meses.

Essa é exatamente a peça que faltava no meu stack, e vai acelerar minha estratégia para o ano que vem.

A Era do SaaS Híbrido

Nos últimos 5 a 10 anos houve um movimento rápido em direção a uma estrutura de “micro-serviços” de terceiros. E isso é realmente ótimo, porque permitiu que muitas empresas pequenas ou até desenvolvedores independentes tivessem acesso a tecnologias que os fizeram andar mais rápido e com cada vez mais qualidade na entrega.

Hoje é super fácil ter um serviço de upload e storage de primeira linha com ferramentas como Cloudinary.

Também é muito fácil ter um banco relacional de ponta, com replicação e escalabilidade, como Heroku Postgres ou AWS RDS.

Gerenciamento de projetos como serviço com Pivotal Tracker, Trello.

Comunicação como serviço com Slack, Hangout, etc.

Gestão de conhecimento como serviço com GitHub, Bitbucket, etc.

Então hoje muitas empresas de tecnologia são um mashup de vários serviços de terceiros diferentes.

Minha pequena implicância é que todo o nosso conhecimento, experiência, portfólio, fica espalhado por uma dúzia ou mais de serviços opacos, completamente fora do nosso controle e dependendo do capricho de cada empresa (ou dos investidores delas).

Não me entenda mal, sou a favor de usar esses serviços, pelo contrário. Uso vários e vou continuar usando muitos deles no futuro previsível. Algumas empreitadas nem seriam possíveis sem a eficiência desse pedaço de um mercado livre baseado em tecnologia.

Só que de vez em quando você chega num ponto de virada onde passa a ser importante ter mais controle sobre seus próprios dados, sua própria identidade. Tanto pela posse em si quanto pela possibilidade de usar esses dados com mais intenção.

E acredito que, chegado esse ponto, a gente deveria ter uma opção que não custasse um rim e um pulmão pra replicar.

Antes de uma opção como o GitLab, estávamos limitados a escolher entre jardins murados como GitHub ou Bitbucket, ou então investir uma tonelada de recursos tentando juntar pequenos componentes open source para construir o seu próprio. Com o GitLab agora temos a opção de fazer uma transição suave para a versão hospedada, sem precisar encarar manutenção de infraestrutura, ou podemos optar por ter controle total. E os usuários não sofrem no processo.

Por isso acredito que o melhor SaaS para sobreviver à próxima década vai começar a entrar no modo Híbrido: ter uma opção comercial, hospedada, geralmente “mais barata”, e uma versão OSS DIY (do-it-yourself).

GitLab é assim. Mattermost é assim. Agora o Code Climate está ficando assim.

Nessa opção, empresas como o GitLab ficam numa situação ganha-ganha. Muito mais gente e empresas podem contribuir para fazer uma plataforma madura e robusta que todo mundo gosta de usar, e ao mesmo tempo cada participante pode estender a ferramenta para seus próprios planos particulares. O GitLab consegue ter um modelo de negócio sustentável atendendo a cauda longa de empresas e desenvolvedores que querem um serviço hospedado razoavelmente acessível, enquanto os 20% do topo podem perseguir empreitadas mais específicas usando a mesma tecnologia.

Dessa forma tiramos a discussão de confidencialidade, do jeito como as empresas tratam nossos dados, e avançamos para ações mais produtivas como construir uma ferramenta que beneficia tanto o público externo quanto os planos internos de cada um.

Jardins murados vieram para ficar. Liberar integração - ainda que opaca - via APIs públicas não é suficiente. É muito animador ver essas novas opções surgindo para preencher essa lacuna. O ambiente OSS junto de um modelo de negócio sustentável faz sentido. E espero continuar vendo cada vez mais concorrentes de serviços fechados seguindo o modelo Híbrido num futuro próximo.

Por que dar o trabalho de instalar, manter e ajustar alternativas open source para serviços hospedados (ainda que opacos) bem estabelecidos? Acredito que seja uma discussão maior do que conveniência, manutenção e corte de custos. A gente deveria começar pequeno, com menos risco, mas à medida que cresce deveria conseguir retomar o controle. Só que normalmente não dá para sair de um jardim murado sem um investimento significativo - e às vezes impossível - em reinventar a roda. Sempre tivemos os pequenos componentes open source sobre os quais esses serviços são construídos, mas ir desses pequenos componentes até um sistema completo é um caminho irrealista.

Com essa tendência possível de pós-SaaS, ou SaaS Híbrido como eu chamo, talvez a gente tenha acabado de ganhar o elo que faltava para ir da mera conveniência ao controle total sem o abismo inerente de custos e riscos.

“A base disso é o mundo open source: a maior experiência capitalista do mundo do software e um exemplo vivo para todos do que é um Mercado Livre Laissez-faire. O melhor lugar para manter e melhorar commodities de tecnologia.”

A estranheza vem da palavra “free”. Por causa dos princípios de liberdade do Free Software, muita gente associa o mundo do código aberto a uma grande experiência “socialista”. Minha tese é o contrário: software livre é a experiência mais capitalista que existe no software. Nenhum governo regula, nenhuma agência protege projeto ruim, toda troca é voluntária e a competição decide quem sobrevive. Um mercado assim não existe em nenhum setor da economia real; o período histórico mais próximo dele foi o fim do século XIX nos EUA, antes do Federal Reserve e do imposto de renda federal.

Matt Asay escreveu na C|NET, em “Código Aberto: É sobre capitalismo, não brindes gratuitos”:

“O segredo é usar software de código aberto como um meio para um fim, e não o fim em si mesmo. Código aberto é um meio de distribuição barata, uma maneira de colocar software nas mãos de potenciais compradores por pouco ou nenhum custo. É uma maneira de tornar a experiência de software social e menos arriscada, porque os usuários podem experimentar antes de comprar e porque eles podem customizar (ou pagar alguém para customizar) o software para suas necessidades por um custo menor do que software proprietário.”

E foi mais direto ainda em “Desculpe, socialistas: Código Aberto é um jogo capitalista”:

“[Sarah] Grey escreve que ’existem alternativas ao capitalismo’. Ela está certa. Infelizmente, código aberto não é uma delas. Código aberto é a essência do Livre Mercado do Capitalismo.”

Definições, para ninguém brigar com espantalho

Antes de seguir, os termos que estou usando. Capitalismo é propriedade privada dos meios de produção, com trocas voluntárias entre os donos dessa propriedade. Livre Mercado é a condução dessas trocas sem coerção e sem regulador: oferta, procura e preços ficam nas mãos dos participantes.

Socialismo, no sentido clássico, é propriedade estatal ou coletiva dos meios de produção. Saúde pública e ensino gratuito num país de economia de mercado são políticas de bem-estar, e não socialismo. A crítica deste texto é ao modelo em que o Estado é o dono da produção.

Com essas definições, defender o socialismo clássico e defender a liberdade individual são posições opostas: o primeiro exige subordinar a propriedade e as escolhas de cada um a uma entidade central.

Software livre é propriedade privada sob licença

Código aberto não é domínio público. Todo software tem dono: o copyright pertence aos autores, e usar, copiar ou modificar esse código só é possível porque o dono concedeu uma licença. Sem licença, ninguém tem direito algum sobre código alheio, como Jeff Atwood lembrou em “Escolha uma Licença, qualquer Licença”:

“Porque eu não indiquei explicitamente uma licença, eu declarei implicitamente um copyright sem explicar como outros poderiam usar meu código. Já que o código está sem licença, eu poderia teoricamente forçar o copyright a qualquer momento e demandar que as pessoas parem de usá-lo. Desenvolvedores experientes não tocam em código sem licença, porque não têm direito legal para isso.”

Existe um teste prático para essa propriedade: o dono pode retirar o código da circulação quando quiser. Em março de 2016, Azer Koçulu despublicou seus pacotes do npm, incluindo o minúsculo left-pad, depois de uma disputa de nome com o aplicativo Kik. Milhares de builds quebraram no mesmo dia, como a Ars Technica reportou. O código-fonte continuava no GitHub; o que ele removeu foi a distribuição no registro.

Concordar ou não com o Koçulu é irrelevante. O pacote era propriedade dele, e a decisão de remover era dele. O mais interessante veio depois: ninguém foi preso, nenhum regulador interveio. O npm restaurou o pacote quebrado e mudou sua política de unpublish. O mercado absorveu o choque e criou anticorpos, sem tirar de ninguém o direito de sair.

A comunidade Ruby viveu uma versão menor disso em 2009, quando _why apagou seus projetos e desapareceu, como contei aqui.

Quando o desacordo é interno, o mecanismo de saída é o fork: quem discorda clona o projeto e compete com o original. Foi o que aconteceu com o io.js, que nasceu como fork do Node.js em 2014 e se fundiu de volta em 2015, sob a recém-criada Node.js Foundation, quando a negociação fez sentido. A história tem vários forks que prosperaram: WebKit a partir do KHTML, LibreOffice a partir do OpenOffice.org, MariaDB a partir do MySQL, X.Org a partir do XFree86. E há derivados que ficaram maiores que a origem, como o Ubuntu a partir do Debian.

Fork é voto com os pés. Custa caro, porque exige manter um projeto inteiro, e é por isso que só prospera quando a motivação é real.

Competição implica o direito de fracassar

Num mercado sem regulador, ninguém mantém projeto ruim vivo artificialmente. Para cada PostgreSQL que existe, dezenas de bancos de dados tentaram e morreram. Para cada distro Linux relevante, centenas viraram nota de rodapé. Isso é sinal de saúde: a seleção está funcionando.

A justiça desse processo é cega. O código não carrega a biografia do autor, e o mercado não distribui medalha por boas intenções. Um projeto sobrevive se convence usuários e colaboradores de seu mérito técnico, e morre se não convence.

Abrir o código, aliás, não salva ninguém. A Nokia concluiu a abertura do código do Symbian em 2010, quando a plataforma já perdia terreno para iPhone e Android. O gesto não reverteu nada: muito pouco, muito tarde.

Eu comparei esse processo à seleção natural num screencast antigo. O software que se adapta melhor às demandas do ambiente é o que mais se reproduz, na forma de usuários e contribuidores. O cemitério de projetos mortos prova que a seleção existe e funciona.

E a paisagem muda o tempo todo. O Apache HTTP cedeu espaço ao NGINX. O Firefox perdeu fatia enorme para o Chrome. O Perl cedeu para Python e para linguagens mais novas como Go. O MySQL perdeu prestígio entre desenvolvedores para o PostgreSQL, enfrentou a onda NoSQL e ainda ganhou um fork competidor, o MariaDB, depois da compra pela Oracle. Nenhum desses projetos tinha direito adquirido ao trono.

O programador paga para participar

O mercado de software livre tem uma inversão curiosa de valores. Numa empresa, o programador recebe dinheiro para escrever código proprietário. Num projeto livre conhecido, é o programador quem “paga”, com seu tempo e sua capacidade, para ter código aceito. Em troca ele recebe reputação, aprendizado, portfólio e, sim, um pouco de vaidade. É uma troca voluntária com benefício para os dois lados, como qualquer outra.

“Preço”, aqui, não se mede só em dinheiro. Valor é qualquer coisa com oferta e procura, e quem define o preço é a competição. A moeda corrente desse mercado é a competência técnica demonstrada em público.

Isso tem uma consequência dura: convencer os outros faz parte do jogo. Se a sua ideia tem valor e mesmo assim ninguém adere, a explicação mais provável está na ideia ou na forma como você a apresenta, e não na burrice da plateia. Culpar a plateia é o jeito mais rápido de desvalorizar a própria causa.

O paradoxo do software livre “socialista”

Imagine o modelo oposto: o mundo do software sob o socialismo clássico, com a produção controlada por uma entidade central.

Sem propriedade individual sobre os projetos, acaba a competição. Projeto ruim que atenda à agenda de quem controla se mantém vivo, mesmo que exista alternativa tecnicamente superior. A escolha sai das mãos de quem usa e vai para as mãos de quem controla. Não haveria acidentes como o left-pad, e o preço disso seria um catálogo imenso de software sucateado que ninguém quer usar.

Sem o benefício individual da troca, acaba o voluntariado. Nenhum programador competente doaria suas melhores horas sem reputação, aprendizado ou liberdade em troca. E se a contribuição virar cota obrigatória decretada em nome do “bem social”, todos farão o mínimo para cumprir a cota. A produção soviética funcionou assim em praticamente todos os setores, com os resultados que conhecemos.

Sem competição, acaba a inovação. Inovação nasce de uma vontade individual de resolver o próprio problema do próprio jeito. Eric Raymond abriu “A Catedral e o Bazar” com essa ideia:

“Todo bom trabalho de software começa coçando uma coceira pessoal de um desenvolvedor.”

Inovação também é transgressora, porque torna profissões inteiras obsoletas. As agências de viagem quase sumiram quando comprar passagem pela internet ficou trivial. As locadoras de vídeo morreram com o streaming. O Uber apertou os taxistas, o Airbnb apertou os hotéis. Quem ficou preso ao modelo anterior sofreu, e o mundo seguiu em frente.

Em software foi igual. O pessoal do GNU Hurd não comemorou quando o Linux explodiu. A Nokia não achou graça no Android. O MySQL não torce pelo PostgreSQL. Quem resiste à dinâmica do mercado fica para trás. Duro, e absolutamente justo.

A distopia do monopólio protegido

Um software proprietário pode ser bom ou ruim; o problema aparece quando ele vira monopólio protegido. A Microsoft dos anos 90 era um monopólio de fato. Podemos discutir se o julgamento do Departamento de Justiça foi justo, mas o golpe decisivo no monopólio veio do mercado: o software livre, com GNU e Linux, e depois a internet comercial, que tirou do Windows o monopólio da plataforma.

Imagine um futuro alternativo em que a Microsoft convence o governo americano de que o Windows é essencial à segurança nacional e merece proteção permanente. Tudo teria parado. Até hoje usaríamos um Pentium de 100 MHz rodando um derivado de Windows 98, com internet discada, porque “ninguém precisa de mais que isso”.

É essa a lógica de quem entrega as decisões do mercado a uma entidade central: não crie e-mail, vai prejudicar os carteiros; não crie sites, vai prejudicar as gráficas; não crie software livre, vai prejudicar os programadores do governo. Todo ditador usa o mesmo discurso, “para o bem da população”, e todo discurso de “para o bem da população, não importam os meios” termina no mesmo lugar.

Tirania e o fim do software livre

O pior caso possível para um projeto livre começa assim. Um desenvolvedor cria um software para resolver um problema e abre o código. Por vinte anos, centenas de pessoas usam e contribuem.

Então surge uma causa, qualquer uma, e alguém se autonomeia representante dela. Por pressão social e propaganda, os mantenedores viram párias. A mídia especializada amplifica, porque controvérsia atrai leitor. O código deixa de ser o assunto: o que passa a valer é a opinião pessoal, a aparência e o passado de cada colaborador.

A partir daí, participar do projeto vira um risco. Ninguém recebe mais valor por contribuir; só recebe exposição. Um a um, os que realmente escreviam código vão embora, e o projeto definha. É uma forma perversa de tomar uma propriedade e destruir seu valor sem confiscar nada formalmente.

Ayn Rand dramatizou esse mecanismo no julgamento de Howard Roark, em “A Nascente”, e escrevi sobre isso em 2011:

“Eu vim aqui dizer que eu não reconheço o direito de qualquer um a um minuto da minha vida, ou a qualquer parte da minha energia, nem a qualquer conquista minha, não importa quem clame por isso!”

Esse é o aviso. Uma camada política sobre um projeto livre destrói o mercado que sustentava o projeto.

Conclusão

Nada disso condena quem contribui por motivação social. Quem troca seu código pela sensação de estar ajudando faz uma troca voluntária como qualquer outra, e isso fora do software tem nome: doação e trabalho voluntário. O problema começa quando alguém decide que a propriedade alheia deve servir à causa que ele escolheu.

Resolver os problemas do mundo é muito mais difícil do que discutir sobre eles. Bill Gates deu esse recado em 2000, respondendo ao hype de que PCs acabariam com a pobreza:

“Ótimo, visite os centros da Infosys em Bangalore, mas saia do oásis e vá três milhas adiante, atrás do cara que vive sem privada, sem água encanada… O mundo não é plano, e PCs não estão, na hierarquia das necessidades humanas, entre as cinco primeiras posições.”

Programadores, de qualquer classe social, têm internet e recursos de sobra para passar o dia em redes sociais discutindo como salvar o mundo. Quem trabalha de verdade nesses problemas está fora desse circuito, executando em vez de falar.

Termino com um caso real que me relataram, sem nomes:

A: Puxa, ninguém dá chance à minha [minoria].

B: Por que você não me ajuda a resolver estes problemas neste projeto open source? Daí você pode palestrar sobre isso.

(A some. B espera, cansa, e chama C, que resolve os problemas e ganha o espaço de palestrar.)

A: Tá vendo, B? Você é parte dos opressores que não dão espaço pra gente como eu, e preferiu dar a oportunidade pro C.

E uma nota pessoal para encerrar. Me taxam de “seguidor de Ayn Rand”, e estão enganados: Rand apenas pôs por escrito, antes de mim, o que eu já pensava e praticava. O mesmo vale para Bastiat, Friedman, Hayek ou Menger. São referências, e referências não são donos. Julgar uma ideia pelo autor em vez de julgar o argumento pelo mérito é a definição de ad hominem, e eu não respondo bem a falácias.

Primeiro foi a perda do venerado Jim Weirich, em 20 de Fevereiro de 2014. Ele foi o autor do projeto Rake. Veja seu Github para ver no que ele contribuía. E de curiosidade, leia um pouco da história do Rake que está dentro do seu código-fonte. Jim sempre foi uma presença essencial nos eventos de Ruby e Rails e tem diversas palestras excepcionais que vale a pena assistir. Antes de partir, ele era Chief Scientist da consultoria NEO.

Em 30 de Novembro de 2014, foi a vez de Ezra Zygmuntowicz, ele foi um dos co-fundadores da famosa Engine Yard. Na época em que ele e Tom Mornini dirigiam a empresa, eles tiveram as equipes do JRuby e do Rubinius sob seu patrocínio e tutela. Ezra foi quem pegou o Mongrel de Zed Shaw e explorou o mundo de evented I/O antes de Node.js, com o Evented Mongrel (que depois foi substituído pelo projeto Thin), foi um dos primeiros a explorar e ajudar a popularizar o Redis, ele trouxe a tona a idéia de Platform as a Service antes do Heroku, a idéia de infraestrutura como software (antes da onda Devops), trouxe o projeto Merb (que depois viria a ser incorporado ao Rails 3). Depois disso, ele saiu da Engine Yard e passou um tempo desaparecido em Portland, Oregon. Começou uma startup de impressão 3D (quando impressão 3D estava começando) mas acabou não dando certo. Pouco antes de partir ele estava twitando que iria empreender uma nova idéia. Ezra foi um visionário como poucos que existem hoje, e o mundo vai sentir sua falta. Assista algumas de suas palestra no YouTube.

Finalmente, em 28 de Dezembro de 2014, perdemos James Golick, um grande companheiro de outro rubista que talvez seja mais conhecido, Joe Damato. Talvez muitos dos rubistas mais novos não tenham ouvido falar dele, mas ele ficou conhecido alguns anos atrás principalmente por causa do projeto Resource Controller, que ele resolveu parar em 2009 por causa de uma alternativa chamada Inherited Resources apareceu para substituí-lo. Eu mesmo cheguei a contribuir um pouco nesse projeto na época. Mas ele era um contribuidor open source prolixo, vejam seu Github para ver as últimas coisas em que trabalhou. Eu fiz uma video entrevista com ele na Railsconf 2010 em Baltimore, assistam aqui.

Todos os 3 eram programadores queridos na comunidade, com reconhecimento pelos seus feitos, e principalmente pelo exemplo de seus bons caráters. Devem ser relembrados nos anais da história desta comunidade e vamos sentir muita falta deles.

Vamos trabalhar em 2015 e adiante para que seus esforços não tenham sido em vão.

PS: fiquei particularmente triste com a perda de Ezra porque coisa de algumas semanas antes dele partir, estávamos combinando de trocar idéias, um Hangout que nunca mais vai acontecer:

No último dia de 2014, Brian Shirai soltou um post unilateral entitulado “Matz’s Ruby Developers Don’t Use RubySpec and It’s Hurting Ruby”, onde ele explica porque é ruim o Core Team do MRI não usar regularmente o projeto RubySpec, vale a pena dar uma lida.

Como contexto, vale explicar que Brixen é quem herdou o manto da implementação Rubinius e também do projeto RubySpec, que tenta ser uma suíte de testes que define o comportamento do que é a “linguagem Ruby” para que implementações alternativas como o próprio Rubinius ou JRuby ou outras possam se basear. Os projetos originaram com Evan Phoenix, atual membro do Ruby Central e organizador das RailsConf. Digamos que Evan é mais “politicamente correto”, Brian é mais “agressivo”.

O problema é que o Brian basicamente “joga a merda no ventilador e sai fora”, que é o tipo de atitude mais infantil e menos efetivo possível. E vindo de um conhecido contribuidor open source como Brian, obviamente isso causou um shit-storm no Twitter e outras redes. Ele simplesmente “acusa” o Core Team do MRI de sabotar o RubySpec ao não usá-lo como ele gostaria. Um dos principais nomes que vieram para defender o Core Team foi Charles Nutter, que é contribuidor tanto do JRuby quanto do próprio MRI, alguns dos comentários mais interessantes e que explicam o ponto de vista do Core Team, eu cito abaixo:

@jamie_gaskins RubySpec was designed from the ground up. MRI's suite is decades old. What we need are people to help clean it up.

@josh_cheek And what of redoing over a decade of work in MRI's suite? It's there, it works, we use it to test JRuby. Don't buy the FUD.

@jamie_gaskins We use it as our primary compatibilty suite for JRuby. We also run RubySpec, but it's far less complete.

@josh_cheek I don't think anyone would disagree that MRI's suite needs improvement, but throwing it out is absurd.

@jamie_gaskins I also don't find MRI's tests hard to read. When I find ugly ones in the future, I will be fixing them. Help me :-)

Folks don't seem to realize JRuby runs MRI's test suite as our primary compatibility suite. It's not pretty, but it's OSS...help us fix it.

@jerrydantonio Please don't spread this kind of FUD. I know most of ruby-core personally and they've been very supportive of JRuby.

@jerrydantonio If they don't use RubySpec, it's because RubySpec did not meet their needs -- as stated in the article.

@jerrydantonio You are going based on what one person says without understanding the complexities involved.

@jamie_gaskins You can submit PRs to MRI's github/ruby/ruby mirror (which may turn into the main repo this year).

@jamie_gaskins If you start looking into it, copy me on your PRs. I'm a committer, and I can help get them in.

@jamie_gaskins Not at all, and ruby-core are all on board with switching to git now too. Like I said...that post is a massive dose of FUD.

Another reminder: I'm a member of the MRI core team and a committer. Got a problem? I'm listening. Let's collaborate, friends.

@samsaffron It doesn't matter if their suite serves their and our needs. It's aesthetics at that point. Aesthetics can be fixed.

@iainbeeston It just a political move. It's still alive and still OSS...if it's valuable to use it on MRI, we can still use it on MRI.

@zedshaw @mentalguy @raganwald The segfault was not reported. And yes, they fix bug reports. ruby-core is still almost all volunteer time.

@johnbender Don't take one article's assertions as truth. There's a lot of misinformation there.

@jc00ke @_zzak I'd like to know why RubySpec wins and MRI is at fault. Does Rubinius run MRI's suite, like JRuby?

@fugueish One person's story. I've been implementing Ruby longer and I have seen steady improvement. It's a community effort.

@josh_cheek And please don't spread FUD like this. There are real people working really hard on MRI. Help them instead.

@raganwald @codefolio @saturnflyer Indeed. But don't start saying things like "MRI devs don't write tests" because they usually do (now).

@chromatic_x The full run of MRI's suite on JRuby includes 5941 tests with 1091418 assertions (we exclude parts). They're indispensable.

@iainbeeston Either that, or it inspires ruby-core and us to improve MRI's suite. Positive things can come from a negative post. :-)

@chromatic_x In any case, MRI is the reference impl, so expecting them to drop their decades-old suite for someone else's is rather bold.

@headius Personally, I think that RubySpec is useful and valuable, but throwing MRI under the bus for not using a tool is pretty petty.

@r343l @sunnyrjuneja No, it doesn't. I don't agree with technical articles that don't take comments. Might as well be a press release.

Lesson for today: here's what you do when you find a bug in a project, rather than just blogging about it: https://bugs.ruby-lang.org/issues/10685

Shyouhei Urabe, um dos principais voluntários japoneses do Core Team disse a coisa mais óbvia logo que o post do Brian saiu:

Release of #ruby happens Dec. 25th EVERY YEAR. If rubyspec found a SEGV, why didn't they report that and blame core devs instead?

Logo em seguida Nate Berkopec fez um apanhado geral e uma explicação/especulação das razões pelas quais o artigo de Brian Shirai está errado no que ele quer atingir.

Em resumo, existe uma grande frustração no time do Rubinius em geral. Ao contrário do JRuby que tem um nicho de usuários e projetos em produção onde ele faz diferença, o Rubinius em si nunca alcançou nenhum uso significativo. Em Outubro de 2013, ele havia anunciado que o Rubinius começaria a experimentar mais e quebrar compatibilidade com o MRI o que, pra mim pelo menos, soa mais como um tiro no pé. Mas eles acharam que, por méritos técnicos, o Rubinius poderia ser o melhor substituto para o MRI. O controle do RubySpec leva nessa direção e por isso a frustração do Core Team nunca adotá-lo “oficialmente”.

Hoje (2/1/2015), o próprio Evan Phoenix resolveu endereçar o assunto pessoalmente no Twitter com o Matz, e eis a transcrição:

@evanphx 1. I wonder if, all those years ago, I misunderstood Matz. Maybe "I like other ruby implementations" was really "I don't mind they exist"

@evanphx 2. I thought it was "I want to help them" but Matz really didn't mean that. He just mean "good luck friends!"

@yukihiro_matz @evanphx Sorry for confusion & disappointment. I still don't know what kind of help you wanted. You do want to control your project as I do.

@evanphx @yukihiro_matz I should have asked: Could the CRuby team help track new features so other impls could know what they are missing.

@yukihiro_matz @evanphx the MRI team maintains the forked version of RubySpec https://github.com/nurse/rubyspec I think it can be a good start.

Existe muito mérito nos esforços que as pessoas contribuíram aos projetos Rubinius e RubySpec ao longo dos anos, porém eles falharam ao tentar forçar sua visão do que deveria ser “o certo” em vez de colaborar com o projeto que já existia muito antes deles chegarem que é o Ruby MRI. É como se você fizesse um kernel alternativo ao Linux e começasse a dizer nas listas por aí que o Linus Torvalds deveria seguir essa alternativa porque é o “jeito mais certo”. Sabe qual seria a resposta do Linus? “Fuck You!”. É que o Matz é bem mais educado do que isso, mas seria a resposta mais adequada a esse tipo de atitude.

Qual seria a alternativa? Charles Nutter já demonstrou: ele é ao mesmo tempo líder da implementação alternativa JRuby e também contribui diretamente no Ruby MRI. Ele roda as suítes do MRI e do RubySpec, em paralelo, no projeto JRuby. Não há atrito entre JRuby e MRI. Mas há atrito entre Rubinius e MRI. O problema não é técnico, não é sequer político como muitos declararam, é um problema de caráter e atitude. O problema é que o estilo do Core do Rubinius sempre foi “somos os melhores, eventualmente todo mundo vai notar isso”. Essa atitude é altamente destrutiva, frustrante e acaba com declarações suicidas como a do Brian Shirai.

Uma coisa que eu sempre digo: fazer um projeto green field (do zero) é muito fácil, qualquer criança faz isso. Agora, pegar um projeto brown field (velho, cheio de débitos técnicos), é bem mais complicado, bem menos recompensador a curto prazo e por isso poucos (só os melhores) conseguem a disciplina para tentar transformar um brown field num green field. O Rubinius e RubySpec são green fields que tentaram enfiar goela abaixo do Core Team. Não é assim que se prova um ponto de vista. Releia os comentários do Nutter acima, é o que ele tenta explicar.

E é uma pena, pois tecnicamente Brian e o Core Team do Rubinius são muito bons e seria bom ver esse talento dentro do MRI. Porém, entre ter alguém tecnicamente bom mas de caráter duvidoso, é melhor não ter. Essa sempre é a melhor alternativa.

Em resumo: nada muda do lado do Ruby MRI, não é nenhuma crise ou algo assim. O MRI deve continuar como sempre: com Matz como seu único ditador benevolente e talvez, com alguma boa vontade, eles permitam o projeto RubySpec ser incorporado dentro do MRI sob a tutela do Core Team do Japão, como deve ser.

Se você é um programador experiente, não precisa de mim para ouvir isso. Mas se as notícias recentes deixaram você inseguro, talvez o que eu tenho a dizer traga alguma perspectiva.

Antes, quero compartilhar outros artigos que li nos últimos dias:

• My Next Chapter: a declaração de Mike Perham, um dos rubistas mais conhecidos desta geração e criador do onipresente e excelente Sidekiq. Ele não abandona o projeto; conta que está tocando um produto novo, e esse produto não envolve Ruby.

• Saying Goodbye To Python: aqui foi o pythonista Ian Bicking, que declarou trocar Python por JavaScript, seguindo a onda do momento. Vale entender que a bolha atual de JavaScript não “exige” que você “abandone” nada. Dá para ser pythonista e usar JavaScript ao mesmo tempo, sem conflito.

• Why I Left the .Net Framework: o desenvolvedor Jonathan Oliver resolveu explicar por que está deixando a tecnologia do dia a dia e aponta os prós e contras das ferramentas Microsoft. Nada de trollagem; é uma leitura bem interessante.

• Java Again: quem é das primeiras gerações da comunidade Java lembra de James Duncan Davidson, criador nada menos que do primeiro Tomcat e do Ant. Ele deixou o Java, passou um tempo na comunidade Ruby e se dedicou à fotografia (procure as fotos das RubyConf de oito anos atrás e vai ver que as oficiais são todas dele). Agora declarou que está voltando ao Java.

• Why Go Is Not Good: como o nome diz, é uma crítica que argumenta que uma linguagem recém-lançada deveria ter sido melhor pensada para cobrir casos que outras linguagens já resolvem.

• Rust vs Go: de novo com um certo tom de “dor de cotovelo”. Rust realmente parece uma tecnologia superior a Go em design de linguagem e recursos, e o texto demonstra a frustração de ver Go mais popular mesmo assim.

• Why Perl Didn’t Win: leitura obrigatória sobre as circunstâncias de uma das linguagens mais populares do fim dos anos 80 ao fim dos anos 90, que caiu no esquecimento e no desuso. Até o Swift, lançado pela Apple semanas atrás, já tem mais usuários ativos que o Perl 6. Uma das conclusões: qualquer coisa nova precisa mirar os problemas do futuro, não os do passado.

Quem é das primeiras gerações das comunidades Ruby e Rails vai lembrar dos “traumas” que passamos:

• Zed is Not Dead: de 2008, quando um dos nossos desenvolvedores mais prolíficos, Zed Shaw, criador do Mongrel e um dos primeiros a encarar o desafio de medir e otimizar a performance do Ruby, declarou que estava deixando a comunidade e migrando para Python.

• Bomba: Merb e Rails se fundem!: também de 2008, quando a equipe do Merb estava em rota de colisão com o Core do Rails. A solução, feliz para muitos e infeliz para alguns poucos, foi engolir o Merb dentro do Rails 3, e ela deixou mortos e feridos. Em retrospecto, vale ler “Learning from Rails’ failures”, de Matt Aimonetti (que também migrou para Go) e que está entre os feridos dessa insurgência, e “The Rails/Merb Merge In Retrospect”, de Giles Bowkett (ainda rubista), que analisa os resultados com olhar bem crítico.

• Twitter muda de Ruby para Java: de 2011, quando o Twitter declarou que estava substituindo as partes da infraestrutura de mensagens escritas em Ruby por uma solução proprietária em Scala. O que a notícia original dizia e o que as pessoas escolheram memorizar são coisas diferentes, mas o fato é que aquilo virou uma bela dor de cabeça de relações públicas para nós. Felizmente já passou.

E esses são só os links que li e lembro de cabeça. Existem dezenas de outros.

Quem ainda é jovem ou inexperiente em comunidades de software, em especial quem é novo no Node.js, deve estar se perguntando: “E agora? Se alguém importante como o TJ diz que está saindo, eu não deveria sair também?” Se fizer sua pesquisa direito, vai ver que não é a primeira vez. Em 2012, o criador do Node.js, Ryan Dahl declarou que continuaria acompanhando o projeto, mas não estaria mais no dia a dia de codificação. “Putz, o mundo acabou!”

Isto não é uma Má Notícia. Esta é uma Excelente Oportunidade! (Sério!)

Em 2006, quando eu estava começando minha militância no mundo Ruby e Rails, eu já sabia o que vinha pela frente. Éramos os novatos, imaturos, com tecnologia incompleta e muita expectativa, então o caminho seria o mais difícil possível. Foi por isso que escrevi o artigo Evolução pela Concorrência.

Muita gente imagina que o melhor dos mundos seria aquele em que ninguém questiona o que você faz, todos deixam você em paz e acreditam nas suas promessas que, claro, você pretende cumprir um dia. (yeah, right…)

Eu discordo. Qualquer promessa ou expectativa que valha a pena precisa ser questionada, pressionada, escrutinada. Se ela é tão frágil que não aguenta crítica, ataque direto e indireto e sabotagem, então a promessa já era fraca e não merecia seguir em frente. Quanto antes cair, melhor, porque menos tempo a gente perde.

Por isso eu sempre abraço os ataques: espero estar pronto para revidar em dobro ou morrer tentando. E não esperaria menos da comunidade Rails. Todo mundo ainda acredita que restrição é ruim, mas eu já disse antes que restrição é importante, porque é o único lugar de onde nasce a inovação.

Quem precisa recorrer ao velho truque de falar mal dos outros, o famoso “não tenho vontade de melhorar, então vou prejudicar o outro para parecer maior” (escrevi sobre isso em 2007, “Para eu ganhar, o outro precisa perder…”), se declara fraco por conta própria. Pare e lembre de artigos, palestras e entrevistas em que você ouviu alguém que admira falando mal de outra comunidade. “Ah, Ruby, aquele negócio de menininha. Porque nós, homens, usamos JavaScript.” Isso me dá vontade de rir e um pouco de pena, porque para mim fica claro que a pessoa sempre vai ser fraca.

Todas as declarações acima, e outras parecidas (“Estou deixando Node”, “Estou deixando .NET”, “Estou deixando Ruby”, “Estou deixando X”), eu honestamente acredito que vieram sem má intenção ou má fé, ao menos não conscientemente. Mas tenho uma teoria. Quem faz declarações assim quer validação dos pares, ou pior, quer que os pares o sigam, o que também é uma validação da própria posição. “Não gosto mais do meu brinquedo velho, mas também não quero que ninguém brinque com ele.” É uma posição bem infantil.

Tomando a comunidade Ruby como exemplo, vários nomes meio que “largaram” suas atividades principais sem bater a porta nem agir com infantilidade. Chad Fowler está na Alemanha tocando o Wunderlist, focado em desenvolvimento mobile e back-end, e não fala mais de Ruby. Ilya Grigorik teve sua startup comprada pelo Google e acabou sumindo também. Matt Aimonetti, depois do episódio Merb vs Rails, se retirou em silêncio e hoje trabalha com Go.

Ryan Bates, um dos mais queridos da comunidade pelo trabalho incansável de anos no RailsCasts, parou de publicar faz meses e não declarou nada a respeito. David Chelimsky, mantenedor do RSpec, passou o bastão adiante e saiu sem alarde. José Valim, um dos principais nomes por trás do Rails 3, hoje está com Elixir e Erlang e raramente comenta algo sobre Ruby.

“O.M.G! Quer dizer que tudo acabou!? Foi pelos ares!?”

Não. Nesse meio-tempo, centenas de novos rubistas surgiram e tocaram o trabalho para a frente. O exemplo mais imediato são Carlos Antônio e Rafael França, que meio que assumiram o manto do José Valim no Rails Core. Evan Phoenix assumiu o manto do Chad Fowler na Ruby Central. Avdi Grimm meio que assumiu o do Ryan Bates com o excelente RubyTapas, e por aí vai.

Uma comunidade é feita de indivíduos, e cada indivíduo rende mais quando age para maximizar o próprio benefício. O efeito colateral disso é que ele acaba influenciando e puxando outros para cima junto com ele. São sempre trocas voluntárias para benefício mútuo. Ninguém age sem nenhum benefício próprio; há quem acredite que sim, e são justamente esses que chegam mais rápido ao “burnout”, porque logo a pergunta vira:

"Por que eu me canso tanto de colaborar nessa comunidade, me estresso, e mesmo assim nem todos apreciam o que eu faço? Eu faço tudo por eles!"

Essa é a pergunta errada, e pergunta errada leva a resposta errada. Alguns começam a achar que os outros lhe devem algo, já que dedicaram tanto do tempo livre (ainda mais no mundo open source) para “ajudar os outros”. E “os outros” acham que não devem nada, porque ninguém pediu esse esforço em primeiro lugar. Na prática, “os outros” estão certos.

Se você participa de uma comunidade, faz isso por você mesmo. Pode ser porque entende que ajudar os outros faz parte da sua recompensa pessoal. Pode ser porque isso traz paz de espírito ou consciência limpa. Ou porque você é bom estrategista e sabe que certas contribuições vão abrir portas lá na frente. O motivo não importa, desde que exista uma recompensa que você não cobra dos outros de forma obrigatória. Cobrar respeito, educação, compaixão, nada disso faz sentido sem contrapartida. Ninguém pediu para você fazer o que faz; se está fazendo, entenda que é por você. Essa é a definição de trabalho voluntário.

E deixando bem claro: trabalho voluntário é trabalho sem remuneração financeira, e não trabalho sem benefício ou puramente altruísta. Se o seu trabalho é remunerado, a conversa é outra, e aí o melhor conselho é o do Don Draper:

Voltando ao assunto, imagino que os nomes que citei, os que se retiraram de forma parcial ou silenciosa, entendem isso. Foram buscar satisfação pessoal em outro lugar. Não devem nada a ninguém, e ninguém deve nada a eles.

Já quem sai com declaração bombástica está, consciente ou não, jogando na cara dos outros: “você não me valorizou, agora perdeu a chance, e eu sei que vai sentir minha falta!” Não está escrito assim, mas é o que faz sentido. Do contrário, por que jogar no ventilador e transformar aquilo em controvérsia pública? Todo argumento por escrito é só parte da razão, nunca “a” razão.

Você, Indivíduo

O outro lado da moeda é quem segue, admira e idolatra uma dessas pessoas que largaram o lugar onde você está. Dependendo do nível de admiração, você fica sem chão, atordoado, sem saber para onde correr. Aí acontece uma de duas coisas: ou você procura outro ídolo e começa o famoso “ele nem era tão bom assim”, ou afunda na depressão e no desespero do “não sei o que vai ser agora”.

Meu conselho: "não tenha ídolos, tenha referências."

Pare de achar que você deve alguma coisa aos outros e, por tabela, pare de jogar nos outros a responsabilidade de ajudar mais gente. É isso que está acontecendo: você não entende o seu propósito e acha que os outros têm que fazer aquilo que você mesmo não faz. Pior, você deixa os outros decidirem o caminho que você vai tomar. Se a insegurança é tão grande assim, pare um instante e reflita sobre o que você “é” antes de tudo.

Seu único propósito na vida é cuidar de si mesmo e produzir, sem atrapalhar o caminho dos outros. Quando você faz isso, o efeito natural é que colaborações espontâneas aparecem, comunidades evoluem e todo mundo sai ganhando. Uma comunidade onde todos cobram todos cresce sem propósito.

Sobre tecnologia, opinião, proposta e promessa, lembre também: você quer estar sob “ataque” e restrição constantes. Não existe nada pior do que ser ignorado. Escrevi outro artigo, tradução de alguém bem mais sábio que eu, a Kathy Sierra, chamado Dilbert e a zona de mediocridade, onde cito:

Quanta coragem você tem? Até onde você (ou seu empregador) iria para evitar a Zona de Mediocridade? A menos que você esteja disposto a arriscar provocar ódio passional, talvez nunca sinta o amor. Scott Adams concorda. Num post recente no blog do Dilbert, ele escreveu: "Se todo mundo que for exposto a um produto gostar dele, o produto não terá sucesso... A razão pela qual um produto que 'todo mundo gosta' vai falhar é que ninguém o 'ama'. A única coisa que prevê sucesso é paixão, mesmo que só 10% dos consumidores a tenham."

E daí se alguém deixou a sua comunidade? Será que ela é tão frágil que uma pancada, não importa o tamanho do impacto, vai fazer tudo desmoronar? Se você acredita que a sua comunidade é apenas resistente, você tem razão: passado certo ponto, ela desmorona. Mas se ela for resiliente, maleável e adaptável, ela sobrevive. É o que garante a sobrevivência das espécies, a Lei do Mais Adaptável (não do mais “forte”; lembre da diferença entre resistente e resiliente, você quer ser o segundo).

Você é adaptável? Ou está só procurando validação dos outros, deixando que eles decidam por você? Uma coisa eu garanto: se um dia eu desistir do que faço, ninguém vai ficar sabendo por um comunicado escrito. Isso eu já tinha decidido no dia em que comecei.