January 30, 2012 by mheadd
This is the first in what I hope will be a series of posts with practical advice for organizing and running hacking events, particularly those focused on building civic apps and using open government data.
These posts will lead up to, and (hopefully) follow a talk I’m giving at SWSWi in March discussing the outcome of two civic hackathons I helped organize in 2011 – one in Philadelphia and one in Baltimore.
One of the lessons I took away from my own experience in helping organizing these events (and participating in many others) is that “free” does not always mean “better.”
It’s a widely held belief that civic hacking events should be free of charge, to encourage wider participation and to make it as easy as possible for people to join an event. There is some logic to this belief, and in some cases making an event free to attend is the best approach.
However, there are some cases where I believe charging people to participate in a civic hacking event can increase turnout.
In making this contention, I draw on the experience I had with a civic hacking event I helped organize last Summer. The event was part of a larger BarCamp focused on innovation in journalism, and it seemed to have all the ingredients to draw a large and enthusiastic crowd of participants. A healthy number of people registered to attend, and expectations were for a big crowd of people at the hackathon.
On the day of the event, however, turnout was very light – only a handful of people showed up to the hackathon, and only one project was worked on over the course of the day. (As an aside, I should say that the group that attended was packed with talent and the project they worked on was pretty cool – but that’s a story for another post.)
Civic hackathons are flash points that bring together members of a local (or regional) developer community to rally around open data and civic apps. As they are meant to help build the civic hacking community, the number of participants in these events is a key measure of their success. By this measure, the event I am describing was not as successful as I and the other organizers had hoped.
Looking back on this example, I started to believe that one of the reasons we had so many people register to attend and so few actually make it to the event was because there was no cost to blowing it off. Prospective participants may not have viewed their registration as having any value because we hadn’t conveyed it to them with the appropriate signals – i.e., a price for participating.
As a way of testing this theory, for another hackathon I helped organize later in the year in the same city I decided to limit the number of registations available and to charge a small fee ($10 per participant) for signing up. This was meant to convey to prospective participants that their registration had value, and that by signing up they would be taking a seat in a finite supply – their participation was, in effect, crowding out someone else who might want to attend.
Charging people to attend civic hacking events (where open government data is used) can be tricky. I had several people who were thinking about attending this event question the motives of organizers, or flat out tell me that they wouldn’t come. But in the end, we had a sell out crowd for the event, and almost every single registrant showed up.
It’s interesting (and gratifying) to see other hackathon organizers come to a similar realization.
A hundred people registered to the event, and in the end around 40 hackers showed up for the event. I did not expect such a large difference, I think it’s due to the fact that the event was free of charge, a lot of people registered and never showed up later.
[For the next event, we] decided that tickets would be €10, not to make money from it, but to make sure that people registering were people really willing to come. In the end, around 140 hackers showed up. I think our strategy worked fine.
Though it may seem counterintuitive, sometimes limiting the the number of seats available and charging a fee may increase turnout at a hacking event. This isn’t always the case, and there are some very specific instances where this approach is probably not a good fit.
Sending the right signals to prospective participants at a hackathon that their participation is important and has real value can help make these events a success.