Project Xanadu: por qué 50 años de visión no bastaron

Lo que Gwern descubrió en una fiesta de San Francisco

En diciembre de 2024, durante una visita a San Francisco, el investigador y escritor Gwern Branwen fue invitado a una celebración atípica: el 50º aniversario de Computer Lib/Dream Machines, el manifiesto de 1974 de Ted Nelson que articuló la visión de Project Xanadu. A esa fiesta, según cuenta en su retrospectiva publicada en gwern.net, también asistió uno de los programadores que trabajaron en Xanadu durante la etapa de Autodesk, entre 1988 y 1993. Lo que Gwern esperaba como curiosidad nostálgica se transformó en una epifanía sobre cómo los grandes proyectos de software fracasan.

Por qué Xanadu no pudo despegar en cinco décadas

Project Xanadu arrancó en la década de 1960 con una premisa ambiciosa: reimaginar el documento digital con transclusión (incrustar fragmentos exactos de otros textos en un documento), enlaces bidireccionales y un sistema de micropagos integrado para rastrear el uso de cada fragmento. Nelson lo imaginó como la alternativa humanista al caos que vendría después con la World Wide Web.

Gwern identificó tres bloqueos que se repitieron durante décadas:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Limitaciones de hardware brutales. Compilar el sistema tomaba cerca de una semana. Un disco duro de gama media de 1990 rondaba los 50 MB, una fracción del peso de un solo PDF que Gwern aloja hoy. La transclusión a nivel de byte era inviable cuando editar texto ya era una heroicidad técnica.
Ausencia de iteración de diseño. El equipo pasaba años puliendo una arquitectura conceptual antes de prototipar un caso de uso real con usuarios. Cuando finalmente se podía ejecutar, el demo era confuso y nadie sabía qué hacer con él.
Una solución en busca de problema. Los ejemplos públicos de Xanadu —el Libro del Génesis con comentarios zigzagueando en pantalla, la Declaración de Derechos de Virginia comparada con la Carta de Derechos de EEUU— funcionaban como espectáculo, pero no representaban el 99,9% del trabajo editorial cotidiano.

Gwern lo resume con una frase dura: "el concepto entero de transclusión de rangos lado a lado es una solución en busca de un problema". Casi ningún texto del mundo necesita ser diseccionado línea por línea; la mayoría de las referencias son al documento completo, no a un fragmento de bytes 123–456 que cambia cada vez que editas.

El demo "completamente ilegible" y la lección oculta

El momento de quiebre para Gwern ocurrió frente a una pantalla mostrando la demo clásica de Xanadu: el Génesis con líneas zigzagueando hacia la derecha para denotar transclusiones. Las líneas se cruzaban, los comentarios quedaban apretados en pantallas pequeñas y, en muchas posiciones de scroll, simplemente no podías leer nada.

"Era completamente ilegible", escribió. "¿Cómo pudo parecer buena idea una interfaz donde a menudo no podías leer nada?". La conclusión que extrajo no es que el equipo fuera malo —escuchó historias de primera mano y entendió las restricciones—, sino que la premisa original estaba mal: la lectura no es una operación horizontal y lado a lado, sino vertical, con la posibilidad de hacer zoom entre niveles de abstracción (título → resumen → sección → párrafo).

Gwern también cuestiona los famosos 17 Principios de Xanadu, que dedican más espacio a temas como micropagos por transclusión, identificación de servidores y mecanismos de regalías granulares que a explicar qué problema resuelven. Los describe como ideas que solo tienen sentido si nunca se prueban en el mundo real, donde aparecerían problemas de derechos de autor, spam y abuso que volverían el sistema inviable.

Cómo Gwern.net resolvió lo que Xanadu no pudo

La mejor respuesta de Gwern al problema no fue escribir otro manifiesto: fue construir Gwern.net, un sitio personal que implementa exactamente lo que Xanadu prometía pero sin la carga conceptual. Según su propia página de diseño, el sitio se rige por cuatro principios: minimalismo estético, accesibilidad y mejora progresiva, velocidad y zoom semántico (ocultar profundidad, mostrar bajo demanda).

Las decisiones técnicas concretas son accionables para cualquier founder:

Popups en lugar de transclusión lado a lado. Al pasar el ratón sobre un enlace, se despliega un extracto con anotación. Es transclusión, pero vertical y dentro de un popup, no horizontal en márgenes.
Enlaces bidireccionales reales. Cada enlace tiene un ID único, lo que permite mostrar contexto exacto de dónde se cita. Gwern procesa estos backlinks como un trabajo cron nocturno, no en tiempo real, y los muestra colapsados al final de cada sección.
Colapsado por defecto. El sitio se lee como un iceberg: corto en superficie, profundo bajo demanda. Secciones enteras se pliegan con un clic.
Archivos locales contra el linkrot. Cada enlace importante se espeja en un archivo local, así el sitio sobrevive décadas aunque las fuentes externas desaparezcan.
Esperar varios casos de uso antes de implementar una feature. Gwern y su colaborador Said Achmiz solo añaden funcionalidades cuando hay al menos tres situaciones reales que las justifiquen.

El contraste es revelador: Gwern.net tiene 50 años menos que Xanadu, pero su visión de qué necesita un lector (resúmenes, navegación sin fricción, citas verificables) está informada por observación directa, no por una idea visionaria de cómo debería funcionar el hipertexto.

Qué significa esto para tu startup

Hay tres lecciones que sobreviven al caso Xanadu y aplican a cualquier producto digital:

1. Los manifiestos no escalan; los prototipos sí. Ted Nelson tenía razón en algunas intuiciones —los enlaces bidireccionales existen hoy en Gwern.net, Facebook y Hacker News; la preocupación por el linkrot anticipó Archive.org—, pero su método de llegar allí (definir 17 principios teóricos antes de probar nada) garantizó el fracaso. Para founders: cada nueva feature debería responder a una pregunta concreta de un usuario real, no a una visión abstracta del futuro.

2. La UI es el producto. El demo de Xanadu era confuso y feo de usar. Aunque la arquitectura subyacente fuera brillante, nadie iba a adoptarla. Gwern describe la UI de Xanadu como una "interfaz de ciencia ficción" estilo Minority Report: impresionante en una demo, insufrible en el día 30. Antes de invertir años en backend, mockea el flujo principal con papel y tijeras y verifica que alguien externo pueda usarlo sin tu ayuda.

3. La mejor versión de tu visión es la que el usuario ya sabe pedir. Gwern no necesitaba transclusión de rangos. Necesitaba popups, abstracts y backlinks. Las tres cosas resuelven el 95% del problema y se pueden construir con HTML y JavaScript básico, como él mismo demuestra en su sitio desde 2017.

Acciones concretas para founders esta semana

Audita tu roadmap en busca de features con cero casos de uso reales. Si llevas más de un trimestre planificando algo sin haberlo prototipado con un usuario, replantéatelo. Copia el patrón de Gwern: no implementes hasta tener tres situaciones concretas donde la feature sea necesaria.
Mide la legibilidad de tus pantallas críticas. Abre tu producto en un monitor 4K y en un móvil de gama baja. ¿Cuántas posiciones de scroll dejan algo ilegible? Si la respuesta es más de una, tienes el mismo problema que el Génesis de Xanadu.
Implementa backlinks bidireccionales o al menos popups de anotación. No necesitas una arquitectura de enfilades ni encriptación cuántica. Con un campo de anotación por enlace y un popup HTML al hover, ganas el 80% del valor que Xanadu prometía. Es la diferencia entre una idea visionaria y un producto usable.