By FRED TROTTER

On Oct 19, I will begin to MC the health equity hackathon in Austin TX, which will focus on addressing healthcare disparity issues. Specifically, we will be using healthcare data to try and make an impact on those problems. Our planning team has spent months thinking about how to run a hackathon fairly, especially after the release of a report that harshly criticized how hackathons are typically run.

A Wired article written earlier this year trumpets a study called “Hackathons As Co-optation Ritual: Socializing Workers and Institutionalizing Innovation in the ‘New’ Economy,” which criticizes the corporate takeover of hackathons. Hackathons are inherently unfair to participants according to these two sociologists.

They argue that hackathons have become a way for corporations to trick legions of technologists into working for free. To a sociologist, that looks like exploitation, and it is hard to see how they are wrong.

After reading the article, I was struck by how many things about typical hackathons are backward:

• Hackathons romanticize workaholism and celebrate insomnia – With hackathons typically running 24-72 hours straight, sleep is for the weak. Those who don’t sleep are seen as heroes.
• Junk food is the only option – Most hackathons provide unhealthy snacks, high in fructose and low in protein. Participants are expected to fuel their unpaid work sprints with sugar and caffeine. These are frequently the only eating options available.
• Healthy work patterns ensure that there are breaks. Opportunities to chat, or walk and take a break from work. And the idea of encouraging people to get up and move, let alone stretch, is unheard of at these hackathons. Hundreds of geeks, unable to shower, or leave the room, can create a pretty bad smell.
• Judging is at best arbitrary, and in some cases completely rigged, with winners sometimes chosen in advance.

On occasion, I have seen harder stimulants used. Although I have never seen anyone on cocaine win, it does make for super-engaging project presentations. The presentations were not good, mind you, just engaging… In the “Holy Moses, this guy is about to present when he is clearly high AF” sense.

Twitter user @evasynder after the annual Penn hackathon:

Navigating home after a 48hr #hackathon with only 5hrs of sleep is harder than the actual hack. @PennApps #PennApps

— EVA SNYDER (@evasnyder) January 19, 2015

As a society, we expect that bartenders have some obligation to ensure that people do not drive after drinking at their establishments. Should hackathons be putting so much stress on participants that they have similar concerns getting home? It’s one thing if this is something that participants are doing to themselves, for fun, but it’s another thing if this is the default expectation. This is especially troubling if the judging is set up so that only people who participate in all-night marathon work sessions can effectively compete.

Hackathons frequently celebrate competition as king. Winning is “the only thing” mentality – It’s a spitting contest. The participants are pitted against each other for prizes, rather than focusing on collaborating. Coders are looking to see who is the best and the brightest. Who can come up with the best solution to the problem, or at least who can come up with a solution the fastest?

Corporate sponsors dangle the carrot of a job opportunity over the heads of the attendees. Most do not leave with an offer or even a conversation. A Dice article written last year praising how one can be hired after a hackathon is an anomaly, not normalcy.

Prizes beget secrecy. Teams are looking for a crown, and for their idea to be selected as best. They aren’t focused on the potential of working together and collaborating with like-minded individuals. It’s us vs. them mentality.

Hackathons help the rich get richer (lining the pockets of well-established companies). And the previously mentioned salesforce hackathon corruption scandal opened up a can of worms. It shed light on the fact that hackathons aren’t always about innovation and community. They’re about companies fooling vulnerable data geeks into working for free, by pretending that they had a “chance”.  Salesforce “resolved” that drama by also giving the $1 million award to the second place team, without noting that the second place team also violated the rules of the contest (they were from a company that Salesforce had invested in).

Teams are judged on their coding/design/etc skills (in the span of 48-72 hours). Like a contest, a pageant if you will. Who made the best product? Whose idea is most useful? What can we capitalize on from here? Rather than taking smart and skilled people and helping them hone their skills, their projects are paraded around execs like an FFA student parades its cattle, hoping to win best in show.

In my experience, most hackathons result in the creation of “toy” projects. Projects from hackathons usually die at the end of the hackathon, as project participants entirely lose interest once the potential of “winning” disappears. This puts the hackathon judges (and I have done this several times) into a bit of a bind. The Judges can tell that all of the projects are useless in the real world, but they want to reward the good ideas that are trapped inside the toys (and there good ideas hiding there, frequently).

Is every hackathon that has a winner-take-all theme exploitative? Not at all. I think there are ways to run a competitive hackathon ethically. But from my perspective, it is much easier to remove the competitive aspect altogether.

The simplest way to run an ethical hackathon is to host a “barn building” and not a “beauty contest”.

Here are the rules that we are following at the Health Equity Hackathon. We hope that other cooperative hackathons might find these principles useful too.

First, this is a barn-building style hackathon. We want people working together to address an issue.

Not every problem is a good hackathon problem. You want to be able to make real progress on a real problem. That means that you need to have subject matter experts available. For our hackathon, that means patients, doctors, nurses, and public health experts, in addition to the developers, designers, and inventors that typically mentor at a hackathon.

Do not condone workaholism! Sleep matters for health. To the best of our abilities, we will make sure that no one is required to work through the entire weekend with little to no sleep. There are hard stop times in the evening when the doors will close, and we’ll begin again the next morning. Obviously, we cannot stop participants from continuing to hack throughout the night, but we can avoid celebrating it, and we will also avoid incentivizing it.

There is no competition and there are no prizes. There will be challenges, and we are seeking good ideas to address issues. This is not a winner-takes-all event. It’s not even a winner-take-any event. We’re hoping to garner trust and cohesion within the community. How can we fix these problems together? Great ideas and innovations will be celebrated, but so will solid work done on boring but important chores.

As far as food is concerned, find some healthy options. We are working with incredibly generous donors and should be providing at the very least, healthy-ish food. No pizza. No cookies… Ok, maybe some cookies. At a minimum, vegetarians should find good options. Preferably, those who are on keto diets and vegans should also have reasonable options. Packing your own lunch should be encouraged, many people need to do this in order to ensure that they stay healthy. Bringing a box lunch should not exclude you from participating in lunch as a networking event.

A hackathon should not be a recruiting ploy, but it can be a professional networking event. We will intentionally provide opportunities for people to meet others who are interested in working with health tech. We will either not have a job board at all, or have one that any participant (not just sponsors or hosts) can post jobs to.

Carefully make the decision about whether you want to have a competition at your hackathon. If you decide to have a competition, take great care to make it fair to participants, and to ensure that your participants are not killing themselves to win.

It is much simpler to run a cooperative hackathon, which is what we decided to do. It is ok to have prizes and rewards, but you need to make them “stuff everybody gets” or, randomly distributed. At best we’ll have door prizes for attendees. If there are rewards, make them focused on next-stage work. So if you have a project that makes a useful app, try and reward them with the cloud resources they need to host their app for a year. If they build something useful for hospitals, make the thing they “win” an introduction to a hospital CEO. Try to keep your rewards as “intrinsic” as possible. No one should leave feeling jealous of something that someone else achieved at the conference.

You should not have to pay a huge amount to attend a hackathon. Nominal costs are ok because they help to ensure that hackathon planners know how many people are coming. In our case, the cost of entry guarantees you food and a t-shirt. There should not be a profit for hackathon hosts. Hosts are not trying to get free labor that we will later monetize. Instead, we are interested in collaboration on projects that have no monetization strategy but would serve to make the world a better place. This is not a good place to launch a company, but it might be a good place to launch a technical revolution.

The projects and challenges that you are promoting should clearly be for the good of the world. Focus on things that can be contributed to Wikipedia, or open sourced through GitHub or perhaps even Thingiverse. For our hackathon, we have a massive chore list from Wikipedia Project Medicine. When possible, leverage Free and Open Source licenses (FOSS) or Creative Commons licenses for the work produced. Open Source software has demonstrated that it is possible to make society better by celebrating a technology gift culture (if you want to read more about that, consider Homesteading the Noosphere). By leveraging Open Source, it is really important to communicate to participants that their work is going to the good of the world, rather than toward a company, via some proprietary “hook” ( For Salesforce they were promoting an API when they had their dramatic fail).

The idea is to come together for rapid collaboration for the good of us all.

Replace judges with mentors. The real reward for attending the hackathon is to learn. Find some experts that are willing to teach and guide throughout the hackathon, rather than to just sit in judgment at the end. A lifeline of sorts. We want people to learn and grow, and attendees should be prepared to both learn and to teach. We are not looking to see who has the best skills or who is the smartest. We want people to work together and become better while helping others in the process.

Be student friendly and celebrate ignorance. While attendees should be willing to teach what they know, try and make your hackathon friendly to those with little-to-no experience. For our hackathon, we have developed a series of tools that can allow anyone who has basic computer skills to contribute. To be a useful hackathon, you might have to make requirements about who can attend, but for the most hackathons, you can assume that anyone who is actually interested in attending probably should be allowed to attend.

For those who are near Austin next week, I’m inviting you to our Hackathon on October 19-21 at the Capital Factory. Food will be provided. You’ll have the chance to work with some incredible healthcare equity experts. And we won’t run you into the ground or milk you for your work.