Young Rewired State in New York

In July this year (2013) we brought Young Rewired State to Queens in NYC, to the Museum of the Moving Image. Have a look at what was built and the Eventifier synopsis of the event over on the Young Rewired State website.

But I wanted to just write a blog post about the more human elements of the hack.

The idea of taking Young Rewired State abroad came from being asked so many times to do so – I wrote a couple of blog posts about how we hoped to do this and now we have done it.

Did it work? YES!!

Did we find 50 coding kids in New York? YES!! More than 50 in fact but it still took a good 10 weeks to find them one by one, it was not easy

Did they understand Open Data and manage to build stuff with it? YES!!

What was more remarkable was that this event was *exactly like the first YRS event we ran in 2009*. Even the stuff they made. Even the kids lying about their age to get in! I love that… meet Ian McJohn age 12 (or 14 depends… watch right to the end) and one hell of a brilliant coder, articulate and destined for big things I say:

We were very blessed in New York with the very best mentors from Code for America and beyond to partners from Mozilla Hive and the local open data coding communities. We even had the lovely Robbie Clutton, one time colleague from the Guardian and YRS mentor from years gone by, now being fabulous in NYC. In this video, Ashley Williams talks about her own experience growing up as a developer and how important it is that things for communities like ours to exist for young coders. Ashley is ace and is coming to be a superstar judge at next week’s Festival of Code (we are very lucky), here she is:

One element of the YRSNYC event was that the UK kids were able to remotely mentor through the hashtag on twitter and the IRC room we had set up. Twitter was definitely not the US kids medium of choice, they all looked slightly horrified/disdainful that we suggested using it! But some were reluctantly persuaded… Facebook is definitely their preferred social channel, but ultimately the simplicity and dev-friendliness of IRC wins out every time. We will continue this joining up of the communities as we roll out YRS Everywhere across Europe and America.

The hacks that the kids produced are listed here and as you can see are hugely varied and inspired, and next year we are coming back to NYC to bring this community back together again in several areas across the city, once again connecting the local kids with their local city data and each other. Anyway, here is Zachary, one of the members of the Best in Show winning team (who will also be coming to YRS Festival of Code 2013 as a part of his prize):

And finally, how can I not mention the girls – we had a 50/50 split throughout the weekend, which was absolutely amazing, and we had not even tried – so thank goodness for that. I shall leave the last word to Nadine (I dare you not to smile with her)

Onwards now to the Festival of Code next week and then YRS Berlin in September…

We were only able to make YRSNYC happen due to sponsorship from SAP, Twilio and the New York City Trust, and partnership from the Museum of the Moving Image and Mozilla Hive. What we do is not for profit but does cost something. If you would like to sponsor our YRS Everywhere Mission please get in touch with me for details of impact and reach.

How hack days have grown up

For the past five years we in Rewired State have been running hack days. Initially to encourage the UK government to open up its data, removing the fear and uncertainty of what developers might do with the information once it was made available with no limitations. Now we run them for all manner of organisations, from media giants to corporates – as well as a continuous symbiotic relationship with central and local government

To briefly describe a hack day in 2009 it was usually a weekend with a number of software developers in a space with spankingly good wifi, some data, pizza, beer and a few dodgy prizes awarded to those who got the most claps, gasps, cheers or laughs. They were informal events that brought together groups of people and individuals who would never usually have time and opportunity to meet. The results, the prototypes, were less important than the community activity for the developers, and the meercat moment for the sponsors or people for whom the hack was being produced.

As with growth of any idea or concept, as Rewired State has continued to run these events so we have refined and learned what we do to make it better for developers, better for clients and to refine outcomes to meet the need that sparked the hack. I hope that by sharing this updated learning with you all now, it will help.

Here is how a hack day looks to us now in 2013

Ideation

We found that we were spending more and more time with clients refining the actual challenges being laid down to developers during the hack. It has always been profoundly important that hack days do not turn into bootcamp for building prototypes to a specific brief. In order to enable the unique collaboration, the creative ideas, the spark of solution that generates a number of prototyped digital ideas that resolve a particular issue – it is essential to define the problem first, not design the solution.

We advise that hack days have three of four challenges laid, and the associated data made available.

In order to define the challenges, the problem must be identified and this usually requires the meeting of several people on the client side of the hack. In Rewired State we spend the majority of our time initially with the client shaping these in such a way that they are clear enough without be prescriptive about potential solutions.

The Hack

Our hack weekends are hugely crafted in order for them to be simple and open. It takes us at least eight weeks from woe to go to get everything in place, including the developers. Luckily for us our network of devs and designers is made up of over 1000 people who can create working prototypes in 36 hours or less. So we have a hugely talented pool of people we can draw upon.

We take time to initially invite specific people from this pool to try to make up a group of people at the hack made up of 50% devs with expertise and experience of the field we are focusing on, and 50% with no experience whatsoever. We find that this mix tends to create realistic yet innovative ideas, without stifling creativity. And then we open the hack up to anyone who would like to join for whatever reason – we don’t second guess peoples’ passions!

The end of the hack event will produce ‘winning’ solutions for each of the three to four problems laid out in the beginning.

Modification days (Modding days)

It was becoming clear to us as we grew up that clients were increasingly wanting to take ideas forward from the hack, as the solutions were what they had been looking for. As we in Rewired State are committed to not becoming a body shop for developers, others are doing this perfectly well, we needed to find a way to enable prototypes to be taken through to product, with the teams who had come together in a perfect storm to come up with the concept in the first place; (often people with full-time jobs and geographically separated).

And so we created a modding process: the selected prototypes from the hack day would go through a process of development whereby the client would feedback to the dev teams on what would be useful to change or adapt, followed by a day or two of scrum-style programming and design, on all three or four prototypes so still a ‘hack’ format everyone is together again, followed by client internal review and feedback, and so the iteration process continues until the products are ready for the client to adopt.

When you don’t need a hack day – we have Rewired Reality

Clearly the hack days we run cost more than sponsoring beer and pizza, well the problem-solving ones do, and so sometimes people come to us thinking they need a hack day, but don’t have the time or money necessary to get the benefit from full-blown physical event. And so we created Rewired Reality, where we have a number of our Rewired Staters and Young Rewired Staters behind an online board. Here is how it works.

IP and money

IP is always the question that must be resolved up front. We are careful to ensure our community of developers feels like they are having fun as much as building solutions to real problems, and so we try to strike a balance between commercial hack days around specific problems, and those where it is just for fun (where we have found some amazing data being released that they would enjoy having a go at, or for a cause that we know touches the hearts of many).

For the former, we pay developers for their time. They are paid to attend hack days, they are paid for modding days and in most cases, the client will retain the IP. But they don’t always, in some cases they are happy for the developers to keep IP, so there is no real defined rule, but it has to be discussed and agreed in advance.

For the latter we don’t pay developers money, but we do provide a well-run hack, with good healthy food, some pizza usually thrown in, fun and frivolity. And they keep their IP.

This balance works for us right now, it may well change as the hack day continues to grow up.

Hack day Prizes

Originally hack days had some token prizes, often deeply ironic or just downright funny. As they began to become a thing outside of the developer-only zone, prizes became more valuable, cash sums or shiny kit. For a while we grappled with this – trying to strike the right balance.

A high sum of money would skew the attendance and reason why the hackers chose to come along, change also the dynamic of the event, less collaboration and more secrecy, and attracted a different kind of developer, often entrepreneurs with an unwilling and exhausted coder in tow. Not what we are about at all!

A low sum of money could be seen to be insulting.

So we try to avoid financial prizes.

“Stuff” is always hard, because it is tricky to second guess the number in a hack winning team, and if an individual but amazing thing is donated, such as a 3-D printer, how does a group of four strangers who have come together to create a prototype over a weekend, share that?

So we try to avoid “stuff”.

Experiences are good. Vouchers are good.

But actually, the conclusion at the moment is that we need to make the hack weekend itself so enjoyable that it is about that experience and not the prize – for our open and non-commercial events. Prizes more in line with the original ironic/playful times and a well-stocked bar at the end.

We do not award prizes for the winners of commercial hacks as the process continues through the modding days. but we maintain a consistently high standard of service to those devs who come along.

With thanks to Hudson Hollister who presumed that I had written all of this up and shared it, ad nauseum, as did I. But then I realised that this was all in my head, or in my conference slides, which is no use to anyone.

Young Rewired State – an update

For any of you who are unaware of Young Rewired State, here is a video from this year’s Festival of Code

To date we have made it our focus to find and foster every child in the UK driven to teach themselves how to code; to support them through community and peer-to-peer learning, and introduce them to open data, primarily open government data. If you would like to read up more on what we do and why, here is a White Paper written by Dominic Falcao, a student at York University.

So we have come far in the last four years and as we enter our fifth year we really are going hyperlocal and global – as I mentioned in a previous post.

Since that post I have had some very great discussions with developer communities in several regions outside the UK, including Berlin, Amsterdam, New York, Kenya and San Francisco – and the narrative has become more clear, why this is so important and how this very well could be the beginning of a game-changing, independent, worldwide community.

Let me explain…

The idea is to start as we did in 2009 in the UK with one weekend in a number of International regions. Find 50 local children, aged 18 or under, driven to teach themselves how to code, and introduce them to open government data in a traditional hack-style event. During these weekends these young programmers will be mentored by their local coding community, as they are in the UK, but as well, they are remotely supported by the worldwide members and mentors for YRS, through twitter hashtags and IRC channels.

If history can repeat itself over the following five years, each of these first 50 will continue to be mentored and add to their number, growing to 500 in five years, maybe more – and then becoming hyperlocal.

The dream is for a child in Berlin to find it completely usual to be supporting a child in New York, for example, with a local civic problem, or just in their learning. For them to grow up expecting and understanding open data and open borders. And almost more importantly to be forever a part of a worldwide community of like-minded people – never again coding alone.

The beauty of this network is that it is so local, we are working with established developer networks and organisations in all of the countries, and as these children become 19 they *typically* fold back into Young Rewired State as mentors. This is important as it creates a support network for teachers and educators worldwide that is so needed.

We work also in partnership with those organisations teaching young people to code, giving them somewhere to continue the learning through collaborative, peer-to-peer education that can scale according to talent and desire.

YRS Scotland

This weekend sees the very first of these hyperlocal events in the UK, with a group of young programmers in Scotland starting their YRS journey. You can follow the action and add your mentor support by following the hashtag: YRSSCO2012 on twitter.

I really do believe these children can actually change the world, and I am grateful to the huge community who have supported us in the UK and overseas to get to now.

We are run as a not-for-profit social enterprise. Here is how you can get involved

Types of hack day

A year ago I wrote a blog post: What’s the point of a hack day? You probably need to scan that and this one: What is a hack day?

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…

What’s the next challenge for Open Government data?

So three years in to data.gov.uk and the inaugural National Hack the Government Day and now there is a tick box exercise to “run a hack day”… please… someone… anyone?

Open data is not about hack days and running one does not achieve “engagement with the developer community”.

Background

I met Liz Azyan today. Someone whom I have been aware of for the last few years: blogs great stuff, is principled and keeps herself gainfully employed with a plethora of socially ethical social media support (if you know what I mean).

I was blindsided by her, she is awesome and I think really trying her damnedest to do the right thing in an environment that she totally understands, but with a community she is less accustomed to – yet. Watch this space, and government data geeks: I urge you to chat to her if you get a chance.

One of the questions she asked me today was: What is the next challenge for open government data? So thank you Liz for the inspiration for this blog post, it got me thinking about something I have not thought about much, recently.

The environment

Government has opened up quite a bit of data through data.gov.uk, and has encouraged engagement with keen developers who have been hankering after such information for years.

Industry too has embraced Open, with a small number of notable businesses throwing open their data doors, with good results. I wrote a post about this, I shan’t repeat myself and bore you.

APIs are being released almost every day – developer information overload has maxed out, and now we risk lethal developer apathy.

Developers have attended hack days, meetings in Whitehall – indeed many of them have joined AlphaGov. This is all fabulous; but not scalable to the extreme that the open data dream promises.

The challenge

Making it all work.

It’s all very well having developers working away with this data, but if government is not ready for it, it’s a waste of time.

Take just one example: two incredibly talented developers worked together over the course of a weekend hack last year, coding through the night to create a notification engine for the government Tell Us Once programme. It worked, it would have saved oodles of time and bucketloads of cash – but government was simply unable to implement it. This is one simplified example of 100s of apps created by Rewired State hack days alone, and there are many others.

Now, if you can imagine for a minute being a developer, donating your time – granted, sometimes the hack days are paid, but always weekends away from family – year on year creating apps that would help government and citizens. Solving problems time and time again – quick example, every year the Young Rewired State coders create apps to help them define safe routes to school/friends. Year on year we showcase these to the Home Office – nothing happens. Still no government supported/approved app to meet this obviously critical need.

Why would you bother?

Open data? Awesome, and we are making tracks.

Open Government? HARD, and we are not banging on that door yet.

The reality

The developers who work on government data often do so either out of personal frustration, or a genuine commitment to making the world a little bit better.

Rarely can they reach an audience that would benefit from their app/widget/website on their own and in their spare time, at least not without considerable support. Nor are they doing this for profit, so they are not going to get investor cash.

Helping government do its work better is not a good proposition for your typical angel or VC – the target is government; and only government can utilise the genius that they are being offered.

Lots of tiny arrows

Right now lots of tiny arrows are rained on the government portals day on day, by an increasingly disparate and desolate group of extremely talented people.

Is there any success anywhere? No. Well unless you count the oft-reported GovSpark created by Issy in Young Rewired State 2010, curated by a plethora of supportive geeks and designers and some financial and hosting support from The Stationery Office. But that was a ‘nice to have’ addition to a Prime Ministerial commitment. It was not a revolutionary way to interact with central or local government.

So what’s the next challenge for Open Government data?

Forget the data.

Find a way to enable these revolutionary ideas, apps, websites and widgets that save time, money and mind-numbing frustration from those who have to engage with government.

Do that, and only that.

And when you have done that – then engage the developers again around your open data through hack days, geek advisory boards or whatever means you can.

Until then, let them have a break. They’ll still be there if you do this. If you don’t, they won’t.

And that is ridiculous.

Also, please don’t insist people ‘do hack days’ for you. Here’s the point of a hack day.

What’s the point of a hack day?

I get asked constantly what my favourite app was that was built at any of the many hack days I have run through Rewired State. I am often ashamed that I struggle to answer, although there are many. This is because hack days are rarely about the prototype.

To cover briefly what a hack day is, it is:

• one or two days long (often belying the name)
• any number of developers, for me a minimum of 10 devs are needed to make it buzz a bit, but 20+ makes it exciting
• a subject, challenge, dataset (the broader the better)
• developers are given a brief of the subject or challenge at the beginning of day 1
• they code/design/engineer over the course of a free form period of around 24 hours to create prototype solutions or ideas
• they present back to their hack peers and any inquisitive viewers, as well as the sponsor, client or group who put the event together
• prizes are awarded
• beer and pizza is essential

Many people will not experience a hack day, but if you can, please do. Show and tells are usually open to anyone who wants to attend and twitter and lanyrd are quite good at curating such event information.

However, the reason for this blog post is to explain the point of a hack day, now in 2011 (it will definitely be different in a year’s time, but to chart right now).

If you take a little time to look at the above list of what a hack day is you can understand that the common question might be: yes but what did they make and what happened next?

My response to that is that you are jumping the gun.

What we do at hack days is show you the future. Here’s why.

Why do developers turn up?

Well, in the current climate: API bonkers, information overload (yes devs get that too), tablet shmablet, toy shmoy world that we live in, there needs to be a little peace, as well as a challenge. As I have explained in a previous post about developers it is up to the rest of the world not to risk developer apathy (already here IMHO), and to look at what really matters.

Developers are simply awesome and if you know one I dare you to go try your million dollar idea out on them – they will have deconstructed and reconstructed it in minutes. Tell them your *save the world* idea and they will probably risk divorce to build it for you – please don’t do this.

Developers who know hack days turn up for the buzz, the competition and to learn, mainly to learn. Those who have never been to one come for the challenge.

I have been running hack days for three years now, and one veteran of the Rewired State hack days was at this weekends’ hactivate event. He spent the weekend coding a composting app, it’s cool, you can see it and many more here. But the big thing for him was spending 1.5 hours playing with a web server, in peace, legitimately, on a Sunday (and learning). Another group (and this is usual for a hack weekend) were hack day virgins, and have adopted the amaze-balls face of pride at what they can actually build when challenged by time (hack days are ruthless) as well as taking home the contact details of the colleagues who are as talented as themselves, at other stuff.

One developer gave himself this hack weekend as a Father’s day present. To have a weekend to spend with his peers, although coding was his day job, to work on his own projects, surrounded by like-minded awesomes, fed, watered – that’s the point.

Most developers will leave a hack day with new knowledge or at least new contacts, that can lead to extending their ability to deliver the awesomeness.

It’s probably fair to say that most would not admit to being so excited by the non-coder audience blinking at what they have managed to create in a two-day period, nor the prizes showered upon them. And, from those I know, it is always the afterthought – although I am now really clever and spend my life finding flipping brilliant geek prizes that they can’t ignore :).

Which is why it is important to understand all this before you ask: what is the point of a hack day?

What’s in it for the non-coders/organisations/brands?

So, there is an immediate and very obvious benefit for anyone engaging a number greater than ten developers on your own idea/API/bit of kit, and hack days seem to be de rigueur. Is not hard to be confident that good things will come of the weekend.

But is it the list of prototypes at the end? That no good hack day host would ever be able to predict?

No, it is engagement with the development community. Gifting your idea/API/bit of kit and enabling some free time for developers to engage with and over said idea/API/bit of kit. Yes of course you will get any number of good prototypes and even working applications – but better you will get to meet a number of developers, showing off their skills and often their newly acquired ones – this is really as rare as hen’s teeth (usually because they are fully employed fulfilling other peoples’ ambitions) engaging over a dedicated period, with peers they may not have yet met, over your technology or challenge. Yes, your super-sexy next bazillion idea might come out of this – but you created the environment for that conversation, that dev-to-dev spark.

But yet…

The thing I have noted today after Hactivate is that the sponsors are actually dedicated to seeing the apps go beyond the hack day. The winning app was one built to try to address human trafficking, and it was created to make the interface so simple that anyone could take it up without needing access to anything too technical; then we could crowdsource peoples’ safety.

The judges are determined – from a human pov, not only the brand they represented – to help collate the necessary charity network information and wherewithall to make it happen. However the geeks who thought it needed to happen and were so passionate about beating human trafficking that they spent their weekend building an application to make people a little bit more safe, found it hard to adjust to the jump of someone actually taking it on and helping make it happen (within 24 hours). Possibly because they had been coding non-stop for 24 hours, presenting to Press, sponsors and co-hackers – more probably because they were not used to their ideas being taken up so strongly and immediately by the kind of brands that can really make it a reality.

Such is the magic of a hack day.

This is why I love hack days… dilemma 🙂

And so…

The point of a hack day for a developer is to be with like-minded people, work on your own stuff, learn and be celebrated; for the rest of us, it is to create the environment for magic to happen.

Maybe in the next few years they may become simply about the prototype, but I hope that day is a long way off. The point is developers, living and learning from each other in an environment that is created by you: the challenger.

Finally…

As ever, my cry is: please, do not take the piss, developers are for life not just for your *next million* or *save the world* idea. They are an asset to be cherished and nurtured and they do not necessarily always value the same things you do. It is rarely money or jobs – most developers are awash with job offers, and extra-curricular *cash* offers.

Hack days do work, right now, because everyone wins when they are run well and with consideration. But please don’t ask me what my favourite app is that was ever built at a hack day! I can’t tell you, I have no idea. I do however now know 200+ developers whom I would be able to call in a heartbeat, and know their skills, passions and talents – but I would never sell them to anyone.

Developers are a talent to be nurtured in our open data and open society world. Hack days respect this and act as breathing spaces for devs.

It is rarely about the prototype, and when it is, I will probably go buy that flower shop I have been promising myself.