What Hackathons Really Are Community building events
Hackathons, Code-a-thons, Code sprints, Hack days, Hackfests, Codefests, call them what you will; they have been going on for quite some time. In recent years, this has moved past the idea of a specific programming language or software to such things as civic hacking, fashion, icons, and more.
As Code Across America and International Open Data Day approach and people across the world come together to help release and utilize public data and make technology that helps their communities, I have been thinking critically about what is the real value and purpose of what I will generally call Hackathons (we so need a better word).
My main idea is this: Hackathons are community building events. Plain and simple; that is their sole purpose. Dress them in whatever activity you want, its still all about strengthening connections among people. I see many organizers let this idea go wayside in place of activities like building apps or clearing the issue queue. I also often hear the idea of community building talked about as a side benefit of hackathon events, but by defining succes of a hacakthon in terms of community building, I fully believe these events will become much more meaningful and productive to everyone involved. So let me explain in more detail.
Let's describe a hackathon a bit first
Hackathons are pretty general events where people of a community come together and work on project(s). Often the actual activities of a hackathon resemble something like the following:
- People meet in person
- Idea generation or task delegation
- Team or group forming
- Building or working (hacking)
- Presentation or judging period
To better define the space that is a "hackathon", here are some general examples of what I would lump into the term "hackathon event"; trying to provide enough variety to show that subject and tasks can be quite different.
- Civic Hackathon. Technologists and civic leaders making applications for their communities.
- Iconathon. Designers and artists coming together to make reusable icons for everyone.
- Code Sprint. Coders sprinting towards the next release of a software product.
- Data Day. Data nerds come together to try to liberate and utilize (public) data.
- Internal Hackathons. Like a code sprint, but for a specific organization or company.
What is community building?
Just to make sure we are on the same page, let's define this a bit more. Community building is simple; its the act of bringing people together for a shared cause and creating connections where there were none before and/or strengthening existing connections. That's it. But keep that in mind as we go through this.
The value of community building is that you grow the size of your community with more participants and also strengthen everyone's ties to the community as a whole, which translates to your community becoming more sustainable and more capable of accomplishing its mission, whatever that may be.
By building a stronger community, you are building more sustainable solutions.
- If your community is focused on creating civic technology, better connections produce sustainability and ensures real needs are met.
- If your community is designing icons, building relationships means knowledge and inspiration sharing, enhancing the artistic pool.
- If your community is all about a specific software, building community means less burnout, more throughput, and more adoption.
So, why a hackathon?
If our primary goal is community building, why not just hold an ice cream social and let people mingle and talk to each other? Good point. Holding a happy hour or ice cream social in your community would be a great idea and would probably strengthen your community, given the audience.
And that's where the answer comes in -- given the audience, i.e. the members of these communities, a hackathon is the best activity for community building. The people in these communities want to build and create and learn with and from each other. In fact, these communities are defined by the things they make Their members want to feel productive. Working together and collaborating builds bonds and strengthens personal ties much better than a beer will (beers can pretty great too).
Sunlight Foundation's recent article says that community building is not the focus of a hackathon and that application building is, and the article makes the comparison of a hackathon to a Habitat for Humanity event. But here's the thing, hackathons are about coming together to find new and innovative ways to tackle problems or otherwise lending one's specific skills to a problem; a Habitat for Humanity event is focused on getting bodies to help build things that have already been planned out, but the skills of the individuals are not important at all. This would translate to a Habitat for Humanity session where a foundation was set, then the volunteers would try to find the best way to build a house; it would probably be really bad unless you had experienced contractors, carpenters, and electricians. But I am not trying to knock what Habitat does; getting volunteers together to build a house is a great activity, and if your community has a set project and plan and all you need are volunteers, do think about it in this way, but a hackathon should not be run like this.
Hackathons are not for everyone, and depending on your community and goals, you may want to hold other sort of events.
What about the apps, the issue queues, the code, the icons?
The activities of the day are not the same as the reason for holding an event. The activities of a hackathon can be fairly different, stretching from everyone working on an existing project in a code sprint, to building new apps at a hackathon, to data wrangling at a open data day, to drawing icons at an iconathon, and more. These are really important and are the focus of what people are practically doing; telling people to come to a Community Building Marathon would probably not convince many folks to attend. But this is not the reason for holding the event; people could do these things by themselves, but they come together because they value their connection to the community.
You aren't going to finish these activities at the hackathon. You aren't gonna come out with anything more than prototypes for applications; even if you close out every issue in the queue, there will still be more tomorrow; you can ship a new release, but there's always another one; you will draw lots of icons, but probably not make any finished ones; there's always more work to be done. This does not mean its not worth the time and energy that people are willing to put into the event, but expectations need to be realistic. Again, it's not about the activities, its about how the activities actually build stronger communities so that this work can continue into the future.
Prototyping and experimentation
The ideas of experimentation and prototyping are very critical to successful community building. These are the ideals that have led to such a strong community of computer hackers. By providing an event where experimentation and prototyping are promoted, people can feel more comfortable with taking risks, learning new things, and being more open with each other. Focusing on finishing activities will often conflict with this.
Promote the work
Given that people are giving their time, energy, and expertise to draw icons, triage issues, scrape data, and more, it is really important that these activities are collected and put on a pedestal after the event. This is not about the actual work, its about promoting the people that did the work.
But we want to create sustainable, stable applications to help your community, you say?
That's great! But a hackathon won't make that happen. Don't get me wrong, some amazing projects have come out of hackathons that have gone on to be great things. But these are rare cases, and at best the hackathon simply played the role of getting the right people together, not providing an environment to fully foster that project. Holding a hackathon that is solely aimed at making great applications is like playing the lottery; sure, you might get a winning ticket, but most of the time you are gonna be disappointed. This is not even to speak to the mechanics of making good applications in which a day, a weekend, or even a week could not produce a sustainable solution to a problem.
If you really want to foster sustainable applications and projects, hold an event or series of events that brings together real funders and established product teams and build those relationships. A hackathon can be a real good step in getting those product teams together, but it will not provide sustainability to them.
What about contests?
First, let's distinguish between hackathons that are contests, and long-running, remote (not in-person) contests, for instances ones that are on Challenge.gov. The latter is actually a productive way to promote innovation and given certain conditions, will actually lead to some significant, long-term projects. The former is a bad idea in my opinion.
Contests at hackathon promote competition, which in a community of people where you want to strengthen relationships with, could have negative results. Also, as discussed above, hackathons do not create long-term projects, and giving significant money to a project that was prototyped over a day or two with a team that may have never met before is not a good investment of money.
On the flip side, contests do provide incentives to people that might not have them in the first place; but it is arguable if this is actually the type of behavior you want to promote. If the prize money is in small, relatively trivial amounts, and almost everyone gets a prize, contests can provide a level of competition that promotes innovation and experimentation that might not be there.
What is success?
If you accept the premise that a hackathon is a community building event, then what does success look like? It is the number of connections made and the quality of relationships at the end of the event; it is not the number of apps built or issues closed or even the quality of the projects produced. Some specific metrics:
- Fun was had
- New connections were made
- People learned new things
- People know how to keep in touch with the community
- Teams continue to work on their projects
- People come to the next event
Planning your hackathon
When you plan your hackathon, ensure that your primary focus is community building and that your activities lend themselves to that idea; you will have a fun and successful event if you do this. Some ideas to keep in mind:
- Do no harm. Make sure you are not doing things that sever connections or lessen community.
- A charismatic, empathetic, vibrant facilitator is so crucial. The person that leads the event needs to understand the core of community building and what needs to happen to facilitate it.
- Ensure everyone feels productive, no matter the skill level, or if they show up late, or even if they dont have a computer. You'll need extra facilitators for this.
- Make sure everyone can speak their ideas if they want to. This needs to be constructive, of course.
- Make sure all relevant audiences are there. Go out and get them! Only having coders working on applications will result in incomplete ideas and solutions.
- Everyone is equally important. Seriously. Make sure this is activated.
- Collect names of participants and promote their work after the event.
I am not trying to say that people are doing bad jobs when running their hackathons, but by keeping in mind that hackathons are just community building events, you will find a lot more success with your events.
I have had the amazing fortune of being apart of some great communities and knowing fantastic people that have allowed me to participate, lead, and critically think about these sort of events. I have not fully attributed them in this article, but will soon.
Note that the Sunlight Foundation article linked to above is really great; I just think the original premise is a bit off.