'Every good piece of software starts by scratching a developer's personal itch', says Eric Raymond, author of the fabulous book on Open Source software,
The Cathedral and the Bazaar.
Hackathons evolved to harness that personal passion of s
oftware developers to create interesting code that solves problems - or sometimes, just create elegant, interesting code simply to see what happens.
Organisers provide a context - for example software platforms such as
Ushahidi that constantly need to to be improved or movements and campaigns such as
development data or
aid transparency which need lots of programmes to import and aggregate data or present the data in a form usable by others and the public - and a space, with coffee, cakes and chocolate. Developers who enjoy working individually or in teams and are moved by the spirit of the organisers come together and have fun.
The Research to Impact Hackathon is
different in significant ways to a standard hackathon. Firstly, there is often criticism that these events produce a lot of interesting but unfinished code, which is either taken over by the sponsor and developed internally or simply abandoned, with the developers un-engaged in the follow up. The sponsors of this event,
IDS/ELDIS and
CABI/R4D see this event as
Phase One in a longer term process. They are providing small prizes for the best products but committing larger sums to supporting the development of particularly promising ideas and prototypes that have the potential to increase the use of research data.
Secondly, we wanted to provide focus to the developers based on an informed understanding of
specific challenges faced on the ground, in East Africa, by those working in agriculture and nutrition, challenges which constrain the use of development data and opportunities it offers to enrich the development process. However, we had to steer carefully between being too directive of the developers - which could reduce creative and risk appearing to be asking for some free labour to help large organisations solve their problems - and not providing a clear enough set of scenarios.

So we were a bit anxious about how
Day Two of the Hackathon would develop, especially since we were joined by some new developers who hadn't had the introduction to the
personas, challenges and triggers which emerged from
Day One of the Hackathon nor been part of the Ideation session. We should have known better: we are in the
iHub, in Nairobi, Kenya, at the centre of a vibrant developer community, supported by the ideas and contacts of
iHub Research. Many of the participants had been trained in mobile application development at the
mLab - yet another source of energy within the iHub ecosystem (and the
iHub is not even three years old!). And all the developers were in some way or another connected or developing software solutions to the needs of those in the agriculture value chain.
We introduced the data available from
ELDIS,
R4D and other relevant open data sources, including the
World Bank's data site and the rapidly growing
Kenyan Government OpenData portal; the ways to access the data through the
ELDIS open API and the tools which
Tim Davies is developing
to access the data, including in Linked Data formats. Finally we introduced the
personas from Day One, together with the ideas which had been rated as having the highest potential impact and most viable as the basis for developing a Proof of Concept in only two days (and nights!).
Chaos of the most productive kind ensued. People discussed ideas; formed, and reformed, teams; ate sausages; asked for more information about the
personas; drank coffee; got support in exploring the data and learning to use the access tools available; fed-back ideas for discussion; storyboarded and planned; ate cake; began to hack. By the end of the day four groupings of ideas and people had emerged, all interesting and within the frameworks we had established, and some with the beginnings of demonstration code - either created or imported. Then we went for beer.
Day Three is a
hack-day: teams will continue working on their ideas, preparing for a presentation on the morning of the fourth day, in some kind of Dragon's Den format. While the progress has been remarkable for two days, the acid test is, of course, what the teams can present on Day Four. Given their commitment to the longer term, the organisers are looking as much for coherent plans and realistic assumptions as finished code - but
watch this space.