Mudança na forma de desenvolver o Ladybird
(ladybird.org)- O Ladybird vai deixar de aceitar pull requests públicos em preparação para o primeiro alpha release e para o lançamento real do navegador para usuários, e apenas os mantenedores do projeto passarão a introduzir mudanças no código
- Com as ferramentas de IA tornando mais rápido e barato produzir trabalhos que parecem contribuições sérias, o modelo de confiança anterior — no qual patches grandes indicavam boa-fé e esforço significativo — enfraqueceu
- Um navegador executa entradas não confiáveis de toda a internet na máquina do usuário, então basta uma única vulnerabilidade bem disfarçada para ser suficiente para um invasor
- Todos os PRs públicos atualmente abertos serão fechados, e não será criado um processo separado de envio de patches via issues, comments, email ou forks, nem um sistema de contribuições paralelas
- O Ladybird continuará sendo open source, e a participação externa será direcionada para relatos claros de bugs, reproduções reduzidas, testes de sites, discussões sobre padrões e design, relatórios de segurança e feedback técnico, em vez de envio de código
Essência da mudança no processo de desenvolvimento
- O Ladybird passará a não aceitar pull requests públicos e fará a transição para um modelo em que apenas os mantenedores do projeto introduzem mudanças na base de código
- Na etapa de preparação do primeiro alpha release, tornou-se necessário um processo de desenvolvimento mais rigoroso, um modelo de segurança mais claro e um grupo menor responsável pelo código que entra no navegador
- No passado, patches substanciais eram um sinal indireto razoável de esforço significativo e boa-fé, mas essa suposição deixou de valer com as ferramentas de IA
- Um navegador executa na máquina do usuário entradas não confiáveis da internet, e uma única vulnerabilidade bem disfarçada já cria condições suficientes para um atacante
- Já houve campanhas pacientes e bem financiadas no open source para conquistar a confiança dos mantenedores e abusar dela; o que mudou é que agora ficou mais rápido e barato produzir trabalhos que parecem contribuições sérias
- Todas as mudanças que entram no Ladybird precisam se alinhar à arquitetura, suportar refatorações futuras, interagir corretamente com o restante do navegador e poder ser compreendidas pelos mantenedores
- O ponto central não é se o código foi escrito à mão, e sim quem se responsabiliza por ele depois que entra no navegador
Medidas de transição e formas de continuar participando
- Todos os pull requests públicos atualmente abertos serão fechados, e manter a fila existente significaria, na prática, deixar o caminho de contribuições públicas ainda aberto, então a transição será feita agora
- Daqui em diante, pull requests serão disponibilizados apenas aos mantenedores do projeto
- Não será criado um processo separado de envio de patches via issues, comments, email ou forks, e forks ou dumps de patches não serão tratados como fila de revisão do Ladybird upstream
- Código externo pode existir de acordo com os termos da licença
- O Ladybird continuará sendo open source, e o código-fonte seguirá sendo publicado sob uma licença open source
- A participação externa ajuda o projeto a avançar por meio de bug reports claros, reductions, website testing, standards discussion, design discussion, security reports e technical feedback
- Na etapa de preparação para lançar o navegador para usuários reais, o processo de desenvolvimento também precisa estar à altura dessa responsabilidade
2 comentários
Comentários do Hacker News
Tenho visto muitos PRs de grandes projetos open source como o Godot ultimamente, e aumentou bastante a quantidade de PRs em que tanto o código quanto a explicação foram feitos por IA
Pela política do projeto isso é proibido, então normalmente o autor recebe só um aviso leve, mas muita gente aceita isso bem, enquanto alguns ficam irritados por acharem que os mantenedores não estão sendo gratos
Parece que até mesmo as pessoas que aderiram totalmente à IA ainda não internalizaram que simplesmente produzir um monte de código não tem valor intrínseco
Embora o esforço próprio delas tenha caído muito, ainda esperam a mesma reação ou gratidão de antes da IA ao abrir um PR grande
Nesse contexto, não espero que as pessoas de atitude ruim que sempre foram numerosas neste setor mudem de comportamento por causa da IA
Aliás, um funcionário não técnico do meu trabalho começou a abrir PRs gerados por IA em um repositório interno que eu administro, e a qualidade é excelente; além disso, ele aceita bem o feedback da revisão e incorpora tudo rapidamente. O problema não é ser ou não técnico, e sim uma questão de atitude
Isso aparece não só na forma de contribuir, mas também no jeito de falar no dia a dia. Coisas como “eu fiz X”, insistir que a própria “curadoria” teve enorme influência no resultado, dificuldade de falar sobre a contribuição do LLM, atitude de “eu foco em construir e os outros perdem tempo com detalhes”, recusa em encarar falhas potenciais, e por aí vai
É surpreendentemente diferente dos desenvolvedores seniores que vivem desconfiando de que aquilo que produziram pode estar cheio de falhas e ter sido feito às pressas. Parece uma síndrome do impostor invertida
O problema está 100% do lado de quem envia esses PRs. Se alguém tem histórico de quebrar regras de projeto sem o menor constrangimento e ainda agir com arrogância, isso deveria ser um enorme sinal de risco para possíveis empregadores ou futuros colaboradores que vejam o perfil dessa pessoa
Não entendo por que alguém destruiria deliberadamente a própria reputação. É muito melhor não ter atividade nenhuma no perfil do que deixar um registro de mau comportamento
Algo como: “Isso não serve para proteger os limites do projeto nem para garantir a qualidade do código. É apenas um mecanismo de gatekeeping criado por tradicionalistas que se sentem ameaçados por criadores visionários como você, que realmente dominaram a eficiência da IA”
“Um patch substancial significava esforço substancial, e esse esforço era um indicador substituto razoável de boa-fé. Agora essa suposição não se sustenta mais.”
Essa frase é o ponto central do texto, e acho que vale para a maioria dos projetos
Ainda assim, é preciso existir algum mecanismo para avaliar se alguém pode se comprometer o suficiente no longo prazo para virar mantenedor. Contribuições ao código agora são difíceis de confiar como sinal disso, e não sei que tipo de sinal vamos usar no futuro. Vai ser um problema bem complicado
Mas, se a IA realmente aumentar drasticamente a produtividade dos programadores, talvez projetos open source bem-sucedidos nem precisem de equipes grandes de mantenedores
Por um lado, se você cresceu no bazar, mudar para a catedral pode parecer “a morte do open source”. Mesmo que, na prática, talvez seja apenas um retorno a uma forma mais antiga de trabalhar
Por outro lado, deixar de aceitar contribuições externas de código certamente melhora a postura de segurança, mas tornará mais difícil descobrir quem convidar para o sacerdócio
Antes do GitHub ganhar força, projetos open source pareciam mais jardins murados. Eram como pequenos clubes em que, ao entrar na sala, todos te olhavam fixamente. O GitHub mercantilizou o contato e reduziu a barreira de esforço e interesse necessária antes de contribuir
Agora essa fase acabou, e é preciso construir confiança primeiro antes de contribuir com qualquer coisa
Isso não é a morte do open source, e sim a morte da aldeia global onde todo mundo circulava livremente e interagia com facilidade. É o renascimento de comunidades pequenas, sociais e baseadas em confiança, e eu gostaria que isso se espalhasse pela internet inteira
Será que as pessoas hoje sequer conhecem essa metáfora ou o livro do Raymond? É um mundo em que a Microsoft é uma grande fornecedora de open source e controla a plataforma que viabiliza a maior parte da programação open source no planeta. Tente explicar isso para um viajante do tempo vindo do fim dos anos 90
Além disso, como um comentário irmão sugeriu, até um “bazar” clássico como o kernel do Linux hoje parece bastante uma catedral quando comparado ao modelo de bagunça ilimitada do GitHub
Por isso não vejo a decisão da Ladybird como um problema. Pelo contrário, vejo como uma decisão que reforça o lado humano do desenvolvimento de software e põe um freio nos oportunistas da IA
Não é o ideal, mas construir reputação sempre deveria levar tempo
Ao ver esse tipo de coisa, dá vontade de pensar que seria melhor se IA nem existisse
É muito decepcionante que projetos de código aberto estejam perdendo a capacidade de encontrar novos mantenedores e treiná-los
“Não haverá procedimento para enviar patches por nenhum meio” e “a participação externa continua importante: relatórios de bug claros”
Então quer dizer que dá para encontrar e corrigir bugs, mas não pode dizer exatamente como corrigiu?
Em vez disso, a equipe tem que descobrir de novo. A equipe deve ficar realmente animada por ter que refazer algo que outra pessoa já fez repetidamente
Como usuário e desenvolvedor, não vejo por que eu deveria gastar tempo com um projeto que coloca esse tipo de barreira em um software que poderia melhorar minha vida. Parece muito mais fácil usar Firefox ou Chromium, onde minhas correções podem de fato ser aceitas
No passado, quando uma nova versão do Chromium fazia meu produto travar, eu pude propor uma correção para o V8, e ela entrou na versão seguinte do Chromium, fazendo o produto voltar a funcionar (https://github.com/v8/v8/commit/4f8a70adca01c)
Sem esse canal, os desenvolvedores do Chromium talvez não tivessem tempo para descobrir a causa e corrigir
Dizem que “pull requests não revelam mais tanto sobre o autor quanto antes”, mas ninguém deveria precisar saber nada sobre a pessoa que enviou o pull request
Espero que o código que entra no Firefox ou no Chromium seja decidido com base na correção do código verificada na revisão, e não no “esforço” ou na “boa vontade” de quem enviou
Revisar uma correção de código é claramente mais fácil do que pensar nela do zero. Se não for assim, então é só escrever o código diretamente
Do ponto de vista do projeto, sempre é possível ignorar ou fechar PRs indesejados. Mas bloquear a própria opção de revisar contribuições externas ou usá-las como insumo para uma reescrita própria não parece inteligente
Compartilhar essa análise refinada é a melhor forma de maximizar a contribuição. O código, no máximo, é um bônus opcional
Sua correção pode ter valor, mas esse valor pode não ser maior do que o custo de revisá-la e aceitá-la
Dizer que “revisar uma correção de código é claramente mais fácil do que criá-la do zero” está completamente errado em projetos suficientemente complexos. A correção pode ser de uma linha, mas as consequências podem se espalhar muito longe
Como usuário e desenvolvedor, se você não quer gastar tempo com um projeto que tem essas regras, então não gaste. Você não deve nada ao projeto, e o projeto também não deve nada a você. É simples assim
Firefox e Chromium operam com equipes muito maiores, sem falar no kernel Linux. Talvez eles tenham folga para aceitar sua contribuição
Isso vale não só para a minha experiência e para os casos citados no texto original, mas também para a experiência de inúmeros mantenedores que compartilharam textos parecidos
Você pode compartilhar links de projetos de código aberto que você mantém há anos e cujas contribuições você revisou, que sirvam de base para sua autoridade nesse assunto?
Basta escrever em linguagem natural para que o mantenedor possa entender a abordagem da solução
As prioridades e necessidades delas são diferentes. Neste caso, elas avaliaram e concluíram que não era útil. Isso significa que o custo foi maior que o benefício
É interessante que, em pelo menos um aspecto importante, Chromium/Gecko/WebKit agora pareçam motores de navegador mais “abertos” do que o Ladybird
O Servo fica mais ou menos no meio, já que aceita contribuições externas contanto que você não use IA
Dá para entender que uma equipe com pouco financiamento precise fechar contribuições para economizar custo de trabalho. Mas também fico com a sensação de que as pessoas não reconhecem o suficiente os recursos econômicos que Google/Mozilla/Apple colocam para tornar essa abertura possível
Para deixar claro meu viés e minha experiência pessoal, hoje estou aposentado, mas antes eu trabalhei no Chrome na Google. Vi muitos colegas formarem contribuidores externos, e eu mesmo fiz um pouco disso, informalmente ou por meio de programas como estágios
Não acho que devamos ser eternamente gratos pela construção de monopólios
Entendo por que estão tomando essa decisão. Se a maioria dos pull requests é código escrito por IA, os mantenedores também podem simplesmente colocar prompts direto no Claude Code
Acho que o jogo inteiro da engenharia de software, seja open source ou não, mudou completamente. Um bloco de código já não significa nem implica a mesma coisa que há 2 anos
Alguns anos atrás, se eu enviasse um PR complexo que compila e passa nos testes, isso significava que eu tinha investido esse tanto de tempo e esforço cognitivo. Se eu não entendesse a base de código, a funcionalidade ou o bug, provavelmente não teria feito esse investimento
Agora, o custo para obter esse entendimento continua mais ou menos parecido com antes, mas a IA reduziu muito o custo de gerar código que compila e passa nos testes
Membros bem-intencionados da comunidade ficam felizes em contribuir com a parte barata, isto é, tokens do Claude Code, mas isso ficou barato demais para servir como um bom indicador de que também contribuíram com a parte cara, que é o entendimento humano
Estou trabalhando em projetos paralelos com OpenCode, e gasto bastante tempo escrevendo prompts, configurando os arquivos certos e explicando o produto e o roadmap que quero construir
Eu monto um loop de validação bem fechado, no qual posso rodar muitas verificações automáticas depois de cada mudança, e então faço muitos testes manuais dos casos de borda que a funcionalidade gerada pode quebrar, repetindo esse ciclo. É um tipo diferente de trabalho, mas consigo avançar mais rápido do que codando à mão. O componente principal é o loop de validação
Pela minha experiência dos últimos meses, programar com IA também é uma habilidade, e você aprende técnicas novas conforme tenta e vai melhorando. Isso também quer dizer que, se fizer bem, dá para produzir resultados valiosos
Então discordo da primeira frase, mas concordo totalmente com a segunda. O que perdemos foi a capacidade de distinguir facilmente entre resultados profundamente pensados e resultados gerados sem pensar. Aqui, focar em validação barata ajudaria muito
Acho que todo projeto vai nessa direção. Faz mais sentido refinar o plano em conjunto
Quando a IA apareceu pela primeira vez, eu tinha medo de perder meu emprego algum dia. Tive sorte, mas muita gente realmente perdeu, e isso doeu bastante
Quando alguém perde alguma coisa para a automação, independentemente da lógica econômica, a gente acaba ficando do lado humano ou pelo menos torcendo para que a sociedade continue sendo justa com quem é mais afetado
Agora estou vendo comunidades serem afetadas. Se você matar os PRs, não abala só a contribuição de código, mas também contribuições invisíveis como ideias e mais olhos sobre o código. Isso parece muito pior
Estou dividido, confuso e com medo. Ainda assim, uso Claude, DeepSeek, várias tecnologias, harnesses complexos e MCP etc. Mas agora tudo isso parece uma transição. Só não sei transição para o quê
Muitas perguntas não podem ser respondidas sem atribuir sentido à vida. Toque humano? Já é tarde demais? E também teve uma música de que eu gostava, mas era do Suno. Quando descobri, tirei meu like. Eu me sinto idiota com frequência demais
Desculpem o desabafo desconexo. Gosto do Ladybird e até tenho um adesivo dele no notebook. Espero que dê certo
A sensação é de estar no meio de um tornado. Mesmo assim, ajuda desligar a tela, sentar à mesa e pensar devagar, com calma, lembrando dos primeiros princípios
Para citar Obama, “a realidade acaba alcançando”
Fala-se muito, mas o iOS não está entregando 10 anos de recursos e correções a cada ano. Literalmente ninguém está conseguindo fazer isso, e, na verdade, o que se ouve são reclamações de que funcionalidades existentes estão quebrando. Então não pode ser verdade que chegamos a 10x de produtividade, e esse fato no fim vai nos alcançar
Precisamos pensar como seres humanos. Também precisamos lembrar que muita gente está emocionalmente investida nisso. Os juniores querem que seja uma chance de brilhar num mercado que os rejeitou. Os CEOs apostaram na IA e não querem voltar atrás. Os sêniors querem sinalizar que não se tornaram inúteis. As empresas de IA vão poluir o debate. Mas essa fumaça vai se dissipar no fim
Em geral, acabavam em opiniões não solicitadas, tentativas de aquisição hostil, extração de valor, drama em geral e uma carga operacional ampla jogada em cima do simples trabalho de fazer código
Nem sempre foi assim, mas o modelo de desenvolvimento open source livre no estilo GitHub e a remoção de todo atrito claramente criaram um novo padrão
Esse modelo já era insustentável desde o início, mas a taxa de desgaste era baixa o bastante para seguir substituindo pessoas exaustas por mais pessoas e continuar funcionando
A IA fez a taxa de desgaste ficar maior do que a taxa de reposição. Então é bem provável que mais projetos adotem essa postura ou algo parecido
Sou criador e programador, e uso agentes no desenvolvimento mesmo não gostando de ver o que está acontecendo em certas comunidades. Assim como foi difícil evitar Google e Stack Overflow quando surgiram, parece que também existe um momento claro de antes e depois com os LLMs
Não tenho muito mais de útil para acrescentar, mas queria dizer que você não está sozinho em sentir esse conflito. Coisas novas costumam ser assim. Em algumas áreas trazem ganhos enormes, mas em outras parecem arrancar a humanidade; algumas pessoas produzem pose e lixo, enquanto outras ganham novas capacidades e fazem coisas melhores. Infelizmente, não parece haver uma verdade universal
Este texto deixa uma sensação estranha. Isso porque o autor costuma abrir PRs não triviais com frequência passando de 1 mil linhas, às vezes vários no mesmo dia, e tende a fazer merge no próprio dia sem revisão
Mesmo deixando de lado a questão dos LLMs, isso já é assim. Não sei qual porcentagem deles recebeu ajuda, mas mesmo que fosse 0%, não é uma velocidade de desenvolvimento com a qual eu me sentiria confortável
“O ponto principal não é se o código foi digitado à mão. O importante é quem assume a responsabilidade depois que o código entra no navegador. O Ladybird está se tornando um navegador para usuários reais. Quem introduz uma mudança deve ser a pessoa que decide que aquela mudança pertence ao projeto e que responderá pelas consequências.”
Há uma plataforma open source que usamos na empresa há anos, e usamos a versão Enterprise paga. Entrou uma falha de segurança bem bizarra nessa plataforma e, ao investigar, dava para perceber que a IA tinha tomado conta do projeto
Estando isso explicitado ou não, basta olhar o log de commits: fica claro pelo volume e pela frequência. Foi muito decepcionante
[1] https://github.com/awesomekling
Os LLMs podem ser um dos motivos que levaram o Ladybird a tomar essa decisão, mas não são o único motivo possível. Por exemplo, o SQLite vem sendo desenvolvido mais ou menos assim quase desde o começo
Parece que cada um tem seu próprio jeito
A licença é MIT e os mantenedores sempre agradecem relatórios de bugs, mas todo o código do projeto foi escrito por apenas 3 pessoas
É uma medida totalmente razoável para proteger o próprio tempo e o projeto
Comentários do Lobste.rs
Hoje em dia, revisar contribuições no clang é miserável demais. Chega uma fila interminável de PRs lixo, e as pessoas estão ficando melhores em esconder os sinais óbvios, mas na maioria das vezes ainda dá para perceber, e filtrar isso toma tempo
Mesmo quando alguém admite usar IA e descreve como usou, ainda preciso verificar de novo se isso é verdade ou se a pessoa está minimizando o uso para tentar fazer um PR ruim passar
Já vi muitos PRs assim até agora, mas acho que nunca vi um PR de vibe coding que fosse realmente bom. Alguns ficam num nível “ok” e o autor até começa o trabalho de verdade, mas a maioria some, e nos restantes fica óbvio, mesmo sem conhecimento interno do clang, que erram completamente desde conceitos básicos de programação
O pior são scripts que automatizam o pipeline fuzzer→bug→LLM→PR, interpretam mal bugs reais de forma grave, “corrigem” de um jeito quebrado e ainda adicionam testes ruins, ou nem incluem o caso que originalmente falhava
No fim, isso até reduz minha vontade de investir tempo ajudando novos contribuidores a desenvolver capacidade. Quando um nome que nunca vi antes envia um PR corrigindo um crash, minha primeira reação é suspeitar se isso é perda de tempo ou se a pessoa realmente pode virar um contribuidor de verdade
Quem só joga lixo no projeto não tem interesse em contribuir nem em aprender, e a maioria parece só querer colocar algo como “contribuiu para o clang” no currículo
Depois voltou várias vezes perguntando “por que a lista não atualiza? por que eu ainda não apareço?”, e quando o site foi atualizado, sumiu
Dito isso, eu mesmo era parecido e tolo quando era mais novo. Uma vez ouvi dizer que dava para espelhar o site de uma figura famosa do open source, então fiz um espelho e mandei e-mail pedindo para me colocarem na lista; também assinei a lista de discussão de desenvolvimento do nmap porque queria virar um 1337 hax0r, mas nunca enviei nenhum patch
A definição do problema é clara para todos. Ao longo de décadas, projetos de código aberto aprenderam em quem confiar por meio das contribuições de código; as pessoas faziam o trabalho, assumiam responsabilidade pelas mudanças e permaneciam, e a confiança surgia do próprio trabalho
Mas isso me parece uma versão estritamente pior da política de proibir contribuições com LLM escolhida pelo projeto Zig
Com as ferramentas de IA mudando rapidamente a economia, um PR agora já não diz tanto sobre quem o enviou quanto antes. Patches grandes costumavam significar grande esforço e eram um bom indicador indireto de boa-fé, mas essa suposição já não se sustenta
O que preocupa é que código aberto já é um negócio difícil e deveria aproveitar ao máximo as vantagens valiosas que tem; contribuidores trazem um valor enorme praticamente de graça (contributor poker) e também são muito importantes como caminho de contratação. Rejeitar tudo isso parece uma escolha insana
Dá para argumentar que LLMs podem preencher essa lacuna, mas, em primeiro lugar, seria possível proibir o uso de LLM apenas em PRs de contribuidores não confiáveis; em segundo, até os melhores LLMs custam dinheiro, o preço dos tokens está subindo, o código de qualquer forma precisa ser revisado e, no fim, eles não podem se tornar contribuidores centrais confiáveis responsáveis por partes da base de código
Se você elimina a entrada de código vinda de PRs, com o tempo um pequeno número de contribuidores passa a possuir todo o código, e fica mais fácil para o projeto fazer um rugpull de licença. Quando a propriedade dos direitos autorais está bem distribuída, isso é mais difícil
No geral, isso não parece bom. Está tornando o código aberto um modelo de negócio desnecessariamente mais problemático, dificultando a contratação de contribuidores centrais e concentrando a propriedade do código em poucas pessoas. É uma receita óbvia para desastre, a ponto de me fazer suspeitar se isso foi apenas um erro ou se alguns patrocinadores do Ladybird estão jogando algum jogo estranho
Fico curioso sobre o que realmente está por trás dessa mudança. É uma virada muito brusca para um projeto que vivia se gabando, na abertura dos relatórios mensais de status, do número de novos contribuidores variados. A explicação apresentada agora parece, no mínimo, incompleta
Tanto Zig quanto Ladybird estão tentando descobrir como seguir em frente em um futuro que ninguém queria. Ficamos sem entender nada por anos e, honestamente, eu não esperava que esse futuro chegasse. Agora já não está nada claro o que seria “a coisa certa” a fazer
O que eu perguntaria ao Zig é: não dá para distinguir PRs com LLM de PRs feitos diretamente por humanos. Dá para filtrar lixo de baixo esforço, mas, para impor “sem IA”, você precisa de algum tipo de teste de Turing — e eu, com uma licença do Claude Pro, provavelmente conseguiria passar
O que “proibir IA” faz na prática é permitir atacar a pessoa e sua reputação quando alguém envia código de LLM, alega que foi manual e acaba sendo pego. É nisso que queremos gastar tempo? Seria como criar um equivalente do Karl Jobst para caçar quem usa LLM fingindo programar na mão
Isso não impede PRs com LLM; só muda o jogo para “tenta me pegar se conseguir”. Quando vi o Andreas tomar no Ladybird uma decisão próxima de um rugpull, primeiro senti um frio na espinha; depois pensei que, pelo menos, coragem ele tem. Assistência por LLM e confiança são realmente um problemão, então eu gostaria de ver tanto Zig quanto Ladybird pensando fora da caixa
Na prática, ele é um Designator e, pelo que entendi, mantém esse cargo por toda a vida, a menos que renuncie ou se torne incapaz. Os Designators decidem por maioria, mas como são apenas 2, ambos precisam concordar; além disso, eles nomeiam e removem Directors, e mudanças no estatuto também exigem sua aprovação
Ou seja, ele efetivamente tem poder de veto sem contrapesos sobre a organização sem fins lucrativos. O mesmo vale para Andreas, mas Andreas é quem construiu uma parte significativa do trabalho, está envolvido no projeto e não é bilionário. Wanstrath é bilionário, decidiu doar uma fração minúscula de sua fortuna e não participa da operação, mas mesmo assim tem o mesmo poder
A menos que eu esteja deixando passar alguma boa razão jurídica, isso não soa como uma boa estrutura de governança para um projeto de código aberto
Fico preocupado com o que vai acontecer no longo prazo com projetos que recentemente fecharam contribuições. Em algum momento, parte do núcleo confiável vai embora, e sem contribuidores veteranos já comprovados talvez não exista um sucessor óbvio
O caminho padrão pode acabar levando a burnout e projetos abandonados, então espero que encontrem uma forma de superar isso
Não vejo isso como qualquer tipo de liderança. Não é nem um passo na direção certa, nem uma ideia de como podemos conviver com isso juntos
Entendo que a pressão é real, mas a resposta parece decepcionantemente cínica e derrotista, em vez de enérgica e esperançosa
A parte “Como parte desta mudança, vamos fechar todos os pull requests públicos atualmente abertos” foi chocante
Há alguns anos, um projeto fechou um PR meu ao decidir que não tinha recursos para revisá-lo, e isso doeu bastante, além de parecer injusto com quem investiu trabalho naquele PR
Entendo os motivos apresentados, mas a decisão me preocupa. Não quer dizer necessariamente que seja ruim, e pode até ser aceitável se for temporária e depois encontrarem outro meio-termo, mas ainda assim preocupa.
Também não é o primeiro sinal de alerta. A reescrita em Rust com ajuda de LLM me passou uma sensação parecida. Diferente do Bun, foi feita com relativamente mais cuidado, com componentes em tamanho revisável, entradas e saídas claras e execução em paralelo com os componentes existentes para detectar divergências. Mesmo assim, não é o tipo de abordagem que eu gostaria de ver em um motor de navegador.
Espero que a Ladybird dê certo. Quero ver um novo motor de navegador desafiando a estrutura de oligopólio. Mas, pensando na possibilidade de a Ladybird sair dos trilhos, também é um alívio ver que o Servo, que ficou estagnado por anos, está avançando bem.
Estão usando código-lixo de IA na implementação em Rust, apoiam DHH, ou seja, parecem alinhados com supremacismo branco e posições anti-LGBT, e também parecem bastante agressivos. Não acho que esse projeto vá longe.
Se não houver uma porta de entrada para que pessoas de fora se tornem contribuidoras, parece que muita coisa vai se perder. Mesmo que seja necessário um compromisso mais sério do que simplesmente aparecer e mandar um PR.
Fazer isso aumenta o grupo de pessoas que conhecem a base de código quando quiserem adicionar desenvolvedores, e organizações externas também podem resolver necessidades que a equipe principal não prioriza. Isso ajuda na adoção e também reduz a carga de trabalho.
Não me parece correto colocar a tag vibecoding neste post. É fundamentalmente estranho agrupar as vítimas de vibecoding com a mesma tag das pessoas que promovem esse comportamento.