Depois de ser removido da equipe do XLibre, artist passou a criticar publicamente o projeto. No entanto, os registros apresentados pelo XLibre mostram uma colaboração pequena diante da responsabilidade que ele aparentemente havia assumido.

Existe uma regra não escrita no software livre: quanto mais próximo você está de um projeto, maior é a sua responsabilidade diante dos problemas que conhece.

Um usuário comum pode encontrar um bug, reclamar em um fórum e seguir a vida. Um mantenedor não. Muito menos alguém apresentado como integrante da equipe central de um projeto e ponto de contato de uma distribuição Linux.

É exatamente por isso que a recente disputa entre o XLibre, o Artix Linux e o desenvolvedor conhecido como artist me parece muito menos uma denúncia técnica corajosa e muito mais o resultado de uma colaboração que não conseguiu se sustentar.

Não posso provar que artist entrou no XLibre de má-fé, que forçou sua entrada ou que planejou algum tipo de ataque. Também não posso entrar na cabeça dele e afirmar que suas críticas foram motivadas exclusivamente por ressentimento.

Mas posso observar a sequência dos acontecimentos:

1. Artist ocupava uma posição de responsabilidade.
2. Sua colaboração pública parece pequena diante dessa posição.
3. Ele foi removido da equipe.
4. Depois disso, passou a enfatizar publicamente os defeitos do projeto.
5. Quando foi confrontado com os próprios registros de colaboração, a discussão deixou de parecer apenas técnica.

A conclusão, para mim, é simples: artist aparentemente não conseguiu manter a função que assumiu e reagiu mal quando essa posição lhe foi retirada.

A confusão veio a público depois que o perfil oficial do XLibre republicou uma resposta escrita por callmetango, um dos mantenedores do projeto.

Segundo o XLibre, essa resposta havia sido publicada no tópico “OpenRC with XLibre?”, no fórum do Artix Linux, e apagada em 24 de julho de 2026.

O texto respondia a críticas feitas por artist, que teria recomendado aos usuários do Artix a instalação do Xorg tradicional ou do xorg-server-tearfree. O argumento era que o XLibre ainda acumulava regressões e demorava para incorporar determinadas correções.

Até aí, nada de extraordinário.

Projetos têm bugs. Forks recentes apresentam regressões. Distribuições precisam decidir se determinado software está maduro o suficiente para seus usuários. Criticar tecnicamente o XLibre não é, por si só, um ato de deslealdade.

O problema começa quando descobrimos que artist não era apenas um usuário do Artix fazendo uma avaliação externa.

Segundo callmetango, ele era membro do XLibre Core Team e o ponto de contato do projeto com o Artix Linux.

Se isso estiver correto, a pergunta muda completamente.

Em vez de perguntarmos apenas se o XLibre tem bugs, precisamos perguntar:

É nesse ponto que a posição de artist começa a desmoronar.

Callmetango afirma que artist havia sido lembrado, em 14 de junho de 2026, de sua responsabilidade de registrar os problemas do XLibre nos rastreadores oficiais.

Entre 14 de junho e 23 de julho, porém, a pesquisa pública apresentada pelo XLibre mostrava somente uma issue criada por artist4artixlinux no repositório do Xserver.

Essa issue estava relacionada a uma transformação do xinput que teria deixado de funcionar em uma versão recente do servidor.

Isso não prova que artist não tenha trabalhado em outras frentes, conversado com usuários ou aplicado patches nos pacotes do Artix.

Mas revela uma diferença difícil de ignorar entre dizer publicamente que o projeto possui muitas regressões e efetivamente registrar esses problemas nos locais apropriados.

Artist conhecia os problemas como membro da equipe. Também seria o contato responsável por uma distribuição. Mesmo assim, teria registrado apenas uma issue no período questionado.

Bugs comentados em fóruns não substituem bugs registrados no upstream.

Uma conversa perdida em um tópico do Artix não oferece necessariamente:

* passos para reprodução;
* informações sobre o hardware;
* logs;
* versão afetada;
* confirmação de outros usuários;
* acompanhamento da correção;
* ligação com commits e pull requests.

Se artist conhecia tantas regressões quanto sugeria, o lugar natural para documentá-las era o rastreador do XLibre.

Não é razoável aceitar uma posição dentro da equipe, deixar os problemas dispersos em fóruns e, posteriormente, utilizar a ausência de correções como argumento contra o próprio projeto.

A resposta do XLibre também confronta a ideia de que artist ou o Artix teriam corrigido uma quantidade significativa de problemas antes que o upstream agisse.

Segundo os registros apresentados, artist havia criado sete pull requests no repositório principal do Xserver. No momento da consulta, todos estavam encerrados, mas somente um aparecia como efetivamente incorporado ao projeto.

Esse pull request apresentava uma solução relacionada ao cursor em máquinas virtuais.

Os demais teriam sido encerrados por diferentes motivos. Alguns seriam duplicados, um estaria relacionado a um problema do servidor de build do Artix, outro teria sido substituído por uma solução diferente e um teria sido fechado pelo próprio autor.

Há também um pull request incorporado ao driver de vídeo da Intel.

Portanto, a contribuição de artist não foi inexistente.

Ele colaborou e teve código aceito. O próprio XLibre o apresentou como novo contribuidor em uma de suas notas de lançamento.

O problema é que duas contribuições incorporadas não combinam muito bem com a imagem de alguém que estaria carregando o projeto nas costas, corrigindo várias regressões ignoradas pelo upstream ou sustentando praticamente sozinho a integração com o Artix.

Talvez ninguém tenha afirmado isso de maneira tão explícita. Mas essa foi a impressão produzida pelas críticas reproduzidas no fórum: o Artix estaria corrigindo problemas enquanto o XLibre demorava para aceitá-los.

Os registros públicos não demonstram uma atividade desse tamanho.

Eles mostram uma colaboração real, mas pequena.

E uma colaboração pequena não é algo vergonhoso. Software livre é feito por pessoas com tempo limitado. Ninguém é obrigado a dedicar a vida a um projeto.

O que não funciona é assumir uma posição central, não manter uma contribuição compatível com ela e depois agir como se o problema fosse exclusivamente a incompetência dos outros.

Outro argumento apresentado por artist teria sido uma pesquisa pela palavra “regression” no repositório do XLibre.

No texto republicado, a busca retornava 24 ocorrências, das quais 16 ainda estariam abertas.

O problema não está simplesmente no número encontrado. O problema está em tratar todos os resultados como se representassem regressões abertas, confirmadas e relevantes para os usuários do Artix.

Uma issue encontrada nessa pesquisa pode ser:

* uma regressão confirmada;
* um relato ainda sem informações suficientes;
* um problema herdado do Xorg;
* uma incompatibilidade em um driver externo;
* um defeito presente apenas na versão de desenvolvimento;
* um problema que já foi corrigido;
* uma solicitação de funcionalidade que apenas menciona uma regressão em seu texto.

Portanto, encontrar a palavra “regression” em 24 issues não significa que existam 24 regressões abertas afetando os usuários.

Antes de utilizar esse número para avaliar a estabilidade do projeto, seria necessário examinar cada issue, verificar seu estado, identificar as versões afetadas e determinar se o problema realmente se aplica ao Artix.

Nesse ponto, a resposta do XLibre está correta: era necessário analisar e classificar os resultados, não apenas contar quantas vezes determinada palavra apareceu na pesquisa.

Isso não significa que as regressões restantes sejam irrelevantes. Um bug não desaparece porque existe uma solução alternativa. Da mesma forma, um problema encontrado em uma versão beta continua sendo importante, especialmente se puder chegar à versão estável.

Mas a crítica de artist parece ter utilizado um número chamativo sem apresentar o contexto necessário para interpretá-lo.

Ser crítico de artist não exige transformar o XLibre em santo.

A resposta de callmetango também apresenta problemas.

Um deles é comparar as regressões do XLibre com centenas de itens encontrados no rastreador do Xorg.

Projetos antigos, grandes e utilizados por milhões de pessoas naturalmente acumulam mais relatórios. O número bruto de issues não serve como medição direta da qualidade de um software.

Um projeto pode ter mais issues porque possui mais usuários, existe há mais tempo, recebe mais testes, mantém relatos antigos abertos ou utiliza critérios diferentes para classificar e encerrar problemas.

Pesquisar pela palavra “bug” no rastreador do Xorg e apresentar o número encontrado como prova de que o projeto é pior também seria uma simplificação inadequada.

Outro problema está no trecho sobre segurança.

A publicação afirma que determinada versão do XLibre corrigia sete vulnerabilidades, mas enumera oito identificadores de CVEs.

São oito números, não sete.

A diferença não destrói o argumento central, mas é um erro constrangedor em um texto cujo objetivo era justamente corrigir os números apresentados pelo outro lado.

Também considero desnecessária a tentativa de relacionar esse conflito à saída anterior de artist do projeto SonicDE.

Se o objetivo era demonstrar falhas em sua contribuição para o XLibre, os registros de issues, pull requests e releases já eram suficientes.

Trazer outro projeto para sugerir um padrão de comportamento transforma uma resposta técnica em julgamento pessoal.

A equipe do XLibre tinha argumentos fortes. Não precisava enfraquecê-los com insinuações.

Os excessos da resposta do XLibre não anulam o núcleo do argumento.

O que emerge dos registros apresentados é a situação de alguém que:

* teria ocupado uma posição no Core Team;
* seria responsável pelo contato com o Artix;
* dizia conhecer várias regressões;
* registrou apenas uma issue no período questionado;
* teve somente uma contribuição incorporada ao Xserver;
* e passou a recomendar o projeto concorrente depois de ser removido.

Isso não prova vingança.

Mas seria ingenuidade fingir que o momento das críticas não importa.

Um desenvolvedor pode ser removido injustamente e ainda estar correto em suas críticas. Também pode ser removido por não cumprir adequadamente sua função e, depois, utilizar problemas reais como munição em uma disputa pessoal.

As duas coisas não são mutuamente exclusivas.

Talvez algumas das críticas de artist ao XLibre sejam tecnicamente verdadeiras. O projeto possui regressões, como qualquer software em desenvolvimento ativo. Algumas correções podem ter demorado. A equipe também pode ter conduzido a ruptura de maneira ruim.

Mas a existência de problemas reais no XLibre não absolve artist da própria responsabilidade.

Esse é o ponto que frequentemente se perde em conflitos dentro do software livre: uma crítica pode conter fatos verdadeiros e, ainda assim, ser apresentada de forma oportunista por alguém tentando reescrever o próprio papel na história.

A parte mais grave da resposta do XLibre está relacionada às atualizações de segurança disponibilizadas aos usuários do Artix.

Callmetango afirma que o XLibre havia publicado uma versão com correções para diversas vulnerabilidades no começo de junho de 2026.

Segundo ele, o pacote correspondente só teria sido atualizado nos repositórios do Artix cerca de seis semanas depois, quando artist já havia sido criticado e removido da equipe do XLibre.

A acusação é especialmente pesada porque inverte o argumento apresentado inicialmente.

Enquanto artist acusava o XLibre de demora na incorporação de correções, os usuários do Artix teriam permanecido semanas utilizando um pacote sem atualizações de segurança que já estavam disponíveis no upstream.

Essa acusação precisa ser analisada com cuidado. É necessário verificar as datas das releases, dos commits e da disponibilização efetiva dos pacotes aos usuários.

Mas, se a cronologia apresentada pelo XLibre estiver correta, artist não estava apenas deixando de reportar bugs. Ele também teria falhado em uma das principais responsabilidades de um mantenedor de distribuição: entregar atualizações de segurança em tempo razoável.

Nesse caso, a crítica ao XLibre não seria apenas contraditória. Seria uma tentativa de transferir para o projeto uma responsabilidade que também pertencia a ele.

Apagar a publicação de callmetango foi, no mínimo, uma decisão ruim de comunicação.

Talvez o fórum tenha considerado o texto excessivamente pessoal. Talvez tenha entendido que a referência ao SonicDE violava alguma regra. Talvez a discussão estivesse saindo do controle.

Sem uma justificativa pública dos moderadores, não é possível afirmar que houve censura deliberada para proteger artist.

Mas a exclusão produziu exatamente essa aparência.

Ao apagar uma resposta que continha referências verificáveis a issues, pull requests, commits e releases, o Artix permitiu que o XLibre se apresentasse como o lado silenciado da disputa.

O resultado foi previsível: o texto saiu de um tópico limitado do fórum e ganhou divulgação no perfil oficial do projeto.

Em vez de encerrar a discussão, a moderação a ampliou.

O melhor caminho teria sido preservar a parte técnica, advertir ou remover apenas os ataques pessoais e permitir que artist respondesse aos dados apresentados.

Software livre deveria resolver esse tipo de conflito com mais documentação, não com menos.

Não há evidência suficiente para afirmar que artist forçou sua entrada no XLibre ou que tudo tenha sido planejado desde o começo.

Mas há elementos suficientes para uma conclusão mais limitada e, ao mesmo tempo, bastante incômoda:

É possível que ele tenha reclamações legítimas.

É possível que o XLibre tenha cometido erros.

É possível que sua remoção tenha sido conduzida de maneira hostil.

Nada disso muda o fato de que o histórico público de colaboração parece pequeno diante do papel que ele ocupava e da autoridade com que posteriormente criticou o projeto.

No software livre, cargo não é título honorífico. Não é apenas um crachá para colocar no perfil.

É responsabilidade contínua: testar, registrar, reproduzir, revisar, corrigir e comunicar.

Quando alguém deseja a posição, mas não consegue manter o trabalho exigido por ela, sua saída não é necessariamente perseguição.

Às vezes, é apenas o momento em que o projeto percebe que o crachá ficou maior do que a contribuição.