Ambas as posições perdem o foco. Se você se preocupa com a agência do usuário, a segurança e a sustentabilidade de longo prazo, como todos os projetos de código aberto deveriam, você precisa de código aberto e de pipelines de construção abertos, para que qualquer pessoa possa inspecionar, reproduzir e fortalecer o que está em execução. São necessárias especificações abertas e governança, para que qualquer pessoa possa entender o que o sistema deve fazer, como deve se comportar e como as decisões são tomadas ao longo do tempo.
A nova “definição” de abertura deve considerar a implementação, a especificação e a governação como três factores críticos que devem ser interligados. Implementação aberta significa que o código-fonte, as dependências e o sistema de compilação estão disponíveis sob uma licença de código aberto para que você mesmo possa reconstruir, auditar e executar o software. Especificação aberta significa que os requisitos, a arquitetura e a constituição do projeto são documentados, versionados e públicos, para que outros possam reutilizá-los, aprender com eles e adaptá-los às suas próprias necessidades. Governança aberta significa que os processos pelos quais as mudanças são propostas, revisadas e aceitas – seja no nível das especificações ou no código – são transparentes e participativos.
O caminho a seguir para as comunidades de código aberto não é recuar do desenvolvimento orientado por especificações e assistido pela IA, nem declarar a antiga missão obsoleta. É liderar a definição e a prática de como são a especificação aberta, a governação e a implementação em conjunto num mundo que prioriza a IA — e fazê-lo com a confiança necessária para sonhar mais do que a automação incremental.
