Desenvolvedor reescreve sete aplicativos da Adobe em Rust e abre o código

Um desenvolvedor reescreveu sete aplicativos da Adobe em Rust e publicou o resultado em acesso aberto. De graça, com o código-fonte. A informação vem de um vídeo do Fireship de 12 de outubro de 2026, em que o autor do canal executa esses clones e verifica o que funciona neles. O título do vídeo é mais duro do que a própria notícia: "Todo aplicativo na Terra agora é open source, queira ele ou não".

O que se sabe de fato

Há poucos fatos no anúncio, e vale citá-los de forma direta. São sete aplicativos. A linguagem de implementação é Rust. A licença é aberta e o preço é zero. O vídeo é um teste, não um lançamento oficial com benchmarks. A descrição não revela os nomes dos programas, o nome do autor, o tamanho da base de código, os formatos de arquivo suportados nem o grau de compatibilidade com os originais. Por isso, qualquer conversa sobre um "matador do Photoshop" ainda é precipitada: é preciso ver o que abre, o que se preserva e onde quebra.

A escolha do Rust é compreensível. A linguagem oferece gerenciamento de memória previsível, bom desempenho e compilação multiplataforma prática, inclusive via WebAssembly. Para ferramentas gráficas e de mídia, em que o código C++ se acumulou por décadas, é um alvo lógico de reescrita.

Por que o título fala em "todo aplicativo"

O tom irônico do Fireship sugere uma tendência mais ampla. Reescrever um produto maduro do zero antes significava anos de trabalho de uma equipe. Hoje, com agentes de programação capazes de ler especificações, analisar o comportamento de um programa e gerar grandes volumes de código, essa barreira cai bastante. O anúncio não confirma isso diretamente, e não se pode afirmar que houve uso de IA. Mas a própria frase "queira ele ou não" aponta justamente para esse cenário: a funcionalidade de um produto comercial é reproduzida sem a permissão do dono.

Daí vem também o principal risco para o projeto. A Adobe protege o código, os formatos, a marca e as soluções de interface. Um clone escrito "por comportamento" é juridicamente diferente de um clone que usou trechos descompilados ou recursos fechados. Ainda não se sabe qual caminho o autor escolheu, e isso determina se o repositório sobreviverá, no mínimo, por alguns meses.

O que precisa ser verificado

Para avaliar o projeto, alguns parâmetros concretos são importantes:

• Licença: MIT, Apache, GPL ou algo mais exótico, e se ela é compatível com uso comercial.
• Compatibilidade de formatos: se PSD, AI e outros arquivos de trabalho abrem sem perda de camadas, efeitos e fontes.
• Desempenho: comparação com o original em projetos grandes, e não em um arquivo de demonstração.
• Origem do código: se foi escrito do zero e se agentes de IA foram usados.
• Manutenção: se o projeto tem mais de um mantenedor e um plano de desenvolvimento.

Conclusão prática

Para designers e estúdios, ainda é cedo para adotar esses clones nos fluxos de trabalho: sem garantia de compatibilidade, uma exportação mal-sucedida custa mais do que a assinatura. Por outro lado, vale clonar o repositório, rodar seus arquivos típicos e anotar exatamente o que não funciona. Para desenvolvedores, o ponto interessante é outro: se uma única pessoa de fato montou sete aplicativos, isso serve de referência para estimar o esforço de reescrever código legado em Rust. Advogados e equipes de produto dos fornecedores precisam rever o modelo de proteção: quando a funcionalidade é reproduzida rapidamente, o valor migra para o ecossistema, a nuvem, os dados e as integrações, e não para o executável em si.

O vídeo do Fireship é um bom motivo para olhar o projeto com os próprios olhos, mas é melhor tirar conclusões depois de verificar o repositório, e não o título.