So I have been thinking a lot about hackathons and community participation (and the barriers thereof) lately. Let's be clear here, I am talking about hackathons which feature a competition of one nature or another, however I'm sure some of this will be applicable and/or helpful generally.
It started with attending the hackathon at SunshinePHP, and then became fueled by talking with members of the Developer Outreach program at Mashery.
The way we generally do hackathons (as a PHP community) right now feels fundamentally broken. A few of the problems I see:
- There generally isn't a lot of clear focus given on what to build, which really becomes an issue when you add the time factor in.
- The expectation of the quality of 'product' produced is way generally totally undefined for newcomers.
- They are incredibly short. SunshinePHP had, I think, 5 hours of 'hacking time' available. I think unless it's long enough that you sleep in the middle of it, you're going to miss some of the fundamental magic that can happen, without some help.
I get that it's difficult to add a hackathon to a PHP conference and make it a first class citizen. I get it. So instead of saying spend more resources on improving the hackathon, I have some ideas on how to take the current constraints and try to work within them to make the experience better while still fitting in to the traditional timeframes we have allotted.
1. Pick a theme
Having a theme for your hackathon will provide an overall context to how people work at deciding what project to do. It's been said many times over that having too many choices is bad. Help out your participants and give them a container to think in. Let them wander outside of it if they like, but it will help many people. Any theme will do, contrived or not, provided you follow the other tips below.
2. Explicitly define the level of 'done' you are looking for
A lot of hackathon participants will be new (or relatively new) to the event style, so they enter it with whatever context they generally operate from. Myself, I'm always looking for the product in something, the viable business model, and the polish. Which is incidentally the totally wrong vantage point to use for a few hour hackathon. Let people know this. Tell them you're expecting (maybe not even fully functional) prototypes of an idea. Tell them to focus on the raw creative pieces, and to leave the polish behind.
3. Give them tools to mitigate the boring parts
If you're doing an API hackathon, write some wrappers for a few curated APIs (here's where the theme comes in useful -- use that to guide which APIs you pick to promote). If you're doing a technology hackathon, have hard-copy references of important pieces of information to make it easier for developers to track and reference several places at once. If you care about the final presentation of the submissions (the polish), give developers a template to work from (probably based on Twitter Bootstrap, but not necessarily). Give them the right tools and setup to let them focus on the thing that they are good at.
There are other issues we face with conference bound hackathons (namely placement in the schedule, timing of that placement, and competing interests) but those just come inherent in the form-factor of the two or three day conference. If you don't like these constraints, be sure to take a look at dedicated hackathons like the SoFloPHP Hack-a-thon that my friend Adam Culp and the SoFlowPHP User Group are putting on in the next few weeks. Florida too far away? Start your own. Need help? Ask me, and I will work to get you in touch with people who can help. Happy hacking!