August 2010

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

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

Here’s an interesting study by AVG on internet security, asking “Where in the World are you most likely to be hit by a malicious computer attack or virus?”.

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.

There’s an good post over at the CGAP blog about mobile money’s innovation crisis. The author claims that nothing new has happened in mobile money since Mpesa was launched in Kenya, except for maybe the launch of Mkesho this year in Kenya as well. Besides that, everyone around the world pretty much tries to duplicate what Safaricom is doing in this space.

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.

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

DukaPress is a new customized WordPress eCommerce platform. It allows you to easily set up a fully featured online shop which can be used to sell digital or physical goods to customers all over the world.

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.

It’s been hectic lately… In the course of one week I’m going from the madness that is running any situation room for a major Ushahidi deployment (Uchaguzi), to what is looking to be one of Africa’s best tech conferences (Tech4Africa).

(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

Safaricom is Kenya’s largest mobile operator with approximately 80% of the market. Most people don’t know this, but they get hundreds of business and technology proposals each week from people all over the country – techies and non-techies alike. It was with this problem in hand that they decided to open up an “Innovation Forum” for Kenyans to share their ideas.

In short, it was a disaster. Draconian legal terms and conditions mixed with ham-handed community engagement meant that they met with a lot of resistance and outright mockery on public channels such as Twitter and Facebook. Just a sample from one blogger:

Engaging the Community

Safaricom is now back to the drawing board. Their problem hasn’t gone away, they’re still overwhelmed with emails, letters and proposals for business ideas that might/might not make sense for them to engage on. Wadzanai Chiota-Madziva heads up their VAS (value added services) department, and is in charge of this. After the noise caused by the less-than-stellar launch of the Innovation Forum, she and CEO Michael Joseph met with one of the techies who was very concerned about the way they were handling this: Al Kags.

Al Kags has sat down in a couple of meetings with them thus far, finally he suggested a board that could serve as a buffer between Safaricom and the people sending in proposals. The Innovation Forum Board’s job would be to speak for the community to Safaricom, as well as push for better access to APIs, a developer sandbox and possibly and app store. They would also be responsible for helping to translate Safaricom’s position to the community.

I was invited, along with some other’s from the tech community, to sit down and discuss this with them last week. It was a fruitful discussion about the possibilities and the roles and responsibilities that the board would have.

Some of the discussion was about the need for a buffer to be created between Safaricom and submissions to foster fairness and openness, to provide confidence to developers to innovate without fears of intellectual property (IP) misappropriation.

“The intention is for the board to create a fair environment for innovatioin by playing the middle ground between Safaricom Ltd and the developer and innovator community”

The position is largely one of an enabler. The board would oversee the Innovation Forum by:

• Create and agree rules of engagement with all parties
• Advocate developers perspectives at Safaricom
• Facilitate understanding of Safaricom position with the developer/innovator community.

Figuring out the Board

The people invited for the meeting, as the potential board, were Moses Kemibaro, Jessica Colaco, Al Kags, Karanja Macharia, Rehema Parmena and myself.

While it is up to Safaricom to decide who is on their Innovation Forum Board, those of us at the meeting pushed back a little on how they had done this. If they want to interact with the community, it might behoove them to reach out to that community for some of the nominations.

They listened, and starting today going through the end of the week, you can make your own nominations for the Innovation Forum Board for Safaricom to review on the website. This is your chance to put a name in of someone that you think would represent the community well on the board.