Plataforma de Código Aberto da Porsche
O novo portal de código aberto da Porsche é acolhido como um pequeno passo por um fabricante tradicional, mas muitos observam que, por enquanto, ele expõe apenas ferramentas web e de sistema de design, e não o software embarcado que realmente faz os carros funcionarem. Os comentadores debatem se as montadoras poderiam ou deveriam abrir o código de ECUs e de sistemas críticos de segurança, citando de um lado toolchains proprietárias complexas, responsabilidade legal e restrições regulatórias, e do outro argumentos de transparência, segurança e direito ao reparo. Temas mais amplos incluem ceticismo em relação ao “OSS-washing”, atitudes diferentes sobre Android vs Automotive Grade Linux para infotainment, e o papel de CLAs e da cultura corporativa na formação de contribuições significativas de código aberto.
Âmbito e impacto da iniciativa de código aberto da Porsche
- Os projetos mais visíveis são focados em web e design (sistema de design, ferramentas do site), não em código de controle do veículo.
- Vários comentadores veem isso como “grande manchete, pequeno impacto” ou “OSS-washing”, mas outros consideram qualquer movimento de um OEM tradicional um primeiro passo positivo.
- O próprio site apresenta erros do lado do cliente para alguns, e o CLA exigido recebe críticas.
ECUs, software embarcado e viabilidade da abertura
- Muitos argumentam que o valor real está nos sistemas embarcados (ECUs, controladores de segurança crítica), que continuam fechados.
- As ECUs são normalmente construídas com toolchains proprietárias baseadas em modelos, middleware em camadas e código de numerosos fornecedores e consultorias; os OEMs muitas vezes nem sequer têm direitos completos sobre o código.
- Mudar essa pilha para FOSS é descrito como uma mudança de paradigma de mais de uma década, em toda a indústria, e não algo que uma única marca possa fazer unilateralmente.
Segurança, proteção e regulação
- Um lado enfatiza segurança/responsabilidade: normas automotivas, certificação de terceiros e análise complexa de falhas tornam arriscada a modificação aberta de sistemas críticos para quem está à volta.
- O outro lado argumenta que a abertura exporia bugs e batota (por exemplo, escândalos de emissões) e acabaria por aumentar a segurança, destacando os limites da certificação e a fraqueza dos reguladores.
- A segurança automotiva é amplamente descrita como fraca, com forte dependência do obscurantismo; alguns argumentam que სწორედ por isso o código crítico de segurança deveria ser FOSS e passível de patches pelo utilizador.
Controle do proprietário vs risco público
- Forte sentimento de direito ao reparo: se você compra o carro, deveria poder inspecionar e modificar o software, com a garantia anulada conforme necessário.
- Contra-argumento: um carro hackeado circula em vias públicas, então o risco “seu” é imposto aos outros; a lei e os custos sociais justificam restrições.
- Alguns propõem uma separação: código de segurança aberto/legível, mas implantação e flashing rigidamente controlados.
Infotainment, Android e superfícies de ataque
- Há dúvidas sobre a Porsche usar Android vs Automotive Grade Linux; são citados exemplos de stacks Android de outros OEMs com bugs ou dependência da Google.
- O infotainment costuma estar logicamente separado dos sistemas de segurança, mas já foi usado como cabeça de ponte para ataques; alguns citam problemas de roubo da Hyundai/Kia.
- Vários perguntam por que, pelo menos, o software e os protocolos da consola central não são abertos, dado que nominalmente não são de segurança crítica.
Aftermarket e ECUs abertas
- São citadas várias ECUs aftermarket abertas ou semiabertas (por exemplo, Speeduino, RusEFI; Megasquirt é mencionado como não sendo verdadeiramente aberto).
- A adaptação de motores antigos é descrita sobretudo como um problema de integração de hardware/sensores; uma vez que as entradas/saídas sejam fiáveis, trata-se de afinação/configuração.
Incentivos corporativos, cultura e ecossistema
- Muitos veem pouco incentivo comercial para os OEMs abrirem o código interno, dada a responsabilidade legal, os emaranhados de IP e a falta de vantagem percebida em vendas.
- Alguns argumentam que normas e OSS poderiam ajudar a comoditizar o software de fornecedores e reduzir custos de licenciamento, mas contratos enraizados são um obstáculo.
- Discussão sobre as práticas de contratação de empresas alemãs (exigência da língua alemã) vs centros mais amigáveis ao inglês, como os Países Baixos; isso é visto como afetando a capacidade de construir equipas fortes de software.
- A política e a estrutura de propriedade do Grupo VW são descritas como complexas, tornando improvável um impulso de OSS em todo o grupo.
Sistema de design e ferramentas web
- A abertura do sistema de design da Porsche confunde alguns, já que copiar a aparência da marca de qualquer forma é restrito.
- Outros apontam razões práticas: contratados externos e integrações do ecossistema precisam de acesso fácil; registos públicos e issues no GitHub são mais simples do que registos privados e Slack interno.
Percepção da marca Porsche e suporte legado
- Alguns dizem que esta iniciativa aumenta um pouco a probabilidade de comprarem um Porsche.
- A Porsche é elogiada pelo suporte ao legado: novo infotainment para modelos de 20 anos e garantias do fabricante invulgarmente longas e extensíveis em carros usados.
- Em comparação com outras marcas que abandonam rapidamente o software, isto é visto como um forte diferencial, embora também sejam mencionados problemas de design do motor em alguns modelos.