La Nube es una prisión. ¿Puede el movimiento de software de enfoque local liberarnos?
¿Puede el software local liberarnos de la prisión de la Nube?
Hace unos años, el foro de discusión Hacker News, donde los ingenieros deciden colectivamente qué deben leer otros ingenieros, desarrolló una peculiaridad. Una nueva frase había entrado en el léxico de los programadores, y parecía propulsar los enlaces hasta la cima de la página con tanta fuerza que a algunos les parecía que las clasificaciones podrían estar amañadas. La frase -“software local-first” (software en primer lugar local)- tenía un tono artesanal, de granja a mesa, a la vez familiar y apuntando a algo nuevo. Tal vez algunos ingenieros lo descartaron como un simple término de marketing. Pero otros, que pasaban sus tardes de trabajo tallando madera, parecían verlo como la solución a un problema que habían sentido durante mucho tiempo: el software que estaban escribiendo estaba roto.
Uno de los primeros enlaces de Hacker News se refería a un artículo técnico publicado en 2019, coescrito por un científico de la computación entonces en 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 exalumnos de exitosas empresas tecnológicas que habían hecho lo que generalmente se espera de las empresas tecnológicas exitosas: ser adquiridas. Habían pasado por sus compradores más grandes y habían salido arrepentidos, decepcionados con ciertos aspectos de su industria. Había más desarrolladores de software que nunca, pero no estaban creando mejores experiencias para sus colegas o usuarios. Estaban programando para la nube.
La lamentación no era exactamente nueva. Un eslogan impreso en pegatinas para parachoques, camisetas y botellas de agua en Silicon Valley ha burlado desde hace mucho tiempo a la industria local con la afirmación “No hay nube. Solo es la computadora de otra persona”. Esa “otra persona” siendo una corporación. Ven a Sand Hill Road con una idea para una aplicación dirigida al consumidor, y hay dos formas de obtener un cheque lo suficientemente grande como para que te mencionen en TechCrunch: monetizar los datos de tus usuarios para su reventa o publicidad, o cobrarles una tarifa por acceder a esos datos. Cualquiera que sea el modelo de negocio basado en la nube que elijas, ya sea “Senador, mostramos anuncios” o “Páganos o sufrirás las consecuencias”, es imperativo que los datos pasen por tus propios servidores.
El artículo técnico local-first (“manifiesto” podría ser el término más apropiado) señaló un tercer camino. 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 diferentes lugares. Los autores propusieron mantener todo eso, pero con un software que fuera esencialmente sin nube. La palabra “local” en el nombre se refiere a tu computadora personal. “First” significa que tu computadora tiene prioridad sobre “la de otra persona”. Si tú 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 desierto de Oregón para mantener la copia maestra. En su lugar, cada uno tendría copias almacenadas localmente en los discos duros de nuestros dispositivos. Yo podría editar mi copia sin conexión, y tú podrías editar la tuya, y los dos archivos reconciliarían nuestros cambios cada vez que se conectaran, ya sea una vez por minuto o una vez por semana.
Para construir productos como este se requerirían formas fundamentalmente diferentes de estructurar los datos. Matemáticas diferentes. ¿El resultado de ese esfuerzo? Un software menos malo. Liberados de preocuparse por los backends, los servidores y las exorbitantes tarifas de computación en la nube, las startups y los desarrolladores independientes podrían prescindir de la financiación de capital de riesgo con condiciones y dedicarse a aplicaciones más interesantes. Además, podrían aprovechar las mejoras de hardware que a menudo los desarrolladores en la nube se perdían. Cuando una aplicación está basada en la nube, su rendimiento está limitado por la velocidad de conexión con el servidor central y la rapidez con que ese servidor puede responder. Con una aplicación local-first, el dispositivo del usuario ejecuta todo el código. Cuanto mejor sea tu computadora portátil o teléfono inteligente, más podrá hacer la aplicación.
- Best Buy prácticamente está regalando este HP Chromebook hoy | ENBLE
- Esta actualización podría extender la vida útil de tu Chromebook po...
- Intel Core i5 vs. i7 ¿Qué CPU es adecuada para ti en 2023? | ENBLE
Para un desarrollador, las tendencias opuestas de máquinas aceleradas y tiempos de carga estancados son bastante ridículas. Ofensivas, realmente. También deberías sentirte ofendido, porque significa que te has estado perdiendo algo. La nube parece celestial, hasta que ya no lo es. ¿No has notado últimamente, a medida que los cinturones se aprietan en Silicon Valley, que tu propio internet personal se siente menos abundante que antes? Que ciertas cosas se están volviendo un poco más caras o 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 vas a ganar.
El periodista y autor de ciencia ficción Cory Doctorow utiliza el término “enshittification” para describir cómo el capitalismo de plataforma desperdicia tecnología útil. Una nueva plataforma, llena de capital de riesgo, es buena para sus usuarios al principio. Luego, los anunciantes llegan por su audiencia, y la plataforma también es buena para ellos. Luego, aún hambrienta de ganancias, envenena el pozo. Comienza a interferir con las características que valoras hasta que te hartas. Esto es “cómo mueren las plataformas”, escribe Doctorow. La lógica fría del negocio traza este lamentable camino, pero las elecciones tecnológicas lo pavimentan.
Tal vez eso está bien. Tal vez el proceso sea regenerativo, como un incendio forestal que limpia la maleza. Abre paso para que nuevas plataformas vuelvan a ser buenas para nosotros, al menos por un tiempo. Pero ¿qué pasaría si algo diferente pudiera arraigarse? ¿Qué pasaría si cambiar los entresijos del software, invisibles para la mayoría de nosotros, pudiera ayudar a empujar la tecnología fuera de la mierda?
Kleppmann y yo estamos suspendidos a tres pisos sobre el estacionamiento del City Museum de St. Louis, una antigua fábrica de zapatos convertida en un parque arquitectónico y depósito de salvamento. Es hora de cierre y los guardias quieren que bajemos y nos vayamos. Sin embargo, Kleppmann apunta al punto más alto de la estructura, un jet de negocios de los años 60 hueco, accesible a través de un tubo inclinado empinadamente hecho de malla metálica. Viste un suéter azul real que de alguna manera instantáneamente lo hace parecer europeo, su cabello rizado naranja-marrón recogido en una cola de caballo apretada. Mientras se desliza dentro del fuselaje, imagino que persigo a un zorro.
La noche en el museo es la parte favorita de Kleppmann de Strange Loop, que podría ser su conferencia de desarrolladores favorita. Es un evento que combina alegría y rareza con practicidad, su combinación ideal. Kleppmann es quizás más conocido por un libro de texto llamado “Diseñando aplicaciones de datos intensivas”, que explica los fundamentos de mover grandes cantidades de datos en sistemas informáticos vastos. Una guía de supervivencia peculiar para el desarrollador moderno, ha vendido más de 200,000 copias, lo que es suficiente para obtener 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, le agradecen por ayudarles a conseguir sus primeros trabajos de software.
Las semillas del manifiesto de local-first se pueden encontrar en una pequeña caja en la página 174 del libro de Kleppmann. Describe algo llamado un tipo de dato replicado sin conflictos, o CRDT, que define como una “familia de estructuras de datos” que permiten 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 los algoritmos CRDT todavía es “joven”.
Según los estándares de la computación, sin embargo, los CRDT en sí ya eran antiguos. Fueron co-desarrollados por un teórico informático francés llamado Marc Shapiro hace aproximadamente dos décadas, cuando la revolución en la nube aún estaba en sus inicios. Shapiro, quien se suscribió a muchos de los ideales del movimiento peer-to-peer, comenzó 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í seguía siendo abierto y descentralizado, lo que se estaba construyendo sobre él se estaba moviendo en una dirección monopolística. Las empresas tecnológicas estaban creando hermosos jardines para atraer a los usuarios y luego construían muros para desalentarlos a abandonarlos.
Sin embargo, aún no habían conquistado por completo la colaboración en línea. En ese momento, la conectividad no era lo suficientemente buena. Shapiro y su colega Nuno Preguiça se preguntaron: ¿Las personas tenían que estar en línea para colaborar en línea? ¿O podían trabajar sin conexión y colaborar de igual a igual?
A nivel conceptual, no era tan difícil imaginarlo: crear muchas réplicas del mismo archivo, cada una de las cuales se ajusta automáticamente a un estado idéntico a sus pares, como átomos en entrelazamiento cuántico. Ya sea que edites tu réplica primero y luego recibas mis cambios, o que edite mi réplica y luego recibas tus cambios, el algoritmo produce el mismo resultado para ambos. En términos matemáticos, esa es la propiedad “conmutativa” (de hecho, es para lo que inicialmente se usó la “C” en CRDT).
¿Cómo debería funcionar el algoritmo para lograr esto? En la mayoría de los casos, la respuesta es sencilla. Si agrego un párrafo y tú eliminas otro, el orden no importa. Pero supongamos que ambos modificamos la misma palabra; tú piensas que debería ser de color púrpura y yo creo que debería ser malva. ¿Qué impide que el resultado sea purmaupleve? Los diferentes CRDT resuelven esto con reglas diferentes destinadas a preservar la intención de los diversos colaboradores. Pueden basarse en 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 o frases. Las posibilidades son numerosas.
Estos trucos para preservar el orden también pueden hacer que el CRDT sea horriblemente ineficiente. Es demasiados datos para realizar un seguimiento. Por lo tanto, la otra tarea al diseñar un CRDT es la de la edición: decidir la cantidad mínima de información que las réplicas necesitan enviarse entre sí para producir un resultado armonioso, y cómo empaquetar esos cambios de manera eficiente.
Shapiro y Preguiça inicialmente publicaron su algoritmo CRDT como un informe técnico. Shapiro pensó en comenzar una empresa centrada en la edición colaborativa. “Unos meses después, boom, sale Google Docs”, me dice. El nuevo software utilizaba un proceso anterior para fusionar cambios llamado transformación operacional, o TO, y aún dependía de un servidor central de Google. Shapiro creía haber inventado algo que era más teóricamente sólido: una base estable para software verdaderamente de igual a igual. Pero cuando Kleppmann encontró su artículo años después, pocas personas estaban usando 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 “lo que era bueno y lo que era basura” de la torre de marfil no le convenían), siguió la carrera técnica clásica: cofundó una startup (llamada Rapportive, integraba datos de perfiles de redes sociales en contactos de correo electrónico); se mudó al área de la Bahía (más cerca de los inversores y los gigantes de las redes sociales); su startup fue adquirida por un gigante tecnológico (LinkedIn). Kleppmann duró unos años antes de irse a 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 más inusuales de la programación, incluyendo proyectos que podrían no dar resultados inmediatos. Explica su trabajo con una analogía tomada de su esposa, una profesora de química de secundaria. Si piensas en los bytes de datos individuales como átomos, entonces las estructuras de datos son como moléculas. Para cualquier nuevo programador, 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 arreglos atómicos más extraños que pudieran permitir diferentes tipos de aplicaciones.
Describe el documento de Shapiro como “un despertar”. En CRDTs, Kleppmann vio la base técnica para una nueva clase de software que nadie estaba proporcionando. 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 usan para crear aplicaciones. Kleppmann se dio cuenta de que tendría que facilitar la vida de los desarrolladores de local-first, guiando la idea desde un conjunto de pruebas matemáticas hasta un código listo para producción. Se puso a codificar una implementación de código abierto de CRDTs, que llamó Automerge, que las personas podían usar libremente para crear aplicaciones.
Vi el fruto de este esfuerzo unos años después, poco después de que el manifiesto local-first se hiciera conocido en Hacker News. Conocí a Peter van Hardenberg, uno de los coautores de Kleppmann, en un café en San Francisco. Él estaba, al igual que Kleppmann, reiniciando después de un largo viaje a través de la nube, primero como parte del equipo fundador de Heroku, que ayudaba a otras startups 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 tablón de anuncios digital.
Van Hardenberg abrió 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 perfectamente; otras veces los cambios dejaban de cargarse, o los píxeles se arrastraban con una latencia propia de la era de la conexión telefónica. Pushpin parecía un juguete, el tipo de aplicación que un par de brillantes estudiantes de Stanford podrían programar en la sala común con visiones de una ronda de financiación inicial y luego guardar en el olvido por vergüenza.
Pero van Hardenberg estaba lejos de estar avergonzado. Se estaba sentando las bases técnicas, creía él, para versiones local-first de Slack, Discord, Google Docs, Photoshop. Mejores aplicaciones de diseño, calendarios, presupuestos. Programas más complejos también, si se podía hacer que Automerge fuera mucho más eficiente. Existía la posibilidad de encriptación privada de extremo a extremo para todas estas aplicaciones colaborativas, ya que no habría un servidor en el camino. Existían límites técnicos para CRDTs y muchas aplicaciones que la nube serviría mucho mejor. Pero para él, el prototipo se sentía como una revolución. No había un servidor entre nosotros. Sin embargo, funcionaba. Mayormente. Éramos dos pares comunicándose, como los primeros albañiles de internet lo habían concebido.
La visión de van Hardenberg fue más fácil de ver cuando nos encontramos nuevamente en St. Louis. Los gigantes tecnológicos se estaban deslizando. Las acciones de Meta estaban en su nivel más bajo en siete años. Twitter estaba en medio de una toma de control hostil por parte de Elon Musk. Kleppmann pasaba algunas horas cada semana como asesor técnico de Bluesky, surgido de Twitter como un experimento descentralizado y de repente lanzado a la luz pública, listo para convertirse en su competidor. Su diseño “federado” prometía dar a las personas la opción de abandonar los servidores y servicios que los trataban mal. Bluesky no estaba utilizando CRDTs, que serían demasiado lentos para coordinar las actualizaciones de millones de usuarios en redes sociales, pero el objetivo era similar: una mejor relación con “la computadora de otra persona”. Las alternativas informáticas volvían a estar de moda.
Entre ellas, CRDTs. Strange Loop estaba repleto de presentaciones sobre local-first, una sorpresa para Kleppmann y van Hardenberg, quienes hasta hace poco se enteraban de cada proyecto a través de Google Alerts y de boca en boca. CRDTs también estaban apareciendo en el mundo en general. Los desarrolladores de The Washington Post los habían utilizado para construir una herramienta para organizar artículos en la página de inicio. Las personas que investigaban el código que ejecuta la aplicación Notas de Apple habían notado CRDTs. Jupyter Notebooks, una popular aplicación de ciencia de datos, restauró sus herramientas de colaboración utilizando CRDTs después de que Google eliminara el servicio en la nube en el que dependía anteriormente.
Entre los presentadores en Strange Loop se encontraba una desarrolladora canadiense llamada Brooklyn Zelenka, cofundadora de una empresa llamada Fission. Cuando leyó el manifiesto de “local-first”, recuerda: “Fue como, esta es una gran frase. Antes de eso, teníamos estas 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 encontró su cultura “agresiva”, lo cual atribuyó al enfoque en el dinero “tan claramente, todo el tiempo”. Fue agradable entrar temprano en el concepto de local-first. “Todo es de bajo colgado ahora”, me dijo Zelenka.
La suya era una trayectoria común. Crypto “sacó a relucir a las peores personas”, me dijo van Hardenberg durante el almuerzo en la conferencia, pero también habló de muchos de los mismos principios que local-first. En su opinión, simplemente usa el enfoque equivocado, prometiendo a los usuarios descentralización e independencia pero atándolos a incentivos financieros especulativos. También es lo opuesto a la filosofía de offline-first: las engorrosas blockchains, controladas por quien acumula más recursos, median cada interacción. Aun así, crypto ofreció una lección sobre cómo la emoción puede impulsar la creación de nuevos productos. Van Hardenberg señaló la gran cantidad de programadores aburridos y descontentos en compañías como Meta y Google que saltaron del barco en el apogeo de la burbuja de las criptomonedas.
Van Hardenberg pensaba que local-first eventualmente podría generar la misma emoción, pero con un software que realmente fuera 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 de local-first y ayudara a atraer más talento y recursos. El crecimiento también daba miedo. Van Hardenberg y Kleppmann hasta ahora habían evitado el financiamiento de capital de riesgo para Automerge en sí, temiendo que los obligaría a adoptar cualquier variedad de modelos de negocio que “totalmente van en contra de los valores de local-first”, como me dijo Kleppmann. Pero en algún momento, se dieron cuenta de que el crecimiento también sería necesario. Esperaban que el software pudiera hablar por sí mismo. “A los inversores de capital de riesgo les encanta una replataforma”, dijo van Hardenberg.
Unos meses después de la conferencia, “local first” volvió a ser tendencia en Hacker News. Un comentario llamó a los CRDTs la espada “matadragones” que permitiría a las aplicaciones de local-first competir con la nube. Otro lamentó que cada publicación técnica interesante sobre CRDTs se convirtiera en una “extraña discusión política sobre la descentralización”.
A pesar de los muchos movimientos hacia la descentralización tecnológica, la acumulación de oro del dragón ha seguido creciendo. Un problema es la percepción de que los principios van en detrimento de la comodidad. Tan satisfactorio y virtuoso como puede ser hacer tu propia mesa de café, también es difícil. Eventualmente te cansas y compras tu siguiente mueble en Amazon. Lo mismo ocurre con la gestión de tus 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 usar internet moderno mientras se adhiere a sus principios, me dijo que simplemente se abstiene de la tecnología tanto como puede. “Es una terrible pérdida de tiempo”, me dijo.
Me preguntaba si el término “local first” molestaba a Shapiro en absoluto, si lo consideraba un rebranding no deseado de su creación técnica. Me sorprendió cuando me dijo que le encantaba. Pensaba que había magia en la frase. Tal vez la revolución tiene que ser un poco sigilosa para asestar un golpe: atraer a los desarrolladores con las posibilidades técnicas, llamarlo un “movimiento” para atraer a periodistas obsesionados con la política (hola). Tal vez también necesita llegar en el momento adecuado, cuando las plataformas de Big Tech parezcan listas para derrumbarse, revelando las características perdidas y los abusos sufridos a cambio de conveniencia.
Kleppmann no estaba exigiendo un retorno a lo análogo o destrozar todos los servidores en la nube, que hacen muchas cosas útiles. La espada no era un asesino, sino una herramienta para tallar algo mejor, y él mismo diría que aún 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 expresión habitual de calma y atención se transformó brevemente en alarma. Por supuesto, teóricamente 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.
Déjanos saber qué piensas sobre este artículo. Envía una carta al editor a [email protected].
