O que realmente entra primeiro no modelo de código aberto é a questão da cadeia de suprimentos.

Uma vez que tal tópico seja escrito como “selado”, a atenção será atraída para uma imagem excessivamente dramática. As mudanças mais comuns no projeto são menos dramáticas: a fonte pública de download torna-se instável, sites espelho começam a aparecer, uma determinada versão é retirada das prateleiras, o ritmo de atualizações contínuas é interrompido e a cadeia de raciocínio nas mãos da equipe de repente tem que se segurar.

A camada de hospedagem sofre a pressão primeiro

Quanto mais o modelo de código aberto é discutido, mais fácil é ver claramente uma coisa: o que pode ser diretamente afetado pelas políticas, controles de exportação e regras de plataforma muitas vezes não são os documentos ponderados que foram distribuídos, mas a hospedagem pública, a inferência on-line, a distribuição de versões e as entradas padrão.

Isso significa que, embora pareça “selado”, o caminho que está realmente cortado costuma ser o caminho mais fácil. O que costumava ser um processo simples de obter uma URL, configurar uma interface de hospedagem e chamá-la de repente mudou para encontrar uma imagem, adicionar uma assinatura, verificar o hash, verificar a licença e confirmar a versão de reversão. As ações podem parecer pequenas, mas quando interligadas, formam uma cadeia de abastecimento completa.

Depois que a versão é bifurcada, o nome não explica mais o problema.

A parte mais difícil do modelo de código aberto nunca é “se existe um”. Quando o peso se espalhar por múltiplas imagens, múltiplos armazéns organizacionais e múltiplas filiais de ajuste fino, diferentes comportamentos crescerão sob o mesmo nome.

Neste momento, já não basta discutir “se o modelo ainda existe”. A questão mais problemática é: qual é a linha principal, qual é apenas uma imagem espelhada, qual foi treinada duas vezes e qual ainda mantém o comportamento de raciocínio original. O nome ainda pode apontar para o mesmo projeto, mas os resultados começaram a divergir. Neste ponto, se a equipe ainda considerar “mesmo nome” como “a mesma coisa”, os resultados online irão divergir mais cedo ou mais tarde.

Esta é também a maior diferença entre modelos de código aberto e APIs de código fechado. A API de código fechado está desconectada e o desempenho é muito simples; o modelo de código aberto é bifurcado e, superficialmente, o serviço ainda está em execução, mas nos bastidores a versão, as dependências e os limites de comportamento foram alterados. O que é realmente perturbador muitas vezes não é o fracasso, mas “ainda parece funcionar”.

O que realmente precisa ser corrigido é a origem, o rollback e a recorrência offline.

Quando esse tipo de mudança chega ao projeto, a primeira coisa a compensar não são as emoções, mas três coisas: origem, reversão e recorrência offline.

A origem deve ser rastreável até armazéns específicos, envios específicos e documentos de peso específico. A reversão deve ser capaz de retornar à versão anterior do comportamento, não apenas a um nome. A reprodução offline deve ser capaz de executar a mesma rodada de experimentos novamente quando a rede estiver instável, o espelho for perdido ou o pacote upstream for excluído.

Muitas equipes costumam sentir que essas coisas estão longe delas. Somente um dia uma atualização upstream altera o estilo de saída, ou uma certa sincronização de imagem é lenta, é que eles descobrem que o problema não está na capacidade do modelo, mas na cadeia de dependência não sendo gerenciada como um cidadão de primeira classe. Quanto mais open source for o modelo, mais óbvio isso será. Porque o que o código aberto traz não é uma “entrada gratuita” sempre estável, mas uma cadeia de abastecimento cada vez mais longa.

A parte mais física geralmente não é o corpo da modelo.

Quando se trata de um ambiente de produção, o lugar mais provável para dar errado geralmente não é a ontologia de peso, mas a entrada padrão, as atualizações automáticas e as dependências implícitas.

Se uma equipe considerar um determinado portal on-line como a única fonte, ainda poderá ligar para ele hoje, mas poderá ter que encontrar temporariamente um substituto amanhã; se considerar uma estação espelho como a verdade padrão, o desvio de versão entrará silenciosamente no treinamento e na avaliação; se o ritmo de atualização for muito apertado, a estabilidade do comportamento de hoje não será clara e a nova versão de amanhã estará online.

Portanto, este tipo de problema parece-se com a política internacional, mas quando se trata de engenharia, parece mais com a governação da cadeia de abastecimento. Quem controla a entrada, quem é responsável pela assinatura, quem define o rollback, quem salva a versão antiga e quem pode reconstruir offline, esses são os limites que continuarão a afetar a entrega. Depois que o próprio modelo for tornado público, o espaço deixado para ações externas será menor; o espaço deixado para a equipe fazer suas próprias aulas ficará maior.

Se o modelo de código aberto será “selado” é uma questão um tanto restrita. Um julgamento mais realista é: quanto mais open source for, mais difícil será controlá-lo com uma única ação; mas quanto mais open source ele for, mais precisará gerenciar versões, fontes, reversões e recorrências offline. Se esta cadeia de abastecimento não for contida, qualquer flutuação externa será amplificada num acidente que se assemelha a um “acidente modelo”.