[Below is my Tech4Africa talk, given today in Johannesburg, South Africa, titled “How we built Ushahidi, w]
I’m used to talking about Ushahidi, and as all of you guys who frequently talk about your product or company know: it gets old spouting off the same old stuff over and over again. That’s why I’m excited about today and for being invited to this excellent conference, since I’ll be telling the backstory, the quirks and funny bits that got us to this point and made our Ushahidi culture what it is today.
This is my story of Ushahidi – Of a small organization that dislikes hierarchy and being told what we can’t do. One that questions everything, embraces innovative thinking, takes risks boldly, and sometimes learns the hard way that we’re human after all.
In January 2008 I spent a week watching news reports roll in from Kenya, frustrated. Frustrated because I had said for years that “technology helps us overcome inefficiencies”. Wasn’t the madness of Kenya, in it’s post-election violence throws, it’s lack of media coverage, and lack of real information just this? Why was I unable to do anything?
It turned out that I needed an idea, and for once I couldn’t come up with one on my own. That seed of an idea that grew into what you see today came from a simple bullet point by my friend and fellow blogger Ory Okolloh, asking if we could map reports of violence around the country. Thus Ushahidi was born.
I’m going to walk you through three defining moments for our organization, and our platform, not all of them pretty, but which make us who we are.
1. Let’s look at the ad hoc cast that got it started:
Ory Okolloh – lawyer, blogger and Kenyan political pundit
Juliana Rotich – renewable tech geek, blogger and database admin
David Kobia – developer and top Kenya forum webmaster
Daudi Were – blogger and web guy
Erik Hersman – Africa tech blogger, web guy
Others – a various cast of tech and non-tech people swarmed around the first Ushahidi deployment in Kenya, helping with small tasks and then disappearing.
Key points:
- You’ll notice that there was not a single one of us who had any humanitarian experience
- None of us had taken part in any open source project. (v1 was built in .NET)
- Most of us were self-employed, running our own businesses or consulting, and didn’t like working for big companies.
- The only common denominators that we shared was our love of our home; Kenya, and the ability to blog.
Thus, we felt we were the best placed to create an African open source platform for crowdsourcing information, our tech gift to the rest of the world.
We didn’t think of that at all actually. Instead we were madly Skyping, emailing, wireframing and coding over a 3 day period to get something up as quickly as possible.
We were brutal about every decision:
- If it wasn’t absolutely necessary, throw it out.
- Pick a name, any name, we don’t care if non-Kenyans can’t say it, just get a domain up asap
- Launch this app, it’s functional, we’ll fix bugs and features on the fly
- No one has a short code for us yet? Screw it, it’s not worth waiting, we’ll get one eventually.
- Money, what’s that for? Media budgets are overrated, we’ll blog it.
- We don’t have a logo. Oh well… Launch already!
How our team came together, the way we made those initial decisions and how we interacted and leaned on what would become our community was defining. It still colors how we operate, our organizational communications and our community focus.
Lessons learned:
- This taught us to keep a shallow and wide decision-making structure so that everyone had access to all the information about ops or platform that they desired. Anyone was empowered to make decisions, since thy understood the macro-game.
- Release code early, it’s better to have it out and being tested and worked on in the real world, than hidden away in a sandbox somewhere.
- If you want it done, build it yourself, don’t put it off onto another team member.
- Community = success
- No money, no worries. Build good stuff and good stuff happens, money follows.
2. Technology is only a tool
No background in open source projects meant that we had little experience in how to engage programmers, designers and the help needed to get things moved from that initial .NET build into an open source language. David and I were trying to decide what language to write this in, and we ended up picking PHP over Python since we thought more African programmers would be proficient in it.
David wasn’t a PHP guy (yet), so the early helpers, the volunteers like Jason Mule, Henry Addo and Chris Blow were a huge help in making the decision to go with the Kohana framework and a myriad of other decisions.
3 months later we announced v0.1 of “THE NEW AND REBUILT USHAHIDI PLATFORM!”
We were very excited, after all, wasn’t this the platform that would save the world? And we were ready to show the world just how it could be done. Gamely mounting our white steeds we charged into a deployment of Ushahidi in the troubled North Kivu region of the DR Congo.
Echoes of that failure splatting against the ground remind us still, today, of the complexities of the space we build software in. We learned from those lessons though, and Ory wrote a good blog post making sure that it was shared within and without.
Lessons learned:
- Technology is only 10% of the solution needed. The rest is administration and messaging.
- Stick to what you do well. Our team is built to build software, not be a deploying organization
- (caveat! We do help in deploying rarely, like Haiti and Kenya, but we now pass those off, or partner)
- Own your failures publicly, learn from them.
3. Enter the failephant!
Only a few months later, after the DRC debacle, we were rested and ready to fail again.
Al Jazeera had used the alpha version of the Ushahidi platform in Gaza, a group of organizations and individuals were deploying it to monitor the worlds biggest elections in Indian, and we had a number of groups in East Africa testing it out.
Our model was that we had a small team at Ushahidi whose job was to come up with and guide the core architecture of the platform. Volunteers also worked on core, but were also encouraged to extend the platform in their own ways. It was working very well, and still does.
We were ready to release the code publicly.
Before I say anything, let’s revisit that point earlier about none of us having eroded on an open source project before…
Preperations were made, blog posts were written, tweets were tweeted – and we got lambasted by one of the guys we respect a great deal in the open source community. Rabble called us out on all the things we did wong.
– The code repository was behind a user/password wall
– We weren’t available in the normal programmer channels like IRC
– Hard to plug into the rest of the dev community
Our team went to work, madly working over the next 12 hours to get our stuff straightened out. Finally I wrote another blog post, introducing our failephant mascot and apologizing for our ignorance and missteps.
Lessons Learned:
- Listen and apply that listening to real changes
- Again, own your failures. Fix things that are wrong.
- It’s okay to think different in how you execute on a project as long as you don’t stray from the spirit of your community and self
.
Finally, I’ll end with this.
We’ve learned that technology does overcome inefficiencies, but that it still takes people to make it happen.
We’ve learned that more people need to buck the status quo, that questioning everything makes us better.
We’ve learned that Africans can build world-class software, and to expect nothing less.
August 12, 2010 at 1:37 pm
Great post… it’s always interesting to hear the lessons learned and takeaways retrospectively. I particularly liked:
“We’ve learned that technology does overcome inefficiencies, but that it still takes people to make it happen.”
Thanks for sharing!
August 12, 2010 at 1:53 pm
Thanks for posting this – as ever, it is great to feel your openness and honesty coming through. I’m just writing something about Ushahidi for a chapter on “The Internet and Development” and was going to include some mentions about your work – this material will be a valuable link! You are so right that technology is only a tool – and usually then the easiest bit to get right!!! Hang on in there.
August 12, 2010 at 2:27 pm
Inspired. Especially about knowing the team that launched initially did not exactly fit the ‘NINJA OPENSOURCE CLAN’ I thought you guys were, but still managed through your passion and teamwork to execute.
August 12, 2010 at 3:00 pm
Great post and very insightful. We hope to learn from your experience.
August 12, 2010 at 4:06 pm
awesome, awesome stuff. truly inspiring. love your work
August 12, 2010 at 6:07 pm
So true, yet so often ignored.
August 13, 2010 at 9:59 am
Inspired!
August 13, 2010 at 1:37 pm
Not so much as a blueprint more a confessional and as such inspiring. Strikes me that you would not have created something so simple yet so effective had you had all the things you initially thought you needed.
August 13, 2010 at 4:49 pm
i love that you share the journey. i also think that it is modest. so quickly you bypass the inherent human drive that good will possesses. this is the heart of both public service or open source, both of which are synonymous I might add. in your case, the good will to map violence drove this accomplishment. but above all, it is the character to see it through by bringing a team together under a cause. Uchaguzi, or Ushahidi – good on you to make crowd-sourcing a democratic achievement to establish much needed pursuit for “uKweli”, and it can be done exceptionally well.. locally! Cheers!
August 14, 2010 at 3:30 pm
Thanks for this, Eric. I wish you would talk about the less-than-successful deployments as well – or, better yet, have the people who actually ran them write about it on the Ushahidi blog. Pretty much everyone we surveyed who actually deployed Ushahidi was not happy with the results, the platform, the number and quality of responses, etc. As Patrick points out often on this own blog (albeit not on the Ushahidi blog, for some reason) this is an experiment and early days of crowdsourcing information of all kinds. It would be good to have a more open and honest discussion about when, where and how crowdsourcing makes sense, and what the shortfalls of the many deployments have been (and how to avoid them in the future).
As always, you have a standing invitation to the next Failfaire. Or even better yet, host your own amongst the people who implemented/deployed Ushahidi who have a few #fails to tell about.
August 15, 2010 at 1:26 am
Katrin, I’m not sure if you’re trying to be offensive, or if it’s just accidental. Nor do I know who you interviewed and why. What I can tell you is that Ushahidi wouldn’t still be around if everyone who used it didn’t like it and didn’t have success with it, so your broad sweeping general statements are misleading at best. Anecdotes are useful in understanding things, but anecdotal hints are worse than anecdotes.
Go ahead and read the Ushahidi Blog to catch up. There are plenty of posts on use cases, successes and failures.
Patrick is a blogger outside of the Ushahidi hat he wears, as am I, Ory and Juliana. Like I did with this blog post, he can do with his thoughts and ideas as well.
August 15, 2010 at 1:18 pm
Katrin’s post seems a little harsh, but there is value is discussing the successes of the deployments.
What I’d like to call the utility and usability of the tool.
A few months ago I investigated Ushahidi platform. I looked carefully at the first Kenyan and South African deployments, and the quality and range of info on the deployments were often not as good as one would have wanted. I read that the South African developers entered the crisis incident information on their deployment themselves, because the ‘crowd’ did not.
I have to say I don’t doubt the effectiveness of crowdsourcing in this particular ‘usecase’ – sourcing crisis information. My gut feeling tells me it will work if you get the system right.
Since each deployment of Ushahidi is done under a new ‘brand’, one of its main problems is service discovery or awareness if you like. People simply don’t know about the deployment, and if they do thy dont know how to use it.
Ushahidi is often deployed in developing countries. The ‘crowd’ dont have web access. SMS is the way people on ground can make reports.
But most SMS based services have suffered from this same problem. Since commands are not menu items, its hard to keep the service top of mind with the ‘crowd’.
Normally these kinds of awareness problems are solved through advertising, but advertising is expensive.
Otherwise they are solved through word of mouth, but often the people that need to make these reports dont use email or Twitter.
An iPhone app on the other hand sits on the phone’s deck and is much more top of mind. (See City Sourced).
Is this awareness issue not the main issue Ushahidi needs to address?
August 17, 2010 at 3:33 pm
Hi Wessel. This was a talk that I was asked to give at Tech4Africa, and it was specifically focused on Ushahidi as an organization – what we’ve learned about ourselves and the platform along the way. That’s why I didn’t go into detail about other people’s deployments of Ushahidi. We do a fair amount of that on the Ushahidi Blog, though even then since it’s someone else doing the deployment, we don’t know all the details, successes or failures.
Like you said, we do find (and state repeatedly) that a lot of the energy around a deployment of Ushahidi in any country is spent on messaging and administration. The platform is fairly straightforward. In other words, the technology should not be what you get hung up on.
We released Crowdmap just a week ago to help people get going faster, and over time we’ll likely have a way to see and find deployments in your own area even faster. However, one step at a time, it’s still very early beta for Crowdmap.
August 19, 2010 at 4:41 am
Inspiring.
Ory’s link is not working. Its linking to kenyapundit.com instead of kenyaNpundit.com
August 19, 2010 at 6:38 am
Fixed. Can’t believe I did that… 🙂
August 19, 2010 at 6:43 am
Thanks Eric.
It’s amazing what you have achieved I have to say. It’s an inspiration for what we are trying now with the Meerkat Project.
http://corruption-sa.posterous.com/call-for-programmers-0
August 19, 2010 at 10:18 am
its a great Post.My favourite line :We’ve learned that Africans can build world-class software, and to expect nothing less. Lovely line.Very inspiring and very encouraging
August 19, 2010 at 11:15 am
The survey that we did was with implementers of Ushahidi in citizen reporting (and no, I am not calling it election monitoring because it isn’t – see Why http://mobileactive.org/cutting-through-hype-why-citizen-reporting-isnt-election-monitoring) during recent elections. This included implementers from Lebanon, India, and Mexico. We also queried implementers in Gaz, Kenya, Uganda, Malawo, Zambia and Togo.
In addition to numeric data, we asked the following questions:
1. Were you satisfied with the number of submissions to the Ushahidi platform?
2. Were you satisfied with the quality of submissions to the Ushahidi platform?
Some answers included (quote):
No. We were expecting more but due to “political issues” and/or mistrust due to lack of knowledge of this kind of systems some NGOs back off and did not use the system however we already talked to them (after elections) and they agree to use it in the upcoming elections. (Mexico)
“No. 1) we launched late, would like to have seen more submissions but recognize that was in part a failure of marketing on our part and are working to rectify this.
2) we would like more integrated submission channels. web and email feels redundant, twitter was poorly integrated, and would be great to see voice submission (speech recognition)
3) signing up for a mobile ‘rss’ of submissions was not enabled, so we didn’t benefit from the critical user feedback loop. (Lebanon)
The software did what it was supposed to. We didn’t have a network of volunteers, or the time/ budget to promote the project, to get enough submissions. (India)
No. The number of submissions could have been better, the main reasons could have been to do with the speed of deployment and getting the word out to locals about the platform and the SMS number. Although we did put it on air, maybe it could have been repeated more. Other factors could have been electricity being cut, people being bombed not having appetite or time to watch News etc. (Gaza)
In addition, we received some useful comments re. technical improvements such as accepting structured data as one key desired feature.
I am reading the Ushahidi blog religiously but I am not seeing any discussion of some of the comments we heard from implementers. You might not see that as the role of Ushahidi as a tech platform. Is there a list of users/implementers? The greater emphasis you have recently put on the time it takes to promote an instance of Ushahidi is helpful and is certainly reflected in the experiences of the implementers quoted above.
Regards,
Katrin
August 19, 2010 at 12:22 pm
@Katrin, I’m not sure why you insist on hijacking this post via the comments.
Your comments here are clearly meant as a way to spread dirt and be a dissenting voice for more attention, your first comment itself is nebulous enough that it was clearly meant not as constructive criticism, but as a way to get a rise out of me. In short, you’re trolling.
If I wasn’t clear in the post itself, the title, or the comments, this was a talk about how we built the Ushahidi platform and the organization and the lessons we learned along the way, not about the uses of it by other organizations.
You know me and all the members of the Ushahidi team. You were an advisor for 1.5 years until we dissolved that due to needing to create a Board of Directors. If that offended you, I’m sorry, but all but Ethan Zuckerman were not included on that Board. It’s not like you weren’t around when all of these deployments were happening (as they all happened 1+ years ago).
You have our emails, our phone numbers our Twitter contacts – you can easily contact us in a non-public space if your goal is to really provide feedback or constructive advice.
Seeing the examples you selectively chose to share, I can tell many of them are issues that we talk about all the time on the Ushahidi blog, around how to pay attention to messaging, community growth and administrative needs before it happens. After all, the tech is only about 10% of a solid and well-run deployment, which we’ve said for a long time now.
I’d like to highlight our community resources page, the communications we have with people in the forums, or the myriad blog posts on lessons from Haiti, Chile, etc…
Finally, if you really want to help the deploying organizations, you can always suggest additional resources by sending an email to support@ushahidi.com. I’d also challenge you to come up with ways to support tech tools, seeing as you claim to be a driver of community support.
August 20, 2010 at 9:47 am
@Katrin
I’ve got to say I agree with Erik on this one. Looking at the context and the case he’s put forward, it must be said that maybe the comment section may not be where these points should be presented. And the thing with Ushahidi, it’s defining principle is the community element. The ability for us to look at where we’ve gone wrong and improve it.
You may certainly have a point on the citizen reporting vs. election monitoring but I’m afraid you’re link isn’t working either to read more or to see your viewpoint on it all.
Information isn’t worth much unless it’s shared and learnt from. That’s what we’re here to do as a community and cheers to Erik for candidly sharing Ushahidi’s challenges.
Onwards & upwards.
September 1, 2010 at 6:03 am
We, at Africa Peace Forum, are welcoming Kenyans to exchange opinions and ideas on the Agenda 4 Items that form part of the accord signed between President Kibaki and Prime Minister Odinga. This is something in line with what Ushaidi is doing but our approach is different. Please, visit http://www.agendayetu.org/blog
October 4, 2010 at 1:57 am
“We’ve learned that Africans can build world-class software, and to expect nothing less.”
I recently did a project paper on appropriating technology for social change in Africa and this is the same conclusion I came to.
Thanks for sharing.