In it I said that it would probably be different in a year, and to some extent it is, but one thing will never change, and that is how you should treat developers. Enough has been said on twitter today about the Cadbury hack and in my head a few weeks ago about the Hack for the high street event – both of which are hack days with the sole intention of the attending developers building an app for either a specific event or for a bunch of businesses, for free, or for props and chocolate.
This is wrong, but I am not being helpful in just saying so, but I must make it clear: I believe this is very wrong.
Thayer Prime has written an excellent blog post about how dangerous this is from a PR angle when you are a large, rich organisation, I would like to update my post from last year to reflect how I see hack days being legitimately used these days:
Hack for a cause
An open hack day, available for anyone to come to where there will typically be decent prizes at the end of it but developers are not paid. Organisation of such an event may well be sponsored to cover beer, pizza, hosting and whatnot but the developers are free to build whatever they fancy, or not if they just want to be there. Apps can be showcased but IP of idea and code remains with the developer.
Hack events like this are very effective for creating meercat moments in entire industries, most recently I saw this happen with the TV industry at the TV hack in Cannes and has been most notably successful with music and open government data.
Hack on new kit or new data/API
Some organisations need developers to engage with their new piece of kit or play with their new data. Hack days are great for this – but developers should be paid something for their time and IP for anything they make at the event should remain with the developer, both code and idea. Prizes should be awarded in addition to the payment to devs.
These are very successful and most recently I can cite the GLA hack day as a good example of this – devs were paid to explore some of the newly released London data sets during the typical two day hack setting.
Hack days as research and development
These are growing in popularity. Whilst they are expensive – you must pay developers the market rate – the expense is nothing compared to a typical six month round of R&D that would result in an awful lot less than a room of 20-30 developers, pizza and focus over 24-48 hours.
The end of these hack days produce prototypes that the commissioning organisation can take back and plug into their own developments and decision-making processes. Whenever we run hack days such as this we would have an agreement with the commissioning organisation and the developers in advance that the IP would fall into one of the following categories:
- IP for idea and code remains with the developer
- IP for the idea passes to the client
- IP for the idea passes to the client but the code is open-sourced on GitHub for the client, or anyone, to reuse
- IP for the code is passed to the client - this costs more than the above two options and we make arrangement directly with the developers to agree this sum as effectively the developers are working on direct commission from the client and should be paid as such at their usual rate
A successful example of using a hack day for R&D would be most recently with UKCES where they used an R&D hack day to test the build of their API. At the very beginning of the build they tested the API with the developers to see whether it was doing what it needed to do in order for developers to work with it in the future.
Hack days alongside conferences
These are interesting, and it depends on the conference as to how this should be handled with paying developers or not. The premise being that there is a conference on a subject that can be brought to life as the conference progresses by running a hack day alongside it really bring the subject to life, maybe even solving some of the more common challenges faced.
My rule of thumb would be that if the conference is aimed even in part at the developer community and they would be attending, or make up some of the audience, then an open hack day format alongside the conference is a great idea. If the subject is not naturally one that would attract developers, say the Cadbury conference on cocoa production or whatever – then a hack day alongside the conference would be an excellent way of bringing it to life or focusing on one particular challenge or problem, but the developers should be paid.
An example of a successful hack day conference would be Hacktivate that runs alongside Activate.
Marketing hack days
Some organisations come to us and want a hack day on order to have something interesting to talk about for their advertising campaign, or to align their brand with the perceived hack celebrities, the brogrammers and geeky chics. These are all good things – but they cost money.
An example of this is the Honda hack. Honda were launching a new Civic and wanted to align their brand with everything that sat under the umbrella of Power of dreams. What better than a hack day for doing such a thing? It was treated in the same way as the R&D hack days I spoke about above and after the event ran they relinquished all call on the IP to anything and still paid the programmers and developed the winning prototypes.
They had plenty of content to write about, point to and they had engaged with a community that did interesting things with their brand beliefs.
Hack days for app building
These are becoming more common, are the most dangerous PR-wise and if you want your app/s built for free, are alienating you from powerful members of the digital community. Believe you me the developer world is a small one, and your reputation will spread fast.
If you want an app built for your organisation, event or brilliant idea – pay a development team. If you are not sure what that app looks like and you want a number of developers to come up with some options for you – then of course, that can be done through a hack day, but it should be paid work.
Polite things to do
If you are running a hack day that falls into any of the above categories where developers are not paid, then take very special care to:
- ensure you take care of every detail and meet all caffeine and sugar needs in a timely fashion
- offer travel reimbursement if you can
- have excellent, excellent prizes
- have lots of staff on hand to make sure the devs volunteering their time and talents feel appreciated
- enable the developers to be showcased to the best effect – be super-organised about that
Needless to say, Rewired State run hack days in all of the above categories. I am writing here after four years of making mistakes and learning from them, so trust me, I have learned this the hard way. Things are of course changing constantly, but there are some things that never change: don’t take the piss.
And before anyone picks me up on the charity hacks that we run, that is exactly so, we do run occasional hacks for charitable causes where developers do work for free, but we call on our own developer community for this and are very, very careful about what is being asked, by whom. We did this most recently with Refugees United and it was a humbling experience for all of us. But we are in the very fortunate position of being four years old with a robust and sizeable developer community of over 600 people that we can call on, and reward, as a group throughout the rest of the year.
And finally, whilst I am on this subject, Matthew Cashmore pointed out on twitter that the term Hack Day has been replaced by Hackathon on Wikipedia. MC has a *lot* to say about this and I concur that it is appallingly lame and something should be done to stop this march of mediocrity. A hack day is a hack day, has always been known as such. A Hackathon is a term coined by those who are scared that people will think a hack day means people will do bad things. Personally I can’t stand the term hackathon and will never run one – get it *run* a hackathon… I’ll get my coat…