Más allá de Bitcoin: colaboración descentralizada.

https://twitter.com/kanzure/status/1043432684591230976

http://sit.fyi/

Hola a todos. Hoy voy a hablar de algo diferente a lo habitual. Voy a hablar más sobre cómo podemos computar y cómo colaboramos. Empezaré con una introducción a la historia de cómo sucedieron las cosas y por qué son como son hoy. Muchos de ustedes probablemente utilizan aplicaciones SaaS en la nube. A menudo se promociona como algo nuevo, algo que ha sucedido en los últimos 10-15 años. Si miramos la historia, toda esta idea de las nubes no es nueva en absoluto. Comenzó en los años 60 con los mainframes. Los ordenadores eran caros de mantener y muy pocas organizaciones podían permitírselo. Les resultaba muy cómodo pagar a alguien para que accediera a las aplicaciones y para que alojara los costosos ordenadores, y utilizar dispositivos baratos para ello. En su día, sólo tenían monitores y teclados conectados al mainframe. Este modelo ha existido durante todo el tiempo de la informática en el ámbito empresarial. Existió a lo largo de los años 60, 70 y 80, y poco a poco se está transformando en otra cosa a medida que los ordenadores son más baratos. Como las organizaciones podían permitirse comprar muchos ordenadores y servidores para su organización, la ventaja era el software, y empezaron a vender software que funciona en intranets.

El problema con el software de intranet era que la complejidad de la gestión de estas aplicaciones era realmente alta. Muchas organizaciones acabaron teniendo su propio personal de TI. Necesitaban centros de soporte internos sólo para operar esto y formar a la gente y gestionar los dispositivos y tener soporte al cliente. Esto ayudó a crear una cosa moderna llamada centro de costes que se alejó de los consumidores de esas aplicaciones y las aplicaciones se pusieron en Internet para que las organizaciones no tuvieran que hacer eso por su cuenta.

Todavía hoy, desde los años 60, nuestras aplicaciones se parecen a esto: bastidores de servidores que ejecutan aplicaciones, y accedemos a ellos con dispositivos que son mucho más inteligentes, pero que siguen actuando como terminales de aplicaciones que se ejecutan en otros lugares. Así que lo que la nube ofrece hoy en día es, obviamente, el bajo costo, donde no tienes que pagar por el software por adelantado, y reduce el opex de la ejecución de los servidores; es conveniente, y es la convención y estás siguiendo el rebaño. Es difícil que te despidan por algo que todo el mundo hace.

Pero el problema es que la nube es como el software fiat. Está fuera de control de sus propios consumidores. ¿Cuántas personas aquí han utilizado la bandeja de entrada de gmail? ¿Alguien? Bien. Se está cerrando. Era una plataforma experimental de Google. No puedes elegir si puedes o no utilizarla. ¿Quizás los usuarios de Google Wave recuerdan esa aplicación? Gmail Inbox no es el único ejemplo. Hay montones de ejemplos en los que las aplicaciones se cerraron sin más. La funcionalidad de esas aplicaciones no depende de ti. Si el proveedor decide que cierta funcionalidad ya no es rentable o no le interesa, no tienes suerte y lo tomas o lo dejas y así será para ti.

El otro aspecto es que, al poner esos datos en otro lugar fuera de su propio dominio, tenemos ese tipo de relación institucional entre nosotros y los consumidores que son usuarios de esas aplicaciones, y los vendedores. Es un feudalismo. Ellos tienen las propiedades y las instalaciones para gestionar tus datos, pero tú no tienes los programas, no eres dueño de los programas que te permiten utilizar esos datos. Los datos en bruto no son muy procesables, pero lo que los convierte en información es el código que puede procesar esos datos.

Con la configuración que tenemos hasta ahora, renunciamos a nuestra capacidad de controlar los datos y utilizarlos y obtener los frutos de los mismos. Es un asunto complicado. Aunque creamos que el proveedor que utilizamos es benévolo y que todo irá bien, seguimos dependiendo de muchos factores. Uno de los factores es el hecho de que estemos utilizando Internet.

"En línea" es una ilusión óptica. Realmente depende de la distancia, por lo que la velocidad de la luz es obviamente un problema. Si Elon Musk llega a poner una colonia en Marte, el tiempo medio de la señal viajando sólo desde la Tierra a Marte será de unos 14-40 minutos. Eso definitivamente impide que tengamos cualquier tipo de relación en línea entre nosotros y esa colonia. Pero ni siquiera es necesario ir tan lejos como Marte: la distancia no siempre es el factor. El factor puede ser el coste, o la complejidad de conseguir la conectividad a un determinado lugar.

Imagina un escenario como el de un buque de carga en la industria. Tienen barcos en el mar, y es prohibitivo estar en línea todo el tiempo. Tienen que confiar en herramientas que les permitan colaborar en modo batch. Hasta el día de hoy, la mayoría de las cosas que se hacen se hacen por correo electrónico en texto plano, por lotes en el correo electrónico, envían lo que tienen cuando consiguen una conexión. Y de esta manera, pueden controlar el coste de la conectividad. Sin embargo, esto no es especialmente eficiente, y el correo electrónico no es la herramienta más eficaz para gestionar información estructurada. Así que a veces la gente envía documentos y hojas de cálculo de Excel y necesitan trabajar con todas las versiones y demás.

Otro aspecto es la propuesta que el término "nube" significa para nosotros. Pensamos en la "nube" como algo esponjoso y agradable, pero en realidad es más bien una oscura tormenta. Estamos compitiendo por diferentes recursos con otros consumidores de esos productos, como el ancho de banda y los recursos informáticos que nos ofrece el proveedor concreto. Así que nos encontramos en una situación de atasco. Para nosotros, no solemos notarlo. Pero la realidad es que el vendedor, el proveedor de ese servicio, tiene que asumir ese coste. Tienen que ser capaces de escalar sus aplicaciones para poder servir a todos sus clientes. Si te imaginas una aplicación como Slack, si necesitas algo así para tu propia organización, de 10 a 10.000 personas, no es una aplicación muy compleja de escalar -puede que necesites 1 o 2 servidores y estará bien. Pero si se trata de Slack, es un problema desafiante que requiere ingenieros que trabajen en esto y lo mantengan y tengan infraestructura. Y seguirás teniendo tiempo de inactividad porque es difícil conseguir algo cercano al 100% de tiempo de actividad. Esto hace que el coste sea mucho mayor de lo que podría haber sido.

En resumen, son tres preocupaciones de la nube: el control, la conectividad y la complejidad. Me gusta pensar en la "computación del desierto", donde los recursos son mínimos y hay que sobrevivir por cuenta propia. ¿Alguien ha leído el libro de Cory Doctorow? A menudo tengo el problema de que mi prometida vive en la otra punta del planeta, así que tengo muchos vuelos de larga duración de más de 10 horas. Ni siquiera puedo programar o triar problemas en mi proyecto mientras estoy en el vuelo. Tengo que descargar algunos de ellos, pensar en ello, y el ncopy todo de nuevo después de que el vuelo ha terminado. Hablo con mucha gente y algunos de ellos simplemente copian y pegan su trabajo en el vuelo. Pero, ¿por qué lo hacemos de esta manera? ¿Por qué tenemos temas de github o jira y no podemos usarlo fuera de línea? ¿Por qué se hace así? ¿Es esto un requisito real para tener un tercero en nuestras conversaciones que estamos teniendo?

Así que me puse a resolver este reto. Se me ocurrió un enfoque muy sencillo. ¿Qué pasaría si simplemente registráramos cada intento y cada cambio que realizamos en esos procesos de colaboración? ¿Y si creamos una nueva incidencia en este contexto y la colocamos en un repositorio git como han hecho BugsEverywhere y otros gestores de incidencias distribuidos? ¿Podemos registrar lo que queríamos hacer? ¿Podemos luego reproducirlo cuando tengamos conectividad? Aquí está el SIT Issue Tracker. Podemos registrar estas acciones como archivos. Podemos capturar la intención y los datos asociados a una intención, y anotarlos. El issue tracker que puedes ver aquí es la interfaz web y el aspecto que tiene actualmente. Me permitió trabajar en mis problemas en vuelo o en cualquier momento. Lo interesante de esto es que, como funcionaba con archivos, no tienes que tener conectividad de red nunca. Puedes escribir todos los archivos nuevos en una unidad flash y pasársela a otra persona que quiera trabajar en ella, y luego volver a ella más tarde y reintegrar esos archivos con lo que estás trabajando. Esto significa que esto podría funcionar en la Tierra, con barcos en el mar, y puede funcionar con Marte, siempre y cuando podamos transferir archivos como por radio o unidades flash o conectividad de red.

Te da algunas características adicionales interesantes. ¿Cuántos de ustedes son desarrolladores de software? Bastante. Esto también le permite llevar sus parches dentro de este sistema y le permite poner esta información las cuestiones dentro de su repositorio. Cada vez que clonas tu proyecto, puedes recibirlo cada vez. Sólo se basa en archivos regulares. Hasta ahora ha funcionado muy bien. Se ha utilizado para algunos proyectos. Pero luego me di cuenta de que hay muchas más cosas que quiero hacer con él; me gusta la simplicidad del enfoque.

También quiero llevar la contabilidad y la facturación, los informes de gastos y otras informaciones de la misma manera, donde puedo capturar los archivos y derivar los informes en un momento posterior. Quiero poder asegurarme de que la información se registra allí y se comprueba su integridad cada vez que uso los archivos. Hice la transición de un rastreador de problemas a un rastreador de información. Puede trabajar en cualquier intención, con cualquier dato que esté asociado a esa intención, y registrar un orden de los cambios que ocurren en esos archivos y su información.

En cierto modo, ya sabes cómo.. hay muchos proyectos en los que la gente quiere poner algo en la blockchain y quieren registrar el orden de ese evento. Generalmente les aconsejo no hacer esto, como por el costo, o la cantidad de datos que quieren poner. En su lugar, lo que recomiendo hacer ahora, es utilizar algo como este rastreador de problemas donde pueden registrar su información en archivos que están vinculados entre sí que están utilizando las mismas primitivas donde el hash de la información está realmente vinculado a los datos anteriores en el sistema. Sólo después de eso podrían básicamente anclar esa información en cualquier otro sistema de blockchain, como el uso de la envoltura de commit git de opentimestamp que puede marcar el tiempo de tus commits git.

La forma en que definí esta aplicación es que, básicamente, permite la descentralización y, lo que es más importante, permite que las partes conectadas de forma espontánea colaboren y compartan piezas de información en las que quieran trabajar juntas.

El otro aspecto importante del desarrollo de este tipo de aplicaciones es que hay muchas convenciones que hay que reconsiderar. Hay una noción de inicio de sesión en los sistemas que establece una relación institucional: tienes una cuenta con el proveedor. Cuando colaboramos con la gente, no nos autentificamos ni nos identificamos. En un mundo digital, eso es como el PGP u otros tipos de firmas que identifican que esto viene de mí. Pero si tu aplicación se ejecuta en tu ordenador, no necesitas iniciar sesión en otra cosa que no sea tu ordenador. No te conectas al sistema de alguien diciendo que esta es mi cuenta o mi contraseña o cualquier otra forma de acceder a él; esto nos permite construir sistemas que operan con la potencia de cálculo que está disponible en los bordes de la red donde tenemos una enorme cantidad de potencia de cálculo ya disponible. Esto es muy diferente de los sistemas que hemos heredado de los años 60, donde los ordenadores eran grandes y caros. Pero ahora no lo son. Esto nos permite repensar cómo construimos las aplicaciones en su conjunto.

La otra pregunta es, obviamente, si vale la pena el esfuerzo. Es complejo y requiere cambiar la forma en que diseñamos las aplicaciones y cómo pensamos en ellas. Ahora mismo es difícil ver por qué es tan útil. Pero si empezamos a recopilar las informaciones que escuchamos de diferentes fuentes de noticias, como las violaciones de datos, los avances en el otro extremo, con incluso los viajes espaciales, merece la pena invertir tiempo en esto, donde puede que no seamos capaces de obtener beneficios sustanciales en 5-10 años, pero en 10-30 años, seremos capaces de controlar nuestra información y controlar el software que la procesa, y eso merece la pena dedicar esfuerzos a este tipo de proyectos.