The hackathon is an interesting phenomenon in the way that people have organized around technology development and social issues. Closely related to the concept of open data, the sort of collaboration that goes on at a hackathon is often structured around themes in the public interest, whether that’s open government, disaster relief, or community-minded apps and technology solutions. Our Hackathon Yackathon was designed to invite hackathon organizers, participants and those interested in such events to look at them with a critical eye, asking the sort of meta-questions that would impede hacakthon’s goals if raised during such events.
We provided a means for people to submit topics and came up with a rough agenda beforehand, but the more intimate nature of this hackathon (focused around conceptual work and ideation) with a smaller crowd meant conversation flowed more organically through the entire group – instead of splitting into our breakout sessions as planned, we started with smaller groups that came together for our first “panel,” which flowed into the next and focused on two main themes: Hackathon methodologies, tools and outcomes, and the tension between civic hacking and data activism. We were fortunate to have a diverse set of perspectives and motivations at the event – VJ Um Amel and Willow Brugh joined us via GoogleHangout and we had a fairly casual conversation with well-thought out input from all the participants.
For me, a key outcome was the sense of the hackathon as a method that has many different iterations and is not beholden to a particular ethos or inherent quality – it focuses on not merely volunteerism, but invested participation, which can be cooped by commercial interests as “cheap labor.” This was something we could all agree on, however, the ideological divide between the hackathon as a model of cooperation versus competition was something that also reflected schisms between hackathons organized to contribute to municipal and governmental goals, versus those which are more activist in spirit and intent.
Another interesting point which I wish we could have devoted more time to is the divide between big data and observable community results. Hackathons draw from a spectrum of skill sets by encouraging participation from people who know how to do more than just code. However, they are not always inclusive – for the activist and even the civic mode, it can be difficult to involve people who can’t just build something on a computer in a day or two. In addition, there’s a need to address the agenda and viability of data (is it alive or dead, and who creates it for what purpose?). One possible answer we thought of was to incorporate some of the methods from citizen science, and to organize hacakthons in a series, where data collection methods are planed and tools are created, then people are trained and can go out to build the dataset themselves, and return to work on it at future events. This way, people of varying skill levels have greater agency, participation and investment in the project as it develops.
This is also important, because as VJ said, “People in the West fetishize data to the detriment of its content” – it may be convenient for us to build tools that are practical and feasible, but do they really solve any questions we need answers to? Are we building things that people need, or just making a wasted effort for the sake of the exercise?
On a final note, there needs to be a set of reusable tools that can be adapted from one hackathon to the next. There may not be a universal set of “best practices” for hacakthons across the board, but there are some outputs (experience) that can be applied, and documenting them is difficult. The “case study” and working groups approach OccupyData has taken is useful, but hackathons in general suffer from a lack of institutional memory and high frequency that dilutes their effectiveness. I’d argue that the most important output of a hackathon is the community that develops as people experiment with each other from one event to the next, but if a hackathon is a platform for building a concrete product rather than concepts, there needs to be more structure to their organization. Unfortunately, this diminishes the agency and representation of participants… the hackathon is a tool itself, a way of organizing, that is contextual and suited towards unique purposes depending on the organizers and the participants. The variety of options between those purposes and motivations reveal the tensions that exist when we try to think of the hackathon as having a singular format and structure, and organizers must try to align the way the event is held with their motivational values.
One thought on “Hackathon Yackathon reflections”
Pingback: MiT8 Reflections/ End of Semester | MrLiterati