Just yesterday I came back home from the first Europeana Hackathon! I’m still a little bit buzzed… The event went off on Friday and is the first of what I hope will be a few more this year. I thought I’d share some of the lessons I feel I’ve personally learnt when it comes to arranging a hackathon (or hackday) and how I see how the hackathon fits into our product marketing strategy. Please feel free to add comments, corrections and sage advice!
When the first version of the API was developed in late summer last year we (our little API-team consists of myself and my colleague Milena) ran a closed beta phase where we approached member organisations, the ones we hoped were likely early adopters, of the Europeana network to develop pilot applications based on the API. The reason we did this was that we wanted the launch of the API to the full network (about 1700 GLAMS and other organisations) to be accompanied with a number of in production applications or prototype applications. In turn, the reason for that was that we were aware of how abstract and vague the notion of APIs were to many stakeholders and decision makers within the network. So we wanted to the potential rewards of a Europeana API to be tangible and clearly outweigh the risks.
During the Europeana Open Culture Plenary in October last year these beta applications were first presented to the network. The results of the beta were positive so we decided to go live with the API early this year. And so it did, after some delays, in February with a “pre-populated” applications gallery.
We had also decided last autumn that we wanted to host a hackathon focused on the API and coinciding with the launch. Our thinking was that this would provide a maximum of buzz for the launch. For various reasons we weren’t able to accomplish that and instead the hackathon was held now just about a month after the launch. I still think that holding a hackathon coinciding with a launch or a major upgrade of an API is a really good idea. Not only for the buzz, the enthusiasm, and the resulting prototypes, but also because a hackathon really puts your API through its paces – ruthlessly revealing flaws in both design and implementation. As I learnt to some embarassment during our recent hack!
Despite deciding we wanted a hackathon none of us in our little hackathon team (myself, Milena, Vanessa and Dasha) had ever attended one, even less so arranged one! So we did our (web) research, went to two hackdays as observers and also interviewed Ton Zijlstra who’s organised a number of Open Data hacks. Based on that we planned our hackathon. Some of the guiding principles are listed below.
Some practical do’ s we managed to stick to (I think!) in planning and execution:
- Location, location, location: Choose a venue both practial and inspirational. The Sound and Vision Archives in Hilversum were certainly that!
- Use your informal networks to invite developers
- Pay special attention to developers and organisations you’ve identified as potential high-priority API clients
- Keep the number of non-developers low
- Set an informal and open atmosphere
- Have a competition and prizes, but keep it all in good fun!
- Provide some gifts for all participants, no matter the competition
- Encourage the developers to team up
- Keep the developers sugared and carbed up!
- Provide some optional and inspirational lightning-talks and other small breaks in the “hacking”. Some, not many.
- Suggest some themes for development
- Encourage the developers to work with what they want and ignore the development themes should they want to
- Keep a Twitter stream (following an announced hashtag) during the event and project it on screen in the “bullpen”
- Plan how to publish and make PR for the results beforehand
- Plan for evaluation of the event to improve the next one!
Some practical do’s we failed with and will do with better next time (I hope!):
- Provide online forums, wiki, e-mail lists or similar prior to the hackathon for the developers to use to discuss ideas, ask questions and form teams before the event
- Plan developer introductions and a quick scrum unconference style at the beginning of the hackathon to identify development themes and team up
So how did we do overall? Well, I think all of us in the API-team were happy with the hackathon! I know I am. And I’m certainly very happy with the outcomes in the form of the 15 or so prototypes that were demoed at the end of the second day. Ultimately though the people who’ll decide how we did are the developers. So please if you attended the hackathon please comment and tell us where we did good and what we could have done better!?