Resumo
Em 15 de setembro, a diretora Mary Hubbard anunciou a criação do Core Program Team do WordPress, decisão somada ao alerta de Estela Rueda sobre a equipe de documentação ficar fora da versão 6.9. Em 21 de setembro, a líder Milana Cap afastou a colaboradora Jenni McKinnon após críticas públicas, que reagiu alegando uma pausa legal do programa.
Quem administra um site em WordPress, seja um blog pessoal monetizado com AdSense, um e-commerce turbinado por afiliados da Amazon ou um portfólio de agência, costuma enxergar o CMS como um “porto seguro” de código aberto. Só que os bastidores nem sempre são tão pacíficos. Nos últimos dias, uma disputa interna veio a público e escancarou tensões sobre quem manda, quem documenta e quem recebe créditos dentro do projeto.
Mais do que fofoca de corredor, o episódio toca num ponto crítico: sem governança clara e documentação robusta, atualizações podem atrasar, plugins podem quebrar e até estratégias de conteúdo podem ser afetadas. A seguir, destrinchamos o que aconteceu, por que isso importa e quais repercussões podem atingir quem vive, técnica ou financeiramente, do ecossistema WordPress.
O estopim: anúncio de Mary Hubbard e a criação do “Core Program Team”
Em 15 de setembro, Mary Hubbard, diretora executiva da fundação que cuida do WordPress, divulgou a formação de um novo Core Program Team. A proposta oficial era simples: melhorar a coordenação entre as equipes que desenvolvem o núcleo do CMS, documentar processos e reduzir atritos.
Embora Hubbard tenha frisado que o grupo não definiria a direção de produto, cada time continuaria autônomo, a iniciativa soou, para parte da comunidade, como uma intervenção hierárquica disfarçada de “facilitação”. O receio era de que a mudança abonasse um modelo mais vertical de decisões, algo historicamente malvisto em projetos de código aberto.
A ferida antiga: documentação fora da versão 6.9
Cinco dias antes do anúncio de Hubbard, em 10 de setembro, a desenvolvedora Estela Rueda já havia alertado no blog oficial: a equipe de documentação ficaria de fora da release 6.9, restando apenas um “liaison” temporário. Ela argumentou que, sem documentação, o ciclo de lançamento perde qualidade, e novos colaboradores não veem valor em contribuir.
O debate ganhou tom mais ácido quando Jenni McKinnon, também do time de docs, classificou a decisão como “exclusão” e comparou a ausência de voz da equipe a práticas “cult-like”. Nas entrelinhas, McKinnon sugeriu que a suposta simplificação de processos estaria sendo conduzida diretamente por Mary Hubbard, numa guinada a favor do controle de cima para baixo.
Escalada pública: afastamento de colaboradora e repercussão na comunidade
Na manhã de 21 de setembro, Milana Cap, líder do time de documentação, publicou que Jenni McKinnon foi convidada a “dar um tempo”. O motivo: comentários fora da linha da equipe, pedidos de remoção de líderes e críticas públicas consideradas excessivas.
Imagem: Internet
Horas depois, McKinnon respondeu com um post (que acabou removido) declarando uma “pausa legal” em todo o programa recém-anunciado. Ela alegou estar amparada por protocolos de “Strategic Social Resilience Operations” (SSRO) e disse que Hubbard “não possui autoridade válida” no assunto. A mensagem, recheada de termos jurídicos, causou estranhamento geral em grupos de Slack e Facebook, onde contribuintes buscavam entender se havia, de fato, um processo legal em andamento.
Sintomas além do episódio: dívida técnica e burnout
Para veteranos do projeto, o conflito revelou apenas a ponta do iceberg. Conversas paralelas em fóruns citam o aumento da dívida técnica do WordPress, isto é, partes do código que precisam de refatoração, e a dificuldade de manter voluntários engajados sem sobrecarga. A própria Estela Rueda mencionou “ondas de contribuintes” que somem após lançamentos, deixando um núcleo pequeno de pessoas exaustas.
Governança aberta ou caos controlado? O que isso significa para quem vive de WordPress
Na prática, o WordPress continua funcionando, e sites não vão cair por causa desse embate. Mas há sinais de alerta que profissionais de marketing, desenvolvedores e criadores de conteúdo não podem ignorar:
- Atualizações podem ficar menos previsíveis: se a documentação entra tarde ou é relegada, plugins e temas podem levar mais tempo para se adequar a mudanças do core, criando janelas de incompatibilidade.
- Prioridades de recurso podem mudar: um time de coordenação mais centralizado tende a decidir o que é “urgente” ou “secundário”. Isso pode acelerar features populares, mas também deixar bugs antigos e otimizações de performance (essenciais para SEO) em segundo plano.
- Barreira de entrada para novos colaboradores: sem clareza de papéis, a comunidade perde capital humano. Menos mãos no código significa ritmo mais lento de evolução, algo que afeta indiretamente quem depende de novidades para manter diferenciais competitivos.
- Risco de fragmentação: conflitos de governança prolongados incentivam forks ou derivadas do projeto, o que já aconteceu em outras plataformas de código aberto. Embora improvável no curto prazo, a mera possibilidade gera incerteza de longo prazo para negócios baseados no CMS.
Do ponto de vista de quem administra sites, o melhor antídoto é acompanhar de perto notas de versão, testar atualizações em ambiente de staging e diversificar dependências (por exemplo, limitar o número de plugins críticos). Já do lado da comunidade, o episódio reforça a necessidade de processos transparentes que valorizem não só quem escreve código, mas também quem documenta, testa e presta suporte, pilares invisíveis que sustentam 43% da web.
A crise pode servir de catalisador para ajustes na governança e na gestão de voluntários. Se isso acontecer, usuários finais colherão um WordPress mais estável e bem documentado. Caso contrário, veremos mais ruídos públicos que, aos poucos, corroem a confiança de quem faz do CMS não apenas uma ferramenta, mas um modelo de negócio.