% !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 intención sería configurar un espacio web que habitáramos los integrantes de HackBo,
Un hábitat digital, en palabras de \cite{wenger_digital_2009}.
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 (\cite{luna_cardenas_habitats_2011})
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 intenció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 Urrego 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}.
cuando se mencionó cómo se decía desde las acciones y las infraestructuras y cómo
ciertas argumentaciones quedaban resueltas (o no) a través de la posibilidad de
expresarse sobre y desde la tecnología digital misma, en este caso sobre la necesidad
de tener infraestructuras autónomas y programables por nosotros mismos.
Hablar desde las infraestruturas acerca de la autonomía en la presencia en línea,
implicaba tener la capacidad, el tiempo y el interés de desplegar y programar las
infraestructuras para lograr dicha autonomía.
Esto marcó el inicio de un primer hábitat digital 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 administradas
por nosotros en nuestros propios servidores web, pero prehechas 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 la 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}):
\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
\footnote{Nótese la palabra "todos".
Los colectivos se forman, pero no con todos los amigos, sino unos pocos
y unos nuevos convocados por las herramientas, que surgieron de rascar
una comezón individual, por emplear la metáfora ya mencionada, y que
luego es compartida por otros con intereses/comezones similares.}.
\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 y decir cuáles de
sus ramas 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 la variante 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.
En un repositorio público de Fossil, que había creado para el doctorado desde el 2011, coloqué
los escritos hechos y exportados desde Leo\footnote{véase: \url{https://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 infraestructura misma era un medio y un fin para comunicar y explorar las ideas
sobre autonomía, cumpliendo los postulados de \cite{saikaly_approaches_2005}, y los
prototipos desarrollados en ella permitían recorridos específicos en los que las
infraestructuras cambian y se combinan para permitir argumentos más específicos sobre
lo que importa de esa autonomía y dónde nos queremos enfocar para que esos ejercicios
desde la autonomía misma, aquieran sentido para varias personas.
En este caso particular, una inquietud gruesa por cómo habitábamos la web desde
HackBo, retomaba aprendizajes y pérdidas sobre lo que había ocurrido con otras
infraestructuras como El Directorio, llevándonos a sistemas autónomos pero
complejos/complicados (Cynin) a otros ligeros y programables (web2py) a unos
aún más sencillos (Grav) y conexos con otros (Meetup, GitHub, Dokuwiki), de
manera que las preocupaciones propias y las comunitarias, así como incidencias
no planeadas (SPAM y tiempo) daban forma a los usos de las infraestructuras
que usábamos y permitían enfocarse en otras por venir, que transmitirían de
mejor manera preocupaciones venideras y los intereses de esta tesis por
por la modificación recíproca entre comunidades y artefactos digitales,
al mismo tiempo que entrarían en diálogo con inquietudes sobre formas de
ejercer ciudadanías.
Pero la necesidad por estas narrativas computacionales, que mezclaran datos e interacción,
y empoderaran voces ciudadanas desde desarrollos locales, se hizó más evidente a partir
de unas hackatones que surgieron como resistencia desde HackBo a la enajenación del discurso
hacker por parte del 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 \cite{lilly_irani_hackathons_2015}
y \cite{schrock_hackathons_2016}, 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 \cite{lilly_irani_hackathons_2015} en distintos lugares con la lógica
uniformizante del ``emprendimiento''.
No importa si se trata en India, (\cite{lilly_irani_hackathons_2015}: Hackatones y la creación
del ciudadano emprendedor), Estados Unidos (\cite{schrock_hackathons_2016} Hackatones sin hackeo
y \cite{scott_how_2015}: El Hacker hackeado: como los yuppies hackearon el ethos hacker
original\footnote{Título traducido del original \emph{The hacker hacked: How yuppies hacked the
original hacker ethos}}),
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, en 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 (\cite{scott_how_2015}) 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 (\cite{luna_gobernaton:_2013}):
\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 \cite{lilly_irani_hackathons_2015}, \cite{schrock_hackathons_2016}
y \cite{vila_permanent_2013}).
\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]
Se ve acá un tránsito progresivo de lo hacker a lo hacktivista, considerado en el
capítulo previo, pues técnicas e infraestucturas informáticas eran reapropiadas
para propósitos cívicos y ciudadanos convirtiéndose en un ejercicio de repolitización
del código, pero también se trataba de un ejercicio de reflexión auto-crítico, al
ver más allá de los procesos de gentrificación con los cuales algunas de esas repolitizaciones
se ven confinadas e incluso repensando dinámicas ocurridas dentro del espacio, de manera
tal que facilitaran la conformación del mismo como espacio para expandir las prácticas
ciudadanas, transformando los artefactos con los que nos dedicábamos a ellas.
Es decir, en la medida en que el investigador habitaba el prototipo, que la comunidad
del Hackerspace configuraba, respecto a otras formas de habitar el mundo, efectivamente
se veía a la comunidad y a sí mismo dentro de ella, transformándose y explorando nuevas
prácticas desde la condición de espacios y sujetos políticos habitando el hackerspace.
Esta es una concreción misma del diálogo estructura agencia desde el hackerspace,
tomando cuerpo en las formas de hacer nuevas y los artefactos nuevos que las soportaban,
en el tránsito específico de apps y portales a narrativas de datos se configuraban
nuevas voces ciudadanas y artefactos que las posibilitaran.
Se trataba de una tensión dialéctica como las que se han indicado desde \cite{fuchs_autopoiesis_nodate},
tomando cuerpo y siendo enunciadas desde los artefactos y las prácticas que
habilitadas por ellos, es decir dicha dialéctica tomaba forma desde las maneras
de argumentar propuestas por \cite{isin_being_2015} en contraste con otras prácticas
e infraestructuras que desplegaban los esfuerzos más gentrificadores y utilitaristas
de las tecnologías digitales, como las que se mostraron acá por parte de entidades
gubernamentales.
La combinación de estas tecnologías para argumentar e interlocutar con el
poder estatal 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.