Nelson Mattos, VP of Africa, Europe and the Middle East gave a keynote, here are some notes from that.

Challenges

High penetration of mobile devices, and growth in mobile, yet not many fixed lines and very little high-speed connectivity. This provides a major challenge to Google, whose internet paradigm is based on a different type of user. Low speed and unreliable connectivity.

The diversity of Africa is also a challenge, especially languages. Example, is that there are 51 African languages with more than 2 million speakers.

Devices and affordability. Cash flow constraints impede the ability to pay the entire device price at once. – plus limited access to financing options as the whole of Africa only has 4% of the population that is banked.

Africa is a fragmented market with 54 countries and 1 billion people compared to other emerging markets like India (1.1b) and China (1.3b). This means lower volumes of things that can be sold and lower return for investors.

Broadband in Africa is 10x more expensive than in Europe. The price is just too high outside of cybercafes and certain limited mobile plans.

14% of the world’s population, 2% of the internet
Globally, 94 domains per 10k people, Africa is 1/10,000.

Opportunities

Africa is embracing mobile, so Google is trying to speed up the process of getting more and more people online using mobile. They’re also working on many different levels to create a more holistic ecosystem for the internet in Africa, including policy, education and developer outreach.

Access – reducing the barrier for potential users
This mainly means reducing the cost to access, data and services. They do this with with devices (like this week’s release of the Android IDEOS phone from Huawei). They also engage with major telcos and ISPs to reduce the price of entry for data connections.

Google works a lot with the African developer communities as well, they’re particularly heavy in Kenya, Ghana, Uganda, Senegal and South Africa, but are growing to more countries. One of their goals with this is to educate on how to better create efficient and effective websites, and it’s also to help grow a higher calibre of developer.

They have a university access program, where Google helps bring universities into the internet era in Africa (though I’m not sure what that means to be honest, outside of giving them Google Apps for free.)

Finally, they work to Improve the end-user experience, including latency for both Google products and internet services in general (ie, Google Global Cache). Note: Google Global Cache only works in certain countries, Kenya is not one of them due to political bickering amongst certain ISPs, AccessKenya amongst them

Relevance – making the internet relevant and useful to local people
Google is working to create and enable more African content online (ex: Swahili Wikipedia challenge and Google books partnerships). They’re helping to develop applications that are locally meaningful and enabling African devs to do the same by launching Google products in more languages.

Sustainability – helping to build an internet ecosystem in Africa that has long term sustainability
Developer outreach is a major component, where they are strengthening the developer community (through places like the iHub), working with universities by raising the level of curriculum and awareness about Google, and are also working and partnering with startups, publishers and NGOs.

Awareness and education (Doodle for Google in Kenya and Ghana, “Best place to watch the match” in Kenya during the World Cup, etc.

Google Tools

Taking advantage of Google apps (email, docs, calendar):
50k students using Google apps for free at universities
Small, medium and large sized organizations are using Google Apps as well, examples given were: Kenya Airways, Homeboyz Radio, USIU

Products developed for Africans – recent launches:

• YouTube (South Africa)
• Streetview (South Africa)
• Google maps in 30 African countries: including driving directions in Kenya, Ghana and SA
• Google News in many African countries
• Google Places (Kenya)
• Google Trader (Uganda)
• iGoogle in 36 Sub-Saharan African countries
• SMS chat in Gmail (Ghana, Senegal and Zambia)
• Tools in local languages (ex: Gmail in Swahili)
• Android Marketplace launched in Kenya and South Africa on Monday, but it’s crippled by lack of Google Checkout use in these same countries.

(There were actually quite a few more “Africanized” tools and features that he listed, but I couldn’t copy them all down in time. I’ll try to get the full list later.)

Ability for organizations to start local and expand globally:

• Google Maps: 300 cities mapped, and represents a chance for local businesses to have a global presence by getting into the business listings
• Google Site Creator: get indexed faster, uses the example of AkiliDada
• Monetization opportunity through AdSense and Adwords: uses an example of “BabyM“, a business out of Nigeria, who used $400 on Adwords and sold their complete inventory in 4 weeks.

It runs Android 2.2 (Froyo) and have access to the Android Market. The IDEOS is a touch-screen phone that comes with bluetooth connectivity, GPS, a 3.2-megapixel camera, up to 16GB of storage and can be transformed into a 3G Wi-Fi hotspot connecting up to eight devices.

2 out of every 3 internet users in Kenya connect through their mobile phone. This is why data is the current battleground in the mobile operator and handset space. Though there are only 6 million internet users in Kenya, the data market though the mobile is huge. Currently, there are 20 million mobile phone subscribers of a total 38 million possible.

Data enabled phones of any type cost a minimum of $40-50 in Kenya, a touchscreen smartphone coming in at $100 is going to be a big deal for a lot of people.

gKenya

Google Kenya started their gKenya conference today. They are meeting with software developers, entrepreneurs and CS students at Strathmore University over 3 days to discuss innovation and growing businesses, as well as discussing their own suite of products.

[An update, after discussions with a bunch of Google employees at the iHub yesterday. The Google team said they didn not know when the phone would be able to be bought in Kenya.]

Android and pre-paid phones

There are two very big issues that the Android team will need to take care of before we see Android being used heavily in Africa.

First, the lack of access to SIM applications is surprising. These are the apps like Mpesa, top-up services and such. These aren’t just “nice to have” features, these are critical and the phone will fail if it doesn’t have them enabled. Your most basic phones can do this, but smartphones running Android cannot? (Note: unless you root your phone)

Second, there are a lot of background services running on an Android phone that use data. That’s fine for people living in an all-you-can-eat world of bandwidth, but here where we have to pay by the megabyte, it doesn’t work. I remember one day when my phone used up 1000 Ksh of credit ($12), that’s unacceptable and will drive users away very quickly.

On Friday he came to the iHub in Nairobi where he took 2 hours to have a fireside chat with local web and mobile technologist on “The Future of Kenya: what needs to happen for local services and apps to succeed.”

“Russell Southwood looks at the kinds of changes that will happen in Kenya over the next ten years, how the barriers to change might be broken down and the relationship between the ICT business and the broader economy and society. He sets out to try and understand what will produce the success factors for the growth of ICT services and apps businesses across Africa and why Kenya has a key role to play. From these broad arguments, he then focuses down on the needs and type of customers services and apps companies can potentially serve.”

Russells relaxed and intimate chat with the community is going to serve as the first of many new fireside chats at the iHub with Africa’s “big thinkers” and top tech CEOs.

Out of curiosity I put out a survey to the Kenyan tech community 2 days ago. I’ve always wondered which schools in Kenya put out the most people who move into positions within tech companies, or start their own. I now have 200 entries, which is a decent enough size sample, though I know if we did a true canvasing of the entire community that the results would be slightly different.

[2010 Kenya Techies School Survey]

Here are the results

The top schools

Starehe Boys’ (20) leads by a large margin, followed by the other big private schools; Strathmore (9), Lenana (8), Nairobi School (8), Alliance (7) and St. Mary’s (6). It’s clear that some schools choose quality over quantity, such as my alma mater Rift Valley Academy (2)…

There are a plenty of examples, such as Gitwe (1), which had only one graduate that come from all over the country. Clearly, many techies here in Kenya had to fight their way up from a challenging environment.

Year Graduated
I started this off in 1980 and went to 2009. There’s an interesting curve happening within the community on when people cleared school. The highest is the year 2000 (25). I wonder if there was something that happened in the school systems at this time to make the number go up, or if there is some other reason for that bump in 2000-2002.

Companies you work for
I was amazed at the number and spread of technologists across the tech companies in Kenya. Here is just a small sampling of 127 different companies that were listed of who people work for:

Access Kenya
AFRICOM
Cellulant
Craft Silicon
Dotsavvy
Google
IBM
Kencall
Mobile Planet
Mocality
Nokia
Safaricom
The Standard
UN (different groups)
Virtual City
Wananchi Group

9 months ago that is just what Jon Gosier set out to do as he took over the reins of the SwiftRiver initiative at Ushahidi. Today he announces the Beta release, and unveils the new website at Swiftly.org.

What is SwiftRiver?

SwiftRiver Open Beta Announcement. from Ushahidi on Vimeo.

“SwiftRiver is an open source intelligence gathering platform for managing realtime streams of data.”

Using 5 different tools in the toolbox, you can create a host of useful applications. Tools ranging from natural language processing to handling duplicates, or a source’s importance in the ecosystem. Much like a box of Lego’s, the value and usefulness of the apps created are up to the creator.

SwiftRiver lets users:

• Manage realtime data streams (e.g. RSS, SMS, Twitter, Email)
• Identify relationships between content (e.g. email and tweets)
• Set parameters to auto-filter incoming feeds
• Curate content based on preferences

Swift code and web services

Like all Ushahidi work, the code is free and open source, anyone can download it, contribute to the code, and run it on their own server. Due to it’s complexity, SwiftRiver also offers a software as a service solution, allowing you to tap our servers for your own needs. Swift Web Services (SWS) is our cloud platform. The platform offers a number of different APIs to developers. With this platform you can easily beef up your applications with natural language processing & active learning, reverse geocaching, distributed reputation, content filtering and web analytics.

This first app, called the Sweeper is the first project to enter Beta and now ships with SwiftRiver. Sweeper, is a term Ushahidi uses to refer to people who ’sweep’ through a system, performing certain tasks, and it was for this reason that we put the Ushahidi resources behind the whole initiative.

SwiftRiver | Sweeper

History, contributors and code

The origins of SwiftRiver are in the community of Ushahidi developers and users. Chris Blow and Kaushal Jhalla asked some hard questions after the Mumbai terrorist attacks in 2008, discussing the need for something that can help with this information overload we have in the first few hours of an emergency or disaster. Today, we’re seeing the first fruits of that technology, and it’s exciting to know that the potential for it’s use goes far beyond the crisis scenarios that we first envisioned.

Matthew Griffiths (Uganda) and Neville Newey (South Africa) have done a great job hacking out much of the code and designing the architecture for the platform. They’ve been joined by an army of volunteers and contributors, including: Joshua Bronson, Soe, Nishith Rastogi, Mang-Git Ng, Josh Bronson, Ivan Kavuma, Andrew Turner, Chris Blow, Kaushal Jhalla, Ed Bice, Moses Mugisha, Victor Miclovich, Wolfgang Werner, M. Edward Borasky, Maarten J. van der Veen, Ahmed Maawy, Colin Meinke. A huge round of thanks to everyone who gave freely of their time and energy to move this project forward!

Find out more on the website at Swiftly.org
Download the code, v.0.5 Cape Jazz

Apparently, and surprisingly to me, the answer is “not Africa” or South America.

“During the last week of July, AVG researchers compiled a list of virus and malware attacks by country picked up by AVG security software. This means we have compiled data from over 127 million computers in 144 countries to determine the incidence rates of virus attacks by country.”

Dirk Singer, of AVG sent over the list of African countries, here they are country-by-country. As you can see, sub-saharan Africa is compatively ‘safe’ compared to other areas of the World. Your chances of being attacked while surfing the web in each country are:

North Africa

• Egypt 1 in 62.4
• Algeria 1 in 86.9
• Libya 1 in 87.7
• Mauritania 1 in 92.4
• Tunisia 1 in 110.7
• Morocco 1 in 112.1

Sub-Saharan Africa

• Mali 1 in 49.9
• Sudan 1 in 53.9
• Nigeria 1 in 67.5
• Benin 1 in 76.6
• Ghana 1 in 99.4
• Ivory Coast 1 in 101.5
• Gabon 1 in 113.1
• Angola 1 in 129.7
• Botswana 1 in 134.4
• Ethiopia 1 in 135.8
• Senegal 1 in 140.6
• Uganda 1 in 153.6
• Liberia 1 in 153.8
• Burkina Faso 1 in 163.4
• South Africa 1 in 172.3
• Tanzania 1 in 180.6
• Kenya 1 in 216.1
• Zambia 1 in 262.2
• Mozambique 1 in 263.8
• Zambia 1 in 262.2
• Namibia 1 in 353.1
• Togo 1 in 359.4
• Niger 1 in 442.0
• Sierra Leone 1 in 696.0

Keep in mind, this was over one week and it also doesn’t point directly towards where the attacks are originating from. Interesting data though, and not what I would have expected to see.

Why?

“There may also be one partnership in particular that could be hampering innovation—that with the banks. Historically, these two players have taken very different strategies for new product development, especially in resource poor countries.”

Thinking big picture

You can send up to $500 for as little as 37 cents using Mpesa. On Zain it will cost you 74 cents. That’s an insanely low transaction cost compared to what banks charge, and that’s not even going into the fact that they can’t do transactions as low as 50 to 100 Ksh ($.60 to $1.24). The kicker, you can store your money in it for no fee at all (unlike the usurious rates that the banks charge).

Simply put, banks cannot compete with mobile operators when it comes to transacting payments for the majority of Africans.

Regulators make and enforce the rules around everything. How do they make their decisions, who lobbies them and why? Is the reason that we haven’t seen a true replication of Mpesa anywhere besides Kenya due to the banking sector protecting its interest?

Opportunity lost

Right now anyone in Kenya can do every type of transaction within our own borders, and if creative into neighboring countries as well. A few other countries have the ability to do this type of thing as well, if less efficient and/or elegantly conceived.

Currently opportunity is lost by local merchants in not integrating mobile payment structures better into goods and services offered to both businesses and the public. This is changing, businessmen are quick to move to figure out new ways to increase margins and customers. It’s only held back by the operators not willingly opening up their platforms for easier integration into business.

11% of Kenya’s GDP was shifted through Mpesa in 2009, and the company expects that to be around 20% this year.

We can all agree those are big numbers and that a massive ability to make money has been shown in Kenya. This begs two questions:

• Why has no one allowed it to truly replicate in another country?
• Why is no one throwing big money after this, trying to figure a way to scale a mobile operator and bank agnostic payment solution across a region, if not the whole continent?

There are big players trying to break into the greater African market (I’m looking at you Naspers). There are banks who have the money to spend on figuring this out, but aren’t thinking beyond their own brand, so continue to fail. Maybe the answer is we just should sit here and let all this lost opportunity continue to drift by us, waiting on the big credit card players of the world like Visa or Mastercard to make a move.

That’s a fatalistic stance, and I certainly hope it’s not true. Unfortunately, I don’t think we’ll see this service come from 2 guys coding in a garage. Instead, I hope that there are mobile operators and banks banding together to make something bigger than themselves that make more profits for everyone. If not them, a big investor willing to wager millions of dollars on making billions.

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.

I’ve been using WordPress for many years, and am a huge fan. When I saw DukaPress last week, I was at impressed to see that it was built locally in Nairobi, but I also wondered why another eCommerce WordPress build was needed, as there are already some good ones out there such as WP-ecommerce and Shopp. So, I asked the Kelvin, from Nickel Pro, and here is his response:

I know you’ve probably been using WordPress even longer than I and the rest of the DukaPress team so I can probably say you know that WP-ecommerce is a bit…buggy (I say this with the highest amount of humility, we are nowhere near achieving what they have). The other free WordPress e-commerce plugins are much less usable, to us, than Wp-ecommerce.

Shopp is really really good but it sits behind a pay-wall – which is okay.

We built DukaPress to be fully featured, yet super simple to use and, well, free. It actually did not start out life as something we’d give out to the public – we built it primarily to serve our own purposes at Nickel Pro because we build a lot with WordPress and when it came to building e-commerce stuff it was always a big problem. One thing led to another and DukaPress, the plugin for public release, was born.

Around the net where WordPress e-commerce is being discussed, there is always a lot of complaints, primarily against WP ecommerce (some people call wp ecommerce a trojan for their ‘for sale’ upgrade), we hope that with DukaPress, people out there have a viable and better (I hope!) alternative.

Other than that, we offer features that none of the other WordPress e-commerce plugins do! As you rightly assumed, we support all three Kenyan mobile payment systems ZAP, yuCash and MPESA! Although I have to qualify that and say that integration of this is still being developed to be more fliud. We’re just at version 1.0.1

How shall we make money with this? We already do, we’ve used it in at least 4 major projects for our client work and it has already paid for itself.

Other than that, we’re currently working on version 2 which will bring full WordPress Multisites support – so that you can build your own etsy.com in 15 minutes – among other features we think are nice. At that point (in the next month or two), we may launch our own etsy.com-type service (or, in better terms, a wordpress.com which can host fully featured shops); or licence the multi-site version of DukaPress for a fee; or both. No other e-commerce plugin has “successfully” pulled off a WordPress Multisites integration to date i.e. users still cannot build a wordpress.com that can host shops without a great amount of hacking.

DukaPress is also a gateway for www.madoido.com.

I think there are certainly similar plugins which may outperform DukaPress but I also do think it probably beats some of the more established ones. I hope the larger WordPress userbase gets to prove me right, but even if they don’t, DukaPress certainly makes our lives easier, and gives a really welcome international perspective to our business.

On a personal level, I’m impressed to see Kelvin and his team at Nickel Pro working on DukaPress, and I hope that they continue to make it better. If you’re a WordPress pro, or in need of an eCommerce solution, check out their website, documentation and features.

(video by Jon Shuler)

Uchaguzi: Monitoring Kenya’s Referendum Vote

Uchaguzi is a deployment of the Ushahidi platform that marries up traditional election monitoring groups and practices with voices from the crowd. It was an experiment in a more holistic approach to monitoring an election.

Our goal is to make this an election monitoring platform that can be used by anyone (at least in E. Africa), as a mixture of the core Ushahidi platform, with a package of customized plugins that do things such as:

• Map known election monitor phone numbers to specific locations
• Content-map the election monitoring number codes into an automated full report
• Use shape files to get make reports not just point-based, but heatmapped
• Ticketing system for escalated items
• Ability to mark items as “actionable” and/or “action taken”

We started Ushahidi 2.5 years ago here in Kenya to crowdsource and visualize some of the stories coming from ordinary people in the midst of Kenya’s post election violence. Last Wednesday the whole country went to the polls again, this time to vote “yes” or “no” on a referendum for a new constitution for the country – arguably something even more important than a politician who will only be in office for 5 years.

Being Ushahidi, and this being Kenya, we were ready to do our part. This came in the form of Uchaguzi, a deployment where we partnered with local groups like SODNET, Twaweza, CRECO and HIVOS. Ordinary Kenyans and election monitors alike could send in text messages to a local shortcode, which was widely advertised before the date. (read more here)

Over 50% of all incoming reports were verified in real-time, and an overwhelming 60+% were reports that things were going well. A win for both the deployment and the country!

A Thank You

Through a combination of great partners and a huge volunteer outpouring of time at the iHub, we were able to manage the inflow of information, mapping and verification.

The Uchaguzi project brought more than 70 volunteers to the iHub August 3rd and 4th (with at least 12 others joining remotely). Volunteers helped map and process over 1400 messages as well as assisted our team of Ushahidi developers fix bugs that popped up during the Uchaguzi deployment. The volunteers met the challenge with incredible enthusiasm, focus, patience, and a spirit of fun! We couldn’t be prouder to have such a wonderful Ushahidi community!

“We” isn’t just the Ushahidi team. Yes, deployments like this do take some time to customize and we did build some new functionality in (than everyone now has access to use), but it’s largely not the technology, it’s the people. The 80+ volunteers, tech and non-tech alike, were amazing and came through in a big way. Not enough can be said about Jessica Heinzelman, Ushahidi intern for this summer, who wrangled all of the volunteers and operations for the situation room.

Media Hits

Fast Company
Christian Science Monitor
Business Daily Africa
UN Dispatch
CNN iReport
All Africa
Reuters
Internews