Hackathon Yackathon reflections

Yackathon-webThe 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?

IMG_0015_2On 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.


OccupyData and TTW13

Evernote Snapshot 20130302 142839Last weekend I was at OccupyData and Theorizing the Web, as I mentioned earlier. Nathan Jurgenson and and PJ Reys put on an impressive conference for work about technology and theory (two things which are apparently difficult to talk about at the same time at conferences, apparently). At the same time, the organizers at OccupyData have done a good job coordinating people working on all sorts of different projects – there was a mixture of pitches and continuing work, and there was a little more structure to begin with this time. Two of the more interesting projects that were Data Anywhere [Day 2 post] and the NoFareHikes map that Ingrid Burrington showed us – I especially liked the later because as Christo said, “there’s a media action agenda inherent in project” which makes it great. I’ve been thinking about how a lot of hackathons propose a sort of data solutionism, or a belief that the technology solution is the solution to whatever the issue is. Continue reading