Abstract
Ushahidi has been hailed as a liberation technology, but, as
In 2007, the Ushahidi platform emerged, giving ordinary citizens the opportunity to report human rights abuses in the wake of the Kenyan presidential elections. Originally a collaboration between Kenyan and international citizen journalists and software developers, it has since been developed so that anyone can start their own mapping website and enable the public to post reports to it. Professor Larry Diamond at Stanford University has heralded Ushahidi as a ‘liberation technology’, while Professor Clay Shirky at New York University has described it as a catalyst for social movements.
There is no doubt that projects using crowdsourcing platforms like Ushahidi can change the velocity and nature of political events: people can organise more quickly, find others who share their views and work together in disparate locations to produce powerful sources of information. But as the sources of user-generated content grow and the volume of data increases, users of the technology face critical choices about what information to highlight, about the authenticity of reports and, consequently, which information should be declared as ‘verified’. It is in this realm that Ushahidi deployment teams face new challenges that raise questions around the role of technology, veracity and the future of citizen reporting in times of crisis.
Organic beginnings
On 27 December 2007, President Mwai Kibaki was declared the winner of the hotly-contested Kenyan presidential election. Citing widespread electoral irregularities, members of the Kenyan opposition staged protests from Nairobi to Kisumu. The protests soon turned into targeted ethnic attacks as a wave of violence swept through the country. Kenyan lawyer, blogger and technology policy expert Ory Okolloh was in the country at the time, providing on-the-ground citizen reporting from Nairobi on her blog, Kenyan Pundit. There was a government ban on local media at the time – supposedly in order to stem the tide of rumour that was said to be fuelling the violence – and blogs like Okolloh’s became one of the main sources of information both locally and internationally. In some of her posts, she asked for locals to send her stories that were not being reported by the media and she was soon overwhelmed by the volume of reports.
When Okolloh left for Johannesburg with her family on 3 January 2008, almost a week after the first protests, she made a plea to her readers and friends to help document what was happening in the country. Because the government ban on news media did not apply to the internet, Okolloh suggested that they collect information from a variety of sources as a record of the lives that had been lost. On Kenyan Pundit, she wrote:
(It) occurs to me that we have no reliable figures of the real death tolls … Perhaps we can begin to collect information from organisations and individuals on the ground eg red cross, hospitals etc and start to build a tally online, preferably with names. Most of the people losing their lives will remain nameless, and it might be worthwhile to at least change that. Any volunteers/ideas?
One of the developers who responded to Okolloh’s post was David Kobia, a Kenyan living in the United States, who was relieved to have an opportunity to provide some assistance. In only a few days, Kobia developed a simple platform in which people could send text messages or reports to a Google map. About 20 developers, many from Kenya, contributed to the code base that went live within a week of Okolloh’s request. The group named it ‘Ushahidi’, meaning ‘witness’ or ‘testimony’ in Kiswahili, because it enabled users to broadcast incidents of death, rape, looting and other human rights abuses to over 45,000 Kenyans, including local radio stations, which used the stories in their broadcasts. The platform was built specifically for the Kenyan environment, where mobile phone penetration is at least 50 per cent, compared to internet penetration of around 10 per cent. It enabled people to send in reports of what was happening on the ground via SMS or the website platform, thereby serving as a voice for those who might have been silenced by the media ban.
When the violence subsided and people began to reflect on the impact of the Ushahidi intervention, commentators at home and abroad called it a roaring success: here was a group of mostly African technologists and citizen journalists solving local problems through their own ingenuity and resources. Carried by a wave of enthusiasm and funding, the team of volunteers formalised their partnership and redeveloped the software so that anyone wanting to make a similar intervention could do so quickly and easily. The new Ushahidi software integrated Twitter and Facebook as well as updates from the web, so that a crowdsourced picture of an event unfolding over time could be depicted on a single map.
New challenges
Okolloh and her team tested the newly-developed software during the 2008 Democratic Republic of Congo (DRC) crisis, in which clashes between heavily-armed groups and government forces in the eastern North Kivu region caused a massive refugee crisis. Writing about the challenges the team faced, she noted some of the more human issues that prevented the widespread use of the platform there. Okolloh wrote about the difficulty in gaining the trust of locals who were concerned about reprisals for reporting human rights abuses on Ushahidi. She added that, ‘Unlike in Kenya, in DRC people [were] not used to a culture of free press – nor of people asking for their opinion.’ Okolloh wrote about ‘the issue of fatigue among the locals, [where] Ushahidi becomes just another organisation’ looking for information as well as with NGOs that suffer from a culture that does not promote information sharing.
Tellingly, Okolloh wrote in 2009:
In comparison to when we launched in Kenya, our efforts in DRC were much more structured. The Ushahidi DRC page has received great coverage in the international press. However, we have not received the volume of reports we anticipated. Many of those affected by the crisis or watching the situation closely had complained about the minimal media coverage on the DRC conflict. In contrast, in Kenya, we received more reports with very minimal active outreach on our part. While we did not expect to receive thousands of reports, we certainly expected more than we have received so far.
Residents of Kibera are able to access valuable information using the Ushahidi platform, Nairobi, Kenya, January 2012
Credit: Noor Khamis/Reuters
When the Ushahidi team moved from a largely organic development trajectory, driven primarily from within Kenya by individuals who were well known and trusted, to the DRC, where they started out as outsiders, they faced significant challenges. Interestingly, these are the same challenges faced by many users of Ushahidi today. While the technology is improving by leaps and bounds – especially in the mobile space – some of the greatest challenges to Ushahidi deployments come in the form of what John Seely Brown and Paul Duguid call the ‘social life of information’, that is the need to look beyond information and individuals to include critical social networks. Looking at these social networks becomes critical when you consider the challenges that interventions like the DRC map faced. These social challenges reflect themselves concretely in the Ushahidi user’s experience. A prime example of this is in the area of verification.
To verify or not to verify
In an interview in early 2012, Kobia recalled that the need for verification emerged only two or three days after the first site had been launched in 2009:
Getting verified information becomes really critical during crises like Kenya. This was really problematic because people were sending text messages to start rumours … This could have a serious reverberating effect and so it was important to be sensitive to the situation. You had to vet information and go back and overlay it with mainstream media … We ended up verifying fewer and fewer reports and putting less up on the map.
Verification has since become one of the biggest quandaries that teams using Ushahidi face. Many use a Ushahidi map to enable voices from the ground to be heard – voices that are often silenced by the mediating influence of traditional media. By enabling their own process of verification and deciding whether reports are ‘verified’ (often decided by the same media that they might have initially opposed), Ushahidi deployers can feel as though they are acting as the very same gatekeepers that they wanted to sidestep.
If a report is not verified, it is still visible, which is materially better than being invisible. But it can often feel that these statements do not count as much as those that have the ‘verified’ checkmark attached to them. Therefore finding ways to verify these statements can become an important differentiating factor for Ushahidi deployments.
The first key challenge is to find ways to verify information using sources on the ground. Teams who do well here recognise that much of the work they need to do happens outside the platform and often outside of what is available online. This involves calling people near reported incidents, speaking to journalists and investigating the identities of those who have sent in reports. But there are still many projects that are driven from outside a region by well-meaning individuals that suffer from a lack of local support and trust. This becomes especially critical to the success of the project when reporting involves issues like sexual abuse or human rights abuses in authoritarian states.
In the case of U-Shahid, the 2010 Egyptian elections monitoring project, verifiers were trained by a Reuters media professional to assess whether reports were accurate. The head of the project, Kamal Sedra, said that members of the team were sent out to the field to verify reports. The main problem the team faced was not one of misinformation through fake reporting but rather an attempt by vandals to bring down the system by posting 260,000 photos to the website.
Verification can be relatively straightforward when a single team with similar views is working together, but when different stakeholders are involved the process is greatly challenged. According to Nigel McNie, who worked on the Christchurch Recovery Map in the aftermath of the New Zealand earthquake, the government officials with whom they were working were concerned about endorsing the project because they were not an active player in the verification process. In an email to me in late 2011, McNie wrote:
We had to work to try and convince the officials that the map was a resource they should be endorsing, and as I recall it, one of their chief objections was the ‘verified’ status of the reports – they didn’t want to endorse a map that had ‘verified’ reports that weren’t actually verified by them. There’s no way they could have verified the reports, of course, although they did suggest the addition of ‘government verified’ as a category.
In this case, the ‘verified’ tag becomes a mark of authority, a site of struggle between competing interests and a locus of reputation and trust for those involved in the effort. For volunteers working to set up Ushahidi or Crowdmap on behalf of other agencies, this can become a significant challenge – especially when volunteers are physically separated from what is happening on the ground.
The future
Since those heady days in 2007, Ushahidi has become one of the world’s most acclaimed non-profit technology companies, winning awards both internationally and locally. Now that users can set up their own mapping project in minutes, the number of Crowdmaps has reached over 20,000 and the number of external installations is about 13,500. A dynamic open-source community is active in developing and implementing Ushahidi software projects around the world and the technology has the potential to reach the status of tools such as WordPress, which has enjoyed huge success as a blogging platform.
But while the technology is growing at exponential rates, processes requiring non-technical intervention, including the verification of user-contributed data, will continue to face challenges, especially as the size of repositories grows and more people start using social media software.
In the future the trend is towards using ‘big data’ to automatically verify reports by semantically analysing each report for key phrases and action verbs and developing clusters of similar statements. According to pundits like Patrick Meier, director of Social Innovation at the Qatar Foundation’s Computing Research Institute, this kind of computing analysis could enable verification of masses of data at digital speed.
But the majority of Ushahidi or Crowdmap installations are still small data projects, with many located in areas that still require offline verification procedures. In these cases a team’s ability to achieve a strong local presence will define the quality of verification practices and consequently the level of trust accorded to their project. After all, verification practices are only ultimately successful if reports are accepted and acted upon appropriately. In these cases, crowdsourcing has the opportunity to lower the barriers to expression and ultimately help and support ordinary people in times of crisis.