This blog entry was inspired by Ory’s recent blog post on “Covering the DRC – challenges for Ushahidi.” The thoughts that follow were originally intended for the comments section of Ushahidi’s blog but they surreptitiously morphed into a more in depth reflection. First, however, many thanks to Ory for taking the time to share the team’s experience in the DRC over the past few weeks.
Much of what Ory writes resonates with my own experience in conflict early warning/response. While several factors contribute to the challenge of Ushahidi’s deployment, I think one in particular regrettably remains a constant in my own experience: the link to early response, or rather the lack thereof. The main point I want to make is this: if Ushahidi addresses the warning-response gap, then Ushahidi-DRC is likely to get far more traction on the ground than it currently is.
To explain, if Ushahidi is going to provide a platform that enables the crowdsourcing of crisis information, then it must also facilitate the crowdsourcing of response. Why? For otherwise the tool is of little added value to the individuals who constitute said crowd, ie, the Bottom of the Pyramid (BoP) in conflict zones. If individuals at the BoP don’t personally benefit from Ushahidi, then they should not be spending time/resources on communicating alerts. As one of my dissertation committee members, Peter Walker wrote in 1991 vis-a-vis famine early warning/response systems in Africa:
It must be clearly understood that the informants are the most important part of the information system. It is their information […] upon which the rest of the system is based […]. The informant must be made to feel, quite rightly, that he or she is an important part of the system, not just a minion at the base, for ever giving and never receiving.
In 1988 (that’s write ’88), Kumar Rupesinghe published a piece on disaster early warning systems in which he writes that civil society has
… a vital role to play in the development of a global, decentralized early warning system. They now need the capacity to build information systems and to provide the basis for rapid information exchange. In general [civil society] will have to confront the monopolization of information with a demand for the democratic access to information technology.
Information on local concerns must be available to the local structures in society. The right to be informed and the right to information have to find entry into international discussions.
Ushahidi’s crowdsourcing approach has the potential to reverse the monopolization of information and thereby create a demand for access to conflict information. Indeed, Ushahidi is starting to influence the international discourse on early warning (forthcoming reports by the EC and OECD). However, it is the mobile crowdsourcing of response that will create value and thereby demand by the BoP for Ushahidi.
Put it this way, Twitter would be far less useful if it were limited to one (and only one) global website on which all tweets were displayed. What makes Twitter valuable is the ability to select specific feeds, and to have those feeds pushed to us effortlessly, using Twhirl or similar programs, and displayed (in less than 141 characters) on our computer screens in real time. At the moment, Ushahidi does the equivalent of the former, but not the latter.
Yet the latter is precisely where the added value to the individual lies. An NGO may be perfectly content with Ushahidi’s current set up, but NGOs do not constitute the BoP; they are not the “fundamental unit” of crowdsourcing—individuals are. (Just imagine if Wikipedia entries could only be written/edited by NGOs).
This mismatch in fundamental units is particularly prevalent in the conflict early warning/response field. NGOs do not have the same incentive structures as individuals. If individuals in at-risk communities were to receive customized alerts on incidents in/near their own town (if they themselves send alerts to Ushahidi), then that response presents a far more direct and immediate return on investment. Receiving geo-specific alerts in quasi real-time improves situational awareness and enables an individual to take a more informed decision about how to respond to the alerts. That is added value. The BoP would have an incentive, empowerment, to crowdsource crisis information.
Here’s a scenario: if an individual texts in an alert for the first time, Ushahidi should: (1) contact that person as soon as possible to thank them for their alert and, (2) ask them what SMS alerts they would like to receive and for what town(s). I guarantee you this person will spread the word through their own social network and encourage others to send in alerts so that they too may receive alerts. (Incidentally, Erik, this is the strategy I would recommend in places like Jos, Nigeria).
In summary, while the Ushahidi team faces a multitude of other challenges in the DRC deployment, I believe that addressing the early response dimension will render the other challenges more manageable. While the vast majority of conflict early warning systems are wired vertically (designed by outsiders for outsiders), the genius of Ushahidi is the paradigm shift to horizontally wired, local early warning/response, aka crowdsourcing.
In a way, it’s very simple: If Ushahidi can create value for the BoP, the client base will necessarily expand (substantially). To this end, Ushahidi should not be pitched as an early warning system, but rather as an early response service. This is one of the reasons why I am trying hard to encourage the operationalization of mobile crisis mapping.
iRevolutions 
Patrick, many thanks for your response. Here are my preliminary comments (which will probably turn into a post!). Crowdsourcing response is very much part of our future plans (or rather we are building that functionality in) but I think we will still run into the same challenges…specifically:
1. The holders of information that would be helpful as far as a response – are typically governments/NGOs. I’m talking here about tangible responses e.g. you can get nutrition kits at relief centre XYZ in Goma. Again you run into the problem of orgs wanting to “sit” with their own information or release it when it’s too late….so you do you get the information holders as far as response to release this information.
2. Second, the system you propose where someone gets a bounceback message with alerts pre-supposes (a) that people are actually contacting us in the first place…which isn’t happening in DRC (b) that we actually have information to send out in alerts…which we also don’t have if no-one is reporting…a bit of a chicken and egg problem…we can build in the functionality, that’s not a problem…the problem is getting the data – BOTH ways.
3. You say that the individual are the fundamental units of crowdsourcing – I agree – but what I’m finding is that in places with connectivity challenges like DRC etc. people are more likely to rely on word of mouth etc for information on where to go, what to do etc. and we need to consider NGOs into the equation to fill the gap…at least until we get traction with individuals, which could take a long time. For Ushahidi to be relevant in non-high tech situations we need to be able to replicate that person to person alert…which is a challenge even with mobile e.g. we would need to presume a free local number, we need to presume that mobile hasn’t gone down (e.g. in some parts of Goma the towers are down), we would need to overcome the trust issues I discussed, and most importantly our info needs to be pretty much real-time for it to have any credibility. Now if we could a MONUC, UNHCR, Heal Africa person e.g. giving information about where the nearest camps are that we could then send out in an alert.. that would make a huge difference and that’s why their buy-in remains important.
An aside, we have sent back bounce-back messages requesting more info. and offering more details to the few people who’ve sms’d in but never heard back from them again. Which brings me back to my sticking point, building in the capabilities that you speak is only a small part of the solution – I think the larger issues still remain.
I applaud the Ushahidi initiative.
But bottomline for any initiative like this is ‘unless if you have a broad base of input, and input quality verification’, there will be no lift off. Peope will not check it, and not be motivated to contribute.
Potentially Ushahidi fulfills a need, but unless they deploy very early into the crisis, the ‘broad base’ will not be there.
P.
Hi Ory, I am the token pessimist at the Web2.0 party, but I hope that you’ll take my comments in the constructive spirit that they’re meant. I think Ushahidi is a good idea with a lot of potential, and I’d like to see it develop that potential. However the problems that you’re facing have nothing to do with the technology, but with the model. I find it difficult to believe that you could not anticipate how difficult it would be to Ushahidi to insert itself into a completely new situation, especially one as difficult as DR Congo. Even organisations which have been on the ground for decades struggle to stay on top of the rapidly shifting situation. The good news is that DR Congo is probably about as difficult as it gets in terms of deployment.
The key to the problems you have faced in DR Congo is the question that I am still trying to answer: what exactly is Ushahidi offering to people on the ground? It’s not enough to argue that it is offering them a way to make reports about activity on the ground if nothing happens with those reports. The Ushahidi website states that your goal “is to create a platform that any person or organization can use to set up their own way to collect and visualize information” – but I am struggling to work out what anybody is supposed to do with that information. You say you’d “like to see the tool working better for the people affected by the crisis” – but how will it work for them?
You say “in Eastern DRC the question we often get when we try to approach local organizations / contacts is what direct benefit will a person get from reporting”, so you’ve already run into this question. Everything that you list under “Issues specific to crisis situations” – well, if you’d asked I could have listed those off the top of my head. We’ve had exactly the same problems everywhere else and we’ll continue to have them. I don’t want to see Ushahidi re-invent the wheel, but in order to avoid that you must must must answer that core question. Where’s the added value for the individual that you want to send a message to Ushahidi?
There are a host of other questions that then follow from that, but I’ll save those for another time. Good luck!
Pingback: The Past and Future of Crisis Mapping « iRevolution
thanks
http://www.mobilephone-tracker.blogspot.com
Pingback: Ushahidi and Conflict Early Response « Conflict Early Warning and Early Response
Pingback: Crowdsourcing and Data Validation « Conflict Early Warning and Early Response
Pingback: The Limitations of Technology in Tracking Election Irregularities | Gauravonomics Blog