Tag Archives: ushahidi

Ping: a Tool for Families and Groups to Check-in During Emergencies

It’s been a hectic 4 days in Nairobi. The Westgate siege is now over, so the President tells us, though there will be a lot of cleanup and forensics to do. Three days of national mourning start tomorrow.

The full Ushahidi team met yesterday (many virtually, of course), and we talked about many issues surrounding the Westgate siege. Not least amongst them was the fact that we had a hard time checking in with each other. And then found out that one of our team’s wife and 5 children were inside of the mall, while he was traveling out of country. They eventually got out a few hours later, to which we were relieved.

This lead us to then think through our skills and tools, and where we could be useful.

In an emergency, how do you find out quickly whether your family, your team, your friends are safe?

The Ping App - a group check-in tool for emergencies

The Ping App – a group check-in tool for emergencies

How About a Way to “Ping” Your Group?

There was a consistent problem in every disaster that happens, not just in Kenya, but everywhere. Small groups, families and companies need to quickly check in with each other. They need to “ping” one another to make sure they’re okay. It has to be something incredibly simple, that requires little thinking to use. People have been doing some stuff in this space in the past, the best like “I’m Ok” are focused on smartphone users, but we have a need to make it work for even the simplest phones. Our goal is to have this available for anyone globally to use.

“Ping” is basically a binary, multichannel check-in tool for groups. The idea is that families and organizations could use this for quick headcounts on how everyone was, then use it as an on-ramp into a Red Cross missing persons index or something like Google’s People Finder app.

We’re putting the first version of it up at Ping.Ushahidi.com – here’s how it works:

  • You create a list of your people (family, organization), and each person also adds another contact who is close to them (spouse, roommate, boy/girlfriend, etc).
  • When a disaster happens, you send out a message for everyone to check-in. The admin sends out a 120 character message that always has “are you ok?” appended to the end.
  • This goes out via text message and email (more channels can be added later).
  • The message goes out three times, once every 5 minutes. If there is a response, then that person is considered okay. If no response, then 3 messages get sent to their other contact.
  • We file each response into one of 3 areas: responded (verified), not responded, not okay.
  • Every message that comes back from someone in that group is saved into a big bucket of text, that the admin can add notes to if needed.
Ping Notes, Features

Ping Notes, Features

Ping Architecture - rough draft

Ping Architecture – rough draft

Yesterday we quickly wireframed out a list of needs, some design basics, and an architecture plan (images above), got a rough product going on it (code is on Github). We now need to make it look better, so some designers are working up some stuff to make it work well on both phones and computers.

Mockups of the Ping app, still undergoing some design tweeks

Mockups of the Ping app, still undergoing some design tweeks

Final touches are to add in:

  • Account creation, we’re using our CrowdmapID tool for this, since it’s already out
  • Message “send” page
  • Archive old campaigns feature
  • Wire into text messaging service (Nexmo or Twilio), and then testing it out internally
  • Designing it so it looks good (responsive design, so it works on mobiles and PCs)

If you’d like to help out, jump on the Github repo, and get in touch with us about what you can do. What we have here is a minimum viable product (MVP) right now, open source, so anyone can make it better by branching the code and adding in features, etc.

Finally, a HUGE thank you to the people who have been burning the midnight oil to make this all happen in 24 hours:

@udezekene (visiting from Nigeria)
@EmiliaMaj (visiting from Poland)
@gr2m (visiting from Germany)
@Dkobia (Ushahidi)
@LKamau (Ushahidi)
@bytebandit (Ushahidi)
@DigitalAfrican (Ushahidi)

Tech Links Around Africa, March 2013

[Last week I had a security problem with WordPress, which is fixed now, my apologies for any inconvenience]

Pivot East, our East African pitching competition, will be held in Uganda for the first time this year. Get your applications in, and plan your travel for June 25-26th in Kampala.

Bosun Tijani and the ccHub are part of what I think is a fantastic idea. Instead of building a “tech city”, they’re creating a “tech neighborhood” in Lagos, Nigeria with many partners.

Nigeria's I-HQ project

The three types of tech incubators in Africa. I disagree a bit here, but will save that for another post.

A long essay, comparing Kenya and Rwanda’s efforts to become the tech hub of East Africa.

Surprising no one, Uganda’s mobile money service eclipses traditional banking with 8.9m users (compared to 3.6m for banks).

Good article by The Next Web on how winning in African tech is a patience game.

Not specifically about Africa, but here’s a great graphic that maps out the alternative financial ecosystem, of which mobile money plays a significant role.

I love this Africa-inspired Foosball table design, which would be made better without all the NGO crap on it.
African-foosball

Personal Link Updates:

A 2013 Uchaguzi Retrospective

MRTN8684


UPDATE: Here’s the report put together by the iHub Research team (3Mb PDF): Uchaguzi Kenya 2013

The elections in Kenya this year have had a lot of drama, nothing new there. As I wrote about last week, Ushahidi has been involved quite heavily on the crowdsourcing side via Uchaguzi, which meant that we had an exhausting week as the results kept getting extended each day.

Uchaguzi Update

Some basic statistics:

  • 5,011 SMS messages sent in (that weren’t spam or junk, as those got deleted)
  • 4,958 reports were created (from SMS messages, the web form, email and media monitoring teams)
  • 4,000 reports were approved to go live on the map
  • 2,693 reports were verified (67% of approved reports)

Notes and Links:

  • Many reports, links an updates can be found on our virtual situation room
  • The analysis team provided twice daily rundowns based on verified data at http://visuals.uchaguzi.co.ke/
  • Rob created a map visual to show the reports coming into Uchaguzi over time.
  • The IEBC tech system failed, I started a Tumblr trying to figure out how the system was built, which companies were involved and what they did, and what actually went wrong.
  • Before the IEBC tech system was shut off, Mikel used their API to create maps (1, 2) and Jeff and Charles created a mobile-friendly results site as well.
  • Heather wrote up a good post on our situation room blog about what we’ve learned along the way.

Here’s an Uchaguzi community graphic:
Uchaguzi community graphic

Uchaguzi: Full-Circle on Kenya’s Elections

Uchaguzi: 2013 Kenyan Election Monitoring Project

Just over 5 years ago, I was just like everyone else tuning into the social media flow of blogs, tweets and FB updates along with reading the mainstream media news about the Kenyan elections. We all know the story – thing fell apart, a small team came together and built Ushahidi, and we started building a new way to handle real-time crisis information. We were reacting and behind from the beginning.

(side note: here are some of my early blog posts from 2008: launching Ushahidi, the day after, and feature thoughts)

Now, the day before Kenya’s elections, I’m sitting in the Uchaguzi Situation Room, we’ve got a live site up already receiving information, 5 years of experience building the software and learning about real-time crowdmapping. There are over 200 volunteers already trained up and ready to help manage the flow of information from the public. This time Kenya’s IEBC is ready, they’re digital, and are doing a phenomenal job of providing base layer data, plus real-time tomorrow (we hope).

In short, we’re a lot more prepared than 2008 in 2013, everyone is. However, you’re never actually ready for a big deployment, by it’s very nature the crowdsourcing of information leads to a response reaction, you’re always behind the action. So, our main goal is to make that response processing of signal from noise and getting it to the responding organizations, as fast as possible.

Uchaguzi 2013

If you’d like to know more about the Uchaguzi project, find it on the about page. In short, Uchaguzi is an Ushahidi deployment to monitor the Kenyan general election on March 4th 2013. Our aim is to help Kenya have a free, fair, peaceful, and credible general election. Uchaguzi’s strategy for this is to contribute to stability in Kenya by increasing transparency and accountability through active citizen participation in the electoral cycles.This strategy is implemented through building a broad network of civil society around Uchaguzi as the national citizen centred electoral observation platform that responds to citizen observations.

The next couple days I’ll be heads-down on Uchaguzi, running our Situation Room online and Twitter account (@Uchaguzi), and troubleshooting things here with the team. We’re already getting a lot of information, trying to work out the kinks in how we process the 1,500+ SMS messages that people have sent into our 3002 shortcode, so that tomorrow when things really get crazy we’re ready.

I’ve already written up a bunch on how Uchaguzi works, so I’ll just post the information flow process for it here:

Uchaguzi's workflow process

Uchaguzi’s workflow process

Your Job

As in 2008, your job remains the same; to get the word out to your friends in Kenya, to get more reports into the system, and to support groups working towards a good election experience.

A huge thank you to the local and global volunteers who’ve put in many, many hours in the workup to tomorrow and who will be incredibly busy for the next 48 hours. Besides the hard work of going through SMS messages and creating geolocated reports out of them, some of the geomapping team have been busy taking the police contact information and mapping it. They’ve created an overlay of the data, it’s on this page right now, but our plans are to put this on the main map later.

Just as in 2008, a few people are making a big difference. All of the volunteers doing the little they can to make their country better.

Geomapping team for Uchaguzi

  • Leonard Korir
  • Samuel Daniel
  • Luke Men Orio
  • Slyvia Makario
  • Wawa Enock
  • Mathew Mbiyu

Some other helpful links for the Kenyan elections

IEBC
Find your polling station
Voter education
Mzalendo
Got To Vote
Wenyenche
Google Elections Site
The Kenyan Human Rights Commission
Mars Group
Kenya Nation Election Coverage
Standard Media Kenya
Kenya’s Freedom Media Council

Poaching, Carbon and Tech in Tsavo

I’m disconnected. Off-grid in the usually dusty and dry (though green currently) Tsavo region of Kenya with seven others from the Ushahidi team as we look into whether or not technology can be useful on the Rukinga Sanctuary.

We’re here to see if our technology, or the knowledge of what can be done with tech, is useful in carbon monitoring of deforestation, security operations with rangers and/or better engaging with the surrounding community?

David Kobia talks to Dr Mwangi Gichiru of Wildlife Works carbon project

David Kobia talks to Dr Mwangi Gichiru of Wildlife Works carbon project

The Wildlife Works team has an extensive for-profit program around carbon credits, carbon offsets, and small factories in an EPZ where brands like Puma get their “made in Kenya” stamp. It’s maybe the most impressive example of what could be termed a “social enterprise” that I’ve ever seen. Over 300 people have jobs due to their presence, and all in the community monetarily benefit from their activities.

The 75,000 acre sanctuary sits just south of Voi, off the Mombasa road. Rukinga was the first place in the world to be VCS (verified carbon standard) verified and REDD (Reduced Emissions from Deforestation and Degradation) certified by the UN, and has since grown to encompass the 13 other ranches and 1/2 million acres surrounding them. 60,000 people in the communities surrounding them are financial beneficiaries from the project.

Last year they sold sold 1.4 million tons of carbon credits for around $6-8 per ton. The revenue from that is split into three parts; 1/3 goes to the land owner(s), 1/3 goes to the managing company (Wildlife Works) and 1/3 goes to the community. Interestingly, unlike a lot of NGO work, the team doesn’t decide how the community should benefit. The community decides how to spend the money, through their own local committees, and it’s led to a huge amount of school bursaries (2,000 kids now in secondary and tertiary schools), water catchements and other public works.

It’s impressive.

So, what does Wildlife Works really do at Rukinga?

In short, they try to increase the amount of trees, protect the animals, while balancing that with the local community.

An elephant in Rukinga Sanctuary, Kenya

An elephant in Rukinga Sanctuary, Kenya

This is where the problems arise as there are encroachments for wood by charcoal burners and poachers killing the elephants. Due to the community benefiting from the ranches, there has been a decrease in the amount of charcoal burners and even the local poison-arrow elephant poachers and bushmeat hunters have reduced.

However, there’s a much bigger problem, that of commercial poachers (mostly of Somali descent) who come down from NE Kenya, with sophisticated weapons and who are experienced in tactical movement. They come in teams of 2-10, using their mobile phones for coordination, moving fast and anchoring off the Mombasa Highway. Often they have buried caches of guns and ivory on the ranch, so they don’t even carry those in or out with them, and they can blend in easily.

18 rhinos have been killed since the holidays in Kenya alone, and elephant tusks sell for around $300/kilo, so provides a massive incentive for income for anyone.

“We’ve been working in Kenya for the past 17 years… We lost 10 elephants to ivory poachers in the first 15 years, and 45 in the last 18 months, and this is despite being a relatively well-funded organization with extraordinary relationships with the local community members who benefit from wildlife,” says Wildlife Works founder and CEO Mike Korchinsky.

The rangers have no weapons. They are highly skilled at finding and tracking the poachers, but need the Kenya Wildlife Service (KWS) to come if they’re going to catch someone. KWS is sometimes slow to respond, and they’re not willing to put their life on the line in order to catch or kill the poachers. When a poacher is caught, the laws are not stiff enough to disincentivize others.

Talking with the Wildlife Works security and operations team

Talking with the Wildlife Works security and operations team

The Tech

So, where can tech help? We don’t know yet, is the answer.

To frame the problem of biodiversity protection, if you get to the animal or tree after it’s dead, then it’s too late. What you really want is prevention. If you can’t get prevention, then you need swift and effective response.

Prevention
We’re wondering if there’s a way to get the community interacting through SMS to pass on information about illegal activities. Beyond informants, we’re thinking that there might be a useful way to connect the local community monitors and make reporting on human-wildlife conflicts more efficient.

Response
The teams of 100+ rangers are on foot a lot, carry a GPS and do have some mobile coverage. They create reports when they come in, and their goal is to be light, hardy and fast. All of them already carry cheap Nokia-type phones, so can send SMS and call, and we’re thinking that a very simple text messaging system as a hub might come in handy for coordination and archived messaging for later assessment (and possibly mapping).

Other Ideas

  • There is a lack of information on all types of location-based data, especially once you get off the main road. There’s an opportunity to do a community-level mapping exercise, tied to Open Street Map.
  • The process for getting GPS-related data from the rangers to HQ and then a map takes a couple weeks. Surely there is a way to make this more efficient.
  • Related to the rangers data is that they rarely see the output of the GPS data and forms that they fill out. Could we create a faster way to visualize it, and let them see their work?
  • It seems to me that if you were able to gather the phones and SIM cards off caught poachers, then you could start dumping their address books and pattern matching for similarities. We could also see if it is possible to streamline the process for legally getting call log data for those SIM cards from the mobile operators.

The camp we’re staying at is situated has a generator that provides backup power in the evenings for a few hours, where we get our daily recharge-dose for our gadgets. If you stand in just the right place you get one bar of connectivity on your phone and send out text messages.

It’s a shock to our digitally connected system when we find ourselves without a digital tether. It’s also a wonderful reminder of the constraints that real life problems have, where technology helps and/or hinders and why simple solutions tend to be the best.

While we’d love to just shove an Android phone in every rangers pocket, it’s probably not the answer. Instead, as my battery dies, I sit here thinking that we’ll revert to our simplest messaging solution (aka SMS) for any communications tools. It also reminds me that technology is at it’s best when it’s a small component that makes one thing work better, faster or more efficiently. If all we were to do was take one pain point out of the Wildlife Works people’s lives, then that would be enough.

(Sidenote: Limo rubs it in that his Blackberry gets messages and calls, and much to my shame he’s right, it’s better than any of the Android of iPhone devices for connection on the edge of network connectivity. Maybe there is still a place for RIM…)

A huge thanks to Taylor Martyn for coming with us and taking some great pictures (seen here)!

What makes the iHub work?

I often get asked what the iHub is, what happens here, and why it has worked. Often followed by the question of whether or not this model could work elsewhere in Africa. Here are my thoughts on the matter.

The iHub is Nairobi’s nerve center for technology; a place where we can grab coffee, create apps, find funders and build businesses. It’s where the community of web and mobile programmers connect with each other, businesses, the government and academia.

[TLDR version: Championed by credible people, alongside advisors from the community. Experimental mindset. Strong connections to corporates. Strict community focus.]

A brief history

Juliana, Erik and David

There was a discussion at Barcamp Nairobi 2008 about how valuable it would be for the Kenyan tech community to have a static space of our own. No one would fund that idea. My organization, Ushahidi, decided that we liked it the idea enough that we would fund it. It fit with our overall thoughts on being “open”, it would serve as Ushahidi’s home in the region, and most of all, we thought we could use our good fortune to find and help the next startups in Kenya.

Thus, I moved back to Nairobi in 2009, with funding from Ushahidi via Omidyar Network and Hivos, to build the iHub. I quickly selected a space, and picked the energetic and gifted Jessica Colaco as the Manager. In March 2010 we started work on the space, and in June it was open for use.

Though we had provided funding for the first 2 years, the iHub is an independent Ushahidi initiative. Meaning, that it runs outside of the normal Ushahidi operations and organization. Though the Ushahidi team has full access for the space, we have a very light footprint, and use it the same way everyone else in the community does. We knew that even though we were the most neutral of parties, with a ton of local credibility, trying to “own” the space would fail – just as it would if it had been named the “Google iHub” or the “Nokia Innovation Hub”. It had to be owned by the community, and that meant name and usage both.

The community

IMG_8629

At the heart of all that happens at the iHub is the community. They designed the room layout and logo, run the network, hold events, built the website, create the house rules and drive the direction of the space. The management of the space is there to provide basic infrastructure support, a foundation, which the community then builds on to make the space what it is today.

What’s important to understand is that we come from this community too, we are it. We knew it could work because it was ourselves we were building for. When people ask me if I could do the same thing in another city, I respond that it would be questionable. A space like the iHub needs to be put together by someone from that community of techies who understands at a basic level the needs and has the credibility within it to make it happen.

As the iHub grew, we realized that all of the administrative duties, mixed with community interaction, were too much for one person. Thus we brought on Tosh to be the community manager, where he is in charge of working with people, memberships and events. His job is to aggregate, translate and enable the communities needs.

The advisors

That “being part of the community” was what drove me to start looking for a small team of advisors who could help make decisions, especially early on. This iHub advisory board was made up of 4 influential and highly credible technology players from Nairobi, plus myself. The greater community could appreciate that they were being represented well, and it provided a small enough team to move quickly.

Initial roles for this team were to make the final decision on build out design, logo and name, as well as figure out how to deal with an influx of members in a tiered membership model if the need arose (and it did, quickly). With over 4,300 white-level members, this team is also responsible for making the decisions on who gets green-level membership, the people who ultimately get to have free and unfettered access to the iHub facility.

The design

IHub Nairobi Incubator 3D

The design of the space was very important, and we were lucky to have Fady Rostom and Kwame Nyongo to lead the design team. They spent a lot of time listening to the ideas and thoughts of the advisory team before they started drawing, and it shows in what was built.

We needed a place that was open, and could be flexibly turned from community commons to event space. We wanted a subsection of the space to be rentable desks, for pre-incubation and co-working activities. At no time was a coffee shop not included – it was seen as core to the vibe and culture of what would happen here. We’d need a secure server room, and plenty of ethernet and electrical points, both inside and outside.

Most of all, the iHub needed to be a place where Kenyan techies were proud of. A place that was uniquely ours, and that we could show off to our visiting friends from abroad. It had to have the feel of being any high-tech community space in the world, with a Kenyan flavor. And it is.

The sustainability strategy

Early on we had no idea how we would pay for things beyond the first 2 years. We projected costs, but didn’t know where the revenue would come from. We had some ideas, but instead of creating a grand plan, we decided to take a very experimental approach, iterating on what worked and killing ideas that didn’t fit.

Right now the iHub has revenue coming in from red members (co-working desk rental), events and the new research arm. Events and desk rental were obvious and worked from very early on. The R@iHub arm didn’t come into being until January of this year, and was very much a big experiment – which appears to be working marvelously well. Jessica’s background is as a technology researcher, and she’s built a brilliant team around her to focus on this. Already we can see that 50%+ of future income will come from this initiative.

The other experiment was taking lead on the m:lab, a space the same size as the iHub which sits one floor beneath us. It’s an incubator. It plays the iHub’s foil, where upstairs is about community, openness and fun, the m:lab downstairs is about professional tech companies building quality products and making it into the market. We took the lead on the consortium behind this, and it is seen as a sister-facility to the iHub, with many shared services between the two.

The corporates

Both the iHub and the m:lab have strong corporate partners. Early on, before the first brush of paint was dry in the iHub, we had started talking to big technology corporates who call Nairobi home. Large tech corporations need an active dev community, and the dev community needs them. Luckily, Kenya is geographically well-positioned for some great companies to make it their home in the region, which worked well for us. We also happened to know a number of them personally, which sped up the discussions and interactions considerably.

We didn’t want to just have corporate partners who were sponsors. We made it very clear early on that their money was less important to us than what value they could add to the space that would help the dev community, but that it was a 2 way street. If we couldn’t facilitate a strong value back to them from the local tech community, then it was a no-go.

Fortunately, despite our lack of a clear idea of exactly how things would work, or what our metrics of success would be, we found some great patners. Nokia, Google, Wananchi and Microsoft are corporate partners with the iHub, and downstairs we have MIH, Nokia and InMobi working with us.

A small aside here, which isn’t corporates, but we’ve also nurtured strong connections with the Kenyan government, though we take no money from them. This also applies to academia.

Final thoughts

IMG_8578

By the end of 2010 people were already claiming that the iHub was a model for technology engagement, aid stuff (gah!), etc… in Africa. I thought that was a premature statement, it was an experiment and it still is. The success of the iHub has come from a strong foundation of advisors and community members who understand their city, their peers and their region.

The success of other tech hubs across Africa will be based on leadership credibility, and ability to engage their community.

Much of the iHub’s success comes from a community that works together. In that spirit of “harambee” that is so much a part of our Kenyan life. While there is always healthy competition, we would rather work together and celebrate each others success, and ultimately help each other along with the knowledge that if more of us succeed, then we all benefit.

I hope to see many more labs and hubs across the continent, and we’re seeing them grow too, in Cameroon and Ethiopia, Uganda and Nigeria. Though some of them will need financial assistance to get going, like Ushahidi did with the iHub, they’re organic growth is what makes them viable.

Ushahidi Strategy Meeting 2011

[Reposted from the Ushahidi Blog]

Yesterday Ushahidi won the Kenya ICT Award for “Social Equity and Poverty Reduction“, which we’re extremely grateful for. None of us were able to attend the conference in Kenya due to the whole team being at our big annual meeting.

The Ushahidi core team works from 7 different timezones ranging from Kampala to Louisville, soon expanding to places like Brazil and Korea. One weekend a year we’re able to get together, in-person, to solidify our connections with each other and talk through the big strategic topics that are best done face-to-face. It could be argued that it’s the most important 3 days of the year for us.

The First XV

2010 was a big growth year for Ushahidi, where we got up to 12 core team members – doubling in size from 2009. We’re adding 3 more people this year, which brings us to 15, a fortuitous number for the team as many of us are big rugby fans. :)

(Caleb decided to have a little fun, putting us all in our positions based on the date that we joined the team.)

12 Months Later

Last year we met in Miami, as we are this year, and a lot has happened since then. To name the big ones:

  • Plugins – extensible way to add new functionality without bloating the core
  • Crowdmap – maps for non-developers, also a means to quickly collect reports giving deployers time to install their own server
  • SMSSync – simple and robust alternative to Frontline and Clickatell
  • iOS – rich smart phone experience
  • Checkins – opens platform to entirely new uses
  • Stand-By Task Force – game changer in disaster response
  • J2ME – extending reaching onto older devices
  • Community Site – fantastic documentation
  • Map Geometry

Looking at the historical record, it’s been a good year. However, there’s a lot more to do. At this meeting, besides drinking a Mojito on South Beach, we’ll get into some of the big future-looking issues, such as:

Visual Reporting: What’s the perfect Ushahidi dashboard? How do we surface “power stats” for Ushahidi deployments and metrics. Swift-Ushahidi integration visuals on the front and back end.

Knowledge Management: How do we come up with a plan to capture information that we know internally, so that it is shared with deployers and developers better?
The inverse, how do we handle and capture information that our *users* know regularly?

Crowdmap Scalability & Migration: Making sure that even the biggest deployments work on Crowdmap. Adding in new a la carte features, etc.

Of course, this is a chance to discuss some of the more mundane items as well, around operations, funds and how we work towards organizational financial sustainability as well. It also means that we’ll be offline from today until about Tuesday of next week. We’ll be a little slower on email and other communications mediums, but bear with us as it’s for a good cause.

Quick Hits Around African Tech

Umbono: Google’s South African Incubator

In Cape Town, Google has initiated a tech incubator that gives 6 months of free space, $25-50k startup funding and access to an extensive mentoring network. The secret sauce here is in the angel & mentor network, who will be providing 50% of all investment money, while Google provides the rest. Johanna Kollar leads this initiative, and tells me they’re looking for at least 5 companies to get behind in this first go at it, though if there are enough exceptional applicants, they might do more. If you’re a registered business in South Africa, then you can participate. (more on the Google Africa blog)

The BoBs

Deutsche Welle runs the “Best of Blogs” awards each year, showcasing excellent blogs from all over the world. If you haven’t yet, take a few minutes and vote for your favorites. There are quite a few from North Africa.

21st Century Challenges: Digital Technology in Africa

I’ll be a guest to the Royal Geographic Society in London on May 18th for a discussion on technology in Africa with Nicholas Negroponte, Herman Chinery-Hesse and moderated by Bog Geldof. Our main topic:

“Can digital technology such as laptops and mobile phones offer the countries of Africa realistic economic and educational opportunities?”

If you’re in London, you can get a ticket to the event and join us.

Ushahidi moves

There are over 10,000 deployments of the Ushahidi platform around the world, and as you might imagine, a lot has been happening at Ushahidi, including:

  • The launch of Crowdmap Checkins at SXSW, a way to “roll your own Foursquare-type service”. It’s in it’s beta stage, but you can play with it now, as others have already using the Ushahidi Android or iOS apps.
  • Some amazing people created a Japan deployment after the earthquake and tsunami there, we helped by getting our SwiftRiver Sweeper app to do real-time translation using Google’s APIs.
  • Japan earthquake Ushahidi data, heatmapped

    Japan earthquake Ushahidi data, heatmapped

  • We’ve released some reports on past deployments and are part way through an evaluation by the Harvard Humanitarian Initiative.
  • One of our volunteer deployers, Anahi Ayala Iacucci, spent a great deal of time and created a 90+ page Ushahidi manual for anyone looking to deploy Ushahidi. Having worked on over 20 deployments of her own, she’s one of the best placed people in the world to do this.

Samsung Seeks to Grow in Africa

Samsung is opening a new Electronics Engineering Academy for youth in Boksburg, South Africa. As Afrinnovator states, they have about 20% of the market, which will only increase as they’ve been smart enough to get behind Android in their devices (currently with 22 models). We’ve felt this presence at the iHub in Nairobi as well, where Samsung has a great interest in reaching out to Android programmers.

SwiftRiver: Curating in an Age of Information Overload

In an age of information abundance, curating meaning is key.

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

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

Making Ushahidi

[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:

The Ushahidi Team - circa Jan 2008

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

allocation

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!

The Ushahidi 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.