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 y Twitter!
[powerpress]Durante estos últimos años, los hackathones se han convertido en uno de los eventos más populares. Rara es la semana en la que no se convocan varios por toda España. Me gustaría exponer porqué me resultan contraproducentes y muy poco interesantes.
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/
3 comentarios. Dejar nuevo
Hola César:
Como muchas cosas que haces, este post junto con su podcast (más ampliado) me ha gustado mucho.
Y aunque yo si que soy fan de los Hackathones, fíjate que coincido contigo en algunos de los puntos que has comentado.
Ahora bien, como te he puesto por twitter, deberías cambiar el título de la entrada, pues al parecer lo que no apoyas son algunos tipos y/o algunas facetas de los Hackathones, y comentas como mejorarlos.
Voy a comentar tus razones intentándolo hacer siempre de una forma constructiva:
1 – Dices que “no son multidisciplinares”, y te doy la razón en parte de lo que argumentas. Cuando son hackathones en donde se juntan gente de negocio, diseñadores y desarrolladores, es verdad que la gente de negocio se queda un poco “aislada” con nada que hacer durante el evento que no sea hacer unas bonitas slides. De hecho esos hackathones, desde mi punto de vista cojean un poco. Pero si en vez de “emprendedores generalistas” coges a gente experta en la materia del hackathon la cosa cambia. Pongo por ejemplo el hackathon que montamos de JustiApps, en donde mezclamos gente del mundo del Derecho con desarrolladores y diseñadores. La gente del Derecho tuvo que ser partícipe en el desarrollo, pues eran los que tenían el conocimiento de que es lo que había que hacer (y los desarrolladores y los diseñadores aportaban el cómo hacerlo).
2 – Dices que “fomentan el trabajo no remunerado”, y puede que en algunos hackathones así sea, pero desde luego no con nosotros. Cuando hemos organizado un hackathon nosotros a los patrocinadores siempre les hemos dejado muy claro que un hackathon no es un desarrollo low-cost, es simplemente un concurso en donde la gente va a aprender, conocer gente nueva, divertirse y a resolver retos.
3 – Hablas también de la “lógica extractiva”, y por desgracia, te tengo que dar la razón: pasa en algunos hackathones. Ahora bien, en todos los hackathones que hemos montado nosotros la propiedad de lo desarrollado siempre es de los equipos, nunca de los organizadores.
4 – Hablas también de que los “resultados son efímeros”, y sí, por lo general lo desarrollado en un hackathon suele ser efímero, aunque hay bastantes casos de StartUps y proyectos nacidos en hackathones. Pero no te centres solo en StartUps o proyectos: la gente hace muy buenas amistades y compañeros en hackathones que perduran mucho más allá del evento 😉
5 – Hablas también de “ambiente limitante”, y sí, en casi todos los hackathones se pone alguna limitación: esta puede ser un tema cerrado, o el uso de una API, o el contribuir a un proyecto OpenSource, o porque no, los entusiastas de un lenguaje/framework/tecnología pueden querer limitar su hackathon, pero eso no lo veo mal. Simplemente son distintas tipos de hackathones. Ahora bien lo que no se puede es limitar todo, porque entonces sucede lo que tu has comentado.
6 – Comentas también que hay hackathones ajenos a la lógica de las comunidades. Si por desgracia los hay. Yo solo puedo decirte que nuestros hackathones nacen desde y por la comunidad de HackathonLovers 😉
Eso en cuanto a las razones que das por lo que no apoyas (ciertos) hackathones.
En cuanto a las formas de mejorar los hackathones estoy de acuerdo contigo en casi todo:
– Si quieres un desarrollo potente contrata a una empresa y/o a un freelance y págale, no montes un hackathon.
– A veces no hace falta demo + pitch (depende del hackathon)
– La propiedad intelectual siempre de los participantes.
– Me ha gustado la idea de buscar hackathones en donde se pueda contribuir a un proyecto más amplio.
– También me ha gustado la idea de los hackathones con ritmos sostenibles. De hecho nosotros nunca hemos montado hackathones donde la gente se quede a dormir, y más aún, a nosostros los hackathones que más nos gustan son los que duran solo un día 😉
Y en cuanto a las alternativas que comentas son muy interesantes y yo no conocía la del Sprint 😉
Un saludo.
Adolfo Sanz (creador de HackathonLovers)
Muchas gracias por tu aportación Adolfo!
Hola, me ha gustado mucho el articulo, y también la respuesta de hackatonlovers 🙂
Como diseñador UX me interesa el componente de sinergia y de ideas que se produce cuando organizo workshops con clientes, usuarios, marketing y tecnología. No es propiamente un hackathon pero el principio es similar.
Sin embargo, nunca he entendido la cultura de sacar cosas en periodos cada vez mas cortos de tiempo. Si bien puede haber la suerte de sacar una idea interesante, la mayoría de cosas que veo (mi agencia ha participado ya en algunos, con un UX y un diseñador visual) deja bastante que desear, y el carácter efímero y puntual de estos eventos impide en general continuar a desarrollar las ideas interesantes.
Sin embargo, hay un concepto muy interesante que estamos empezando a aplicar, es el Design Sprint (idea original de un tipo de Google Ventures), que en 5 días permite sacar no solo ideas, sino también productos mucho mas elaborados cara a un cliente o a un posible funding como startup. : http://www.gv.com/sprint/