El día que la web se anunció en un foro y casi nadie contestó

Hoy, 6 de agosto, se cumplen años de la publicación más consecuente de la historia de internet. Fue un mensaje en un foro.

El 6 de agosto de 1991, Tim Berners-Lee escribió en el grupo de noticias alt.hypertext, un rincón de Usenet para entusiastas del hipertexto. El mensaje empezaba con una frase que hoy se lee como un titular y entonces se leyó como un proyecto más:

«El proyecto WorldWideWeb (WWW) pretende permitir que se puedan crear enlaces a cualquier información en cualquier sitio.»

Y a continuación, lo importante: dónde descargarlo. El navegador-editor para NeXT, el navegador de línea de comandos, el servidor básico «para cualquier máquina». Todo, gratis, con instrucciones.

El NeXT del CERN que sirvió la primera web, con el aviso pegado a mano: «This machine is a server. DO NOT POWER IT DOWN!!». Foto: Coolcaesar, CC BY-SA 3.0; imagen recortada y disponible bajo la misma licencia.

Cuidado con la fecha: hay tres y no son la misma

Esto es de las cosas que se citan mal a menudo, así que conviene separarlas:

• Marzo de 1989. Berners-Lee entrega a su jefe en el CERN una propuesta de gestión de la información. Mike Sendall la devuelve con una anotación a mano en la portada: «Vague but exciting». Vaga pero interesante. Es probablemente la reseña de código más generosa jamás escrita.
• Diciembre de 1990. El primer sitio web existe y funciona, en su estación NeXT del CERN. Hay servidor, hay navegador y hay una página. Lo que no hay es nadie fuera.
• 6 de agosto de 1991. El proyecto sale del edificio. Es el día en que alguien ajeno al CERN puede bajarse el software y montar el suyo.

Para lo que quiero contar hoy, la fecha que importa es la tercera: no la de la propuesta ni la del primer sitio funcionando, sino la del día en que aquello salió del edificio. Es una manera de mirarlo, no una datación histórica —la web «nace» en 1989, en 1990 o en 1991 según qué se esté midiendo—, pero es la distinción que también existe en tu trabajo.

La acogida fue más tibia de lo que suele contarse

Aquí está la parte que más me gusta de esta historia, y es la menos contada.

En 1991 el hipertexto era un campo académico serio, con congresos y décadas de investigación detrás. La web no llegó a esa comunidad como una revelación: el mensaje de Usenet tuvo una repercusión modesta y, en los años siguientes, parte de ese ámbito recibió el sistema con reservas —no toda: hubo también quien lo adoptó pronto y quien colaboró—. Las objeciones que se le hicieron eran técnicamente correctas:

• Los enlaces eran unidireccionales: la página de destino no sabe quién la enlaza.
• No había integridad referencial: si el destino desaparece, el enlace se queda apuntando al vacío. Un enlace roto. Un 404.
• No había base de datos, ni control de versiones, ni gestión de derechos, ni ninguna de las cosas que los sistemas de hipertexto de la época sí tenían.

Todo cierto. Y aquí está lo interesante: cada una de esas carencias es también lo que permitió que la web creciera. Un enlace que no necesita permiso del destino se puede crear sin coordinarse con nadie. No hay que negociar, ni registrarse, ni pedir que el otro extremo instale nada.

Lo que no significa que aquellas críticas fueran ociosas. Los enlaces rotos, la falta de integridad referencial y la ausencia de versionado se convirtieron en problemas reales y siguen sin resolverse bien treinta y cinco años después: la mitad de las notas al pie de internet apuntan hoy al vacío. Aquella comunidad no se equivocaba en el diagnóstico; se equivocaba al pensar que un sistema con esos defectos no podía imponerse.

Los sistemas rigurosos exigían que las dos partes participaran. La web solo exigía que una parte se lanzara. Por eso ganó.

Lo que esto significa el lunes por la mañana

No es una anécdota de museo. Es una decisión de diseño que se repite en cada proyecto, casi siempre disfrazada de otra cosa:

• El sistema que solo funciona si todos los departamentos rellenan bien su parte.
• La integración que exige que el proveedor cambie su formato antes de poder empezar.
• El gestor documental impecable que nadie usa porque subir un archivo son once campos obligatorios.
• La convención de nombrado que sería perfecta si la siguiera el equipo entero.

Todos esos diseños tienen razón. Y todos pierden contra la alternativa fea que un solo equipo puede adoptar el martes sin pedirle nada a nadie.

La pregunta útil al diseñar algo no es «¿qué garantías ofrece?», sino «¿cuánta cooperación ajena necesita para dar el primer valor?». Cada persona que tiene que decir que sí antes de que la cosa sirva es una probabilidad más de que no llegue a servir.

Publicar es la funcionalidad

El mensaje de aquel 6 de agosto no era un anuncio de marketing: era una URL, un README implícito y una invitación a trastear. Berners-Lee no pidió permiso, no montó una beta cerrada y no esperó a la versión 2.0 con integridad referencial.

Y lo que puso encima de la mesa no fue solo el código. Fue el código más la especificación más la documentación, de forma que cualquiera pudiera escribir su propio servidor sin hablar con él. Esa es la diferencia entre soltar un repositorio y publicar un estándar, y es la razón por la que treinta años después seguimos poniéndonos de acuerdo en cosas tan tontas como en cuántos bytes ocupa una carita.

Si tienes algo a medias que ya resuelve un problema real y llevas tres meses sin sacarlo porque le falta el panel de administración: el panel de administración no es lo que impide que se use. Lo que impide que se use es que está en tu rama.

Nadie aplaude el primer día

Aquel mensaje no fue una noticia. No hubo titulares. Hubo unas cuantas respuestas educadas, alguna pregunta técnica y bastante escepticismo cortés.

Merece la pena tenerlo presente cuando publicas algo y no pasa nada. La reacción del primer día no mide la importancia de lo que has hecho; mide cuánta gente estaba mirando ese día. Son cosas distintas y solo una de las dos depende de ti.

Este blog empezó con su propio hola mundo, que también fue leído por aproximadamente nadie. Así empiezan casi todos.

Feliz aniversario

Tres cosas que puedes hacer hoy, en orden de dificultad creciente:

1. Publica la cosa a medias. Ese script, ese documento, esa plantilla. En un sitio donde alguien más pueda encontrarlo sin preguntarte.
2. Cuenta cuántos síes ajenos necesita tu proyecto actual antes de dar valor a alguien. Si el número pasa de dos, tienes un problema de diseño, no de gestión.
3. Escribe la documentación como si el lector no pudiera preguntarte nunca. Es la prueba real de si has publicado algo o solo lo has enseñado.

(Y si alguien te devuelve una propuesta con un «vago pero interesante» escrito a mano en la portada, no lo tires: guárdalo, que hay quien acaba enmarcándolo.)