La exportación no basta

El botón de descargar mis datos es la respuesta estándar del sector a la pregunta de la propiedad, y funciona porque desactiva la conversación: si puedes bajarte todo, parece que todo es tuyo. La tesis de esta lección es que esa inferencia no se sostiene, y no por mala fe de quien construye el botón sino por una diferencia estructural entre dos clases de artefacto que solemos llamar igual. Un formato de intercambio existe para ser leído una vez por otro sistema; un formato de trabajo existe para ser el sustrato sobre el que una aplicación opera de forma continua. Confundirlos produce el equívoco central del debate sobre propiedad de datos: te entregan un archivo cuando lo que hacía falta era un espacio de trabajo. Vamos a precisar la diferencia, a inventariar las tres cosas que toda exportación pierde y a definir qué tendría que cumplir una exportación para contar como propiedad de verdad, incluido por qué a un proveedor honesto le cuesta tanto ofrecerla.

Qué prueba y qué no prueba un botón de descarga

Conviene empezar por lo que la existencia del botón demuestra, porque el argumento pierde fuerza si se presenta como una denuncia y no como una distinción.

Empecemos reconociendo lo que sí prueba, porque no es trivial. Que exista una exportación demuestra que el proveedor no ha diseñado una prisión deliberada, que existe algún camino de salida y que el contenido no está atrapado en un formato imposible de serializar. En términos regulatorios cumple con el suelo que fija la portabilidad: un formato estructurado, de uso común y lectura mecánica. Cualquier alternativa a eso es peor, y conviene no confundir la crítica al botón con un desprecio del botón.

Demuestra también algo cultural que no es menor: que dentro de esa organización alguien defendió la salida del usuario en una reunión donde nadie tenía incentivo para hacerlo. Los exportadores no se construyen solos, no producen ingresos y compiten por tiempo de desarrollo con funciones que sí lo producen. Que existan y funcionen razonablemente bien es, con frecuencia, la señal más fiable de que el equipo se toma en serio la relación con quien usa el producto.

Conviene además distinguir tres motivos por los que alguien exporta, porque el mismo artefacto sirve muy desigualmente para cada uno. La copia de seguridad solo exige que el contenido esté completo y sea legible por un humano en el peor de los casos: para eso, casi cualquier exportación vale. La migración exige además que otro producto pueda importarlo con una pérdida tolerable, lo que ya elimina a la mayoría. La operación paralela —seguir trabajando fuera del proveedor, o construir algo encima— exige identidad estable, actualización incremental y semántica completa, y ahí no llega prácticamente nadie. Discutir sobre exportaciones sin decir para cuál de los tres usos garantiza confusión.

Lo que no prueba es cualquier cosa relacionada con la continuidad. Una exportación es una instantánea puntual de un sistema vivo, y todo lo interesante de ese sistema está en el hecho de estar vivo: los índices que hacen que buscar sea instantáneo, las vistas que agregan, los permisos que gobiernan quién ve qué, las automatizaciones que reaccionan a los cambios, las referencias que otros mantienen hacia tus elementos. Nada de eso viaja. Lo que llega a tu disco es la sombra proyectada de una estructura, no la estructura. Y lo que se descarga empieza a envejecer en el mismo segundo en que termina la descarga, porque el sistema original sigue cambiando y tu copia no.

Hay una prueba mental que deja el punto claro de inmediato: imagina que el proveedor cierra esta noche y mañana solo tienes el archivo que descargaste. Cuánto tiempo pasaría hasta que pudieras volver a trabajar como trabajabas, con qué herramienta y con cuánta pérdida. Si la respuesta se mide en semanas, lo que tenías no era propiedad sino una copia de seguridad; y una copia de seguridad es una cosa razonable de tener, pero es una respuesta a un problema distinto del que la palabra propiedad sugiere.

flowchart LR
subgraph Exportacion
  A[Sistema vivo del proveedor] -->|instantanea puntual| B[Archivo descargado]
  B --> C[Copia que envejece desde el primer segundo]
end
subgraph LocalFirst
  D[Formato de trabajo en tu disco] <--> E[Aplicacion que lo edita]
  D -.sincronizacion opcional.-> F[Servidor de replicas]
end
style C fill:#f38ba8,color:#11111b
style D fill:#a6e3a1,color:#11111b

Intercambio frente a trabajo

La distinción se puede definir con precisión, y esa precisión es lo que convierte una intuición en un criterio. Un formato de intercambio es unidireccional, con pérdida asumida, pensado para una lectura única y sin obligación de identidad estable: su éxito se mide en que otro sistema pueda importarlo aproximadamente. Un formato de trabajo cumple seis propiedades que el de intercambio no necesita cumplir:

1. Bidireccional. Se puede leer y escribir con el mismo grado de fidelidad, no solo generar.
2. Sin pérdida. Todo lo que el sistema sabe está representado, incluidas las partes que no se muestran en la interfaz.
3. Mutable en el sitio. Se puede modificar una parte sin regenerar el conjunto.
4. Incremental. Se puede actualizar por trozos, lo que hace viable mantenerlo sincronizado de forma continua.
5. Con identidad estable. Cada elemento lleva un identificador duradero entre versiones y entre exportaciones.
6. Con invariantes explícitas. Las reglas que el contenido debe cumplir están declaradas y son verificables desde fuera.

Ninguna de las seis es un capricho de purista: cada una habilita una capacidad concreta que la otra clase de formato no puede ofrecer. Sin bidireccionalidad no hay vuelta atrás y la migración es un viaje de ida. Sin ausencia de pérdida no se puede confiar en la copia como sustituto. Sin mutabilidad e incrementalidad, mantener la copia al día exige regenerarla entera cada vez, lo que en volúmenes reales la vuelve impracticable. Sin identidad no hay comparación posible. Y sin invariantes explícitas nadie de fuera puede validar que lo que tiene está completo y es coherente.

De esas propiedades, la más subestimada es la identidad estable. Si los elementos exportados no llevan identificadores duraderos, no puedes comparar la exportación de hoy con la de la semana pasada, no puedes fusionar cambios, no puedes mantener enlaces desde otro sistema y no puedes construir nada encima. Sin identidad no hay diferencia; sin diferencia no hay proceso; sin proceso solo hay archivo. Un producto que exporta con identificadores aleatorios en cada descarga puede estar cumpliendo la letra de la portabilidad y anulando por completo su utilidad.

Y es una omisión que casi nunca responde a mala intención, lo cual la hace más instructiva. Los identificadores internos suelen considerarse un detalle de implementación que no debe filtrarse al exterior, y esa es una regla de diseño sensata en casi todos los contextos: exponerlos ata al equipo a no cambiarlos nunca. Pero en el contexto de la exportación esa misma prudencia produce un artefacto inservible para todo lo que no sea leerlo una vez. La solución habitual —publicar un identificador estable y público, distinto del interno y sin relación con él— es barata y poco frecuente, y su ausencia es un buen indicador de que nadie pensó la exportación como algo que alguien fuera a usar dos veces.

Las tres pérdidas

Toda exportación pierde tres cosas distintas, y conviene no mezclarlas porque cada una se mitiga de un modo diferente.

La primera es la fidelidad semántica. Se conservan las palabras y se pierden las relaciones, y la lista de bajas es siempre parecida:

• Las referencias entre elementos se degradan a texto plano o a enlaces rotos hacia un dominio al que ya no tienes acceso.
• Las vistas filtradas y ordenadas desaparecen, porque eran consultas ejecutándose y no datos almacenados.
• Las fórmulas se sustituyen por los valores que producían, con lo que se conserva el resultado y se pierde el razonamiento.
• Los permisos, los comentarios y las menciones se omiten, por ser propiedades de la colaboración y no del contenido.
• La historia de revisiones se aplana a la última versión, y con ella se va la posibilidad de auditar quién cambió qué.

La prueba diagnóstica es brutal en su sencillez y casi nadie la pasa: exporta, importa en el mismo producto y compara. Si el propio importador del proveedor no consume sin pérdida la salida de su propio exportador, ningún tercero lo hará jamás.

La segunda es la continuidad. Una exportación es un evento, no un flujo. No hay exportación incremental, no hay suscripción a los cambios, no hay forma de mantener una copia al día sin repetir la descarga completa. Desde el instante en que se genera, tu copia y el sistema vivo divergen, y esa divergencia solo crece. Poseer una fotografía de tu trabajo de hace tres meses no es poseer tu trabajo.

Esta pérdida tiene además un efecto psicológico que conviene nombrar, porque explica por qué el botón funciona tan bien como argumento comercial. La exportación calma la ansiedad sin resolver el problema: quien descarga su archivo siente que ha recuperado el control y archiva la preocupación, aunque el archivo que guarda quede obsoleto en horas y nunca vuelva a abrirse. Es una garantía que casi nadie ejercita y que por eso casi nadie descubre insuficiente hasta el día en que la necesita de verdad.

La tercera, y la más decisiva, es el intérprete. Los datos sin el programa que los ejecuta no son un espacio de trabajo, son un archivo histórico. Puedes leer tus notas, no puedes seguir trabajando en ellas con las mismas capacidades. Esta pérdida no se arregla mejorando el formato, porque no es un problema de formato: es que la mitad del valor estaba en el software, y la exportación nunca incluyó el software. Aquí es donde la lección sobre longevidad y esta se cruzan: un formato durable sin intérprete reconstruible es una conservación a medias.

Y conviene ordenar las tres por dificultad de reparación, porque no todas admiten la misma respuesta:

• La fidelidad se mejora con trabajo del proveedor: es una cuestión de cuánto se decide representar en la salida, y es negociable.
• La continuidad se mejora con una interfaz de lectura incremental e identificadores estables: es un problema técnico bien delimitado y resuelto en otros dominios.
• El intérprete no se mejora desde dentro del producto: exige que exista un ecosistema con al menos dos implementaciones, y eso es un hecho del mercado y no una decisión de ingeniería.

Qué haría que una exportación contase

Con lo anterior se puede escribir un criterio verificable, y prefiero enunciarlo como cuatro pruebas concretas antes que como un principio abstracto:

1. Ida y vuelta. Exportar, importar en el mismo producto y obtener un sistema indistinguible del original. Es la prueba mínima y la que más productos suspenden.
2. Espejo continuo. Que la exportación sea incremental, automatizable sin intervención humana y con identificadores estables, de modo que dos ejecuciones consecutivas se puedan comparar.
3. Intérprete disponible. Que exista al menos un programa ajeno al proveedor capaz de abrir el resultado y permitir seguir trabajando, no solo leer.
4. Cobertura declarada. Que el proveedor documente explícitamente qué campos no se exportan, porque una lista honesta de omisiones vale más que una promesa vaga de completitud.

Las cuatro son verificables por un tercero sin acceso al código del proveedor, y esa es su virtud: convierten una discusión sobre intenciones en una comprobación que se ejecuta en una tarde.

Aplicadas a productos reales, el resultado suele ser desigual de una manera muy reconocible. Los formatos de contenido puro —texto, imágenes, mensajes— pasan la primera prueba con soltura y suspenden la segunda. Los productos estructurados —bases de datos ligeras, gestores de proyectos, espacios de trabajo— suspenden la primera y aprueban a veces la cuarta, porque documentan sus omisiones. Y la tercera prueba, la del intérprete ajeno, la superan casi exclusivamente los formatos que nacieron públicos, lo que confirma que ese requisito no depende del esfuerzo del proveedor sino de la existencia previa de un ecosistema.

Conviene añadir una quinta prueba que no es técnica sino temporal: la exportación debe funcionar cuando ya no eres cliente. Muchos productos ofrecen una salida excelente mientras pagas y ninguna cuando dejas de pagar, o la ofrecen durante una ventana de gracia tan corta que es inútil para quien se entera tarde. La capacidad de recuperar tu trabajo el día en que más lo necesitas —tras un impago, un cierre o una suspensión— es la única que cuenta, y es también la que jamás se prueba antes de contratar.

Ahora la posición contraria, y es más sólida de lo que el discurso soberanista suele conceder. Exportar el formato de trabajo real es genuinamente difícil y a veces perjudicial. Ese formato codifica invariantes internas, desnormalizaciones, índices y decisiones de rendimiento que existen para servir a la implementación actual; publicarlo lo convierte de facto en una interfaz pública con obligaciones de compatibilidad, y a partir de ahí cada refactorización interna se convierte en una ruptura para terceros. Muchos proveedores ofrecen exportaciones pobres por cálculo estratégico, pero muchos otros las ofrecen pobres porque un exportador fiel es, literalmente, un segundo producto que hay que mantener y probar. Y hay una consideración de fondo: para servicios cuyo valor reside en la red de participantes o en el cómputo que ejecutan, y no en el contenido, el formato de intercambio es la respuesta correcta, porque exportar los bytes no exportaría nada de lo que hacía valioso al servicio.

La objeción tiene incluso una versión que va más lejos y merece considerarse. Publicar el formato de trabajo puede perjudicar al propio usuario a medio plazo, porque congela la capacidad del producto de mejorar: cada cambio en la representación interna rompe a los terceros que dependían de ella, y un equipo que ha asumido ese compromiso empieza a rechazar mejoras que antes habría hecho. Hay productos cuya calidad actual sería impensable si su formato hubiera sido público desde el primer año. Reconocer esto no invalida el argumento de la propiedad, pero sí obliga a formularlo con más precisión: lo que hay que exigir no es que el formato interno sea público, sino que exista alguna representación completa, estable y documentada del contenido, aunque no sea la que la aplicación usa por dentro.