Putting Crowdsourcing In Action

Crowdsourcing is increasing in popularity as a form of distributed problem solving enabled by digital technologies. “The crowd” is invited to contribute towards projects, this contribution potentially being in the form of knowledge or design skills. On June the 3rd this year an interdisciplinary workshop investigating crowdsourcing and citizen science convened. It brought together experts and practitioners from many disciplines that apply a crowdsourcing approach, presenting outputs and how crowdsourcing aids projects from GalaxyZoo (an interactive project for volunteer classification of galaxies), Artmaps (an application for crowdsourcing information on Tate digital artworks) and Taarifa (a platform and community supporting the crowdsourcing of public service issues in the developing and developed world).

My personal presentation was on Taarifa, a project I started in 2011 to support community based public service delivery. Since then I’ve worked in collaboration with the World Bank in Uganda to support the Education and Local Government Ministries with reporting across the country; what started as a pilot was rolled out quickly to cover 111 districts, over a year of an at-scale pilot 14,000 reports were received and acted upon. This resulted into wider research into the wider use of public participatory service delivery in developing countries (FOSS4G Taarifa paper). The uniqueness of Taarifa is that it has been developed and maintained by wholly volunteer contributors, creating free and open source software. The contributors to Taarifa are as diverse as the problems which Taarifa addresses, ranging from PhD Candidates like myself to Physicists, Bankers and Community Organisers. Consequently, Taarifa doesn’t just look after a platform of software; it acts as a forum to share knowledge, experimentations and innovation.

Taarifa was conceived at the London Water Hackathon, as an innovation around water access and quality in Tanzania. Access to water in Tanzania currently covers less than 50% of the country’s population and with 38% of the water infrastructure, like taps, are graded as non-functional. Currently the Ministry of Water has a WPMS (Water Point Mapping System) developed after a countrywide survey. However, the system has is no functionality to update the status of the water point or view a history of service problems. This is combined with poor performance of repairs nationally if water points are repaired; citizens are disenfranchised with current methods of reporting water faults, if they can report at all. The ecosystem around supporting the repair of water points is non-existent; consequently millions of Tanzanians have no access to publicly delivered water.

It is important to stress that there isn’t ‘one’ solution to the problem of water access nor is there ‘one’ platform or software to ‘fix’ the problem. There is no one discipline that can resolve the issue of water access, there has to be a multidisciplinary approach, to a multidisciplinary problem. Cartography, Economics, Engineering, not one discipline can wholly resolve the issue of water access, nor it is an issue which can be researched and resolved through the lens of one discipline. The societal side of technology needs to not be just taken into account, but integrated into the core of the design with the people who face the issue and who will use the technology to resolve it. It is imperialistic and deterministic to assume that technology can just ‘fix’ the kind of complex issue of water access, especially as the technology is, in effect, imposed broadly by outsiders to the community in which it is intended to take root. Hence, an understanding of the community is needed; who the users are, how water access is dealt with currently and the general state of affairs. From this we have created two streams of Taarifa, one that is currently implemented and one that is currently being designed, incorporating lessons learned from initial deployments.

The first iteration of Taarifa’s design story and user action assumed that mobile connectivity wasn’t an issues and that there was an active organisation, be it government or an NGO wanting to resolve water access issues, another predicate was that the water infrastructure was adequately mapped. This led to the following reporting process for a water issue; When a report is made, for example from a Community Water Officer or a concerned citizen, it goes into the Taarifa workflow, which identifies the specific water point from the database. The reporter is then notified, thanked that they have made a report and given an estimation, based on prior time taken to repair broken water points in that district on how long it will take. An engineer is informed what is wrong with the water source. Once an engineer has been selected, a verifier can verify that repair has been completed satisfactorily. Importantly, at each stage the initial reporter is informed about the progress of the repair. This was the version trialled in Uganda.

Subsequently, learning from how Taarifa was deployed and used, the design is now intended to incorporate offline capability and ‘marketplace’ functionality. The offline capability due experiences in Uganda that connectivity wasn’t universal (this was not a surprise, however, improvements to the paradigm should be incremental) the marketplace due to the capacity of local government and organisations. If a district has no capacity to repair a broken water point, the cost could be estimated by a number of engineers receiving information about the problem and they bid using their phones. A micropayment is taken to support the system, providing a surplus, potentially reinvested into creating new capacity. Micropayments are ubiquitous in the developing world, effectively replacing a formal banking infrastructure, hence are familiar to the communities who will use this method. Consequently this should hopefully be viewed as an extension of what already exists, not something completely new.

What does all this mean within the context of the Crowdsourcing in Action workshop? Broadly it allows us, as academic researchers to typify crowdsourcing and understand more. Taarifa acts as a community crowdsourcing code and by extension curating community reporting issues in developing countries. Artmaps develops applications for use on smart phones that will allow people to relate artworks to the places, sites and environments they encounter in daily life. GalaxyZoo leverages the many eyes of the crowd to process space imagery data. Thematically, all the projects presented utilised volunteers to provide information, process it and return it to the user and other interested actors.

After the initial presentations we formed groups, of other experts and practitioners to build a common model of what crowdsourcing means to their projects and work. Then coalescing at periods to feedback practice and information learned from other participants. In doing so, we learn from successes and failures of others, understanding common themes for collaboration.

In identifying these common themes, it hopefully sets an agenda to focus on specific factors and communities under the crowdsourcing agenda. Jeremy Morley and I are planning a future “How to Hackathon” event building “Crowdsourcing in Action”. Hackathons allow volunteers (generally) to co-create ‘hacks’ to problems. In its truest sense you accelerate innovation by combining a random mix of people and skills, providing a set of previously unsolved problems, then observing what happens. As was identified in the Crowdsouring In Action, we can observe the states before crowdsourcing; we can help provide a process for participants; we can observe and process the result. However, an understanding of how participants use the tools to conduct crowdsourcing is scant. By now focusing on hackathons, we hope to discover more on how the design and development of crowdsourcing works.

Prologue to the Sanitation Hackathon

Florian Rathgeber and Fayaz Valli at the World Bank, Washington DC.
Florian Rathgeber (right centre) and Fayaz Valli (left centre) at the World Bank, Washington DC.

Taarifa was announced in various mediums as being a winner of the sanitation hackathon. To this end two Taarifans are currently representing all Taarifans in Washington DC and San Francisco. More will come from this, I’m sure. However, all of the projects of the sanitation hackathon should be given the same pedestal and treatment.

The number of projects and energy that the sanitation hackathon generated should not be lost, and energised by the constant support and coverage;

“The event featured nearly 1000 registered hackers at ten locations worldwide who developed some 62 new prototypes.” – Sanitation Hackathon Site

While this moment is still in the here and now we should all move forward, collaborating, instead of competing. From this solve the technical challenges within the sanitation issues which we face. Undoubtedly, it is a naïve and deterministic proposition to suggest that technology will solve the world’s problems. However, events like the sanitation hackathon have demonstrated that technologists from all walks of life can work together. Building a social side to these systems is a bigger problem than the technological ones, prizes and recognition aren’t replacements and should not be considered replacements for this. The hard work starts now.

Written and submitted in the Hotel Kilimanjaro, Dar Es Salaam, Tanzania (-6.81669, 39.293198)

ICCM RHoK in DC and Hacking for NYC OEM

Phew. Quite a lot of acronyms. So without further ado;

  • ICCM – International Crisis Mappers Conference
  • RHoK – Random Hacks of Kindness
  • DC – Washington DC
  • NYC OEM – New York City, Office of Emergency Management

After the Rethinking Cities conference in Barcelona, I was travelling to DC for the conference for Crisis Mapping ICCM. I was hoping for a continuously eye opening conference from the cutting edge. However this wasn’t to be, see here for wider details. Serendipitously I then got pulled into Code for Change event, hacking for the NYC OEM. They wanted something with a workflow and tasking system that would allow citizens to report problems with fallen electricity lines, snow drifts and abandoned cars and the such like. After a short sprint and a great meet with the guys and gals at mWater it was off to DC for ICCM.

Heather Leeson and Willow Burgh were exemplary in getting a bright bunch of hackers together for the hackathon. I was pitching a new API for Taarifa, following REST-ful principles. The idea behind having an open reporting platform is great, however we also want the data we collect to be open as well. Also we’re starting to look at seriously integrating sensors into Taarifa, so the data can come in from sensors and get pushed out.

Pressor Sensor


Above is a pressure sensor which Sam Wilkinson hacked on during the Washington DC hackathon while he was in Southampton (hands across the ocean!). Myself and Jeremy Baron (good to meet you!) where formulating the API, but were starting out as Django beginners. Needless to say we didn’t get to the point which Sam got in England, however we did know a little more about REST APIs and Django.

Combined with some tablecloth design and interface work – done while having dinner in Front Page Restaurant on Dupont Circle literally on the table cloth! We somehow got 2nd prize in the hackathon. It really shows how the Taarifa community is pulling together, with new taarifans complementing existing ones, across the world. I’m constantly astonished.

Written on the train from Nottingham to London St. Pancras and submitted just before the train pulled into the station (51.5362298,-0.129432)

Mapitude: Open Data, Open Platforms, Open Communities?

(Open) Data Needs Open Service for Enterprise

I was fortunate to be invited to give a talk at Mapitude. Unsurprisingly I spoke about community mapping, spatial data infrastructures in developing nations and Taarifa. I also touched upon open data and how services and platforms using open data need to be developed. I think that open data is great – for more info watch this TED talk by Tim Berners-Lee – however I believe open data is only the beginning not the end point of data development.

We need platforms and services, which are open and free to use for the vast majority of citizens. This presents opportunities for new business models, while the data should be free at the point of service, the costs of collecting and distribution (if not crowdsourced – I’m not implying crowdsourced is free to produce either) need to be paid by someone/something. Data is just data, it doesn’t help improve sanitation or water access but wrapping it into a service or platform could and should.

Platforms and services like Taarifa, Ushahidi and Open Street Map all are very expensive to run, however need to be free for the public good that they serve. I doubt advertising can fully meet the needs and costs – look at Facebook, whereas I believe over a long term grants and loans are unsustainable. A freeium model could be the way forward, tailored around a service being offered which the platform sits on, which is free up to a limit. Deciding on who to charge for an what is a difficult question and would be needed to considered carefully, with questions around licencing and ‘fairness’ paramount. As such the communities which create the open source software which drives the platforms and services need to be part of any decision that takes place and be at the heart of the community and process.

I’m not saying that open source platforms and services using open data need to make a large profit, this is a charitable enterprise after all, the profit needs to be reinvested to support innovation, be it buying equipment, investing in training or paying for hosting. However open data, open platforms and open services need to make money, which can be reinvested in supporting its community, providing free services to those that deserve and need it, while enforcing payment from those that can pay.

Written and submitted from Mokka City, Dar Es  (-6.8162376,39.2885885)

Geomob Taarifa

View more presentations from Mark Iliffe
Taarifa has been going from strength to strength, from pilots in Uganda and Zimbabwe, to talk about going to Senegal and others. As such building awareness in the wider geospatial community is an important step, not just to pull in developers to the project, but raising awareness of the project to a wider audience. Broadly the presentation framed the point that geospatial data is now available (or is coming) for developing nations, therefore we should position our efforts to understanding what platforms and services should be built on-top of this new infrastructure, while continuing to build the basemap. I believe that Taarifa represents one of those platforms, and its future’s bright.

Engaging, Leading/Managing

How do you engage different groups of people and keep people engaged? These people may be some of the most highly skilled and sought after professionals. They could walk into the larger IT conglomerates (The Googles and Microsofts of the world) and name their price. They have families, nice things. So why do they give up their spare time over weekends to work on something they will have known for 5 minutes beforehand, with the potential of pulling an all-nighter. For little or no reward. If there is a reward it’s unlimited coke, burritos and pizza with a dash of chocolate and crisps. I believe they do it for the thrill of the chase, camaraderie and the challenge.

In conversation with a good developer friend he added that “90% of open source software exists because people can’t get any software written at work”. He was quoting a source which I’ve forgotten, but if someone can enlighten me I would be grateful; It’s a great quote!

It brings me on to musing about the dynamic between management and leadership. When I was eighteen I was at a leadership seminar, which for the first hour found very tiring. A combination of ironing and shoe shining the night before with a refreshing run at period zero (circa 05:30). The second hour I’ll remember for the rest of my life. It started with the beach scene of Saving Private Ryan, Tom Hanks gets disorientated coming up the beach, things go numb, then a solider is screaming at him “What do we do now, sir?”. Our hero organises his troops then, from the front, charges up the beach and his soliders follow him. They beach is taken, good guys win, bad guys loose. The end.

This part was led by a guy who, frankly, had been sunk a few too many times in his illustrious career. However he launched with gusto in leading by example, however impressed the point of knowing when to let others take the mantle. Being an exemplar shows to others how to act, even if they’re afraid, galvanising them into taking a deep jump into the unknown. But said leader needs humility to know when they’re not the best person lead and allows others to step up and show the same level of skill.

One of the sayings I’ve across (from my  father) is “Too many chefs, not enough cooks”. In theory it holds, but in practice falls over horribly. Consider a developer team, hungry for success, in all probability educated at the finest institutions on the planet and capable of developing cutting edge software and hardware. Each one of those developers will have ideas on how the project could work better and given the opportunity probably would manage an aspect of the project better. In the context of a hackathon, I think consensus can be reached within the group, in trusting the individual coders, who are giving up their free time, effort and skills to achieve the best they can do. This effort inspires other people and by default, the people that first step out into the unknown become the leaders instead of managers. These people form a nucleus around which the project (with respect to Taarifa, but could easily be a product or service) is built, they lead (not manage) by example. This doesn’t particularly conform to a specific type of programming ethos, it isn’t Aglie, Scrum or Lean, it should just be common sense.

Written and submitted from the Novotel Docklands Hotel, (51.50789,0.02329)

Taarifa: Go Big Or Go Home

Demonstrating any piece of software regardless of its inception is a hard task. You have to understand the group that you’re pitching to, even if ultimately, they aren’t the end user and have little technical inclination. It helps if the group you’re pitching to is enthusiastic. When pitching Taarifa today the group was enthusiastic, engaged quickly and wanted to participate further. I spoke my previous blog about having Fear, Uncertainty and Doubt, though some of those concerns were allayed, some still remain.

The group to which software was demonstrated was a mixed bunch, comprising of field inspectors to managers in charge of implementing monitoring programs. Phones were unboxed the Hauwei (Lady?) Gaga and distributed to the workshop participants. They navigated to the dev.taarifa.org site and proceeded to make reports. There were two universal complaints; the keyboard screen was too small (therefore typing was difficult) and the Android system was using autocomplete . Users did not like when they were typing in something unrecognised by the system that it changed what they were typing, so they stopped. Secondly the feature took up valuable space on the screen. Barring these hardware related issues, participants were able to take photographs and make reports using the custom form provided especially for the workshop.

After this workshop we moved to field trails. After meeting the local administrator for the district our group of myself a colleague and an IT specialist from the Ministry of Local Government demonstrated Taarifa and it worked wonderfully. Taking on the district inspector and other local government officials our convoy delved into the countryside, visiting CDD (Community Driven Development) projects. The idea of CDD is that the local community raises money and the government either matches it or improves it by an order of magnitude. These projects then create a business selling or renting goods and services. Here we hit our first issue; network coverage. I can safely say that the EDGE network isn’t capable of uploading photos in any usable manner. This was expected, though due to constraints of time, a contingency wasn’t planned.

On our third and final visit the stars aligned and with 2 bars of 3G the reporting worked and worked very well. Visiting a local charcoal selling project (making around 100kg a day) the inspectors where able to file reports in a consistent manner without paper and repeat form filling. They really liked it, and wish to use it further. They like it so much that we’re now going to Northern Uganda, near the border with South Sudan to trial the project there.

What have we learnt? Taarifa has performed well in the face of an expectant and demanding crowd. The progression depends on a few factors both technical and operationally. The technical factors are ‘simple’, fix a few bugs, add an improved export functionality and allow reports to be submitted when ‘offline’. Bug fixing and exporting requires time, the offline feature is both time and a bit of HMTL5/Javascript knowledge. Not exactly low hanging fruit but it’s reachable. On the operations side we now need to consider how the Ministry (or other government agencies) host and support the project. Friday is dedicated to this, to ensure that what we’re doing isn’t a flash in the plan but that it transforms in a fully sustainable and used system.

Written and submitted from the Kampala Sheraton, Kampala, Uganda (0.3145283,32.5828674)

Engaging All Users, Not Just Developers

Taarifa is entering its endgame. Over the next week two workshops and two field tests will determine how the Ugandan Ministry of Local Government see the platform and wish to move forward with it. Currently there are three users, all with unknown requirements; the local civil servants (reporting), the national civil servant(s) (administrating) and the ministry (data users).

Currently the group which has been engaged the most are at the ministry level and as such dictate the forms and data-structure of the data which is to be collected. Taarifa (taking functionality from Ushahidi) is able to customise forms for data collection, in early stages it seems that Taarifa is being used to replicate forms directly, with – IMHO – a lot of unnecessary information. This boils down to asking what data the ministry actually requires to complete their job and that they use, instead of collecting data for the sake of it.

The Taarifa community is composes developers worked hand in glove with experts in water, sanitation and other fields. This brings a unique opportunity to design and implement software that focused on endemic issues not flashpoint crises. Taarifa could be badged as an e-government platform but goes beyond that in allowing two way interaction between government services and the citizens. This good on paper, however the platform is being demonstrated to the Ugandan Ministry of Local Government tomorrow. Engaging with them to better understand how existing functionality will fit into their workflows and what they further need is an important step and not one that should be taken lightly.

We already have buy in from the administrators on the system, now we’ve two user groups to get on board. This will be done with a series of workshops first with the Ministry then with the end users in the remotest parts of Uganda. We need more time for development, more time to understand the users and more time to operationalise. I have some fears, uncertainty and doubt. We have some bugs, and some misbehaving ‘features’. But the Taarifa platfom and community has come a long way since the London Hackathon. A roadmap is currently in production with ideas for big data visualisation. We’ve ported the code so the UI on a mobile device far outstrips known competitors (in our opinions!). This the future of Taarifa however this is pilot, and that time is now. Go big or go home. Yes, I’m a long way from home.

Written and submitted from the Kampala Sheraton, Kampala, Uganda (0.3145283,32.5828674)

Community -> Hackathons -> Software Shipped -> Repeat?

Taarifa inception as hackathon project makes it special through it’s continued existence. From speaking to peers it seems that many hackathon projects are to create ideas not code. Fortunately we’ve stuck together, widened the community and now have members of the Taarifa community working on it for their dissertations, myself with my job within the World Bank deploying an instance of it to Uganda.

Within our own community we’ve got developers across the world working on little bug fixes and functionality. One member has taken on improving mobile UI upon himself and now the mobile web app looks brilliant on a mobile phone screen, decluttered from unnecessary components with things like inline labels ensuring things are ‘better’ on a phone. This is building upon a hackathon held at Shoreditch Design’s office where we shipped Taarifa 1.0.

With the forthcoming Uganda deployment (and potentially other applications) we have the opportunity to test and refine certain components. However building capacity in places where this is deployed is important. We hope by demonstrating Taarifa in developing innovation centres we can seed the ideas and principles of Taarifa (and by extension open source software) with them joining our growing community. This in turn would provide different perspectives on the requirements and ultimately filter down into software releases improving it.

The community is currently in the process of writing a Taarifa API consisting of entirely new code. We’ve just deployed a Q&A site on help.taarifa.org making it easier for users of Taarifa to ask questions and be a knowledge base for future users, avoiding the ‘goto github’ mentality which – in my opinion – should be for developers. Currently Nico and I are working on screencasts to give short introductions into installing and using the Taarifa system. Onwards!

Written and submitted from the Leicester, UK (52.6352614,-1.1378884)

Moving Past The Hackathon

A hackathon is a wonderful thing for any project, be it a community driven project like Taarifa or something that ships ‘professionally’. The idea behind it is simple, get hackers in a room, ply them with food, drink and ideas and 48 hours later reap the rewards of their work. The problem is it’s not often where a project continues after the hackathon. Taarifa in many ways broke that trend, by its developers continuously communicating, adding code, patching bugs and the such like.

We were joined by new developers, some who were corralled into the project by the original developers, other brought in by friends of friends. Taarifa as a project is getting bigger! Assembling for the first hackathon since the first we sought to address problems caused by new bugs and already existing ones. One of the mistakes of many coding projects (especially ‘hacks’) is that the developer is in the mindset of putting in new functionality before fixing known bugs. Bugs are always going to be found, but you’ll be building upon shifting sands if you don’t fix what you already know. Simply because when you go back and fix old problems, they’ll often break newer code down the line.

Part of this is about making it easier to develop and the code base ‘better’. At the original hackathon we took the Ushahidi code base because of the functionality which was included out of the box. We hacked it to make something that looked like it was working. However we now realise that this wasn’t the best strategy for sustainability. Though what we had done worked, it was not ready to be deployed and put into release. The opinion of the developers on Ushahidi’s code base, using the Kohana framework wasn’t good. Finding something as simple as a HTML header took two developers a few hours to resolve with more complicated issues requiring a ‘strong investigative ability…’

While this bellies the importance of documentation, sometimes this isn’t enough. Making code simpler and easier to use isn’t just good for new people joining a project, it’s good for your existing development team as well. In the context of a hackathon this is really important because time is also a consideration. In Taarifa practically all the ‘significant’ code base has been written in these two day sprints, and we’ve only had two events. To engage more developers and contributors in the project we now need to work on communications and other non-code matters. Now we’ve a bigger and more engaged community than before. We have contributors from many countries around the world, an active mailing list, github repository and live demo and development sites. To coin a ’90s phrase: the future’s bright. The future’s Taarifa.

Written and submitted from the Isle of Dogs, London, UK (51.487291,-0.0183036)