Mobile Apps in Africa (2011 Report)

I maintain that Russell Southwood and his Balancing Act newsletter and reports are some of the best material on pan-African technology and broadcast information that you can find anywhere. Their recent “Mobile apps for Africa: Strategies to make sense of free and paid apps” report is one of them, and here are some interesting tidbits from it.

The report is broken into three parts: device, developers and distribution.

Device

South Africa, Egypt, Nigeria, Morocco, Ghana, Kenya and Tanzania all are good markets for apps, due to their population, 3g pickup and smartphone penetration. It should be noted that the highest smartphone penetration is in South Africa at 10%, though the high-potential countries are expected to grow by 8-10% per year over the next 3-5 years.

“Interestingly, infotainment activities score high off-line (using the phone’s features) and online (mobile Internet).”

Balancing Act provides a very interesting visual of what the “Handset pyramid shift” looks like in Africa.

Africa's handset pyramid, and its shift

Developers

The development of smartphone applications in particular commercial apps will depend on the rate and level of smartphone adoption. Developers in countries like South Africa, Kenya or Egypt with encouraging smartphone penetration rates have more opportunities in terms of apps development and uptake by potential users.

The major international apps stores (Apple, Android, etc) have set a figure of 70% of the revenue generated by apps will be going to the developer. This is very good news for African developers because so far with SMS based content, the revenue sharing model is not in favour of developers since less than 30% of the revenue generated by the content is going to the author. It is African mobile operators that make the most out of them as they take a minimum of 50% of the revenue generated by SMS services. The major international apps stores also offer additional revenue to developers via advertising and in-apps purchases. These revenue streams are becoming more and more significant for developers.

Building into the next section on distribution is the issue that developers have with creating apps for the international app stores. It’s very difficult, and often impossible, to sell apps on them and for African customers to buy them.

Distribution

The major consequence of the “success story” of the apps store is that it
establishes a distribution model for mobile content that breaks away from the monopoly and exclusivity that mobile operators have enjoyed so far on the delivery of services to their mobile subscribers. Today the mobile apps distribution ecosystem can roughly be divided in 4 main groups:

  1. Operating system app stores
  2. Handset manufacturer’s app stores
  3. Mobile operators’ app stores
  4. Independent app stores

So far, most African mobile operators have been little affected because smartphone penetration rates are very low in most African countries and also because African smartphone users still have access issues to the full portfolio of international apps stores.

The report goes on to express Balancing Act’s thoughts on how mobile operators can get into and take advantage of mobile app stores, “While revenue potentials are promising what else do mobile operators have to consider if they want to roll out their own apps store?” The report establishes the following 8 recommendations:

  1. Be OS agnostic
  2. Know the devices on your network
  3. Use “white label” apps store
  4. Source international content from third party content providers
  5. Don’t forget about additional revenue streams
  6. Build a strong local flavour to your apps store
  7. Make apps affordable to your subscribers
  8. Use carrier billing

And there’s More

Unfortunately, I can’t put all of the good stuff in this blog post. There are a lot more interesting points in the report, and you can buy it here. Amongst some of the best are:

  • What smartphones do South Africans want?
  • Nigerians love their BlackBerry
  • Examples of mobile apps start-ups companies in Africa
  • Morocco: Mobile internet users and penetration rate
  • Mobile Internet subscribers and market share per operator
  • Advertising and in-apps purchases potential income for developers

Pivot 25: East Africa’s Mobile Competition & Conference

I’m excited to announce Pivot 25, which will happen on June 14-15 in Nairobi.

If you’re an app developer or entrepreneur, submit your idea here!
Applications are due midnight (East Africa Time) March 15th, 2011

What is it?

Pivot 25 is an event bringing together East Africa’s top mobile entrepreneurs and startups to pitch their ideas to an audience of 400-500 people, with a chance of winning monetary prizes and increasing awareness of their work to local and global investors and businesses. In East Africa’s hot mobile market, this is a way to find out “what’s next?“.

The competition is for 25 entrepreneurs/startups to pitch their best mobile apps or services, in 5 different verticals, to the audience and a panel of judges. Anyone who has a new app or service can apply, if they’re from Uganda, Tanzania, Somalia, Sudan, Rwanda or Kenya.

Pivot 25 is mostly about the entrepreneurs and their pitches, but we’re also sprinkling it with fireside chats with the top mobile industry leaders in the region.

Get Involved

There are a couple of ways to get involved with Pivot 25.

  • Sponsor the event – we’re already getting some great sponsors on board, but there are still a couple areas available.
  • Enter your startup – this is the BIG one, if you make it to the event, the awareness will be huge and the prizes bigger!
  • Register to attend – we expect tickets to sell quickly, so get yours now before they’re all gone.

Help us get the word out by tweeting (our handle is @pivot25), blog it, and definitely tell your friends around East Africa to get their startup application in right away.

Some Background on Pivot 25

The mLab (mobile lab) is a new incubation, training and testing space for mobile apps in Kenya. It’s situated directly underneath the iHub, and was created from an infoDev grant to a consortium of the iHub, Emobilis, the Web Foundation and the University of Nairobi.

As the team behind the mLab got together and talked we realized that we needed to solve two problems. First, a good way to create awareness of and access between the mobile entrepreneur community and investors and businesses. Second, that an event could help raise funds for the mLab, making it sustainable.

The Event will not only showcase developer talent in the region but also bring much needed focus to the mLab and the role that it play’s in the mobile application development ecosystem in East Africa. Our goal is to make this truly inclusive, bringing together startups, manufacturers, businesses and operators from every country in East Africa. The mLab is accessible to anyone in any of these countries, and Pivot 25 is as well.

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.

Never Good Enough: Speed (pt 1/3)

We’re never good enough when it comes to speed, stability or simplicity of our mobile and web applications. This is a three-part series where I unpack my experience building apps on each of these subjects. It’s not just for those of us working on Ushahidi, these are the three most crucial abilities of any web or mobile application.

Me in a cyber cafe in Monrovia

Let me tell you a personal story:

Libera, March 2009

I’m sitting, sweating in the sweltering heat of a Monrovia cyber cafe, I have my notebook out and my am watching the clock. My goal is to see how fast I can load up the Ushahidi home page for the Democratic Republic of the Congo, it has a map, timeline and list of recent events tracking the current level of unrest in the country.

It’s not looking good. As I look around, waiting for the page to load, I count 8 others in the room – 6 of which have fired up stuttering and unusable Yahoo and Skype video chat windows. Why this is the channel and usage of choice, when it so obviously doesn’t work, I cannot answer. But this is reality, and if we expect ordinary Africans to use our application, we had better make sure that it loads up relatively fast on the low-bandwidth, shared internet connections that proliferate across the continent.

Utter failure. After 20 minutes painfully watching the page load byte by byte, I give up. I quickly type out a message to our team, imploring everyone to streamline this “fat, squeeling pig of a page”. Peppering them with questions… Can I buy some caching please? What can we do with this map to make it not kill the load? Can we get rid of 75% of the images on the page? Do we need to redesign this from the ground up?

Granted, Liberia’s internet situation is worse than almost any other on the continent. Especially when it comes to the grinding halt you see in the cyber cafes during the daylight hours as the local population piles on at the same time, completely overwhelming the limited satellite connection. That’s no excuse though. Ushahidi is built on the idea that the lowest common denominator, whether it’s PC or mobile-phone based access, will work. The PC-side is clearly failing.

Worst of all, my patience is short, Liberia is pissing me off with the heat, humidity, lack of bandwidth and no electricity grid. Objectively, this is the perfect state to be in, I am now able to come up with a solution for normal users in Africa.

What other’s know

Speed… if there’s only one thing that you do with your application, make it faster. No, it’s not fast enough.

This isn’t news to anyone, or it shouldn’t be. For years the major web sites around the world have known this and have been building for it. Mozilla, Amazon, Google and Facebook are all aware of just how critical speed is to their success. It boils down to attention threshold and what we, as users ourselves, are willing to put up with.

There is no area in which our team has felt more pain than in trying to speed up the page loads of our apps. Maps tend to be page killers by themselves. Once we add multiple calls to the database we start to get some truly agonizing speeds. It’s a constant pressure that sits on every one of our development cycles, and for which we dedicate a great deal of energy.

User experience research needed in Africa

One area that hasn’t seen enough true user experience testing is Africa. We know that internet speeds are slower, sometimes by orders of magnitude. I’ve got a lot of questions, more than answers at this point. Should we cut out the maps and all images? What’s the true cost of a page load +/- 7 seconds? What is the real value of maps in Africa compared to the West – do they matter?

Jessica Colaco is a top-notch programmer who has shifted to doing research in Kenya. I hope that she, and others like Eric Osiakwan and his team from Internet Research in Ghana, will help us dig out these answers. More than that, I hope they will help us ask the right questions.