A Sua Pilha Tecnológica de Código Aberto Tem um Conselho de Administração. Ninguém Lhe Faz Due Diligence.
O Linux 6.15 eliminou um suporte que três décadas de compradores davam como garantido, e quem pagou a factura não estava na sala. As empresas fazem due diligence a todos os fornecedores comerciais e a nenhuma das fundações sobre as quais a sua infraestrutura realmente assenta.
Em maio de 2025, o kernel Linux 6.15 foi lançado sem suporte para os processadores 486 e os primeiros 586 da Intel, encerrando uma promessa de compatibilidade que se mantinha desde o início dos anos 1990 e que nunca tinha sido escrita em lado nenhum. A justificação apresentada foi prática: manter a camada de emulação de que esses chips precisavam consumia atenção de manutenção que o projeto considerou melhor aproveitada noutro lugar, e a própria lista de discussão do kernel debatia esta remoção abertamente desde 2022. Defensável, nos seus próprios termos. Agora pergunte quem foi consultado. As empresas que ainda têm esse silício a correr, em controladores industriais, instrumentos de laboratório e sistemas embutidos que sobrevivem aos próprios fornecedores, não tiveram período de aviso, nem calendário publicado, nem lugar à mesa. Fechar essa lacuna é precisamente para isso que serve a due diligence ao código aberto, e quase ninguém a faz.
A sua empresa não assinaria um contrato de cinco anos com um fornecedor sem verificar quem o detém, quem o financia e o que acontece quando os seus interesses mudam. E, no entanto, essa mesma empresa constrói uma década de infraestrutura sobre uma plataforma de código aberto sem colocar uma única pergunta sobre a organização que a governa. Quando existe alguma diligência, esta para no ficheiro da licença, e a licença regula apenas o que pode fazer com o código tal como ele está. O que o responsável pelo projeto pode fazer ao código a seguir fica inteiramente fora dela. Ninguém envia uma fatura por uma descontinuação. A linha no orçamento aparece na mesma.
As comunidades de código aberto devem-lhe compatibilidade retroativa?
Não. O roteiro, a política de descontinuação e o suporte de plataforma ficam, sem exceção, ao critério de quem gere o projeto. Com um fornecedor comercial teria períodos de aviso, níveis de serviço e vias de reparação; com quem gere um projeto a montante tem influência proporcional ao que financia e participa, e a maioria das empresas não faz nem uma coisa nem outra. Em termos de governação, é um cliente não pagante de um fornecedor que não lhe deve nada. Este equilíbrio funciona lindamente enquanto os incentivos calham estar alinhados, e o erro está em tratar esse alinhamento como uma propriedade do código aberto, e não como uma coincidência a vigiar. Nem o responsável pelo projeto é uma abstração neutra: os membros platina da Linux Foundation, segundo a própria lista de membros, são um desfile de fabricantes de chips, operadores de cloud e fabricantes de dispositivos, cada um com os seus próprios interesses comerciais, e os órgãos de governação do setor têm, de um modo geral, o mesmo aspeto.
Que aviso prévio dão, na prática, as descontinuações em código aberto?
O que a política do responsável disser, nem mais um dia. O registo comparativo compensa ser lido com atenção, porque o intervalo é enorme. No extremo generoso está o Python. A PEP 373, publicada em 2008, agendou o fim de vida do Python 2.7 para 2015 e, quando ficou claro que o ecossistema não estava pronto, o projeto adiou a data para 1 de janeiro de 2020. Mais de uma década de aviso público e escrito, revisto uma vez, a favor de quem dependia dele.
No extremo oposto está o CentOS. As empresas adotaram o CentOS 8 em 2019 com base num ciclo de vida publicado que espelhava o do Red Hat Enterprise Linux, com fim de vida previsto para 2029. Em dezembro de 2020, o projeto anunciou que o CentOS Linux 8 terminaria afinal no final de 2021, à medida que o trabalho se deslocava para o CentOS Stream. Um prazo que as empresas tinham orçamentado em quase uma década reduziu-se a cerca de doze meses de aviso, e todos os planos de migração construídos sobre ele venceram-se sete anos mais cedo.
O Node.js fica a meio caminho e ensina a lição mais subtil. O Node 16 tinha fim de vida publicado para abril de 2024 segundo o calendário de lançamentos do projeto, que depois antecipou essa data em sete meses, para 11 de setembro de 2023, porque a biblioteca OpenSSL 1.1.1 subjacente perdeu o suporte primeiro, e ninguém queria um runtime a correr sobre criptografia sem correções. O calendário era real e o responsável cumpriu o seu próprio processo. Ainda assim, quem dependia dele perdeu sete meses, porque o relógio de outro responsável, mais a montante, chegou ao fim primeiro.
Coloque estes registos ao lado do kernel e o padrão fica claro: o aviso prévio é política, não física. Vai de uma década a um ano, as datas publicadas movem-se em ambos os sentidos, e o seu aviso efetivo é a janela mais curta em toda a sua cadeia de dependências. A remoção do 486 não é um escândalo; é o ponto de dados no extremo mais apertado do intervalo. Não existia nenhum documento de ciclo de vida para o suporte de hardware do kernel, pelo que o único aviso disponível era uma discussão numa lista de correio que quase nenhuma equipa de aquisições do mundo estava a ler.
Quando a burocracia fabrica o problema
Está a surgir um risco distinto, e convém dizê-lo com clareza: não teve qualquer papel na decisão sobre o 486, que foi discutida em aberto durante anos, por razões técnicas. O risco é que a prova de «sobrecarga de manutenção» pode agora ser gerada por encomenda. Um trecho de código corre em produção durante anos sem uma única reclamação humana; uma ferramenta de análise automática produz uma falha teórica com aparência plausível; o relatório entra no sistema de acompanhamento; o código passa a ter questões em aberto, e removê-lo passa a parecer arrumação, e não descontinuação. O projeto curl está a viver a fase inicial disto. O responsável pela manutenção, Daniel Stenberg, já alertava para relatórios de segurança gerados com apoio de IA em janeiro de 2024, e, em julho de 2025, relatou que cerca de um quinto das submissões de segurança que o curl recebia era «lixo» gerado por IA, sem que uma única se tivesse revelado válida até então, consumindo horas de revisores qualificados a cada submissão. A eliminação por via burocrática é uma possibilidade real para qualquer projeto cuja triagem não consiga distinguir especulação gerada por máquina de uma falha real, sentida por um utilizador real.
Trate a expressão «por causa da IA» com particular suspeita em debates sobre o âmbito de um projeto, já que a mesma premissa é usada como capacidade num argumento (menos pessoas a gerir podem tratar de mais código) e como sobrecarga no argumento seguinte (o lixo gerado inunda o sistema de acompanhamento), e uma premissa que sustenta uma conclusão e o seu oposto não está a fazer trabalho analítico nenhum.
Como é, na prática, a due diligence ao código aberto?
Como a diligência a um fornecedor, mas dirigida uma camada abaixo, e o registo comparativo acima entrega-lhe as perguntas diretamente.
Política de ciclo de vida escrita. O responsável publica sequer uma? A década de aviso do Python existiu porque a PEP 373 existia. O kernel não tem documento equivalente para o suporte de hardware, o que já lhe dizia, de antemão, que o aviso seria o que a lista de correio decidisse que era.
Histórico e direção. Quando este responsável já adiou ou antecipou uma data, em que sentido o fez? O Python reviu a favor de quem dependia dele; o CentOS reviu contra, em quase uma década. A última revisão de um responsável é a melhor previsão disponível para a próxima.
Aviso transitivo. A sua janela de aviso é o mínimo em toda a cadeia, não o número no rótulo. O calendário do Node 16 foi cumprido até o da OpenSSL se esgotar. Mapeie que relógios a montante as suas plataformas herdam.
Governação e dinheiro. Quem financia o responsável, e esses financiadores beneficiam quando a sua empresa é forçada a renovar hardware ou a mudar de plataforma?
Exposição e saída. Saiba que funcionalidades, plataformas e gerações de hardware do seu parque tecnológico estão na zona plausível de «legado» a montante, e calcule o custo do fork, da fixação de versão ou da migração agora, com calma, e não no trimestre em que o corte de suporte acontece. Uma saída já orçamentada é a única que reforça a sua posição negocial.
Nada disto é exótico. É o mesmo mapeamento de incentivos que aplicamos nas revisões de estratégia tecnológica, apontado a uma contraparte que a maioria das organizações nunca pensou em examinar, e pertence ao mesmo plano de ciclo de vida que as plataformas sobre as quais a sua empresa assenta. Articula-se ainda com uma disciplina que já defendemos a propósito da preparação para a IA: as afirmações são testadas antes de alguém agir sobre elas, seja quem for a fazê-las, a montante ou na sua própria direção. As fundações sob a sua pilha tecnológica são fornecedores sem nenhuma das obrigações de um fornecedor. Reveja os seus responsáveis de projeto como reveria fornecedores. Eles podem mudar de ideias, e o custo cai em si.
Perguntas frequentes
Como posso perceber se um projeto de código aberto a montante pode vir a deixar de suportar algo de que dependo?
Vigie o responsável pelo projeto, não apenas o código. A ausência de uma política de ciclo de vida escrita, mudanças no financiamento e na composição do órgão de governação em direção a novas prioridades comerciais, discussões de descontinuação enquadradas como «redução de sobrecarga de manutenção», e pouca cobertura de manutenção nos trechos de código que utiliza são todos indicadores avançados. A remoção do 486 foi sinalizada em discussões do kernel quase três anos antes de acontecer. Trate os tópicos de governação de um projeto como trataria os resultados trimestrais de um fornecedor: aborrecidos, públicos e cheios de sinais.
Os relatórios de bugs gerados por IA são um risco real para software estável?
Sim, e a experiência do projeto curl mostra a forma que isso toma: uma grande fatia dos relatórios de segurança recebidos é agora gerada por máquina, e praticamente nenhum se revelou válido. O perigo está na triagem. Uma falha teórica, gerada por máquina, é uma prova mais fraca do que uma falha real, sentida por um utilizador em produção, e um projeto que trata as duas da mesma forma acaba por reclassificar código funcional como sobrecarga. Ao avaliar uma dependência, pergunte se o processo de triagem distingue especulação gerada por máquina de falhas reportadas por humanos.
O que deve cobrir uma revisão de governação de código aberto?
Quatro coisas: se o responsável publica uma política de ciclo de vida e como cumpriu ou reviu datas no passado (o intervalo vai da década de aviso do Python 2 ao colapso do CentOS 8, de 2029 para 2021); quem governa e financia o responsável e para onde caminha a sua receita; um mapa dos sistemas da sua empresa que dependem de funcionalidades passíveis de serem classificadas como legado, incluindo janelas de aviso herdadas de fornecedores ainda mais a montante; e uma via de saída já orçamentada (fork, fixação de versão ou migração). Repita-a todos os anos, porque os incentivos de quem gere projetos mudam mais depressa do que os ciclos de renovação.
Relacionado
- No Ubuntu 26.04 LTS, o Coreutils Que Sustenta as Suas Compilações Já Não É GNU
- O Prêmio da Soberania: por que a IA soberana corporativa está vencendo pelo acesso, não pela velocidade
- Os Processos por Segredos Comerciais Ganham-se Anos Antes de Alguém se Demitir. Pergunte à Faccenda Chicken.
- Security & Trust
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.