La honestidad del marco: puntuar en lugar de certificar
Ningún producto real cumple los siete ideales, así que el marco solo es útil como rúbrica de evaluación con pruebas falsables y como mapa de compromisos declarados, nunca como sello de pertenencia.
Si has leído las cuatro lecciones anteriores con atención, ya sabes el final: los siete ideales no se cumplen a la vez. Algunos chocan entre sí, otros chocan con el modelo de negocio y uno depende de investigación abierta. Esa es la parte honesta del marco, y es también la que lo hace útil. Un marco que nadie cumple del todo obliga a declarar dónde cedes, y declarar dónde cedes es la única forma de diseñar con criterio.
- Aceptar la incompletitud como diseño deliberado del marco y no como defecto.
- Aplicar una rúbrica de siete ejes con pruebas observables y falsables.
- Ponderar los ejes según el dominio en lugar de exigirlos uniformemente.
- Separar los compromisos aceptables de los que vacían el término.
Nadie cumple los siete
El propio artículo de 2019 evaluó las categorías de software disponibles en su momento —desde ficheros en carpetas sincronizadas hasta editores colaborativos en la web, pasando por el control de versiones distribuido— y no encontró ninguna que satisficiera las siete propiedades. Ese resultado no invalidó el marco: lo definió. Por eso son ideales.
Vale la pena entender por qué la incompletitud es estructural y no coyuntural. Ya has visto tres causas independientes.
La primera es una tensión interna: los ideales 4 y 5 tiran del formato en direcciones opuestas, porque colaborar exige acumular causalidad y archivar exige olvidar el proceso.
La segunda es una tensión externa: los ideales 6 y 7 eliminan funciones y palancas comerciales, de modo que cumplirlos es una decisión de negocio antes que de ingeniería.
La tercera es una frontera abierta: el control de acceso descentralizado con revocación sigue siendo objeto de investigación activa, y ningún equipo de producto va a resolverlo de paso.
Un marco que ignorase estas tres realidades produciría una lista de verificación con cero elementos aprobados, es decir, ruido. Uno que las asume produce una rúbrica, que es una herramienta de decisión.
Conviene subrayar que la incompletitud tampoco es una excusa universal. Que nadie cumpla los siete no implica que todos los incumplimientos sean equivalentes. Hay ejes donde ceder cuesta caro y tiene contrapartida clara, y ejes donde ceder no compra nada salvo comodidad para el proveedor. La rúbrica existe justamente para distinguir esos dos casos, que el lenguaje de marketing tiende a mezclar bajo la misma frase de que ningún sistema es perfecto.
Precisamente porque no hay umbral, la etiqueta se aplica hoy a productos que solo cumplen una versión débil del ideal 1 mediante una caché de lectura. El remedio no es inventar un umbral arbitrario ni una certificación, sino exigir que quien use el término publique su posición en los siete ejes con la evidencia correspondiente. La honestidad se demuestra declarando lo que no se cumple, no afirmando lo que sí.
Cómo se puntúa una aplicación
La rúbrica útil convierte cada ideal en un experimento reproducible con resultado observable. Ninguna de estas pruebas requiere acceso al código fuente.
Ideal 1, sin esperas. Desactiva la red, abre un documento grande y representativo, y mide el percentil 99 de la latencia de las interacciones frecuentes: escribir, desplazar, deshacer, buscar. Criterio: por debajo del umbral de manipulación directa, y sin degradación al crecer el documento.
Ideal 2, multidispositivo. El mismo documento en dos dispositivos, uno de ellos sin conexión. Edita en ambos, reconecta y comprueba si convergen sin intervención y sin pérdida. Criterio: convergencia automática y ausencia de ficheros de conflicto.
Ideal 3, red opcional. La prueba del avión frío: modo avión, cierre completo del proceso, reinicio del dispositivo, apertura. Criterio: acceso completo de lectura y escritura sin ninguna pantalla intermedia.
Ideal 4, colaboración. Dos personas editan concurrentemente la misma región mientras al menos una está desconectada. Criterio: ninguna edición desaparece en silencio y el resultado es explicable.
Ideal 5, longevidad. Localiza los datos en disco e intenta interpretarlos con una herramienta ajena al producto. Busca la especificación del formato. Criterio: formato documentado y contenido extraíble sin el proveedor.
Ideal 6, privacidad. Determina qué actor posee claves de descifrado. Criterio: solo los dispositivos autorizados, y por defecto, sin activación manual.
Ideal 7, propiedad. Caduca o desconecta la cuenta y vuelve a abrir. Criterio: el trabajo local sigue siendo editable.
flowchart LR A[Elegir el dominio] --> B[Ponderar los siete ejes] B --> C[Ejecutar las pruebas observables] C --> D[Puntuar con evidencia] D --> E[Declarar los compromisos] E --> F[Revisar en cada version] style D fill:#a6e3a1,color:#11111b style E fill:#89b4fa,color:#11111b
Sobre la escala: una puntuación de tres niveles —cumple, cumple parcialmente, no cumple— acompañada de la evidencia concreta es más honesta y más accionable que una nota numérica fina, que da falsa precisión a juicios cualitativos. Lo que hace útil la rúbrica no es el número, es la traza de evidencia que obliga a producir.
Dos advertencias metodológicas evitan los errores más comunes al aplicarla.
La primera: no aceptes afirmaciones arquitectónicas como evidencia. Que la documentación diga que el sistema usa estructuras replicadas sin conflicto no acredita el eje 4, del mismo modo que decir que el almacenamiento es local no acredita el eje 7. La evidencia válida es el resultado de la prueba, no la descripción del mecanismo. Un sistema puede usar el mecanismo correcto y seguir exigiendo cuenta para arrancar.
La segunda: prueba con datos realistas. Casi todos los productos aprueban el eje 1 con un documento de tres párrafos, y bastantes lo suspenden con uno de trescientas páginas y años de historial. La degradación con el tamaño es precisamente lo que distingue una réplica bien diseñada de una demostración.
La rúbrica se calibra evaluando tres o cuatro productos que ya conoces bien, incluyendo alguno que no pretenda ser local-first. Descubrirás dos cosas incómodas: que herramientas que jamás usan la etiqueta puntúan alto en varios ejes, y que herramientas que la usan en su portada suspenden los ejes 6 y 7. Esa calibración es lo que impide que la rúbrica se convierta en un espejo complaciente.
Ponderar en lugar de exigir
Los siete ejes no valen lo mismo en todos los dominios, y tratarlos como equivalentes es un error de método.
En una herramienta de escritura personal, el eje 4 puede pesar casi nada y los ejes 5 y 7 casi todo: nadie colabora en tu diario, pero quieres poder leerlo dentro de treinta años. En una herramienta de campo para trabajo en zonas sin cobertura, los ejes 1 y 3 son innegociables y el 6 puede resolverse por otras vías si el dispositivo ya está bajo control físico de la organización. En una herramienta clínica o legal, el eje 6 domina sobre todos los demás y puede justificar sacrificar parte del 4.
La consecuencia metodológica es que la evaluación empieza por declarar el dominio y asignar pesos antes de puntuar. Puntuar primero y ponderar después es la receta para racionalizar las decisiones ya tomadas.
Dicho esto, la ponderación tiene un suelo. Los ejes 3 y 7 son difíciles de rebajar en cualquier dominio sin vaciar el término, porque son los que sostienen la afirmación central del marco: que tu trabajo sigue siendo tuyo y utilizable cuando el proveedor no está. Un sistema puede ignorar la colaboración, puede podar agresivamente su historial y puede aceptar que sus metadatos sean visibles, y seguir siendo reconociblemente local-first. Un sistema que no arranca sin red, o que se apaga cuando caduca una cuenta, no lo es en ningún dominio, por muy bien que puntúe en el resto. Ponderar sirve para ordenar prioridades, no para conceder indultos.
Escritura personal
Pesa 5 y 7 por encima de todo. El eje 4 es prácticamente irrelevante.
Trabajo de campo
Los ejes 1 y 3 son innegociables. El resto se negocia alrededor de ellos.
Dominio regulado
El eje 6 domina y puede justificar recortar el 4 con mecanismos de coordinación.
Qué compromisos son aceptables
Aquí está la distinción que da valor práctico al marco. Un compromiso es aceptable cuando acota el daño, es declarado y es reversible. Es inaceptable cuando devuelve la autoridad al servidor mientras se sigue usando la etiqueta.
Son razonablemente aceptables: usar un servidor de retransmisión o de descubrimiento que solo vea metadatos, porque acota la fuga sin tocar la autoridad; podar historial con una política declarada, porque sacrifica una parte acotada del eje 5 a cambio de peso y simplicidad; ofrecer funciones opcionales en la nube que requieren descifrado explícito y consentido para casos concretos; mantener una réplica cifrada alojada para disponibilidad y recuperación, siempre que no sea la copia autoritativa; y no resolver la revocación criptográfica perfecta, siempre que se documente qué significa exactamente revocar en ese sistema.
No son aceptables: exigir cuenta o red para abrir datos que ya están en el disco; que el servidor guarde el contenido en claro mientras el producto se anuncia como local-first; ofrecer la exportación como única historia de propiedad; incluir comprobaciones de licencia que impidan trabajar sin conexión; y usar un formato local sin documentar cuya única implementación es el propio producto.
La regla que ordena la lista es sencilla de enunciar: los compromisos aceptables añaden dependencias opcionales, y los inaceptables restauran una dependencia obligatoria. Un servidor de retransmisión mejora tu experiencia si está disponible y no te quita nada si desaparece; una comprobación de licencia en el arranque te quita el producto entero el día que el servicio no responda. La pregunta operativa, entonces, es siempre la misma: apagado el proveedor, ¿qué queda en pie?
Hay una consecuencia útil para quien construye. Si defines desde el principio el conjunto exacto de funciones que deben seguir operando con el proveedor apagado, ese conjunto se convierte en una prueba automatizable que puedes ejecutar en integración continua, con la red simulada como caída permanente. La deriva hacia la nube casi nunca ocurre por una decisión deliberada; ocurre por acumulación de pequeñas llamadas remotas que nadie revisó. Una prueba que falle en cuanto el arranque toque la red es más eficaz que cualquier principio escrito en un documento.
Un compromiso es aceptable si, tras explicarlo con precisión a una persona usuaria informada, esta seguiría eligiendo el producto. Es inaceptable si el producto necesita que ese detalle no se explique. El marco, en el fondo, es un dispositivo para forzar esa explicación.
Queda un último uso de la rúbrica que es el más productivo de todos y el menos evidente: aplicarla antes de construir, sobre un sistema que todavía no existe. Puntuar un diseño en los siete ejes durante la fase de propuesta cuesta una tarde y revela de inmediato cuáles de las decisiones aparentemente abiertas están en realidad ya tomadas. Si el diseño contempla identificadores asignados por el servidor, los ejes 2 y 3 ya están perdidos aunque nadie lo haya escrito. Si contempla búsqueda del lado del servidor, el eje 6 ya está perdido. Descubrir eso en el documento de diseño es barato; descubrirlo dos años después, cuando el formato ya está en los discos de miles de personas, es una reescritura.
Evidencia, no promesa
Puntúa por el resultado de la prueba, nunca por el mecanismo declarado en la documentación.
Pesos antes que notas
Declara el dominio y pondera los ejes antes de puntuar, para no racionalizar a posteriori.
Rúbrica en el diseño
Aplícala sobre la propuesta, no sobre el producto acabado. Ahí es donde todavía se puede cambiar.
La tentación permanente con los siete ideales es convertirlos en una frontera: definir un umbral, otorgar un sello y discutir quién está dentro. Esa deriva destruiría exactamente lo que los hace valiosos. Su función no es clasificar productos, sino obligar a hacer explícita una negociación que de otro modo se haría por omisión. Cuando un equipo construye sin este vocabulario, no evita los compromisos: los toma igual, pero los toma sin nombrarlos, distribuidos entre decisiones aparentemente técnicas y locales —un identificador asignado por el servidor aquí, una comprobación de sesión en el arranque allá, un formato binario sin especificar porque había prisa— y descubre demasiado tarde que ha construido una aplicación de nube con caché. Con el vocabulario, cada una de esas decisiones aparece como lo que es: un pago concreto en un eje concreto, hecho a cambio de algo que puede justificarse o no. La incompletitud del marco es, por tanto, su mecanismo central de funcionamiento: al garantizar que nadie puede reclamar el pleno, elimina el incentivo de fingirlo y sustituye la pregunta de pertenencia por la única pregunta que produce mejores sistemas, que es dónde estás pagando y qué estás comprando con ello. Que en 2026 FOSDEM dedicara una sala entera al tema indica que la conversación ha madurado lo suficiente como para discutir compromisos concretos en lugar de manifiestos; ese es exactamente el estado en que un marco de ideales rinde más.
- Redacta las siete pruebas observables en una sola línea cada una, ejecutables sin ver el código.
- Elige un dominio concreto, asigna pesos a los siete ejes y justifica los dos extremos.
- Puntúa dos productos que uses, uno que se anuncie como local-first y otro que no, y compáralos.
- Clasifica cinco compromisos reales que hayas visto en aceptables o inaceptables según el criterio de la explicación.
- Escribe la declaración de compromisos que publicarías si diseñases hoy una herramienta con este marco.