La nube es una prisión. ¿Puede el local

Gregorio Barbero

Hace unos años, el foro de discusión Hacker News, donde los ingenieros deciden colectivamente qué deberían leer otros ingenieros, desarrolló una peculiaridad. Una nueva frase había entrado en el léxico de los codificadores y parecía impulsar enlaces a la parte superior de la página con tal fuerza que a algunos las clasificaciones podrían haber parecido manipuladas. La frase “software local primero” tenía un tono artesanal, de la granja a la mesa, familiar y al mismo tiempo indicando algo nuevo. Quizás algunos ingenieros lo descartaron como un mero término de marketing. Pero otros, que redujeron sus tardes de trabajo, parecieron verlo como la solución a un problema que habían percibido durante mucho tiempo: el software que estaban escribiendo no funcionaba.

Uno de los primeros enlaces de Hacker News hacía referencia a un documento técnico publicado en 2019, en coautoría de un científico informático de la Universidad de Cambridge llamado Martin Kleppmann y un grupo de desarrolladores de código abierto en un “laboratorio de investigación industrial” independiente llamado Ink & Switch. Kleppmann y los demás eran alumnos de nuevas empresas tecnológicas exitosas que habían hecho lo que generalmente deben hacer las nuevas empresas tecnológicas exitosas: ser adquiridas. Habían dado un giro dentro de sus compradores más importantes y salieron arrepentidos, decepcionados con ciertos aspectos de su industria. Había más desarrolladores de software que nunca, pero no estaban codificando mejores experiencias para sus colegas o usuarios. Estaban codificando para la nube.

El lamento no era precisamente nuevo. Un eslogan impreso en calcomanías para parachoques, camisetas y botellas de agua en Silicon Valley se ha burlado durante mucho tiempo de la industria local con la afirmación “No hay nubes. Sólo existe la computadora de otra persona”. Que “alguien más” sea una corporación. Venga a Sand Hill Road con una idea para una aplicación orientada al consumidor, y hay dos rutas para obtener un cheque lo suficientemente importante como para que aparezca en TechCrunch: monetizar los datos de sus usuarios para reventa o publicidad, o cobrarles una tarifa por acceder a esos datos. Cualquiera que sea el modelo de negocio basado en la nube que elija (“Senador, publicamos anuncios” o “Páguenos o si no”), es imperativo que los datos se ejecuten a través de sus propios servidores.

El libro blanco local (“manifiesto” podría ser el término más apropiado) apuntaba a una tercera vía. La belleza de la nube, para el usuario promedio, es que es accesible desde muchos dispositivos y permite la colaboración entre muchas personas en salas y continentes. Los autores propusieron mantener todo eso, pero con un software que esencialmente no tuviera nubes. La palabra "local" en el nombre se refiere a su computadora personal. "Primero" significa que su computadora tiene prioridad sobre "la de otra persona". Si usted y yo quisiéramos trabajar juntos en un documento, ya no tendríamos que depender de algún centro de datos de Google en el alto desierto de Oregón para mantener la copia maestra. En cambio, cada uno de nosotros tendría copias almacenadas localmente en los discos duros de nuestros dispositivos. Podría editar mi copia sin conexión y tú podrías editar la tuya, y los dos archivos conciliarían nuestros cambios cada vez que se conectaran, ya sea una vez por minuto o una vez por semana.

Para crear productos como este se necesitarían formas fundamentalmente diferentes de estructurar los datos. Matemáticas diferentes. ¿El resultado de ese esfuerzo? Software menos de mierda. Liberados de preocuparse por los backends, los servidores y las tarifas exorbitantes de la computación en la nube, las nuevas empresas y los desarrolladores independientes podrían saltarse la financiación de capital riesgo y buscar aplicaciones más interesantes. Es más, podrían aprovechar las mejoras de hardware que los desarrolladores de la nube a menudo pasan por alto. Cuando una aplicación está basada en la nube, su rendimiento está limitado por la velocidad de su conexión al servidor central y la rapidez con la que ese servidor puede responder. Con una aplicación local, el dispositivo del usuario ejecuta todo el código. Cuanto mejor sea su computadora portátil o teléfono inteligente, más podrá hacer la aplicación.

Para un desarrollador, las tendencias opuestas de acelerar las máquinas y tiempos de carga estancados son bastante tontas. Ofensivo, de verdad. Tú también deberías ofenderte, porque significa que te has estado perdiendo algo. La nube parece celestial, hasta que deja de serlo. ¿No te has dado cuenta últimamente, a medida que los cinturones se aprietan en Silicon Valley, que tu Internet personal parece menos abundante que antes? ¿Que ciertas cosas se están volviendo un poco más caras o un poco menos convenientes? Un costo mensual para mantener todas tus fotos almacenadas o hacer una copia de seguridad de tu teléfono. Una actualización premium para permitir que varios usuarios editen el mismo archivo. Un videojuego que requiere una suscripción y se retrasa justo cuando buscas ganar.

Matt Simón

Celia Ford

adrien so

Hermoso Biondini

El periodista y autor de ciencia ficción Cory Doctorow utiliza el término “enshitificación” para describir cómo el capitalismo de plataforma desperdicia tecnología útil. Una nueva plataforma, repleta de capital de riesgo, es, en primer lugar, buena para sus usuarios. Entonces los anunciantes acuden a su audiencia y la plataforma también es buena con ellos. Luego, todavía hambriento de ganancias, envenena el pozo. Comienza a interferir con las características que valoras hasta que te hartas. Así es “como mueren las plataformas”, escribe Doctorow. La fría lógica empresarial abre este lamentable camino, pero las opciones tecnológicas lo allanan.

Quizás eso esté bien. Quizás el proceso sea regenerativo, como un incendio forestal que limpia la maleza. Da paso a que las nuevas plataformas vuelvan a ser buenas con nosotros, al menos por un tiempo. Pero ¿y si algo diferente pudiera echar raíces? ¿Qué pasaría si cambiar las entrañas del software, invisibles para la mayoría de nosotros, pudiera ayudar a sacar a la tecnología de la mierda?

Kleppmann y yo estamos suspendidos tres pisos sobre el estacionamiento del Museo de la Ciudad de St. Louis, una antigua fábrica de zapatos convertida en patio de juegos arquitectónico y patio de salvamento. Es hora de cerrar y los guardias quieren que bajemos y nos vayamos. Kleppmann, sin embargo, apunta al punto más alto de la estructura, un jet ejecutivo ahuecado de los años 60, al que se puede acceder a través de un tubo muy inclinado hecho de eslabones de cadena. Lleva un suéter azul real que de alguna manera lo identifica instantáneamente como europeo, su cabello rizado de color marrón anaranjado recogido en una apretada cola de caballo. Mientras se desliza dentro del fuselaje, imagino que estoy persiguiendo a un zorro.

La noche en el museo es la parte favorita de Kleppman de Strange Loop, que podría ser su conferencia de desarrolladores favorita. Es un evento que fusiona alegría y rareza con practicidad: su combinación ideal. Kleppmann es quizás mejor conocido por un libro de texto llamado Diseño de aplicaciones intensivas en datos, que explica los fundamentos del movimiento de grandes cantidades de datos en vastos sistemas informáticos. Una peculiar guía de supervivencia para el desarrollador moderno, ha vendido más de 200.000 copias, suficientes para merecer el estatus de celebridad en esta comunidad. Los fanáticos detienen a Kleppmann junto a la boca abierta de una escultura de ballena de tamaño natural y cuando emerge de un tobogán de cinco pisos, agradeciéndole por ayudarlos a conseguir sus primeros trabajos de software.

Las semillas del primer manifiesto local se pueden encontrar en un pequeño recuadro en la página 174 del libro de Kleppmann. Describe algo llamado tipo de datos replicados sin conflictos, o CRDT, que define como una "familia de estructuras de datos" que permite a muchas personas colaborar en un archivo y "resolver conflictos automáticamente de manera sensata". En el libro, Kleppmann señala que la implementación de algoritmos CRDT es "todavía joven".

Sin embargo, según los estándares informáticos, los propios CRDT eran viejos. Fueron desarrollados conjuntamente por un teórico informático francés llamado Marc Shapiro hace unas dos décadas, cuando la revolución de la nube aún era incipiente. Shapiro, que suscribía muchos de los ideales del movimiento peer-to-peer, estaba empezando a temer a dónde podría llevar la computación en la nube a la Web. Si bien el protocolo de Internet en sí permaneció abierto y descentralizado, lo que se estaba construyendo sobre él se movía en una dirección monopolística. Las empresas de tecnología cultivaban hermosos jardines para atraer a los usuarios y luego construían muros para disuadirlos de irse.

Matt Simón

Celia Ford

adrien so

Hermoso Biondini

Sin embargo, un área que aún no habían conquistado por completo era la colaboración en línea. La conectividad no era lo suficientemente buena en ese momento. Shapiro y su colega Nuno Preguiça se preguntaron: ¿La gente tenía que estar en línea para colaborar en línea? ¿O podrían trabajar sin conexión y colaborar entre pares?

Conceptualmente, no era tan difícil de imaginar: crear muchas réplicas del mismo archivo, cada una de las cuales automáticamente pasa a un estado idéntico al de sus pares, como átomos en entrelazamiento cuántico. Ya sea que edite su réplica primero y luego reciba mis cambios, o que yo edite mi réplica y luego reciba sus cambios, el algoritmo produce el mismo resultado para ambos. En lenguaje matemático, esa es la propiedad "conmutativa". (De hecho, es lo que inicialmente significaba la “C” en CRDT).

¿Cómo debería abordar esto el algoritmo? En la mayoría de los casos, la respuesta es sencilla. Si agrego un párrafo y quitas otro, el orden no importa. Pero supongamos que cada uno de nosotros jugueteamos con la misma palabra; tú crees que debería ser morado y yo creo que debería ser malva. ¿Qué impide que el resultado sea purmaupleve? Diferentes CRDT resuelven esto con diferentes reglas destinadas a preservar la intención de los distintos colaboradores. Es posible que dependan de marcas de tiempo para ordenar los nuevos elementos, o tal vez tengan alguna forma de codificar la relación de cada elemento con los elementos que lo rodean, preservando alguna noción de palabras u oraciones. Las posibilidades son numerosas.

Estos trucos para preservar el orden también pueden hacer que el CRDT sea terriblemente ineficiente. Son demasiados datos para realizar un seguimiento. Entonces, la otra tarea para diseñar un CRDT es la edición: decidir la cantidad mínima de información que las réplicas deben enviarse entre sí para producir un resultado armonioso y cómo empaquetar esos cambios de manera eficiente.

Shapiro y Preguiça publicaron inicialmente su algoritmo CRDT como un informe técnico. Shapiro pensó en iniciar una empresa centrada en la edición colaborativa. “Unos meses más tarde, ¡bang!, sale Google Docs”, me dice. El nuevo software utilizó un proceso más antiguo para fusionar cambios llamado transformación operativa u OT, y aún dependía de un servidor central de Google. Shapiro creía que había inventado algo que era más sólido desde el punto de vista teórico: una base estable para un software verdaderamente peer-to-peer. Pero cuando Kleppmann encontró su artículo años después, pocas personas utilizaban el software.

Kleppmann había crecido en Alemania jugando con computadoras y su viola. Después de un coqueteo abandonado con una carrera en composición (las nociones de la torre de marfil de “lo que era bueno y lo que era basura” no le convenían), había seguido el arco clásico de su carrera tecnológica: cofundó una startup (llamada Rapportive, que integraba datos desde perfiles de redes sociales hasta contactos de correo electrónico); se mudó al Área de la Bahía (más cerca de inversores y gigantes de las redes sociales); su startup fue adquirida por un gigante tecnológico (LinkedIn). Kleppmann duró algunos años antes de partir para ocupar un puesto de investigación en Cambridge.

El nuevo trabajo le dio a Kleppmann lo que había deseado durante mucho tiempo: volver a la creatividad. Tenía flexibilidad para explorar enfoques de programación más inusuales, incluidos proyectos que podrían no dar resultados inmediatos. Explica su trabajo con una analogía que tomó prestada de su esposa, profesora de química de secundaria. Si piensa en los bytes individuales de datos como átomos, entonces las estructuras de datos son como moléculas. Para cualquier codificador nuevo, el siguiente paso después de "hola, mundo" es aprender estos arreglos: listas, árboles, hashes y gráficos, por nombrar algunas categorías amplias. Lo que Kleppmann quería descubrir eran disposiciones atómicas más extrañas que pudieran permitir diferentes tipos de aplicaciones.

Matt Simón

Celia Ford

adrien so

Hermoso Biondini

Describe el artículo de Shapiro como "un despertar". Kleppmann vio en los CRDT la base técnica para una nueva clase de software que nadie ofrecía. Pero los algoritmos eran en su mayoría inútiles para los programadores profesionales. Eran demasiado ineficientes y carecían de las herramientas típicas que los desarrolladores realmente utilizan para crear aplicaciones. Kleppmann se dio cuenta de que tendría que facilitarles la vida a los desarrolladores locales, guiando la idea desde un conjunto de pruebas matemáticas hasta un código listo para producción. Se dedicó a codificar una implementación de código abierto de CRDT, a la que llamó Automerge, que la gente podía utilizar libremente para crear aplicaciones.

Vi el fruto de este esfuerzo unos años más tarde, poco después de que apareciera el primer manifiesto local en Hacker News. Conocí a Peter van Hardenberg, uno de los coautores de Kleppmann, en un café de San Francisco. Al igual que Kleppmann, se estaba reiniciando después de un largo viaje a través de la nube, primero como parte del equipo fundador de Heroku, que ayudó a otras nuevas empresas a poner en marcha sus servicios en la nube, y luego dentro de su adquirente, Salesforce. Quería mostrarme una aplicación llamada Pushpin, concebida como un tablero de corcho digital.

Van Hardenberg sacó un proyecto en blanco en su iPad. Cargué una réplica del mismo archivo en mi computadora portátil. Comenzamos a experimentar, agregando imágenes y cuadros de texto a nuestros propios archivos y luego permitimos que se fusionaran. A veces esto funcionaba a la perfección; otras veces los cambios dejaron de cargarse o los píxeles se arrastraron con la latencia de la era del acceso telefónico. Pushpin parecía un juguete, el tipo de aplicación que un par de estudiantes universitarios de Stanford con ojos brillantes podrían codificar en la sala común con visiones de una ronda de semillas y luego dejar de lado avergonzados.

Pero van Hardenberg estaba lejos de avergonzarse. Creía que se estaban sentando las bases técnicas para las primeras versiones locales de Slack, Discord, Google Docs y Photoshop. Mejores aplicaciones de diseño, calendarios, presupuestos. También programas más complejos, si pudieran hacer que Automerge sea mucho más eficiente. Existía la posibilidad de un cifrado privado de extremo a extremo para todas estas aplicaciones colaborativas, ya que ningún servidor se interpondría en el camino. Había límites técnicos para los CRDT y muchas aplicaciones a las que la nube serviría mucho mejor. Pero para él, el prototipo le pareció una revolución. No había un servidor entre nosotros. Sin embargo, funcionó. Principalmente. Éramos dos pares comunicándonos, como pretendían los primeros albañiles de internet.

La visión de Van Hardenberg fue algo más fácil de ver cuando nos volvimos a encontrar en St. Louis. Los gigantes tecnológicos estaban cayendo. Las acciones de Meta estaban en su nivel más bajo en siete años. Twitter estaba en medio de una adquisición hostil de Elon Musk. Kleppmann pasaba algunas horas a la semana como asesor técnico de Bluesky, generado por Twitter como un experimento descentralizado y ahora repentinamente destacado, listo para convertirse en su competidor. Su diseño “federado” prometía dar a las personas la opción de abandonar servidores y servicios que los trataban mal. Bluesky no estaba usando CRDT, que serían demasiado lentos para coordinar las transmisiones de millones de usuarios de redes sociales, pero el objetivo era similar: una mejor relación con "la computadora de otra persona". Las alternativas informáticas volvieron a estar de moda.

Entre ellos, los CRDT. Strange Loop estaba repleto de presentaciones locales, una sorpresa para Kleppmann y van Hardenberg, quienes hasta hace poco habían realizado un seguimiento de cada proyecto a través de alertas de Google y el boca a boca. Los CRDT también estaban apareciendo en el resto del mundo. Los desarrolladores de The Washington Post los habían utilizado para crear una herramienta para organizar artículos en la página de inicio. La gente que husmeaba en el código que ejecuta la aplicación Notas de Apple había notado CRDT. Jupyter Notebooks, una popular aplicación de ciencia de datos, restauró sus herramientas de colaboración utilizando CRDT después de que Google se deshiciera del servicio en la nube del que dependía anteriormente.

Entre los presentadores de Strange Loop se encontraba un desarrollador canadiense llamado Brooklyn Zelenka, cofundador de una empresa llamada Fission. Cuando leyó el primer manifiesto local, recuerda: “Pensé: ésta es una gran frase. Antes de eso, teníamos frases incómodas, como 'independencia de ubicación' o 'datos propiedad del usuario'”. Zelenka había estado interesada en las ideas de Web3, el apodo adoptado por las aplicaciones “descentralizadas” que utilizan tecnología blockchain y criptomonedas, pero descubrió que su cultura es “agresiva”, lo que ella atribuyó al enfoque en el dinero “tan claramente, todo el tiempo”. Fue agradable llegar temprano al local primero. “En este momento todo es una fruta madura”, me dijo Zelenka.

Matt Simón

Celia Ford

adrien so

Hermoso Biondini

La suya fue una trayectoria común. Las criptomonedas "sacaron a relucir a las peores personas", me dijo van Hardenberg durante el almuerzo en la conferencia, pero también refirieron muchos de los mismos principios que lo local primero. En su opinión, simplemente utiliza el enfoque equivocado: promete a los usuarios descentralización e independencia, pero los ata a incentivos financieros especulativos. También es lo opuesto a lo primero fuera de línea: las engorrosas cadenas de bloques, controladas por quien acapara la mayor cantidad de recursos, median en cada interacción. Aún así, las criptomonedas ofrecieron una lección sobre cómo la publicidad puede impulsar la creación de nuevos productos. Van Hardenberg notó la gran cantidad de programadores aburridos y descontentos en empresas como Meta y Google que abandonaron el barco en el apogeo de la burbuja criptográfica.

Pensó que lo local primero podría provocar eventualmente el mismo entusiasmo, pero con un software que fuera realmente bueno. Lo que necesitaba, dijo van Hardenberg, era una gran “salida” que trajera “señales de riqueza visible” a algún grupo afortunado de desarrolladores locales y ayudara a atraer más talento y recursos. El crecimiento también fue aterrador. Van Hardenberg y Kleppmann hasta ahora habían evitado la financiación de capital de riesgo para la propia Automerge, por temor a que los obligara a adoptar cualquier variedad de modelos de negocio que “van totalmente en contra de los valores de lo local primero”, como me dijo Kleppmann. Pero se dieron cuenta de que en algún momento el crecimiento también sería necesario. Esperaban que el software pudiera valerse por sí solo. "A los capitalistas de riesgo les encanta cambiar de plataforma", dijo van Hardenberg.

Unos meses después de la conferencia, “lo local primero” volvió a ser tendencia en Hacker News. Un comentarista llamó a los CRDT la espada “matadragones” que permitiría que las aplicaciones locales compitan con la nube. Otro lamentó que cada publicación técnica interesante sobre las CRDT se convirtiera en una “extraña discusión política sobre la descentralización”.

A pesar de muchos movimientos a favor de la descentralización tecnológica, el tesoro de oro del dragón ha seguido creciendo. Un problema es la percepción de que los principios se obtienen a expensas de la conveniencia. Por más gratificante y virtuoso que sea tallar tu propia mesa de café, también es difícil. Al final te cansas y compras tu próximo mueble en Amazon. Lo mismo ocurre con la gestión de sus datos. "Es mucho más fácil ser perezoso y dejar que Apple o Google lo hagan por ti", me dijo Shapiro. Cuando le pregunté cómo era utilizar Internet moderno respetando sus principios, dijo que simplemente se abstiene de la tecnología tanto como puede. “Es una terrible pérdida de tiempo”, me dijo.

Tenía curiosidad por saber si el término “local primero” molestaba en algo a Shapiro, si lo tomó como un cambio de nombre no deseado de su creación técnica. Me sorprendí cuando me dijo que le encantaba. Había magia en la frase, pensó. Tal vez la revolución tenga que ser un poco astuta para asestar un golpe: atraer a los desarrolladores con las posibilidades técnicas, llamarlo un “movimiento” para atraer a los periodistas obsesionados con la política (hola). Quizás también deba llegar en el momento adecuado, cuando las plataformas de las Big Tech parezcan a punto de desmoronarse, revelando las características perdidas y los abusos sufridos a cambio de conveniencia.

Kleppmann no exigía volver a lo analógico ni destruir todos los servidores en la nube, que hacen muchas cosas útiles. La espada no era un asesino, sino una herramienta para tallar algo mejor, e incluso él diría que todavía necesita afilarse. Cuando le pregunté si podía probar un nuevo editor de texto basado en CRDT en el que había estado trabajando, su habitual expresión de tranquila atención se transformó brevemente en alarma. Por supuesto, en teoría podría ejecutar el prototipo que está publicado en línea, ya que es de código abierto, "pero por favor no hagas eso", me dijo. Me avisaría cuando local-first estuviera listo.

Háganos saber lo que piensa acerca de este artículo. Envíe una carta al editor a [email protected].