Software local-first (2019)

• El software local-first es un enfoque que busca materializar al mismo tiempo las ventajas de la colaboración basada en la nube y la propiedad personal de los datos
• Las aplicaciones tradicionales en la nube destacan en colaboración en tiempo real y accesibilidad, pero generan problemas como la propiedad de los datos y el acceso a largo plazo
• El software local-first considera al almacenamiento local como la ubicación principal de los datos, y ofrece como complemento funciones de sincronización y colaboración
• Este tipo de software ofrece ventajas en velocidad, soporte offline, privacidad y control del usuario, aunque también presenta una alta dificultad de implementación en áreas como la colaboración en tiempo real o la sincronización entre múltiples dispositivos
• Para hacer realidad este software, se están comparando y analizando diversos modelos tecnológicos existentes, mientras se explora la posibilidad de desarrollar en el futuro modelos más ideales

---

Limitaciones de las apps en la nube y de la propiedad de los datos

• La mayoría de los usuarios utiliza diversas apps en la nube como Google Docs, Figma y Slack para redactar documentos, diseñar y colaborar con distintos fines
• Estos servicios se acceden desde el navegador o desde apps móviles, y en la mayoría de los casos almacenan los datos en servidores
• El software basado en la nube ofrece la ventaja de permitir colaboración y acceso a los datos desde cualquier lugar, pero cuanto más tiempo se invierte en una app, mayor se vuelve el valor de los datos dentro de ella
• A través de entrevistas con especialistas, se confirmó que detrás de las ventajas funcionales de las apps en la nube existen desventajas críticas como la pérdida de propiedad y la incertidumbre del acceso a largo plazo
• Existe tanto una inquietud psicológica como un riesgo práctico por las limitaciones al derecho de conservar y poseer los materiales y datos que los usuarios crean o producen directamente

Qué significa poseer realmente los datos

• Los datos almacenados en la nube parecen ser “propios”, pero en la práctica el control de administración y acceso lo tiene el proveedor del servicio en la nube
• Si el servicio se interrumpe o falla el servidor, puede producirse la imposibilidad de acceder a los datos y dificultades para su preservación a largo plazo
• El núcleo del problema no es la propiedad intelectual legal, sino la sensación de propiedad y capacidad de control que experimenta el usuario sobre sus datos
• Las aplicaciones antiguas centradas en almacenamiento local (editores de texto, control de versiones y diversas herramientas) garantizaban una propiedad plena de los datos y autonomía

Comparación de ventajas y desventajas entre la nube y lo local

• “Apps en la nube = colaboración y accesibilidad”, “apps locales = propiedad y autonomía”
• Se plantea la necesidad de buscar la mejor combinación mediante un enfoque híbrido, en lugar de una elección excluyente
• La propiedad de los datos y la colaboración en tiempo real no son necesariamente incompatibles, y es posible diseñar un modelo de software que logre ambas
• A esto se le define como software local-first, proponiendo como estructura básica la combinación de almacenamiento local, red y servidores auxiliares

Las 7 virtudes del software local-first

• En las apps en la nube, el servidor actúa como la “copia maestra” de los datos, por lo que cada solicitud requiere ida y vuelta al servidor, generando latencia en la experiencia de usuario
• En cambio, el software local-first trata la copia del almacenamiento local como la versión principal de los datos, dejando la sincronización (a través del servidor) como algo secundario
• Este cambio de perspectiva ofrece ventajas reales en velocidad de respuesta, soporte offline y control sobre los datos

1. Velocidad (respuesta rápida)

• Las apps local-first procesan todas las operaciones en el sistema de archivos local, por lo que pueden ofrecer respuesta inmediata sin esperar retrasos por solicitudes al servidor
• La sincronización se realiza silenciosamente en segundo plano, de modo que la experiencia del usuario no se interrumpe en ningún momento

2. Sincronización entre dispositivos

• Como los usuarios modernos trabajan desde varios dispositivos, las apps local-first también necesitan sincronización de datos entre dispositivos
• La sincronización a nivel de archivo es sencilla para una sola persona usuaria, pero cuando varias personas editan al mismo tiempo surgen problemas de conflicto

3. Prioridad offline

• El software local-first permite crear y editar datos en cualquier momento sin conexión, y sincronizarlos automáticamente cuando vuelve la red
• Es posible compartir y sincronizar datos entre dispositivos mediante Bluetooth, WiFi local y otros métodos
• Para un soporte offline real, se prefiere el formato de ejecutable instalable localmente

4. Colaboración y gestión de conflictos

• Los métodos tradicionales (archivos adjuntos por email, herramientas de control de versiones, etc.) presentan la incomodidad de los conflictos y la fusión manual cuando varias personas trabajan sobre el mismo archivo al mismo tiempo
• Las apps en la nube (como Google Docs) minimizan la dificultad y los roces de la colaboración mediante edición simultánea en tiempo real
• El software local-first también tiene potencial para implementar colaboración en tiempo real, propuestas de cambios y aprobaciones, y diversos flujos de trabajo colaborativos, aunque sigue siendo un área de desafío técnico

5. Preservación de los datos a largo plazo

• Si se usa una app local-first, se garantiza el acceso a los datos incluso si la empresa creadora del software desaparece
• Los formatos de archivo comunes (texto, PDF, JPEG, etc.) pueden mantener compatibilidad durante mucho tiempo, e incluso los formatos incompatibles podrían abrirse mediante máquinas virtuales o emuladores
• Sin una verdadera preservación de datos a largo plazo, el problema de una edad oscura digital —en la que la humanidad futura no pueda acceder ni interpretar los datos actuales— podría volverse realidad

6. Privacidad y seguridad

• La estructura centralizada en la nube es vulnerable a diversos incidentes de seguridad como hackeos o abuso por parte de empleados internos
• Los profesionales que manejan información personal o datos sensibles pueden asegurar seguridad e independencia de los datos mediante cifrado de extremo a extremo en una estructura local-first
• Grandes empresas como Google pueden aprovechar internamente los datos de distintas maneras, mientras que el software local-first devuelve el control al titular de los datos

7. Propiedad y control del usuario

• El acceso a los datos puede ser bloqueado o restringido arbitrariamente por el proveedor del servicio en la nube (por marcados automáticos erróneos, cambios de política, etc.)
• En un entorno local-first, el usuario decide directamente sobre todos los derechos de uso de sus datos: modificarlos, respaldarlos y conservarlos
• Esto no se trata solo de derechos de autor legales, sino de la autonomía real del usuario y su control sobre los datos

Comparación de distintos modelos de software

• Email adjunto + archivo local: sobresale en velocidad, modo offline, preservación a largo plazo y control, pero resulta incómodo en colaboración y sincronización entre dispositivos
• Web apps en la nube (Google Docs, Trello, etc.): sobresalen en colaboración en tiempo real y accesibilidad, pero son débiles en velocidad, modo offline, propiedad y privacidad
• Servicios de sincronización de archivos (como Dropbox): destacan en velocidad, modo offline, preservación a largo plazo y control, pero tienen limitaciones en colaboración y en entornos móviles
• Sistemas de control de versiones (como Git): sobresalen en velocidad, modo offline, preservación a largo plazo y control, pero son débiles con archivos no textuales y en colaboración en tiempo real
• Clientes móviles (Firebase, CloudKit, etc.): fuertes en sincronización y funcionamiento offline, pero con limitaciones en privacidad, datos personales y continuidad del servicio a largo plazo
• Replicación multi-master (BD, por ejemplo CouchDB): fuerte en offline y sincronización, pero difícil o insuficiente para alcanzar ideales como colaboración, privacidad y control

Perspectiva de los desarrolladores de software y dirección futura

• El software local-first ideal debe diseñar e implementar desde el inicio offline, sincronización entre múltiples dispositivos, colaboración en tiempo real, privacidad y control del usuario
• Sin embargo, en la práctica todavía no existe una tecnología abierta que satisfaga todos estos ideales al mismo tiempo
• Nuevas tecnologías concebidas en investigaciones recientes en ciencias de la computación (por ejemplo, Conflict-free Replicated Data Types (CRDTs) y métodos de sincronización de datos distribuidos) podrían convertirse en la base clave para materializar el software local-first del futuro

Conclusión

• El software local-first es una dirección importante para equilibrar en la era digital la colaboración, la independencia, la privacidad y la soberanía de los datos
• Puede ofrecer a especialistas, creadores y otros usuarios una sensación de propiedad sobre sus datos y protección a largo plazo, y además se proyecta como una fuente de cambios positivos en toda la industria
• En adelante, será necesario continuar investigando y experimentando con mejor infraestructura, herramientas de desarrollo, arquitectura y algoritmos que hagan realidad este ideal

[GN⁺]

Comentarios en Hacker News

• Me identifiqué muchísimo con esto. Yo también estoy desarrollando para resolver este tipo de problema y ya me cansé del modelo de meter mi información en la nube y solo pagar suscripción. Ahora estoy haciendo una app de fitness tracking y planeo aplicar el modelo de Sublime. Compras una vez al inicio, recibes actualizaciones por algunos años, sincronizas entre todos tus dispositivos y la usas de por vida. Si después quieres más actualizaciones, basta con volver a comprar una nueva versión. La meta es que, si la calidad es lo suficientemente buena, puedas seguir usándola así para siempre. Quisiera este modelo para el 90% del software. Debe poder comprarse a un precio justo, el producto en sí tiene que ser bueno, y es importante que funcione bien incluso sin integración con la nube. No solo por privacidad de datos; este modelo tiene muchas ventajas. Todavía quedan retos como el tooling, pero la base técnica ya existe. La mayor ventaja del software local-first es que tiene una estructura de incentivos sana. No te recompensa por anuncios, rastreo de usuarios o maximizar el “engagement”, sino por el producto mismo. De verdad se siente como software centrado en el usuario.

  • El modelo de la app de notas Obsidian también es un gran ejemplo. El cliente es gratis y el servicio de sincronización se vende como opcional. Además, como las notas son archivos Markdown, ni siquiera necesitas forzosamente el cliente.

  • Me da curiosidad cómo planeas manejar la sincronización sin usar infraestructura en la nube.

  • Totalmente de acuerdo. Si no te molesta, también me gustaría saber cuál es el tech stack de tu app de fitness tracking. En especial me interesa cómo piensas resolver la sincronización entre dispositivos.

  • También hay muchas apps puramente locales que se monetizan con anuncios, así que eso de “sin publicidad” no siempre aplica.

• Ahora mismo en Berlín se está realizando con mucha actividad la conferencia Local-first Software (https://www.localfirstconf.com/), organizada por Ink and Switch, y este noviembre incluso apareció Sync Conf (https://syncconf.dev/) en San Francisco. En conferencias recientes, los coautores del paper participaron directamente en paneles, lo que fue muy útil para entender lo aprendido desde el contexto de herramientas de desarrollo para software local-first. Recomiendo mucho este video del panel. En la comunidad, “Sync” se está consolidando como el elemento clave de local-first, y la idea es que herramientas para desarrolladores como los motores de sincronización son solo herramientas de soporte para implementar tecnologías con características local-first, no que sean local-first por sí mismas. También subieron aquí una recopilación completa de charlas de los últimos años. Se está avanzando con mucha fuerza en herramientas para colaboración en tiempo real y asíncrona, y con la llegada reciente de la IA el mercado está creando una necesidad cada vez mayor de este tipo de motores de sincronización. Las apps de IA son, en esencia, entornos de colaboración multiusuario, así que esta es una época en la que se necesita la base técnica que viene de la comunidad de motores de sincronización.

• Ya hubo discusiones muy activas sobre este tema antes, así que vale la pena leerlas si te interesa: 2019-05, 191 comentarios
  2019-11, 241 comentarios
  2020-07, 9 comentarios
  2020-08, 134 comentarios
  2021-02, 90 comentarios
  2022-06, 30 comentarios
  2023-10, 50 comentarios

• Sostengo que no hace falta que cada app tenga su propia plataforma de sync. Esta tendencia parece venir de lo difícil que es combinar y modularizar programas entre sí en el mundo de las apps móviles. Si de verdad quieres local-first, puedes usar el sistema de archivos. Desde la perspectiva del usuario, ya existen muchas soluciones entre las que puede elegir directamente, como git o box. Todo el proceso de registrarse al sync de cada app termina siendo tan opaco y frágil como el mismo SaaS, así que resulta una carga.

  • Estoy de acuerdo en que no todas las apps necesitan un motor de sync, pero no creo que el sistema de archivos sea una solución universal para local-first. Hay dos razones. La primera es la concurrencia. Si te quedas solo con local-first puro, cualquier sync sirve, pero yo quiero algo más. Por ejemplo, quiero la experiencia de que mi esposa y yo podamos editar por separado en nuestros teléfonos aunque no haya comunicación, y que luego todo se combine automáticamente de manera correcta. Quiero una sincronización realmente natural, como Dropbox. La segunda razón es que el motor de sincronización necesita entender a fondo la estructura y la semántica de los datos para ofrecer una mejor experiencia de sync. git o box tienen varias limitaciones frente a esa necesidad de edición simultánea con semántica.

  • De hecho, ya implementé un enfoque que usa únicamente el sistema de archivos, pero al final es difícil coordinar entre clientes cuándo permitir editar un archivo, así que los conflictos de archivos terminan siendo inevitables.

• Los sistemas que dependen de estar en línea inevitablemente conllevan costos de mantenimiento y operación. Si no están diseñados como local-first o local-only, no pueden ser sistemas confiables a largo plazo. Los electrodomésticos conectados y los autos de ese estilo son ejemplos de ingeniería realmente tonta desde una perspectiva práctica.

  • Todo esto al final se debe a los ingresos por suscripción. Las empresas con modelo de suscripción generan más ingresos y consiguen mejor financiamiento que las que no lo tienen, así que ganan en el mercado. Esa es justamente la razón por la que desapareció el software local-first.

• Yo más bien soy crítico de la idea de resolver técnicamente los problemas de confiabilidad de la nube evitando estructuras centralizadas. Antes, los problemas de software cerrado —falta de control y de confianza— se resolvían a través del modelo de negocio, con cosas como desarrollo open source o contratos de mantenimiento. Sostengo que para los problemas de la nube también hacen falta soluciones de modelo de negocio. Por ejemplo, podrían crearse contratos o licencias estándar que especifiquen claramente los derechos del usuario, y empujar al mercado a elegir solo vendors que adopten esas licencias certificadas. Se podrían agregar muchísimas cláusulas: garantía de portabilidad de datos del usuario, transparencia sobre cómo se usan los datos, procedimientos definidos para el cierre del servicio, etc. Claro, el mayor obstáculo es por qué los vendors aceptarían algo así. Como temen la fuga de clientes, podrían permitir esas licencias solo con suscripción anual o exigir un costo adicional.

  • Cuando un problema de negocio o político puede abordarse con una solución técnica, me parece que suele ser una forma más robusta, porque bloquea técnicamente los intereses adversos desde el inicio. El ejemplo clásico es el cifrado del lado del cliente (client-side encryption). Hay demasiada tentación, y además es difícil vigilar y detectar abusos, como para depender de políticas de privacidad o reglas burocráticas. Si los datos están cifrados de tal forma que el servidor matemáticamente no pueda leerlos, gran parte de la preocupación desaparece. Eso sí, si quieres que el servidor procese realmente los datos, entonces terminas en una situación donde básicamente tienes que usar tu propio servidor.

  • Por ejemplo, incluso si intentas resolverlo con contratos para cuando el servicio cierre, si el proveedor cloud quiebra y lo único que hace es avisar y permitir exportar tus datos, al final lo único que te queda es un JSON enorme. Si no haces tu propia app o alguien más la hace por ti, en la práctica no sirve de mucho. La intención es buena, pero sigue quedándose corto frente a una app local que te permite seguir usando a largo plazo los datos de una app que ya murió.

  • Incluso una cláusula que garantice la portabilidad de datos tiene límites: en la práctica, migrar grandes volúmenes de datos es difícil y lleva mucho tiempo. Si además hay que hacerlo de urgencia en una crisis, todo sale peor. Ni siquiera entre bases de datos open source de la misma versión es algo sencillo, porque cada servicio tiene demasiadas variables. Al final, la alternativa realista es guardar los datos desde el principio en tu propio entorno y poder “desenchufarte” cuando haga falta. Existe la posibilidad de combinar BYOC (bring your own cloud) con open source. En mi empresa también operamos un producto de datos BYOC, así que sé por experiencia que esta estructura sí es viable.

  • Aunque el contrato deje clara la responsabilidad en caso de cierre del servicio cloud, cuando realmente se toma la decisión de cerrar o quebrar, no queda muy claro cómo podría ejecutarse y supervisarse eso en la práctica.

  • No es solo un tema de negocio o de política; la seguridad de los datos en sí también es un problema. Una razón importante para evitar el modelo de suscripción o cloud es mi deseo de proteger mis datos. Los datos que se transmiten sin cifrado local realmente pueden terminar comprometidos en cualquier momento.

• Leer este texto me pareció refrescante. Creo que más apps deberían ser local-first. Si el usuario no quiere sincronización en la nube, esa opción debería estar garantizada sí o sí. Brisqi (https://brisqi.com), que estoy desarrollando, también se basa en esta filosofía offline-first. Una app local-first significa, en esencia, que funciona perfectamente offline de manera indefinida. La experiencia offline es la base, y el sync en la nube es una mejora adicional. Una app basada en caché temporal no puede considerarse offline-first. Los datos deben guardarse en una base de datos local; un verdadero enfoque offline-first implica que los datos se preservan sin depender de internet. La mayoría de las apps que se describen como “offline-first” en realidad son solo offline-tolerant, es decir, ofrecen soporte offline limitado. Construir una app offline-first es mucho más difícil que hacer una web app solo online. Es indispensable contar con un mecanismo de sincronización confiable que no pierda datos incluso cuando se pasa entre modo offline y online. En mi blog explico cómo lo implementé (https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).

• Estos principios también tienen mucho sentido aunque se apliquen al mercado de consumo. En Sentinel Devices (www.sentineldevices.com) actualmente estamos desarrollando una estructura para entornos industriales —como SCADA y automatización industrial— donde los datos no pueden salir al exterior bajo ninguna circunstancia, y donde la ejecución, el análisis y la toma de decisiones ocurren completamente en el equipo del propio cliente. Ni siquiera ofrecemos un servidor externo. Este enfoque centrado en principios on-device suele darles, tanto a clientes como a vendors, una especie de giro mental bastante fuerte. Muchas empresas de datos e IA ignoran este mercado porque les resulta demasiado difícil ofrecer sus servicios directamente en las instalaciones del cliente. Aun así, con frecuencia tenemos que enfatizar que operamos sin conectividad y con procesamiento totalmente local para que el cliente realmente entienda la propuesta. Si en el ámbito de consumo la gente se familiarizara más con local-first, el sector industrial también podría transformarse mucho más rápido.

  • Incluso la industria de SCADA últimamente está empujando todo hacia la nube. El slogan es algo como “administra tu fábrica desde tu smartphone”. Pero eso también incrementa el riesgo de que incluso un simple hacker aficionado termine con acceso a controlar una fábrica.

  • Este campo me parece muy interesante y apoyo lo que hacen. Solo tengo una duda: vi en la página de carreras que todas las vacantes son presenciales (onsite). ¿Eso es porque el desarrollo local-first realmente requiere trabajar presencialmente y offline, o se debe más bien a un tema de gestión?

• Los proyectos en los que trabajo (selfhostblocks, skarabox) también buscan que cualquiera pueda hacer self-hosting fácilmente sobre NixOS. Ofrecen de forma declarativa casi todo: https, SSO, LDAP, backups, snapshots de ZFS, etc. Puedes guardar la mayoría de tus datos con cosas como Vaultwarden y Nextcloud, e incluso incluye servicios como Home Assistant. Compite con YUNoHost, pero con objetivos mejores. SelfHostBlocks permite que cualquiera extienda y haga self-hosting libremente a partir de varios bloques de construcción de paquetes. Es más un enfoque tipo librería que framework. También funciona como alternativa a un NAS, y además es completamente open source. Puede que le parezca fácil a alguien con conocimientos técnicos, pero la meta es bajar la barrera de entrada para que incluso una persona común pueda instalarlo en hardware sin necesidad de nix ni CLI.

  • De verdad apoyo mucho este tipo de proyectos. Hay muchísimas alternativas FOSS increíbles, pero en la práctica solo los técnicos pueden instalarlas fácilmente (algo tipo “docker compose up”), así que para la gente común sigue habiendo una barrera. Muchas apps self-hosted tienen una estructura de web app + DB + servidor + frontend, pero en mi caso realmente las uso solo en un dispositivo. Me bastaría con un programa de escritorio totalmente local, pero para alguien que no es desarrollador incluso eso puede ser una barrera enorme. Hay un desajuste clarísimo entre el FOSS self-hosted de alta calidad y los usuarios reales. Hacen falta más proyectos que cierren esa brecha. Yo también voy a probar selfhostblocks; ojalá siga avanzando.

  • Me encanta que incluya hledger. Puede parecer un poco inusual para quienes recién entran al mundo de la contabilidad en texto plano, pero es un software excelente.

  • De verdad gracias por haberlo hecho tan limpio y bien armado.

• Al revisar el texto principal, siento que toca la mayoría de los puntos importantes, pero el motivo del primer párrafo se siente algo débil. Se lee como si dijera algo como: “El pay de manzana es rico y nutritivo, pero algún día podría incendiarse de repente y desaparecer, llevándose también el babero al que le tenías cariño”.