En este capítulo vamos a hablar sobre Hackathones, a partir de un texto que preparé hace tiempo y que llevaba demasiado tiempo circulando entre buzones particulares. Este texto está planteado desde el punto de vista propio, como persona que organiza eventos ocasionalmente y dinamiza comunidades, pero creo que puede aplicarse a muchos más perfiles.

Como novedad esta vez he relatado cómo me gustaría que fueran estos eventos y apuntado a algunas alternativas en cuanto al formato. Espero poder dar formato en breve también a esta parte y publicarlo por aquí también.

Comentarios y sugerencias son siempre bienvenidas en [Facebook][1] y Twitter!

La dinámica de estos eventos suele consistir en una convocatoria abierta para que emprendedores, diseñadores, hackers, makers, gente de negocios y marketing se junten por equipos para crear soluciones distintas para resolver un problema importante en un plazo de 24 o 48 horas. Al acabar el plazo, los equipos realizan sus presentaciones siguiendo un modelo conocido como elevator pitch que resumen los puntos más importante en 3-5 minutos. Alternativamente se puede finalizar el proceso presentando un prototipo que muestre la idea de una forma aplicada.

Expondré a continuación seis razones por las que no apoyo los hackathones: * No son multidisciplinares: Uno de los principales reclamos de estos eventos suele ser la participación de perfiles muy diversos que te aporten otros puntos de vista complementarios. La realidad es que en la mayoría de hackathones el público asistente es básicamente el mismo: programadores jóvenes sin cargas familiares que pueden invertir todo el fin de semana picando código sin parar. Aunque la idea es encontrarse con gente nueva, muchos de los participantes repiten y repiten, sin estar demasiado implicados con el problema a resolver. El papel del resto de participantes en el equipo suele quedar relegado a un segundo plano, encargándose durante el último día en adaptar un powerpoint para contar algo interesante. * Fomentan el trabajo no remunerado: En el mundo del diseño llevan luchando desde hace varios años contra el trabajo no remunerado. Tal es la lucha, que han creado un término para resumirlo: no-spec (no speculative work). Trabajo especulativo es aquel trabajo no remunerado en el que participan múltiples personas con la expectativa de conseguir un único premio, trofeo o trabajo, en base a una pieza que desarrollan a medida sin garantizar remuneración alguna. Pensadlo bien: ¿Cuánto tendríais que pagar si contratarais a 100 personas para desarrollar casos de uso para vuestro programa o plataforma, abonando 48 horas extra nocturnas y de fin de semana? ¿Es una cantidad equivalente a una Xbox o una tablet cara? ¿Quién contratará a un programador o diseñador contando que puede conseguir resultados iniciales organizando un hackathon por una cantidad mucho menor? * Lógica extractiva: La estructura de los hackathones se enmarca en muchos casos dentro de una lógica extractiva, orientada a captar valor externo a la organización de una comunidad más amplia y diversa. En otros casos, simplemente se organiza hackathones para dar una pátina de modernidad a instituciones ancladas en el siglo pasado. Aunque el objetivo oficial sea generar soluciones a problemas reales, el resultado suele ser código espagueti y muchos videos en la cuenta del organizador, en los que se ve a gente dándolo todo 24 horas al día.  El hilo conductor suele apelar al heroismo y alegría que supone pasar la noche programando para conseguir solucionar el reto. ¿Es este modelo sostenible o simplemente se espera que la gente vaya quemándose y siendo reemplazada por nuevos ninjas de la programación? * Resultados efímeros: Es imposible resolver cualquiera de los grandes problemas del mundo en 24 horas. De hecho buena parte de los problemas actuales no se solucionarán escribiendo código, sino a través de un análisis profundo y una dedicación a sostenida en el tiempo. La insistencia en invertir horas y esfuerzos en loshackathones empeoran el problema: aparentemente se está trabajando en el tema, lo que desincentiva a la gente crear otras propuestas o a invertir su tiempo en otros espacios. Evgeny Morozov llegó incluso a poner un nombre a esta tendencia: Solucionismo. * Ambiente limitante: Muchos de los hackathones no solo proponen una temática sino una serie de herramientas. El refrán castellano: “Cuanto tienes un martillo, todo son clavos” explica la cuestión con claridad. Cuando tienes que enfocar esfuerzos para ver cómo la herramienta X resuelve el problema Y, se producen toda una serie de remedios frankenstenianos: “Resuelve el paro juvenil usando Ruby on Rails”, “Salva el planeta usando las nuevas placas con procesadores ultramegapower x2”. El objetivo de estos encuentros suele ser promocionar un producto o plataforma, para captar futuros clientes, independientemente del problema a resolver. (Que de hecho, da bastante igual). * Ajenos a la lógica de las comunidades: A menudo nos piden hacer hackathones, difundirlos entre la comunidad, presentar los beneficios para los miembros del grupo… Por lo general, estas propuestas ignoran la lógica de las comunidades, en las que la gente se reúne para compartir aprendizajes y experiencias a lo largo del tiempo, guiados por sus propias inquietudes.Las comunidades dejan de ser grupos de personas con un interés común para pasar a ser un recurso desechable: son público de fácil acceso, menor coste de adquisición y con ganas de probar cosas nuevas. Empresas especializadas, sin ninguna relación previa con el grupo, quieren hablar por skype lo antes posible para localizar a personas clave en la comunidad, encontrar la forma para enviar información sobre su evento y ofrecer un descuento del 20% para ese evento irrepetible en el que se va a salvar el mundo de una forma multidisciplinar, innovadora y, por supuesto, disruptiva.

Ultimamente esta ocurriendo esto también con nuevos grupos en Meetup cuyo único objetivo es promover actividades o herramientas de pago: congresos, drones, webinars, etc. Hay que andar con pies de plomo antes de darle al botón de aceptar, para no verte sumergido en una maraña de “ofertas beneficiosas”.

Conclusión

Los hackathones surgieron como una forma de conocer gente nueva y probar qué tal te manejas creando cosas locas junto con otras personas. En estos últimos años, se han convertido en una herramienta que emplean las empresas para captar nuevas ideas y detectar talento de forma más económica, en un marco entre lo molón y el flower power.

Frente a estos nuevos mecanismos rápidos y desechables, prefiero planteamientos mucho más honestos a largo plazo y que reviertan realmente en la comunidad. Y si lo que queremos es conocer gente y aprender e inventar sin limitaciones, siempre nos quedarán los Stupid Hackathon.

Notas

Agradezco todas las aportaciones y comentarios sobre este artículo, que me han permitido aprender sobre otras alternativas, puntos de vista complementarios y otras comunidades. En particular me gustaría agradecer a Santiago Fariño, Adolfo Sanz y al resto de organizadores de comunidades tecnológicas.

Obviamente hay más modelos de hackathones, o eventos con otros formatos que utilizan el mismo nombre, pero creo que está claro al tipo de actividad a la que me refiero explícitamente.

Alternativas más interesantes mencionadas durante este episodio * Hackergarten: http://hackergarten.net * Pi Week: https://piweek.com * Open Source Weekends: https://www.meetup.com/es-ES/Open-Source-Weekends/ * Sprint: http://www.gv.com/sprint/ [1]: https://www.facebook.com/lahoramaker/