Uma bifurcação de comunidades de código aberto está surgindo no horizonte?

Uma bifurcação de comunidades de código aberto está surgindo no horizonte?

Recentemente, teve o CNCF: KubeCon + CloudNativeCon China Summit em Hong Kong, onde palestrantes e apresentações chinesas dominaram. Isso é esperado em Hong Kong, mas talvez o mais esclarecedor tenha sido o número de novos projetos de código aberto sendo desenvolvidos principalmente na China.

Nos últimos anos, a China tem se tornado cada vez mais um centro de gravidade no mundo do código aberto. As empresas chinesas também estão bem representadas em grandes fundações de código aberto, como OpenInfra e CNCF. Estamos olhando para uma potencial fenda futura no mundo do código aberto? Haverá um ecossistema do Oriente e do Ocidente que só se tocam ocasionalmente? Ou podemos superar nossas diferenças para o bem comum?

A ascensão da China no código aberto

A incursão da China no código aberto pode ser marcada pelo advento do Red Flag Linux em 1999, mas desde então, tem havido uma proliferação de novos projetos de código aberto da China. Desenvolvedores chineses dominam amplamente esses projetos, mas buscam ganhar validação e criar confiança, geralmente se juntando a fundações de código aberto.

De acordo com um artigo recente da TechTarget (APAC), "a China tem o segundo maior número de desenvolvedores no GitHub por país", de acordo com Stormy Peters, vice-presidente de comunidades do GitHub em sua palestra no evento. A China agora também responde por mais de 10% dos patrocínios de fundações.

O Ocidente adotará o software chinês?

Não acho que nada disso deva ser uma surpresa. Como a maioria dos países, a China quer ser dona do seu próprio destino, criando assim suas próprias distribuições Linux e um crescimento massivo em projetos de código aberto nacionais. Isso parece positivo para o mundo do código aberto.

Certamente, você não pode invejar o desejo de se tornar um dos principais agitadores e agitadores na terra do código aberto. O Ocidente domina o código aberto há muito tempo, e é natural que as empresas chinesas se sintam mais confortáveis ​​usando software escrito principalmente por desenvolvedores chineses.

Mas aqui está o problema: Dado o clima geopolítico atual, as empresas ocidentais estarão dispostas a adotar o mesmo software? É difícil ver uma grande instituição financeira dos EUA migrando do RHEL para, digamos, Open Euler ou OpenKylin. Já vemos um impulso razoável para marginalizar empresas de hardware como a Huawei no Ocidente.

Parece uma questão de tempo até que a pressão aumente para usar software de código aberto que desenvolvedores ocidentais desenvolvem principalmente. Simultaneamente, instituições chinesas provavelmente favorecerão projetos de código aberto nacionais em vez daqueles originários e dominados pelo Ocidente.

Desafios de segurança do software de código aberto

Alguns acham que o software de código aberto é geralmente mais seguro, mas será que é? O software de código aberto feito principalmente no Ocidente tem problemas de segurança bem documentados, devido em parte à sua forte dependência de mantenedores sobrecarregados e voluntários.

Proteger o software de código aberto requer tempo, energia e diligência. Infelizmente, muitos projetos têm recursos muito escassos e não têm a expertise necessária para procurar riscos de segurança diligentemente.

Mais importante, nenhum software de código aberto existe no vácuo. Em vez disso, há uma longa "cadeia de suprimentos" de dependências para qualquer pedaço de software de código aberto, daí o advento dos SBOMs (software bills of materials) para validar qual outro código está incluído quando você adota um pedaço de software. No entanto, isso não garante a segurança.

Recentemente, o que é mais provável que um ator patrocinado pelo estado tenha se infiltrado em um backdoor no OpenSSH ao atacar sua cadeia de suprimentos de software. O exploit, inserido em uma dependência em algumas distribuições Linux, foi lentamente introduzido e então deliberadamente pressionado para inclusão em diferentes distribuições.

A necessidade de um bem público comum de código aberto

É isso que nos prepara para um potencial Apocalipse de Código Aberto: uma divisão do código aberto em Leste versus Oeste. Cada lado da divisão confiará no outro lado? Ou estamos olhando para o tribalismo impulsionando uma mentalidade de bunker, resultando em um cisma significativo na terra do código aberto?

O código aberto funcionou porque é um bem público comum. Um cisma criaria dois mundos de código aberto, uma divisão onde nenhum confia no outro, semelhante ao que vemos com as guerras comerciais entre o Leste e o Oeste hoje. Essa divisão pode retardar a inovação e a adoção por ambos os lados das melhores soluções disponíveis.

Como uma comunidade, precisamos olhar além dos conflitos geopolíticos e avançar em direção a um bem público comum de software de código aberto confiável, incluindo sua cadeia de suprimentos. Uma estratégia de engajamento entre todas as partes interessadas é obrigatória. Criar interesses e grupos compartilhados em torno da proteção de cadeias de suprimentos de software para todos os envolvidos é essencial, mas não será suficiente depender apenas de fundações independentes de código aberto.

O papel das fundações de código aberto

As fundações só podem fazer muito para diminuir a divisão. As fundações de hoje não investem muito em segurança, análise de código ou em ajudar com o gerenciamento da cadeia de suprimentos de software. Elas agem mais como entidades organizacionais e de marketing, dependendo de seus constituintes para promulgar medidas técnicas. Precisamos de instituições independentes semelhantes às ideias por trás do CVE (pela corporação MITRE), cuja missão é ajudar a proteger o software de código aberto e as cadeias de suprimentos.

Como essas instituições poderiam ser? Primeiro, elas precisariam ter liderança de todas as geografias, uma espécie de Nações Unidas do Código Aberto que representasse a todos igualmente. Idealmente, não seria uma situação de "pagar para jogar", onde aqueles com maiores meios financeiros teriam mais voz. Essas instituições forneceriam as melhores práticas para proteger cadeias de suprimentos de código aberto, exigindo um modelo de governança de base de código específico para obter a certificação de segurança.

Eles trabalhariam com instituições públicas e privadas com recursos de auditoria e escaneamento de código que podem ser alavancados para qualquer projeto de código aberto. Eles podem fornecer uma maneira de autenticar e verificar as identidades dos contribuidores de código aberto, de modo que haja um método para fornecer responsabilidade para confirmações. Apenas fornecer as melhores práticas, ferramentas gratuitas e verificação de identidade do desenvolvedor contribuiria muito para gerar confiança nas cadeias de suprimentos de código aberto.

No momento, gerenciamos a segurança da base de código em uma base de projeto por projeto e, enquanto isso continuar, todos nós estaremos em risco. Devemos proteger nossas cadeias de suprimentos de software de código aberto como uma comunidade global para evitar um futuro Apocalipse de Código Aberto.

contenido relacionado

Regresar al blog

Deja un comentario

Ten en cuenta que los comentarios deben aprobarse antes de que se publiquen.