Hacking the hackathon

Friends, romans, civic tech enthusiasts, lend me your eyeballs. I come to bury hackathons, not to praise them.

Maybe it’s just the crowd I run with, but it’s hard to find a kind word about hackathons these days. You can see this attitude in commentary around the web: Hackathon projects aren’t sustained past the event, or picked up by anyone else. They don’t scale, and they’re hard to monetize. They don’t address well-articulated problems. Hackathons are literally bad for your health.

There’s depressingly little follow up after hackathons - it’s hard to figure out, six to twelve months later, what percentage of projects are still being maintained, let alone actually serving their intended purposes. Maybe this is simple oversight. Or maybe organizers don’t measure long-term success because they’re afraid they won’t find it. My own haphazard round-up of some of the sites participating in the National Day of Civic Hacking (NDoCH) found that even the most successful projects are seldom maintained well past the event. Of 10 projects with stated ongoing goals that I was able to find code repositories for, only 3 were updated in the last two months.

(NDoCH, to their credit, sent around a detailed survey about attendee experiences, including questions about demographics, diversity, skills learned, and perceived impact. Sadly, the results have yet to be released 3+ months later.)

I don’t mean to pick on NDoCH, which I helped to plan a small part of. But the scale of the event - 90 sites! 11,000 people! - makes me worry that we’re going all in on the idea of hackathons. And I believe that hackathons are harming the civic tech/open gov community.

I haven’t heard many people argue that hackathons are hurtful. People seem inclined to view them as ineffectual, with few successful projects. “But at least they’re good for something,” they add. “They’re good for networking and community-building.”

That is exactly where the harm lies.

People who attend hackathons have large chunks of free time on weekends. This selects against parents and other caregivers, people who work shifts and weekends, and people with health problems which demand frequent breaks.

People who attend hackathons tend to be programmers, and programmers in turn tend to skew to certain demographics. This selects against women, most minorities, and people with less education and a lower socioeconomic bracket. Civic hackathons tend to be a bit better in this regard, but they’re still not representative of the general population.

People who attend hackathons tend to believe that technology can solve most social problems, and that it can do so in 48 hours. Their backgrounds are less likely to involve political or community organizing, and they’re less likely to be deeply knowledgeable about the problem areas that the hackathon seeks to address. This selects against the people most invested in solving those problems, and those with differing opinions about how to solve them.

This lack of diversity obviously hurts the individuals and groups shut out of this stealth community-building process. It also hurts the communities that do form, which suffer from narrowed perspective and a shallower form of investment. Perhaps this is why so many hackathon projects get lost in the ether - because they are built by a micro-community of casual volunteers, not by people with a deep stake in seeing the project succeed.

In my experience, it is difficult to get funding to do community-building when you call it community-building, rather than dressing it up as “running an app contest” or “throwing a hackathon”. So not only are these hackathon communities exclusionary, in some ways they’re the only game in town.

Okay, so what can we do to fix them? How do we change the game?

How can we “hack the hackathon”?

A number of people have made great suggestions about how to improve hackathons, from focusing on local impact and secondary benefits, working with community partners to define problems, and extending efforts beyond the hackathon itself with pre-planning meetings and post-event mentorship.

I agree wholeheartedly with all of those suggestions, and I have some additional ones:

Make hackathons welcoming to a greater diversity of people

People who attend hackathons have large chunks of free time on weekends.

Within the “hackathon weekend” model, you can try to counteract this by providing childcare or at least by making sure the event is child-friendly. You can choose your venue and your process with an eye to disability needs and make clear in promotional materials that you are committed to addressing problems that arise. You can make sure your hackathon is structured to provide clear tasks such that people who can only attend for a few hours can jump right in and make a real contribution. You can also consider creating a “permanent hackathon” - not a single marathon event but an ongoing group, meeting at a time picked to fit the needs of its members.

People who attend hackathons tend to be programmers, and programmers in turn tend to skew to certain demographics.

Actively do outreach to under-represented groups. Advertise the event in places you might not normally advertise a hackathon - in local community centers, to area non-profits, and on the mailing lists for women in tech and minorities in tech. Put up flyers in community colleges as well as your local liberal arts college or prestigious university. Make sure your promotional materials are welcoming to non-programmers, to non-college-educated folks, to women and minorities, to non-twenty-somethings.

Another important step towards creating a safe and inclusive space is to adopt a code of conduct that makes it clear that harassment and intolerance will not be allowed. Even if you don’t expect those things to be problems at your hackathon, adopting and advertising a code of conduct is a signal to under-represented groups that the organizer is working to include them and is willing to deal with problems if they do arise. Besides, it never hurts to be prepared.

People who attend hackathons tend to believe that technology can solve most social problems, and that it can do so in 48 hours.

As discussed by others in the links above: work hard to include people with different backgrounds and different skillsets. Make it clear in your publicity that the event isn’t just for coders. Find partners in groups and organizations that are already working on these problems. Emphasis on partner - don’t view them as a client or, god forbid, a charity that you are donating your time to. Let them take the lead in defining the problem to be solved. Leave space for the solution to be non-technical - if it turns out a partner needs data entry or money, not code, then the best use of a programmer’s time might be entering data or drafting fundraising materials.

Make education a key part of hackathons

I’ve heard a lot of people say that they don’t attend hackathons because they don’t feel technically competent enough to contribute. One way to address this is to emphasize in your publicity the importance of non-technical contributions - it helps if you really do believe that the best solutions may be non-technical (as I’ve argued above) and that technical-support contributions are vital to a project’s success (as I’ll argue below). Some argue that the term ‘hackathon’ inescapably privileges technical contributions like coding, so consider renaming your event to something like “project night” or “data dive”.

Another way to address this is to provide education/training to attendees. Find local volunteers or use online materials to teach attendees how to use version control, how to navigate the command line, how to call an API, how to make a working website using basic html or, if you’re feeling adventurous, Django.

Providing training makes it absolutely clear that inexperience isn’t only acceptable - it’s expected. It eliminates attendees’ worries that they won’t be able to accomplish anything, because at the very least they’ll have gained a new skill. Your event won’t just draw more contributors, it will create them.

And you don’t have to limit yourself to technical trainings. Ask those with different skillsets to teach them. Have social media experts talk about how to do publicity, journalists lecture on how to craft stories, community organizers train you on mediating conflict and building consensus. If you’re partnering with, for instance, a food pantry, ask them to teach you how their organization works, their metrics for success and their best practices for common problems.

That sounds like more fun to me, anyway.

Emphasize making projects sustainable long-term

Sustainability is a recognized problem with hackathon projects. As mentioned in the links above, holding planning meetings before the event and providing mentorship afterwards are promising suggestions that will hopefully help. But how can we alter the hackathons themselves to improve the sustainability of projects?

I have one word for you: documentation.

Just as technical solutions dominate non-technical solutions at hackathons, coding contributions dominate non-code contributions. That’s incredibly unfortunate, as documentation is vital to the long-term success of any project. In my work at OpenHatch, one of our biggest goals has been to identify the barriers to new contributors. A huge obstacle is complicated and/or poorly documented development environment setup processes. You need to be able to answer: Where is the code? How do I download it? Which operating systems/system versions will it work on? What dependencies do I need to install and how do I install them? Do I need to build or run anything to get this working? How do I test my changes? How do I submit my changes back to the project? Many hackathon projects don’t begin to provide this information. Some don’t even have a readme!

Once you get past dev environment setup, there’s still tons of work for documentation enthusiasts to do. They can make sure the project’s main location (website, code repository, etc.) has or links to all relevant information (documentation, issue trackers, contact info). They can write explanations of how the project is structured or manuals for users. They can do user testing and record the results. They can work together with a coder to make sure code is clean and commented.

That’s a lot of work! Luckily you’re hosting a big event with tons of people eager to help out. (And hopefully this event includes plenty of people who can’t or don’t want to code, and who might therefore be drawn to these types of tasks.)

This leads me to suggest a final, non-documentation strategy: have projects identify goals going forward and assign a leader or leaders to follow up on those goals. At New England GiveCamp I worked with a small group to build several websites for local non-profits. About a year later one group contacted us about a technical issue that had taken down their website. Unfortunately no one had kept the information about account names and passwords for the host website, and the problem never got fixed. Don’t let something so easily preventable happen to your projects!

Fund pure community-building

I’m all for improving hackathons, obviously. But in the end, they’re just a tool - same as code is just a tool. What’s most important is the people who use the tools, because it’s people who solve problems.

People need to communicate. They need a forum for sharing ideas and they need to be connected to others with complimentary skillsets and thought-provoking differences. They need to know about what others are doing so they can learn from their successes and failures, and so they can borrow ideas, materials, and code that works. They need people to turn to for advice and suggestions when they run into obstacles.

People need to feel invested. They need to know that their hard work is appreciated and matched by others who care as much as they do about an issue. I wonder sometimes if we might be better of stepping away from a ‘food pantry’ model of civic tech volunteering, and towards a ‘crisis hotline’ model. By this, I mean that when I’ve volunteered at a food pantry, I dropped in for a day with minimal training or commitment. When I volunteered on a crisis hotline, we spent thirty hours in training and made a minimum ten month, twenty hours a month commitment. This may seem like a lot to ask of volunteers, but people are willing to make huge contributions to a wide number of causes, if they believe that the work they’re doing will make a difference. This investment may be the difference between projects getting finished and projects getting abandoned.

People need friends. Seriously. When your project doesn’t seem to be working, or you feel too exhausted to go to a meeting, knowing you’ll see someone you like, catch up with them, have a laugh - it can make all the difference in the world. I’ve definitely gone to events purely because I was looking forward to seeing a friend there.

It’s easier to get funding to build an app or host a hackathon because the measurement of success is clear - lines of code written, downloads. But said clear measures are showing failure. So why not try funding something else? Why not provide support for people who are leading the way in community-building, and not just app-building?

*

The choices we make about the events we run and the people we include will determine the projects we undertake and the type of impact we have. I believe the best, most vibrant civic tech community will result from re-thinking how we spend our time and money, at hackathons and outside of them.

As with any essay of this kind, I’m sure there are generalizations I’ve made, points I’ve missed, or facts I’ve got wrong. I welcome feedback in the comments and elsewhere on the web, and I look forward to hearing the response.