☰ Menu

06.10.2026 · Signal Titans Editorial

La palabra “wiki” vino de un autobús del aeropuerto. Ward Cunningham la convirtió en una nueva forma de escribir.

Ward Cunningham junto al Wiki Wiki Shuttle y una representación de una página editable de WikiWikiWeb.

La palabra “wiki” entró en la informática porque Ward Cunningham tomó una vez un autobús lanzadera en el aeropuerto de Honolulu.

El autobús se llamaba Wiki Wiki Shuttle.

“Wiki” significaba rápido.

La palabra se quedó en la cabeza de Cunningham.

Años después, cuando construyó un nuevo tipo de sitio colaborativo, podría haberlo llamado algo dolorosamente literal como QuickWeb.

En su lugar lo llamó WikiWikiWeb.

Una palabra extraña escuchada en un aeropuerto terminó dando nombre a una forma completa de escribir juntos en Internet.

La Web se había vuelto más fácil de leer que de escribir

La visión temprana de la Web era colaborativa.

Las personas no solo leerían documentos.

También los crearían, enlazarían y mejorarían.

Pero a medida que los navegadores se extendían, publicar una página seguía teniendo mucha más fricción que leerla.

Hacían falta archivos, HTML, acceso al servidor y cierta comprensión de cómo estaba organizado el sitio.

Cunningham trabajaba con comunidades de programadores que querían compartir patrones de diseño de software: descripciones prácticas de problemas recurrentes y sus soluciones.

El conocimiento era colectivo.

El proceso de publicación no.

Quería que editar fuera casi accidental

Cunningham había experimentado con sistemas de información enlazada antes de la Web, incluido HyperCard.

A mediados de los noventa gestionaba el Portland Pattern Repository, un lugar donde programadores compartían ideas sobre patrones, proyectos y personas.

Su pregunta era sencilla:

¿Y si los visitantes pudieran cambiar la página ellos mismos?

Sin workflow de publicación separado.

Sin enviar la corrección a un administrador.

Sin esperar a que otra persona actualizara el documento.

Abrir la página.

Editar.

Guardar.

La barrera entre lector y autor casi desaparecía.

El 25 de marzo de 1995, WikiWikiWeb salió en vivo

El primer WikiWikiWeb apareció en c2.com como parte del Portland Pattern Repository.

Su diseño era deliberadamente simple.

Las páginas podían editarse desde el navegador.

Nuevas páginas podían crearse rápidamente.

Ciertos nombres de página podían convertirse automáticamente en enlaces.

Recent Changes permitía ver qué había modificado la comunidad.

El sistema no necesitaba una jerarquía compleja diseñada desde el principio.

La estructura podía emerger mientras la gente escribía y enlazaba ideas.

Ese era el cambio importante.

El sitio dejaba de ser una publicación terminada.

Se convertía en un espacio de trabajo compartido.

El nombre hablaba de velocidad, no de conocimiento

Cunningham aprendió la palabra “wiki” durante un viaje a Hawái.

En el aeropuerto de Honolulu lo dirigieron al Wiki Wiki Shuttle.

La frase le llamó la atención porque era memorable y capturaba exactamente cómo quería que se sintiera el software.

Rápido.

Inmediato.

Con poca fricción.

Le gustaba la aliteración de WikiWikiWeb con World Wide Web.

El script Unix se llamaba simplemente wiki.

Con el tiempo, el nombre corto se convirtió en la palabra genérica.

Millones de personas conocen hoy “wiki” sin conocer el autobús que llevó la palabra a la informática.

La verdadera innovación fue reducir el coste de contribuir

Un sistema de publicación tradicional pregunta:

¿Quién tiene permiso para cambiar esta página?

Un wiki pregunta algo diferente:

¿Con qué rapidez puede una mejora útil convertirse en parte de la página?

Eso no significa que todos los wikis deban ser totalmente abiertos o anónimos.

Los sistemas modernos añaden permisos, moderación, historial y revisión según las necesidades de cada comunidad.

Pero Cunningham cambió la suposición por defecto.

Editar dejó de ser un evento administrativo especial.

Editar pasó a formar parte de leer.

Por eso los wikis cambiaron mucho más que las enciclopedias

Wikipedia se convirtió después en el uso más famoso de la idea.

Pero los wikis se extendieron por equipos de software, organizaciones de ingeniería, documentación, bases de conocimiento internas, comunidades de fans y grupos de proyectos.

El patrón es especialmente poderoso donde el conocimiento cambia continuamente.

Un documento estático empieza a envejecer en el momento en que se publica.

Una página compartida y editable puede cambiar con el trabajo.

Eso hace que un wiki se parezca menos a un libro y más a una memoria colectiva.

La colaboración suele fallar porque contribuir es demasiado caro

Las organizaciones dicen que quieren compartir conocimiento.

Después colocan cinco pasos entre detectar un problema y arreglar la documentación.

Abrir ticket.

Encontrar al owner.

Pedir acceso.

Esperar revisión.

Esperar publicación.

Para entonces, quien detectó el problema ya está en otra cosa.

El wiki de Cunningham hizo otra apuesta:

Si la persona útil ya está al lado del conocimiento, deja que lo mejore mientras todavía le importa.

El mismo principio sigue vivo en productos modernos

Las mejores herramientas colaborativas acortan la distancia entre notar algo y contribuir.

GitHub permite convertir una corrección de documentación en un pull request.

Google Docs normalizó comentarios y edición en vivo.

Notion y herramientas similares permiten reorganizar conocimiento sin llamar a un webmaster.

Las interfaces cambian.

El principio sigue cerca de WikiWikiWeb:

Haz que contribuir sea tan barato que la gente realmente lo haga.

A veces la función no es el contenido. Es el permiso para cambiarlo.

Ward Cunningham no inventó el conocimiento colaborativo.

Los humanos llevan milenios construyéndolo juntos.

Lo que cambió fue la fricción de hacerlo en la Web.

Un lector podía convertirse en autor en segundos.

Una página podía generar otra con un enlace.

Una comunidad podía construir estructura mientras usaba el sistema en vez de diseñarla toda de antemano.

Y una palabra extraña recordada de un shuttle del aeropuerto se convirtió en la etiqueta de todo el patrón.

¿En qué parte de tu producto los usuarios ya están lo bastante cerca del problema para solucionarlo, pero el workflow todavía los obliga a esperar a otra persona?

Fuentes