Porsche Plataforma de Código Abierto

Artículo original ↗ Discusión en Hacker News ↗

El nuevo portal de código abierto de Porsche se recibe como un pequeño paso por parte de un fabricante tradicional, pero muchos señalan que por ahora solo expone herramientas web y del sistema de diseño, no el software embebido que realmente ejecuta sus coches. Los comentaristas debaten si los fabricantes podrían o deberían abrir el código de las ECUs y de los sistemas críticos para la seguridad, citando por un lado toolchains propietarias complejas, responsabilidad legal y restricciones regulatorias, y por otro transparencia, seguridad y argumentos de derecho a reparar. Otros temas incluyen el escepticismo sobre el “OSS-washing”, las distintas posturas sobre Android frente a Automotive Grade Linux para el infoentretenimiento, y el papel de los CLA y la cultura corporativa en unas contribuciones de código abierto realmente significativas.

Alcance e impacto de la iniciativa de código abierto de Porsche

  • Los proyectos más visibles se centran en la web y el diseño (sistema de diseño, herramientas del sitio), no en código de control del vehículo.
  • Varios comentaristas lo ven como “gran titular, poco impacto” o “OSS-washing”, pero otros consideran que cualquier movimiento de un OEM tradicional es un primer paso positivo.
  • El propio sitio arroja errores del lado del cliente para algunos, y el CLA obligatorio recibe críticas.

ECUs, software embebido y viabilidad de la apertura

  • Muchos sostienen que el verdadero valor está en los sistemas embebidos (ECUs, controladores críticos para la seguridad), que siguen cerrados.
  • Las ECUs suelen construirse mediante toolchains propietarios basados en modelos, middleware en capas y código de numerosos proveedores y consultoras; a menudo los OEM ni siquiera tienen derechos completos sobre el código.
  • Trasladar esta pila a FOSS se describe como un cambio de paradigma de más de una década y de toda la industria, no algo que una sola marca pueda hacer unilateralmente.

Seguridad, protección y regulación

  • Una parte enfatiza la seguridad y la responsabilidad: las normas automotrices, la certificación de terceros y el análisis complejo de fallos hacen que la modificación abierta de sistemas críticos sea arriesgada para los transeúntes.
  • La otra parte sostiene que la apertura expondría errores y trampas (por ejemplo, escándalos de emisiones) y, en última instancia, aumentaría la seguridad, destacando los límites de la certificación y la debilidad de los reguladores.
  • La seguridad automotriz se describe ampliamente como deficiente, con una fuerte dependencia de la oscuridad; algunos argumentan que precisamente por eso el código crítico para la seguridad debería ser FOSS y parcheable por el usuario.

Control del propietario frente a riesgo público

  • Fuerte sentimiento a favor del derecho a reparar: si compras el coche, deberías poder inspeccionar y modificar su software, anulándose la garantía según corresponda.
  • Contraargumento: un coche hackeado circula por vías públicas, así que “tu” riesgo se impone a otros; la ley y los costes sociales justifican restricciones.
  • Algunos proponen una separación: código de seguridad abierto y legible, pero despliegue y flasheo estrictamente controlados.

Infoentretenimiento, Android y superficies de ataque

  • Preguntas sobre si Porsche usa Android o Automotive Grade Linux; se citan ejemplos de otros stacks Android de OEMs que son defectuosos o dependen de Google.
  • El infoentretenimiento suele estar lógicamente separado de los sistemas de seguridad, pero se ha usado como cabeza de puente de ataque; algunos citan problemas de robo en Hyundai/Kia.
  • Varios preguntan por qué al menos el software y los protocolos de la consola central no se abren, dado que en teoría no son críticos para la seguridad.

Aftermarket y ECUs abiertas

  • Se citan múltiples ECUs aftermarket abiertas o شبهabiertas (por ejemplo, Speeduino, RusEFI; Megasquirt se señala como no verdaderamente abierta).
  • El reequipamiento de motores antiguos se describe sobre todo como un problema de integración de hardware y sensores; una vez que las entradas y salidas son fiables, se trata de ajuste/configuración.

Incentivos corporativos, cultura y ecosistema

  • Muchos ven poco incentivo comercial para que los OEM abran código interno, dado el riesgo legal, los enredos de propiedad intelectual y la falta de una ventaja de ventas percibida.
  • Algunos argumentan que los estándares y el OSS podrían ayudar a commoditizar el software de los proveedores y reducir costes de licencias, pero los contratos arraigados son una barrera.
  • Se debate sobre las prácticas de contratación de empresas alemanas (requisito de idioma alemán) frente a polos más amigables con el inglés como los Países Bajos; se considera que esto afecta su capacidad para crear equipos de software sólidos.
  • La política y la estructura de propiedad del Grupo VW se describen como complejas, lo que hace improbable un impulso de OSS a nivel de grupo.

Sistema de diseño y herramientas web

  • La apertura del sistema de diseño de Porsche desconcierta a algunos, ya que copiar la apariencia de la marca sigue estando restringido.
  • Otros señalan razones prácticas: los contratistas externos y las integraciones del ecosistema necesitan acceso fácil; los registros públicos y las incidencias de GitHub son más sencillos que los registros privados y Slack interno.

Percepción de marca Porsche y soporte a largo plazo

  • Algunos dicen que esta iniciativa aumenta un poco su probabilidad de comprar un Porsche.
  • Se elogia a Porsche por el soporte a su legado: nuevo infoentretenimiento para modelos de 20 años y garantías de fabricante inusualmente largas y ampliables en coches usados.
  • En comparación con otras marcas que abandonan el software rápidamente, esto se ve como un fuerte diferenciador, aunque también se mencionan problemas de diseño del motor en algunos modelos.