Capítulo 7 Análisis de proyectos GOSH

7.1 Introducción al capítulo

Las preguntas de investigación 2 y 3 de esta tesis exploran cómo el hardware científico abierto contribuye a democratizar la producción de ciencia y tecnología en términos de participación en el proceso y producción de conocimiento y construcción de capacidades, en particular aquellas necesarias para la producción de conocimiento y tecnologías altamente contextualizados. Este capítulo contribuye a estos objetivos presentando los resultados de cuatro estudios de caso, correspondientes a proyectos que se desarrollan en el sur global y forman parte del movimiento por el hardware científico abierto (GOSH).

Los resultados que se presentan derivan del trabajo empírico realizado entre 2018-2020. De acuerdo al diseño de la investigación presentado en el capítulo metodológico, la unidad de análisis en este capítulo es el proyecto. Cada proyecto se categoriza de acuerdo a su contexto de implementación en dos bloques: académico o comunitario.

El capítulo está compuesto por los cuatro casos de estudio:

  1. Gorgas tracker (bloque académico)
  2. Open flexure (bloque académico)
  3. Vuela (bloque comunitario)
  4. Kossamtor (bloque comunitario)

Dentro de cada caso se presentan los resultados del análisis según las dimensiones definidas en la metodología; cada uno finaliza con una figura que sintetiza estos resultados por cada dimensión.

7.2 Proyecto Gorgas tracker

Bloque: Proyectos académicos

7.2.1 Introducción al caso

Gorgas tracker es un proyecto que tiene como objetivo explorar el rol de la movilidad humana en la transmisión de malaria. Nace en 2016 a partir de la iniciativa de Gabriel Carrasco-Escobar, investigador en epidemiología en el Instituto de Medicina Tropical de la Universidad Peruana Cayetano Heredia (UPCH) y fue co-dirigido con Pierre Padilla-Huamantico, investigador en ingeniería biomédica de la misma casa de estudios.

Carrasco-Escobar había leído un estudio realizado en África donde se utilizaban teléfonos celulares para evaluar cómo los patrones de movilidad de la población podían relacionarse con la transmisión de la enfermedad. Esta idea lo motivó a formular un proyecto con una lógica similar pero trabajando con poblaciones indígenas de la amazonia peruana. Sin embargo, rápidamente pudo comprobar que los métodos no eran replicables en la nueva zona de estudio: en la Amazonia no hay internet, red de telefonía ni ninguna de las otras herramientas que usaban los equipos africanos para evaluar la movilidad de la población. La opción disponible era utilizar localizadores GPS, importados a un costo aproximado de 100 USD cada uno.

El proyecto se presentó a un concurso de la UPCH, que lo aceptó y otorgó un subsidio por 10 mil dólares como “fondo semilla”. Con un presupuesto reducido y buscando el mayor impacto posible, en 2017 Carrasco-Escobar invita a Padilla-Huamantico a desarrollar un dispositivo abierto específico para el proyecto, que cumpliera con los requerimientos de la investigación. Hasta ese momento Padilla-Huamantico trabajaba en UPCH desarrollando tecnologías abiertas para salud pública, habiendo participado del encuentro GOSH en Chile y formando parte de otras redes donde se trabajan tecnologías abiertas, como el MIT Bio Summit.

El equipo de trabajo interdisciplinario se constituyó con Carrasco-Escobar liderando la investigación desde el punto de vista epidemiológico, Padilla-Huamantinco a cargo del desarrollo técnico del dispositivo, la colaboración de investigadores asistentes como el Ing. Edgar Manrique Valverde y el trabajo de estudiantes para llevar adelante la fase a campo.

En 2018 el equipo realizó la prueba piloto de funcionamiento de los dispositivos. En un período de casi dos meses se hizo el seguimiento de 50 miembros de distintas comunidades originarias en la región de Loreto. El área de estudio abarca seis comunidades en dos cuencas hidrográficas: el río Mazán (comunidades de Gamitanacocha, Libertad y Primero de Enero) y el río Napo (comunidades de Salvador, Lago Yurac Yacu y Urco Miraño). En el último estudio publicado se analizaron datos de 20 personas, representando el 40% de la población de la comunidad de Gamitanacocha.

Gorgas tracker: participantes utilizando el dispositivo (fuente: proyecto Gorgas Tracker)

Los resultados del piloto y el desarrollo del prototipo, publicados en revistas internacionales, muestran que la movilidad de las personas tiene efectos significativos sobre la transmisión de malaria, y que el desarrollo del dispositivo resultó útil para poder hacer el estudio en la zona. Además, sugieren que las estrategias de control implementadas por Salud Pública en la región presentan limitaciones.

A partir del proyecto el equipo entró en contacto con funcionarios involucrados con el Plan Malaria Cero del Ministerio de Salud, y logró incorporar la movilidad humana como uno de los factores relevantes para la política de control de la malaria en Perú. A partir de estos resultados, en 2019 se crea el “Laboratorio de Innovación en Salud” en la UPCH, co-dirigido por Carrasco-Escobar y Padilla-Huamantinco.

7.2.2 Producción propia

Gorgas desarrolla tres estrategias principales de trabajo: metodologías iterativas y colaborativas, diseño basado en la usuaria y diálogo interdisciplinario con división de tareas. Esto le permite producir artefactos que responden a la necesidad de los investigadores, son localmente reparables y modificables, y toleran las condiciones de uso impuestas por el contexto.

7.2.2.1 Trabajo iterativo y colaborativo

Gorgas implementa una forma de trabajo que internaliza el proceso de fabricación de equipos en el Laboratorio de Biodiseño de la UPCH, con los investigadores en el rol de usuarias/desarrolladoras, y los agentes de promoción en salud y miembros de la comunidad indígena como usuarias finales (y sujetos del estudio). Las interacciones entre estos tres grupos se dieron en dos etapas: primero los investigadores tomaron el rol de usuarias frente a los desarrolladores del Laboratorio de Biodiseño a cargo de Padilla-Huamantinco; una vez superada esta etapa se realizaron pruebas directamente con la comunidad.

La iteración en dos grandes etapas permitió diseñar un dispositivo que respondiera a las necesidades del estudio en primer lugar, y luego que pudiera ser adoptado por los sujetos del estudio, considerando que iban a tener que encontrarlo cómodo y poco disruptivo de sus tareas diarias para alcanzar un alto porcentaje de uso. En ambas etapas la metodología de trabajo es iterativa, a prueba de conceptos y error, en ciclos. Las herramientas de prototipado rápido permitieron contar con versiones mejoradas incrementalmente, producidas en ciclos cortos y probadas frecuentemente con las diferentes usuarias en cada paso. Una vez definida la versión final, el equipo ensambló y soldó 70 dispositivos de los que se utilizaron finalmente 50. En una entrevista realizada en 2020 con Carrasco, el investigador recuerda el proceso de prueba que lo tuvo del lado de la usuaria:

a nosotros nos dieron tres dispositivos para que juguemos […] les dije a mis estudiantes “traten de romperlo, de apretar todos los botones, de someterlo a un estrés suficiente como para que no funcione” […] y estaba bien en ese momento porque si eso pasaba a campo, iba a ser un desastre.

La decisión de construir equipos propios se tomó en base a la experiencia previa que el grupo de Padilla-Humantinco tenía trabajando con gestantes rurales y dispositivos de comunicación. Este trabajo se basaba en rePhone16, una plataforma de telefonía de código abierto desarrollada por la compañía china SeeedStudio. RePhone es un “teléfono do-it-yourself” diseñado de forma modular que permite la personalización total del dispositivo, agregando o quitando los módulos bluetooth, GPS, pantallas, o audio. La propuesta original incluye el armado de una caja en cartón para contener los módulos. En una entrevista en 2020, Padilla-Huamantinco comenta qué criterios utilizaron para decidirse por el rePhone:

primero evaluamos qué opciones teníamos que pudieran ser programables, que pudieran tener estas capacidades GPS y que sean pequeñas y portables […] encontramos el rephone, una plataforma que había sido lanzada por Kickstarter y que logró ser financiada, y que Seeed Studio lanzó como producto en su tienda

El proceso de ideación de Gorgas a partir de la adaptación del rePhone incluyó el desarrollo de mejoras tanto en términos de funcionalidades como de usabilidad. El primer trabajo consistió en entender qué módulos del rePhone eran útiles a los objetivos del estudio, qué funcionalidades extra se podrían necesitar, y cómo diseñar una carcasa que tolerara altas condiciones de temperatura y humedad sin ser totalmente hermética, para poder captar la señal GPS.

El desafío de la carcasa implicó sucesivas iteraciones. Fabricada en impresión 3D, uno de los primeros diseños consistió en una caja conteniendo los componentes que podía colocarse en el cinturón. El testeo con los vecinos hizo descartar esta idea, ya que el dispositivo resultaba demasiado grande y que no les gustaba usarlo así: los hombres comenzaron a usarlo en sus bolsillos, las mujeres lo ponían en sus carteras. Esto disparó nuevas pruebas, ya que este nuevo uso impedía la captación de la señal GPS; luego de sucesivas iteraciones el equipo acondicionó la caja agregando silicona para poder cubrir huecos y hacerla lo más resistente al agua posible, e incorporó una antena de mayor recepción. Esto solucionó el problema de recepción pero no el tema del tamaño, que era una de las principales quejas de los pobladores y constituye una de las próximas mejoras a implementar en la próxima iteración.

Una de las mejoras clave en el diseño para poder responder al uso de los investigadores es la optimización del uso de energía. Uno de los problemas con el rePhone es que la batería con la que viene por defecto es insuficiente para el estudio, que demandaba que el dispositivo estuviera sin cargar por una semana. A partir de examinar el hardware y el software del rePhone, el equipo identificó una modalidad de uso del hardware que permite optimizar el uso de la batería, logrando que dure los siete días requeridos por el estudio. Una entrevista en 2020 con Manrique expone por qué la necesidad de la batería larga duración:

teníamos la limitación técnica de que la batería dure por lo menos una semana […] muchas personas viajan y pues durante el viaje no van a tener un lugar donde cargar el GPS; necesitábamos que la batería dure lo suficiente como para que viajen y regresen de su viaje.

Otra de las demandas del proyecto de investigación era que el artefacto pudiera detectar cuándo una persona salía de un área de interés, una funcionalidad que excede la de un GPS convencional. Para ello el equipo desarrolló software capaz de definir el área de interés y almacenar cuándo sucedían estos eventos de salida. Para facilitar la tarea del personal a campo, se creó una interfaz gráfica para ser utilizada cuando se conecta el dispositivo a una tablet o computadora con cable USB. A través de ella se podían descargar los datos recolectados, visualizarlos y también modificar los parámetros, por ejemplo de ahorro de energía. El personal de campo de la investigación tenía nivel de educación superior y sabía utilizar computadoras. Sin embargo, este no era el caso de todos los trabajadores del sistema de salud. El desarrollo de una botonera que permitiera contar con una interfaz física fue una de las estrategias para mejorar la usabilidad de Gorgas. Carrasco-Escobar comenta sobre una de las innovaciones más importantes de Gorgas, una función “reportero” que generaba una señal luminosa para indicar distintos resultados según un código de colores, en lugar de solo poder verlo vía software:

el ministerio de salud emplea agentes comunitarios en salud […] son personas locales de las mismas comunidades que muy probablemente no sepan lo que es la computadora […] el sistema binario nos parecía esencial para poder comunicarnos con ellos

7.2.2.2 Diseño basado en la usuaria

Uno de los objetivos principales del proyecto fue garantizar la adopción por parte de las usuarias finales, lo que justifica la aproximación de diseño basado en la usuaria. Los agentes promotores de salud otorgaban los dispositivos a los vecinos de la comunidad, que los utilizaban durante una semana y luego los intercambiaban por dispositivos cargados en el puesto de salud. En estas visitas, dependiendo de los resultados del geolocalizador, se realizaba una extracción de sangre y diagnóstico de malaria al participante. Al menos un trabajador de campo siempre estaba en la comunidad, durante todo el tiempo del estudio, incentivando el uso del dispositivo entre los vecinos. Manrique explica cómo era el procedimiento del estudio:

en la primera visita se les entrega al GPS y para la siguiente visita a los 7 días de nuevo se les hacía un diagnóstico, una encuesta y se recogía el GPS […] esos GPS los llevamos a nuestro punto de acopio en esa misma comunidad, descargamos la información, los cargamos y se los volvíamos a entregar ese mismo día

La primera fase de testeo del dispositivo se hizo en el campus de la UPCH, con el equipo de investigación en el rol de usuaria. Una vez superada esta etapa se pasó a la fase de testeo a campo, con varios encuentros tanto con los promotores de salud como con los vecinos, futuras usuarias. Más allá de las visitas casa por casa, las reuniones también se hacían con toda la comunidad en el colegio o en un local de usos generales. Manrique, a cargo de la implementación a campo, comenta cómo se gestionó el acceso a la comunidad:

contactamos al jefe de la comunidad donde hicimos el estudio que es como el alcalde o gobernador de la comunidad […] le comentamos acerca del proyecto, le dimos un dispositivo, para que lo pueda entender, sentir que era lo que estaba pasando

Esos intercambios permitieron al equipo entender de primera mano algunas cuestiones que podían llevar a los participantes a no usar el dispositivo. La mayoría de los pobladores se dedican a la pesca, a la agricultura o a la caza. Si el diseño resultaba incómodo para usar durante la jornada de trabajo, se podía golpear, los cables podían desconectarse o romperse. Padilla-Huamantinco comenta cómo rápidamente surgieron diferencias entre las propuestas del equipo investigador y los vecinos de la comunidad en torno al diseño:

Nosotros lo habíamos hecho rojo [al dispositivo] porque si se caía en la selva, se perdía, era fácilmente distinguible […] pero para ellos era no tan bueno, porque todo el mundo se iba a dar cuenta que estaban utilizando un GPS

Las mujeres de la comunidad jugaron un rol decisivo en el diseño del dispositivo, principalmente dando consejos sobre cómo cuidar el artefacto. Para evitar que el resultado del reportero influyera en los vecinos y sus patrones de movimiento (según el resultado se les extraía sangre o no), el equipo había agregado un botón para obtener el resultado sólo cuando el promotor de salud quisiera. Los niños de la comunidad encontraron el botón y comenzaron a desarmarlo por pura curiosidad, situación que las mujeres detectaron rápidamente. Manrique comenta cómo esta situación llevó a un rediseño para ocultar el funcionamiento a la usuaria final:

el dispositivo tenía un botón que prende una luz para saber si es que las personas han salido o no de la comunidad […] Inicialmente ese botón era de fácil acceso, y varias personas bastante curiosas se ponían a presionarlo a cada rato […] finalmente decidimos que el botón tenía que estar relativamente escondido para que no pudieran de casualidad dañar el equipo.

Las contribuciones de los participantes no fueron sólo en términos de respuesta o sugerencia al equipo de investigación, también adaptaron el diseño activamente para poder utilizarlo mejor. En uno de los casos, dos vecinos de la comunidad se vieron en la situación de que la banda elástica que sostenía el dispositivo se dañó. Para repararla, la cosieron ellos mismos, pero además la alargaron y comenzaron a usar el dispositivo en forma de bandolera, sobre el hombro. Los vecinos también sugirieron colocar los dispositivos en los botes que utilizan normalmente como medio de transporte. Esta sugerencia está siendo evaluada, ya que sería una forma de evaluar la conectividad entre comunidades que el equipo investigador no había considerado y que puede brindar perspectivas interesantes. Carrasco-Escobar comenta sobre el peso en el proyecto de estas devoluciones por parte de la comunidad:

Diría que las iteraciones más sutiles fueron las que obtuvimos de campo, pero fueron las que tuvieron mayor impacto en el resultado final

Gorgas tracker: vista del interior del dispositivo (fuente: proyecto Gorgas Tracker)

7.2.2.3 Usuarias-sujetos y usuarias-desarrolladoras

La posibilidad de fabricar un dispositivo dentro de la universidad reconfiguró las posibilidades del equipo de investigación habilitando nuevos usos en comparación con la versión estándar disponible en el mercado. Otros grupos de usuarias, como los promotores de salud y la comunidad indígena adquirieron nuevas posibilidades de uso con algunos rediseños como la interfaz física, pero vieron limitados algunos otros por ejemplo a través del ocultamiento del botón. Esto en parte se relaciona a las características de esta investigación en particular: las usuarias finales son sujetos del estudio.

El hecho de diseñar un dispositivo propio permitió realizar pruebas con las usuarias, en particular con los vecinos de las comunidades. Las mujeres de la comunidad tomaron un rol clave en poder diseñar un dispositivo que pudiera ser utilizado de manera eficaz por parte de todos los vecinos. Sin embargo, el nivel de participación de las comunidades en el estudio fue limitado. Carrasco comenta las observaciones que las mujeres de la comunidad hacían sobre el diseño:

notamos que las mujeres nos daban más consejos sobre sobre cómo tener cuidado con el dispositivo y es porque ellas pasan más tiempo con los niños, entonces sabían a todos los peligros que están expuestos los dispositivos y eso fue bastante útil para nosotros

Carrasco-Escobar menciona también como en las próximas etapas uno de los objetivos es incorporar más requerimientos hechos por la comunidad, como ser la reducción del tamaño del dispositivo, o el agregado de funcionalidades:

[los pobladores] en casi todas sus actividades diarias utilizan una radio, porque además de escuchar música y entretenerse es el único medio de comunicación que les llega […] hoy Gorgas le sirve a los investigadores y al sistema de salud […] creo que sí hacemos el switch* a combinar el dispositivo con una radio finalmente les va a ser útil a ellos también.

Las estrategias implementadas para incrementar la participación de los pobladores incluyeron la organización de talleres al inicio del proyecto para explicar cómo se iban a realizar las tareas e intentar un alto grado de adhesión. También se hizo un taller de cierre con la comunidad donde se comunicaron los resultados de forma accesible, seguido de una conversación abierta.

Un punto a señalar es la significativa ausencia o minoría de mujeres en el grupo investigador. El actual Laboratorio de Innovación en Salud cuenta con un 20% de investigadoras mujeres según su página web17, sin embargo no fueron mencionadas como parte del equipo en las entrevistas. En cuanto a la colaboración online, la estrategia del equipo es detectar potenciales colaboradores ya sea en eventos académicos o a través de redes como GOSH, e invitarlos al grupo de Slack del laboratorio.

La documentación del proyecto fue publicada en GitHub18 en idioma inglés, una vez que se llegó a la versión final del dispositivo, pero no se obtuvieron colaboraciones significativas por esa vía hasta el momento. La difusión del proyecto también se realiza vía redes sociales y en una página web dedicada al LIS.

7.2.2.4 Dialogando entre disciplinas

Una de las características generales de los proyectos de hardware abierto es que demandan una combinación de habilidades y conocimientos para poder desarrollarse. En el caso de Gorgas esto incluye el diseño y fabricación digital de la carcasa, la electrónica, la usabilidad, la programación del dispositivo, el análisis georreferenciado de los datos y los conocimientos de epidemiología para poder definir y estructurar los datos necesarios. Otras habilidades quizás no tan evidentes pero también clave son, por ejemplo, dominar el idioma inglés, saber construir buena documentación y conocer los procesos de importación de los componentes electrónicos.

La gestión del proyecto, iterativo y colaborativo, también demanda un know-how particular. Padilla-Huamantinco señala cómo basa su trabajo en conceptos de design thinking y diseño determinístico, donde el desarrollo de la solución se planifica y los aprendizajes se sistematizan. El manejo de herramientas digitales para gestionar este tipo de desarrollos también es una habilidad valiosa, por ejemplo en términos de plataformas con control de versiones. En este sentido el Laboratorio de Innovación en Salud planifica talleres para capacitar a sus estudiantes no sólo en las técnicas específicas, si no también en la gestión efectiva de los proyectos de innovación. Padilla-Huamantinco menciona los meta aprendizajes sobre el desarrollo de soluciones:

esta metodología de design thinking**, donde hay un proceso más sistematizado y ordenado de lo que es el desarrollo de una solución […] sumado a lo que es propiamente el framework que permiten plataformas de documentación como GitHub para comunicación y administración de proyectos […] estoy tratando de promoverlo en los cursos en los cuales he estado involucrado

En el caso particular de Gorgas, estos conocimientos necesarios se ensamblan de acuerdo a los distintos perfiles disponibles en el grupo. Carrasco-Escobar y Padilla-Huamantinco, como personas de más experiencia en el proyecto, organizan el trabajo y asignan responsabilidades, de acuerdo al expertise y tiempo disponible en los colaboradores. Manrique hace referencia al sistema de división de tareas que se utilizó en Gorgas:

[los coordinadores] designan y dicen bueno, como tú ya tienes experiencia en estas cosas, encargate de ver la parte de logística de la implementación del trabajo de campo […] o coordina el diseño del dispositivo GPS con Pierre [Padilla-Huamantinco], luego ya Gabriel se encarga de revisar que los diferentes componentes del proyecto sean consistentes entre sí para cumplir con los requerimientos del análisis final

Existen además reuniones de grupo donde se incentiva a los estudiantes o colaboradores más jóvenes a que expresen sus ideas, por ejemplo en instancias de brainstorming. Manrique, sobre su experiencia trabajando en el Laboratorio de Innovación en Salud:

siempre he tenido algo que hacer ya sea en Gorgas o en otros proyectos del LIS, y siempre son cosas distintas […] es divertido, nunca nos quedamos estancados

El trabajo codo a codo con colaboradores que provienen de disciplinas completamente diferentes puede resultar difícil. Una de las ideas que Carrasco-Escobar menciona más frecuentemente es cómo Gorgas lo forzó a encontrar un “lenguaje común” con su equipo. Y que esto es un proceso que lleva tiempo, actitud receptiva y sensación de pertenencia:

decidimos un par de veces ir a comer o ir a tomarnos una cerveza porque finalmente ahí vas un poco limando asperezas y entiendes, que ese robot que son los ingenieros y que crees que hablan otro idioma, pueden tomar una cerveza y hablar lo mismo que tú […] Y en el otro sentido también

La identificación con el espíritu de la “innovación”, con trabajar de forma iterativa, de tomar riesgos y de la formación autodidacta, es relevante en todo el grupo del Laboratorio de Innovación en Salud, pero en particular en los coordinadores. Es una identificación además con algunas de las redes con las que están en contacto, como el MIT Biosummit o la competencia iGEM. Esta misma idea es la que el Laboratorio de Innovación en Salud pretende incentivar dentro de la universidad, a través de cursos con estudiantes de ambas carreras. Carrasco-Escobar menciona que trabajar con estudiantes le resulta mucho más sencillo que con profesionales con años de experiencia:

¿Quieres hacer innovación? Pues tienes que aprender que tienes que hablar múltiples idiomas, y bueno sobrevive. Hasta ahora tenemos una tasa de supervivencia del 100% […] las personas que ya están muy avanzadas en su carrera lo viven como una ruptura en la comunicación […] los estudiantes en cambio son muy plásticos para lidiar con esto

El diálogo interdisciplinario no sólo se da en el laboratorio, sino también online aunque en una medida mucho menor. A través de GOSH, Gorgas se contactó con el proyecto de microscopía abierta Open Flexure, diseñado en Inglaterra y fabricado en Tanzania. Uno de los spin-off de Open Flexure es la construcción de algoritmos de detección automática de malaria, basados en el análisis de enormes cantidades de muestras con el microscopio. Para el equipo del Laboratorio en Innovación en Salud este es un proyecto sumamente atractivo. Por un lado, los parásitos que se observan en Perú son morfológicamente distintos a los que se ven en África. Por otro lado, pertenecer al Instituto de Medicina Tropical facilita el acceso a muestras y a pacientes de forma continua, tarea que resulta mucho más complicada en Tanzania. Ambos equipos trabajan actualmente en el desarrollo de la arquitectura del repositorio de imágenes, para que sea abierta y pueda servir para entrenar los modelos de detección de diferentes parásitos de malaria, en distintos lugares del mundo. Esta automatización reduciría los tiempos de diagnóstico, disminuyendo los costos y facilitando el trabajo en zonas escasas de personal calificado. Ya se imprimieron tres microscopios en el LIS que se están probando en el diagnóstico de Malaria, y Carrasco-Escobar realizó una visita a la Universidad de Bath, donde se encontró con el equipo de Richard Bowman para intercambiar experiencias:

lo que nosotros estamos dando desde el lado Perú es que queremos armar una arquitectura para repositorio de imágenes que sirva porque sea abierta y que finalmente sirva para entrenamiento de visión computacional de machine learning para detectar parásitos de malaria

Gorgas tracker: visualización de datos obtenidos y mapa de calor de tránsito (Carrasco-Escobar et al. 2020)

7.2.3 El eje en el impacto por fuera de la academia

Uno de los conceptos claves para entender Gorgas es la ambición de producir conocimiento que tenga un impacto directo en la realidad local. Más allá de cuantificar y describir patrones de movilidad, uno de los principales objetivos de Carrasco-Escobar es generar información útil para la planificación de intervenciones y desarrollo de políticas en salud. En el caso de Gorgas producir esa información útil demanda cumplir con condiciones muy exigentes: contar con artefactos que sean aceptados por las comunidades indígenas, que toleren las condiciones de humedad y temperatura de la selva, que puedan repararse y adaptarse fácilmente. Carrasco-Escobar comenta al respecto en términos de su experiencia como epidemiólogo:

[los investigadores] en general nos dedicamos básicamente a describir cuáles son los estados de salud en poblaciones, qué cosa está relacionada con otra cosa y luego viene un gran párrafo de “se sugiere para, y los siguientes pasos son estos” […] pero todo queda en papel

La primera disrupción que plantea Gorgas en el contexto de la academia es desafiar la norma de lo que se acepta como proyecto de investigación y lo que no. Hasta este proyecto, los estudios de movilización se realizaban ya sea realizando encuestas a los pobladores, utilizando redes de internet o telefonía celular, o GPS comerciales. Trabajos de campo anteriores mostraron como las encuestas resultaban poco confiables; los GPS comerciales resultan económicamente inaccesibles para estudios con un gran número de participantes. La decisión de fabricar un dispositivo propio dentro de la universidad implicó desafiar el concepto tradicional de proyecto de investigación dentro de la academia. En lugar de los típicos proyectos de investigación donde se sabe qué va a suceder en cada etapa, Gorgas se propone como proyecto de innovación, de mayor riesgo. Carrasco-Escobar comenta sobre sus aprendizajes al respecto: “hay dos cosas que he aprendido en este proceso: uno lo complicado de vender una idea nueva en un entorno clásico, y dos, que creo que la universidad la cual estamos tiene un entorno muy clásico, muy tradicional”.

Por otro lado, el proyecto propone estudiar un tema novedoso, que prácticamente no podía ser abordado con los aparatos disponibles, en un contexto de recursos escasos y a una escala no suficientemente interesante para las empresas desarrolladoras de tecnología. Desde el inicio hasta la formación del Laboratorio de Innovación en Salud, todas las actividades del proyecto están marcadas por la toma de decisiones diferentes a lo esperado en el contexto, pero que terminan funcionando. Aunque la malaria es un problema en Perú, otros países en África presentan números mucho mayores que atraen fondos para la investigación. Carrasco-Escobar comenta cómo esta situación sumado a otras condiciones no eran favorables para que el proyecto sea financiado:

era el combo perfecto como para archivar el proyecto […] una persona que recién está empezando su carrera, un tema relativamente complicado de hacer, un país donde no es tan atractivo hacerlo

En la decisión de producir un prototipo propio, la apuesta es en términos de carrera académica. Tras varios intentos infructuosos de buscar apoyo a su proyecto en UPCH, un voto de confianza de su mentor en el Instituto de Medicina Tropical le permitió postular y obtener un fondo de la UPCH para proyectos menores, de estudiantes. Enfrentado a la negociación entre recursos disponibles y el impacto deseado, Carrasco-Escobar decide asociarse con Padilla-Huamantinco quien comenta cómo participar en Gorgas fue para él una apuesta personal:

en mi caso en realidad sí fue más una apuesta personal y una participación en el hecho de que se pudiera desarrollar y publicar los resultados

Arriesgando los pocos fondos disponibles, destinan la partida originalmente estipulada para la compra e importación de equipos a financiar el tiempo de estudiantes fabricar equipamiento. Este mero desvío de fondos les genera un problema burocrático considerable con las autoridades de la universidad. El proceso de prototipado no estuvo exento de contratiempos, marcado por la falla de componentes, los problemas para la importación de materiales y las exigencias de diseño impuestas por un estudio a realizarse en la selva amazónica.

Tanto Carrasco-Escobar como Padilla-Huamantinco son investigadores jóvenes, que se encontraban cursando estudios de maestría y doctorado al inicio del proyecto. La mayoría de su equipo está compuesto por investigadores más jóvenes que ellos y estudiantes. Carrasco-Escobar comenta cómo los mecanismos académicos terminan imponiendo ciertas formas de trabajo sobre otras:

[la investigación tradicional] es un círculo muy cerrado, que no te permite flexibilidad para incluir o no incluir cosas nuevas […] depende estrictamente de lo que querías responder en un inicio […] en procesos de innovación el riesgo de fracaso es alto pero basta que un intento sea exitoso para que el beneficio sea muchísimo más grande

Las decisiones riesgosas y el eje en el impacto resultaron fructíferos en términos tanto convencionales (publicación, influencia en políticas) como de cambio hacia dentro de las instituciones. La creación del Laboratorio de Innovación en Salud a cargo de Carrasco-Escobar y Padilla-Huamantinco es, de alguna manera, un reconocimiento al valor de esta nueva forma, más flexible, de producir conocimiento desde la academia.

7.2.4 El diálogo en la construcción del problema

A lo largo de las distintas entrevistas, una de las capacidades que nombraron todos los participantes y que apareció en reiteradas oportunidades es la capacidad de producir conocimiento científico que genere impacto a nivel local, por fuera de la academia. Asociada a esta capacidad, inmediatamente aparece la idea de desarrollar herramientas útiles en el contexto local. Para Carrasco-Escobar la cuestión de poder producir impacto está relacionada a la asimétrica producción de conocimiento a nivel global, que deriva en la generación de soluciones que se exportan sin ser aplicables a todos los contextos.

El desarrollo de la herramienta dentro del contexto de la universidad permitió al equipo entrar en contacto no sólo con el trabajo de control de Malaria que desarrolla el Ministerio de Salud en Perú, sino (más importante) con el grupo que participa en el desarrollo del Plan Malaria Cero. Las necesidades de la política pública están presentes desde un inicio en Gorgas, pero la diferencia la hace el diálogo con un mentor en contacto directo con la política pública por fuera del ámbito académico. Padilla-Huamantinco menciona la conexión entre Gorgas y el Plan Malaria Cero:

en el país tenemos un programa que se llama el malaria cero, que justamente busca la eliminación de la malaria en los próximos años en etapas […] una de las personas que estuvo liderando este programa, no sé si aún continúa, fue el doctor Alejandro Llanos, quien también ha sido parte del equipo de Gorgas

Siguiendo en términos de impacto, el desarrollar un artefacto en interacción con la comunidad le permitió al equipo detectar toda una serie de mejoras posibles en el flujo de trabajo de los promotores de salud. Una de las posibilidades, por ejemplo, es la digitalización de los datos recolectados por los agentes de salud, que actualmente registran en papel. Otro ejemplo mencionado es incluir Gorgas dentro del flujo de trabajo de la red de salud, a fin de poder medir y mejorar ellos mismos lo que está sucediendo en el campo. Para poder contribuir de alguna manera a que estos cambios sucedan, una de las capacidades subyacentes es la de poder influir en la política pública. Padilla-Huamantinco menciona la colaboración y habilitar a otros a producir conocimiento como uno de los ejes de Gorgas:

desarrollar algo que pueda sumar fuerzas para eliminar esta enfermedad […] Pero también desarrollar una herramienta que pueda ser utilizada por otra persona para hacer estudios, generar evidencia y ayudar en la toma de decisiones

7.2.5 Construcción de capacidades

7.2.5.1 Capacidades alcanzadas

En este sentido la capacidad más esperada y valorada en el proyecto era la de poder contar con herramientas altamente personalizadas que reflejen las necesidades de la investigación y permitan incorporar los puntos de vista de los pobladores, a fin de lograr una alta adherencia al estudio. Según Carrasco-Escobar, esta oportunidad que brinda el desarrollo abierto de explorar y modificar las herramientas a medida que avanza el trabajo es una situación ideal para los investigadores, “es como darle un caramelo a un niño”.

La capacidad de diseñar el dispositivo y ajustarlo completamente a las necesidades locales es quizás el logro más significativo de Gorgas. Este es el proceso más mencionado por todos los participantes, en particular aquellos que no contaban con una formación en diseño o ingeniería, para los que Gorgas fue su primer contacto con el concepto de herramientas abiertas para la ciencia. Manrique resalta por qué esto es importante para él:

en cuanto al valor de este tipo de herramientas, es que te permite customizar el dispositivo para las necesidades que uno requiere […] no es lo mismo aplicar no sé este tipo de herramientas en África, en un contexto más urbano como Europa, o como nosotros en la amazonía peruana […] cada uno va a tener un diseño distinto para hacerlo de la manera más óptima y obtener la información que se necesita para lograr los objetivos que se plantea el proyecto

El dispositivo producido por el equipo expande las funcionalidades de un GPS comercial: optimiza el uso de energía de uno a seis días, incorpora una interfaz o botonera física para mejorar la experiencia de usuarias no expertas, habilita la definición de un “área de estudio” generando alertas cuando se traspasa la zona, y permite visualizar el estado del dispositivo y los datos recolectados mediante una interfaz gráfica, si se lo conecta vía USB a una tablet o computadora.

Gorgas habilitó además la capacidad de incorporar a la investigación los intereses y preferencias de las comunidades en estudio. De acuerdo a cómo los participantes utilizaban el artefacto, el equipo pudo ir modificando sus características para ajustarlo lo más posible a sus preferencias. El dispositivo puede adaptarse en términos de colores, tamaños y funcionalidades según los requerimientos de las comunidades que los utilizarán. Carrasco-Escobar rescata cómo la apertura facilitó esta flexibilidad:

esa capacidad y flexibilidad fue algo que no hubiéramos podido obtener si hubiéramos comprado un equipo comercial […] muchas veces cuando tratamos de buscar soluciones, estamos limitados a la oferta que hay en el mercado […] un mercado que no está pensado para nuestros países

La capacidad de construir herramientas propias implica el desarrollo de habilidades tanto técnicas como de gestión. Por lo general, los investigadores tradicionalmente no cuentan con entrenamiento en fabricación digital o prototipado rápido. Pero el aprendizaje más significativo pareciera estar relacionado a la metodología iterativa y colaborativa de trabajo que viene aparejada a la fabricación de instrumentos abiertos. Padilla-Huamantinco comenta cómo el haber participado de la construcción del equipo, de alguna forma convirtió al grupo en una referencia para las usuarias de rePhone y plataformas similares:

Ya sabemos qué cosas puedes hacer y qué no con el rePhone […] nosotros podemos decir si sirve o no para determinada aplicación

Una de las capacidades no mencionadas pero claramente adquiridas en el proceso fue la de reparar los propios equipos. Entrenar a los coordinadores del trabajo a campo en reparación fue clave para poder solucionar problemas que surgían en el momento, frecuentes dada la alta tasa de fallos de algunos componentes importados. Además, por su diseño modular los dispositivos Gorgas pueden ser reutilizados para otros fines una vez que el estudio se da por finalizado. Padilla-Huamantinco rescata cómo la reparación es también importante en términos de generación de residuos electrónicos:

se pueden desarmar y utilizar para otros propósitos, reprogramar […] No es que se usen una sola vez y se dejen de lado, o se botan a la basura

Los resultados obtenidos en el estudio sugieren un rol importante de la movilización humana en la transmisión de Malaria, y por lo tanto que las actuales estrategias de control que desarrolla el Ministerio de Salud son subóptimas. Por otro lado, el taller de cierre con la comunidad brindó información útil respecto de la percepción que las comunidades tienen sobre estas medidas, que pueden utilizarse en el diseño de mejores programas de concientización.

La capacidad de influir en las políticas públicas, mencionada por todos los entrevistados, se logró en las etapas finales del proyecto. Por el lado académico, en base a los resultados de Gorgas uno de los proyectos del grupo de malaria dentro del Instituto de Medicina Tropical incorporó la dimensión de la movilidad humana dentro de la evaluación del impacto de la enfermedad. En cuanto al Ministerio de Salud, a partir de los resultados de Gorgas y la discusión generada en el Instituto de Medicina Tropical hubieron intercambios con los integrantes del Plan Malaria Cero. Finalmente la comisión que elabora el Plan incorporó la movilidad humana como uno de sus ejes, por su rol como facilitador de la importación de casos de malaria.

El poder intercambiar información y colaborar con otros equipos de investigación en el sur global fue mencionado como una capacidad deseada. Carrasco-Escobar menciona cómo las situaciones en estos países son generalmente mucho más similares entre ellas que cuando se las compara con Estados Unidos o Europa, quienes producen las herramientas. Padilla-Huamantinco relata cómo, cuando revisaron la documentación de Open Flexure -que además tradujeron al español-, ésta mencionaba que se podía utilizar la parte óptica de un microscopio que ya no funciona para construir el nuevo instrumento. Pero el equipo peruano nunca pudo encontrar un microscopio que no funcionara en la UPCH, donde muchas veces los materiales en uso son de segunda mano y si un equipo definitivamente no funciona sus partes son reutilizadas, como práctica normal:

nunca encontramos algo así […] aquí si al menos uno de los lentes se puede utilizar entonces tú ya lo usas […] no es como en Europa o USA donde cada cierto tiempo la gente cambia los equipos

El esquema de colaboración online a través de plataformas como GitHub no fue lo que funcionó (aún) para Gorgas. En cambio el encuentro a través de GOSH si resultó en colaboraciones que enriquecen el trabajo del equipo, como la del grupo Open Flexure en Inglaterra/Tanzania. La colaboración con el Ifakara Health Institute en Tanzania permite expandir los horizontes del proyecto original. El rol de las herramientas abiertas en este sentido garantiza la interoperabilidad y reduce la fricción a la hora de compartir datos.

La capacidad de trabajar de modo interdisciplinario es una de las más significativas en el proyecto. El éxito del equipo derivó en la creación del Laboratorio de Innovación en Salud, donde las metodologías de trabajo interdisciplinarias, abiertas y colaborativas constituyen la filosofía de trabajo que se transmite a los estudiantes. Manrique comenta sobre la ventaja de la interdisciplinariedad:

En nuestro caso teníamos al grupo de Pierre [Padilla-Huamantinco] que se encargaba más de Hardware, Gabriel [Carrasco-Escobar] como epidemiología, yo como ingeniero ambiental, tenemos otro chico que es administrador en salud pública […] cada uno aportaba distintas cosas para poder tener un diseño más amplio y más flexible para nuestro caso

Participar del desarrollo de Gorgas permitió a los distintos investigadores pensar nuevas ideas y aplicaciones de las tecnologías abiertas. No sólo en el caso de los coordinadores, sino también los estudiantes e investigadores asistentes. Manrique Valverde tiene interés en estudiar vectores de la enfermedad, y está ideando un proyecto que combina Gorgas con herramientas de diagnóstico molecular, que permita capturar y comparar mosquitos en zonas de transmisión y en las comunidades. José Saldaña, estudiante de pregrado, tomó el diseño de Gorgas y lo extendió para incluir sensores de temperatura y humedad. Carrasco-Escobar y Padilla-Huamantinco están evaluando una segunda etapa de Gorgas con 300 participantes y seguimiento de 50 embarcaciones. El proyecto además abrió la puerta a pensar plataformas de recolección de datos ambientales en las ciudades, para contribuir a generar políticas basadas en evidencia.

7.2.5.2 Capacidades ausentes y otros limitantes

En general, las principales capacidades esperadas por el equipo se vieron cumplidas por el proyecto. Existen factores estructurales que limitan algunos de los cambios que imaginan los investigadores, y que dependen de la generación de capacidades colectivas. En este sentido, el cambio en las prácticas de los trabajadores de salud, el pasar de registrar datos en papel a hacerlo digital, es una iniciativa que encuentra apoyo en los mismos trabajadores. Sin embargo existen mecanismos burocráticos que hacen que los planes avancen, pero lentamente. Carrasco-Escobar comenta sobre el rol de los promotores en salud y su relación con las herramientas de trabajo:

[los agentes de salud] son personas que están muy cansadas de utilizar las mismas formas de registro de pacientes, que están muy cansadas del sistema de salud, pero que se ven en un entorno donde no lo pueden cambiar

Por otro lado, todos los entrevistados señalan que la llegada a la política pública es, por lo general, un camino sinuoso y realmente difícil para los investigadores. En este sentido, el apoyo del mentor dentro de la universidad, y el hecho de que el mismo mentor participe del comité del Plan Malaria Cero facilitaron mucho la llegada del proyecto a la política pública. Padilla-Huamantinco menciona cómo no todos los investigadores tienen esa puerta abierta:

una vez se logra el contacto ellos están muy abiertos a escuchar ideas nuevas […] lo malo es que llegar a esos niveles para que te escuchen es muy complicado

Una de las capacidades que los participantes indican como relevante es poder sostener la iniciativa en el tiempo. Más allá de la disponibilidad de recursos para llevar adelante la mejora de Gorgas y nuevas investigaciones, existen aspectos técnicos del proyecto que condicionan su sostenibilidad. En el caso de SeeedStudio, rePhone fue un producto desarrollado como prueba de concepto que no posee una comunidad activa y que la empresa pensaba discontinuar pronto, como comenta Padilla-Huamantinco:

una lección aprendida es asegurarte de que haya una documentación extensa y una comunidad detrás con experiencias previas sobre su desempeño

En términos de limitaciones institucionales, la falta de mecanismos internos para desarrollar procesos de investigación-innovación hizo que el proyecto tenga que ser presentado como una iniciativa académica tradicional, siguiendo protocolos académicos de investigación. Carrasco-Escobar señala que el obstáculo más significativo fue intentar “vender” una idea nueva a la universidad:

no existe algo como “tenemos esta plataforma y queremos hacer un diseño interactivo” […] tuvimos que de alguna forma disfrazar lo que estábamos haciendo dentro de una investigación académica tradicional

La gestión de la importación de los componentes fue un aprendizaje sobre la marcha. La administración de la universidad colabora con los procesos de compras pero más a nivel local que internacional. Especialmente con la compra en cantidades de cargadores y otros componentes, el laberinto administrativo sin orientación fue todo un reto para el equipo. En cuanto a la calidad de los materiales, la tasa de equipos que no funcionaron como se esperaba son altas. Resultó imprescindible contar con un número extra para evitar huecos en la recolección de datos.

teníamos presupuestados, no sé, cien GPS y al final usamos cincuenta porque era la cantidad de personas que ingresaron al estudio, pero tuvimos suerte porque de los cien la mitad no funcionó como se esperaba

Otro de los aspectos de la capacidad de sostener la iniciativa son los incentivos para los investigadores. A nivel académico, Padilla-Huamantinco señala cómo poco motivador el hecho del poco reconocimiento académico de este tipo de desarrollos. En una de las revistas especializadas en movilización donde Gorgas tiene un artículo en revisión, uno de los revisores comentó que el desarrollo del equipo abierto no era relevante para ser incluido.

sería diferente si se envia a Hardware X o al “Journal of Open Hardware” pero nosotros entendemos que este desarrollo es clave en el tema de esta revista, que es movilización […] se desmerece el esfuerzo de proponer algo diferente, pero además replicable, reproducible, siendo que eso es algo que se critica mucho en los estudios.

<img/tablas/sintesis-gorgas.png" style=“max-width: 100%;”>
Figura síntesis del caso Gorgas Tracker (click para ampliar)

7.2.6 Síntesis del caso

Este caso presentó los resultados del análisis de Gorgas tracker a partir de entrevistas a tres de sus participantes en diversos roles y del análisis de documentación pública. El equipo logró desarrollar un dispositivo propio de geolocalización con HCA para testear una nueva hipótesis en el estudio de la malaria en Perú, desarrollo en el que las comunidades que fueron sujeto del estudio, los trabajadores de salud a campo y las usuarias de la información desde la política pública influyeron de forma crítica para que se pudiera construir conocimiento útil.

Los resultados muestran de qué forma se construyó un dispositivo que responde a las necesidades locales de investigación: el diseño modular y orientado a la usuaria, la fabricación en ciclos iterativos, la división de tareas en el desarrollo y fabricación, el diálogo interdisciplinario en estas etapas. La diversidad de la participación en términos de género y formación/visiones del mundo aumenta cuando el equipo sale de la institución académica. En este sentido resulta crucial el rol que tuvieron los contactos con dos tipos de actores extra académicos: la comunidad indígena como sujetos de la investigación y su influencia en el diseño del artefacto; la política pública y su influencia en la construcción del problema de conocimiento, facilitada por los contactos a través de la universidad.

El análisis de capacidades permite observar que la autonomía en la construcción del artefacto y la utilidad en la producción de conocimiento son los factores principales que los participantes consideran como alcanzados. Aunque no mencionada inicialmente, la capacidad de base alcanzada que habilita las anteriores es la de trabajar de forma interdisciplinaria y generar un diálogo en el equipo desarrollador. Además, el proyecto permitió a jóvenes investigadores desarrollar sus ideas en un contexto institucional inicialmente adverso, beneficiándolos en la actualidad con la creación de un laboratorio propio. La capacidad de reparación de los artefactos también fue relevante, así como la de idear nuevos proyectos a partir de esta experiencia, en todos los participantes. El uso del espacio online como fuente de colaboración no resultó significativo, aunque sí se generaron colaboraciones con otros equipos de investigación dentro de la red GOSH.

7.3 Proyecto Open Flexure

Bloque: Proyectos académicos

7.3.1 Introducción al caso

El proyecto “Open Flexure” es una iniciativa del Dr. Richard Bowman, físico especialista en óptica, que surge en el contexto de su trabajo en la Universidad de Cambridge y la Universidad de Bath, en Inglaterra. Su objetivo es hacer que el posicionamiento mecánico de alta precisión sea accesible para cualquier persona que cuente con una impresora 3D. Estos mecanismos se utilizan en distintos artefactos, siendo el más desarrollado y visible hasta el momento el uso en microscopios de alta precisión.

Los archivos de diseño de Open Flexure (OF) fueron publicados en 2015 en GitHub, junto a la publicación de un pre-print describiendo el diseño y funcionamiento del artefacto. La principal innovación de OF consiste en el uso de bisagras flexibles que pueden fabricarse con impresión 3D y en su diseño monolítico, que le brinda gran estabilidad. Esto lo vuelve altamente preciso y minimiza las probabilidades de obtener imágenes defectuosas incluso en condiciones ambientales poco favorables. Actualmente, el desarrollo y mantenimiento del proyecto sigue siendo liderado por Bowman desde su laboratorio en la Universidad de Bath, el “Bath Open Instrumentation Group (BOING)”.

El equipo de Bowman obtuvo dos financiamientos para trabajar en el proyecto, por parte del programa del gobierno inglés denominado Global Challenges Research Fund (GCRF). El objetivo del programa es apoyar investigación que trabaje sobre los desafíos que atraviesan los países en desarrollo. La primera propuesta, compartida por Cambridge y Bath, financió la colaboración entre el equipo desarrollador y STICLab, un makerspace en Tanzania. El rol de STICLab es el de co-desarrollar y fabricar microscopios OF completamente en Dar es-Salaam, a fin de proveer institutos de investigación en salud y universidades locales con equipos de alta precisión y bajo costo. La segunda propuesta financia la automatización del proceso de diagnóstico de malaria a partir del uso de microscopios OF. En este caso el equipo trabaja directamente con el Ifakara Health Institute (IHI) en el desarrollo de algoritmos de machine learning que permitan acelerar el proceso de diagnóstico, basándose en el análisis de muestras obtenidas con microscopios OF. Las siguientes secciones presentan sintéticamente ambos espacios.

7.3.1.1 STICLab

STICLab, el primer makerspace de Tanzania, fabricó su primer OF o “SayansiScope” en 2016. El espacio fue co-fundado en 2015 por Stanley Mwalembe, una personalidad local en términos de innovación y desarrollo. Mwalembe, profesor en el Instituto de Tecnología de Dar es-Salam (DIT), había asistido en 2012 a una charla sobre impresión 3D en BuniHub, un espacio local de innovación, junto a dos de sus alumnos: Valerian Sanga y Paul Nyakyi.

El instructor de esa charla/taller, el estadounidense Matt Rogge, volvió a BuniHub en 2014 para seguir desarrollando una de las ideas que surgió de los participantes en esa primera instancia. El problema de los desechos electrónicos es muy importante en Tanzania, con 9500 toneladas generadas sólo en 2015. La idea era aprovechar esos desechos para construir una impresora 3D. El equipo logró construir la impresora, hecho que visibilizó la escena de innovación en Tanzania internacionalmente, opacada hasta ese entonces por el desarrollo activo de su vecino, Kenya. Poco después un fondo proveniente de Finlandia apoyaría a BuniHub para promover el desarrollo de fablabs locales y equiparlos con el nuevo modelo de impresora 3D.

En este contexto, Mwalembe y su equipo fundan STICLab en 2015, no sólo fabricando y utilizando impresoras 3D sino también trabajando en proyectos de innovación relacionados con el acceso al agua, que recibieron financiamiento del Banco Mundial. En 2016, a través de la organización inglesa TechForTrade, STICLab entró en contacto con TReND in Africa, organización sin fines de lucro que realiza capacitaciones en ciencia abierta y talleres de equipamiento con hardware científico abierto en distintos países africanos.

El repentino fallecimiento de Mwalembe en 2019 obligó a los co-fundadores Sanga, Nyakyi y Christian Brighton Mweta a tomar el mando de STICLab. El espacio cuenta hoy con un equipo de ocho colaboradores que se suman a los tres co-fundadores, con Sanga como CEO. A partir de la colaboración con OF, STICLab produjo y vendió microscopios a la Universidad de Dar es-Salam, en Tanzania. Sin embargo, su principal cliente es el Ifakara Health Institute (IHI), instituto de investigación en salud reconocido como de excelencia a nivel internacional (TWAS, 2009).

Tanto el equipo de Bowman como miembros de TReND in Africa participan activamente en GOSH desde sus inicios, por lo que STICLab entró en contacto rápidamente con la comunidad. Además, se convirtió en una referencia regional para GOSH a partir de ser la sede de la segunda edición de AfricaOSH, en 2019.

Open Flexure: primeros microscopios, o sayansiscopes fabricados en Tanzania (fuente: Twitter BuniHUB)

7.3.1.2 Ifakara Health Institute (IHI)

El instituto de investigación en salud Ifakara (IHI) fue fundado por investigadores del Instituto Tropical Suizo (STI), con sede en Basilea. El investigador Rudolf Geigy, del STI, llegó a Ifakara en 1949, cuando aún Tanzania se encontraba bajo dominio británico, buscando un lugar para desarrollar trabajo de campo en enfermedades tropicales. El valle otorgaba una oportunidad perfecta, ya que sus habitantes sufrían de toda enfermedad tropical imaginable y la ayuda era escasa. El nombre “Ifakara” significa “lugar donde se va a morir”, probablemente relacionado a la alta tasa de mortalidad en la región (IHI, 2020).

A partir de la independencia del país en 1961, Geigy coordinó con el nuevo presidente la transferencia del centro a manos locales. El paso de mando oficial sucedió en 1996, cuando el instituto pasó de llamarse Swiss Tropical Institute Field Laboratory (STIFL) a su nombre actual. Se convirtió además en un “trust” autónomo, con lazos directos tanto con el Ministerio de Salud de Tanzania como con el STI.

El instituto realiza tareas de investigación, educación y servicios. En cuanto a investigación, existen tres líneas principales: salud y ecología ambiental, intervenciones y ensayos clínicos, y evaluación de impacto y políticas. En términos de educación, desarrolla programas cortos de entrenamiento para investigadores en malaria y coordina el Máster en Investigación en Salud Pública. Provee también servicios de archivos, sala de conferencia y plataformas de información tanto a privados como a entidades públicas.

Actualmente el IHI emplea 600 trabajadores en seis localidades, con tres sitios principales. En Dar es-Salam se encuentra la sede administrativa. En Ifakara se encuentra la sede original y más antigua a siete horas de la capital, en una zona predominantemente rural. Sus investigaciones aportan datos sobre las enfermedades que afectan a los sectores más pobres del país. La sede costera de Bagamoyo, inaugurada en 2005, se encuentra a una hora de la capital y muy cercana a la isla de Zanzíbar, el destino turístico más importante de Tanzania. Es en Bagamoyo donde se utilizan los microscopios fabricados por STICLab, ya que el trabajo que allí se desarrolla es principalmente de diagnóstico, investigación y capacitación en temas relacionados a la malaria.

Open Flexure: ‘Mosquito city’ en el Ifakara Health Institute (fuente: web IHI)

7.3.2 Participación distribuida

El modelo de trabajo de Open Flexure puede pensarse como una cadena de suministro distribuida donde inicialmente existe una clara división del trabajo: desarrollo en Inglaterra, fabricación y uso en Tanzania; y que a través de los tres años de proyecto se desdibuja para dar origen a un modelo de codesarrollo entre Inglaterra y Tanzania, y de fabricación y comercialización locales por parte de STICLab. Una entrevista realizada en 2020, Valerian Sanga, CEO de STICLab, detalla las etapas en las que se involucra el makerspace:

Realizamos pruebas de fatiga, hacemos desarrollo de electrónica con el controlador de motor sangaboard, imprimimos en 3D los microscopios, proporcionamos asistencia técnica, desarrollamos el test mecánico “MechJiwe” […] pero también realizamos visitas a los lugares y tenemos reuniones con las partes interesadas, o buscamos la aprobación del gobierno para que los microscopios se utilicen en educación

El equipo en Bath, estrictamente académico, es liderado por el Dr. Richard Bowman e integrado por Julian Stirling, físico especialista en metrología, Joel Collins a cargo del desarrollo de software, Kaspar Bumke en soporte técnico, Ed Meng también físico y Kerrianne Harrington, especialista en óptica. En Tanzania, los trabajos de co-desarrollo y fabricación local fueron principalmente desarrollados por Valerian Sanga, Paul Nyakyi y Grace Anyelwisye, tres ingenieros graduados del Dar es-Salam Institute of Technology, CEO, co-fundador y colaboradora de STICLab respectivamente.

Las principales usuarias de Open Flexure son actualmente los trabajadores del Ifakara Health Institute en la sede Bagamoyo. El grupo está integrado por tres profesionales: la Dra. Catherine Mkindi, a cargo del equipo, y los profesionales Valeriana Mayagaya y Joram Mduda, quienes realizan diagnósticos de malaria, entre otras tareas de investigación.

Aunque de manera informal, el equipo de Bath señala como particularmente significativa la participación de Anna Lowe, consultora en procesos de manufactura con experiencia de trabajo en Ghana y una amplia red de contactos en la región, cofundadora de la alianza MakerNet. En entrevistas con Stirling en 2019, el investigador resalta la importancia del contacto local: “Es tan útil tener a alguien que hable el idioma correcto y haga las preguntas correctas, en lugar de un científico brusco como yo, que se acerca y dice: “Me gustaría ayudarte a hacer esto”.

El rasgo más llamativo del proyecto es la efectiva coordinación y construcción de capacidades entre Bath y STICLab como socio para la manufactura, comercialización y reparación locales del microscopio en Tanzania. Los integrantes del makerspace no sólo participaron en el proceso de fabricación de los diseños, sino que adaptaron los mismos a distintas particularidades del contexto local. Sanga recuerda la forma en que entraron en contacto con los investigadores ingleses:

G.W. [una estudiante] vino a nuestra espacio para hacer prácticas industriales mientras terminaba su maestría, de la Universidad de Cambridge […] a través de ella nos conectamos con el Dr. Richard Bowman y el resto del equipo […] un año después, el Dr. Richard estaba escribiendo una propuesta de proyecto, Open Lab Instrumentation, donde nos pidió que fuéramos socios en la fabricación

Open Lab Instrumentation, que permitió que Bowman ganara independencia como investigador a cargo del grupo BOING, financia el trabajo de STICLab, que no es solo técnico sino también de articulación con las organizaciones locales; tarea que de otra forma hubiera sido imposible para el equipo en Inglaterra. A modo de ejemplo, para poder insertar OF en las escuelas en Tanzania, primero es necesario acordar con el Ministerio de Educación, que tiene que aprobar el proyecto. Este es un proceso altamente burocrático que fue liderado totalmente por STICLab y permitirá en los próximos meses distribuir el microscopio en las escuelas del país. Algo similar sucedió con el contacto con la Universidad de Dar es-Salam, que sólo avanzó una vez que se concretó un contacto en persona. Stirling hace referencia a las dificultades de trabajar “a la distancia” con Tanzania: “Fue muy difícil para nosotros ponernos en contacto originalmente con la universidad de Dar es Salaam, pero ahora ya estamos en contacto […] los visitamos cuando estábamos allí para AfricaOSH”

Por otro lado, el rol de las usuarias del microscopio es fundamental en el proceso de coproducción, tomando un rol activo en la prueba y sugerencia de mejoras sobre el diseño. Las usuarias del IHI son investigadores altamente calificados; OF les abre la posibilidad de intervenir en el diseño del artefacto, estando en contacto directo con los fabricantes, transmitiendo sus inquietudes y nuevas ideas. Joram Mduda, técnico en IHI, comenta en una entrevista en 2019 cómo entró en contacto con el makerspace: “Conocí a STICLab después que lo mencionaran nuestros colegas de Cambridge […] me informaron de cómo querían que sea esta colaboración, me dijeron que estaban trabajando también con STICLab”

En términos de diversidad de la participación, OF articula actores que de alguna forma observan el proceso de fabricación desde ángulos diferentes de acuerdo a sus roles en el proceso (desarrollador, fabricante, usuaria); en el primer caso los perfiles son de investigadores académicos, en el segundo ingenieros, en el tercero técnicos de laboratorio. La participación de mujeres sólo se da a partir de la etapa de uso, como técnicas en el Ifakara Health Institute. La distancia más grande entre saberes, más allá del tipo de expertise, está en la distancia entre dos culturas tan diferentes. Stirling menciona una de las diferencias concretas que primero observó en Tanzania: “Si intentas construir algo, necesitas gente para soldarlo, con hierro fundido […] si intentas hacer que algo se suelde así en Inglaterra, casi nadie lo hace ya aparte de las grandes empresas”.

7.3.3 Diálogo hacia la coproducción

Uno de los objetivos principales del proyecto fue desde el comienzo poder fabricar los microscopios completamente en Tanzania. Para ello, la estrategia del equipo en Bath fue programar visitas largas tanto de Stirling a STICLab como de Sanga y Nyaki a Cambridge/Bath. En estas visitas, además de perfeccionar habilidades en términos de fabricación digital y ensamblado de los equipos, se consideraba cómo adaptar los procesos a las condiciones locales en Dar es-Salam y los desafíos que pudieran surgir en el día a día. Stirling menciona por qué se decidieron por esta metodología de trabajo: “si vas a visitar a alguien durante dos días, todo el mundo te muestra las mejores cosas que quieren mostrarte y tal vez no exactamente cómo funcionan las cosas”.

Fabricar un microscopio como OF demanda habilidades prácticas concretas, como saber utilizar software CAD, poder realizar un diseño para impresión 3D y saber operar una impresora. Pero también otras habilidades menos evidentes, como por ejemplo saber cómo manipular las partes ópticas del microscopio de forma tal de garantizar la calidad del trabajo. En STICLab la impresión 3D no es un problema, pero las buenas prácticas para manejar elementos ópticos fueron un desafío. Las condiciones del makerspace se asemejan más a un taller mecánico abierto que a un área limpia para trabajar en óptica, por lo cual hubo que adaptar el trabajo para obtener los mejores resultados posibles. Stirling comenta que, como físico especializado en óptica, esto fue lo que más trabajo le costó aceptar: “Lo que cuenta como limpio para la óptica es muy diferente de lo que cuenta como limpio para un tornillo”.

Una de las ventajas del diseño monolítico de OF es que no sufre tantas alteraciones como otros materiales frente a la temperatura o la humedad. Para facilitar y acelerar el proceso de ensamblado, las piezas impresas se “encastran” con el resto de los componentes. En total, el microscopio puede ser ensamblado en dos horas por una persona con experiencia, o en cuatro horas la primera vez. Desde el diseño de las piezas impresas el criterio que se utiliza es el de evitar imprimir material de soporte. Esto hace que sea fácil y más rápido de imprimir, evitando el riesgo de dañar piezas en el ensamblado. Sin embargo algunas piezas son delicadas y en definitiva es un artefacto pequeño, que requiere de un manejo de precisión. Fue necesario que se rompieran los primeros modelos para poder incorporar esa dimensión de cuánta fuerza tolera el artefacto. Sanga comenta que este fue uno de los aprendizajes que rescata: “Aprendí algunos nuevos trucos de la impresión 3D porque el microscopio está hecho completamente con una impresora FDM”.

La lista de materiales necesarios para construir un microscopio OF incluye una placa/computadora Raspberry Pi que controla el microscopio, lentes que pueden obtenerse de microscopios viejos y cámaras web, y componentes no impresos que pueden reciclarse o conseguirse en una ferretería fácilmente, como tuercas, O-rings. Se seleccionan siempre considerando disponibilidad local, costo y performance. Uno de los problemas que aparecieron rápidamente fue la falta de acceso a ciertos componentes, o la utilización de técnicas diferentes de trabajo, como identifica Sanga: “la logística de los productos importados en Tanzania es un poco un problema, no es lineal como en el Reino Unido”. Stirling también pudo observar diferencias en metodologías de trabajo: “Si quieres algo bien hecho en Tanzania probablemente lo quieras soldar; aquí [en el Reino Unido] seguramente atornilles extrusiones de aluminio”.

Todas las versiones de OF se manejan con el mismo código backend, que se distribuye como imagen en una tarjeta SD para Raspberry Pi; para poder configurar el microscopio es necesario tener un nivel medio de programación. Los conocimientos en electrónica, electricidad e ingeniería en general en STICLab son altos, habiendo fabricado sus propias impresoras 3D. Por el contrario, la curva de aprendizaje fue ardua en términos de software y programación del microscopio. Stirling menciona que esto fue inesperado para el equipo de Bath, y por lo tanto formó parte del programa de capacitación de STICLab: “Al comenzar el proyecto esperábamos un grado mucho más alto de conocimientos de programación por parte de STICLab, por el título universitario que tenían, pero estaba más orientado a la ingeniería general y la electrónica”

Quizás lo más interesante en términos de diferentes grados de participación sea la división de tareas debido a la propia complejidad de la innovación. En este caso, el repositorio base de código escrito por el Dr. Bowman no suele ser modificado ni siquiera por su equipo en Bath. La dinámica adoptada, similar a muchos otros proyectos de software y hardware abierto, es modular. Si el equipo desea agregar una funcionalidad, escribe el código necesario de forma tal que sea compatible con la base original y “lo enchufa” a la base. Stirling menciona de qué forma trabajan el software:

el código base del microscopio es increíblemente complejo […] la mayoría de los grandes increíbles cambios vienen de Richard sólo porque es un código base tan grande el que él escribió, que es más fácil para él saber cómo funciona que para nosotros.

El proceso de coproducción tomó aproximadamente tres años desde el inicio del proyecto hasta hoy. Ambos participantes comentan la complejidad de colaborar, desde el lado desarrollador delegando control sobre el proyecto en la otra parte, y por el lado del fabricante poder confiar en que un actor con más poder va a mantener una relación equitativa en la colaboración. Stirling comenta que en definitiva es un proceso que toma tiempo: “Trabajábamos juntos, teníamos problemas comunes que resolver […] se trataba, creo, de desarrollar suficiente respeto mutuo”

Es interesante señalar cómo más allá del intercambio exitoso entre los equipos y la confianza lograda, el proyecto sigue inserto en una sociedad que reproduce visiones colonialistas y esto impacta en el proceso. Por un lado, en una nota que Nature Toolbox le realizó a Stirling, el entrevistado mencionó el costo de pagar vuelos de primera clase a ingenieros europeos como una de las barreras a la reparabilidad de artefactos en Tanzania. Sin embargo, el artículo publicó una versión ligeramente diferente, hecho que Stirling menciona con visible enojo: “me citaron diciendo que no hay buenos ingenieros en Tanzania”. Por otro lado, Stirling nota cómo la conexión con Cambridge y Bath abre puertas para STICLab localmente: “tienes la sensación de que la gente desconfía de las cosas que se hacen en Tanzania, lo que es una gran vergüenza”.

Open Flexure: coprodución en GOSH 2018, Shenzhen, China (fuente: GOSH Flickr)

7.3.3.1 El espacio online

Toda la documentación tanto para fabricar como para utilizar un microscopio Open Flexure se encuentra disponible en el sitio web del proyecto. Los documentos técnicos están alojados en un repositorio GitLab, y el equipo interactúa con la comunidad a través del foro de discusión y de una sala de chat, alojada en Gitter. Se pueden encontrar traducciones al español y video tutoriales de como ensamblar cada parte del microscopio.

Las contribuciones más significativas fueron realizadas a nivel de software, no del lado del servidor, que resulta más complejo, sino de los módulos con los que interactúan las usuarias. Las colaboraciones incluyen la detección de bugs o preguntas específicas sobre el funcionamiento del microscopio, pero también un adaptador que permite conectar el microscopio OF con el sistema modular óptico “UC2” alemán -otro proyecto de hardware abierto-, y una carcasa resistente diseñada por STICLab para proteger el microscopio al transportarlo.

7.3.4 Diseño desde la usuaria

En STICLab se producen actualmente cuatro diseños de Open Flexure, como menciona Sanga: “nuestro producto se divide en cuatro categorías, tenemos algunos para fines educativos y tenemos los de diagnóstico de la malaria para el hospital y centros de investigación”. Para obtener las diferentes versiones, el concepto de diseño modular se vuelve clave, ya que facilita el intercambio de componentes que habilitan diferentes funcionalidades.

Dadas las características especiales del mercado educativo en Tanzania, aún no se pueden comercializar los microscopios con escuelas ya que requieren de autorización del gobierno. Sí se comercializa la versión avanzada con el IHI; el grupo liderado por la Dra. Mkindi está en contacto con STICLab, quien provee los equipos y las partes en caso de ser necesaria una reparación. El grupo utiliza el microscopio para realizar diagnósticos de malaria y entrenar a nuevos técnicos en su ensamblado, uso y reparación. Mduda, técnico del IHI y parte del proyecto, detalla las tareas que realiza para OF:

Pruebo el dispositivo, identificando problemas en las etapas de desarrollo y también hago la corrección de datos de las imágenes resultantes […] También comparto el conocimiento con los técnicos locales en otros centros de salud

El equipo en IHI, además de testear los microscopios y dar su opinión para volver a testear las nuevas versiones, entrena a otros técnicos a campo, en regiones más alejadas, en el uso del equipo para el diagnóstico de malaria. Mduda comenta que como parte de esta tarea de divulgación hace demostraciones en el mismo centro para testear usabilidad y difundir el proyecto: “cuando entreno a alguien le muestro todo, cómo ensamblarlo y después de ensamblarlo, asegurándome de que conoce bien el microscopio”.

El primer diseño que produjo STICLab, aunque funcional, presentaba algunas dificultades para los técnicos del IHI. A través de varias reuniones e iteraciones, se detectaron que los obstáculos estaban principalmente originados en la ausencia de una interfaz gráfica para realizar las distintas tareas. Por ejemplo, el agregado de pacientes se hacía a través de línea de comandos, teniendo que utilizar código; el autofoco, esencial para el trabajo con microscopio, también se controlaba con una interfaz basada en texto.

Mduda tiene años de experiencia trabajando con microscopios convencionales, sin embargo, señala que trabajar con la primera versión del microscopio le resultaba muy difícil, especialmente por la necesidad de programar: “Cuando empecé a usar esa versión, era tan complicada que necesité encontrar un curso o tutorial para asegurarme de que era capaz de usarla”.

La segunda versión, diseñada a partir de estas observaciones, permitió una adopción mucho más amplia por parte de los técnicos. Por un lado, la nueva versión permite acceder a los datos y controles del microscopio desde una aplicación en el celular. La masificación de los smartphones hace que la mayoría de las personas esté muy familiarizada con este tipo de interfaces. La aplicación permite acceder a las notas, imágenes, metadata ingresadas e incluso accionar el escaneo. Por otro lado, se desarrolló un software para ajustar el autofoco del microscopio utilizando el mouse, y un formulario gráfico en la misma interfaz para agregar pacientes. Mduda asegura al respecto: “Enseñar a alguien a usar el microscopio para esta etapa en la que estamos es muy fácil, porque no necesitas programar”

Las imágenes obtenidas con OF se almacenan en un servidor en el IHI, de manera que tanto los investigadores del IHI, de Cambridge y de Bath tienen acceso a ellas. Con estas imágenes trabaja el proyecto más reciente del equipo, que pretende desarrollar algoritmos de machine learning que puedan evaluar una muestra y determinar si es sospechosa de malaria o no; a fin de que el técnico no pierda tiempo en revisar aquellas que claramente no presentan evidencia de la enfermedad. OF inspiró a Mduda nuevas ideas y proyectos de automatización de tareas, que ya está planificando con sus compañeros del IHI.

7.3.5 Construcción del problema

El equipo en Bath comenta cómo la construcción del problema de conocimiento se basó en dos objetivos principales: solucionar el problema del acceso a equipamiento científico en Tanzania a partir de crear un circuito corto de provisión y reparación, y generar equipamiento abierto confiable, de alta calidad que pueda ser útil en investigación.

El equipo inglés entra en contacto con STICLab a partir de una colaboración previa entre el makerspace y otro proyecto en Cambridge. Este primer contacto, y luego la participación en los encuentros globales GOSH consolidaron el vínculo. El eje principal de problematización al que llegaron es la ausencia de capacidades locales de mantenimiento de los equipos científicos en Tanzania, lo que hace que la compra de herramientas, de por sí poco accesibles, se vuelva insostenible en el tiempo. Por un lado, las partes de los microscopios (y de otras herramientas) no se consiguen en el mercado local. Pero todavía más significativo, los proveedores de equipos no poseen personal local ni regional entrenado en reparación y los diseños son cerrados por lo tanto no pueden inspeccionarse. Esto deriva en que cualquier mínima operación de reparación o mantenimiento demanda viajes de técnicos especializados desde Europa o Estados Unidos, imposibles de costear para los locales. Julian Stirling, investigador en Bath que llevó adelante el trabajo de codiseño con STICLab, comenta este problema: “Especialmente cuando hablamos de equipos de laboratorio, una gran proporción de ellos en África están rotos”.

En segundo lugar, el acceso a la impresión 3D como metodología de fabricación digital de bajo costo provocó una explosión de diseños de microscopios “do it yourself” en los últimos años. Hechos a partir de combinar lentes reciclados o cámaras web y piezas impresas, el mensaje de estos proyectos suele ser “ciencia a bajo costo” o “ciencia para todos”. Sin embargo, la calidad de estos diseños es muy variable y su precisión no alcanza el grado necesario como para ser utilizados en investigación, aunque sí son utilizados en educación. Stirling menciona que uno de los problemas es la dinámica de la académica que incentiva a publicar aunque los diseños no estén probados: “muchos de los proyectos de GOSH que he visto no son de alta calidad debido al modelo académico de que una vez que has publicado un trabajo, algo está hecho […] haces un primer prototipo y publicas un trabajo diciendo ‘esto más o menos funciona’".

Combinando estos dos problemas el equipo OF problematiza la concentración de la producción de las herramientas científicas de alta calidad en el norte global como perjudicial para los países en desarrollo. Frente a esta situación, la propuesta del equipo es generar un diseño abierto de microscopio de calidad apta para la investigación y en asociación con un makerspace local, generar la capacidad de fabricación y mantenimiento del mismo. Se plantea la producción distribuida, a bajos volúmenes y la venta a universidades e institutos como una alternativa de modelo de negocio posible para sostener la existencia de los makerspaces.

El equipo de investigación en la Universidad de Bath está interesado en el diseño, pero no en el aspecto de fabricación y distribución de los microscopios. Encontrar un socio capaz de fabricar y reparar el artefacto se considera como un círculo virtuoso que beneficia a todas las partes, garantizando la sustentabilidad del proyecto. Stirling menciona sobre la sustentabilidad: “lo que realmente necesitamos para hacer que el hardware abierto sea una realidad es una forma de que la gente pueda producirlo manteniéndolo abierto, manteniendo suficiente rentabilidad”.

El caso de aplicación elegido, diagnóstico de malaria, ilustra estos problemas de forma muy concreta. La microscopía óptica es el criterio de referencia adoptado internacionalmente por la Organización Mundial de la Salud para el diagnóstico de malaria. Sin embargo los problemas mencionados anteriormente demoran y dificultan el diagnóstico y tratamiento de la gran cantidad de pacientes. La motivación principal del equipo es poder acelerar este proceso en zonas donde no solo los equipos escasean sino que la disponibilidad de personal técnico de diagnóstico es reducida.

La propuesta, que surge en colaboración tanto con STICLab como con el IHI, es desarrollar un circuito completamente local, donde un makerspace pequeño produce y mantiene microscopios de bajo costo, capaces inicialmente de permitir que todos los técnicos trabajen simultáneamente, atendiendo más pacientes en menor tiempo. Stirling defiende muy enfáticamente la intención de cerrar el circuito local en la mayor medida posible: “Creemos que identificar y resolver estas cuestiones es esencial si queremos alentar a los institutos de investigación del Norte Global a diseñar la instrumentación con los africanos, en lugar de “para África”.

Participar de este tipo de proyectos, tanto para el makerspace como para los técnicos del IHI en Tanzania, es motivo de orgullo. Tanto Sanga como Mduda mencionan que son parte de un proyecto que pretende tener un impacto social en su país; en el caso de Sanga: “[en el futuro] nos vemos a nosotros mismos en el rol de la fabricación, el apoyo técnico, y en ser los mejores embajadores de esta innovación”. Para Mduda, “cuando empecé a trabajar en este proyecto sabía muy poco sobre el diagnóstico, pero ahora puedo decir que soy experto […] incluso cuando estoy en casa, cuando alguien conoce un caso de Malaria ahora la gente me pregunta, sé todo sobre la Malaria”.

Open Flexure: configuraciones y modos de imagen posibles (J. T. Collins et al. 2020b)

7.3.6 Construcción de capacidades

7.3.6.1 Capacidades alcanzadas

La capacidad más mencionada en entrevistas y documentos por parte del equipo de Open Flexure es la de contar con mayor autonomía en cuanto a la provisión y reparación de herramientas científicas. Para ello, el proyecto intenta generar la capacidad de fabricar y reparar localmente bajos volúmenes de microscopios. Por un lado generar un circuito corto de comercialización, que contemple la provisión de componentes disponibles en el mercado local o que pueden importarse sin mayores restricciones, destinado a compradores locales o regionales. Por otro lado capacitar al personal necesario que pueda garantizar el funcionamiento del circuito.

En términos de autonomía y producción local, STICLab tiene actualmente la capacidad de producir microscopios Open Flexure tanto para educación como para investigación de forma local. Los componentes necesarios pueden ser adquiridos de forma confiable, garantizando la provisión. A su vez, las estancias de intercambio hicieron que STICLab cuente con profesionales capacitados para producir y reparar los microscopios de manera independiente. Las usuarias, en el IHI, también desarrollaron entrenamientos en reparaciones básicas, para sólo tener que acudir a STICLab en caso de problemas mayores.

Unida a esta capacidad se encuentra la capacidad de generar pequeños emprendimientos locales con un modelo de negocios sostenible basado en la apertura. Se trabaja aquí sobre el supuesto de que al igual que en el software de código abierto, las oportunidades de negocio basadas en el hardware abierto son posibles y poco exploradas. STICLab ha comercializado algunos modelos, y se encuentra en camino a acordar con el gobierno local la autorización para proveer a escuelas. A partir del préstamo inicial de algunos microscopios, la universidad de Dar es-Salam mostró interés en adquirirlos. Uno de los puntos clave para poder comercializar el microscopio de alta precisión es obtener la certificación CE que garantiza conformidad con las normas de salud, seguridad y protección del medio ambiente mínimas que rigen en el mercado europeo, dado el origen europeo del diseño.

Otra capacidad importante para el equipo es la de poder producir equipos de alta precisión y calidad, aptos para la investigación científica y adaptados a las necesidades de las diferentes usuarias. Ya sean universidades, escuelas o institutos de investigación, poder desarrollar vías de comunicación que permitan incorporar las mejoras que estas usuarias consideran importantes en términos de accesibilidad, innovación y durabilidad. Stirling comenta cómo los incentivos académicos influyen en este problema de la calidad:

En muchos proyectos, el modelo académico de ‘publico un artículo, hago algo y paso a otra cosa’ […] Si alguien quiere usar [tu proyecto de hardware] en su laboratorio, ¿cuánto debugging necesita? No es tan útil como algo que ha sido diseñado como un producto.

Más allá de las normas de calidad para poder comercializar el producto, la capacidad de producir un artefacto de alta calidad localmente está lograda. El trabajo a largo plazo del equipo permitió diseñar pruebas de resistencia mecánica, pruebas de fatiga y otras que permiten generar datos confiables. Esos datos permiten aseverar que el microscopio funciona, y su vida útil estimada.

La capacidad de adaptar el diseño al uso se ve probada en las iteraciones entre el personal técnico del IHI y los fabricantes en STICLab. Las sugerencias propuestas por Joram fueron mayoritariamente implementadas, derivando en una segunda versión que incluyó no sólo cambios a nivel de software a nivel de usuaria sino desarrollo de una aplicación móvil dedicada. Mduda comenta al respecto: “Tengo una persona, un pasante, que aprendió en tres días y ahora es capaz de usar el microscopio”.

Si consideramos al personal de STICLab como “usuaria” del primer diseño originado en Bath, también los integrantes del makerspace adquirieron la capacidad de modificar el diseño para ajustarlo a sus necesidades. El diseño de la carcasa de transporte, el cambio en la lista de materiales para poder obtenerlos fácilmente, permitieron que los fabricantes co-desarrollen junto al equipo en Bath.

En términos de impacto, la capacidad de poder influir a través del proceso en soluciones a problemas de desarrollo local está en proceso. Las pruebas para reducir la carga laboral sobre el escaso personal técnico en diagnóstico de malaria siguen en período de prueba. Para Mduda es fundamental que se pueda acelerar el proceso de diagnóstico:

La demanda de diagnósticos diarios es grande comparada con el número de técnicos […] si la gente obtiene un diagnóstico más rápido obtendrá los tratamientos adecuados y los tratamientos correctos implican que la gente va a estar sana, y siguen trabajando, y generando ingresos.

Otro uso planificado de OF es la venta a universidades, que no suelen contar con instrumental para que los estudiantes utilicen. Mduda también comenta sobre este problema que vivió cuando estudiaba:

Algunas personas completan sus estudios en las universidades y algunas de ellas ni siquiera saben cómo se ve la malaria en la realidad, no en la foto […] si tenemos la oportunidad de aplicar esto a la enseñanza, al sistema educativo, creo que sería útil para ellos.

Una de las capacidades quizás implícitas en las definidas por el proyecto pero no explícitamente mencionadas es la de generar nuevas ideas a partir de necesidades locales. Las usuarias en el IHI por ejemplo están interesados en iniciar un proyecto de automatización que vaya un paso antes al análisis de muestras. Uno de los principales problemas que encuentran en el día a día es que la calidad de las imágenes depende de la calidad del preparado de la muestra. Mduda comenta que lo que están planificando es automatizar este paso de preparado, para poder obtener mejores imágenes en lugares donde no se cuenta con técnicos: “una máquina que no implica mucha tecnología […] ayudaría al técnico, una máquina de teñido automático que preparara la muestra para ingresarla al microscopio”.

7.3.6.2 Capacidades ausentes y otros limitantes

Como en todo proyecto de hardware abierto, la documentación es el centro que permite que los actores colaboren y contribuyan al desarrollo. Actualmente, la capacidad de actores por fuera del equipo original de colaborar con el proyecto es limitada. En parte porque mejorar la documentación es una tarea laboriosa que toma mucho tiempo, en parte porque el software muchas veces vuelve la tarea más complicada. En palabras de Stirling, “No creemos que el co-diseño sea intrínsecamente menos eficiente, pero sí que las herramientas que necesitaríamos para hacerlo eficazmente no están disponibles”.

En software, el trabajo con control de versiones está ampliamente diseminado y es utilizado como un estándar en la industria. En hardware, aunque cada vez más utilizado, no está aún totalmente incorporado, especialmente en proyectos comunitarios. Sin embargo, se vuelve un requisito imprescindible si se pretende que los desarrollos sean colaborativos, sumando sobre lo que otros equipos trabajan. Todos los archivos de diseño de OF están alojados en GitLab. Trabajar con la plataforma demanda una cierta curva de aprendizaje, que hasta el día de hoy genera desajustes en el equipo. La barrera es tan importante que parte del equipo de Bath está desarrollando una interfaz más sencilla orientada a hardware, denominada GitBuilding.

Otra de las herramientas fundamentales es el software de diseño asistido (CAD), ampliamente difundido a nivel global, con interfaces gráficas que facilitan el acceso a públicos más amplios. Sin embargo, de acuerdo a su historia y formación, algunas personas manejan algunos programas y no otros. Considerando apertura y utilidad, el equipo desarrollador utilizó desde el comienzo OpenSCAD. Éste difiere del resto de los programas en que su principal interfaz de uso no es gráfica, sino a través de código. Dada la formación del equipo en Bath (todos son físicos) OpenSCAD resulta más eficiente y provee mayor control que sus alternativas, pero definitivamente no es accesible al equipo en Tanzania, ni a otros que no posean esa formación.

En términos de infraestructura, la desigualdad de condiciones entre países y contextos, implica que algunas estrategias que se asumen simples en Bath no funcionen en Tanzania. Stirling comenta sobre estas diferencias:

desde un taller en Dar es-Salaam uno puede tener que encontrar una computadora portátil y conectarla a un teléfono antes de poder responder a una pregunta en GitHub […] Este inconveniente extra lleva la conversación a plataformas como WhatsApp, que no son ni públicas ni sencillas de archivar y buscar

Existe un esfuerzo desde el proyecto por minimizar las desigualdades estructurales entre los equipos en Tanzania y en Inglaterra. Sin embargo, la confianza que tienen los mismos habitantes de Dar es-Salam en STICLab como proveedor local es un factor a trabajar. Stirling menciona cómo utiliza a su favor los prejuicios colonialistas para aumentar la buena imagen de STICLab entre los locales: “Es realmente desafortunado, pero ‘soy un inglés que recién llega, ¿puedo visitar su organización?’ es más exitoso que ‘hola, soy STICLab, ¿puedo visitar su organización?’”

La relación con la universidad es otro factor especialmente importante para el equipo en Bath. Las oficinas de transferencia tecnológica no están capacitadas en el uso de licencias abiertas, y por lo tanto suelen presionar a los equipos desarrolladores a patentar sus invenciones. En el caso de OF, las innovaciones fueron publicándose bajo licencias abiertas de forma modular, poco significativa, de manera que no fuera algo “tentador” que la universidad busque patentar. Actualmente el equipo busca activamente el diálogo con la oficina de transferencia tecnológica de Bath para impulsar una vía de asesoramiento interna en hardware abierto y sus esquemas de licencias disponibles.

<img/tablas/sintesis-of.png" style=“max-width: 100%;”>
Figura síntesis del caso OpenFlexure (click para ampliar)

7.3.7 Síntesis del caso

Se presentaron los resultados del análisis del proyecto Open Flexure a partir de entrevistas a tres de sus participantes en diversos roles y del análisis de documentación pública. En tres años, el equipo logró pasar de un diseño prototipo a un desarrollo que puede ser fabricado a bajos volúmenes respetando normas de calidad, apto para investigación clínica. Lo hizo a través de un proceso de coproducción que permitió construir capacidades en el makerspace STICLab, habilitando su rol de co-desarrollador, fabricante y comercializador del microscopio en Tanzania. En este proceso de coproducción y adaptación a las condiciones locales a la vez, el rol de las usuarias del microscopio fue fundamental, testeando funcionamientos y proponiendo mejoras. Este rol activo además generó nuevos proyectos de automatización y reubicó el problema desde la falta de infraestructura a la falta de recursos humanos para el diagnóstico de la malaria.

Para habilitar todos estos procesos, se realizaron intercambios en forma de largas estancias entre el equipo inglés y tanzano que llevaron a la construcción de un lenguaje común a pesar de las grandes diferencias culturales. El diseño modular y orientado a la usuaria, la fabricación en ciclos iterativos, la división de tareas en el desarrollo y fabricación y el diálogo interdisciplinario son claves para facilitar estos proyectos. Este gran trabajo en términos de diálogo entre culturas contrasta con la nula diversidad en términos de género en el proyecto. Los aprendizajes del proceso de coproducción se documentan y hacen disponibles online, recibiendo colaboraciones principalmente en módulos de software.

El análisis de capacidades permite observar que la autonomía en la construcción del artefacto y la utilidad en la producción de conocimiento son los factores principales que los participantes consideran como alcanzados, además de la capacidad de sostener la iniciativa a partir de poder comercializar los microscopios. Una de las capacidades más interesantes en OF es la de producir artefactos que cumplan con criterios y tests de calidad, probablemente derivado del hecho de que se trabaja continuamente sobre el proyecto hace tres años. Aunque no mencionada inicialmente, la capacidad que habilita las anteriores es la de poder trabajar de forma colaborativa, o coproducir.

La capacidad de reparación de los artefactos también fue relevante, así como la de idear nuevos proyectos a partir de esta experiencia, en todos los participantes incluidas las usuarias. El uso del espacio online como fuente de colaboración resulta fructífero aunque demanda de esfuerzos constantes por parte del equipo. Algunas de las barreras que se identifican para este tipo de colaboración es la falta de software adecuado para colaboración en hardware, y las barreras de acceso dada la complejidad del desarrollo.

7.4 Proyecto Vuela

Bloque: Proyectos comunitarios

7.4.1 Introducción al caso

Vuela es un proyecto nacido en el año 2017 en la ciudad de Melipilla, Chile, al pie del Cerro Sombrero, iniciado por Paz Bernaldo y Gustavo Pereyra Irujo luego de conocerse en la reunión global GOSH en Chile. Desde entonces Vuela construye drones de código abierto para investigación científica tanto comunitaria como académica.

Antes del encuentro en 2017, Bernaldo trabajaba con una comunidad de vecinos en zonas vulnerables de Melipilla en proyectos de inclusión social a través de la fabricación colaborativa de tecnologías simples. Estos talleres donde se construían luces con elementos reciclados fueron financiados por un subsidio pequeño de la fundación holandesa “Age of Wonderland”. Tanto los talleres como otras actividades realizadas con artistas locales contribuyeron a crear lazos de confianza con la comunidad local.

Estos talleres habían finalizado hacía poco tiempo cuando sucedió el encuentro GOSH 2017 en Chile. Allí se conformaría el equipo entre Bernaldo, que buscaba nuevas ideas para seguir trabajando con la comunidad, y Pereyra Irujo, ingeniero agrónomo e investigador CONICET en INTA Balcarce, que se encontraba experimentando con drones para investigación en agricultura desde 2013.

Invirtiendo fondos propios y luego a través de un subsidio de la organización “Knowledge, Culture, Ecologies”, Vuela realizó una serie de talleres con la comunidad de Melipilla durante 2017. El objetivo de los talleres era construir un drone de código abierto con los vecinos de una comunidad vulnerable de la zona, que sirviera para trabajar algunas de las problemáticas que vivían a diario y como instancia de empoderamiento a través del aprendizaje con tecnologías. Más allá del drone como artefacto, Vuela es también un experimento que intenta responder a la pregunta ¿Quién puede producir conocimiento y tecnología? ¿Para qué?

A través de la participación en los talleres y las conversaciones con diversos investigadores, los vecinos de Melipilla llegaron a formular un problema a trabajar usando el drone. Muy cerca del cerro donde se ubican sus casas existe una cantera que la municipalidad dice haber cerrado pero que los vecinos aseguran sigue en funcionamiento, y resulta peligrosa para quienes habitan los alrededores. Quizás el drone se podría usar para sobrevolar la cantera y fotografiar la actividad, generando pruebas para presentar ante la municipalidad.

En los talleres los vecinos logararon construir un drone a partir de copiar el “Flone”, un diseño español abierto, fácil de fabricar, económico y con materiales fácilmente accesibles desde cualquier lugar. Una vez conseguido este objetivo, en 2018 un fondo de Mozilla Science permitió seguir con las actividades, ya que el Flone necesitaba mejoras para poder tomar imágenes que fueran útiles.

Estas modificaciones, que se hicieron no solo en talleres en Melipilla sino también en talleres itinerantes en Balcarce, Buenos Aires y Mendoza, mejoraron la estabilidad, maniobrabilidad y usabilidad del drone, cuyo nuevo diseño fue denominado “Meliflone”. Una vez agotado el financiamiento, aunque el Meliflone se convirtió en una versión mejorada del Flone, todavía no servía para tomar imágenes aptas para la investigación.

Fue así que con el fin de convertir al Meliflone en un drone de código abierto capaz de cumplir funciones de herramienta de investigación, en 2019 Vuela consigue un financiamiento del Programa Cooperativo para el Desarrollo Tecnológico Agroalimentario y AgroIndustrial del Cono Sur (PROCISUR). Este fondo, aún activo, tiene como objetivo equipar a los institutos de tecnología agropecuaria de distintos países latinoamericanos con drones de código abierto aptos para la investigación en agricultura y cambio climático.

Esta versión mejorada del Meliflone se denominó “Objeto Volador Libre” (OVLI), y fue producida en conjunto con investigadores de los institutos de tecnología agropecuaria de siete países latinoamericanos, en talleres itinerantes. Los OVLIs que se construyen en cada taller quedan para los investigadores que los fabrican, y en algunos casos ya los están volando.

Desde el inicio del proyecto en 2017 hasta hoy, Vuela construyó drones en centros vecinales con participantes que no hablan español, que no tienen ningún tipo de conocimiento previo sobre drones, con estudiantes, con activistas en espacios comunitarios, con investigadores en ámbitos formales. El proceso fue documentado en diferentes plataformas y puede accederse, junto a toda la documentación para fabricar un OVLI, en la página web del proyecto.

Vuela: Múltiples versiones de los drones para ciencia comunitaria (fuente: Instagram)

7.4.2 Coproducción radical

La hipótesis principal de trabajo detrás de Vuela viene desde los primeros talleres de fabricación de luces en Melipilla. La idea que guía el trabajo es que la segregación y marginalización de las personas en los espacios físicos tiene un correlato con su exclusión también de los espacios digitales, y que esta segregación está relacionada con el acceso diferencial de distintos grupos de personas al conocimiento y la tecnología. A partir de esta idea, los talleres se piensan como instancias de desarrollo de capacidades en ciencia y tecnología que empoderan a los participantes para disminuir esa brecha en el terreno de lo digital, y quizás, también en el espacio físico.

En una entrevista en 2017 Bernaldo expone estas ideas que surgen a partir de observar problemas en relación al territorio urbano en Melipilla, y su extrapolación al territorio digital:

Si queremos que este lugar deje de ser segregado y se utilice este cerro urbano como un espacio transformador, de innovación y para la acción colectiva, ¿Cómo podemos utilizar aquello que parece ser tan sencillo para la gente, como es lo digital, para generar ese empoderamiento a nivel material? El espacio público puede ser lo digital, internet o las tecnologías de la comunicación, y también puede ser un espacio material, físico.

La génesis de Vuela trae aparejadas ideas críticas sobre teorías del desarrollo y descolonización del conocimiento que hacen un fuerte énfasis en la coproducción. En este contexto el hardware abierto es visto como una herramienta que facilita los procesos locales de coproducción de conocimiento y tecnología. Poder acceder a los diseños de las herramientas es considerado un requisito fundamental para poder mejorarlas, adaptarlas y usarlas en contexto. Bernaldo resalta la dimensión de poder asociada a lo tecnológico:

la democracia no sólo pasa por votar para las elecciones sino también pasa por cómo se genera el conocimiento […] quienes acceden a las tecnologías finalmente están marcando tanto fenómenos económicos, como laborales

La participación en GOSH 2017 tuvo un impacto crítico tanto en términos de formación de equipo como en la construcción de los objetivos del proyecto. Tanto Bernaldo como Pereyra Irujo tuvieron un rol clave en la escritura colaborativa de la hoja de ruta de la comunidad; Vuela fue diseñado, entre otras cosas, como una “prueba piloto” de las ideas del manifiesto GOSH.

Quizás por esa razón uno de los objetivos principales de Vuela es que su proceso de producción de conocimiento científico/tecnológico incluya actores que normalmente no participan en ámbitos de investigación, y en lo posible que a partir del proyecto interactúen con investigadores formales. Pero además, que los colaboradores y sus conocimientos sean respetados, estando en pie de igualdad. En una entrevista en 2019, Pereyra Irujo señala la influencia de las ideas de GOSH en el proyecto: “el roadmap y los objetivos de GOSH siempre los teníamos como guía […] a Vuela lo consideramos como enmarcado dentro de los objetivos de GOSH […] siempre lo pensamos así y creo que lo seguimos pensando así”.

7.4.3 Fabricando desde abajo

Una de las características más interesantes de Melipilla, a una hora de Santiago, es la composición de su comunidad. En los últimos años ha habido un crecimiento significativo de la inmigración en la ciudad, particularmente desde Haití. Los inmigrantes sólo hablan haitiano criollo, aunque algunos comienzan a aprender algunas palabras de español, y se asientan en las zonas menos privilegiadas de la ciudad. Las Juntas de Vecinos, que les brindan asistencia en los diversos barrios, son la principal vía de contacto entre Vuela y la comunidad.

Los talleres de Vuela en Melipilla congregaron en promedio 15-20 personas, en su mayoría inmigrantes haitianos pero también vecinos chilenos, miembros de la Junta Vecinal, miembros de la red GOSH que ocasionalmente participaban de los talleres. La convocatoria se realizaba a través de las Juntas Vecinales. Los participantes haitianos acudían a los talleres con una actitud de experimentar y socializar, mientras que los los participantes chilenos enviaban a sus niños o hijos adolescentes, de forma más esporádica. Antoni Pérez, técnico electrónico y uno de los colaboradores claves de Vuela, cuenta en una entrevista en 2020 que “muchos de los participantes que iban [a los talleres en Melipilla] eran mujeres amas de casa de la comunidad haitiana, otros eran jóvenes adolescentes que estaban curiosos, otros personas que tenían cualquier trabajo que no tenía nada que ver con eso”.

Desde el inicio en 2017, unas 175 personas participaron en total de los talleres de Vuela. A medida que fue avanzando, el proyecto fue incorporando nuevos actores: miembros de un hackerspace comunitario en Buenos Aires, activistas del software libre, académicos/activistas con interés en procesos de ciencia comunitaria. Al llegar a la etapa financiada por PROCISUR, la participación estuvo compuesta principalmente por investigadores de los diferentes institutos de tecnología agropecuaria que son parte del proyecto en Argentina, Brasil, Chile, Paraguay y Uruguay. Además de la colaboración presencial, Vuela mantiene una presencia virtual que atrae a diversos colaboradores en línea. Algunos de ellos incluyen al creador original del Flone, Lot Amorós; al Ing. en sistemas Guillermo Pereyra Irujo; la Ing. Alejandrina Egozcue, especialista argentina en drones, y miembros de la comunidad Mozilla que colaboraron en aspectos específicos.

En particular en el caso de las comunidades más vulnerables, uno de los objetivos de Vuela es lograr el empoderamiento de los participantes, que a través de la construcción de tecnología cambie el grado de confianza y la percepción sobre sí mismos. Bernaldo expande este concepto:

Que piensen sí, puedo participar, puedo compartir lo que aprendí, lo que fabriqué con otros, no soy el tonto o el inútil que me dijeron siempre que fui […] pasa mucho en estas comunidades marginales, toda la vida les han dicho que no saben hacer nada, que son unos tontos o que son unos flojos

Aunque la participación fue diversa en términos de perfiles, un denominador común a través de todas las etapas del proyecto fue la baja proporción de mujeres y personas no binarias presentes en los talleres. Replicando un patrón reconocido en ciencia y tecnología, las mujeres acudían a los talleres pero normalmente no se involucraban con las tareas técnicas. Bernaldo reflexiona sobre este patrón que reconocía en ella misma: “las mujeres en el taller no solíamos practicar de volar el drone”. Algunos de los problemas identificados incluían desde los comentarios despectivos de participantes varones sobre la habilidad de las participantes mujeres (“¡Cuidado, una mujer está manejando!”) hasta mujeres que dejaban de asistir a los talleres porque sus parientes varones no lo veían bien (“no quiero que venga mi novia, tiene que hacer otra cosa”). El equipo implementó un código de conducta y además de intentar discutir la problemática de género en las sesiones, los materiales de comunicación se diseñaron con perspectiva de género. Esto incluyó la elección de imágenes que no refuercen estereotipos de mujeres “mirando cómo otros hacen” sino que incluyen, por ejemplo, mujeres manejando drones; modificar el lenguaje para incluir el género femenino (“están invitadas e invitados a participar”). Aunque las barreras de género fueron fuertes, las mujeres también ocupaban otros roles, tanto o más relevantes, como se describe en próximas secciones.

7.4.4 Domingos de drones

Una de las preguntas que surgen primero cuando se piensa en Vuela es ¿para qué un drone? Producir, modificar, volar y tomar imágenes con un drone es una tarea compleja. Los drones comerciales son objetos costosos, por lo general frágiles. ¿Por qué no construir algo “más útil”, en especial si se trata de un proyecto con una comunidad vulnerable?

La pregunta tiene en principio dos respuestas. La más inmediata es que Pereyra Irujo tenía experiencia previa en drones a partir de su trabajo en INTA Balcarce, donde había conseguido un fondo que le permitió comprar un drone mucho antes de comenzar Vuela. La otra lectura tiene que ver con el rol de la tecnología como objeto de deseo. Un drone es un artefacto atractivo, brillante, que permite observar lo que nos rodea desde otros ángulos y hacer cosas, como volar, que normalmente no podemos hacer. Es un objeto caro, que salvo excepciones donde se lo usa para trabajar, la gente lo compra para divertirse y filmar videos, no se suele pensar como herramienta.

Lograr fabricar un objeto tan atractivo y que funcione, es emocionante, o como dice Bernaldo “llama el niño que tenemos adentro”. Volar un drone se parece mucho a jugar, para volarlo se utiliza un radiocontrol. En este punto vale preguntarse si una comunidad vulnerable debería estar condenada solo a construir artefactos productivos, o si también puede fabricar artefactos que sean simplemente deseables e inviten al juego. Se puede pensar que esto quizás tiene algo que ver con la atención que Vuela sostuvo en Melipilla durante meses, a pesar de que los talleres se realizaban los domingos, que la mayoría de los participantes no hablaban el idioma, que el centro vecinal no contaba con la mejor infraestructura y que los participantes podrían haber elegido quedarse descansando en su casa después de trabajar toda la semana.

Los participantes de los talleres en Melipilla se autodenominaron “la tripulación”. La experimentación y lo lúdico, tan cercanas al corazón hacker de la práctica del hardware abierto, están muy presentes en Vuela. El error o la equivocación es visto como algo altamente valioso, a documentar. Todo el proyecto se configura alrededor de la idea de trabajo colectivo colaborativo, la disminución de barreras a la participación y la democratización del espacio aéreo: “Vuela es una invitación a volar”.

Vuela: parte de “la tripulación”, participantes de los talleres en Melipilla (fuente: Instagram)

7.4.5 Construcción del problema

Más allá del uso experimental y lúdico, una de las propuestas de Vuela fue utilizar la fabricación del drone para cuestionar, por ejemplo, quién tiene derecho a utilizar el espacio aéreo. La propuesta del drone resulta atractiva porque permite pensar varios usos, por ejemplo problematizando de forma práctica quién puede volar y quién no dadas las restricciones para volar en espacios urbanos, entre otros. Bernaldo comenta cuál era el objetivo de estas discusiones:

No queríamos al final del proceso tener a un grupo de personas entusiasmados por los drones porque sí, obsesionados con volar para tomarse selfies aéreas

El financiamiento para los primeros talleres en Melipilla, provino de un evento denominado Knowledge, Culture, Ecologies (KCE) que ese año sucedió en Chile. KCE es un evento organizado por el Institute for Culture and Society (ICS) de la Western Sydney University, que reúne investigadores en estudios sociales de la tecnología, ecología política, antropología, geografía y las humanidades ambientales para pensar los diferentes aspectos de lo socio-técnico-ecológico. Ese fondo pequeño de KCE permitió realizar una serie de encuentros con los vecinos, fabricar el drone y poder volarlo durante el día del evento con los investigadores. El programa del evento muestra cuál era el objetivo de este taller:

La conversación girará en torno a la fabricación y mapeo con volantines, globos y flones durante los meses previos a KCE, y al proceso de definición de problemas y potencial de resolución de éstos al experimentar con tales tecnologías en el espacio público […] La idea es combinar el conocimiento local con los enfoques investigativos de los participantes de KCE.

El “precalentamiento” para poder construir el drone en la comunidad incluyó ejercicios con globos y otras tecnologías menos complejas. A medida que avanzaban los talleres y la copia del Flone, empezaron a surgir discusiones sobre qué se podría hacer con el drone. Bernaldo e Irujo rescatan el rol de dos colaboradores en particular en esas conversaciones, Daniela Muñoz (“una tipa muy, muy aguerrida, con mucha personalidad y muy segura de sí misma” como la describe Bernaldo), dirigenta de la junta de vecinos, y Juan Muñoz. Cuando llegó el día de la muestra en el evento de KCE, estas conversaciones se plantearon con los investigadores, y el problema comenzó a tomar forma. Pérez detalla cuál era la situación en Melipilla que los vecinos decidieron trabajar:

Se evaluaron varias cosas pero al final lo que pegó más fue hacer una vigilancia en una cantera que estaba cerca de una zona que estaba siendo habitada […] habían construido casas muy cerca de ese cerro y estaban haciendo extracciones de tierra, representando un peligro para las personas que viven cerca de ahí […] la alcaldía decía que pararon las obras pero la comunidad decía que se seguía extrayendo material de forma ilegal […] la idea era utilizar el drone para llevar un registro de la actividad con fotos aéreas

La formulación del problema iba a tener efectos directos sobre el diseño del drone, y sobre los talleres a futuro tanto con la comunidad como con otros actores. Pereyra Irujo comenta cómo el contacto con los investigadores de Knowledge, Culture, Ecologies, reorientó el proceso de construcción:

Lo que sacamos un poco en limpio fue una serie de limitaciones que tenía el drone como herramienta científica […] dijimos bueno si queremos que este hardware, que era un drone como para volarlo y tomar fotos nada más, fuera hardware científico, había que hacerle mejoras.

Poder formular la actividad comunitaria de los talleres en términos de problema de conocimiento brindó un punto de contacto entre lo que se hacía con los vecinos y otras actividades con actores diferentes. El financiamiento de Mozilla Science que permitió la realización de los talleres de esta nueva etapa post-KCE incluyó talleres en INTA Balcarce, en espacios comunitarios de Buenos Aires y en Mendoza, donde nadie tenía problemas con una cantera; el objetivo era mejorar la capacidad de producción de conocimiento a través del uso del artefacto. En esta instancia el discurso se movió más hacia el eje de la autonomía, la soberanía tecnológica y la posibilidad de contar con tecnología que se puede producir, adaptar y reparar.

Utilizar la apertura del drone como punto de partida para una conversación entre actores y usos muy diferentes facilitó que el proyecto pudiera seguir su curso a través de otras vías distintas a las imaginadas inicialmente, como los talleres institucionales financiados por PROCISUR. Pereyra Irujo comenta cómo Vuela llegó a trabajar con los institutos que integran PROCISUR:

escribí [en el llamado a proyectos] todas las ventajas del hardware científico abierto, la soberanía tecnológica, no depender de un drone chino con software yankee, que comprabas todos los drones y tres años después ya no había servicio técnico […] que estaría bueno tener una tecnología adaptada y adaptable a las condiciones de cada lugar y a los objetivos de investigación […] y lo compraron, sobre todo porque era más barato que salir a comprar drones, pero bueno tuvimos aprobado el financiamiento para hacer talleres en todos esos países.

7.4.6 Espacios que configuran la participación

Vuela brinda la oportunidad de rastrear, a lo largo de sus etapas, la influencia de los espacios en los modos y la diversidad de la participación. Quizás el factor más visible de esta relación se ve en cómo el desarrollo de talleres en la comunidad, en espacios que originalmente no están pensados para diseñar y construir artefactos, permitió que llegaran participantes inesperados. Pereyra Irujo comenta sobre esta situación:

Al principio nosotros dijimos bueno, encontramos que una de las ventajas de este proyecto del Flone es que eran españoles entonces todo estaba en castellano […] mejor, va a ser más fácil para todo el mundo porque está en castellano […] después Paz [Bernaldo] empezó a organizar los talleres en Melipilla… Y se llenó de haitianos que casi ni hablaban español [risas]

Loulou Jude fue uno de los haitianos que primero llegó a los talleres de Vuela en 2017. No faltó a ninguna de las sesiones siguientes, pasando a formar parte esencial del equipo. Pérez comenta sobre la participación de Jude:

[con Loulou] no había mucha comunicación verbal por la barrera del idioma […] al final, cuando se hizo el evento de Knowledge, Culture, Ecologies había un traductor de creole, y le preguntaron a Loulou de qué trabajaba, y él dijo que era electricista en Haití… ¡Y nosotros no teníamos idea!

Las estrategias utilizadas por el equipo para poder comunicarse fueron variadas: el armado de materiales audiovisuales con audios en criollo haitiano, la traducción por parte de aquellos haitianos que dominaban algo de español, la creación de la primera versión de la documentación del taller en criollo haitiano antes que en español. De esa forma, utilizando servicios automáticos de traducción y su propia experiencia, los organizadores eran los que tenían que verse en el papel de traductores al español. Pereyra Irujo retoma algunas de las escenas que se veían en los talleres: “estar dos personas en los talleres tratando de soldar una cosa y estar hablando, escribiendo en el teléfono y traduciendo con Google al mismo tiempo, eso pasó varias veces”.

El espacio comunitario impuso otro tipo de barreras que no estaban presentes en los espacios institucionales. La principal barrera a la participación sostenida en el tiempo, especialmente para los inmigrantes, era el carácter voluntario de la iniciativa. Bernaldo detalla algunos de estos problemas: “la precariedad en la que muchos viven, cambiando de ciudad constantemente en busca de empleo, con sueldos insuficientes y estrés, hace que involucrarse en un proyecto de largo plazo sea difícil”. Para participar, los vecinos de Melipilla debían resignar horas de descanso o trabajo; mientras que los investigadores que participaron de los talleres durante la etapa de PROCISUR lo hacían durante la jornada laboral. Las estrategias para que la comunidad participara incluyeron desde cubrir sus gastos de transporte hasta “amigarse” con la participación esporádica, ya sea de una sola vez o en un momento específico del taller si llegaban más tarde.

Una de las formas más visibles en que los espacios configuraron la participación fueron las asimetrías de infraestructura entre los centros vecinales donde faltaba acceso a computadoras, conexión estable a internet, o incluso lugares de reunión para trabajar; y los espacios de los centros de investigación o espacios de innovación. Las estrategias del proyecto incluyeron utilizar fondos para costear planes de internet móvil limitados que se usaban en los talleres, o colaborar con espacios que contaran con infraestructura apropiada, como el club de innovación en Balcarce.

Por otro lado, Vuela no cuenta con lugar propio, lo que hace que las reglas o la simbología de los espacios también configuren quién entra y quién no más que el propio proyecto. Bernaldo comenta por ejemplo, el caso de un taller desarrollado en un salón parroquial del barrio: “ciertos grupos no han sido tradicionalmente bienvenidos por la iglesia católica, grupos que nos habría encantado tener como colaboradores y que no se iban a sentir bienvenidos allí”.

Vuela: pruebas de los drones a campo (fuente: Instagram)

Los espacios determinaron por completo el diálogo entre actores académicos y no académicos. Uno de los objetivos de Vuela era fomentar este diálogo entre distintos tipos de saberes a partir de compartir talleres. A través del desarrollo de los talleres, los organizadores se dieron cuenta del rol clave de la elección del espacio, que excluía automáticamente a uno de los dos grupos. Los vecinos no acudían a los talleres organizados en la universidad o en institutos de investigación, y los investigadores no participaban de talleres fuera de los institutos. Pereyra Irujo ilustra este mecanismo con una anécdota:

Hacíamos una reunión acá en INTA y por más que invitamos a gente que no era de INTA, les decíamos vení, es libre para cualquiera, está abierto, venía una persona y porque conocía a alguno de acá o ya había venido antes […] hacía la reunión en el Club Social de Innovación de balcarce y le decía a la gente de INTA que fuera ahí, que iba a haber gente de la ciudad, gente común pero también podía ir la gente de INTA, y no iba nadie.

En general, los centros de investigación suelen ubicarse alejados de los barrios, y demandan costos de transporte para los participantes. Bernaldo comenta sobre esta división: “la periferia no va a ir al centro, o va al centro pero no a esto, va a ir a trabajar al centro o a buscar trabajo […] el tema territorial es importante”. La superposición ocurrió en ocasiones especiales, como la muestra final en el evento KCE donde los investigadores estaban invitados y dispuestos a asistir al taller que se desarrollaba en la cancha de fútbol del barrio.

La estrategia del proyecto para incorporar nuevos actores se basó principalmente en llevar los talleres cerca de donde vive gente que usualmente no participa de la producción de conocimiento y tecnología. La invitación al barrio también tenía otro propósito, más simbólico, de mostrar que también se puede hacer ciencia fuera de las instalaciones convencionales, como explica Bernaldo: “[nos interesaba] que científicos de instituciones tradicionales pasen de decir ‘esto solo se puede hacer en un laboratorio profesional’ a algo como ‘los laboratorios no son el único lugar, otras personas saben cosas que yo no’.

Otro de los espacios que Vuela supo aprovechar es el espacio online. El gran esfuerzo de facilitación se tradujo en documentación muy completa, en múltiples idiomas y sencilla de entender para no expertos. Para documentar los avances en los talleres, por lo general otros proyectos de hardware abierto utilizan software de control de versiones, que no resulta accesible para personas que recién comienzan y no están familiarizadas con la herramienta. En Vuela el circuito fue al revés: la documentación se hacía en los talleres en afiches, post-its o una computadora abierta con un documento de Word, y luego esto se abría a los expertos desde los facilitadores, que traducían los avances y los obstáculos detectados.

Esto permitió abrir un canal con los expertos, a partir de documentar las experiencias de los los talleres comunitarios en issues o notas en la plataforma GitHub. La misma estrategia de llevar el taller donde está la gente se aplicó en esto caso a llevar el taller donde están los expertos. Las discusiones en la plataforma muestran interacciones con el creador original del Flone, Lot Amorós, pero también con otros expertos como la Ing. Egozcue, productora agropecuaria que hace diez años fabrica y vuela sus propios drones. Su contribución en aspectos técnicos a través de la plataforma GitHub fue particularmente valiosa para el equipo. Bernaldo comenta sobre esta participación en particular:

ella empezó con los drones hace nueve años y sola, es productora agrícola […] no la querían aceptar en el club local de aeromodelismo, la miraban así pésimo […] se hizo experta con los drones porque es muy buena, los fabrica, los vuela y los utiliza para su trabajo […] ella era una de la gente con la que colaboramos en línea

7.4.7 Ciclos de adaptación

La primera etapa de copia del Flone dejó en evidencia que algunas modificaciones iban a ser necesarias para poder usar el drone. Al ser de bajo costo, Flone no cuenta con todos los sensores y estabilizadores que vienen incluidos en los drones comerciales; se maneja casi totalmente de forma manual y requiere de práctica y destreza poder volarlo sin estrellarlo. Las actividades prácticas se enfocaron en hacer que el drone no sólo fuera más amigable para el “tripulante”, sino que también pueda ser utilizado para obtener imágenes aéreas útiles para la investigación. Estos dos objetivos, accesibilidad y rigurosidad, orientan toda la actividad post-copia.

El control del vuelo del drone se hace a través de una aplicación para teléfono, conectado vía bluetooth. Bernaldo comenta por qué sin embargo, este método no era muy accesible: ”Tú generalmente pones el teléfono frente a tu cara, y si pones al teléfono frente a tu cara en el flone, se te venía el drone encima. La usabilidad era baja, la aplicación en fin, funcionaba, pero no era muy cómodo”. El control del drone a través del teléfono se reemplazó por un radiocontrol como los que se utilizan en aeromodelismo, más costoso pero de mayor alcance, más robusto y seguro para que todos puedan volarlo.

La calidad de las imágenes se volvió un punto clave: las vibraciones del drone hacían que el teléfono alterara el foco, produciendo resultados borrosas. En la etapa PROCISUR se tomó la decisión de cambiar el teléfono por una cámara de bolsillo. Utilizando software de código abierto estas cámaras se pueden programar para tomar una determinada cantidad de imágenes en un período de tiempo, además de permitir controlar otros parámetros como velocidad y exposición. Otras modificaciones realizadas por el equipo en los distintos talleres incluyen el agregado de motores más potentes y baterías de mayor capacidad, que permiten mayor tiempo de vuelo y cargar la cámara, más pesada que el anterior teléfono. El agregado de sensores GPS resultó fundamental no sólo para que sea más fácil el manejo, sino también para poder programar recorridos y asegurar repetibilidad.

Quizás la modificación que más evidencia la concepción del drone como herramienta científica sea que en los últimos talleres se incorporó la posibilidad de programar el artefacto para realizar recorridos y capturar imágenes de forma sistemática, utilizando una aplicación abierta con una interfaz gráfica similar a Google Maps. El criterio de diseño, siempre buscando la usabilidad por parte de no expertos, se puede observar especialmente en las interfaces, que más allá de ser físicas o digitales también son metodologías. Para evitar el problema de pedir coordenadas geográficas a las usuarias, un proceso que suele ser problemática, Vuela desarrolló un protocolo para el “tripulante”: La persona recorre todo el perímetro del área a relevar caminando con el teléfono, que guarda los puntos en un archivo. Ese mismo archivo se abre desde el software que controla el dron, muestra el recorrido hecho y a partir de ahí se programa que el drone haga el mismo recorrido. Una vez que el drone captura las imágenes, éstas se cargan en un software abierto que compone un mosaico del área, corrigiendo la perspectiva y posibles distorsiones.

Los drones se ensamblan y las partes se obtienen en un alto porcentaje con materiales y elementos locales, incluida la estructura de madera, los motores o los componentes genéricos. Como en la mayoría de los proyectos, las tarjetas controladoras deben importarse, en general desde China, casi siempre se compran vía plataformas online para ahorrar costos. Aunque son más económicas, tienen baja trazabilidad y muchas veces pueden fallar, como comenta Bernaldo:

algunas [tarjetas controladoras] funcionaban mal y otras funcionaban bien y no teníamos cómo distinguir […] si tú estás haciendo un taller y te compras 2 tarjetas controladoras, cruzas dedos de que va a funcionar una, pero si estás haciendo una cosa más de largo plazo es todo un problema

7.4.8 Un idioma común

La complejidad de los proyectos de hardware abierto para ciencia se refleja en sus múltiples capas de trabajo: diseño del artefacto, electrónica, trabajo con software, interpretación de datos. Más allá de estas especificidades, ciertas habilidades son transversales a casi todos los proyectos: saber usar una computadora, manejarse con comodidad para instalar un programa, descargar archivos, saber cómo buscar soluciones cuando algo falla.

En Vuela, los trabajos realizados en pos de fabricar, modificar, volar y apropiarse del dron, más allá de las distintas etapas, fueron siempre trabajos colectivos con un alto grado de facilitación. Quienes usan también fabrican: el aprendizaje se da sobre la marcha del mismo proyecto, siempre de forma colaborativa, con otros. En este sentido no sólo los participantes de los talleres atravesaron procesos de “domesticación” del drone en distintos niveles, sino que los facilitadores también formaron parte, anticipando y documentando los avances. Bernaldo comenta de qué forma atravesó ese proceso:

en un primer momento había cierta reticencia de mi parte, inconsciente […] aprendía la teoría de cómo era que se conectaba, qué cosa, pero no lo hacía […] pero luego tuve que empezar a meter mano porque no me quedaba otra, me necesitaban en el equipo

Uno de los aspectos más fuertes de la facilitación es la metodología de trabajo colaborativa, fuertemente anclada en el diseño iterativo. Como menciona Pérez, “si era por hacer el drone por nuestra cuenta en casa, hasta hubiera sido más rápido, pero no era la idea”. En ninguno de los talleres hubo expertos en drones; la metodología implicaba intentar fabricar el artefacto siguiendo la documentación disponible hasta donde se pudiera, fomentando que los participantes se ayuden entre pares. Siguiendo las prácticas de la comunidad de hardware abierto, cuando se encontraban con un obstáculo se buscaban en internet posibles soluciones, gente que tuviera problemas similares, y se ponían a prueba. Una vez implementadas las soluciones, se documentaban para que queden para próximos talleres, mejorando la documentación original.

Pérez fue uno de los colaboradores que llegó a Vuela casi por casualidad. Uno de sus amigos, estudiante en la Universidad Católica de Chile, había conocido al equipo en GOSH 2017. El día del primer taller en Melipilla su amigo se enfermó y le pidió si podía reemplazarlo; Pérez, entusiasta amateur de la electrónica, aceptó pensando que iba a un curso en formato convencional sobre cómo fabricar drones. Rápidamente se convirtió en un experto y punto de referencia para los demás participantes:

de las personas que estaban ahí yo era uno de los que tenía perfil de trabajar con tecnología […] Y aprendí un montón de cosas, como una forma de ver cómo sacar la estructura, o algo que estaba haciendo al revés y no me daba cuenta pero otra persona me ayudaba

Una de los objetivos más fuertes de las estrategias de facilitación es que los participantes pierdan el “miedo a romper”, entendiendo que el error es valioso y que el drone es un “rompecabezas” que se arma entre todos. De hecho el error es celebrado; en el evento KCE donde se debía demostrar el trabajo hecho en los talleres, el drone se salió de control y se estrelló, pero fue recuperado y reparado por la tripulación, que lo hizo volar de nuevo. Bernaldo reflexiona sobre esto: “me di cuenta que el proceso más interesante es aprender, equivocarse, seguir adelante y no frustrarse tanto, es una actitud”.

Cada vez que se muestra un nuevo componente en un taller, los participantes discuten qué creen que es, para qué sirve, lo vuelven una discusión ligera. Los facilitadores intentan que los participantes sean quienes más toquen los componentes, en lugar de guiar ellos mismos el proceso. Algunos ejemplos de facilitación incluyen hacer mover a los participantes alrededor de las mesas, rotando los roles, evitando el uso de pizarras, presentaciones u otros elementos que evoquen el contexto de aula escolar, fomentando en cambio instancias de colaboración entre pares. Las personas rotaban para que todos hicieran todo, y los organizadores garantizaban que todos estuvieran al tanto del estado de avance en todo momento. Bernaldo comenta que no siempre funcionaba: “Los niños del Club Social [de innovación, en Balcarce] seguían llamándonos “profesor” a pesar de que les insistíamos que no lo hicieran”. Pérez rescata en este sentido la relevancia de la distribución del espacio: “en la mesa todo estaba como distribuido, así hubiese un drone armado, siempre había piezas de otros y motores”.

Con una gran proporción de inmigrantes que no hablaban español durante los talleres de Melipilla, Vuela tuvo que recurrir a nuevas estrategias. En la primera etapa o copia del Flone la barrera del idioma se sorteó a través de imitación, viendo cómo el otro participante hace la tarea; Pereyra Irujo se grababa a sí mismo construyendo el drone, y el video servía para que los participantes es fueran guiando en la construcción. La limitación se volvió más fuerte en la etapa de mejora del artefacto, cuando se hizo necesario tener conversaciones sobre qué modificar, cómo, para qué.

En este sentido los procesos de formación de pares fueron una de las estrategias fundamentales para lograr que los participantes fabriquen el drone. La documentación de los talleres se entregaba a uno de los participantes, para que corrobore si la comprendía o no, y se pudieran hacer las modificaciones necesarias. Pero además los participantes se capacitaban entre ellos; Pérez comenta cómo se daban estos procesos en los talleres:

Siempre llegaba alguien nuevo y siempre había alguien que le explicaba o uno de ellos mismos, que ya se le había explicado, explicaba a otro que había llegado a veces el mismo día […] llegaba alguien bien temprano y se le explicaba cómo soldar, cómo probar el motor y después nosotros ya estábamos haciendo otra cosa y llegaba otra persona, y ese primero ya le explicaba al otro como soldar

Aprender a trabajar de forma colaborativa e iterativa, valorando y hasta buscando el error, implicó que los organizadores también realicen un trabajo arduo de reflexión, aprendiendo a partir de los diferentes talleres hasta perfeccionar su metodología. En todas las etapas el financiamiento disponible se utilizó principalmente para la compra de materiales y costear traslados y alojamiento para talleres, en ningún momento los fondos cubrieron el trabajo de facilitación u organización. Este esfuerzo, no remunerado, es vital para la existencia del proyecto como comenta Pereyra Irujo: “se necesita gente que esté todo el tiempo moviendo porque si no se cae, si no hay alguien pedaleando todo el tiempo, se frena”.

7.4.9 Construcción de capacidades

Quizás la capacidad observable más directamente sea la de haber producido, en la escala de tiempo amplia, un drone de código abierto capaz de ser utilizado en investigaciones científicas. Para llegar a ese resultado se construyó un proceso a veces sincrónico (talleres) y otras veces asincrónico que permitió a algunos participantes adquirir habilidades técnicas y a expertos técnicos adquirir habilidades colaborativas, proceso en el cual fue fundamental la facilitación y la formación de pares, como comenta Pereyra Irujo:

Siempre llegaba alguien nuevo y siempre había alguien como que le explicaba o uno de ellos mismos, que ya se le había explicado, explicaba a otro que había llegado a veces el mismo día.

Los participantes adquirieron nociones básicas de electrónica, diseño y manejo de software. La metodología iterativa y colaborativa permitió que adquieran estos conocimientos con barreras de acceso más bajas. Partiendo de la práctica, estos conocimientos específicos para la fabricación del drone pueden ser utilizados en próximos proyectos. Pérez comenta su propia experiencia con el drone:

creo que en general tuvimos una experiencia más profunda con el drone que la mayoría de las personas que lo compran, lo sacan de la caja y lo usan […] nosotros comenzamos desde la estructura, probar cómo funcionaban los motores, teníamos a veces errores de cómo giraban […] estoy más familiarizado con el aparato, por haberlo ayudado a construir y ver las piezas por parte.

Fuera de la comunidad, la modalidad intensiva de 4 días de los talleres en PROCISUR implica que personas sin conocimiento previo de electrónica ni programación desarrollen un OVLI desde cero. A través de la participación en el foro virtual, algunos de los equipos que armaron drones en aquellas sesiones siguen en contacto, compartiendo experiencias y soluciones a problemas que encuentran en el camino. Bernaldo comenta al respecto como “[en los talleres estaban] todos sorprendidos, nadie creía que era posible en 4 días gente que no tenía ninguna experiencia con drones, fabricar un drone y volarlo”.

Otro de los logros interesantes en este sentido fue poder sortear la falta de confianza y “miedo a romper” de los no expertos, presente en todos los participantes al inicio de los talleres, ya sean vecinos o investigadores. Pereyra Irujo tenía experiencia previa en trabajar con drones a partir de su trabajo en INTA Balcarce, había podido comprar un drone con el que mucho antes de comenzar Vuela había estado experimentando. Sin embargo, recuerda que “nunca le toqué un cablecito, nada, y eso que había funciones que no usamos y se podían sacar”. Adquirir el drone había implicado trámites de importación, aduana, costos de envío en dólares, era “un instrumento irremplazable”. Su relación con los OVLIs es diferente:

a los OVLIs que tengo acá dando vuelta les cambio cosas, los vuelo mucho más tranquilo, porque sé que si se cae y se parte una pata lo puedo arreglar, me animé a meterle mano y hacerle modificaciones y a decir “ah me gustaría que fuera más grande, vuele más tiempo, sea más liviano, tenga tal o cual característica”.

Quizás el ejemplo más claro de esta situación se encuentre en la capacidad alcanzada de reparar los instrumentos por cuenta propia. En este sentido, la demostración se impuso en uno de los talleres, donde la emoción de volar el drone recién armado hizo que dos participantes no dijeran nada a los facilitadores, omitieran los protocolos de seguridad y lo volaran (y estrellaran) inmediatamente, como comenta Bernaldo:

dos participantes fueron, agarraron el OVLI sin seguir ninguna de las instrucciones que les habíamos dicho y prendieron la radio, salió volando y lo estrellaron […] fue un choque terrible para todos, porque habían estado 2 días, todos construyéndolo […] Y luego drama, como que todo así en shock, ellos pensando que su jefe los iba a echar […] bueno, agarraron los restos, volvieron a la sala y en tres horas armaron otro nuevo porque llevamos materiales para hacer otro […] nosotros no metimos la mano ni les dijimos que hacer ni nada, ni miraron el manual, lo armaron todo en tres horas de apurados, de asustados […] y anduvo y voló y todo.

La capacidad de trabajar en grupos diversos y colaborar efectivamente es en alguna medida la base de todas las otras estrategias del proyecto. El equipo facilitador documenta la forma en que se trabaja, cómo se hacen los talleres, y han publicado lecciones aprendidas en formato blog. Los aspectos de colaboración también se materializan en el diseño. Pérez comenta cómo la inclusión del radio control, responde también a criterios de poder compartir: “tu puedes tener la misma radio configurada para distintos drones al mismo tiempo […] si tú no tenías plata para comprar una radio puedes compartirla con otra gente que la use con otros drones”.

El tiempo sostenido de facilitación de los talleres, las estrategias para lograr que más gente se sumara tanto online como offline, la interacción con contextos diferentes, constituyen aprendizajes que Pereyra Irujo aplica actualmente en nuevos proyectos: “en uno de nuestros proyectos nuevos contribuyo directamente en temas de diversidad e inclusión […] la teoría la saque de GOSH pero el aprendizaje real en la práctica lo saque de la experiencia con Vuela”.

Vuela: talleres para investigadores (fuente: Instagram)

7.4.10 Usos y no usos

La comunidad de Melipilla había definido una problemática a trabajar utilizando drones, y estaba fabricándolos; ¿cuáles son las razones detrás de que una vez terminados los talleres no los siguieron fabricando o volando? Una de las pistas puede venir por el lado de las mismas restricciones que Vuela cuestiona. Bernaldo arriesga que lo mismo que le pasó a ella le pasó al resto de la tripulación: incluso si quisiera o tuviera una motivación para volar uno de los drones, no puede porque en la ciudad existen restricciones de vuelo. La falta de práctica hace que las habilidades técnicas se vean un poco resentidas, y por ejemplo el manejo del software “se me ha olvidado porque no lo practico”, menciona Bernaldo.

La barrera del idioma, más allá de que pudo sortearse para la construcción del OVLI, impidió otras discusiones de mayor profundidad con los participantes. El equipo organizador piensa que una vinculación más profunda desde las problemáticas de la comunidad podría incentivar más el uso del drone o de otras tecnologías abiertas. El nivel de organización y motivación de la comunidad también es importante, más allá de los procesos de facilitación más o menos exitosos, como explica Bernaldo:

la cantera es importante para ellos, es un tema que está ahí pendiente, pero no es una cosa que nos están contaminando con un agroquímico y necesitan ponerle una demanda al Estado para poder pagarse la sala de operaciones y el tratamiento médico; no es una cosa así, que sea súper apremiante

Por otro lado, la versión de OVLI que permitiría técnicamente monitorear la cantera se obtuvo a partir de los talleres realizados con PROCISUR, donde Melipilla ya no participaba; como menciona Pereyra Irujo: “este drone de ahora de PROCISUR creo que sí tiene la capacidad de hacer eso [monitorear la actividad de la cantera] estaría bueno, en algún momento hacerlo, llevar de vuelta a Melipilla el último modelo”.

Quizás el punto más interesante sea cómo Vuela en la etapa en Melipilla logró habilitar un proceso local de discusión, y como el contacto con investigadores del encuentro KCE permitió transformar esa necesidad en un problema de conocimiento. Esas visiones, materializadas en un artefacto, atraviesan actores muy diferentes, con el hilo común de la apertura. Para Pereyra Irujo es simbólico que en el caso de Vuela, la dinámica de la extensión universitaria se trastocó: “un proyecto nacido en una comunidad ahora es utilizado en institutos de investigación científica alrededor del continente”.

<img/tablas/sintesis-vuela.png" style=“max-width: 100%;”>
Figura síntesis del caso Vuela (click para ampliar)

7.4.11 Síntesis del caso

Este capítulo presentó los resultados de analizar el primero de los casos comunitarios, que desarrolla sus actividades en Latinoamérica, a partir del análisis de entrevistas a dos de sus iniciadores y un colaborador clave, la observación participante y el análisis de documentación pública. El capítulo abre con un resumen general del caso, presentando las etapas del proyecto y las actividades realizadas.

Los resultados muestran que el modo de participación en el proyecto no es por división de tareas, sino que la coproducción lleva a borrar los límites entre desarrolladores, fabricantes y usuarias: todos hacen todo. Se muestran también las principales ideas que informan a Vuela, la influencia del manifiesto GOSH y las corrientes de descolonización del conocimiento; y cómo esto repercute en la importancia para Vuela de poder incluir a aquellos actores más vulnerables y marginalizados de los procesos de producción de ciencia y tecnología, ya sean inmigrantes, mujeres, o simplemente “no expertos”. La elección de fabricar un drone se analiza desde el punto de vista de lo simbólico en la tecnología, y en cómo esto resultó estratégico para garantizar la participación en el proyecto a partir de lo lúdico y la creatividad.

La construcción del problema de conocimiento se analizó a través de las diferentes etapas de proyecto, con especial atención en los procesos comunitarios donde la construcción colaborativa de tecnología permitió disparar una discusión local que se cimentó a partir del contacto con investigadores de las ciencias sociales. El rol de los espacios en la participación a lo largo del proyecto mostró las diferencias entre institutos de investigación y espacios comunitarios no pensados para la producción de conocimiento. Los espacios influyen tanto por cuestiones prácticas de acceso como también simbólicas que impiden a los investigadores ir al barrio y a la comunidad ir a las instituciones. Llevar las actividades a espacios alejados de la producción formal de conocimiento derivó en una mayor diversidad y flexibilidad en la participación de no expertos.

La construcción del artefacto implicó una metodología incremental para la mejora, basada en la apertura y la colaboración. Las adaptaciones se hicieron en base a criterios de rigurosidad científica y de usabilidad, incluyendo no sólo el desarrollo de adaptaciones materiales sino también la construcción de metodologías y protocolos para bajar las barreras de acceso. Estas actividades requieren necesariamente de habilidades para la colaboración, y principalmente de estrategias de formación de pares que permitieron construir un idioma en común con los participantes en espacios muy diversos.

El análisis de capacidades permite observar que el proyecto habilitó la construcción de una herramienta abierta para la investigación científica que puede ser modificada, reparada y producida localmente; que esto demandó la construcción de capacidades técnicas en participantes tradicionalmente relegados de la ciencia y tecnología, y que la capacidad de colaboración entre participantes disímiles a través de un idioma común fue clave para este proceso. Por otra parte, como consecuencia de este recorrido los participantes en distintos espacios ganaron confianza en su relación con los artefactos, logrando repararlos sin problemas y perdiendo en parte el “miedo a la tecnología”. Finalmente, el no uso actual del drone en la comunidad de Melipilla evidencia algunos elementos clave para la producción de conocimiento en ámbitos comunitarios, siendo la motivación inicial de los participantes uno de los más significativos.

7.5 Proyecto KossamTor

Bloque: Proyectos comunitarios

7.5.1 Introducción al caso

Kossamtor es un proyecto surgido en 2017 en el Mboa Lab, un makerspace en Yaoundé, Camerún. Su objetivo es utilizar incubadoras de bajo costo, fabricadas en el makerspace, para que las mujeres de la comunidad rural aledaña puedan producir y comercializar yogur de forma segura. El nombre del proyecto está compuesto por una combinación de las palabras Kossam (un tipo de yogur muy popular en Camerún) y el sufijo -tor, por “incubator”.

Mboa Lab surge como espacio promovido por Thomas Mboa, actualmente estudiante doctoral en Canadá y referente de ciencia abierta en la región. En una reunión en 2015 de la red de investigadores “ciencia abierta y colaborativa para el desarrollo” (OCSDnet), Mboa entra en contacto con el mundo de la ciencia “do it yourself”. A partir de ello, cuando vuelve a Camerún decide fundar el Mboa Lab como espacio que promueve el desarrollo de herramientas abiertas para la ciencia, en particular orientado a la biología sintética.

A inicios de 2017 Mboa participó del segundo encuentro global de la red GOSH en Chile, donde conoció a Jorge Appiah, con quien fundaría AfricaOSH en 2018. En esa reunión conoció también a Jenny Molloy, fundadora de GOSH e investigadora de la Universidad de Cambridge, quien luego sería socia del Mboa Lab a través del proyecto transnacional Open Bioeconomy Lab. También en GOSH conoció a André Chagas, investigador en neurociencias, quien a fines de 2017 lideró un programa online de mentoreo de proyectos de hardware para ciencia, auspiciado por la Fundación Mozilla, llamado “BFOSH”.

En 2017 BFOSH abrió una convocatoria a proyectos de hardware abierto para ciencia que quisieran participar de un programa de mentoreo con especialistas de distintas áreas. La idea principal del programa era que los desarrollos se realicen teniendo en cuenta la disponibilidad de materiales locales, y se documenten de forma tal que luego otras personas pudieran reutilizar lo aprendido.

Mboa y su equipo presentaron el proyecto de realizar una incubadora sencilla, con materiales disponibles en Yaoundé. El proyecto resultó seleccionado, y BFOSH otorgó 750 dólares para la compra de materiales. Durante las semanas de mentoreo el equipo se reunió con diferentes especialistas, entre ellos quien suscribe, que guiaron el proceso de fabricación colaborativa y documentación.

Una vez terminado el programa BFOSH, parte del equipo en el MboaLab sugirió utilizar la incubadora para un proyecto que incluyera a la comunidad de mujeres que viven en la zona aledaña al makerspace. Esto implicó que se realizaran modificaciones en el artefacto que permitieron controlar pH además de temperatura, y se desarrollen talleres para capacitar a las mujeres en el uso y fabricación del artefacto.

Actualmente MboaLab es uno de los espacios más relevantes en términos de innovación social y ciencia abierta en Camerún. Es socio del proyecto Open Bioeconomy Lab, que produce equipos y enzimas abiertas para investigación en biología sintética, forma parte de la red Global Innovation Gathering que reúne diversas comunidades de innovación de base, sus miembros asisten al MIT Bio Summit y está en contacto con institutos de investigación tanto en ciencia abierta como en proyectos de desarrollo a nivel global.

KossamTor: incubadora en funcionamiento

7.5.2 Hardware abierto y desarrollo

La idea original detrás del proyecto de fabricar incubadoras estaba anclada en la enorme distancia que existe entre la teoría y la práctica en las universidades en Camerún. Mboa estudió biología en la universidad de Yaoundé, donde las prácticas de laboratorio eran casi inexistentes. Esto hace que los egresados casi no cuenten con experiencia de cómo es el trabajo real, en el día a día. Mboa comenta su propia experiencia: “la idea al principio era construir una incubadora de bajo costo que se utilizara en un laboratorio de biología en Camerún para llenar ese vacío entre la teoría y la práctica […] muchos laboratorios de nuestras universidades locales, como la Universidad de Yaundé I, no tienen este equipo”.

Más allá del impacto en la academia, la idea de la democratización de los equipos necesarios para hacer ciencia está muy presente en el discurso de Mboa, quien es un miembro activo de la comunidad de ciencia abierta en general y GOSH en particular. Su trabajo doctoral trata el tema de la mirada colonialista de la ciencia y en particular la ciencia abierta en África, con una mirada desde la justicia cognitiva. En una entrevista en 2018 Mboa explica qué significa esto en la práctica: “cuando se discute qué hacer con la gente no importa si vienes de África, si eres académico o no, si eres técnico; lo más importante son las ideas”.

En este marco, el uso de herramientas científicas abiertas se concibe como autonomía y autodeterminación de las comunidades para poder resolver sus propios problemas utilizando tecnología, siempre desde una perspectiva situada. Mboa explica qué significa esto para él en el contexto africano:

El problema es que en el extranjero, África parece ser sólo la parte inglesa de África […] estamos pasando por alto una parte muy grande de lo que África puede darnos: tienes el África árabe, tienes el África francófona, nuestro conocimiento es igual […] tenemos que apropiarnos, contextualizar y ver lo que es bueno para nosotros o lo que no es bueno para nosotros, y cómo podemos adaptarlo.

El MboaLab se encuentra ubicado en el predio contiguo a una escuela, en el barrio de Mbakomo. En las zonas aledañas al espacio vive una comunidad pequeña de mujeres, algunas nativas del lugar y otras llegadas de las zonas del noroeste y suroeste del país en calidad de refugiadas (denominadas IDP, por las siglas en inglés de “internally displaced people”) tras las crisis en la región. En una entrevista en 2020 Nadine Mowoh, microbióloga del MboaLab, describe algunos de los problemas que viven estas mujeres:

los desplazados internos (IDPs) luchan por adaptarse, buscando un medio de vida se dedican a diversas actividades pero apenas ganan dinero suficiente para sostenerse […] hablan un idioma diferente (inglés) de los nativos de Mbakomo (francés), por lo general es difícil para ellos integrarse.

El grupo de mujeres habita en el contexto mayor de una población en los suburbios de la capital, donde los problemas de seguridad alimentaria son frecuentes especialmente en la población más vulnerable, como detalla Lenshina Agbor en una entrevista en 2020, una de las microbiólogas que participó en las primeras etapas del proyecto: “la comunidad se caracteriza por una población distribuida de forma desigual, con la mayoría compuesta por niños y ancianos […] viven vidas muy sencillas”.

A partir de la participación de Agbor y luego de Mowoh y Nelly Mengue, también microbióloga del espacio, en el proyecto BFOSH, el eje de problematización del proyecto se movió desde fabricar incubadoras para proveer instancias prácticas de aprendizaje en las universidades, hacia KossamTor: fabricar incubadoras para contribuir a la seguridad alimentaria de la comunidad. Agbor comenta por qué eligieron el kossam como objeto de trabajo:

El kossam es muy caro en Camerún […] el proyecto ha reducido el costo de la compra de yogur …] Ya no tienen que asignar el consumo de yogur a los niños, ahora pueden gastar sólo una fracción de su dinero en recursos para producir más yogur para todos

Las tres microbiólogas señalan que como práctica en la vida cotidiana ellas producen kossam para consumo propio, y que a partir de esa experiencia cuando vieron que en el MboaLab estaban fabricando una incubadora automáticamente pensaron en la posibilidad de utilizarla para fabricar kossam. Mowoh además señala que la incubadora presenta ventajas frente al método tradicional: “produce el yogur más rápido que los métodos locales, de 10 a 12 horas en comparación con 14 horas, y la calidad del producto estará garantizada”.

En el contexto de una cultura predominantemente patriarcal, las mujeres de en situaciones vulnerables suelen no contar con los mínimos ingresos necesarios para garantizar la alimentación de su familia. Por otro lado, aunque mucha gente fabrica, comercializa y consume su propio kossam, lo hace de manera irregular, sin controles que verifiquen que es un producto seguro. Mboa explica que KossamTor es una alternativa de seguridad alimentaria para que estas mujeres puedan producir alimentos de calidad comprobada y generar ingresos a partir de la comercialización del producto: “el principal problema que queremos abordar con KossamTor es permitir a la gente obtener un pequeño ingreso […] mediante la venta de yogur que saben que es un yogur seguro”.

7.5.3 Diálogos interdisciplinarios

La participación de MboaLab como socio en la red del Open Bioeconomy Lab le permite contar con dos biólogos empleados permanentes en el makerspace. A través de la colaboración con universidades el espacio aloja además a pasantes de la universidad pública, que colaboran con los proyectos en curso.

Los voluntarios no son remunerados, pero a veces, cuando tenemos algunos proyectos, también podemos darles algo de dinero […] Nuestro lema en el laboratorio es “el valor social primero, la habilidad después” porque cuando tienes valor social puedes aprender fácilmente habilidades, puedes aprender fácilmente de los demás

La composición del equipo se fue modificando a través de las diferentes etapas del proyecto. Durante la participación en BFOSH, el grupo estuvo compuesto por Thomas Mboa, fundador del espacio, Marius Tchakounang, ingeniero especialista en sistemas embebidos e internet de las cosas, Agbor, MSc en biología molecular, e Yves Obame, colaborador técnico en MboaLab. Poco tiempo después Agbor partió a Inglaterra a realizar su doctorado, y se sumaron Mowoh y Mengue, con la idea de desarrollar el proyecto KossamTor. Mengue comenta que el trabajo interdisciplinario no es fácil pero tiene ventajas: “trabajar en Mboalab es difícil pero gratificante porque nos permite aprender de los demás, convivir y compartir nuestras diferentes experiencias.”.

Agbor comenta que una de sus tareas era el contacto con la comunidad: “hicimos una evaluación de los hábitos de los locales y una de las cosas que se destacaron fue su preferencia por los productos lácteos, especialmente el yogur”. Mowoh se sumó al proyecto en rol de control de calidad; su formación como microbióloga le permitió comprender los procesos que suceden en la incubadora, y evaluar si el producto era seguro para consumo. Pero también funciona como uno de los puntos de contacto con la comunidad y de difusión del proyecto, organizando los talleres de uso y fabricación de la incubadora:

Mis tareas específicas consistieron en la divulgación con las mujeres locales de la comunidad […] organizar talleres con ellas sobre la producción de yogur usando el Kossamtor y [asistir] a una conferencia internacional para demostrar cómo el Kossamtor puede ser usado para producir yogur localmente.

En todo el desarrollo del proyecto fue clave contar con un equipo diverso. Por un lado, los ingenieros se enfocaron en el desarrollo de la incubadora y luego su adaptación. Las micro biólogas por su parte realizaron las pruebas de producción de kossam, que finalmente resultó más rápida que la tradicional. Sin embargo, Mboa les pedía a todos los participantes que estuvieran al tanto de todas las tareas del proyecto a medida que avanzaba:

tanto si eres ingeniero como microbiólogo, tienes que asistir al taller porque si tienes que explicar a alguien fuera del laboratorio cómo funciona Kossamtor, tienes que ser capaz de explicar desde el principio hasta el final. Me refiero a la historia de Kossamtor, su construcción y la producción del yogur.

A diferencia de otros proyectos de hardware abierto, la proporción de mujeres en Kossamtor es casi del 50%. Sin embargo, al analizar cómo se distribuye el equipo a lo largo de las distintas etapas del proyecto, se puede observar un patrón de división de tareas y género. Tanto Mowoh como Mengue participaron sólo de las tareas finales de testeo de la incubadora para realizar kossam, y del desarrollo de talleres con la comunidad. Agbor participó brevemente de la etapa de fabricación antes de emigrar; ni Mowoh ni Mengue participaron de la elección del diseño, ni de su fabricación, que fue una etapa principalmente liderada por los ingenieros y técnicos del proyecto. Mboa señala que puede ver un patrón más allá de las preferencias individuales: “las partes técnicas de este proyecto están masculinizadas”.

7.5.4 Adaptando un diseño probado

MboaLab comienza a trabajar en mayo de 2017 en la fabricación de la incubadora dentro del programa BFOSH. En el programa los participantes podían desarrollar nuevos diseños o adaptar alguno existente, sin embargo en el espíritu de “no reinventar la rueda” se promovía que los participantes hicieran una revisión exhaustiva de los diseños disponibles para el uso de interés19.

KossamTor: un día de trabajo en el MboaLab

En un principio, con el objetivo de proveer de instrumental a las universidades locales, el equipo quería construir una incubadora-agitadora 2 en 1 para laboratorios de biología. Después de discutir esta idea con los mentores del programa, terminó siendo descartada dada su complejidad para un equipo que trabajaba por primera vez en desarrollo de hardware. El objetivo de fabricar solo la incubadora resultó más abordable: las incubadoras “do it yourself” son muy populares en el hardware científico abierto, existiendo un volumen significativo de desarrollos documentados dentro de la comunidad, en particular de biohacking. En los laboratorios caseros siempre hace falta una incubadora, que suele ser de los primeros artefactos que los aficionados intentan fabricar.

Uno de los requerimientos del programa BFOSH era hacer una revisión de diseños disponibles. Tras esta revisión el equipo se decidió por un diseño sencillo, bien documentado y probado publicado por la BioHack Academy20, una iniciativa de la fundación holandesa Waag Society, combinándolo con elementos de una incubadora publicada por el desafío Biomakers, una iniciativa de la Universidad de Cambridge, como comenta Mboa: “no hemos hecho el diseño desde cero […] Es un fork de la primera versión de la incubadora DIY que construimos."

Una vez elegido el diseño, el equipo realizó una pequeña investigación sobre qué materiales eran los mejores para utilizar como caja de la incubadora, que sintetizaron en pros y contras. Entre las opciones evaluaron cajas de cartón corrugado, acrílico, madera, y finalmente la opción que resultó elegida, una conservadora como las que se utilizan para hacer un picnic o se llevan a la playa. Este tipo de decisiones se documentaron en el repositorio de GitHub del proyecto21. Mowoh comenta por qué es importante para el equipo elegir bien los materiales de la incubadora:

una herramienta que pudiera ser fácilmente utilizada por la población local considerando que los materiales para construirla son baratos, y pudiera ser fácilmente obtenida en las tiendas locales, o incluso hacer uso de algunos viejos contenedores abandonados, por ejemplo, conservadoras, baldes, etc., lo que hace que tenga un corto plazo de construcción y entrega.

El dinero otorgado por BFOSH fue utilizado para comprar la lista de materiales incluyendo la electrónica, que comenzaron a ensamblarse durante la semana cuatro del programa. Agbor comenta que la parte más difícil del desarrollo no fue el hardware o la electrónica, sino el software: “fue un desafío hacer que el código funcionaran y que la unidad de control mostrara exactamente lo que estaba pasando […] más tarde, descubrimos que había un error que se arregló mediante la revisión del código”. La falta de expertise en programación hizo que el equipo colabore con el FabLab Ongola, también en Yaoundé, para ajustar el código de la tarjeta Arduino que permite controlar la incubadora.

Este primer diseño permitía a la usuaria definir una temperatura entre 20 y 80 grados centígrados y mantenerla constante, utilizando una placa Arduino UNO o similar, a un costo aproximado de 80 euros. Tres meses después del inicio del programa, el equipo presentó sus avances en la videollamada pública; poco después conseguirían su primer cliente en la Universidad Católica de Yaoundé. Agbor comenta sobre esto: “[las universidades] tienen sus propias versiones de la incubadora ahí en sus laboratorios y haciendo los mismos trabajos que las marcas comerciales caras ahí afuera”.

KossamTor: parte del equipo desarrollador, en el MboaLab

7.5.5 Re-orientando el uso

Fue a partir de este diseño que Agbor pensó la idea de utilizar la incubadora para producir kossam, que luego desarrollaron en colaboración Mowoh y Mengue con el resto del equipo. En primer lugar realizaron una pequeña encuesta para ver qué productos eran más consumidos por la comunidad. Al ver que el kossam era muy popular, durante esta etapa el trabajo fue principalmente de adaptación de la incubadora que habían construido para que pudiera servir para la fabricación del yogur. Mowoh cuenta qué modificaciones fueron necesarias en el artefacto:

la posibilidad de utilizar el kossamtor para producir yogur con un pH particular que se adapte a las necesidades de una serie de personas (niños, adultos, personas con problemas digestivos, etc.) […] esto sólo podría lograrse mediante la incorporación de un medidor de pH que determine el pH del yogur en cada momento del proceso de fermentación.

Esta nueva necesidad hizo que el equipo investigue cómo agregar un controlador de pH al diseño, a fin de producir las dos variantes en producción actualmente: para adultos, con un pH de 3.5 y para niños, más suave, con un pH 4.2. Mboa comenta que además esto trae otros beneficios: “al permitirles controlar el pH de una manera muy simple pueden prevenir muchas de las enfermedades relacionadas con los alimentos y los productos lácteos”.

Durante este proceso las investigadoras estaban en contacto con la comunidad de mujeres, a quienes llegaron a través del jefe local. Fue a esta persona a quien transmitieron los detalles del proyecto, los beneficios potenciales para la comunidad, y quien les garantizó acceso a las participantes, como relata Mowoh: “hicimos una visita al jefe de la comunidad y le explicamos el proyecto […] el jefe lo anunció a la comunidad local a través de reuniones locales (njangi) [y también] envió anuncios en las iglesias”.

Las principales usuarias de la incubadora son las mujeres de la comunidad, que no la compran directamente sino que obtienen una cuando consiguen algunos de los materiales iniciales, que acercan al equipo técnico del MboaLab, donde las ayudan en la construcción. Para que las mujeres puedan utilizar la incubadora correctamente, Mowoh y Mengue realizan talleres en el Mboa Lab donde se demuestra tanto la fabricación del artefacto como los principios de la fabricación de los distintos tipos de kossam. Los talleres además brindan la posibilidad a las mujeres de compartir sus propias experiencias en la fabricación de yogur, y de observar de primera mano el proceso, como relata Mowoh:

Se inicia una demostración del proceso de producción adquiriendo los ingredientes en las tiendas locales, se toman otros materiales de los hogares y el proceso de producción comienza con una persona que realiza cada paso del proceso junto a la otra, mano a mano

Aunque las mujeres utilizan frecuentemente la incubadora, existen algunos problemas relacionados al uso que no pudieron ser detectados en principio por el equipo del Mboa Lab, como por ejemplo los frecuentes cortes de electricidad en la comunidad, o el tamaño de la caja de la incubadora y el volumen de producción pequeño. Estos elementos que ya se están trabajando en un nuevo diseño, tienen implicancias para las usuarias que Mowoh detalla de la siguiente manera:

los frecuentes cortes de energía en esta comunidad […] el hecho de que solo algunas personas lo poseen entonces no se usa simultáneamente […] la incapacidad del Kossamtor para permitir la producción de yogur a gran escala debido al tamaño de la conservadora […] esto dificulta su uso

Otros desafíos que surgieron en el proyecto tienen que ver con el grado de alfabetización de las usuarias, que dificulta la transmisión de algunos conceptos, o que algunas no hablan el idioma, prosigue Mowoh:

[las mujeres] apenas podían entender la ciencia que había detrás de la producción de yogur o tener conocimientos electromecánicos para construir independientemente sus propias incubadoras […] algunas tenían comprensión de un idioma y otras de otro […] hubo que dedicar mucho tiempo a aclarar algunos puntos y hacer que se entendieran entre sí mientras trabajaban en grupo.

Una de las claves para garantizar que el proyecto fuera adoptado fue la de realizar videos donde se explican los conceptos básicos, o como comenta Mboa: “El concepto de pH era difícil para las personas que no han ido a la escuela, así que usamos ejemplos simples para explicar”.

Construir la incubadora, por otro lado, demanda algunas nociones básicas de electrónica para entender cómo están conectados los módulos y poder repararla llegado el caso. Además demanda de algunas habilidades básicas de programación, para poder configurar la placa Arduino que controla el artefacto y poder solucionar problemas que pueden aparecer. Mboa señala que tratan de facilitar toda la actividad desde el espacio:

Lo que estamos haciendo es mayormente un proyecto comunitario, si pones algunos requisitos, no ayudas a mucha gente […] tienes que aceptar a todo el que quiera un lugar en el proyecto para que pueda aprender y obtener capacidades con el tiempo.

En este sentido, Mboa resalta lo importante que resulta para él no contar con una afiliación a una universidad o una fundación que fuerce sus propias reglas en el espacio. Esta flexibilidad le permite al equipo formar parte de proyectos y luego modificarlos de acuerdo a sus propias motivaciones, como en el caso de KossamTor: “tenemos mucha libertad para movernos como queramos […] no necesitamos la aprobación de nadie para cambiar los planes, en nuestro caso eso es muy fácil de manejar.”

KossamTor: electrónica necesaria para construir la incubadora

7.5.6 Construcción de capacidades

La capacidad más nombrada por los participantes del proyecto es la de poder fabricar el equipo de forma local y más accesible. En un primer momento se mencionaba como motivación que la falta de equipamiento en las universidades del país es alta, y que en general a nivel región el problema de los equipos sin reparación es significativo. En un segundo momento del proyecto, a partir de la reorientación del uso, las capacidades mencionadas como deseables cambiaron. Agbor por ejemplo expresa: “No puedo evitar imaginar el lanzamiento de un proyecto "1 escuela, 1 incubadora", que se centrará en la utilización de las documentaciones para construir incubadoras para cada escuela secundaria en el Camerún”.

En este sentido, la capacidad de producir una incubadora de forma local, con insumos accesibles y disponibles en Yaoundé se vio lograda. A partir del proyecto el makerspace identificó dos proveedores locales (DBL electronique y Megatec Electronic) de donde obtener la mayoría de los insumos necesarios. El contar con estos recursos locales hace que el MboaLab pueda también ofrecer el servicio de reparación de las incubadoras.

La colaboración con otros espacios permitió suplir las habilidades con las que no contaba el espacio, como la de programar o modificar el programa de la placa Arduino. A partir del proyecto se acercaron representantes de la Universidad Católica de Yaoundé y de la Universidad Pública, a quienes el espacio ya vendió tres incubadoras. El Hive Biolab, espacio comunitario en Ghana, ya replicó el diseño de la incubadora de forma exitosa.

El grupo pudo también adaptar un diseño externo a las necesidades propias. A partir de haber construido la incubadora, que funciona correctamente en cuanto a temperatura, tomó un tiempo adicional pero el equipo pudo adaptarla para poder también medir pH. Este diseño es propio de KossamTor, y el grupo piensa documentarlo y ponerlo a disponibilidad pronto para otras comunidades.

La capacidad de compartir el diseño original de kossamtor con el resto de la comunidad global en línea es limitado. La plataforma utilizada por el programa BFOSH, GitHub, es poco amigable para quienes no poseen una formación o experiencia en software, que son la mayoría en el makerspace. Por otro lado, la documentación en general se realiza en inglés, que no es el idioma dominado por la mayoría de los participantes (que hablan francés y otros idiomas locales). Un breve análisis de la historia del repositorio donde se encuentra la documentación de la incubadora muestra cómo los principales colaboradores son Mboa y Molloy, que probablemente mejoró la documentación en una de sus visitas al espacio. Los issues utilizados para discutir decisiones o problemas en el diseño no cuentan con actividad.

Una de las capacidades más mencionadas es la de poder sostener la iniciativa en el tiempo. KossamTor no significa solo una oportunidad para que las mujeres puedan obtener ingresos; a partir del proyecto el MboaLab también las produce para la venta a universidades e institutos de investigación.

<img/tablas/sintesis-kt.png" style=“max-width: 100%;”>
Figura síntesis del caso KossamTor (click para ampliar)

7.5.7 Síntesis del caso

Este capítulo presentó los resultados de analizar el segundo de los casos comunitarios, que desarrolla sus actividades en África, a partir del análisis de entrevistas al organizador y a cuatro de sus colaboradoras, la observación participante a partir de ser mentora del proyecto en el programa BFOSH y el análisis de documentación pública. El capítulo abre con un resumen general del caso, presentando las etapas del proyecto y las actividades realizadas.

Los resultados muestran que el modo de participación en el proyecto es la división de tareas, y que existe un patrón de género que masculiniza las tareas técnicas y orienta a las mujeres a las tareas de contacto con la comunidad y adaptación al uso. Se muestran además las ideas de justicia cognitivas que informan al proyecto, y las estrategias puestas en marcha para intencionalmente borrar los límites entre expertise en el grupo desarrollador.

La fabricación del artefacto se realiza a partir de la adaptación de diseños altamente probados, a través de la selección de materiales adecuados al uso específico del artefacto y la sencillez de implementación de acuerdo a las capacidades técnicas disponibles localmente. Los resultados muestran también como a partir de una reorientación del problema a trabajar, desde incubadoras para laboratorio hacia incubadoras para fabricar kossam, los trabajos de los colaboradores se reconfiguraron para la nueva tarea.

El nuevo uso implicó para el espacio entrar en contacto con la comunidad de mujeres a través de distintas estructuras sociales de la zona, y desarrollar talleres para poder contar de qué manera utilizar y ensamblar los artefactos. Esto derivó en un esfuerzo de comunicación y “traducción” por parte del equipo desarrollador para sobrepasar barreras de idioma y grados de alfabetización.

El análisis de capacidades permite observar que el proyecto permitió la construcción de una herramienta abierta reparable, adaptable y fabricada con materiales locales capaz de dar respuesta a una necesidad urgente. Pero que además habilitó una reconfiguración de los roles dentro del makerspace a fin de lograr los objetivos esperados, recurriendo a la colaboración con otros espacios para sobrepasar faltas de expertise. Finalmente, la iniciativa logra sostenerse en el tiempo gracias a la comercialización de los artefactos, que financian la actividad comunitaria del espacio.

7.6 Resumen del capítulo

Este capítulo introdujo los resultados de cuatro estudios de caso sobre proyectos de hardware científico abierto en contextos académicos y comunitarios de la periferia. Las dimensiones analizadas incluyen el contexto general de inserción, la diversidad y modos de la participación, los procesos de domesticación tecnológica y el desarrollo de capacidades.

Los resultados de los estudios de caso comprenden:

  • identificación de motivaciones, visiones y estrategias;
  • identificación de grupos incluidos, excluidos y la distinción de modos de participación y sus implicancias;
  • descripción de patrones de trabajo que permiten a los proyectos desarrollar dispositivos apropiados a cada contexto;
  • identificación de capacidades esperadas, alcanzadas y no alcanzadas en cada caso;
  • Identificación de barreras que impiden alcanzar las capacidades esperadas y cómo estas afectan a los participantes de forma diferencial.

En el próximo capítulo se presenta el análisis comparativo de estas experiencias dentro del contexto comunitario y académico respectivamente, para luego plantear el análisis comparativo global de todos los proyectos presentados.