%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Tufte-Style Book (Documentation Template)
% LaTeX Template
% Version 1.0 (5/1/13)
%
% This template has been downloaded from:
% http://www.LaTeXTemplates.com
%
% Original author:
% The Tufte-LaTeX Developers (tufte-latex.googlecode.com)
%
% License:
% Apache License (Version 2.0)
%
% IMPORTANT NOTE:
% In addition to running BibTeX to compile the reference list from the .bib
% file, you will need to run MakeIndex to compile the index at the end of the
% document.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%----------------------------------------------------------------------------------------
% PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
%----------------------------------------------------------------------------------------
\documentclass{tufte-book} % Use the tufte-book class which in turn uses the tufte-common class
\hypersetup{colorlinks} % Comment this line if you don't wish to have colored links
\usepackage[utf8]{inputenc}
\usepackage[spanish]{babel}
\usepackage{microtype} % Improves character and word spacing
\usepackage{lipsum} % Inserts dummy text
\usepackage{booktabs} % Better horizontal rules in tables
\usepackage{graphicx} % Needed to insert images into the document
\graphicspath{{graphics/}} % Sets the default location of pictures
\setkeys{Gin}{width=\linewidth,totalheight=\textheight,keepaspectratio} % Improves figure scaling
\usepackage{fancyvrb} % Allows customization of verbatim environments
\fvset{fontsize=\normalsize} % The font size of all verbatim text can be changed here
\newcommand{\hangp}[1]{\makebox[0pt][r]{(}#1\makebox[0pt][l]{)}} % New command to create parentheses around text in tables which take up no horizontal space - this improves column spacing
\newcommand{\hangstar}{\makebox[0pt][l]{*}} % New command to create asterisks in tables which take up no horizontal space - this improves column spacing
\usepackage{xspace} % Used for printing a trailing space better than using a tilde (~) using the \xspace command
\newcommand{\monthyear}{\ifcase\month\or January\or February\or March\or April\or May\or June\or July\or August\or September\or October\or November\or December\fi\space\number\year} % A command to print the current month and year
\newcommand{\openepigraph}[2]{ % This block sets up a command for printing an epigraph with 2 arguments - the quote and the author
\begin{fullwidth}
\sffamily\large
\begin{doublespace}
\noindent\allcaps{#1}\\ % The quote
\noindent\allcaps{#2} % The author
\end{doublespace}
\end{fullwidth}
}
\newcommand{\blankpage}{\newpage\hbox{}\thispagestyle{empty}\newpage} % Command to insert a blank page
\usepackage{units} % Used for printing standard units
\newcommand{\hlred}[1]{\textcolor{Maroon}{#1}} % Print text in maroon
\newcommand{\hangleft}[1]{\makebox[0pt][r]{#1}} % Used for printing commands in the index, moves the slash left so the command name aligns with the rest of the text in the index
\newcommand{\hairsp}{\hspace{1pt}} % Command to print a very short space
\newcommand{\ie}{\textit{i.\hairsp{}e.}\xspace} % Command to print i.e.
\newcommand{\eg}{\textit{e.\hairsp{}g.}\xspace} % Command to print e.g.
\newcommand{\na}{\quad--} % Used in tables for N/A cells
\newcommand{\measure}[3]{#1/#2$\times$\unit[#3]{pc}} % Typesets the font size, leading, and measure in the form of: 10/12x26 pc.
\newcommand{\tuftebs}{\symbol{'134}} % Command to print a backslash in tt type in OT1/T1
\providecommand{\XeLaTeX}{X\lower.5ex\hbox{\kern-0.15em\reflectbox{E}}\kern-0.1em\LaTeX}
\newcommand{\tXeLaTeX}{\XeLaTeX\index{XeLaTeX@\protect\XeLaTeX}} % Command to print the XeLaTeX logo while simultaneously adding the position to the index
\newcommand{\doccmdnoindex}[2][]{\texttt{\tuftebs#2}} % Command to print a command in texttt with a backslash of tt type without inserting the command into the index
\newcommand{\doccmddef}[2][]{\hlred{\texttt{\tuftebs#2}}\label{cmd:#2}\ifthenelse{\isempty{#1}} % Command to define a command in red and add it to the index
{ % If no package is specified, add the command to the index
\index{#2 command@\protect\hangleft{\texttt{\tuftebs}}\texttt{#2}}% Command name
}
{ % If a package is also specified as a second argument, add the command and package to the index
\index{#2 command@\protect\hangleft{\texttt{\tuftebs}}\texttt{#2} (\texttt{#1} package)}% Command name
\index{#1 package@\texttt{#1} package}\index{packages!#1@\texttt{#1}}% Package name
}}
\newcommand{\doccmd}[2][]{% Command to define a command and add it to the index
\texttt{\tuftebs#2}%
\ifthenelse{\isempty{#1}}% If no package is specified, add the command to the index
{%
\index{#2 command@\protect\hangleft{\texttt{\tuftebs}}\texttt{#2}}% Command name
}
{%
\index{#2 command@\protect\hangleft{\texttt{\tuftebs}}\texttt{#2} (\texttt{#1} package)}% Command name
\index{#1 package@\texttt{#1} package}\index{packages!#1@\texttt{#1}}% Package name
}}
% A bunch of new commands to print commands, arguments, environments, classes, etc within the text using the correct formatting
\newcommand{\docopt}[1]{\ensuremath{\langle}\textrm{\textit{#1}}\ensuremath{\rangle}}
\newcommand{\docarg}[1]{\textrm{\textit{#1}}}
\newenvironment{docspec}{\begin{quotation}\ttfamily\parskip0pt\parindent0pt\ignorespaces}{\end{quotation}}
\newcommand{\docenv}[1]{\texttt{#1}\index{#1 environment@\texttt{#1} environment}\index{environments!#1@\texttt{#1}}}
\newcommand{\docenvdef}[1]{\hlred{\texttt{#1}}\label{env:#1}\index{#1 environment@\texttt{#1} environment}\index{environments!#1@\texttt{#1}}}
\newcommand{\docpkg}[1]{\texttt{#1}\index{#1 package@\texttt{#1} package}\index{packages!#1@\texttt{#1}}}
\newcommand{\doccls}[1]{\texttt{#1}}
\newcommand{\docclsopt}[1]{\texttt{#1}\index{#1 class option@\texttt{#1} class option}\index{class options!#1@\texttt{#1}}}
\newcommand{\docclsoptdef}[1]{\hlred{\texttt{#1}}\label{clsopt:#1}\index{#1 class option@\texttt{#1} class option}\index{class options!#1@\texttt{#1}}}
\newcommand{\docmsg}[2]{\bigskip\begin{fullwidth}\noindent\ttfamily#1\end{fullwidth}\medskip\par\noindent#2}
\newcommand{\docfilehook}[2]{\texttt{#1}\index{file hooks!#2}\index{#1@\texttt{#1}}}
\newcommand{\doccounter}[1]{\texttt{#1}\index{#1 counter@\texttt{#1} counter}}
\usepackage{makeidx} % Used to generate the index
\makeindex % Generate the index which is printed at the end of the document
% This block contains a number of shortcuts used throughout the book
\newcommand{\vdqi}{\textit{VDQI}\xspace}
\newcommand{\ei}{\textit{EI}\xspace}
\newcommand{\ve}{\textit{VE}\xspace}
\newcommand{\be}{\textit{BE}\xspace}
\newcommand{\VDQI}{\textit{The Visual Display of Quantitative Information}\xspace}
\newcommand{\EI}{\textit{Envisioning Information}\xspace}
\newcommand{\VE}{\textit{Visual Explanations}\xspace}
\newcommand{\BE}{\textit{Beautiful Evidence}\xspace}
\newcommand{\TL}{Tufte-\LaTeX\xspace}
%----------------------------------------------------------------------------------------
% BOOK META-INFORMATION
%----------------------------------------------------------------------------------------
\title{Grafoscopio y el Data Week\thanks{Thanks to Edward R.~Tufte for his inspiration.}} % Title of the book
\author[Offray Vladimir Luna Cárdenas]{Offray Vladimir Luna Cárdenas} % Author
\publisher{Universidad de Caldas, Doctorado en diseño y creación} % Publisher
%----------------------------------------------------------------------------------------
\begin{document}
\frontmatter
%----------------------------------------------------------------------------------------
% EPIGRAPH
%----------------------------------------------------------------------------------------
\thispagestyle{empty}
\openepigraph{The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with. The new becomes threatening, the old reassuring.}{Paul Rand, {\itshape Design, Form, and Chaos}}
\vfill
\openepigraph{A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.}{Antoine de Saint-Exup\'{e}ry}
\vfill
\openepigraph{\ldots the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual\ldots If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important.}{Donald E. Knuth}
%----------------------------------------------------------------------------------------
\maketitle % Print the title page
%----------------------------------------------------------------------------------------
% COPYRIGHT PAGE
%----------------------------------------------------------------------------------------
\newpage
\begin{fullwidth}
~\vfill
\thispagestyle{empty}
\setlength{\parindent}{0pt}
\setlength{\parskip}{\baselineskip}
Copyright \copyright\ \the\year\ \thanklessauthor
\par\smallcaps{\thanklesspublisher}
\par\smallcaps{http://mutabit.com}
\par Licensed under the Apache License, Version 2.0 (the ``License''); you may not use this file except in compliance with the License. You may obtain a copy of the License at \url{http://www.apache.org/licenses/LICENSE-2.0}. Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an \smallcaps{``AS IS'' BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND}, either express or implied. See the License for the specific language governing permissions and limitations under the License.\index{license}
\par\textit{First printing, \monthyear}
\end{fullwidth}
%----------------------------------------------------------------------------------------
\tableofcontents % Print the table of contents
\setcounter{tocdepth}{5}
%----------------------------------------------------------------------------------------
%\ listoffigures % Print a list of figures
%----------------------------------------------------------------------------------------
% \listoftables % Print a list of tables
%----------------------------------------------------------------------------------------
% DEDICATION PAGE
%----------------------------------------------------------------------------------------
\cleardoublepage
~\vfill
\begin{doublespace}
\noindent\fontsize{18}{22}\selectfont\itshape
\nohyphenation
Dedicado a mi mamá, Hilda Cárdenas Pachón, y mi hermana, Divian Luna Cárdenas,
pues sin su apoyo incondicional durante los años que duró mi doctorado
(y los años en los que hice pausa) este ''artefacto híbrido'' no existiría.
\end{doublespace}
\vfill
\vfill
%----------------------------------------------------------------------------------------
% PAGINA DE AGRADECIMIENTOS
%----------------------------------------------------------------------------------------
\cleardoublepage
~\vfill
\begin{doublespace}
\noindent\fontsize{18}{22}\selectfont\itshape
\nohyphenation
Agradecimientos: \\
A mi familia en Colombia y Canadá. \\
A mis amigos en el hackerspace \smallcaps{HackBo} y \smallcaps{502Lab}. \\
A las comunidades consolidadas alrededor de Pharo y nacientes
alrededor de Grafoscopio y el Data Week y a las personas en ellas.\\
A mi tutor, Adolfo Grisales.
\end{doublespace}
\vfill
\vfill
%----------------------------------------------------------------------------------------
% INTRODUCTION
%----------------------------------------------------------------------------------------
\cleardoublepage
\chapter{Introducción: Artefactos híbridos, discursos cenagosos y lugares propios} % The asterisk leaves out this chapter from the table of contents
\newthought{¿Cómo cambiamos los artefactos digitales que nos cambian?}
Esta es la pregunta que inspiró la investigación que este escrito presenta y para abordarla
se creó y jalonó una dinámica de modifcación recíproca entre una jóven
comunidad de práctica, en el \emph{hackerspace} HackBo, en Bogotá Colombia,
y un artefacto digital amoldable para escritura interactiva, investigación reproducible, visualización y activismo de datos, llamado Grafoscopio (en el cual fueron escritas
varias partes el presente texto).
La investigación da cuenta de esta dinámica de modificación recíproca entre artefacto y comunidad,
de los enfoques teóricos para apreciarla (investigación desde el diseño, sistemas autopoiéticos),
del hábitat de dicho problema y su contexto (la contracultura hacker y sus recontextualizaciones
en un lugar del Sur Global) y de cómo se llegó a dicha dinámica en una aproximación informada
etnográficamente, que rastrea en las huellas dejadas en por la comunidad, las primeras intuiciones
y los diálogos entre tradiciones y prácticas computaciones en dicho contexto (software libre y de
código abierto, el \emph{dynabook} y sus encarnaciones en Smalltalk y \emph{Pharo},
la investigación abierta y reproducible, la escritura interactiva, la visualización y el
activismo de datos).
Intenta ser una investigación consecuente con este momento, en que el diseño
intenta construir un lugar epistemológico y metodológico que le sean propios,
lo cual se ve fortalecido ante los esfuerzos a nivel mundial de consolidar
doctorados en diseño con un componente investigativo pertinente a este nivel
de formación superior, pero también con el diseño como forma de conocer particular
(Saikaly\cite{Saikaly-1,Saikaly-2}).
Los procesos de formación doctoral son espacios para hacer explícita
la necesidad de diálogo dentro de los saberes en diseño, pero también
con otras formas de saber y ayudar a consolidar un lugar que le sea
propio.
Esto quiere decir que el diseño tienen una posición privilegiada,
y los espacios doctorales deberían resistirse ante las presiones de ser
validados dentro de alguna métrica institucional
(por ejemplo la de las revistas indexadas) y darle la bienvenida
a otros objetos no hegemónicos para reportar conocimiento:
los \emph{viscursos} con un énfasis a lo visual propuestos por Bonsiepe\cite{Bonsiepe-1}
y que de cuenta del giro pictórico al que se enfrenta nuestra cultura y que le
atañe al diseño, los objetos activistas, los ensayos sonoros, los artefactos de software,
entre tantos otros.
La propuesta acá es a resistir el afán de construir textos ``puros'',
que se defiendan por sí mismos, por su consistencia interna
lograda a partir de los diálogos de los autores del texto con aquellos
que el texto cita, al mejor estilo de la tradición académica.
Y no porque ésta sea una pretensión inválida, sino porque es insuficiente.
El viscurso y otros artefactos de conocimiento no hegemónicos,
recientemente propuestos, están aún en construcción y por tanto no se le
puede pedir al mismo tiempo su carácter exploratorio y de prototipo
y su consistencia interna, al mejor estilo de los ``discursos puros''.
Así el texto que el lector tiene ante sí, es un artefacto híbrido y
cenágoso, como diría Jonas\cite{Jonas-2}, un \emph{viscurso} impuro, propio del diseño:
\begin{itemize}
\item
Para dar cuenta de su caracter visual la presentación misma del texto
cambió para establecer un diálogo más fluido con lo visual e inspirada
en las propuestas de Tufte\cite{Tufte2001}, usa amplios márgenes laterales
para las notas y está acompañado por gráficas, que no son ``de apoyo''
sino parte esencial del discurso/viscurso.
De hecho los mapas mentales se usaron como manera de descubrir/profundizar
argumentos y serían el primer paso de una transición que permita ir de éstos
a los mapas conceptuales y de allí a los argumentativos (en la caracterización
brindada por Twardy\cite{Twardy-1}).
Consecuentemente las direcciones de Internet que aparecen al margen han
sido todas acortadas de manera que sean fáciles de transcribir a un
navegador y usando un acortador de enlaces ``ético``, que no rastrea
al usuario, mercantilizándolo en el panóptico del ciberespacio.
\item
Para dar cuenta del diseño como su asunto de reflexión, vincula dos
discursos, el de Jonas, por un lado y el de Fuchs y Horkheimer\cite{Fuchs-1},
por otro, a propósito del diseño, la autopoiesis y la
teoría de sistemas sociales críticos, usando como puente a
Luhmann y como inspiración una dialéctica entre lo complejo y lo simple caracterizada por
el \emph{zoom}, en línea con lo propuesto en
los análisis ecológicos desde sistemas complejos, de los cuales
hablará más adelante.
Este es el foco de esta primera parte.
\item
La segunda parte ya tiene que ver con la indagación dentro del hackerspace.
Usa una dinámica de zoom, descrita en la primera parte, definiendo el fenómeno
hacker desde tres autores principales: Coleman, Maxigas y Clark, para luego acercarse
(\emph{zoom in}) a la comunidad de HackBo en particular y contar la experiencia que
llevó a la construcción de Grafoscopio y el taller-hackatón llamado Data Week,
donde aprendemos a usarlo y modificarlo,y las huellas de ese proceso comunitario en los artefactos co-construidos.
Habla así de los contextos humanos donde dichas herramientas se desarrollaron.
y en ese sentido establece una diferencia con el laboratorio en su proceso de
purificación la naturaleza, denunciado por Latour, al observarla, analizarla
y entregarnos sus ``leyes subyacentes'', sin dar cuenta de como los ``datos crudos''
procesados al calor de todas las subjetividades, historias humanas,
nos dan ``verdades cocinadas''.
\item
La tercera cierra el texto con hallazgos, conclusiones y recomendaciones.
\end{itemize}
Este artefacto híbrido tiene, además, distintos niveles de cocción.
Por una parte es textual, por otra parte es visual.
Unos elementos son software, habitando un ``mar de objetos``,
otros recurren a la naturaleza lineal del texto escrito y otros se conectan con
sitios web, repositorios de código y narrativas de comunidades que habitan tanto
espacios analógicos y cara a cara, como digitales y virtuales.
Es un artefacto que intenta favorecer un mejor el metabolismo cognitivo,
no sólo desde lo visual, como diría Bonsiepe\cite{Bonsiepe-2}, sino desde
la comprensión de los ingredientes y cómo están articulados.
Pero es sobre todo una provocación para el lector, a intentar sus propios objetos
no hegemónicos de conocimiento, sus propios artefactos
impuros o acompañarnos en la (de)construcción de los estamos (des)armando.
Este texto, y los artefactos digitales y prácticas asociadas constituyen así de un lugar ecléctico,
que se configura como nodo, nudo y puente, con importantes consecuencias prácticas:
Si podemos cambiar los artefactos que nos cambian, podemos decidir sobre nuestros cambios
futuros, agenciando autonomía y autodeterminación y posibilitando la construcción más plural
de un mundo compartido.
Espero que el lector encuentre múltiples lugares de ingreso y diálogo para construir juntos.
La invitación queda abierta.
%----------------------------------------------------------------------------------------
\mainmatter
%----------------------------------------------------------------------------------------
% INTRODUCTION
%----------------------------------------------------------------------------------------
\cleardoublepage
\chapter{Justificación} % The asterisk leaves out this chapter from the table of contents
\begin{quote}
Indagar sobre lo educativo allí se torna central a la hora de comprender y
problematizar los modos en que el conocimiento establecido se constituye
socialmente como una caja negra. Una que es configurada en el acto educativo y
que tiene el poder de ocultar, de neutralizar, en clave posmoderna,jerarquías
epistémicas de carácter colonial, en donde ciertos saberes y formas de conocer,
atravesados por constructos de género, se vuelven más legítimos que otros.
- Tania Bustos, Los márgenes de la Popularización de la ciencia y la tecnología: Conexiones feministas en el sur global.
\end{quote}
\begin{quote}
Hasta hoy, la tecnología ha sido manejada como una caja negra, como una esfera
autónoma y neutral que determina su propio camino de desarrollo, generando
inexorables efectos, constructivos o destructivos a su paso. Esta visión lineal,
determinista e ingenua de la tecnología permanece aún vigente en la visión ideológica
de muchos actores clave: de los tomadores de decisión, de los tecnólogos, científicos
e ingenieros. Lejos de un sendero único de progreso, existen diferentes vías de
desarrollo tecnológico, diversas alternativas tecnológicas, distintas maneras de
caracterizar un problema y de resolverlo.
Hernan Thomas, Tecnologías para la inclusión social y políticas públicas en América Latina
\end{quote}
\newthought{Los saberes como cajas negras}, perpetuadoras de discursos de poder hegemónicos y excluyentes,
manifiestan particularmente su caracter irónico en el terreno de las tecnologías digitales,
pues este "saber blando" toma cuerpo en un "medio blando", que se caracteriza por ser flexible y abundante,
lo cual se demuestra en la facilidad de copiado, transmisión y modificación de los constructos digitales,
en comparación con sus contrapartes analógicas.
Sin embargo, prácticas tecno-sociales, en diversas dimensiones que atañen a lo cultural, lo legal,
lo tecnológico y lo cognitivo, han contravenido esta naturaleza colocando barreras de ingreso artificiales,
que no han sido adecuadamente deconstruidas y que dejan a gran parte de la población por fuera de las posibilidades
de inclusión y participación que se supone dichas tecnologías iban a permitir o, peor aún, manteniéndonos en la
ilusión de que estamos participando, cuando somos sólamente personajes marginales inconscientes de lo que ignoramos.
Así las cosas, cómo tales barreras se deconstruyen, reconfiguran y desconfiguran es una pregunta importante si queremos,
efectivamente, posibilitar pasar de la marginalidad a la participación y la construcción plural del mundo,
anotando de antemano, que como decía Thomas \cite{Thomas-1}, no se pretende caer en un determinismo tecnológico
o uno social, sino que entendemos que abordar esta pregunta por el "cómo" es insertarnos en un fenómeno complejo,
donde interactuar es en parte responderse y donde no podemos desligarnos de las preguntas por el "para qué".
Las nuevas condiciones tecno-sociales han posibilitado el avance y visibilidad de otros discursos marginales,
que pretenden deconstruir las barreras antes mencionadas (Software Libre, Creative Commons, Libre Society, el Dynabook),
algunas con más éxito y postura crítica que otras.
Sin embargo, habitamos la periferia de estos movimientos y tampoco hemos propuesto un discurso propio frente a ellos.
Por un lado porque el papel de "prosumidores" (ese híbrido entre productores y consumidores) sigue fuertemente inclinado
hacia el consumo y por otro, porque en lugar de sentar derroteros propios, hemos tomado partido en discusiones polarizadas,
por ejemplo copyright vs copyleft (aunque ya se empieza a constituir copysouth, cuestionando elementos básicos de estas
posturas, como aquella en la que se supone que quien crea es el individuo en lugar del colectivo, cuando la idea de lo plural es un asunto innegable en las tradiciones indígenas o afrodescendientes, por ejemplo), reiterando posturas binarias y sus jerarquías.
La naturaleza de la creación digital en el Sur Global es diferente a la del Norte Global y si bien,
el movimiento de la librecultura cuenta con creaciones abundantes en campos como la músical, por ejemplo en Brasil,
tales creaciones digitales circulan por las infraestructuras de información provistas por el Norte Global,
desde sus circunstancias y sus lógicas, embebidas en la infraestructura, y por tanto no están resignificadas
para este contexto.
Cosas como la baja conectividad, la fácilidad para aprender e intervenir, el caracter \emph{p2p} o entre pares,
hacen gala de su ausencia en las soluciones concebidas para otros, sin incluir en el diálogo y el diseño a aquellos
a quien \emph{se les crean} las soluciones, salvo contadas excepciones.
El caracter descontextualizado, paternalista y/o asistencialista de algunas iniciativas ha hecho que
ellas no se sostengan a sí mismas y no continuen la exploración tecno-social por cuenta propia.
La estructura de comunidades de práctica propuesta por Wenger supone una dualidad esencial de la experiencia:
se cosifica y se participa, en un diálogo y complemento permanente.
Construir y visibilizar los discursos propios tiene que ver con cosificar las participaciones que los construyen,
de manera que falicitemos, o no, las participaciones futuras.
Es decir que, si el paso por el artefacto es inevitable en la construcción de la participación futura, entonces,
es clave entender las dinámicas artefactuales y como éstas nos permiten expresar discursos locales y nuestro
aporte desde la diversidad a la construcción global.
No se trata sólo de usar software libre o licencias de la libre cultura o las \emph{obras culturales libres}\cite{moller-1}.
Sin embargo, como afirma Jonas, los artefactos son "materializaciones necesarias pero contingentes" al problema de diseño
y ellos dan cuenta la solución temporal a brechas en los sistemas autopoéticos contituidos por los organimos, la conciencia y la comunicación
(un tema en el que se profundizará en la primera parte).
Este proyecto de investigación particular indaga por la brecha entre los artefactos, la conciencia y las comunicaciones,
o dicho de otro modo, los artefactos, lo mental y lo social.
Se trata, sobre todo, de poder expresar en artefactos digitales, preocupaciones genuinas y locales que,
articuladas con otras de naturaleza similar, contribuyan a la construcción de un mundo por y para todos y todas.
La pregunta de investigación de este trabajo es cómo cambiamos los artefactos digitales que nos cambian,
de manera que participemos en la construcción de dinámicas tecno-culturales autónomas.
Es un intento de abordar las inquietudes presentadas en esta justificación.
Se enmarca dentro de las tradiciones intelectuales de las comunidades de práctica, las redes fluidas,
la cibernética y las tecnologías sociales y dialoga con tradiciones como las del dynabook, Pharo,
Unix, el activismo de datos y la visualización feminista de datos.
Hasta donde la investigación preliminar ha podido arrojar, se trata de un abordaje nóvel por esta pregunta,
con consecuencias importantes tanto a nivel teórico, como práctico y un correlato social permanente.
Lo anterior nos muestra una justificación del proyecto de investigación ocurre, tanto desde el punto de vista tecno-político,
como desde el teórico y metodológico.
Es una abordaje que dialoga con otros, pero que se responde de maneras particulares, habitando un problema,
construyendo artefactos dialógicos y dislocando otros artefactos, mientras propone dinámicas sociales, para
contextos particulares, afirmando el caracter político del investigador y las comunidades a las que se acerca,
habita y pertenece.
\chapter{Problema / Objetivo}\label{problema-objetivo}
\section{General}
Alentar y caracterizar la transición de usuarios a hacedores de artefactos digitales en el
el \emph{hackerspace} HackBo, en Bogotá Colombia.
\section{Específico}
Diseñar e implementar un artefacto digital autoreferencial (metasistema) y revisar sus impactos
y relación con una comunidad de práctica.
%----------------------------------------------------------------------------------------
% PARTE 1
%----------------------------------------------------------------------------------------
\part{Perspectivas teóricas y críticas}
\label{part:perspectivas}
\newthought{¿Cuál lugar ocupa esta tesis, desde lo epistemológico y metodológico?} Esta será la pregunta
que se abordará en esta sección.
Para ello se realizará una panorámica de las distintas
epistemologías, se sugerirá una manera de conectarlas
y se usará una aproximación de \emph{zoom} para modificar la teoría de diseño de
Jonas, conectándola con la perspectiva crítica de Fuchs y Hockhaimer.
También se mostarán aproximaciones metodológicas al
diseño que suponen al investigador/diseñador como sujeto
político, que co-diseña y habita un problema/prototipo
dentro de una comunidad (de práctica o interés) apostando
por un mundo más plural e incluyente.
Esto permitirá entender los lugares de mirada
y acción de la segunda parte.
%----------------------------------------------------------------------------------------
% CAPITULO 1
%----------------------------------------------------------------------------------------
\chapter{Ecología y sistemas complejos como posibilidad
dialectica}\label{ecologuxeda-y-sistemas-complejos-como-posibilidad-dialectica}
\newthought{La naciente epistemología del diseño} está caracterizada por la diversidad de miradas y enfoques,
desde quienes intentan buscar los fundamentos en lugares como la filosofía
(con los 4 principios generativos de Buchanan\cite{Buchanan-1} ),
% Bonsiepe-2
la antropología, la teoría del arte, los enfoques ontológicos (Friedman\cite{Friedman-1})
y cognitivos (Simon), hasta quienes, por el
contrario, creen que, dentro de las particularidades del diseño, está en
que este no es un saber sostenido en una base (un ``fundamento'') sino
en una red y dado que es una red que se sostiene a sí misma le
corresponde al diseño un discurso epistemológico desde la cibernética y
la teoría general de sistemas (Jonas\cite{Jonas-1}, Glanville\cite{Glanville-1}).
Yo en particular me adscribo a esta última mirada. Desde esta diferencia de
posturas se han abordado puntos en común, por ejemplo, el hecho de que
el diseño se ocupe de lo posible y que necesita construir un saber que
le sea característico en diálogo con otros saberes como los de la
ciencia y el arte, pero distinto a ellos.
Por lo anterior, los saberes en diseño son buenos candidatos a ser
considerados sistemas complejos: son diversos, no lineales, interconectados y dinámicos.
Si partimos de la hipótesis de que tales saberes conforman efectivamente
sistemas complejos interconectados entre sí, los análisis ecológicos
desde sistemas complejos pueden ser una buena inspiración sobre cómo
mapear y representar las conexiones actuales y posibles de los saberes
en diseño entre sí y dar cuenta de cómo ellos conforman una ecología de
saberes. Esta hipótesis de partida tomará más fuerza en la medida en que
desarrollemos la propuesta que ella nos permite. Si se quiere, esto
puede ser un tipo de pensamiento circular, pero no uno tautológico, sino
autopoiético, que emplea un proceso de \emph{bootstraping} sencillo, la de que
\emph{los saberes en diseño constituyen una red compleja} para jalonar
estados más avanzados de sí mismos, la de que \emph{la sociedad es una
red compleja autopoiética y esto tiene consecuencias en las
epistemologías y acciones del diseño}.
Al respecto del tratamiento de sistemas complejos Berlow\cite{Berlow-1} nos
sugiere una abordaje desde la dinámica del acercarse (\emph{zoom in}) y
del alejarse (\emph{zoom out}) que de hecho estaría en consonancia con
las propuestas de explicitar y ubicar las tensiones dialécticas hecha
por Fuchs y Horkheimer y con la idea de visualizar para argumentar y
preguntarse, hecha en los viscursos de Bonsiepe y los medios para para
pensar lo impensable de Victor\cite{Victor-1}.
En su ejemplo, Berlow toma la inspiración en el tratamiento de redes
complejas en ecología (figura \ref{fig:simple-complicado-vs-complejo} a)
y los aplica a la política, en particular al problema de incrementar
el apoyo popular en Estados Unidos al gobierno afgano, de modo que este
deje de aparentar ser un problema complicado
(figura \ref{fig:simple-complicado-vs-complejo}b) y se manifieste como un problema complejo.
Decía que la dinámica del \emph{zoom in} y el \emph{zoom out} permitía,
no sólo ubicarse en la interacción de dos elementos de la red,
sino considerar varios grados de influencia y descartar algunos no
directamente relacionados, de este modo podía mapear la red compleja del problema,
en este caso el político,
(figura \ref{fig:simple-complicado-vs-complejo}c) y encontrar conexiones
interesantes/relevamentes (figura \ref{fig:simple-complicado-vs-complejo}d).
\begin{figure*}[h]
\includegraphics[width=3in]{./graphics/complejidad-ecologia.jpg}%
\includegraphics[width=3in]{./graphics/eeuu-guerra-afganistan-2-20.jpg} \\
\includegraphics[width=3in]{./graphics/eeuu-guerra-afganistan-complejidad-2-39.jpg} %
\includegraphics[width=3in]{./graphics/eeuu-guerra-afganistan-complejidad-influencia-2-55.jpg}%
\caption{El dialogo entre lo simple y lo complejo para desenmascarar lo complicado:
Fila superior: Izquierda (a), una red compleja en ecología.
Derecha(b): una red \emph{complicada} en política.
Fila inferior: Izquierda(c): la red complicada expresada como red política compleja.
Derecha(d): un zoom en la red política compleja para asuntos relevantes.}
\label{fig:simple-complicado-vs-complejo}%
\end{figure*}
Una idea similar se ha seguido en este escrito y para explicitarla se
desarrolló un mapa mental de las lecturas que lo informan (\emph{zoom out}),
mostrado en la figura \ref{fig:mapa-lecturas},
para enfocarse luego en dos propuestas y las consecuencias de las mismas
en una parte de las epistemologías del diseño (\emph{zoom in}) y las
conexiones con otros autores (se hará referencia a las distintas partes del
\emph{zoom in} a lo largo del texto).
Las propuestas conectadas fueron una que se podría denominar una
aproximación cibernética/autopoiética a la epistemología del Diseño por
parte de Jonas y la teoría de sistemas sociales críticos de Fuchs y Horkheimer.
Es de anotar que la conexión entre tales discursos se había hecho antes
de la existencia del mapa y no era difícil de ver, pues ambos hablan de
autopoiesis y se basan en Luhmann, pero Jonas lo usa para derivar su propuesta
de epistemología para el diseño, mientras que Fuchs y Horkheimer se ubican
en una crítica al funcionalismo de Luhmann, preservando el
caracter autopoíetico de su propuesta desde otra perspectiva. Para lo
que sirvió el mapa fue para derivar consecuencias más detalladas de este
posible diálogo de discursos y su relación con otros autores. Es allí
donde esta el poder de lo visual y el \emph{zoom in}, como se mostrará más
adelante.
\begin{marginfigure}%
\includegraphics[width=\linewidth]{mapa-lecturas-examen-candidatura.png}
\caption{Mapa de lecturas para la preparación de este texto. Se harán
ampliaciones del mismo en la medida en que se avance por el texto.
Hay una versión más grande al final del escrito y una versión totalmente ampliada
en línea se puede encontrar en: \url{http://bit.ly/VeT2JA}.}
\label{fig:mapa-lecturas}
\end{marginfigure}
Las secciones siguientes presentarán brevemente la teoría autopoiesis de
diseño de Jonas desde Luhmann, la crítica de Fuchs y Horkheimer a
Luhmann, para luego revisar las consecuencias de dicha crítica en la
teoría de Jonas y conectarla con otros autores y ofrecer un ethos al
diseño consecuente con el diseño de un mundo posible más emancipador y
potenciador de lo humano.
Desde esa perspectiva epistemológica y crítica es donde esta investigación
intenta desarrollarse en en las partes 2 y 3.
\section{Jonas: El discurso del diseño como un artefacto evolutivo}\label{diseno-evolutivo}
Jonas considera que para desarrollar una genuina identidad del diseño,
es necesario mantener la pregunta por los fundamentos abierta y viva, lo
cual implica aspectos ontológicos, epistemológicos y metodológicos como:
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\itemsep1pt\parskip0pt\parsep0pt
\item
¿Hay alguna esencia del diseño / diseñar?
\item
¿Cuál es la función general del diseño?
\item
¿Cuál es la naturaleza específica del conocer en diseño?
\item
¿Cuál es la relación entre diseño y ciencia?
\item
¿Cómo mejorar el proceso de ``resolución de problemas'' a través de la
investigación?
\end{enumerate}
Jonas afirma que en estas preguntas el producto mismo del diseño, el
artefacto, está perdido, pero continua diciendo que el \emph{artefacto
es una materialización necesaria pero contigente} en el proceso nunca
terminado de diseño, que puede, en el mejor de los casos ser
interpretada en retrospectiva y con beneficios a futuro. El caracter
\emph{contigente} del artefacto no dejaba de generarme inquietudes.
Particularmente porque como seres corporeos, habitantes y creadores de
una cultura material, estamos inmersos en un mundo de artefactos, con
profundos vínculos afectivos, que pueden durar generaciones. Sin
embargo, su contigencia tiene que ver con el hecho de que los artefactos
presentes dan cuenta de su historia particular como suma de
contingencias y de elecciones. Habitamos hoy sólo uno de los mundos
posibles, no el mejor de los mundos, como diría Jonas, y entonces
podemos deconstruir los artefactos que constituyen nuestra cultura
material y preguntarnos por otras posibilidades para ellos y a través de
ellos para dicha cultura y para nuestro mundo en general. Los diseños
son intervenciones intencionales pero temporales y ``la mayoría de los
resultados desaparecerán, algunos pocos son integrados en futuros
procesos.
Las fallas como los aciertos hacen parte del archivo
socio-cultural de la humanidad''. (Jonas 2007 pp. 195)
Jonas critica algunos de los fundamentos clásicamente dados como
aquellos basados en la definición y deducción de Friedman y los
principios generativos de Buchanan y propone otros 3: la epistemología
evolucionaria, la teoría de los sistemas sociales (basado principalmente
en Luhmann) y la teoría de la evolución socio-cultural. Lo interesante
del enfoque de Jonas es que vincula los sistemas autopoiéticos y el
diseño al mismo tiempo que da una base sólida para tal vínculo. Sus
saberes son dinámicos y cibernéticos y no tiene fundamentos subyacentes:
no lo sostiene un saber debajo, sino que lo sostiene una red de saberes
al lado. Jonas, siguiendo a Luhmann, establece que existen sistemas heterónomos:
los artefactos o mecanismos, y sistemas autónomos autopoiéticos: los
organismos, la conciencia, la comunicación. Al diseño le corresponde
abordar las brechas/puentes entres las estas cuatro entidades, con lo
cual se tienen las siguientes combinaciones (véase figura):
\begin{enumerate}
\def\labelenumi{\alph{enumi})}
\itemsep1pt\parskip0pt\parsep0pt
\item
Artefactos / Organismos
\item
Artefactos / Conciencia
\item
Artefactos / Comunicaciones
\item
Artefactos / Organismos / Comunicaciones
\item
Artefactos / Conciencia / Comunicaciones
\item
Artefactos / Organismos / Conciencia
\item
Artefactos / Organismos / Conciencia / Comunicaciones.
\end{enumerate}
\begin{figure}[h]%
\includegraphics[]{auto-hetero-poietico.png}
\caption{Interpretación de la teoría de Jonas: El diseño
como puente entre entidades autopoiéticas (circulares)
y artefactos (rectangulares)}
\label{fig:jonas-design}
\end{figure}
Cuando aborda el vínculo entre diseño e investigación, Jonas nos
enfrenta a tres garantias constitucionales paradójicas de la modernidad
(Jonas 2005 pp 192):
\begin{itemize}
\itemsep1pt\parskip0pt\parsep0pt
\item
Incluso cuando construimos la naturaleza, es como si no lo hiciéramos.
\item
Incluso cuando no construimos la sociedad, es como si lo hiciéramos.
\item
La naturaleza y la sociedad deben permanecer absolutamente separados;
el trabajo de purificación debe permanencer separado del trabajo de
mediación.
\end{itemize}
Para Jonas el diseño se ocupa del mundo posible y hay en el una
asumpción antropológica: La habilidad de diseñar es una característica
esencialmente humana cuya función esencial es la concepción y proyección
de las condiciones humanas de vida. El diseño ``es el medio para obtener
conocimiento sobre el mundo {[}y{]} no podemos superar nuestro
involucramiento en ese proceso'' (Jonas 2007 pp. 194). Como diseñadores
no podemos separarnos y ser sólo observadores de lo observado, sino que
el diseñador es visto como un sistema que se auto-organiza, ``que está
observando un artefacto que evoluciona más el o ella observando el
artefacto que evoluciona''(Jonas 2007 pp .193). Jonas también afirma
que el diseño es una práctica reflexiva, en línea con lo establecido por
Dewey cuando dice que conocer es una manera de actuar y que se trata de
pasar de la verdad a la ``afirmabilidad garantizada'' (`warranted
assertibility').
En este mundo de artefactos contigentes y peregnes y de
acciones/conoceres ineludibles como criaturas vivas y hacedoras de
sentido, ¿qué papel nos corresponde como diseñadores entonces, en
particular desde una formación doctoral en diseño? La crítica que se
presentará de Luhmann puede ayudarnos a entrever una respuesta y, como
se dijo, servir de puente para entablar el diálogo entre estos dos
discursos.
\section{Fuchs y Horkheimer: Teoría de sistemas sociales críticos}\label{diseno-evolutivo}
Fuchs y Horkheimer reconocen el potencial de la teoría
aupoiética en los sistemas sociales, al mostrarlos dinámicos y
autoreferenciales, por tanto susceptibles de modificación, sin embargo
critican la perspectiva de Luhmann, pues piensan que es descriptiva y no
normativa. La teoría de Luhmann, centrada en las comunicaciones como
unidad de auto-referencia para conferir a los sistemas sociales
propiedades autopoiéticas es funcionalista: habla del mundo como es y no
como podría ser, y el mundo posible es una preocupación que no sólo le
atañe al diseño, sino, de acuerdo a estos autores, también a las
ciencias sociales.
Como afirman Fuchs y Horkheimer, un lugar donde es notoria la
insuficiencia de la teoría del Luhmann para hablar de lo posible se hace
manifiesto en su tratamiento a la protesta (pp. 115):
\begin{quote}
Las implicaciones dramáticas de la teoría de Luhmann se hacen más
evidentes en su dicusión de los movimientos de protesta. El argumenta
que los movimientos sociales son alternativas sin alternativas (Luhmann
1996b, p.~75ff.), que ellos protestan en contra de la diferenciación
funcional de la sociedad (p.~76), operan dentro de la sociedad en contra
de la sociedad (p.~103, 204), no tienen alternativas que ofrecer
(p.~104), hacen un fetiche la oposición y la forma alternativa de pensar
(p.~159), son inventadas por un público que es notoriamente inestable
mentalmente (p.~204), establecen la provocación como un fin en sí mismo
(p.~206), no poseen profundidad analítica y no saben por qué algo es
como es (p.~207), establece protestas como pseudoeventos (p.~212), son
una forma de comuincación refractaria contra la comunicación (p.~214),
constituyen un aspecto perturbador de la sociedad moderna (Luhmann 1984,
p.~545), y actuan como negadores que debilitan la afirmación de la
sociedad (ibid., p.~549ff.).
\end{quote}
\begin{quote}
Para Luhmann, los movimientos de protesta son reactivos, sin objeto y
peligrosos. Cada movimiento de protesta tiene valores y ciertos
objetivos políticos; por tanto, quiere cambiar la sociedad. Los
movimientos sociales no son reactivos, sino activos y proactivos. La
caracterización de Luhmann apunta a desacreditar la protesta; si la
última no es vista como una función positiva de la sociedad, las
alternativas son consideradas como indeseables. Una sociedad que
previene la crítica parece cercana al una sociedad totalitaria; una
teoría que considera la crítica y la oposición como indeseables es
afrimativa y parece consecuentemente cercana a una teoría totalitaria.
El rol de la sociología en la sociedad es la crítica y reflexión de la
sociedad; una descripción pura de la sociedad como si fuera la mejor
forma de sociedad es no crítica y afirmativa.
\end{quote}
\begin{figure*}[h]
\includegraphics[width=\linewidth]{./graphics/dualidad-agencia-estructura.png}%
\caption{\emph{Zoom in} al mapa de lecturas para ampliar la parte
referidad a la dualidad estructura-agencia y los cuatro tratamientos
posibles: El individualismo en que las personas condicionan lo social,
proyectivismo hacia abajo en el que las estructuras
condiciones a las personas,
El dualismo de Luhmann que los separa, y el de la re-creación
que los integra. Estos dos últimos se tratan con detalle en el texto}%
\label{fig:dualidad-estructura-agencia}%
\end{figure*}
El problema de Luhmann es que coloca como unidad de la autopoiesis
social a las comunicaciones, pero no cuenta ni de su contenido, ni su origen,
ni de lo humano en ellas, particularmente si se trata de la protesta. Esto tiene
varias consecuenciasn en partiuclar sobre un problema esencial no sólo
para las ciencias sociales, sino para el diseño y es el de la relación
agencia/estructura (véase figura \ref{fig:dualidad-estructura-agencia}),
que se puede resumir en esta pregunta ¿cuál es la
relación entre la agencia humana y las estructuras que habitamos? En
dicho problema subyace la pregunta de si podemos cambiar el mundo, si
podemos pasar del mundo que tenemos al mundo posible. Según
Fuchs y Horkheimer la respuesta de Luhmann al problema agencia y estructura
es dualista: Los seres humanos somos simples observadores de las
comunicaciones y son ellas las que constituyen los fenómenos sociales:
humanos y sociedad van cada uno por su lado, avanzando en paralelo, pero
sin influenciarse de a mucho. Es quizás desde allí que los
\emph{artefactos contingentes} de Jonas podrían leerse en una
perspectiva nihilista.
¿Cómo puede una teoría social descriptiva (de las cosas como son) y no
normativa (de las cosas como deberían ser) dar cuenta de una teoría del
diseño?
La clave para mí está en la propuesta de Fuchs y Horkheimer al colocar a
los humanos como la unidad social y preservar el caracter autopoiético
de los sistemas sociales desde esa otra unidad (pp. 126):
\begin{quote}
La teoría de sistemas sociales críticos ve a los humanos en el centro de los sistemas humanos,
argumenta que los humanos coproducen y reproducen las estructuras sociales, que condicionan
las acciones humanas venideras, por las cuales de nuevo esas estructuras emergen y son
reproducidas, etc. Este proceso dinámico y dialéctico es denominado re-creación. La Re-creación
es un proceso autopoiético porque la hunidad de actores humanos y estructuras sociales que
constituye la socialidad es permanentemente reproducido y reemergente. La agudeza de los
problemas sociales globales requiere que la teoría social de hoy no sólo sea descriptiva
y analítica, sino normativa y en el interés de los grupos e individuos oprimidos. Por tanto,
argumentamos que el caracter de centrado en lo humano debería ser visto como una característica
crítica de la teoría social contemporánea.
Son los sistemas sociales autopoiéticos? Si, pero sugerimos una
comprensión que es centrada en lo humano y por tanto se aparta de la
interpretación de Luhmann. Argumentamos que los humanos permanentemente
crean la unidad de actores humanos y estructuras sociales, es decir, la
socialidad humana, en sociedad. Lo qué es permanentemente creado en
sociedad es la cualidad fundamental de humanos, sus socialidad. La
sociedad reproduce y produce al hombre como ser humano, y el hombre
reproduce y produce a la sociedad al coordinar socialmente acciones
humanas. El hombre es el creador de, u es creado por, la sociedad;
sociedad y humanos se producen al otro mutuamente. Tratamos de enmarcar
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}
\section{Consecuencias de la crítica de Fuchs y Hofkirchner en la teoría de
Jonas}\label{consecuencias-fuchs-en-jonas}
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.
La primera consecuencia es nominal, pero no por eso trivial. Desde la
teoría de sistemas sociales crítica de Fuchs y Horkheimer 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).
\begin{marginfigure}%
\includegraphics[width=\linewidth]{dualidadParticipacionCosificacion.png}
\caption{Dualidad cosificación participación de Wenger}
\label{fig:dualidad}
\end{marginfigure}
Por otro lado permite repensar puentes entre la agencia humana y la
sociedad en su conjunto más grande a partir de las comunidades de
práctica y lo que Wenger\cite{Wenger-1999} ha caracterizado como la dualidad
consificación/participación (Figura \ref{fig:dualidad}), ya que nuevos artefactos,
propiciarían nuevas participaciones. Esto en consonancia con los patrones
emergentes y evolutivos de los sistemas complejos auto-organizados de los que
hablan tanto Jonas cuando aborda la variación, selección y re-estabilización,
como Fuchs y Horkheimer cuando abordan la emergencia de abajo-a-arriba y
de arriba-a-abajo en los procesos de recreación social. Veamoslo más detalladamente.
\begin{figure*}[h]
\includegraphics[width=\linewidth]{jonas-zoom-evolucion.png}%
\caption{Zoom al mapa de lecturas al Jonas y las partes de la evolución.
(las líneas que van hacia afuera muestran relaciones explicitadas en el
mapa entre distintos autores. Los íconos amarillos representan anotaciones
textuales extendidas, hechas para complementar el mapa)}%
\label{fig:zoom-jonas-evolucion}%
\end{figure*}
Las teorías evolutivas abordadas por Jonas hablan de tres procesos básicos para
la evolución: \emph{variación}, en la cual se introducen nuevos elementos al sistema,
\emph{selección} en el cual se selecciona de las variedades creadas en el paso
anterior alguna(s) de ellas y se incorporan a la estructura del sistema y \emph{re-estabilización} en el cual los elementos integrados a la estructura
se convierten en parte integral del sisema y que da cuenta del estado del sistema
como sde su compatibilidad (véase figura \ref{fig:zoom-jonas-evolucion}).
Dado que Jonas se ubica en la lectura clásica de Luhmann, los elementos,
corresponden a la comunicación, las estructuras en este caso corresponden a las expectativas.
Desde allí nos dice que podemos tener alto control en la variación, pues somos quienes
las introducimos al sistema, pero no sobre la selección o reestabilización.
Según Sanders (citada por Jonas) la selección entre todas las variaciones
posibles se suele hacer desde criterios de lo usable, lo deseable y lo útil,
y que si bien somos bastante buenos en diseñar para la usabilidad y estamos
haciendo progresos en diseñar para lo deseable, somos aún muy débiles en
diseñar para lo útil, esto es consecuente con esta perspectiva, pues acá el diseño
es un acto externo al uso, que ocurre procurando un cambio, proponiéndolo, desde
una mirada exógena: el diseñador como profeta e intérprete de lo que otros
deberían hacer/usar, así que no es de sorprender que las propuestas sean deseables
y que elementos como la ergonomía cognitiva nos permitan concretar una
largra tradición de usabilidad, pero al ser exógeno la pregunta por lo útil
pareciera siempre a \emph{posteriori}.
En las comunidades de práctica, sin embargo, vemos
un camino inverso y la utilidad es la que prima en la creación conjunta
de artefactos que transitan en dichas comunidades, aunque es la
comunidad la que diseña para sí misma, desde sus dinámicas de
cosificación y participación en lugar de ser ``intervenidos'' por el
diseñador externo. Un ejemplo puntual de esto se puede encontrar en las
comunidade de Unix/Linux, donde las personas crean artefactos para,
según su propio argot, \emph{rascar su propia comezón}\cite{Coleman_2013_coding_freedom},
para resolver un problema de cada cual, cuya solución luego comparten con otros.
El criterio de utilidad es el primero que se usa en el diseño: si no alivia la comezón,
no es el artefacto adecuado. La usabilidad y el deseo en cambio no
ocupan altas prioridades, sobre todo para quienes no han pasado por el
acto iniciático de entrar en la subcultura del uso del sistema
operativo y que les puede parecer un lugar poco deseable y usable.
Sobre la poca usabilidad y deseabilidad de Unix hay un largo libro
que puede ilustrar muchos puntos ciertos:
``The Unix \emph{Haters} Handbook''\cite{Garfinkel:haters}.
Esto no deja mejor parados a otros sistemas operativos y en general al paradigma
dominante de la computación. Otros presentes posibles que podrían constituir nuestro
cotidiando respecto al uso de los computadores ``al servicio del espíritu humano''
\cite{Ingalls1981-Principles-Smalltalk} fueron cercenados en el
pasado\cite{Maxwell-2006_tracing_dynabook} y hoy vivimos con el mundo que nos queda.
Esto, sin embargo no hace que las comunidades en torno a estas tecnologías
y los individuos en ellas dejen de persistir, al margen de la popularidad.
Son artefactos que hacen sentido para las personas y colectivos alrededor
de ellos, que los usan y los (re)hacen de modo permanente y abordan
de modo paralelo dos los problemas planteados por Sanders, pues el sentido
y la filiación ayudan a resuelver en simultánea el deseo y la utilidad.
Algo similar se puede decir del quehacer artesanal, que se centra en
lo útil, bello y usable, sin pretensiones grandilocuentes, sino ocupándose
los problemas desde la unidad del hacer-pensar que menciona Sennet\cite{Sennett_artesano_2009}.
Sin embargo, esta otra mirada del diseñar como actividad inherentemente
humana no ocurre centrada en las comunicaciones,
sino en los actos de sentido de las personas y las comunidades de práctica
que constituyen y habitan.
Las comunidades de práctica son un puente que no sólo permiten pasar de
abajo a arriba, desde la agencia humana a las estructuras sociales, sino
regular la influencia de la estructura en la agencia humana desde arriba
hacia abajo.
Es decir que la reinterpretación de lo social desde Fuchs y Horkheimer en
las teorías autopoiéticas del diseño de Jonas, nos permite abordar algunas
cuestiones que desde la perspectiva de Sanders son preguntas abiertas
sobre los procesos de selección, pero cuyas respuestas son cotidianas
si se piensan desde las comunidades de práctica. Estas comunidades son además un sitio
donde no sólo se puede experimentar, sino persistir con la variación, es decir
con la creación de posibilidades alternativas al mundo y los artefactos que tenemos
y mantener más controladas, aunque no por ello predecibles, la selección y
restabilización. Son un lugar desde donde explorar y persistir en la diferencia,
si valoramos y respetamos la agencia de personas y comunidades en la construcción
de mundos posibles y mejores.
Precisamente Krippendorff, habla de la necesidad de involucrar más \emph{stakeholders}
en el proceso de diseño y no reservarlo de manera exclusiva a los diseñadores, como
compromiso ético del diseño:
\begin{quote}
Algunos académicos han sugerido que el diseño es una empresa ética.
Si los diseñadores se dan cuenta que ellos no pueden ir sólos, no pueden forzar
sus concepciones sobre otros, y que lo que sea que ellos propongan debe resonar con
las concepciones de los \emph{stakeholders}, as preguntas que los diseñadores
necesitan preguntar son implícitamente éticas. El único principio ético que yo
adicionaría es evitar monopolizar el diseño en una profesión y en cambio
delegar la práctica a tantos \emph{stakeholders} como sea posible. El diseño es una
actividad humana básica a la cual todo el mundo tiene acceso. Los diseñadores profesionales
no deben usurpar la habilidad de otros \emph{stakeholders} para diseñar su propio futuro
--Krippendorff (pg 75)
\end{quote}
Para el caso de las comunidades de práctica este involucramiento es evidente como
muestran las investigacinoes de Manzini y Meroni sobre
innovación social emergente\cite{Manzini_Meroni}, 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.
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.
%----------------------------------------------------------------------------------------
% CHAPTER 2
%----------------------------------------------------------------------------------------
\chapter{De todos los mundos posibles, uno potenciador de
lo humano, emancipador y construido en comunidad}\label{mundos-posibles-humanos-comunitarios}
En la diversidad de saberes y perspectivas epistemológicas que hay
en diseño tanto las mencionadas brevemente al comienzo de este escrito como
muchas que no, hay una cosa el común:
el diseño es una actividad humana que se ocupa del mundo posible.
La búsqueda de dicho mundo tiene dos preguntas importantes:
¿Cuál mundo de entre todos? y ¿Cómo lo creamos? Si estas preguntas reflejan preocupaciones
claves para el diseño, la formación doctoral en diseño debería ayudarnos a contestarlas,
así que el papel de la investigación en las tentativas de solución a esas
dos preguntas, también es un tema de esta sección.
Las secciones precedentes nos permitieron un recorrido que nos deja ahora
en condiciones de proponer respuestas a esas preguntas. Y usamos acá la
primera persona del plural porque estas respuestas nos corresponde a todos
nosostros, quien escribe este texto, quien lo lee y quienes están por fuera
de este ejercicio académico, pues sólo la participación plural y amplia en la
construcción del mundo posible nos dará uno más potenciador de lo humano.
Fuchs y Horkheimer nos dicen que una teoría social, en un mundo que afronta
problemas como el nuestro, no puede ser sólo descriptiva,
ya qe los problemas existen, al margen de que los queramos reconocer como tales, es más
yo agregaría que muchos de ellos se dan por nuestra causa. En este sentido ambos
asumen la postura del perspectivismo de Bertalanffy en la Teoría General de Sistemas,
que no asume una postura de constructivismo extremo, en el cual la realidad
es toda creada por nuestras interpretaciones, incluidos los problemas, ni tampoco
supone una realidad totalmente objetiva, al margen de lo que pensemos de ella.
En ese sentido el perspectivismo no es ni absolutista ni nihilista (pp 120).
Los procesos con los que re-creamos y co-creamos la sociedad y los seres humanos
dan cuenta de la naturaleza cambiante del mundo social. Esto quiere decir que no
sólo estamos en condiciones de definir nuevos problemas, abordar viejos de modos
alternativos, sino de negociar el problema y sus soluciones.
En este sentido no todos los problemas son por completo construidos por todos y,
por ejemplo, la muerte en varios miles de Chigüiros en los llanos colombianos
por una sequía producto de una política ecológica laxa, permisiva y extraccionista,
es un problema, al margen de si el gobierno o las multinacoinales lo reconocen
como tal.
Así las cosas y dado que no podemos entrar a ese nivel de detalle para saber
qué mundo queremos de entre todos los posibles, sólo podemos dar un conjunto
de lineamientos, una posibilidad normativa de los criterios que deberían tenerse
en cuenta en la negociación del mismo y su búsqueda.
Algunas pistas sobre esa negociación nos las brindan Fuchs y Horkheimer es su
perspectiva materialista de la teoría crítica que describen como tal en tres
sentidos (pp 115):
\begin{itemize}
\item
\emph{Es materialista}: ``En el sentido que aborda fenómenos y problemas no en
términos de ideas absolutas y un desarrollo social pretederminados, sino en términos de
la distribución de recuros y las luchas sociales. La realidad es vista en términos que
abordan tenencia, propiedad privada, distribución de recursos, luchas sociales, poder,
control de recursos, exploración y dominación.''.
\item
\emph{No es contructivista}: ``porque encontramos difícil concebir la sociedad sólo como
un constructo de la mente humana.''
\item
\emph{Es realista}:``Asume que la realidad social existe objetivamente y que es
reconocida y transformada por humanos que son parte de la realidad social y forman
esta realidad en interacciones conotro.
Nuestro abordaje puede ser clasificado como una variedad del realismo crítico''.
\end{itemize}
No creo que todas las preguntas preguntas sobre el deseo o lo bello, o el poder
se puedan colocar en perspectiva materialista.
Pero indudablemente el diseño debe ocuparse de un mundo posible
con mayores garantías para la busqueda de sentido y potencial individual y comunitario
para todos y todas y con el sostenimiento y diversidad de la vida presente\footnote{
No me ocuparé acá de si queremos diseñar otras creaturas vivas, pues no es el
texto ni el momento para abordarlo, sin embargo, el sostenimiento de la
vida presente, salvo los supervirus y otros entes vivos por el estilo
si me parece una compromiso asumible. Las negociaciones en la diversidad podrían
terminar con alguna de ella y son un tema sensible para el cual no hay espacio
suficiente}
y en ese sentido debe incorporar las inquietudes de la teoría crítica, muchas de las
cuales toman cuerpo en la protesta que estos autores reivindican mientras que Luhmann no.
Ya hay indicios de cómo la transformación posible del mundo pasa de la
protesta a la propuesta,y sin invalidar la primera, muestra prototipos viables
de otras maneras de habitar el mundo compartido, que repiense los modelos de
gobernanza, filiación y propidad (Bauwens, Ghalim) o que establezcan
críticas a los modelos de desarrollo neo-liberal que ponen el derecho a
la propiedad y al lucro por encima de otros derechos más fundamentales
(Coleman 2013). Así, sin una explicitación clara de una agenda
materialista, vemos algunas de esas inquietudes incoporadas en las acciones
cotidianas de las comunidades de la denominada innovación social difusa de Manzini.
Todas estas comunidades participan y construyen su propia cultura
material y cambian los artefactos, espacios y pactos sociales que
permiten hacer viable su otro modelo de vida. En la medida en que esos
modos de vida tienen sentido para quienes participan de ellos, los
artefactos cobran sentido, pues hacen parte del diálogo de cosificación
y participación: la participación humana crea artefactos/cosas que
facilitan (o no) participaciones futuras. Su caracter contigente tiene
que ver con la posibilidad de ser repensandos para dar cuenta de otros
modelos de mundo de otras formas de participar y hacer sentido del
mismo y en ese sentido no hay contradicción con Jonas
cuando nos recomienda no centrarnos en el artefacto como elemento
central de la investigación \emph{a través} del diseño (en este caso
se convertiría en R + D, como dice Findinelli), sin embargo yo no sólo diría que el artefacto
es una materialización necesaria, pero contingente, sino ineludible.
Los ejercicios de diseño compartido están mediados por artefactos que
se comportan como prototipos y argumentos sobre cómo hacer viable el
mundo posible, para comunicarlo a aquellos con quienes diseñamos y vivimos
(Saikaly 2005, Keller\cite{Keller_2007_Inspiration}), en ese sentido los prototipos
``hablan el lenguaje de la experiencia, el cual nos une en el mundo.
Siven como portadores y realizando esas experiencias compartidas
facilitan la comunicación''\cite{Stappers_2007_doing_research}.
Los artefactos son contigentes por su caracter de prototipo, nos hablan
de otros artefactos posibles para rediseñar el mundo al mismo tiempo que nos
unen en este. Debemos estar atentos a esa dualidad.
Los artefactos-prototipos acá son entendidos en el
sentido amplio e incluyen a los espacios que habitamos y de hecho la
anotación de Keller respecto a que los diseñadores viven con sus prototipos,
se podría poner en diálogo con Manzini y Meroni cuando la investigación sobre
estas comunidades innovadores y alternativas tiene este enfoque quasi-etnográfico,
pues acá los diseñadores viven \emph{dentro} de sus prototipos pues toman la forma
de las comunidades y los espacios que estas habitan con las cosas que los pueblan
y las relaciones con el entorno. En esta otra investigación que reconoce la
preocupación por la contrucción conjunta de mundo, ya no sólo estamos observando
el artefacto con nostros observando el artefacto evolucionar, sino que somos
detonantes de su evolución, en la medida en que estamos dentro de la comunidad,
haciendo sentido con ella y nuestros trabajos de campo irían en la línea
sugerida por Manzini y Meroni de abordar lo bello, lo innovador y de
investigar sobre la felicidad, en últimas de indagar sobre aquello que
para nosotros es significativo y participar del rescate de la utopía
propuesto por Bloch, a través del \emph{no todavía}, en el sentido de que
la utopía ``no es más un sin lugar deprivado de posibilidad para llegar allí,
sino un futuro a que puede ser avizorado y anticipado in lo que es
posible aquí y ahora''.
Pero estas no son las únicas consecuencias investigativas y metodológicas,
sino que habría otras que implican poner a dialogar los enfoques
sociales críticos y sus metodologías dialéticas de unidad en la diversidad,
búsqueda activa de contradicción y dinámicas de análisis y síntesis, propuestas por
Fuchs y Horkheimer, con las propuestas por Jonas que apelan a la teoría fundada y
la investigación acción, ya que ``admiten el involucramiento del investigador
junto con la emergencia de teorías de datos empíricos, en contraste con el
tradicional concepto de construcción de la teoría como verificación de la hipótesis
previamente formulada.'' (Jonas, 2007 pp. 192).
La pista que se me ocurre en este momento es asumirse como sujeto político que
mira-hace al sistema que evoluciona con uno adentro mirando-haciendo.
Esa explicitación política involucra un discuros de poder que pone manifiesto
el papel del investigador en la (de)construcción del mundo posible.
Dicha deconstrucción está emparentada con la historia del diseño, pero se
propone acá no tanto una historia real de lo que es, sino una historia virtual
de lo que hubiera podido ser. Se trata de ubicar sobre todo los puntos de bifurcación
pasados que se agotaron, cortaron u ocultaron para encontrar allí, como propone
Jonas y Krippendorff las claves de lo posible. Hasta ahora tenemos historias lineales
hacia atrás que nos hablan sobre todo de como llegamos a donde estamos, tenemos
que junto a ellas ubicar la pregunta por dónde podríamos haber estado si siguieramos
un punto de bifurcación y reactivarlas cuando sean pertinente, lo cual
tiene el trabajo adicional de comunicar el mundo actual que el que hubiera podido
ser (véase figura \ref{fig:bifurcacion-estudio}).
\begin{figure*}[h]
\includegraphics[width=3in]{bifurcation-points-complex-system.png}%
\includegraphics[width=3in]{bifurcation-technology.png} %
\caption{Patrones de bifurcación en los sistemas no líneales (izquierda)
y en la evolución de artefactos (derecha) (Tomados de Jonas 2007).
Acá se propone agregar a la historia del diseño no sólo lo de que es,
sino la de lo que hubiera podido ser, con especial atención a las bifurcaciones
y lo fallido.
}
\label{fig:bifurcacion-estudio}%
\end{figure*}
El desafío investigativo es más grande que el comunitario. Las comunidades
continuaran codiseñando y haciendo sentido desde el cotidiano, al margen
de si existe sobre ellas una lectura y acción activa desde la investigación
en diseño.
Las comunidades que hoy exploran ese mundo deseable y futuro,
habitando el \emph{no todavía} de la utopía enfrentan tensiones y fragilidades
y las externalidades de sus redes pueden ser cooptadas por discursos
hegemónicos. Hay un problema latente y vigente que abordar allí que le
compete al diseño en la configuración de un mundo posible, y como acá, ya
no se pregunta por cualquier mundo posible, sino que lo hace pensando en
uno que sea emancipador y posibilitador de lo humano, debe velar por
proteger, dinamizar y extender el asomo de mundo que dichos lugares y
personas representan.
Como se podrá notar las consecuencias expandidas de esos dos enlaces interconectados
en el mapa de autores presentan desafíos grandes. Para asumirlos el metabolismo cognitivo
de Bonsiepe no debe aplicarse sólo desde el diseño a otros saberes, sino también desde
el diseño hacia sí mismo. La metáfora del metabolísmo implica dos procesos, uno catabólico
en el que se libera energía desde la degradación de compuestos en partes más simples y otro
anabólico en el que se usa la energía liberada para construir componentes a partir de
otros elementos más sencillos. Los ejemplos de Bonsiepe son en su mayoría anabólicos,
como lo ha sido este texto hasta acá.
Ahora quiero ofrecer un ejemplo catabólico en el que se ve parte de los componentes
que hicieron este texto posible.
Ellos toman la forma de algoritmos e infraestructuras, que ocultamos en nuestro
esfuerzo de textos puros, pero que serían inconsecuentes con un viscurso impuro.
Pues explicitar estas palabras dentro de algoritmos e infraestructuras en ``la nube''
no sólo es un ejercicio de escritura, sino que permite mostrar los componentes que
permitirían otras recombinaciones si se les aplica energía.
Explicitar no sólo las concialiciones, sino los componentes y procesos para otras
recombinaciones, son parte de hacer posible la construcción compartida de variedad
en principio y en últimas de mundo.
\clearpage
%----------------------------------------------------------------------------------------
% PARTE 2
%----------------------------------------------------------------------------------------
\part{Jalonando la modificación recíproca de artefactos digitales y comunidades}
\label{part:bootstrapping}
%----------------------------------------------------------------------------------------
% CAPITULO 3
%----------------------------------------------------------------------------------------
\chapter{El contexto: culturas hacker globales y locales}\label{cultura-hacker}
\section{La multisituada cultura hacker}\label{hacker-zoom-out}
\section{HackBo, un hackerspace en Bogotá}\label{hacker-zoom-in}
\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 ello 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 libre 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 man e 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 Windows me tenía acostumbrado.
Por otro lado, también me seducian 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 épica teníamos por ejemplo que configurar
las frecuencias de barrido horizontales y verticales del monitor adecuadamente, o correr el riesgo
de quemarlo, como efectivamente hicimos con un amigo).
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 desistalado 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, por ejemplo como configurar computadores livianos conectados
a máquinas pesadas (en la comunidad LTSP) o cómo usar editores de texto científico (en la comunidad
de TeXmacs) o legales y filosóficos del software libre (en la comunidad Colibri),
por ejemplo qué libertadas definían al software libre, cómo sue 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, que
justifica 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 Colibir o FISLC,
y en los años siguientes acompañé su transformación el en FLISoL o 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.
En el 2010 ayudé a fundar HackBo, del cual me he ocupado anteriormente en este texto.
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.
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.
Respecto a la programación y modelación computacional, me inicié con el lenguaje
\emph{logo} en la escuela primaria en los ochentas, computadoras científicas Casio 4500
en el colegio y luego con 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, Python y Smalltalk
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 (Luna 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,
Mathcad y Matemathica, y fue en este último donde encontré la primera idea unificadora
de la computación, con la idea de 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, Octave,
Yacas, Mathpiper, Maxima y otros programas y formatos para escritura matemática, entre los
que estaban LaTeX, MathML y uno que permitía particularmente la escritura de documentos
estructurados científicos interactivos, integrando varios de los paquetes ya mencionados,
llamado TeXmacs, 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.
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 interface 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 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.
%----------------------------------------------------------------------------------------
% CAPITULO 4
%----------------------------------------------------------------------------------------
\chapter{Habitar el problema}\label{habitar-el-problema}
En la primera parte se habló de como el diseñador "habitaba el prototipo" cuando se
acercaba a las comunidades y codiseñaba con ellas.
También se reconoció el caracter de investigador como sujeto político, que no
intenta describir objetivamente un fenómeno, sino que está involucrado con él
intimamente.
Una metodología consecuente con esta forma de conocer está de la mano de
las epistemologías feministas y se crea un viraje desde la observación
participativa a la participación observante.
Los capítulos de esta segunda parte describen el problema y los prototipos
desde esa perspectiva inmersa en la comunidad y si bien inician con una pregunta/objetivo
relativamente claro en esta narrativa organizada que demanda la academia,
esta misma fue aclarándose en la medida en que dicho habitar se daba, como es propio
de los problemas difusos de los que se ocupa el diseño.
El relato tiene una recurrente voz en primera persona, pero también
se intercala con lecturas del trabajo colectivo y nombres de personas
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.
\section{Prehistoria: Hábitats digitales e Indie Web Science}\label{prehistoria}
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, e 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, 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.
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.
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}, que fuera de fácil montaje y con la ventaja de una gran cantidad
de \emph{plugins} preexistentes.
Mi contra argumento 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",
que HackBo fuera un lugar donde ocurriera.
Se planteó una bifurcación,
%LATERAL: bifurcación
clásica de las comunidades hacker y una resolución
propia de la \emph{tiranía del hacedor}, %LATERAL: 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 web framework hecho en Python,
llamado web2py.
Nadie más implementó el sitio en PHP.
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 plugins, como wikis en PHP, %LATERAL: dokuwiki,
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 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, grav, 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) y
descripción de datos (yaml), similar al que usaba 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.
Esto me permitía entregar el sitio a otra persona que lo quisiera administrar
o cambiar e hice el respectivo correo a la lista, 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, Twitter, Facebook y repositorios de código en GitHub.
Desde finales del 2012, había empezado a explorar formas de combinar la escritura
arbórea de Leo, con la escritura interactiva de libretas en IPython, lo cual permitiría
ir agregando estructura progresiva y emergente del primero a la computación
exploratoria propia del segundo.
En aquel entonces escribí (luna-on-deepnes):
\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 línea (TeXmacs, Tiddly Wiki, 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/partdias 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}
Finalmente esperaba 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 \REF, sobre dicha idea e hice algunas preguntas
sobre cómo implementarla en la arquitectura de ese entonces de IPython \REF,
pero no hubo mayor interés y tampoco mayor esfuerzo de mi parte en mover dicha idea en la
comunidad internacional, al menos sin tener más prototipos desarrollados localmente.
Empezamos, entonces, a explorar estas 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}\footnote{
Los nombres en inglés de dichos eventos ayudaban a
comunicarlos a comunidades internacionales y posicionarlos en motores de búsqueda}
\REf.
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}.
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 combina los términos \emph{hack} y \emph{maratón} parece haber
surgido, según la Wikipedia \REF, 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\Ref y Schrock \Ref,
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"\Ref, 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." \Ref
El fenómeno hacker, multisituado y de orígenes diversos, también está siendo
gentrificado, como diría Scott, 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 hicieorn 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 porta 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 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 ?
El Data Week y Grafoscopio
\section{Grafoscopio}\label{grafoscopio}
Grafoscopio, según su sitio web, es:
\begin{quote}
una herramienta amoldable para documentación interactiva y visualización de datos, que está siendo usada para ciencia abierta, ciudadanas y de garage, investigación reproducibles, (h)ac(k)tivismo, innovación abierta y comunitaria , visualizaciones de dominio específico, y periodismo de datos, entre otros usos actuales y potenciales. Grafoscopio está cubierto por una licencia libre y de código abierto (MIT) y se socializa, realimenta y modifica en un taller-hackatón recurrente de una semana llamado el Data Week, que está orientado principalmente desde preguntas ciudadanas mediadas por datos y visualización.
Grafoscopio es y usa "infraestructuras de bolsillo", sencillas y autocontenidas, que pueden ejecutarse On/Off-line, desde una memoria USB, una rasberry-Pi, un servidor modesto y cualquier otra infraestructura intermedia o más potente.
\end{quote}
Sus orígenes se remontan a mediados del 2014 y están documentados en:
Esencialmente son una continuación de lo esbozado al final de examen de candidatura
de ese entonces, respecto a la necesidad de artefactos que facilitaran el
metabolismo cognitivo, indicando las distintas capas que los constituyen,
permitiendo también la recombinación y trazabilidad de las mismas.
\subsection{Autorreferencialidad y Bifurcación}\label{auto-bifur}
Acá la idea de autorreferencialidad de la que se ocupa el diseño,
esbozada en la primera parte, toma cuerpo en este artefacto digital y las prácticas con éste
de dos maneras:
\begin{itemize}
\item
Es un artefacto hecho para escribir, en particular sobre el artefacto mismo,
lo cual genera ciclos de realimentación que cambian tanto el artefacto,
como el proceso de escritura (veáse figura \ref{fig:realimentacion-artefacto-escritura})
\item
Las tecnologías con las que está hecho Grafoscopio, son meta-sistemas (Markus),
es decir sistemas tecnológicos hechos en sí mismos, con lo cual permite mayor
simplicidad y extensibilidad.
\end{itemize}
\begin{figure*}[h]
\includegraphics[width=\linewidth]{./graphics/Parte2/realimentacion-artefacto-escritura.png}%
\caption{Realimentación entre escritura y artefacto en Grafoscopio. Tomado de Luna 2014. }%
\label{fig:realimentacion-artefacto-escritura}%
\end{figure*}
Estas dos maneras se combinan en una idea fuerza:
\emph{
Al escribir en Grafoscopio documentos interactivos, que requieren el desarrollo
de competencias computacionales, para modelar y hablar de fenómenos complejos mediados por datos
y sus visualizaciones, el autor de tales documentos aprenderá no sólo el lenguaje y entorno para
su problema/prototipo, sino aquel con el que está hecho todo el sistema.
Es decir, en el camino de hablar sobre un fenómeno mediado por simulación, modelación,
datos y visualización, aprenderá a cambiar la herramienta que le permite establecer dicho diálogo.
Así, {\bfseries la herramienta que cambia sus maneras de pensar, percibir y expresar un problema,
usando documentos interactivos y visualizaciones, puede ser cambiada de vuelta por el autor/lector,
de tales documentos y visualizaciones}}.
Rushkoff\cite{rushkoff_program_2010} habla de una barrera entre los usuarios
y hacedores de artefactos digitales, medida por la programación,
que ilustra particularmente con el software para escribir:
\begin{quote}
Pero la capacidad subyacente de la era de la computación
es de hecho la programación --la cual casi ninguno de nosotros
sabe como hacer. Simplemente usamos los programas que han sido
hechos para nosotros, y entramos nuestro texto en la caja apropiada
en la pantalla. Le enseñamos a los niños cómo usar el software
para escribir, pero no cómo escribir el software.
\end{quote}
en ese sentido, Grafoscopio usa la escritura de historias
soportadas/orientadas por datos para tender un puente entre el
"software para escribir" y "escribir el software".
En la primera parte se mencionó como la estrategia de diseño para nuevos
artefactos, desde Jonas, tenía que ver con el estudio de los puntos de bifurcación
de artefactos previos y las posibilidades de diálogo entre tales bifurcaciones.
A continuación mencionaré como Grafoscopio da cuenta de dichos puentes:
\begin{itemize}
\item
La idea de los metasistemas y la autorreferencialidad, se esbozaba desde el 2010 y comienzos
del 2011, en una conversación cara a cara con Wolfgang Jonas y se retomó y mostró en el examen de candidatura de 2014 (véase figura XY) %NOTA: Jonas scroll?.
Se hablaba de dos "mantras" de la computación en paradigmas distintos,
que marcaron puntos de bifurcación a comienzos de la misma.
Por un lado estaba la tradición y el mantra de "todo es un archivo" y
la Smalltalk y el mantra de "todo es un objeto".
A su vez se tienen implementaciones de metasistemas en dichas tradiciones:
Con Leo teníamos un (meta)archivo (arbóreo) que integraba y hablaba de otros archivos
(usualmente externos a Leo) y con Pharo/Smalltalk teníamos un entorno de (meta)objetos
que que integraba y hablaba de otros objetos (usualmente internos a Pharo/Smalltalk).
Dichas tradiciones a su vez fortalecieron caminos paraleos: En de los archivos y las
aplicaciones, propio de la tradición Unix y sus derivados (incluidos Windows, Mac y Gnu/Linux)
y el de las simulaciones y las meta-herramientas, propio de Smalltalk.
Mientras el primero estaba orientado a "usuarios finales", que usan aplicaciones para crear
documentos el segundo estaba orientado a programadores que usan meta-herramientas para crear
otras herramientas o aplicaciones y "software educativo", para jóvenes y niños que usan la
simulación para expresar y desarrollar el pensamiento.
Estos, por supuesto, son "acentos" de dichas tradiciones y no factores exclusivos de las mismas.
Sin embargo desde ellos se puede ver una proliferación de herramientas en la cultura de dichas
tradiciones: Los sistemas operativos tienen una miriada de aplicaciones para crear documentos,
y los sistemas Smalltalk tienen meta-herramientas para programadores y jóvenes y niños,
sin aplicaciones populares o ampliamente conocidas fuera de tales nichos.
Grafoscopio une estas dos tradiciones al ofrecer herramienta para documentar, simular y visualizar,
que son "internas" del entorno Smalltalk, pero que pueden producir documentos "externos" al mismo
y con un público objetivo que no se centra en niños, jóvenes o programadores profesionales,
sino que incluye activistas, periodistas, comunicadores, filósofos, investigadores académicos,
químicos farmacéuticos, entre otros (considerados a partir de la población que ha asistido a los
talleres del \emph{Data Week}, que se mencionaran más adelante).
\item
Grafoscopio también explicita las propuestas de integración respecto
a una escritura que fuera arbórea/emergente e interactiva,
con una experiencia similar a la que se buscó con la integración de Leo e IPython,
pero considerando tecnologías mucho más uniformes y simples, y por tanto empoderantes,
en el sentido de que permite expresar en prototipos más fluidamente las ideas. %NOTA: luna iceberg.
Se ha procurado un balance, que sin reducir todo a tecnologías desarrolladas exclusivamente
en Smalltalk, tampoco sea excesivamente diverso y complicado, como se dice en su repositorio
de código
\begin{quotation}
Grafoscopio trata de ser una herramienta simple, comprensible, amoldable, versátil y flexible,
gracias al poder el ecosistema de Pharo Smalltalk y la combinación con frameworks y herramientas maduras externas e internas. Usa:
\begin{itemize}
\item Internas:
\begin{itemize}
\item GT Tools y Spec para los playgrounds embebibles, los nodos interactivos y la Interface \item Gráfica de Usuario (GUI).
\item Roassal para visualización de datos.
\item STON para un ligero almacenamiento de datos y formato de documentos.
\item Fuel: para almacenamiento medio y serialización de objetos.
\end{itemize}
\item Externas:
\begin{itemize}
\item Fossil SCM para colaboración y trazabilibildad de los documentos
\item Pandoc para exportación a formatos pdf/impreso y html/web.
\item SQLite para almacenamiento y manipulación de datos tabulares.
\end{itemize}
\end{itemize}
\end{quotation}
\item
Grafoscopio también explicita las idea de objeto activista, los dominios de ciencia ciudadana,
de garaje y abierta y las \expand{infraestructuras de bolsillo}.
Al respecto, de dichas temáticas, Luna 2014 afirmaba:
\item
Grafoscopio dialoga con ideas de Bret Victor y Alan Kay, respecto a formas de pensar de manera
multimodal un problema, como medio para entenderlo y expresarlo mejor.
Combina la prosa y el código, tanto en las libretas interactivas, como en el entorno continuo
que no separa en capas disyuntas, lenguaje de programación, entorno integrado de desarrollo
(IDE, por sus siglas en inglés), los gestores de código, la aplicación y el documento, facilitando
difuminar la distinción entre usuario y hacedor (problema central de esta investigación)
y usa representaciones simbólicas (código) y gráficas (visualizaciones) para abordar un problema.
\end{itemize}
Es precisamente en los problemas que se abordan y los prototipos que se crean donde se pueden explicitar
estos puentes entre tradiciones y bifurcaciones, tratados anteriormente.
A continuación mencionaré dos de los constructos creados con Grafoscopio que cristalizan dichos puentes.
\subsection{Constructos con Grafoscopio}
Los siguientes artefactos fueron creados en el contexto de Grafoscopio,
pero habitan y dieron origen a un paquete complementario llamado {\ttfamily Dataviz}.
Además se usan para ilustrar lo que se puede crear con él durante los Data Week, pero
no son parte de los problemas abordados durante el mismo.
Las motivaciones y su funcionamiento ha sido ampliamente documentado en dos entradas
al blog (luna-med, luna-pp), bajo la premisa de una investigación doctoral interconectada, que excede los
límites y tiempos confinado dentro de la tesis doctotal y se comunica de maneras más
fluidas hacia afuera, en tiempos más cortos y lenguages menos formales.
Los textos acá son maneras complementarias de referirse a lo descrito en aquellos
documentos y para otros detalles una lectura de las entradas al blog.
\textbf{Visualizaciones de dominio específico para información sobre medicamentos}
\begin{figure}[h]
\includegraphics[]{./graphics/Parte2/gay-rights-infography.png}%
\caption{Visualización de los derechos homosexuales por \emph{The Guardian}, que
sirvió como modelo para las visualizaciones sobre ausencia de información sobre
medicamentos del paquete Dataviz en Grafoscopio. }%
\label{fig:derechos-homosexuales}%
\end{figure}
\begin{figure}
\centering
\begin{subfigure}[a]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/omeprazol-admin-by-country.png}
\caption{A mouse}\label{fig:mouse}
\end{subfigure}
\begin{subfigure}[b]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/omeprazol-by-property.png}
\caption{A gull}\label{fig:gull}
\end{subfigure}
\begin{subfigure}[c]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/omeprazol-pu-by-country.png}
\caption{A tiger}\label{fig:tiger}
\end{subfigure}
\caption{3 visualizaciones a la medida, a partir de la gráfica de \emph{The Guardian},
creadas en el paquete \texttt{Dataviz}, que es parte de Grafoscopio.
Los detalles sobre las mismas y cómo interpretarlas están en Gil-2015.
La historia de como surgieron están en Luna-2016-Infomed}
\label{fig:infomed-visuals}
\end{figure}
La primera visualización servía para apreciar ausencias o presencias de información,
en particular en medicamentos.
Precisamente se trataba de lidiar con un problema metodológico (no encontrar información)
convirtiéndolo en uno investigativo: ¿cómo comparar las ausencias y presencias de información
respecto a medicamentos?
La descripción detallada de este problema y su análisis están en Gil 2015.
Acá se mencionarán los hitos de este abordaje, que complementan el texto del blog:
\begin{itemize}
\item
Pasar de \emph{tener la información} como lugar de inicio, a \emph{usar su ausencia}
como lugar problémico e investigativo.
\item
Se partió de una visualización base de \emph{The Guardian}, respecto a ausencias
y presencias, en este caso de derechos en la población homosexual, como modelo del tipo
de visualización que se quería (veáse figuras tales y pascuales).
\item
Se adaptó una visualización preexistente, que era para información jerárquica,
de modo que permitiera trabajar con la información recolectada, que era de naturaleza
tabular.
Se hizo un algoritmo de conversión de formato tabular a jerárquico y se creó un Lenguaje
de Dominio Específico (DSL, por sus siglas en inglés) para hablar del problema en cuestión.
\item
Yaneth Gil participó de la visualización como experta de dominio, indicando qué quería ver,
qué formatos tenían los datos, parámetros estéticos de las visualizaciones e incluso haciendo
comentarios sobre los algoritmos implementados en Smalltalk, si bien no programaba este lenguaje.
Yo comentaba qué se podía implementar, forzaba el entorno y mi conocimiento para lograr algunas
de sus visualizaciones, y establecimos un sistema de convenciones \emph{ad-hoc} para poder
hacerle consultas a los datos.
Se produjo, así, una negociación entre mi rol como visualizador/programador y el de ella como
experta de dominio.
\item
La solución fue implementada de manera ágil aunque poco elengante.
Habían muchos parámetros en los mensajes del DSL y no se usaba la infraestructura de
\emph{builders}, que permitía abstraer el problema y generar visualizaciones sin
transformaciones de datos y el uso de convenciones \emph{ad-hoc}, que facilitaran su visualización
y consulta. Aún así fue funcional y dio cuenta de los tiempos estrechos para la implementación.
\item
En las distintas implementaciones, tanto de la solución rápida, como de las más elegante,
se contó con la ayuda de la comunidad de Pharo, particularmente de Miltón Mamani, primero
en un encuentro en Argentina, de la comunidad de Smalltalk, luego de manera remota por chat
y finalmente durante mi pasantía doctoral en Chile.
El uso de soluciones cada vez más formales tuvo que ver con mi comprensión progresiva
del problema, el motor de visualización y sus constructos y maneras más acertivas de
participar en la comunidad, pues desde el comienzo Miltón estaba ofreciéndome soluciones
formales (construyendo \emph{builders}), pero yo no tenía los preconceptos adecuados para
aprenderlos y quería continuar con lo que ya tenía y sacar un prototipo funcional desde
lo que ya entendía.
Esto a su vez fortaleció la motivación para crear en los \emph{Data Weeks} caminos de
aprendizaje que facilitaran los recorridos para otros novatos, a partir de mis errores y rutas,
pero sin tener que repetirlas.
Algunos \emph{builders} y problemas pre-tratados ayudarían a futuros aprendices,
a enfocarse en lo conceptual y crear código más suscinto, comprensible y elegante.
\end{itemize}
\begin{figure*}[h]
\includegraphics[width=3in]{./graphics/Parte2/roassal-sunburst-examples-2.png}%
\includegraphics[width=3in]{./graphics/Parte2/matriz-a-arbol.png} %
\caption{Dos adaptaciones hechas al software de visualización, incluidas con
Grafoscopio y su paquete Dataviz, para crear las imágenes en la figura \ref{fig:infomed-visuals}.
A la izquierda visualización base para información jerárquica en lugar de matricial.
A la derecha, ilustración de la transformación de información matricial en jerárquica
para adaptarla a la nueva visualización.
Tomadas de Luna-2016-infomed.
}
\label{fig:bifurcacion-estudio}%
\end{figure*}
Acá el enfasis no estuvo en la documentación interactiva, sino en la visualización de Datos,
por tanto se colocó lo desarrollado en un paquete independiente que tuviera una galería de problemas
que pueden ser abordados con Grafoscopio, llamado {\ttfamily Dataviz}.
Esto forleció la necesidad de dicho paquete y mejoró la modularidad del software.
Algunas veces estaríamos enfocados en la documentación y otras veces el énfasis sería la
visualización.
\textbf{Panamá Papers: investigación reproducible y activismo de datos incluyente}
Otro proyecto realizado durante la pasantía doctoral en Chile fue el de los \emph{Panama Papers}.
(luna 2016-pp).
En este periodo, además se mejorón las visualizaciones de de medicamentos vía \emph{builders} y
se mejoró la interface de Grafoscopio empleando el puente entre el \emph{framework} de
Spec y las herramientas adaptables \emph{GT Tools} del proyecto Moose, desarrollado por
Johan Fabri y con su acompañamiento.
\begin{figure*}[h]
\includegraphics[width=3in]{./graphics/Parte2/Countries_implicated_in_the_Panama_Papers.png}%
\includegraphics[width=3in]{./graphics/Parte2/choropleth.png} %
\caption{Dos mapas sobre los paraisos fiscales.
La de la izquierda, tomada de la Wikipedia, es irreproducible a partir de los datos publicados.
La de la derecha, hecha por el autor, es reproducible y el entorno que la crea y contiene,
incluido el micrositio web, cabe en una memoria USB y se puede ejecutar en un computador modesto.
}
\label{fig:pp-dos-mapas}%
\end{figure*}
Se iniciaba con dos mapas referidos a los \emph{Panamá Papers} y se mostraba que uno de ellos
(el de la Wikipedia) era irreproducible y el otro, desarrollado en Grafoscopio y el Dataviz,
si lo era.
A partir de ello se introducía un micrositio y un entorno portable para explorar el segundo mapa
y sus los datos, aproximándose críticamente a la idea de \emph{Big Data},
mostrando que los datos curados y el entorno para trabajar con ellos podía ejecutarse en
una memoria USB y computadores modestos, de modo que las argumentaciones e historias basadas
en tales datos fueran más participativas e incluyentes.
\begin{figure*}[h]
\includegraphics[width=\linewidth]{./graphics/Parte2/minisite.png}%
\caption{Minisitio desarrollado para el proyecto de los \emph{Panamá Papers}.}%
\label{fig:pp-minisitio}%
\end{figure*}
Los hitos más importantes para el desarollo del proyecto de los \emph{Panama Papers} fueron:
\begin{itemize}
\item
Se hizo un viraje de la idea de \emph{Big Data} a \emph{Frictionless Data} e
\emph{infraestructuras de bolsillo}, en aras de alentar la puralidad y la participación
de lectures y ciudadanos en fenómenos complejos mediados por datos y de escala global,
como los paraisos fiscales.
La elección del tema no sólo tenía que ver con su popularidad, sino con el abordaje
crítico tanto de los datos como de las temáticas: hacer accesible la manera en que los
poderosos guardan su capital, es una manera de pensar el caracter no neutral de los
datos y la información.
Se trataba de mirar, entonces, si se podía abordar la filtración noticiosa con el conjunto
de datos (\emph{dataset}) más grande de la historia con infraestructuras sencillas y
al alcance de más personas, una vez los datos han sido curados y liberados.
\item
Uno de los aspectos claves fue la trazabilidad de la información y se desarrollo la idea
de un \emph{entorno vivo continuo de datos} (\emph{Data continuum [live] environment})
\footnote{Si bien en el texto original no se hablaba del caracter vivo del entorno,
este fue clave en la exploración de los datos, no sólo en este ejercicio/prototipo,
sino en los demás de los que se habla en esta investigación, como fue resaltado en
la entrada al blog sobre la visualización de medicamentos.},
que establecía puentes entre los datos, las consultas, las visualizaciones y los documentos,
permitiendo pasar de los unos a los otros
(véanse figuras \ref{fig:pp-libreta-y-consulta} y \ref{fig:pp-workflow}).
La premisa era que, una vez se publicaban estas narrativas y visualizaciones de datos,
\begin{quote}
El lector podía convertirse en explorador/co-autor en el \emph{mismo entorno continuo completo}
que el autor había usado para crear la visualización de datos publicada, con un sencillo
click de arranque.
\end{quote}
\begin{figure*}[h]
\includegraphics[width=3.5in]{./graphics/Parte2/pp-intro-notebook.png}%
\includegraphics[width=2.5in]{./graphics/Parte2/pp-query-data-environment.png} %
\caption{Izquierda: Libreta interactiva en Grafoscopio de los \emph{Panama Papers}.
Derecha: Consulta a la base de datos y lenguaje de dominio específico integrados
dentro del entorno.
}
\label{fig:pp-libreta-y-consulta}%
\end{figure*}
\begin{figure*}[h]
\includegraphics[width=\linewidth]{./graphics/Parte2/process.png}%
\caption{Flujo de trabajo para la creación de la visualización de los \emph{Panama Papers}
y sus publicaciones de soporte (minisitio y entrada al blog).
Los círculos representan los entornos donde se realizan actividades asociadas a los datos,
representadas por rectángulos.
Se puede apreciar como Grafoscopio, a través de la documentación interactiva,
es el puente entre la exploración y visualización de los datos y su publicación.
Este flujo de trabajo con entornos y actividades fue prototipado como parte de la
pasantía doctoral.
Tomado de Luna-2016-pp. }%
\label{fig:pp-workflow}%
\end{figure*}
\item
El aspecto más dispendioso fue completar y curar la información.
El mapa mundi provisto por el motor de visualización Roassal, no incluía tantos territorios
como los mencionados en los \emph{Panama Papers} (faltaba cerca de un tercio de ellos),
por lo cual algunos datos fueron completados a mano al comienzo y cuando la estrategia mostró
sus limitaciones, al generar errores de integración con los territorios pre-existentes,
pues las coordenadas no coincidían (véase figura tal),
se implementó un algoritmo que resolvía el inconveniente haciendo importaciones de mapa mundis
más completos y con sistemas de coordenadas consistentes.
Esto a su vez permitió detectar y corregir un error el algoritmo de importación de gráficos
vectoriales escalables (SVG, por sus siglas en inglés) y hacer un aporte al núcleo de Roassal.
\item
Se proveyeron imágenes descargables para Windows y Mac que permitían probar el prototipo y
reportar errores, aunque las únicas pruebas y reportes provinieron de colaboradores cercanos
al proyecto y otras personas contactadas vía Twitter y la lista de la \emph{Open Knowledge Fundation}
no manifestaron mayor interés en el proyecto (salvo uno de ellos).
\item
La visualización que se quería hacer era sencilla y si los territorios estuvieran completos,
hubiera salido en minutos, literalmente, pero fue el completar la información y curarla lo que
tomó más tiempo.
Enfrentado a esta dificultad, un programador me sugirió que colocara en la gráfica
"los paises más importantes", para resolver rápidamente el problema.
Cuando se detectó el problema con los SVG, antes mencionado, el proyecto cobró un nuevo
interés desde el punto de vista de lo algorítmico y el desarrollo de software.
Esto reveló una tensión del activismo de datos al estar entre dos mundos: los periodistas
quieren veracidad y no se preocupan por errores (o \emph{bugs}, como son llamados en la jerga
computacional) como el de los importadores del SVG.
Los programadores consideran que curar la información es un trabajo al que no debería
dedicársele mucho tiempo.
La necesidad de un grupo de personas en la mitad, que pueda hacer puente entre estas
dos preocupaciones y dedicarse a ellas es, por tanto, más importante.
\item
Al final de la pasantía, con la ayuda de Alejandro XX, logró empaquetarse Grafoscopio,
usando el sistema de gestión de paquetes y dependencias, Monticello, lo cual mejoraría
el proceso de instalación en las versiones venideras del \emph{Data Week} y la facilitaría
para otros autores/exploradores de datos, que lo usaran a futuro.
\end{itemize}
La necesidad de una comunidad particular de personas interesadas en la visualización
y narrativas de datos, con preocupaciones tanto por la técnica y como por la historia,
había sido detectada previamente.
\footnote{Para mi pasantía en Chile, ya llevaba 3 ediciones del \emph{Data Week} realizadas
y haría una cantidad similar a mi regreso}.
Esta nueva comunidad de práctica, no surgiría en el grueso de los miembros de la
comunidad nuclear de HackBo, pues los intereses por otras apuestas, tecnologías y miradas ya se
había hecho claro en los primeros años, viendo los artefactos y prototipos construidos.
Los caminos de aprendizaje que habían recorrido los miembros del espacio y que los habían llevado
a sus experticias particulares eran muy específicos y extra curriculares y las charlas y talleres
eran esporádicos y suponían públicos relativamente expertos en programación o con intereses
por desarrollarse en temas como la electrónica y la computación física, pero principalmente niños
y jóvenes, sin la edad suficiente para un compromiso crítico y sostenido, como lo muestra la programación
de actividades en el \emph{hackerspace}.
A su vez la \emph{Gobernatón} había mostrado el interés por estos temas críticos y de activismo,
pero también la necesidad de crear capacidad entre los asistentes de manera que un
número mayor pudiera expresar sus ideas a través de la técnica y los artefactos digitales,
sin entrar en las lógicas instrumentales y de "cadena de montaje" en la cual los programadores
eran vistos como aquellos que podían implementar las ideas de otros pero sin preocupaciones
propias que expresar a través de la técnica.
El diseño de un espacio, que recibiera a novatos y donde los lugares comunes y del quehacer
fueran ensanchados, se empezó a hacer evidente, como resultado de la Gobernatón la participación
en otras hackatones (como la de Chicas Poderosas y en la Universidad de los Andes) (véase Luna XY).
El código sería el material para explicitar, negociar, construir y catalizar esos saberes comunes,
desde los cuales podrían ponerse a conversar otros saberes y miradas.
Allí surgió el \emph{Data Week}, que será el tema de la siguiente sección.
\section{El Data Week}\label{dataweek}
El \emph{Data Week }, según su página web, es:
\begin{quote}
[Un] taller-hackatón sobre visualización y activismo de datos donde aprendemos a trabajar e interconectar las representaciones simbólicas (código) y las visuales (visualizaciones) referidas a los datos. Es un taller porque está orientado al aprendizaje mediante la práctica y el ejemplo y una hackatón por su caracter intensivo y orientado a prototipos. La intensión es aproximarse de manera crítica a la construcción, comprensión y mejoramiento de un mundo compartido mediado por tales datos.
[En el taller se] enseña como usar Grafoscopio, una herramienta flexible y amoldable para documentación interactiva, visualización y activismo de datos. Combinamos algo de historia y fundamentación con ejercicios progresivamente más complejos. Luego abordamos un problema común que nos permitirá mostrar cómo se usa, adapta y extiende grafoscopio, cuáles son sus diferencias y valores agregados y, si nos queda tiempo, trataremos problemas diversos, propuestos por los participantes con sus propios conjuntos de datos. Elegimos problemas que pueden ser entendidos mejor con visualización de datos y usaremos una aproximación alternativo al "Big Data", que usa pequeños datos significativos (frictionless data) y sus visualizaciones. La intensión es que el problema común nos de herramientas y saberes para que luego podamos abordar por nuestra cuenta los problemas e inquietudes propias, que pueden ser considerados para talleres y eventos venideros.
También se hará extensiva la participación de los asistentes a vincularse a distintas comunidades locales e internacionales relacionadas con visualización y activismo de datos, herramientas amoldables y datos abiertos, entre otras.
\end{quote}
El vértigo en el hacer, el inmediatismo y la excesiva orientación al lucro y la manoseada "innovación"
de las \emph{hackatones} enagenadas, denunciadas
por Irani con su crítica a la "ciudadanía emprendedora", por Schrock (\emph{hackathons without hacking})
y Luna en la Gobernatón,
son una desconexión evidente a este discurso de la idea de hacer es pensar expresada por Sennet.
El quehacer artesanal tiene un ritmo y continuidad que dichas hackatones no logran capturar ni interconectar.
La idea de pulso, que yo mismo digo, con momentos sosegados y frenéticos tampoco se ve.
Tan sólo hay cabida para los momentos frenéticos.
\subsection{Ediciones: los ritmos, intensidades, temáticas y productos}\label{dataweek}
Debido a su caracter simultáneo de taller y hackatón, el \emph{Data Week} buscaba lograr
un balance entre el aprendizaje guiado, que permitiría asumir los conceptos necesarios
para la exploración autónoma luego, y los problemas abiertos, sin una respuesta preconstruida
para ser enseñada.
Cada una de las ediciones sucesivas del evento fue una exploración de dinámicas
e infraestruturas que se acercaran a este balance, durante el periodo entre junio de
2016 y noviembre de 2016, en el cual se desarrollaron 7 ediciones del mismo, probando
diferentes esquemas.
El propósito era lograr una experiencia intensiva, que contrastara con los esporádicos
tallerdes de \emph{Indie Web Science}.
Tener un taller de cerca de 30 horas, que se pudiera incorporar a la vida sin requerir de
demasiados esfuerzos extra.
La primera edición (junio 22 al 27 de 2015) ocurrió todas las noches de 5 pm a 9 pm y el
sábado todo el día, pero debido a que era parte de una semana laboral habitual, los ritmos
eran extremadamente desgastantes para los participantes, en particular para mí en mi rol de organizador.
La temática acá fue \emph{los mapas del silencio}, que buscaban mostrar qué tanto
contestan o no los políticos en Twitter. %NOTA: Referenciar: http://mutabit.com/offray/static/blog/output/posts/que-tan-bien-usa-el-ministerio-tic-de-colombia-las-tic-para-comunicarse-con-los-ciudadanos.html
Si bien el código era desordenado, se lograron avances, pasado de prototipos en papel
a gráficas computacionales, (véase gráfica tal y detalles en luna mapas),
que empezaron a mostrar que efectivamente el entorno de visualización ágil,
integrado en Pharo y accesible desde Grafoscopio, permitía rápidos avances con respecto
a los talleres de Indie Web Science e incluso con respecto a otras hackatones de periodismo
de datos y visualización, que sólo se quedaban en la maqueta (\emph{mockup}), sin
apelar a datos o resultados algorítmicos tomados de fuentes reales de información (cfg César Arias).
La segunda edición (septiembre 21 al 26 de 2015) se hizo dentro de una semana
de descanso de la Universidad Javeriana, en el marco de una investigación conjunta
llamada Ciudad de Datos, en la que participé como co-investigador, pues se pensó que
mucha de la población interesada, sería estudiantes universitarios.
La intensidad horaria aumento a 6 horas diarias, que entre semana estaban repartidas en
un par de horas (10:30 AM a 12:30 PM) en la mañana, un receso para el almuerzo y 4 horas
en la tarde (2:30 PM a 6:30 PM, aprox.) y el sábado iban de 2:30 pm a 8:30 pm.
La asistencia no fue muy masiva y los estudiantes universitarios prefirieron invertir
su semana de receso en otros lados.
Esto no fue un impedimento, pues desde los talleres y encuentros en la prehistoria del evento,
se había decidido que lo importante, más que la asistencia masiva, era el carécter comprometido
y continuo de la participación.
Sin embargo esta intensidad horaria por sesión mostró ser adecuada
para la consecución de mejores resultados, pues si bien era más demandante,
se beneficiaba de mayores tiempos de concentración de los participantes
el mismo sitio (en el anterior horario, con sesiones más cortas
y viajes en la noche, los participantes se empezaban a
alistar y se marchaban desde antes).
El principal avance en esta edición fue la mejora del tutorial interactivo de Smalltalk,
hecho en Grafoscopio y la consolidación de algunas visualizaciones de los
\emph{mapas del silencio} en el paquete {\ttfamily Dataviz}, lo que a su vez permitió iniciar
una didáctica particular, en la que se mostraba cómo los algoritmos, prototipados
colectivamente con los asistentes, se incorporaban al conocimiento cristalizado en
el sistema a través de paquetes y cómo se podía empezar a navegar y deconstruir dicho conocimiento.
Esto constituyó un avance respecto a lo anterior, pero no había un paquete de visualización
totalmente usable por un participante
al final del evento, ni mucho menos por alquien externo.
Quedó más claro que la intensión del \emph{Data Week}, en parte, era iterar sobre esos
prototipos imperfectos e irlos mejorando con sucesivas ediciones.
La tercera edición se probó partir el \emph{Data Week} en dos sesiones,
ambas de jueves a sábado, de 2:30 PM a 6:30 PM (ocurridas en febrero 25 al 27 y marzo 3 al 5 de 2016).
Si bien estas sesiones implicaban que algunas personas deberían contar con dos tardes dentro
del horario laboral habitual, o bien los asistentes contaban con flexibilidad del tiempo,
o bien era un permiso que se podía solicitar en caso de que no.
Lo cierto es que esta forma de organización generó la asistencia más regular, con jornadas
suficientemente intensivas para avanzar el el problema.
Una particularidad acá fue el cambio del problema, para adecuarlo a las necesidades percibidas
en la investigación Ciudad de Datos, según uno de los coinvestigadores.
Esto trajo la ventaja de triangular información: ya no estábamos más centrados en los temas de redes sociales,
sino que podíamos poner a circular en ellas información extraida de otros lados,
en este caso del portal de contratación pública, en aras de articularnos con la naciente comunidad
*Open Data Colombia* (OpenDataCo) y el *scrapper* de contratos del portal gubernamental colombiano
``contratos.gov.co`` (prizbilla-xxx).
Además nos alineaba con otras comunidades como [OpenBugets](http://openbudgets.eu/),
[OpenSpending](https://openspending.org/) y algunos proyectos y temáticas de la [Open Knowledge Foundation](https://discuss.okfn.org/).
También mostraba el potencial del trabajo desde individuos y pequeños colectivos: por ejemplo, el proyecto OpenSpending
mostraba como 76 países habían liberado 1105 datasets conteniendo 28'369.534 registros [@OpenSpending, index].
El scrapper de un sólo individuo, y la organización y limpieza posterior en la comunidad OpenDataCo y el Data Week 3ra edición,
logró liberar (XXX) registros para 15 años de contratación.
Sin embargo, tenía un riesgo, como se señaló antes de la ejecución del taller al coinvestigador,
y es que familiarizarse con los datos
y sus visualizaciones y lograr continuidad y resultados con el problema era algo difícil para un problema de una semana,
si nadie se iba a ocupar de dichos datos después.
Liberar los datos no bastaba, había que comprometerse con encontrar las estructuras e historias dentro de dichos datos y contarlas.
A esto se sumaron dificultades con la conexión entre Pharo y SQLite, el motor de datos para trabajar el dataset de contratos, que,
si bien fueron temporales debido a la transición a la siguiente versión de Pharo, en un evento intensivo como el Data Week, cobraron
su tiempo y causaron descontento entre los participantes, un par de ellos reportó que no concebián como una cosa que el los demás
lenguajes de programación está resuelta, en este termina siendo un impedimento tan grande para el tratamiento de datos.
Finalmente logramos rodear el problema, no sin una considerable pérdida de tiempo y fluidez
durante la realización del taller/hackatón.
Aún así los asistentes mantuvieron el interés y hubo 3 sesiones de un día, posteriores al evento,
para continuar con el problema y la solicitud de crear una lista de correo para los asistentes al Data Week.
Si bien dicha solicitud no fue implementada inmediatamente, e invité a la gente a la comunidad de OpenDataCo,
con el ánimo de dinamizarla, la implementé con el tiempo, al ver el interés sostenido de los participantes y la necesidad de tratar temas específicos a los interesados en Grafoscopio y los asistentes al Data Week.
Desde la edición 4 del data week se consolidó el esquema, de la anterior, de dividir el encuentro en dos sesiones.
Esta se realizó en el colaboratorio de Medellín (ver fotos), también en alianza con el proyecto Ciudad de Datos,
pero se volvió al problema de visibilizar la comunicación en Twitter, ya no desde los mapas del silencio,
sino desde un proyecto llamado \emph{data selfies}, que se basaba en la información
provista por cada usuario de Twitter, en lugar de la información desde el scrapper.
La edición 5 del Data Week se realizó de septiembre 22 al 24 y 29 de septiembre a octubre 1 de 2016.
En esta edición se continuó con el problema de los Data Selfies, pero hubo interesantes
exploraciones de teorías y proyectos relacionados con lo que se planteaba en el evento y
se mejoró la infraestructura que soportaba la interconexión con repositorios de documentación
en Fossil.
La edición 6 fue una edición "unipersonal" e hizo énfasis en la \emph{hackatón} como una
forma de resistencia y crítica civil a los proyectos de enagenación de lo público, particularmente
las bibliotecas, para la apropiación de los privados, particularmente Microsoft, sobre la base
de enseñar a todos a hacer código.
Esta perspectiva crítica intentaba ilustrar otras formas de empezar con la programación,
otras iniciativas y comunidades que se acercaban críticamente e ellas y por ello continuo
la numeración de ediciones que se llevaban hasta el momento, pues si bien la dinámica fue distinta,
se construía desde las mismas perspectivas.
El énfasis acá estuvo en mejorar la infraestructura, usando lo desarrollado en la edición
anterior.
\subsection{Los participantes y sus lecturas}\label{participantes}
\begin{figure}
\centering
\begin{subfigure}[a]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/indie-web-science.jpg}
\caption{Taller Indie Web Science}\label{fig:indie-web-science}
\end{subfigure}
\begin{subfigure}[b]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/dataweek-small-1.png}
\caption{Data Week 1, Bogotá}\label{fig:dataweek-1}
\end{subfigure}
\begin{subfigure}[c]{}
\includegraphics[width=\linewidth]{./graphics/Parte2/dataweek-small-2.png}
\caption{Data Week 4, Medellín}\label{fig:dataweek-4}
\end{subfigure}
\caption{3 Eventos relacionados con el Data Week:
[a] Talleres de \emph{Indie Web Science} en HackBo, Bogotá (marzo 2015).
[b] Data Week 1 en HackBo, Bogotá (junio 2015)
[c] Data Week 4 en el Colaboratorio, Medellín (julio 2016).}
\label{fig:infomed-visuals}
\end{figure}
%----------------------------------------------------------------------------------------
% ANEXOS
%----------------------------------------------------------------------------------------
\part{Anexos}
\label{part:bootstrapping}
\backmatter
%----------------------------------------------------------------------------------------
% BIBLIOGRAPHY
%----------------------------------------------------------------------------------------
\bibliography{bibliography} % Use the bibliography.bib file for the bibliography
\bibliographystyle{plainnat} % Use the plainnat style of referencing
%----------------------------------------------------------------------------------------
\printindex % Print the index at the very end of the document
\end{document}