Cuando un hardware se descataloga, las empresas deberían liberar su software como código abierto

• Cuando un producto de hardware llega a su fin de vida (EOL), se plantea que la empresa debería estar obligada a liberar ese software como código abierto
• El movimiento Right to Repair ha avanzado, pero se propone que, a nivel de la Unión Europea, se obligue legalmente a publicar el software al llegar al EOL
• Se mencionan como ejemplos el caso de una báscula inteligente que perdió funciones al dejar de recibir soporte de la app, y el Car Thing de Spotify, que tras su descontinuación terminó convertido en residuo electrónico
• Las empresas no tendrían que publicar toda la base de código; bastaría con liberar las especificaciones del hardware y los protocolos de conexión para que la comunidad pueda desarrollar sus propias apps
• Por sostenibilidad y derechos de los usuarios, un enfoque open source que permita revivir hardware descontinuado es esencial

---

La necesidad del open source cuando un hardware se descontinúa

• Cuando un producto de hardware llega a estado EOL (End of Life), la empresa debería liberar su software como código abierto

  • Se señala el problema de que productos descontinuados que todavía podrían funcionar terminan inutilizados por el fin del soporte de software
  • Para evitar esta situación, se sostiene que hace falta fuerza legal obligatoria

• Aunque el movimiento Right to Repair ya ha fortalecido los derechos de los consumidores, se propone ir más allá y que la Unión Europea (UE) haga obligatoria la liberación del software al llegar al EOL

  • La postura es que la Comisión Europea (European Commission) debería regular que las empresas publiquen el software cuando un producto sea descontinuado

Experiencia personal y casos problemáticos

• En el caso de una báscula inteligente, el hardware funciona con normalidad, pero la app dejó de operar y se perdió la función de guardar datos

  • La conexión por Bluetooth sigue siendo posible, pero como la app ya no se desarrolla, el producto quedó prácticamente inservible
  • Se plantea la frustración y el desperdicio de ver cómo un hardware perfectamente funcional queda “muerto” por el fin del soporte empresarial

• También se menciona el caso de la descontinuación del Car Thing de Spotify

  • Con el cierre del servicio a fines de 2024, un hardware de 200 dólares pasó de un día para otro a ser residuo electrónico
  • El caso de Bose, que antes del EOL liberó como open source sus bocinas SoundTouch, se valora positivamente, aunque se señala que sigue siendo una excepción poco común

Una alternativa realista

• Las empresas no necesitan publicar toda la base de código

  • En cambio, bastaría con publicar en un repositorio de GitHub las especificaciones del hardware y los protocolos de conexión
  • A partir de eso, la comunidad podría desarrollar sus propias apps

• Con nuevos enfoques de desarrollo como vibe-coding, incluso personas no expertas pueden participar fácilmente

  • Estamos entrando en una era en la que los usuarios comunes también pueden manipular y mejorar directamente su hardware

Sostenibilidad y derechos de los usuarios

• Un enfoque open source que permita revivir hardware descontinuado es una necesidad ambiental y ética
  • Puede reducir la generación innecesaria de residuos electrónicos y ayudar a mantener un ecosistema tecnológico sostenible
  • Si un hardware ya quedó “brickeado”, lo mejor es publicar el software para darle a la comunidad la oportunidad de reutilizarlo

[GN⁺]

Comentarios de Hacker News

• La forma más segura de lograr que un proyecto EOL (End-of-Life) termine volviéndose open source es empezar como open source desde el principio
  Las promesas de “lo abriremos cuando cumplamos el objetivo” o de publicarlo si la empresa quiebra no significan nada
  Hay que empezar como open source para que inversionistas y comunidad puedan confiar
  Hay que gastar dinero en empresas que hacen productos y hardware open source, y apoyar a artistas que distribuyen libremente su trabajo
  Criticar a las empresas por no liberar algo después del EOL al final no pasa de ser un gesto para aparentar

  • Al mismo tiempo, también hay que considerar que el hardware de consumo no es simplemente un mercado de hobby
  • Si los consumidores se organizan y votan con la cartera, pueden cambiar el mercado
    Incluso las grandes empresas tienen dificultades para resistir demandas de consumidores unidos
    Así como la FSF logró generalizar el software libre, hace falta educación al consumidor y un cambio cultural
    Hay que crear una cultura de comunidades de consumidores donde las opiniones expertas se compartan rápido
    Más que el cinismo, importa el esfuerzo por generar cambios reales
  • Pero en la práctica el mercado está estructurado para recompensar el código cerrado
    Solo con presión del consumidor es difícil; hace falta regulación

• La mayoría de los sistemas dependen de una cadena de firma de código para operar en modo fail closed
  Pero cuando desaparece la entidad original que firma, hace falta una estructura fail open que permita delegar la autoridad de firma a una nueva entidad

• La propuesta de simplemente publicar las especificaciones de hardware y los protocolos tiene poca viabilidad en la realidad
  La mayoría de los dispositivos no son solo un protocolo de conexión simple, y las especificaciones pueden averiguarse analizando la PCB

  • El punto clave es proporcionar la información mínima necesaria para reutilizarlo
    Con publicar cómo flashear el firmware y un firmware mínimo ya podría bastar
    Aun así, como cada producto es distinto, hace falta un enfoque caso por caso

• En dispositivos como routers, donde el secure boot está grabado en e-fuse, no se resuelve solo con liberar el código como open source
  En esos casos, el fabricante debería mantener la clave de firma en escrow, para que incluso después del EOL pueda ejecutarse software nuevo

  • Pero publicar la clave de firma podría ser un desastre de seguridad
    Un atacante que secuestre un dominio expirado incluso podría crear una botnet
    En su lugar, haría falta un procedimiento como una acción física con botón mediante la cual el usuario apruebe explícitamente la instalación de firmware de terceros
  • Esto muestra que el enfoque de “solo publiquen el protocolo” no basta para todos los dispositivos
  • También hay quienes opinan que habría que prohibir el bloqueo del bootloader
    El usuario debería tener el derecho de modificar su propio dispositivo sin permiso del fabricante
  • O también se podría permitir el registro de claves mediante un botón físico

• A mí también me frustra tener que tirar hardware que todavía sirve solo por culpa del EOL
  Pero un enfoque del tipo “hagamos ilegal producir residuos electrónicos” no parece realista

  • Aunque no sea una solución completa, se podría mejorar mucho con una ley simple como una obligación de reembolso cuando se pierda la funcionalidad
    Ej.: si el producto ya no puede cumplir su función principal, reembolso total, salvo que el fabricante publique el software necesario en el dominio público
    Una ley así podría poner límites a grandes empresas como Google, que inutilizan productos al apagar sus servidores
  • Pero con esa lógica, ¿también habría que publicar Windows EOL?
    Si Windows 10 se hiciera open source, la estrategia de largo plazo de Microsoft se vendría abajo

• Esta idea es interesante incluso más allá del “open source” en sí
  Por ejemplo, si UBNT publicara su bootchain EOL para que Cambium pudiera usar ese firmware,
  el resultado podría no ser soporte comunitario, sino una competencia eterna de actualizaciones de producto

  • En la práctica, el open source completo es difícil, y el fabricante no tiene derecho a divulgar IP de terceros
    Como mínimo, no debería impedir que el usuario ejecute software alternativo que quiera usar
  • Pero ni siquiera eso basta
    La mayoría de los usuarios, si desaparece el servidor, no va a reinstalar firmware: simplemente tirará el dispositivo
    Por eso hace falta un diseño sin dependencia de servidores externos
    Ej.: una bocina inteligente debería soportar streaming por red local, y una bombilla debería permitir emparejamiento con protocolos estándar
    Por suerte, estándares como Matter over Thread están avanzando en esa dirección

• El Google Nest Thermostat de 1.ª y 2.ª generación es un caso representativo
  El proyecto No Longer Evil revivió este dispositivo con firmware open source
  Eliminó la dependencia de la nube de Google y permite que el usuario aloje su propio servidor o lo controle de forma independiente
  Gracias a eso, hardware costoso volvió a tener vida

• Siento que ahora estamos en una especie de edad oscura
  Antes, una caldera simplemente funcionaba si ponías un pin a tierra, pero los modelos posteriores pasaron a protocolos cerrados, lo que hizo mucho más difícil acceder a ellos
  Sin embargo, los modelos más nuevos volvieron a soportar el estándar OpenTherm, así que hackearlos se hizo más fácil otra vez
  Hoy hay mucho hardware abierto basado en ESP32 o Raspberry Pi, así que uno mismo puede hacer una GUI con ESPHome + LVGL e integrarla en la automatización del hogar
  El resultado tenía tanta calidad que mis amigos pensaban que era un producto de marca

• Creo que “eso no va a pasar”
  Por suerte, gracias a AI y Android, la ingeniería inversa de protocolos se ha vuelto más fácil
  Solo analizando APKs se puede obtener mucha información, así que estoy creando por mi cuenta una app y un servidor para el Limitless Pendant que compré antes de la adquisición por Meta
  No escribí ni una sola línea de código yo mismo

• Nadie espera soporte de por vida
  Pero cuesta aceptar que maten incluso la funcionalidad básica solo porque desaparecieron el backend de la app o la hoja de ruta
  Si el dispositivo sigue bien en lo eléctrico y mecánico, al menos debería garantizarse un uso mínimo