Doctorado

% !TEX root = tesis.tex

%----------------------------------------------------------------------------------------
%	CAPITULO 3
%----------------------------------------------------------------------------------------

\chapter{El contexto: culturas hacker encarnadas}\label{cultura-hacker}

Este capítulo abordará la cultura hacker desde cómo esta toma cuerpo
en en mí como investigador y sujeto político y en el hackerspace
HackBo, donde esta investigación ocurre, colocando en diálogo con
perspectivas teóricas y críticas que dan cuenta del fenómeno hacker
como una definición abierta que puede ser leída como práctica ciudadana y 
cotidiana.

\section{Mi lugar en la comunidad}\label{mi-lugar}

La metodología de esta investigación, al igual que algunas mencionadas en la primera
parte, está \emph{informada} etnográficamente (sin ser del todo una investigación
etnográfica) y por ello es importante establecer mi lugar en la comunidad.
Para esto lo ubicaré en dos ejes: uno de ellos como activista y miembro
de la comunidad de software libre y otro usuario de lenguajes de programación
y entornos interactivos de computación y modelación.
Dicho lugar establecerá también cómo me posiciono y desde qué lugar y experiencias
realizo los ejercicios de diseño de artefactos y dinámicas, mediados por tecnologías
digitales, en esta investigación.

Mi vinculación a la comunidad de software libre empezó en 1996, cuando instalé
el Gnu/Linux en computador de la familia.
Ya antes había tenido inquietud por los computadores,
y armaba computadores clones de PC e instalaba Windows en ellos.
En 1994, de desarrollé software para hacer 
boletines de calificaciones, usando la plataforma Windows, adaptando unos macros
en el procesador de palabra \emph{MS Word}, que los conectaban con la base de datos
\emph{MS Access}. 
Esto me permitió darme cuenta de los excesivos costos de licenciamiento
asociados al software comumente usado en aquel entonces,
(como \emph{Windows} y  \emph{Office}) y, de hecho, la manera usual de adquirir conocimiento
sobre los computadores y su funcionamiento era empleando software "pirata".
Lo cual abrió mi búsqueda y mi mente al encuentro con el software libre un par
de años después.

La experiencia de contar con software cuya licencia alentaba la copia, el estudio
y la distribución del mismo, sin convertirlo en un acto de pirateria, sino por el
contrario, normalizando y potenciando lo que era una práctica habitual entre estudiantes,
curiosos y usuarios de la computación, resonó fuertemente con mis búsquedas y mi contexto.
Por la forma como se hacía la instalación de Gnu/Linux en aquel momento, se iniciaba
con una interface de texto o CLI (por las siglas en inglés de \emph{Command Line Interface}),
y a partir de allí se empezaba a configurar manualmente el resto del sistema, hasta tener
un sistema con interface gráfica o GUI (por las siglas en inglés de \emph{Graphical User Interface})
y las aplicaciones habituales de ofimática, juegos y la naciente navegación en la \emph{World Wide Web}.
Esto implicaba la lectura de libros introductorios al sistema operativo, que incluían CD-ROMs 
con el software completo, y fueron el lugar de ingreso de muchos a esta tecnología y filosofía,
como en mi caso), así como la lectura de los sistemas de ayuda y manual dentro del sistema 
(páginas \emph{man} e \emph{info}, en la jerga Unix).
Me impresionaba de modos muy marcados la diversidad de autores de dichos documentos, particularmente
los de los sistemas de ayuda y el hecho de que aparecieran los nombres de individuos de
distintas afiliaciones, en lugar de una única empresa en los créditos, sin atribuciones
individuales, a las que el uso de la plataforma \emph{Windows} me tenía acostumbrado.
Por otro lado, también me seducían las demandas que se hacía del usuario.
No se pensaba que era alguien para quien la tecnología informática ocupaba un lugar instrumental,
sino que la documentación era profusa y permitía adquirir conocimientos sobre lo que había
detrás de la tecnología y cómo funcionaba (en aquella época teníamos por ejemplo que configurar
las frecuencias de barrido horizontales y verticales de la pantalla del computador adecuadamente, 
o correr el riesgo de quemarlo, como efectivamente hicimos con Herman Sandoval, un amigo y 
secuaz de esa otras luchas de ese entonces).

\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{./Parte2/colibri-2005.png}
	\caption[Colibri como lucía en el 2005]
	{Página web de Colibri, como lucía en 2005, recuperada de Internet Archive 
		en \url{https://is.gd/XbEW65}.
		Como la mayoría de proyectos digitales de esa época de la comunidad, esta memoria
		incompleta sólo está disponible en algunos servidores externos y como copias estáticas,
		pero los datos y el software que producián dichas páginas ya no está disponible en
		línea.}
	\label{fig:colibri}
}

Dicha seducción de carácter tecnológico y político cambió mi forma de ver la tecnología de
manera definitiva. 
Para 1999 había desinstalado \emph{Windows} de mi computador y desde entonces no lo he vuelto a usar
en ninguna de mis máquinas.

A comienzos del milenio me uní a distintas comunidades nacionales e internacionales de software,
donde se discutían aspectos técnicos: cómo configurar computadores livianos conectados
a máquinas pesadas, en la comunidad LTSP\footnote{\url{http://ltsp.org/}}; o cómo usar 
editores de texto científico, en la comunidad de TeXmacs)\footnote{\url{http://www.texmacs.org}};
o temas legales y filosóficos del software libre, en la comunidad Colibri (en alusión a la Comunidad
de personas interesadas en el Software Libre en Colombia, véase figura \ref{fig:colibri}), por ejemplo qué 
libertades definían al software libre, cómo su opuesto no era el "software licenciado", 
pues el software libre también tenía  varias licencias que alentaban y protegían dichas libertades, 
ni el "software comercial", pues el software libre también tenía esquemas comerciales, 
sino el software privativo, porque priva a los usuarios de las libertades que el software libre brinda.
Para el 2002 construimos y llevamos una propuesta de proyecto de Ley de Software Libre, articulado
desde la comunidad Colibri, que justificaba cómo el software libre debía ser implementado en 
entidades estatales sobre las bases de inclusión, transparencia y seguridad.
Esos años consolidaron la comunidad de software libre de Colombia y hubo varios eventos regionales
a los que me desplazaba, invitado o con fondos propios, dando charlas y conferencias sobre el
software libre.
Del 2004 al 2008, ayudé en el lanzamiento y sostenimiento de El Directorio, un wiki que funcionaba
como unas páginas amarillas de software libre, para documentar recetas de configuración, comunidades, 
empresas y servicios brindados nacionalmente y otros saberes de la comunidad.
En 2005 ayudé a la concepción y lanzamiento del Festival de Instalación de Software Libre
Colibri o FISLC, y en los años siguientes acompañé su transformación el en 
FLISoL\footnote{\url{https://flisol.info/}}, por Festival de Instalación de Software Libre 
de Latinoamérica, uno de los eventos más importantes y grandes de instalación y acercamiento 
al software libre en la región y quizás en el mundo.

\begin{figure}[tbp]
	\centering
	\subfloat[]{\includegraphics[width=0.45\linewidth]{./Parte2/el-directorio-2011.png}}
	\quad
	\subfloat[]{\includegraphics[width=0.45\linewidth]{./Parte2/flisol.png}}
	\caption[El Directorio y FLISoL]
	{Página web de El Directorio, como lucía en 2011 (recuperada de una copia de Internet Archive en 
	  \url{https://is.gd/vH9Hc6}) y del FLISoL, que, en contraste con el primero, aún en 2018 continua 
	  siendo un lugar comunitario activo y va más allá de las fronteras nacionales.}
	\label{fig:directorio-flisol}
\end{figure}

Respecto a la programación y modelación computacional, me inicié con el lenguaje 
\emph{logo} en mis primeros años de escuela primaria, en los ochentas, pasé a calculadoras científicas 
Casio 4500 en el colegio y luego a C, C++, Pascal en la universidad, a comienzos de los noventas, 
con un intermedio en Visual Basic y bases de datos Access,
a mediados de los noventas y Scheme\footnote{\url{http://plt-scheme.org/}},
Python\footnote{\url{https://www.python.org/}} y Smalltalk\footnote{\url{http://squeak.org/}}
como docente universitario  a comienzos de este milenio.
Sin embargo estas experiencias fueron dispersas a lo largo del tiempo y a pesar de
entender los fundamentos de algoritmia y algunos paradigmas de programación, por
mi formación de pregrado como informático-matemático, mi mayor experticia estuvo centrada
principalmente en la modelación computacional de la resolución de problemas, desde
modelos multiagente \ref{luna_cardenas_resolucion_2007}, intentando explicar fenómenos cognitivos 
y vincularlos a un correlato de aula y estrategias de enseñanza-aprendizaje, para lo cual usé Squeak,
la variante libre de Smalltalk.
La idea de computación científica llegó principalmente a través de programas como 
Matlab\footnote{\url{https://la.mathworks.com/products/matlab.html}},
Mathcad\footnote{\url{https://www.ptc.com/en/products/mathcad/}} y 
Mathematica\footnote{\url{https://www.wolfram.com/mathematica/}}, y fue en este último donde 
encontré la primera idea unificadora de la computación, con la programación simbólica y el hecho de que 
en este lenguaje todo son expresiones, compuestas de cabeceras y argumentos.
Me parecía particularmente interesante la idea de documentación interactiva de Mathematica
y Mathcad, donde se podía combinar la escritura de prosa, con código, gráficas y modelos 
computacionales, en documentos que reaccionaban a la interacción con el lector y generaban
otros modos de lectura y escritura y otras formas de pensar con ellos.
Intenté ubicar experiencias de documentación interactiva similares con sistemas de software libre,
con lo cual conocí software para hacer matemáticas computacionales, con programas para
modelación y similación y los cálculos numéricos y simbólicos, como 
Scilab\footnote{\url{http://www.scilab.org/}}, Octave\footnote{\url{https://www.gnu.org/software/octave/}},
Yacas\footnote{\url{http://www.yacas.org/}}, Mathpiper\footnote{\url{http://www.mathpiper.org/}}, 
Maxima\footnote{\url{http://maxima.sourceforge.net/}} y otros programas y formatos para escritura matemática, 
entre los que estaban LaTeX\footnote{\url{https://www.latex-project.org/}}, 
MathML\footnote{\url{https://www.w3.org/Math/}} y uno que permitía particularmente la escritura de 
documentos estructurados científicos interactivos, integrando varios de los paquetes ya mencionados, 
llamado TeXmacs\footnote{\url{http://texmacs.org/}}, en el que escribí mis tesis de pregrado y maestría 
y fui uno de los principales traductores de la documentación al español.
%PENDIENTE: Va acá o en la parte de Grafoscopio?
TeXmacs fue el primer software que personalicé (usando Scheme) brindándome la experiencia de escribir
un pequeño archivo que creara una nueva funcionalidad disponible para el usuario (consistía en agregar
un nuevo menú en la interfaz de usuario) y me introdujo a una idea poderosa,las 
\emph{expresiones S}\footnote{\url{https://es.wikipedia.org/wiki/Expresi\%C3\%B3n_S}}, 
que permitían tratar a documentos como estructuras uniformes arbóreas, donde tanto datos como código,
son considerados de manera uniforme y uno puede convertirse en el otro.
Esta idea sería después reforzada por Leo y parte importante del diseño de Grafoscopio, casi 15 años
después, lo cual es una muestra de la exaptación mencionada por \cite{jonas_design_2004},
cuando habla de los ``repositorios latentes de soluciones'' con las que deben contar los diseñadores.

Durante esa época, usaba ciertos \emph{scripts} en el lenguaje de programación Python para automatizar 
ciertas tareas, y cuando pensaba en código determinadas ideas y prototipos, o hacía más desde una
perspectiva teórica y académica (por ejemplo la de los modelos cognitivos computacionales de
mi tesis de maestría), que la de un programador como tal, que fuera responsable de la labor
artesanal\footnote{La idea de programación como artesanía en lugar de como ingeniería, retoma
	lo dicho en la primera parte en alución al hacer es pensar de Sennet y será extendido
	posteriormente sobre unas ideas de la materialidad de código de programación.}
y cotidiana de la misma, atendiendo distintos detalles respecto a cómo se implementa
una funcionalidad o dónde se coloca un botón o ícono en una interfaz gráfica.

Intenté conectar mi experiencia con estos sistemas de matemática computacional, como docente-investigador
universitario y como activista de software libre, al crear algunas distribuciones a medida de Gnu/Linux,
que podían ser ejecutadas desde un CD-ROM, sin tener que instalarse en el computador.
Esto permitiría a mis estudiantes acceder a software libre y crear memoria de lo hecho
en clases, con sistemas similares a los que yo usaba en mi propia máquina, sin que ellos
tuvieran que pasar por las dificultades propias de instalar Gnu/Linux en las propias.
Del 2002 al 2008 fui el autor y compilador principal de las distribuciones SciLix,
Tangram Linux y Virtual Tangram.
Mi labor como docente, especialmente en pregrado, durante esos años, estuvo mediada permanentemente 
por la creación de entornos virtuales de aprendizaje, que complementaran el aprendizaje cara a cara en 
clase (también llamados de \emph{b-learning} por \emph{blended-learning} o aprendizaje bimodal: 
digital-análogo).
En estas prácticas había una patrón: el disponer una infraestructura (en la forma de distribuciones 
de Linux hechas a medida, como las ya mencionadas, o lugares virtuales) y desarrollar un conjunto de 
prácticas alrededor de las mismas, que sirvieran a propósitos educativos (usualmente en espacios formales 
e institucionalizados, pero en diálogo con lo que ocurría en espacios informales y no institucionalizados).
De ellas hago un recuento detallado en la presentación \emph{Nómadas digitales, Aprendizaje} 
(ver figura \ref{fig:nomadas-digitales}).

\begin{figure}[tbh]
	\centering
	\subfloat[]{\includegraphics[width=\linewidth]{./Parte2/nomadas-digitales.png}}
	\caption[Nómadas Digitales]
	{Nómadas digitales: Mapa de un recorrido por varias experiencias de \emph{b-learning} con
		mis estudiantes durante la primera década del milenio.
		Disponible en \url{https://is.gd/Syq0SS}}
	\label{fig:nomadas-digitales}
\end{figure}

Mi propio lugar en la comunidad de Smalltalk empezó con algunas experiencias de enseñanza de 
la programación en un curso de introducción a la informática, dictado del 2005 al 2007, en la 
que exploraron distintas herramientas y lenguajes, como Python, Scheme, Scratch, Etoys y Bots Inc, 
encontrando que estás tres últimas eran extremadamente adecuadas para la enseñanza a novatos, 
por el uso de metáforas visuales para explicar los elementos de la programación orientada a objetos 
y su sintaxis minimalista, como está documentado con mayor detalle en 
\cite{luna_cardenas_resolucion_2007}. 
Sin embargo, después de dicha experiencia, mi vinculación a la comunidad de Smalltalk fue 
principalmente a través de las listas de correo y a pesar de considerarlo para varios proyectos
como un enrutador de identidad digital (\cite{luna_cardenas_ubakye:_2011,luna_cardenas_ubakye_2012}, 
y un clon del software de presentaciones Prezi, dichas intenciones nunca llegaron a una primera
línea de código. 
Otras herramientas, como we2py, Leo o IPython eran más maduras y pertinentes para asumir las tareas
de exploración, uso y prototipado de tecnologías digitales a las cuales me veía constantemente abocado. 
No fue sino después de la salida de Pharo en el 2009 como variante basada en Squeak (base para Scrach, 
Etoys y Bots Inc, en ese entonces) y el cambio de énfasis hacia la construcción de herramientas 
a la medida de Moose y la visualización ágil, que las condiciones estuvieron listas para reemprender 
un prototipo más factible, con un valor diferencial que ninguna de las herramientas conocidas tenían, 
como se explicará en el capítulo \ref{grafoscopio}.

Para el 2008, como coordinador de tres áreas temáticas (Software Libre, Desarrolladores
de Software e Inclusión Digital) de la \emph{Campus Party}, una de las fiestas en red
(o \emph{LAN Parties}, por su acepción en inglés) más grandes del mundo, tuve la oportunidad de conocer 
a Jose David Cuartas, Adriana Castrillón y Manuela Monsalve, estudiantes de Diseño Visual en la 
Universidad de Caldas, con quienes entablaría una duradera amistad, que perdura hasta el momento.
En las conversaciones tempranas sobre lo que hacíamos con tecnología ellos me dijeron que
esa orientación a hacer cosas con infraestructuras digitales y comunidades alrededor,
atento a lo que pasaba en dichas interacciones, era muy parecido a las formas de hacer
en diseño.
Tener un marco de enunciación, una epistemología si se quiere para lo que ya hacía y saber
que ocurría desde el diseño me orientó en los intentos de conciliar mi labor docente, mis inquietudes
investigativas y comunitarias y los requerimientos de la universidad para la que trabajaba (que, como 
la gran mayoría ha caído en la inflación absurda de títulos para sus profesores y en formar más doctores 
de los que el mercado puede contratar).

Fue así como este trayecto me llevó a iniciar el Doctorado en Diseño y Creación en la Universidad de Caldas,
cuyo caracter jóven y sin miedo a proponer y experimentar y cuya epistemología abierta desde el diseño,
permitiría tender redes hacía las prácticas activistas, desde el \emph{hackerspace}, HackBo, que 
ayudé a fundar, por una afortunada coincidencia en el mismo año en que empecé el doctorado (2010) y del 
que me ocuparé en la siguiente sección.

Lo anterior muestra a una persona largamente involucrada con la comunidad de software libre del país
y en contacto con otras comunidades nacionales e internacionales.
También a alguien con cierta visibilidad y reconocimiento en nichos particulares, preocupado
por las infraestructuras que soportan las prácticas comunitarias y siendo parte de varios proyectos
nacionales e internacionales.
Esto, por su puesto, no está libre de inconvenientes y puntos ciegos, pero es consecuente con
la idea de investigación activista e investigador como sujeto político que habita/observa a un
sistema que lo incluye a él, esbozada en la primera parte.
La siguiente sección profundiza en el contexto de lo hacker, describiendo un espacio particular
donde dicho concepto encarna (un hackerspace) y poniéndolo en diálogo con algunas perspectivas
teóricas que han estudiado dichos espacios y las relaciones entre ciudadanía y tecnologías.

%PENDIENTE: Infraestructuras autocontenidas y sencillas luego de probar muchas complejas


\section{HackBo, un hackerspace en Bogotá}\label{hackbo}

Numerosos académicos han hablado ampliamente del fenómeno hacker desde perspectivas
académicas.
Los trabajo seminales de Coleman \cite{bibid} ubical al código como una forma de
ejercicio de la libertad de expresión dentro de otras tradiciones libertales
(no en el sentido económico, sino político del término).
Maxigas y su genealogía del fenómeno hacker desde los hackerspaces y Hacklabs,
asocia los últimos a movimientos autonomistas europeos en la tradición
okupa y los primeros a esfuerzos gentrificadores dentro de la noción del
emprendimiento y la innovación social.
Mackenzi Clark y su Manifiesto Hacker, pone en diálogo la tradición hacker con las 
ideas marxistas, ya no desde el enfretamiento entre el proletariado y los capitalistas,
sino entre los hackers (aquellos que ven, gracias a la abstracción, en 
el mundo presente el mundo posible) y los vectoristas, aquellos que usufructuan
y extraen el valor del trabajo de los primeros al colocar las plataformas
donde dicha abstracción circula y se expande, es decir los vectores de
la misma (usualmente en la forma de redes sociales) e invita a pensarnos como
clase en las luchas por lo posible, del agricultor, del transgenero, del programador,
de todos y todas.
Sebastian muestra cómo el fenómeno en Berlin, particularmente en el Chaos Computer Club 
(CCC) ha adquirido capacidad de interlocución pasando de lugares marginales a lugares
centrales del discurso público y nos da claves para entender en fenómeno en términos
estéticos y políticos desde las estrategias desplegadas por el CCC.
Schrock hace un recuento de algunas de esas genealogías, preservando la invitación
de Coleman a mantener la definición de lo hacker como abierta y multisituada
e indicando que los hackers son cotidianos, en el sentido de que el hacker
no es esa figura mítica que gracias a una comprensión especial de la tecnología
la domina, sino que en una relación dialéctica, es la tecnología la que hace al
hacker en actos cotidianos, al soldar, programar, y \emph{cacharrear} todos los días.
Por ello, él indica que los hackerspaces son espacios de aprendizaje disfrazados,
donde al establecerse esas relaciones cotidianas con la tecnología, los participantes
se hacen hackers sin darse cuenta.

La aproximación a la cultura hacker asumida en esta tesis no pretende profundizar en
lo que ya han dicho estos y otros autores, ni resumirlo, sino ponerlo en diálogo con un
lugar particular donde lo hacker encarna, se recontextualiza y se (de)construye:
HackBo, un hackerspace en Bogotá.
De esta manera, el enfoque se puede mantener en las maneras en que dicha cultura
y quehaceres encarnados desde HackBo permiten abordar el problema central de esta
investigación dentro de dicho diálogo.
Para ello se dará cuenta de la historia del espacio y de cómo las prácticas allí
conversan con las lecturas de algunos autores, en particular la espacio cotidiano y bien
recursivo, es decir aquel bien que construye a quienes lo construyen y de lugar para
la ciudadanía.
Se mantiene así el potencial de una definición abierta, pero también se indican los
lugares donde dichos autores interpelan a las prácticas cotidianas en el espacio.

HackBo empezó en diciembre de 2010, meses después de empezar el doctorado, en una
feliz coincidencia que permitió entrelazar procesos académicos y comunitarios.
Sus miembros fundadores (entre los cuales me encuentro) reunidos en un bar 
y empezaron a cristalizar una idea de la que algunos que nos habían comentado 
pro primera vez en la Campus Party de Bogotá este mismo año.

Muchos sentíamos que la Campus usufructuba, de maneras instrumentales sin ofrecer 
valor real, dentro de las lógicas de la ``publicidad experiencial'' donde lo 
importante era tener una ``experiencia con la marca'' y bastaba con que las cosas 
lucieran bien en la superficie, así no tuvieran mucho de fondo.
Esta sensación era compartida por muchos de los que estuvimos tanto detrás de la 
organización de la Campus Party en varias de sus ediciones, así como de los
invitados, que sentían un control extremo y hablábamos de condiciones de
explotación: no se pagaba a todos los conferencistas, existía una ``zona VIP''
donde se diferenciaba a unos expositores y talleristas de otros y el ``voluntariado''
de muchos era pagado con unas entradas que no estaban en condiciones reales de
disfrutar ante las demandas de tales voluntariados.
Este era un comportamiento recurrente en varias ediciones de la Campus no sólo en
varios años (empezó en el 2008 en Colombia), sino en varios lugares
(para el 2008, participé de la preproducción en Brasil, la producción en Colombia
la post-producción en El Salvador y fui invitado a la de España).

Arpunk, un miembro de la comunidad de software libre, conocido con ese apodo, 
nos dijo, en una reunión informal dentro de la Campus de Colombia de 2010, 
precisamente relacionada con aquel malestar compartido frente al evento, que 
existian estas lugares gestionados comunitariamente y que eran más fieles al espíritu 
hacker.
El hecho de que la reunión para pensar otras formas de encontrarnos ocurriera
dentro del evento que criticábamos era de hecho una muestra de ese espíritu:
si bien algunos trabajábamos, en aquel entonces, para la empresa tras la Campus,
esto no quiere decir que fueramos acríticos, ni como organizadores, ni como asistentes
a lo que en ella ocurría y que nuestra premisa de buena fe detrás de las primeras
participaciones condicionara nuestro involucramiento crítico con el evento y sus
lógicas.
Para diciembre de 2010 estábamos retomando esa conversación y realizando un acto
fundacional clásico en las comunidades de software libre: bautizar un proyecto y
sacar un dominio en Internet que lo representara.
En nuestro caso, el nombre fue HackBo por Hackerspace y Bogotá, usando la notación
de combinar mayúsculas y minúsculas dentro de una palabra, popularizada por los wikis
(y denominada Camel Calse\footnote{\url{https://en.wikipedia.org/wiki/Camel_case}})
y el dominio fue \href{http://hackbo.co/}{hackbo.co}.

\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{./Parte2/hackbo-twitter.png}
	\caption[HackBo en Twitter]
	{HackBo en Twitter. Nótese como la descripción aún hace alusión a la Campus
		Party, pero también marca constrastes con ella, que serían extendidos
		en los espacios físicos y virtuales del evento. 
		La cuenta está inactiva desde hace años.}
	\label{fig:hackbo-twitter}
}


Los primeros dos años de funcionamiento, HackBo sería un espacio itinerante, que
inició como una esquina, literalmente, en el Tecno Parque en las oficinas del Sena
en el sector de Chapinero de Bogotá, con dificultades de acceso, tanto al edificio
físico como a Internet, que mostraban todas las restricciones institucionales y
de seguridad impuestas por tal institución.
Luego estuvimos en el colectivo cultural La Redada, que nos prestaba sus instalaciones
las tardes de los sábados, pero requeríamos de más tiempo para reunirnos, por lo
cual pasamos a estar dos noches por semana y los sábados en la Fundación Buinaima,
hasta que se dió la oportunidad de tener un espacio exclusivo en un apartamento del
Barrio de la Javeriana, donde estamos radicados desde 2012.

Los miembros fundadores y los primeros asistentes al espacio nos conocíamos de años
atrás por muchos de los procesos y actividades comunitarias compartidas que derivaron
en amistades entrañables.
Algunos de tales procesos y proyectos han sido recapitulados en la sección \ref{mi-lugar}:
La Ley de Software Libre, El acuerdo distrital por el Software Libre, El Directorio,
las Jornadas de Software Libre, la Semana Linux de la Universidad Distrital, varios grupos
de usuario de Linux, la participación en la Campus Party y varios centanares de encuentros 
y proyectos durante casi una década.
HackBo se alimentaba de esas relaciones de confianza mutua y conocimiento, y también
implicaba que los nuevos participantes estaban dispuestos a invertir los tiempos necesarios
en hacerse parte de esas redes de confianza.
De hecho, en la caracterización hecha por Elionor Östrom sobre los bienes comunes, ella habla 
de cómo la confianza es necesaria para la producción y el sostenimiento de tales bienes
y en ese sentido varios de los patrones detectados por Ostrom aplican al Hackerspace como
espacio físico y a lo que en él se produce desde y hacia los espacios simbólicos.

Östrom no sólo clasifica los bienes en privados y públicos dependiendo de la exclusividad
sobre los mismos y si esta es fácil (privado) y difícil (públicos), sino que agrega otra
dimensión referida a cuanto queda de un bien después de que se goza de este, es decir la
sustracción y si esta es alta (no queda mucho) o baja (queda bastante del bien).
Esta otra dimensión configura cuatros tipos de bines: privados, públicos, clubes y 
bienes comunes.

%PEN: Gráfica

HackBo es entonces un club, pues el exclusión sobre acceso al bien es fácil y tiene que
ver con quiénes tienen las llaves, cómo se entregan o se quitan, pero una vez adentro,
la sustracción del bien es baja y queda mucho de HackBo para todos sus usuarios.
En cuanto a los espacios simbólicos, debido a la fuerte relación de la mayoría de sus
miembros con movimientos de software y cultura libre, se producen bienes simbólicos
comunes en la forma de software, diseños de circuitos y documentación.
Hackbo es entonces un tercer espacio que opera en una diagonar complementaria a
la que clasifica los bienes privados y públicos, mediados por las lógicas del mercado y 
del estado.
Incluso, miembros más recientes del espacio, dedicados a la producción audio-visual,
hacen parte de la logística del Festival de Cine Creative Commons y New Media, si bien no 
todo lo que se presenta en dicho Festival tiene licencias abiertas y ellos mismos no han 
producido trabajos con tales licencias, aunque sí referidos a proyectos de hardware libre
y abierto que los tendrían, en colaboración con otros miembros de HackBo.

Es decir, HackBo es un bien club, desde lo físico, pues la exclusión es fácil, pues se tienen o no
las llaves de la entrega y se es parte si dos miembros presentes lo recomiendan para el que quiere
pertenecer), que está marcado y de algún modo orientado hacia los bienes comunes desde lo simbólico, 
aunque no todos los miembros participan igualmente de la segunda parte, se produce constantemente
documentación, software, audivisuales, diseños de hardware que están cubiertas por licencias bajo
el esquema de las obras culturales libres, que garantizan su uso, disfrute y/o modificación por
parte de esa y otras comunidades.
Esta multiplicidad de aproximaciones al mismo espacio y las formas de vinculación mediadas
por unas normas mínimas, son los miembros de Las Indias\footnote{\url{https://is.gd/las_indias}} 
denominan ``plurarquía'' en contraste con las jerarquías y de manera complementaria, pero distinta 
a las anarquías\footnote{\url{https://is.gd/plurarquia}}:

\begin{quote}
	En un sistema pluriárquico la toma de decisiones no es binaria. No es sí o no. 
	Es en mayor o menor medida. Alguien propone y se suma quien quiere. 
	La dimensión de la acción dependerá de las simpatías y grado de acuerdo que suscite la propuesta. 
	
	[...]
	
	cuando una red se configura como una plurarquía se hace imposible mantener indefinidamente privilegios 
	o ventajas para un individuo o un grupo de individuos porque o lo impone el consenso o los 
	desfavorecidos abandonarán la red para unirse o crear una escisión, un «fork». [...]
	La plurarquía es la forma de organización característica de las comunidades orientadas a la abundancia, 
	ya sean comunidades exclusivamente conversacionales o comunidades que, además, producen.
\end{quote}


Para Bauwens, mercado y estado son maneras de administra la escasez, bien sea a través
del precio y la compra o bien de la toma de decisiones democráticas, en las que unas minorías
se someten al dictamen de las mayorías.
La plurarquía, permite que varias decisiones distintas puedan convivir en el mismo espacio.
Para el caso específico de HackBo, las acciones sólo se anuncian previamente para evitar
posibles conflictos por el uso de un recurso común (por ejemplo el proyecto para dictar 
un taller o ver una película) y si ningún miembro se opone, se presupone en acuerdo tácito
sobre dicha actividad y uso de recursos.
En caso de que haya disenso sobre el uso de las infraestructuras físicas, pero sobre todo
las virtuales
La argumentación sobre las ventajas o desventajas de cada una de las propuestas, ocurre 
en los hechos, a través de las implementaciones de infraesctructuras tecnológicas 
paralelas (o su ausencia).
Las bifurcaciones (del inglés \emph{fork}) son las maneras de enfrentar el disenso de manera
enactiva: en lugar de intentar un consenso previo, antes de la acción o atenerse a la parálisis
por su ausencia, las acciones simultáneas, diversas, y en ocasiones encontradas, pueden desplegarse 
en el mismo espacio, para ser comparadas, contrastadas y convividas.
Esto muestra uno de los ethos permanentes de HackBo, en el que la votación es la última acción,
dentro de muchas posibles, para lidiar con la ejecución: en principio las diversas acciones están
permitidas y sólo se consulta cuando dos acciones encontradas requieren del mismo recurso o
afectan los recursos de otros.
Existen acuerdos tácitos que son renovados y recordados permanentemente: pagar la mensualidad,
lavar la loza, mantener el espacio mínimamente organizado y usable, especialmente los baños y cocina.

La bifurcación toma cuerpo no sólo en las acciones sino tambíen en las infraestructuras
y en ese sentido ejemplifican la idea expresada por \cite{isin_being_2015} frente a cómo
decir con acciones.
Estos autores, recogen los actos de habla, aquellos que no sólo afirman o niegan algo,
sino que hacen cosas: prometen, ::::.
De manera recíproca a cómo las palabras hacen, las acciones dicen.
Cuando se elige compra comida orgánica, si se bota basura a la calle, o se emplea una
infraestructura tecnológica, no sólo se están realizando acciones, ellas hablan.
Para el caso de HackBo, infraestructuras digitales implementadas sobre nuestra
presencia en línea, hablan de hasta donde apropiamos o delegamos la autonomía en
plataformas propias o cedemos esas formas de presencia a terceros y enagenamos sus
condiciones.
Es más, el hecho de que plataformas distintas existan, sirviendo a propósitos distintos
en lo que \cite{coates_addendum_2005, coates_my_2003} ha denominado software social (y se
verá con mayor detalle en el capítulo \ref{dataweek}) es una manera manifiesta de la plurarquía.
El desplegar infraestructuras digitales que permitan argumentar sobre cuál de ellas es mejor
para las necesidades de la comunidad y juzgar desde los compromisos de los proponentes con las
acciones ejecutadas para defender sus argumentos desde la infraestructura misma es un ejemplo
claro de decir con acciones y de la \emph{tiranía del hacedor}, pues quien hace, determina cómo
se hace, en lugar de ser mandado por una junta o votación sobre cómo debería hacer aquello que
otros decidieron, pero que no van a ayudar a hacer.

Lo anterior configura también una serie de dificultades, pues quien no sabe cómo hacer, no puede
argumentar tan claramente como quién sí lo sabe, incluso si los argumentos son buenos. 
Es decir la claridad para argumentar está vinculada a la capacidad para hacer y con la tecnología, 
y se puede correr el riesgo de que los argumentos sean buenos, pero el lenguaje de los prototipos no 
los exprese claramente, como cuando intentamos argumentar en una lengua que no es la nativa.
Por otro lado, la ausencia de una falta de estructura explícita, hace difícil la contestación: %REF
si la estructura es explícita y hay un desacuerdo, es posible contestar el acuerdo desde los mecanismos
provistos para ello, pero para el caso de HackBo, simplemente se cuenta con la bifurcación 
(en caso de desacuerdo) o el apoyo/afiliación (en caso de acuerdo).
Si bien esto no es grave en un lugar donde muchas decisiones conviven a la vez, puede hacerse difícil
para organizar labores logísticas que impliquen un esfuerzo grande como organizar el taller y los equipos.

HackBo es, entonces un espacio polisémico y plurárquico que tiene lecturas y posibilidades distintas
para quienes lo construyen y habitan.
Como todo espacio, esta regido por tres fuerzas, según \cite{isin_being_2015}: 
performativas, legales e imaginarias, que se refieren, respectivamente, a lo que ocurre en el espacio,
a su condición legal y a lo que nos imaginamos que puede ser y ocurrir.

En lo legal HackBo es símplemente un apartamento coarrendado por varias personas que contribuyen 
con una cuota  mensual para pagar su sostenimiento (servicios, arrendamiento y eventuales mejoras).
Este es un estatus legal mínimo y algunos miembros (entre lo que me encuentro)
se han opuesto a que adquiera un caracter legal más allá de este, sin convertirse en fundación,
corporación u otra cosa, esencialmente para mantener la dimensión comunitaria y la productiva y
de financiación separadas.
Las reuniones iniciales para la constitución legal crearon reglamentos, pero ninguno de los asistentes
llevó a términos el conjunto de acciones que permitián el registro y la contitución del espacio:
consultas jurídicas, firmas en papel, levantamiento de otros documentos y su radicación, etc.
Si bien el tema de la constitución legal era recurrente, particularmente en los primeros años,
ante la ausencia de compromisos, interés y acciones que formalicen dicha figura, se ha usado una 
figura emergente y conveniente y es que las fundaciones o empresas de los miembros del la
comunidad nuclear puedan recibir recursos que transfieren luego a al espacio para los pagos habituales, 
o en los pocos casos en los que hay superhábit, para ser coadministrados por ellos.

La fuerza legal es relativamente estable y minimalista mientras que las fuerzas performativas 
e imaginarias dentro del espacio son más dinámicas y entretegidas (por su puesto, un cambio 
dramático en ellas podría implicar un cambio en las fuerzas legales, pero hasta ahora no ha ocurrido).
Esto es particularmente notorio respecto a qué es hackear dentro del hackerspace
y la naturaleza política o despolizada de dichos actos.
Particularmente porque una definición abierta como la de hacker puede permitir que cualquier cosa sea
``hackear'', con lo cual la definición se diluye y despolitiza.
Hackear, en esas acepciones diluidas tiene que ver con cómo amarrar un nudo de corbata o bajar la grasa 
abdominal, como en el sitio \emph{Daily Life Hacks}\footnote{\url{https://twitter.com/dailylifehackz}} 
y no con la gambiarra y el meta-reciclaje brasilero o con los actos cotidianos que nos permiten adquirir
maestría de modos comprometidos pero invisibles en la acepción de Schrock.
Los hackerspaces se vuelven exclusivamente lugares de \emph{co-working} para el ``emprendimiento''
capitalista, donde la relación es entre arrendatario y arrendador y no entre pares, dentro de lugares 
cocreados y co-administrados con plurarquía, gozo y tensión.
Ya no se trata de pensar desde la perspectiva de clases, siguiendo la invitación de Wark y cómo ver 
en lo presente lo posible conecta la lucha por la autonomía de las  semillas (y la nefasta Ley 970), 
la libertad de expresión (y la nefasta Ley Lleras recientemente aprobada en el Congreso de Colombia 
para entrar a la OCDE), el matrimonio igualitario y las reinvidicanciones feministas, sino de reunirnos
temporalmente en una ``hackatón'' fashionista y gentrificada, para competir unos contra otros por
un premio consistente en un mal contrato (como el denunciado en la sección \ref{gobernaton}), un
parlante o una consola de vídeo juegos.

Que un sólo tipo de definición sobre lo hacker agote e invisibilize las otras o las diluya hasta
gentrificarlas va en contra de las ideas de futuralidad y mundos posibles planteadas por 
\cite{escobar_autonomiy_2016} y las ambigüedades de una definición abierta se constituye en un espacio 
dialéctico para señalar esas tensiones y los hackerspaces y hackatones son eventos donde las definiciones 
se pueden repolitizar.
Es por eso conveniente indicar por qué en la acepción de esta tesis, no todo es hackear, sin 
agotar la definición, pero sí articulándola con los alfabetismos digitales mediados por código 
y datos, un asunto fundamental de la pregunta por cómo cambiamos los artefactos digitales que 
nos cambian y cómo esta se constituye también en una pregunta por la autonomía y desde allí se 
exploran maneras de ciudadanía, tanto en las personas como en las comunidades de práctica.

En palabras de \cite{isin_being_2015} (pág 139):

\begin{quote}
	To understand the emergence of citizen subjects acting through the Internet as
	subjects of power requires investigating the conventions that call them forth as
	digital citizens and the digital acts they perform to say and do things. No doubt,
	the birth of a subject position called ‘hacker’ and the digital acts with which it
	came into being present a challenge. The stories that have been told about
	hackers make it difficult to resignify this subject of power afresh. Since the
	1980s, the image of hackers has dominated fictional and semifictional worlds of
	writing and filmmaking. Our focus here, though, is to get a grip on the openings
	that ‘acts of hacking’ have created.
	
	Comprender la emergencia de sujetos ciudadanos actuando a través de Internet como
	sujetos de poder requiere investigar las conveciones que los convocan como 
	ciudadanos digitales y los actos digitales que ellos performan para decir y hacer cosas.
	Sin duda, el nacimiento de una posición de sujeto llamada `hacker' y los actos digitales con
	los cuales se constituye presentan un desafío. Las historias que nos han dicho acerca de los
	hackers hacen difícil
\end{quote}

Acá Isin y Rupert se separan de la mirada caricaturizada de los medios
``informativos'' y hollywoodenses sobre el hacker (una distinción que nos toca
hacer semanalmente en el espacio, cuando nos piden, por correo o en persona, que entremos a 
la red social de la (ex)pareja o cambiemos notas o estados bancarios), para pensarla en
clave ciudadana desde la idea de sujetos de poder, que Isin y Rupert contrastan
con la idea de sujetos al poder y sus relaciones con lo digital, desde la perspectiva de 
la teoría crítica política:

\begin{quote}
	What distinguishes the citizen from the subject is that the
	citizen is this composite subject of obedience, submission, and subversion. The
	birth of the citizen as a subject of power does not mean the disappearance of the
	subject as a subject to power. The citizen subject embodies these forms of power
	in which she is implicated, where obedience, submission, and subversion are not
	separate dispositions but are always-present potentialities.
	
	[...]
	
	For Foucault, it was ‘acts of truth’ that afforded possibilities for
	the subject to constitute herself as a subject of power. For us, this also means that
	acts of truth afford possibilities of subversion. Being a subject of power means
	responding to the call ‘how should one “govern oneself” by performing actions
	in which one is oneself the objective of those actions, the domain in which they
	are brought to bear, the instrument they employ, and the subject that acts?’[14] In
	describing this as his approach, Foucault was clear that the ‘development of a
	domain of acts, practices, and thoughts’ poses a problem for politics.[15] It is in
	this respect that we consider the Internet in relation to myriad acts, practices, and
	thoughts that pose a problem for the politics of the subject in contemporary
	societies.
	
\end{quote}

\begin{quote}
	If we focus on how people enact themselves as
	subjects of power through the Internet, it involves investigating how people use
	language to describe themselves and their relations to others and how language
	summons them as speaking beings. To put it differently, it involves investigating
	how people do things with words and words with things to enact themselves. It
	also means addressing how people understand themselves as subjects of power
	when acting through the Internet. This requires exploring how people come into
	being through the Internet not only as speaking subjects who use language but
	also other modes of engaging and acting.
\end{quote}

En la medida en que las fuerzas de obediencia, sumisión y subversión están presentes
en los ciudadanos, estos no solo están sujetos \emph{al} poder, sino que son sujetos
\emph{de} poder.
Dicho poder lo ejercen de distintas maneras, atendiendo verdades

\begin{quote}
	For us, probably the most
	pertinent distinction is between programmers and hackers. In or by saying
	something in code performs both illocutionary and perlocutionary acts.
	The difference between programmers and hackers is, however, the effects of their acts, 
	which have dramatically changed over time. 
	Programmers are those— either employed by software companies or working independently—who 
	make a living by writing code, which includes anything between snippets (short code) and apps. 
	Hackers may also program code in this fashion, but the culture that gives them the name 
	emanates from a distinct set of ethical and aesthetic values that combine to create a 
	different kind of politics than programming does. 
	This difference is hard to express, but it is also the difference that is of interest to us. 
	It is hard to express perhaps because so much has been said and written about 
	hackers—mostly negative. 
	As a consequence, a unified, typically clandestine, selfish, young, male, and outlaw image 
	has become dominant, which more recent studies have shown is grotesquely simplified. 
	We want to argue that hackers are those whose acts break conventions of programming.
\end{quote}

\begin{quote}
	What are the effects of digital acts of hacking? What conventions do these
	acts break? What conventions do these acts resignify? They are as broad as there
	are types of hackers.
	
	We want to consider these combined and diffuse effects of acts of hacking in terms of actions 
	against closings such as filtering, tracking, and normalizing. 
	These actions that feed the imaginary force of acts of hacking perhaps explain the joy of the 
	deep hack mode that Coleman documents. 
	Yet a generalized conclusion cannot be reached since hackers can create dangerous effects that 
	also participate in closings of the Internet.
	
	
\end{quote}


% Tensiones: inactividad de las cuentas, sostenimiento de la infraestructura
% resolución de conflictos.

%PEND: Historia.
% - Bienes comunes: Gobernanza, filiación y propiedad
% - Gobernanza: plurarquía y tiranía del hacedor.
% - Lugar de ciudadanía: El hack como acto político (es también estético y lúdico).
% - Espacios y fuerzas: enactivas, legales, imaginarias.
% - Los hackers y los hackerspaces son bienes recursivos.

No todo es "hackear".

	la autopoiesis social como un proceso, en el cual encontramos una
	dialéctica de estructuras sociales y actores humanos. El foco de Luhmann
	en las comunicaciones y las estructuras como unidad de reproducción
	autopoiética es en nuestra aproximación reemplazado por la unidad de
	estructura y actores.
\end{quote}




Este cambio de unidad de autopoiesis de las comunicaciones y las
estructura y los actores (humanos) reinvindica la agencia humana en la
posibilidad de transformar el mundo y brinda puentes con otras teorías.
Las exploraremos en la siguiente sección.

\section{Consecuencias de la crítica de Fuchs y Hofkirchner en la teoría de Jonas y los diseños autonómicos}\label{consecuencias-fuchs-en-jonas}

La primera consecuencia es nominal, pero no por eso trivial. Desde la
teoría de sistemas sociales crítica de \cite{fuchs_autopoiesis_nodate} las
brechas/puentes de Jonas que aborda el diseño, podrían actualizarse como
aquellas entre los artefactos/mecanismos, lo biológico (organismos), lo
mental (conciencias) y lo social como hecho humano (desenfatizando así
las comunicaciones, que son parte de lo social, pero no su centro).

\marginpar{
	\captionsetup{type=figure}

\end{quote} 

Para el caso de las comunidades de práctica este involucramiento es evidente como
muestran las investigacinoes de \cite{manzini_emerging_2013} sobre innovación social emergente,
donde comunidades codiseñan, desde sus apuestas cotidianas, otras maneras de habitar el mundo,
que se convierten en críticas proactivas desde la acción, frente a un modelo depredador actualmente 
generalizado.
Y resuena con la idea de futuralidades de  

%PEND:
Esto resuena fuertemente con la idea de futuralidades de \cite{escobar_autonomiy_2016},
en su apuesta por la autonomía y el diseño.
Retomando su abordaje:

\begin{quote}
	Varela dio una definición minimalista del concepto que podemos usar como una bisagra hacia una 
	conceptualización más amplia: «de hecho, la clave para la autonomía es que un sistema vivo encuentre su camino 
	hacia el momento siguiente actuando adecuadamente a partir de sus propios recursos» (Varela 1999: 11). 
	Lo mismo ocurre con los mundos y las comunidades, aun, o quizás especialmente, bajo condiciones de 
	ocupación ontológica.
	
	[...]
	
	Igualmente, tendremos que investigar lo que esto significaría en términos del diseño de herramientas,
	interacciones, contextos y lenguajes que cumplan con el principio del diseño ontológico de cambiar la 
	forma como nos ocupamos de nosotros mismos y las cosas.
	
\end{quote} (pág 192)

\begin{quote}
	Autonomía: se refiere a la creación de las condiciones que permiten el cambio de las normas 
	desde dentro o la capacidad de cambiar las tradiciones tradicionalmente. 
	Podría implicar la defensa de algunas prácticas, la transformación de otras y la verdadera 
	invención de nuevas prácticas.‘Cambiar las tradiciones tradicionalmente’ podría ser una descripción 
	adecuada de la autopoiesis; su correlato, ‘cambiar la forma como cambiamos’
\end{quote} (pag 197)

Esto coloca la pregunta central de esta tesis, sobre cómo cambiamos los artefactos digitales que
nos cambian, en dialogo directo con las inquietudes de Escobar, y sus conexiones con las teorías
de Sistemas sociales críticos de \cite{fuchs_autopoiesis_nodate} y las aproximaciones al diseño
de \cite{jonas_design_2004, jonas_design_2007}.
Es un lugar concreto donde estas tres posturas se exploran, pues nos ofrece una teoría cibernética 
crítica del diseño, que conecta lo social, lo mental, lo biológico y lo social mediados por el
lenguaje y los artefactos, donde lo social esta basado en lo humano, y en cómo perteneciendo a una 
red/sociedad humana nos (re)hacemos humanos, pero también podemos lidiar con la dualidad estructura-agencia, cambiando las prácticas sociales, transformando tradiciones desde las tradiciones mismas, reinventando
artefactos, prácticas y comunidades desde las comunidades mismas (que constituye la segunda parte de esta 
tesis), ampliando la autonomía de ellas para ser, en un mundo donde las ocupaciones ontológicas pretenden 
qué sólo seamos como otros quieren.
La pregunta por cómo cambiamos los artefactos digitales que nos cambia es, en últimas, desde esta
reintepretación del diseño crítico, una pregunta por cómo nos hacemos más autónomos.

La preocupación del diseño por el mundo posible presente en varios autores,
debe estar acompañada los compromisos éticos del diseño respecto a cómo
construiremos entre todos y todas un mundo para todos y todas.
De esto precisamente se ocupa la siguiente sección, donde se retomará
la pregunta por el papel del diseño, en particular desde la formación
doctoral, que se dejó abierta previamente.

que ayudaron a tales descubrimientos.
Esta voz individual coincide con idea de un desarrollador principal y solitario 
en lugar de una comunidad, que no es infrecuente de la mayoría de proyectos
de software libre y código abierto, como han mostrado varias
métricas (Mako y OSS in numbers), pero también puede dar cuenta de
la génesis de una comunidad.





\input{hacker}




















































































































































































































































































































































































































































































\input{prehistoria}







































































































































































































































































































































































































































\input{grafoscopio}

\input{dataweek}

\input{prototipos}

% !TEX root = tesis.tex

% Front cover
% \includepdf{cover-front.pdf}

% Half-title
\author{Offray Vladimir Luna Cárdenas}
\title{Codiseñando Autonomías: \\ artefactos digitales amoldables, hacktivismo y ciudadanías}
%\title{Grafoscopio y el Data Week: \\
%	Aproximaciones desde el Diseño sobre cómo cambiamos los artefactos digitales que nos cambian}
\date{}
\maketitle

% Copyright page
\clearpage

% !TEX root = tesis.tex

%----------------------------------------------------------------------------------------
%	CAPITULO 4
%----------------------------------------------------------------------------------------

\chapter{Prehistoria}\label{prehistoria}

Este capítulo cuenta aborda las infraestructuras y prácticas que antecedieron y de
alguna forma allanaron el camino para aquellas que son centrales a esta tesis 
(Grafoscopio y el Data Week).
Estos caminos recorridos y prototipos que fallaron o dejaron de ser centrales,
constituyen un repertorio latente de soluciones y técnicas que pueden ser
desplegados en artefactos y prácticas posteriores (exaptación, en palabras
de \cite{jonas_design_2004}).
Mostrar dichos caminos permite reconocer ciertas apuestas que están presentes
en los artefactos actuales y revisar los trayectos que los constituyen o
podrían reconfigurar.
A eso se dedican las secciones a continuación.

\section{Hábitats digitales web}\label{hackbo-web}

Los primeros intentos por explorar el problema sobre cómo cambiar las tecnologías
que nos cambian, se hicieron a finales del 2010 y comienzos del 2011, esencialmente
explicando este problema a los miembros de la naciente comunidad de HackBo, en las
reuniones periódicas que teníamos en la casa del colectivo cultural, La Redada,
en el barrio Las Aguas, de Bogotá.
Eran exposiciones en exceso teóricas, que mencionaban términos como autopoiesis
y auto-referencialidad.
Se mencionaban tecnologías con dichas característica autoreferencial, como Leo
y Smalltalk, pero en general aquellas charlas encontraban poco eco en la comunidad.

Por aquel entonces también estábamos definiendo la infraestructura web que tendría
el sitio web de HackBo y consideré que esta sería una buena oportunidad para la investigación-acción,
que permitiera poner en diálogo mi investigación con los problemas cotidianos y apremiantes de
la comunidad.
La intensión sería configurar un espacio web que habitáramos los integrantes de HackBo,
Un hábitat digital, en palabras de Wenger %REF
y ver cómo en la medida en que lo poblábamos, lo ibamos extendiendo y cambiando,
de maneras similares a las experiencias previas como las que tuvimos con El Directorio
(referenciado en la sección \ref{mi-lugar}), pero superando las limitaciones de aquel entonces.

Hice una fuerte argumentación sobre que deberíamos tener una infraestructura propia y lo 
más autocontenida posible, de manera que contáramos con un sólo sitio autónomo que contuviera buena
parte de nuestra presencia: blogs, wikis, videos, enlaces, archivos, etc.
Sugerí e implementé Cynin\footnote{\url{http://cyn.in/}}, pues su arquitectura era robusta 
(basado en Zope/Plone) y estaba hecho en un lenguaje de \emph{scripting} Python, que si bien no era 
tan popular como PHP para aplicaciones web, sí era usado en múltiples dominios además de la web, 
así que el aprendizaje del mismo podría permitirnos movernos a otras temáticas.
Además, estaba mi experiencia en el uso de Cynin para configurar el hábitat digital para 
el proyecto de investigación Narratopedia %REF.
y creía que dicha experiencia podía ser traída de los limitados marcos académicos al
grueso de la comunidad.

Pero Cynin reveló ser extremadamente complejo y con una alta curva de aprendizaje.
Habían muy pocos expertos locales en la infraestructura Zope/Plone que no eran muy
cercanos al espacio.
El punto de quiebre se dio cuando el sitio de HackBo en Cynin se hizo inestable
por el SPAM\footnote{El SPAM es la sigla con la que se denomina al uso de sistemas digitales
	para el envío de información no deseada, usualmente con fines publicitarios, pero también
	con intensión de apropiar información de terceros o insertar código malioso en sus dispositivos
	electrónicos. Para mayor información véase: \url{https://en.wikipedia.org/wiki/Spamming}}.
Luego de hacer un backup de la información, decidí cambiar la infraestructura por
algo que fuera fácil de entender, extender y cambiar, que no requiriera de altos
recursos externos.
La argumentación esta vez ocurrió en persona, en la siguiente sede de HackBo,
la Fundación Buinaima.
La mayoría de la gente quería ir por algo prehecho en el popular gestor de sitios web
\emph{WordPress}\footnote{\url{https://wordpress.org/}}, que fuera de fácil montaje y 
con la ventaja de una gran cantidad de \emph{plugins} preexistentes.
Mi contrargumento fue que no quería algo que sólo pudieramos modificar vía cosas
prehechas, pues como había ocurrido en la comunidad con el wiki comunitario 
\emph{El Directorio}, que vio su auge y caida entre 2004 y 2008, cuando lo prehecho
no satisfaciera nuestras necesidades, tendríamos que migrar a otras plataformas
(como ocurrió en desbandada en aquel momento) o estar en la posibilidad de extender
las nuestras, caso en el cual sería bueno que estén hechos en lenguajes más
versátiles y con ecosistemas más diversos, como Python en lugar de PHP.
A la mayoría, las tecnologías subyacentes no les importaban y querían una solución
rápida a nuestro problema de presencia web y una minoría alentaba la experimentación
y la apropiación de nuevos saberes y tecnologías, con motivo de dicha presencia y si
bien no estaban interesados ellos mismos en tal exploración, si apoyaban ``moralmente'',
según sus propias palabras, que HackBo fuera un lugar donde ésta ocurriera.

\afterpage{
	\begin{figure*}[tb]
		\centering
		\subfloat[]{
			\includegraphics[width=0.3\linewidth]{./Parte2/hackbo-cynin.png}
			\label{subfig:hackbo-cynin}}
		\quad
		\subfloat[]{
			\includegraphics[width=0.3\linewidth]{./Parte2/hackbo-web2py.png}
			\label{subfig:hackbo-web2py}}
		\\
		\subfloat[]{
			\includegraphics[width=0.3\linewidth]{./Parte2/hackbo-grav-1.png}
			\label{subfig:hackbo-grav-1}}
		\subfloat[]{
			\includegraphics[width=0.3\linewidth]{./Parte2/hackbo-grav-2.png}
			\label{subfig:hackbo-grav-2}}
		\subfloat[]{
			\includegraphics[width=0.3\linewidth]{./Parte2/hackbo-grav-3.png}
			\label{subfig:hackbo-grav-3}}
		\caption[Histórico de los sitios web de HackBo]
		{Diferentes hábitats digitales web para HackBo, en orden cronológico. 
			Arriba, capturas antiguas recuperadas de Internet Archive: 
			la figura \ref{subfig:hackbo-cynin} (ver \url{https://is.gd/4zIRKi}), 
			corresponde al primer espacio integrado, pero muy complejo (usando Cynin) y 
			la figura \ref{subfig:hackbo-web2py} (ver \url{https://is.gd/9x1TXo}) corresponde al
			la segunda versión, integrable a partir de piezas sencillas (web2py + dokuwiki + Fossil).
			Abajo: Diferentes partes de la tercera y actual versión sitio del web de HackBo 
			(ver \url{http://hackbo.co/}), que incorpora aprendizajes de los sitios  previos, 
			usando tecnologías aún más sencillas en cuanto a almacenamiento y también extensibles 
			(Grav, Fossil).
			El sitio se ha mantenido relativamente estable desde esta última migración y no han
			habido muchos aportes de funcionalidad o contenido al mismo.}
		\label{fig:hackbo-web}
	\end{figure*}
	\clearpage
}

Se planteó una bifurcación, propia de las comunidades hacker y una resolución 
desde la \emph{tiranía del hacedor}: cualquiera podría implementar el sitio web, 
en la tecnología que quisiera, siempre y cuando mostrara resultados en el corto tiempo.
Leonardo hizo una página de llegada (\emph{landing page}) en HTML y Javascript que resolvía la 
contingencia y con él y Jorge Guevara implementamos el primer borrador del sitio usando un 
\emph{web framework} hecho en Python, llamado web2py\footnote{\url{http://web2py.com/}}.
Nadie más implementó el sitio en PHP.
Este es un ejemplo de cómo se dice con acciones/infraestructuras, desde las dinámicas del
hackerspace, mostrado desde una perspectiva más teórica en la sección \ref{hackbo}.

Esto marcó el inicio de un primer hábitat digital %LATERAL: Wenger.
para HackBo, que era principalmente hecho por mi, con ayuda de miembros de la
comunidad y otros cercanos, como Iván Pulido.
Allí se experimentaron algunas características, como adicionar enlaces o
noticias para el sitio y la de mayor uso colectivo: la programación de eventos y
actividades dentro del espacio de HackBo, con su respectiva publicación de actividades
pasadas y venideras.
Las pocas solicitudes externas no fueron implementadas rápidamente.
La idea era alentar que las mismas personas en la comunidad reportaran e implementaran
las soluciones, expandir el conocimiento sobre dicho hábitat y cómo está construido.
Pero la estrategia fue inadecuada y no despertó mayor interés.
El sitio se ceñía a su funcionalidad básica de eventos y otras funcionalidades,
como la del wiki, fueron delegadas en infraestructuras prehechas, administradas
por nosotros en nuestra propia infraestructura, pero hechas por otros.

Esta combinación entre lo prehecho y lo hecho por unos pocos miembros dentro
de HackBo, permitió lidiar con cierto descontento por la ausencia de características
en el sitio implementado en web2py.
Para las cosas específicas haríamos desarrollos propios (usando web2py y Python),
y para otras apelaríamos a software libre y sus \emph{plugins}, como 
Dokuwiki\footnote{\url{http://dokuwiki.org/}}, el potente y sencillo wiki hecho en PHP,
lo cual generaba un punto medio entre las dos posturas en la comunidad.
Aún así, no muchos miembros usaron el wiki.

De nuevo el sitio de HackBo se cayó, aunque esta vez no fue por el SPAM.
Ya contábamos con una sede exclusiva en nuestra actual localización en el barrio Javeriana.
Como implementador, anfitrión y proponente de sitio en las tecnologías precedentes
(Cynin y web2py), era responsable por él y sentí que era también el momento de desentenderme del mismo.
Su impacto en visibilidad de la comunidad era alto, al ser el lugar de entrada en línea a la misma.
Los requerimientos frente a su correcto funcionamiento o la ausencia de características,
sin ser frecuentes, eran demandantes cuando ocurrían y su gestión y modificación era solitaria.
La funcionalidad principal de gestionar eventos había sido delegada por otros miembros del
hackerspace en una infraestructura externa de Meetup y si bien no teníamos 
control sobre ella, la convocatoria había crecido, pues se adecuaba a las lógicas de
esa web feudal, en la que otros ponen la infraestructura y nosotros los contenidos y las
interacciones.
Esta normalización de esa forma de ver y usar la infraestructura hacía que muchas
personas y comunidades usaran ya este tipo de lugares y fuera fácil encontrar otras comunidades
y lanzar convocatorias genéricas en ese sitio, con el consecuente aumento de asistentes a los
eventos.

Así que migré el sitio web de HackBo a otra infraestructura web, llamada 
Grav \footnote{\url{https://getgrav.org/}}, que al estar en PHP, y no requerir de base de datos, 
tenía la ventaja de ser fácilmente desplegable en servidores web relativamente genéricos, 
sin preocuparse por las migraciones de datos (cosa que no pasaba con Cynin o web2py).
El uso de lenguajes de etiquetamiento ligeros para documentación 
(Markdown\footnote{\url{https://es.wikipedia.org/wiki/Markdown}}) y descripción de datos 
(Yaml\footnote{\url{https://es.wikipedia.org/wiki/YAML}}), similar al que usa en Grav, 
ya había sido prototipado por mi previamente en un proyecto en web2py (llamdo Brea) 
y era neutral respecto al lenguaje de programación, pudiendo intervenirse y extenderse en
Python, PHP, Smalltalk, Javascript o una amplia gama de lenguajes que entendieran
dichos formatos\footnote{Brea fue un proyecto que reenfoqué ahora desde Pharo, con los
	saberes nuevos adquiridos a lo largo de este doctorado.
	Algunos desarrollos con esta nueva encarnación de Brea serán mostrados en la parte 3 de 
	este escrito (otro ejemplo más de exaptación.)
	Un sitio actualizado para Brea está en \url{http://smalltalkhub.com/\#!/~Offray/Brea}}.
Esto me permitía entregar el sitio a otra persona que lo quisiera administrar
o cambiar e hice el respectivo correo a la lista, %REF: Correo Lista HackBo
indicando que esta infraestructura estaba lista para quien quisiera hacerse cargo de 
ella o migrarla a otra.
Es la tecnología en la que ha estado funcionando el sitio hasta el momento y sigo
responsable de él, aunque es sólo una página de llegada (\emph{landing page}) y la
presencia en línea de la comunidad combina infraestructuras propias y comunitarias 
(principalmente el sitio web y algunos repositorios de código) con ajenas:
Meetup\footnote{\url{http://www.meetup.com/es/hackbo/}}, 
Twitter\footnote{\url{http://twitter.com/hackbo}}, 
Facebook\footnote{\url{https://www.facebook.com/HackBo}} y repositorios de código en 
GitHub\footnote{\url{https://github.com/HackBo}} y 
Fossil\footnote{\url{http://mutabit.com/repos.fossil/hackbo-web2/}}.

Estas formas de habitar la web, permitieron apreciar dónde estaban los intereses de
la comunidad de HackBo, el caracter diverso de dichos hábitats, e incluso la fatiga
de mantenerlos en solitario.
Pero lo más importante es que permitieron enfocarme en otro tipo de experiencias más
específicas de mis propios intereses y algunas personas cercanas a HackBo, en lugar
de en el grueso de la comunidad y también iniciaron una confianza respecto a la posibilidad
de programar soluciones a medida desde apuestas propias (particularmente web2py y Fossil),
que profundizaría y revaluaría después, hasta llegar a Grafoscopio.
De estas exploraciones más específicas se encargan las siguientes secciones.
 
\section{Indie Web Science}\label{indie-web-science}
 
\begin{figure}[tbh]
	\centering
	\includegraphics[width=0.9\linewidth]{./Parte2/leo-tesis.png}
	\caption[Un primer borrador de la tesis, escrito en el meta-editor Leo]
	{Uno de los primeros borrador de esta tesis, escrita en el meta-editor 
		\href{http://leoeditor.com/}{Leo}, de donde deriva la inspiración de organizar la escritura 
		forma arbórea.
		Otros detalles de estas fuentes de inspiración son explorados en esta sección.}
	\label{fig:halfspace}
\end{figure}


Desde finales del 2012, había empezado a explorar formas de combinar la escritura 
arbórea de Leo\footnote{\url{http://leoeditor.com/}}, con la escritura interactiva de libretas 
en IPython\footnote{\url{https://ipython.org/}}, lo cual permitiría ir agregando estructura progresiva 
y emergente del primero a la computación  exploratoria propia del segundo.
En aquel entonces escribí en la entrada al blog titulada 
\emph{On ``deepness'' and complexity of IPython documents}\footnote{\url{https://is.gd/4JEVo1}}
(\cite{luna_cardenas_deepness_2013-1}):

\begin{quote}
	Fernando Pérez, primer autor y co-lider de proyecto de IPython, ha hablado acerca de la naturaleza explorativa
	de la computación científica y cómo esto se mantiene también para muchos usuarios de computador.
	Estoy de acuerdo. La mayoría de las veces, los usuarios (científicos) no tienen un estricto conjunto de reglas
	predefinidas para orientar o restringir  su interacción con los computadores.
	Una pregunta entonces, es cómo esta naturaleza explorativa de la interacción con el computador,
	empezará a mostrar estructura progresiva cuando la complejidad de la exploración y la escritura se incrementen.
	Este es un problema que todo escritor confronta y es incluso más importante/visible
	si se tienen documentos interactivos
\end{quote}


y hacía un recorrido por varias plataformas de escritura estructurada y publicación en y fuera de línea 
(TeXmacs\footnote{\url{http://texmacs.org/}}, Tiddly Wiki\footnote{\url{https://tiddlywiki.com/}}, 
Leo e IPython) y sobre algunos experimentos para combinar escritura arbórea y publicación en línea con 
documentos interactivos en IPython y afirmaba:

\begin{quote}
	Pienso que complejos documentos interactivos (científicos) que ``emergen'' de la exploración,
	necesitan una interface arbórea para la estructuración progresiva, por las razones ya mencionadas
	en el caso de Leo.
	De hecho argumentaría que Leo e IPython comparten un profundo interés por la introspección y tener
	esta característica implementa en un [documento arbóreo] haría las libretas de IPyhon realmente poderosas.
	Podría pensarse incluso en un notebook de IPython como celdas organizadas/partidas en subárboles, que
	habilitarían otro nivel de agregación a las celdas y pienso que los árboles y las celdas son casi todo lo que
	los usuarios necesitarían para organizar documentos de IPython de la complejidad de una tesis.
	Incluso con esta metáfora de interacción, los usuarios podrían construir complejas aplicaciones web
	hechas sobre IPython, usando subárboles internos para las partes internas de las aplicaciones y las
	partes externas para aquello con lo que el  usuario web puede interactuar, de una manera similar a
	ocultar las partes internas de la escritura al lector de mi tesis 
	(pero, por ahora, esto va más allá de lo que este escrito quiere proponer).
	%NOTA: valdría la pena conectarlo con el escrito de cómo hago la tesis?
\end{quote}

\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{Parte2/offrayLC-status-293188236019388417.png}
	\caption[Trinos a Fernando Perez y Brian Granger]
	{Conversación breve con Fernando Pérez y Brian Granger, co-líderes del proyecto IPython, 
		sobre la posibilidad de implementar una interface arbórea para la escritura de documentos 
		interactivos (ver \url{https://is.gd/H7XY19}). }
	\label{fig:fperez-trino}
}

Finalmente expresaba mi deseo por que esta idea tuviera acogida y no me tocara implementarla a mi mismo:

\begin{quote}
	Espero que la comunidad de IPython piense que una metáfora adecuada para escribir 
	progresivamente documentos complejos y profundos es necesaria si queremos que IPython 
	sea la herramienta para una experiencia de escritura continua en este contexto, y que 
	los árboles son la vía en ese sentido.
	Por supuesto la experimentación sería necesaria y con optimismo, no estaré escribiendo el código sólo
	para probar my tesis y esta idea sería sonora e interesante, incluso viniendo de un no programador.
\end{quote}

Pero no fue así.
Dirigí un breve trino con copia a Fernando Pérez (ver figura \ref{fig:fperez-trino} y 
\cite{luna_cardenas_deepness_2013}), sobre dicha idea e hice algunas preguntas sobre cómo 
implementarla en la arquitectura de ese entonces de IPython \cite{}. %PENDIENTE: Ref correo o GitHub
Pero no hubo mayor interés y tampoco mayor esfuerzo de mi parte en mover dicha idea en la 
comunidad internacional, al menos no sin tener más prototipos desarrollados localmente.

Empezamos, entonces, a explorar las ideas de escritura interactiva y publicación en línea,
en 2014, con personas cercanas a HackBo, que no eran miembros de la comunidad nuclear: 
Rafael Medina, Iván Pulido y Camilo Hurtado, que se sumaron a varias actividades en lo que 
terminó por llamarse los talleres de \emph{Indie Web Science}.
Si bien el fuerte de la exploración seguía recayendo en mi, Rafael, Camilo e Iván
fueron claves en acotar el problema, mirar sus alcances y complejidades, e incluso
se sumarían luego a ediciones futuras de la transformación desde los talleres de 
\emph{Indie Web Science} en las primeras ediciones del \emph{Data Week}.

Los nombres en inglés de dichos eventos ayudaban a comunicarlos a comunidades internacionales, 
posicionarlos en motores de búsqueda y también a establecer conexiones y diferencias con prácticas 
emergentes que ya tenían nombres posicionados.
Para el caso de \emph{Indie Web Science}, se evocaba que compartíamos ciertas prácticas asociadas
al movimiento de la \emph{Indie Web}\footnote{\url{http://indiewebcamp.com/}} respecto a tener 
infraestructuras propias y autónomas para alojar y publicar nuestros contenidos y ser
los principales y primeros usuarios de aquello que construíamos, como práctica
cotidiana de nuestra presencia en línea, en lugar de sólo recomendarlo para otros 
(algo llamado \emph{selfdogfooding}) y que seríamos dueños y hospederos de nuestros propios datos.
Como mencionaba en la entrada al blog titulada 
\emph{Indie web science = indie web + open/garage science?}  (\cite{luna_cardenas_indie_2014}):

\begin{quote}
	
	Porque estamos usando tecnologías portables, auto-contenidas y fáciles de aprender para este
	experimento, ellas pueden ser colocadas en una memoria USB o un computador de bajo costo tipo
	Rasberry Pi.
	Y es fácil de imaginar algunos escenarios no muy distantes, [donde haya] un espectro completo
	de colaboración en narrativas de datos que cubra usuarios singulares/múltiples escritura 
	en/fuera-de línea, computación y visualización en varios temas, desde la publicación académica 
	a la ciencia ciudadana y el periodismo de datos.  
	
	Acá estamos rascando nuestra propia comezón usando alguna solución incompleta auto-construida
	y agregaría código [fuente] sucio, en el sentido de que no tenemos aún buenas práctica de 
	programación.
	[...] Lo que hemos hecho tiene esta clase de espíritu \emph{indie} en el sentido del
	\emph{selfdogfooding} y también \emph{poseer tus datos} y tu infraestructura 
	para publicación usando software y formatos libres y de código abierto para ello.

\end{quote}

Es de anotar que acá se empezaba a vislumbrar ya una apuesta por lo que denominé luego 
las \emph{infraestructuras de bolsillo}, que podían ser ejecutadas desde hardware modesto, con o sin 
conectividad, eran simples y autocontenidas, lo cual se volvería un concepto importante después
en las prácticas con Grafoscopio, el Data Week y las Data Rodas y en distintos proyectos, como
los de los \emph{Panama Papers}, particularmente desde la perspectiva de hacer la investigación
reproducible y decolonizar la infraestructura, como veremos más adelante. %DONDE?
De hecho, en la misma entrada al blog, me refería a otro tipo de infraestructura baratas, que cupieran 
en un bolsillo y se separaran de las tecnologías centralizantes populares de Internet:

\begin{quote}
	Alguna gente dice  que necesitamos una especie de \emph{GitHub para la ciencia}\footnote{
		GitHub (\url{https://github.com/}) es el lugar que centraliza muchas de las actividades
		de desarrollo de software, con alrededor de 80 millones de repositorios de código fuente
		para estos proyectos.
		Su influencia es notoria, pero también contradictoria, pues Git surgió como propuesta
		al desarrollo cerrado propuesto por BitBucket, pero GitHub, que facilita desde interfaz web
		el uso de Git, es cerrado e incluso los desarrolladores de software que sabrían como 
		modificarlo, no pueden hacerlo %PEN: Carta
		y vuelven a surgir alternativas desde las lógicas de bifurcación, en proyectos como 
		GitLab o Gogs.
		Un interesante análisis de los peligros de tales centralimos estan en Egbal, %REF
		que luego fue contratada por GitHub.}.
	No concuerdo.
	Lugares como esos tienden a construir
	monoculturas\footnote{\url{http://indiewebcamp.com/monoculture}} 
	(por ejemplo alrededor de Git [...]).
	Pienso que lo que necesitamos es más un \emph{BitTorrent para la ciencia}\footnote{
		BitTorrent (\url{https://is.gd/w_bittorrent}) es un protocolo descentralizados de 
		comunicación entre pares para la transmisión y sincronización de archivos.
		A diferencia de GitHub, no hay un lugar que centralice la interacción y todos
		los nodos hacen las veces de emisores (servidores) y receptores (clientes).},
	donde diferentes implementaciones, como aquellas exploradas/propuestas acá, puedan hablar
	con otras más visibles [...].
	Para ello, los protocolos y los metadatos serán más importantes en habilitar la interoperabilidad
	entre diferentes abordajes, pero siguiendo el 
	consejo\footnote{\url{http://indiewebcamp.com/Principles}}
	del movimiento por la Indie Web:
		\begin{itemize}
			\item La experiencia de usuario (UX) es más importante que los protocolos.
			\item Usa datos visibles para los humanos primero y las máquinas después.
			\item Construye herramientas para tí mismo, no para todos tus amigos.
			\item Construye para la web duradera.
			\item Diviértete.
		\end{itemize}
		
\end{quote}
	
Estos y otros principios compartidos con el proyecto fueron un descubrimiento clave respecto
a dejar intentar convocar o complacer a los miembros de la comunidad nuclear de HackBo, como
lo había hecho desde los hábitats digitales web antes mostrados y trabajar más desde procesos
de largo aliento, centrados en unos pocos que estábamos yendo a los talleres de 
\emph{Indie Web Science}, desde la experiencia que teníamos al usar y construir dichos lugares
más pequeños para proyectos más puntuales y personales que vincularan formas de contar y publicar
historias, mediadas por datos y visualizaciones, desde infraestructuras propias y alternativas.

También retomé estos principios cuando empecé a experimentar con otras metáforas escriturales
que me permitieran abordar las complejidades de la tesis y sus múltiples capas empleando 
Leo \cite{luna_cardenas_forma_2014}, un metaeditor de texto para dar cuenta del caracter no lineal 
de la escritura y sus niveles de ``profundidad'', de los cuales el texto final en PDF es sólo la 
``superficie''.
Leo permite escribir de manera``arbórea'', para dar cuenta de lo anterior, pero además la estructura
de árbol es auto-referente, con lo cual se puede usar una de las ramas para definir, a través del 
\emph{scripts} lenguaje de programación Python, recorridos en todo el árbol, decir qué niveles de 
profundidad ignorar para producir el PDF. 
Para eso se elaboraron dos  en el lenguaje de programación Python, 
El desarrollador lider de Leo es Edward K. Ream.

En estas exploraciones también se definieron elementos que luego serían importantes para la creación
de Grafoscopio: el uso de Markdown de Pandoc como lenguaje de etiquetamiento ligero por su soporte
para referencias bibliográficas, notas al pie, metadatos expresado en YAML; la integración con el 
gestor blbiográfico Zotero para manejar dichas referencias y la creación de una colección abierta 
en el mismo para el doctorado, (que alcanzó más de 3400 items desde entonces), así como reiterar 
el uso de Fossil, un sistema de control de versiones distribuido, minimalista, autocontenido 
ligero y fácil de usar para publicar archivos de textos, imagen, código fuente y su historia.
donde coloqué los escritos hechos y exportados desde Leo, integrándolos a un repositorio público 
que había creado para el doctorado desde el 2011 
(véase: \url{mutabit.com/repos.fossil/doctorado-offray/}) y que ha contenido la historia de varios 
artefactos creados durante el mismo, incluida esta misma tesis.

Las piezas de infraestructura se estaban juntado.
Pero la necesidad por estas narrativas computacionales, que mezclaran datos e interacción
se hizó más evidente a partir de unas hackatones que surgieron como resistencia desde
HackBo a la enagenación del discurso hacker por parte del el estado, desde el discurso
del ``emprendimiento'', pero con unas lógicas de explotación.
Estas serán ampliadas en la siguiente sección.

%NOTA: buscar fechas para Indie Web, Gobernaton y entrega del portal.

\section{La Gobernatón: La hackatón como acto de resistencia y crítica desde la sociedad cívil}\label{gobernaton}

Las \emph{hackatones} son maratones de prototipado y resolución de problemas.
El término, que a su vez combina los términos \emph{hack} y \emph{maratón} parece haber
surgido, según la Wikipedia \cite{noauthor_hackathon_2017}, tanto entre los desarrolladores del sistema
operativo OpenBSD, como entre los miembros del equipo de mercadeo de \emph{SUN Microsystems}.
Desde entonces este término ha sido reapropiado, diversificado y dislocado para
incluir diversos tipos de hackatones (10, en la taxonomía de la Wikipedia)
y ha sido aproximada de manera crítica por autores como Irani (2015) \cite{lilly_irani_hackathons_2015} 
y Schrock %REF: Shrock, 
denunciando lógicas de solucionismo tecnológico y una manera limitada y limitante 
de concebir la ciudadanía, pues como afirma Irani, ``las hackatones algunas veces
producen tecnologías, y ellas siempre, sin embargo, producen sujetos''(p. 2), en la medida
en que configuran imaginarios y formas de acción respecto a qué es ser un ciudadano
y cómo estas formas de ciudadanía pueden ser mediadas por tecnología desde 
una percepción de ``innovación'' y una ``política que favorece la acción rápida y
forzada entre colaboradores socialmente similares, sobre las contestaciones de la
democracia masiva o la lenta construcción de coaliciones sobre la diferencia''. (p. 3)

El fenómeno hacker, multisituado y de orígenes diversos, también está siendo 
gentrificado, como diría Scott, %REF: Hackers Hackeados
en distintos lugares con la lógica uniformizante del ``emprendimiento''. 
No importa si se trata en India, (Irani: Hackatones y la creación del ciudadano emprendedor), 
Estados Unidos (Schrock: Hackatones sin hackeo y Scott: 
El Hacker hackeado: como los yuppies hackearon el ethos hacker original),
o Colombia, donde el programa Gobierno en Línea lanzó la \emph{hackatón de gobierno móvil} (HGM).
Al igual que en otras latitudes, dicha hackatón, iniciada en Bogotá,
tenía un fuerte pensamiento desde el solucionismo tecnológico, 
con el sesgo hacia la acción emprendedora y a cruzar la distancia sin caminarla,
denunciada por Irani:

\begin{quote}
	La frase ``sesgo a/por/hacia la acción'' era empleada rutinariamente
	para describir la figura de un hacedor emprededor que usaba atajos a la
	cinta roja burocrática y las largas deliberaciones en busca del eficiente, progreso inspirado.
	Progreso, in este discurso profesional, con frecuentes soluciones visibles
	—servicios, infraestructuras, negocios y orden público—
	en lugar de justicia procedimental o redistribución de los 
	derechos.\footnote{Esta lógica de soluciones visibles mercadeables es consecuente con la
			provocación de Scott sobre cómo el espíritu rebelde del hacker ha sido orientado
			hacia la consecución y el servicio al capital.}
\end{quote}

\begin{quote}
	Este sitio realmente existente de prácticas de diseño reveló que sus políticas estaban en sus formas
	y sus normas — en su manufacturada urgencia, en la distancia entre el estudio y el mundo,
	y en la ecología de medios que hacia posible prometer cruzar la distancia sin caminarla.
\end{quote}

La lógica del espectáculo en la hackatón (Schrock) también estuvo presente,
en la HGM, con las respectivas campañas en redes sociales 
y, luego, (quizás reforzado por la crítica hecha desde HackBo con la Gobernatón) 
con la idea de adscribirse a otros eventos de asistencia masiva, 
como la Campus Party de 2013 y los eventos de emprendiento del \emph{Startup Weekend}.

Pero lo que llamaba fuertemente la atención y prendió las alertas en 
Twitter y Facebook, tanto en las comunidades de base tecnológica como en la emprededora, 
era el costo del contrato y los modelos de reparto de dividendos, lo que
generó una \emph{contrahackatón}, 
la \emph{Gobernatón} \footnote{El nombre fue resultado de una broma: Si desde el Gobierno
	no sabían organizar una \emph{hackatón}, desde HackBo íbamos a organizar una \emph{Gobernatón}.},
que organicé y lideré desde HackBo. 
Como afirmé en aquel entonces:

\begin{quote}
	La Gobernaton es una iniciativa ciudadana de innovación social y abierta. Inició como una crítica 
	constructiva a una iniciativa de MinTIC en 2013 que gastó 2700 millones de pesos en la supuesta 
	inversión en innovación social, pero que pararon, principalmente, en las arcas de intermediarios 
	en lugar de en la construcción de beneficio colectivo. 
	El balance de la Gobernatón como contrapropuesta cívica fue bastante alentador:
\end{quote}

La participación fue plural: vinieron miembros de HackBo y personas externas.
La mayoría hicieron código, otros se encargaron de publicitar el evento,
algunos querían explicar teorías políticas, otros querían aumentar la base de
datos y/o hacer la corta charla publicitaria (\emph{pitch}) para sus emprendimientos.
Algunas empresas y fundaciones donaron la pizza.
Entre usa sesión y la otra del evento la población varió y si bien participaron intensivamente
al comienzo, al final del mismo, fueron disminuyendo.
El listado de prototipos fue diverso: algunas de ellas eran aplicaciones web,
otras aplicaciones móviles (\emph{apps}).
La mayoría de prototipos no sobrevivió ni continuó más allá de este primer encuentro 
(como también han observado Irani, Schock y EngineRoom).

\subsection*{De las apps y los portales a las narrativas computacionales}\label{hacia-narrativas-computacionales}

Durante la primera gobernatón se hizo claro para mi, que una estrategia
alternativa a la de crear una \emph{app} o un portal web era la de contar una historia
soportada por datos, pues nuestros argumentos sobre lo irregular del
llamado del Ministerio de las TIC a ``participar'' de la hackatón de gobierno
en línea, era sustentada por los datos de la convocatoria colocados en
la web y los cambios que ocurrían en los mismos mientras la crítica circulaba
en redes sociales.
%NOTA[ vincular capturas del hashtag y copias del wiki]  
Tecnología como los números de integridad criptográfica (o números \emph{hash}) 
empleados para auditar cambios en archivos, eran usados ahora para auditar cambios 
en la convocatoria, o los cuadernos interactivos de IPython, eran usados ahora 
para sustentar la narrativa, integrando datos, prosa y publicándo nuestos avances en Internet
y nos permitían participar de la conversación de nuevos modos y con nuevas
potencias.
Si bien las apps y portales podrían ser pasajeras (como el tiempo demostró),
las técnicas para contar historias e interlocutar con los poderes hegemónicos, 
particularmente del gobierno, basados en datos y técnicas computacionales 
podrían sobrevivir al evento específico de la gobernatón.
Era la historia que se desplegaba sobre estas nuevas formas de participación 
ciudadana y las técnicas para contarla lo fundamental.
Encontré que este tipo de iniciativas también estaban tomando cuerpo en otras
latitudes bajo el nombre de periodismo de datos.
%NOTA[Captura de pantalla de dokuwiki con las referencias respectivas]

La combinación de estas tecnologías para argumentar e interlocutar con el
Estado recogía lo que habíamos hecho en los talleres de \emph{Indie Web Science}
referidos a crear y publicar libretas de notas/argumentos computacionales,
y también se convertiría en un puente con lo que vendría después, intentando
transpasar los límites de tales tecnologías complicadas y encuentros intensivos, 
pero sin continuidad y la difusión de la experticia: %NOTA: Incluir: http://mutabit.com/offray/static/blog/output/posts/medios-en-colombia.html ?
Grafoscopio, como artefacto y El Data Week y las Data Rodas y otros encuentros, como 
experiencias de aprendizaje.
Este será el tema de los capítulos siguientes.

								}
							],
							#parent : @93,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Lines of code',
							#body : '| totalLines myPackages myPackagesSizes b ds lb |
myPackages := {
\'Brea\'.
\'Dataviz\' .
\'Grafoscopio\' . 
\'Grafoscopio-Utils\' .
\'Fossil\' .
\'Pubiblio\'}.
myPackagesSizes := OrderedDictionary new.
myPackages do: [ :pkg |
\tmyPackagesSizes at: pkg put: pkg asPackage linesOfCode].
totalLines := myPackagesSizes values sum.

b := RTGrapher new.
ds := RTData new.
ds barChartWithBarTitle: #key rotation: 0.
ds points: myPackagesSizes , (Array with: \'\' -> #()).
ds y: [ :as | as value size ].
b add: ds.
b axisX
\tnoTick;
\tnoTitle.
b axisY noDecimal.
b maxY: 5.
b build.
lb := RTLegendBuilder new.
lb view: b view.
lb addText: \'Total lines of code: \', totalLines asString.
lb build.
^ b view',
							#tags : OrderedCollection [
								'código'
							],
							#children : OrderedCollection [ ],
							#parent : @93,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@96,
				@99,
				@103,
				@108,
				GrafoscopioNode {
					#header : '%borrar Anexos',
					#key : '',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [
						GrafoscopioNode {

						}
					],
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@116,
				GrafoscopioNode {
					#header : 'Gráficas',
					#key : '',
					#body : 'Los códigos para hacer las gráficas fueron movidos al archivo workbook.leo, que se abre por omisión.
Por lo pronto es mejor trabajar dichos trozos desde allí, pues leo tiene mejores atajos de teclado y maneras
de aumentar la fuente (al igual que TeXStudio), lo que es un factor de ergonomía bien importante para
escritura prolongada de texto.

"Esto apunta al repositorio en GitHub, pues será más fácil clonarlo y adaptarlo
luego al diplomado \'alvicoda\', sin embargo el repositorio aún no está completo.
La intensión de todos modos es tener los enlaces de referencia, para luego traducirlos
con Amara al español y presentarlos durante el diplomado."',
									#tags : 'código',
									#children : OrderedCollection [ ],
									#parent : @128,
									#level : 3
								}
							],
							#parent : @125,
							#level : 2
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						'',
						''
					]
				},
				@128,
				@131,
				GrafoscopioNode {
					#header : 'Artículos',
					#body : 'Dada la relevancia que ocupan los artefactos de software en la tesis y la intensión
explícita de la misma de crear y validar objetos no hegemónicos de conocimiento,
que vayan más allá del fetichismo por el artículo en la publicación indexada y sean
consistentes con las epitemologías del diseño, presentadas en la primera parte,
acá se ha optado por presentar los dos artefactos de software a la publicación

								GrafoscopioNode {
									#header : 'Announcing The Journal of Open Source Software | Weakly Typed',
									#body : '',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										'',
										'',
										'',
										'http://www.arfon.org/announcing-the-journal-of-open-source-software'
									]
								},
								GrafoscopioNode {
									#header : 'Author Guidelines',
									#body : '',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										'',
										'http://joss.theoj.org/about#author_guidelines'
									]
								},

											#body : '> The Journal of Open Research Software (JORS) features peer reviewed Software Metapapers describing research software with high reuse potential. We are working with a number of specialist and institutional repositories to ensure that the associated software is professionally archived, preserved, and is openly available. Equally importantly, the software and the papers will be citable, and reuse will be tracked.

> JORS also publishes full-length research papers that cover different aspects of creating, maintaining and evaluating open source research software. The aim of the section is to promote the dissemination of best practice and experience related to the development and maintenance of reusable, sustainable research software.',
											#tags : OrderedCollection [
												'text'
											],
											#children : OrderedCollection [ ],
											#parent : @148,
											#level : 4,
											#links : OrderedCollection [
												'',
												'',
												'',
												'',
												'http://openresearchsoftware.metajnl.com/'
											]
										},
										GrafoscopioNode {
											#header : 'SoftwareX',
											#body : '> SoftwareX aims to acknowledge the impact of software on today\'s research practice, and on new scientific discoveries in almost all research domains. SoftwareX also aims to stress the importance of the software developers who are, in part, responsible for this impact.

Es publicado por Elsevier, a pesar de ser Open Access. Mejor apoyar otras iniciativas que no tengan asociaciones a editoriales con prácticas de privatización de conocimiento y explotación de los académicos como esta.',
											#tags : OrderedCollection [
												'text'
											],
											#children : OrderedCollection [ ],
											#parent : @148,
											#level : 4,
											#links : OrderedCollection [
												'',
												'',
												'https://www.journals.elsevier.com/softwarex/'
											]
										}
									],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										''
									]
								}
							],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

  # References
  ',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

  # References
  ',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

						'',
						'',
						'',
						'',
						''
					]
				},
				@137,

				@140,
				@144,
				@148,
				@151,
				@155,
				@161,
				@165,
				GrafoscopioNode {
					#header : 'Participación en Eventos',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [
						GrafoscopioNode {
							#header : 'Hackademia',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Smalltalks 2015',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'ESUG 2016',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Big Data from the South',

									#tags : 'código',
									#children : OrderedCollection [
										GrafoscopioNode {
											#header : 'Subcolección BDS',
											#body : '(ZoteroLibrary new groupID: \'\') subcollection:\'6GE8GRDX\'',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										},
										GrafoscopioNode {
											#header : 'Subcolección como BibTeX',
											#body : '(ZoteroLibrary new groupID: \'329470\') subcollectionAsBibTeX: \'6GE8GRDX\'',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										},
										GrafoscopioNode {
											#header : 'BibTeX as file',

\tifTrue: [ bibFile delete ] 
\tifFalse: [ bibFile ensureCreateFile ].
bibFile writeStreamDo: [ :stream | stream nextPutAll: bibTeXData ].
bibFile
',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												'',
												'http://ws.stfx.eu/4138G3OYJZ9I',
												'http://ws.stfx.eu/5NQ4UFNDRO9M'
											]
										}
									],
									#parent : @185,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'ISEA',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [
								GrafoscopioNode {
									#header : 'Items de la subcolección',
									#body : '(ZoteroLibrary new groupID: \'204755\') subcollectionAsBibTeX: \'QE5NGJXF\'',
									#tags : 'código',
									#children : OrderedCollection [ ],
									#parent : @201,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},

				@173,
				@177,
				@181,
				@185,
				@188,
				@190,
				@193,
				@196,
				@201,
				@204,
				GrafoscopioNode {
					#header : 'Notas',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [
						GrafoscopioNode {
							#header : 'Los hackers son "bienes" recursivos',
							#body : 'Kelty [1] habla de cómo los hackers crean bienes recursivos, como el Internet y el software libre, es decir, bienes que les permiten crear más bienes, que les permiten estar juntos. Yo diría que el bien recursivo que los hackers crean por naturaleza es el de los hackers mismos.

[1] http://kelty.org/or/papers/unpublishable/Kelty.RecursivePublics-short.pdf',
							#tags : OrderedCollection [ ],
							#children : OrderedCollection [ ],
							#parent : @209,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@212,
				GrafoscopioNode {
					#header : 'Kanban',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [

b dates: (dictByDate keys min to: dictByDate keys max).
^ b
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Usando commits en Fossil',

b dates: (dictByDate keys min to: dictByDate keys max).
^ b
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														'',
														'http://ws.stfx.eu/BBZHG8UA1529'
													]
												},
												GrafoscopioNode {

b build.
(b view elements select: [ :e | e model isKindOf: Month ]) pushFront.
^ b view',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Fossil: Paleta de colores',
													#body : '"La idea es obtener un color por cada valor en una paleta
de colores."
| testRepo colors valuedColors |
testRepo := FossilRepo new
\tremote: \'http://localhost:8080/\'.
colors :=  RTColorPalette sequential colors: 9 scheme: \'Greens\'.
valuedColors := testRepo commitsByDate collect: [ :v |
\tcolors at: v // 2 + 1 ].
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Calendario con datos en Fossil',

(b view elements select: [ :e | e model isKindOf: Month ]) pushFront.
^ b view
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														'',
														'http://ws.stfx.eu/EQ5ZTLRQMSH2'
													]
												},
												GrafoscopioNode {
													#header : 'Commits calendar',
													#body : '| urls repo palette |
urls := #(\'http://mutabit.com/repos.fossil/mapeda\' \'http://localhost:8080/\' \'http://localhost:8081/\').
repo := FossilRepo new
\tremote: (urls at: 2).
palette := RTColorPalette sequential colors: 9 scheme: \'Blues\'.
repo commitsCalendarFrom: 201 to: 2017 colored: palette

',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Paleta de colores',
													#body : 'RTColorPalette sequential colors: 9 scheme:\'Greens\'',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												}
											],
											#parent : @223,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										}
									],
									#parent : @220,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								},
								GrafoscopioNode {
									#header : 'Evolución de código',
									#body : '  - [Code Frequency](https://github.com/rqlite/rqlite/graphs/code-frequency): Código borrado vs código agregado, por fecha.
  - [Commits](https://github.com/rqlite/rqlite/graphs/commit-activity).
  - [Contributors](https://github.com/rqlite/rqlite/graphs/contributors).',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @220,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @217,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Brea',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @217,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@220,

				@223,
				@226,
				@229,
				@233,
				@237,
				@241,
				@245,
				@249,
				@253,
				@259,
				@264
			]
		},
		#level : 1,
		#links : OrderedCollection [
			''
		]
	},
	@8,
	@11,
	@14,
	@29,
	@93,

	@113,
	@121,
	@125,
	@134,
	@170,
	@209,
	@217
]