Many good programmers today are quite adept at modularization or other related efforts like framework building. By utilizing existing frameworks and modules one can leverage an enormous amount of existing code. I think though that many of the most worthy efforts at hackathons actually leverage existing modules or frameworks that were actually built or co ntributed to by the particular hackathon participant who is using them.
I think because of this contradiction and because it is difficult to distinguish between a completely new project and one that is a continuation of existing work that we need to alter the concept somewhat.
Getting together to hack on existing projects and describe them is probably a more honest and generally applicable idea. If you really want to limit people to work done on that day you are going to need to be very specific about what types of existing modules and frameworks can be used and whether the individuals participating may have created those. I'm not sure I really see a great point to that sort of exercise though unless it is just for developers to demonstrate how many interesting techniques and algorithms they can carry with them in their mind. That seems kind of a primitive thing to test for when we have so many great ways of reusing code.
We have been wondering about the value of using a cloud IDE (disclaimer, I am CEO of Codenvy) as a type of quarantined project workspace that is managed by a 3rd party for the duration of an event, like a hackathon. The workspace would be structured & owned by the organizer and not the hackers. And this way the organizers could place assets like keys into the workspace, and also monitor what code is authored and / or imported into it throughout the duration.
We'd value the community feedback to see if there is value in such an offering. We may want to hack one up ourselves :)
* Create private repos for all the participants well in advanced, and ask them to commit their changes to their designated repo.
* At the time of the deadline, all pushes will be blocked, and/or the current version will be pulled down to a "demo" machine.
* Participants must provide a make file (or something similar) to automate the building on all projects.
* When their time for demo comes, they will only get to demo whatever that has been compiled on the "demo" machine.
* The "demo" machine would be hooked up to the projector, and will be the only machine used for demo-ing purposes. This also saves the time spent in hooking up their laptops to the projector.
That's all. Sounds academical, but it's a really good way of monitoring cheating (provided you have an audit team as well).
Also I'm not sure it would cover all the bases for more complex hacks that involve hardware or more unique setups/dependencies.
Ultimately, I wish a solution could be found that doesn't work to limit the types of hacks, since that freedom is one of my favorite parts of hackathons.
I think the simplest fix is to start shifting the focus away from the negative competitive aspects. Large cash prizes are a great example of one that we could do away with. As you suggested, focusing on non-monetary or community incentives would be a great alternative and the whole hackathon scene could benefit from that.
You should check out this talk I gave about hackathons a few months back. We definitely seem to be singing a similar tune. http://www.youtube.com/watch?v=ocY70UORNsk
Also, thanks for the Major League Hacking shout out!
You don't have to go to every hackathon that comes along, especially ones that "feels" like you'll be pissed at in the end
Some things I didn't like:
* Big prizes encourage sucking up to sponsors
* Crappy work environments (plastic tables and folding chairs)
* No camaraderie between participants and teams
So I decided to run my own. My idea of a good hackathon was just a bunch of geeks in a room building cool stuff for a day. I didn't care about commercial viability or any business concerns, I just wanted to see people have fun building something neat.
* 8 hours on a Saturday, not overnight. This does lead to smaller projects but also brings in more people who don't want to spend the night.
* Have everyone introduce themselves at the start and talk a bit about what they want to work on. I only had 24 participants, this wouldn't scale to larger events.
* Keep everyone in one room so everyone knows what everyone else is working on.
* Keep the prizes small. While I had a sponsor, I capped the prizes at $50.
* Don't allow the sponsors to run the event. I let them give a five minute pitch about their product and put their logos on the website but I didn't give them control over prize categories or let them bother the participants during the event.
* Keep prize categories vague so that participants don't build for the prize. This is easier when the prizes aren't worth much anyways.
* Since the prizes were so small, I didn't mind if people worked on something they'd already started on prior to the event.
Overall, I think my event went pretty well. I charged $10 to get in which barely covered the T-Shirts, my venue was a coworking space I use so I didn't have to pay for that (and they paid for the pizza) and my sole sponsor (thanks BazaarVoice!) paid for the prizes and a keg. The dev evangelist they sent did a pretty good job and even worked on some code himself.
None of what was built was commercially viable in any way but that wasn't the point: people had fun building cool projects and that was my only goal for the day.
Some of the projects:
* A Lego Mindstorm robot that played the drums (one of the participants brought his son, this was their project)
* A MakeyMakey project that used pizza crust and a keychain as input devices (seriously)
* A Raspberry Pi based SNES emulator complete with HDMI output
* Voice-controlled lighting
* An Arduino-based step sequencer
* A virtual world simulator
* A naive chess AI in Scala
Personally, I thought it went really well. No, it didn't make any money (in fact I lost money since the shirts cost more than I expected) and no one was able to pitch their startup but that wasn't the point. People had fun. If you're hackathon is oriented towards anything else, don't expect the participants to have a good time.
shameless plug: If you're near San Antonio and this sounds like an event you want to go to, we're holding another one sometime soon, probably December. Email is in my profile if you want to get on the mailing list.
I haven't announced the next one yet as I'm going to be out of town for much of the rest of the year (Houston -> Japan -> Seoul -> Boulder) so I'm not entirely sure when I'll have time to do it.