Due diligence? We need an app for that.

The ubiquity of mobile phones, the reach of the Internet, the shear number of problems facing the planet, competitions and challenges galore, pots of money and strong media interest in tech-for-good projects has today created the perfect storm. Not a day goes by without the release of an app hoping to solve something, and the fact so many people are building so many apps to fix so many problems can only be a good thing. Right?

The only problem is this. It’s become impossible to tell good from bad, even real from fake. It’s something of a Wild West out there. So it was no surprise to see this happening recently. Quoting The Guardian:

An app which purported to offer aid to refugees lost in the Mediterranean has been pulled from Apple’s App Store after it was revealed as a fake. The I Sea app, which also won a Bronze medal at the Cannes Lions conference on Monday night, presented itself as a tool to help report refugees lost at sea, using real-time satellite footage to identify boats in trouble and highlighting their location to the Malta-based Migrant Offshore Aid Station (Moas), which would provide help.

In fact, the app did nothing of the sort. Rather than presenting real-time satellite footage – a difficult and expensive task – it instead simply shows a portion of a static, unchanging image. And while it claims to show the weather in the southern Mediterranean, that too isn’t that accurate: it’s for Western Libya.

The worry isn’t only that someone would decide to build a fake app which ‘tackles’ such an emotive subject, but the fact that this particular app won an award and received favourable press. Wired, Mashable, the Evening Standard and Reuters all spoke positively about it. Did no-one check that it did what it said it did?

i-sea-app

This whole episode reminds me of something Joel Selanikio wrote in his contributing chapter to two books I’ve recently edited and published. In his chapters, which touch on his work on the Magpi data collection tool in addition to some of the challenges facing the tech-for-development community, Joel wrote:

In going over our user activity logs for the online Magpi app, I quickly realised that no-one from any of our funding organisations was listed. Apparently no-one who was paying us had ever seen our working software! This didn’t seem to make sense. Who would pay for software without ever looking at it? And if our funders hadn’t seen the software, what information were they using when they decided whether to fund us each year?

Donors are not alone. Whether you’re the media, or a judge in a competition, or a charity looking to make use of an app, surely there’s an expectation that some due diligence will be done. In the case of I Sea, perhaps some was, but clearly not enough.

refugee-apps-tweet

The shear number of apps available that claim to solve all manner of problems may seem encouraging on the surface – 1,500 (and counting) to help refugees might be a case in point – but how many are useful? How many are being used? How many solve a problem? And how many are real?

Due diligence? Maybe it’s time we had an app for that.

1995. 2005. 2015. Two decades of code

Precisely ten years ago this morning I sat down at a kitchen table in Finland and started coding. Armed with a Visual Basic.net manual, a laptop and GSM modem, a couple of SIMs and a Nokia 6100 and cable – and plenty of coffee – I delved into the world of Windows programming for the very first time.

I’d already done a fair amount of professional software development over the years, designing and building a membership/fundraising system for Jersey Zoo, and a range of accounting and amortisation systems for a legal firm, but that was ten years earlier in the mid-1990’s when QuickBASIC was my weapon of choice. Ten years had passed, and I’d never written anything event-driven before. I was on a steep learning curve, but was motivated.

quickbasic

I’d already figured out earlier that year that I could drive a mobile phone by sending it a series of Hayes commands through a cable – that was my epiphany moment, so-to-speak – so my task that summer was to try and build a nice user interface around it. It sounds almost crazy now to think that a lot of this was new, but back then very few people were building messaging platforms, and even fewer building messaging platforms aimed at grassroots non-profits in the developing world. After two years working across South Africa and Mozambique it had already become blatantly clear to me that there was a growing need there that nobody seemed willing, or able, to meet.

One of the big advantages I had back in 2005 was that it was easy to hide away and be left alone to focus on a project like this. Anyone with no team, no money and a big project idea knows all too well how important it is to be able to get away and focus. Thanks to the luxury of being unknown in the ICT4D world I was able to hide well enough to write a working prototype of FrontlineSMS in just five weeks.

FLSMS-vb-net

Designing the ContactManager form

FLSMS-coding

Coding ContactManager

FLSMS-ContactManager

The finished, compiled article

FLSMS-web

The first FrontlineSMS website, built in a day. The field banner was the view outside

Fast forward to today, I once again sit hidden away taking on a new coding challenge (my decades of code seem to take me from 1995 to 2005 to 2015, which may or may not be significant). In a similar vein to my attempts to tackle Windows programming in 2005 – which didn’t turn out too badly, I guess – today I’ve started work on my first iOS app. With a long list of ideas it’ll hopefully be the first of a few. Not surprisingly, they are pretty-much all based on improving how we interact and engage with the people, causes and world around us. I’m close to securing angel investment for the first app, which is another first. And it has a solid business model, which is another.

Interestingly, my brushes with code seem to have taken me through each of the key platforms of the past twenty years – MS-DOS, Microsoft Windows and, now, iOS. And, like 2005, I find myself with a window of opportunity to hide away and code as I continue my summer sabbatical. Watch this space for more.

An inconvenient truth?

Exactly ten years ago this month I was preparing for my first ever piece of work in mobile, two years of work which would lead to the development of an innovative conservation service in 2003 – wildlive! – and the release of one of the earliest reports [PDF] on the application of mobile technology in conservation and development in 2004. A lot has happened since then, not least an explosion in interest, buzz, excitement – and, yes, hype – and a sense that mobile can be the saviour of, well, everything. Back then you’d likely be able to fit everyone working in mobile-for-development (m4d) into a small cafe. Today you’d need at least a football stadium. m4d – and it’s big brother, ICT4D – have become big business.

Not that I needed more proof of mobile’s status at development’s top table, earlier this week I attended Vodafone’s “Mobile for Good” Summit in London. It was a high-profile affair, and an extremely upbeat one at that. I left with mixed feelings about where m4d is headed.

My five takeaways after a day of talks, debates and demonstrations were:

1. Everyone is still excited by the potential of mobile
2. The same projects surface over and over again as proof mobile works
3. Mobile is still largely seen as a solution, not a tool

4. It’s up to the developed world to get mobile working for the poor
5. The top-down mindset is alive and well

Suffice to say, all of these conclusions troubled me as I sat on the train home.

I’ve been thinking for some time about the future of m4d, and how far we’ve got over the past ten years or so. I’ve written frequently about the opportunities mobile technology offers the development community, and my fears that we may end up missing a golden opportunity (see Time to eat our own dog food?” from March 2009). I’ve long been a champion of platforms, and understanding how we might build tools for problem owners to take and deploy on their own terms. Yes, we should provide local entrepreneurs and grassroots non-profits with tools – and where appropriate and requested, expertise – but we shouldn’t develop solutions to problems we don’t understand, we shouldn’t take ownership of a problem that isn’t ours and we certainly shouldn’t build things thousands of miles away and then jump on a plane in search of a home for them.

But this is still, on the whole, what seems to be happening. And this, I’m beginning to believe, is rapidly becoming ICT4D’s “inconvenient truth”.

A fulfilled future for ICT4D (of which m4d is an increasingly dominant part) is not the one I see playing out today. It’s future is not in the hands of western corporates or international NGOs meeting in high-profile gatherings, and it’s not in our education establishments who keep busy training computer scientists and business graduates in the West to fix the problems of ‘others’. The whole development agenda is shifting, and my prediction for the future sees a major disconnect between what ‘we’ think needs to be done, and what those closest to the problems think needs to be done. Call it “disruptive development“, if you like. As I told the Guardian in an interview earlier this month:

The rise of homegrown solutions to development problems will be most crucial in future. That means African software developers increasingly designing and developing solutions to African problems, many of which have previously been tackled by outsiders. This, I think, will be the biggest change in how development is ‘done’

I’m not the only person to be saying this. Many good friends working at the intersection of African development and technology have been doing the same for some time. The real change, and the big difference, is that it’s finally happening. A message which was previously given in hope, a message that was previously given out of an inherent belief that there was a better, more respectful and appropriate way of doing things, is now becoming reality. ICT4D is changing, and the balance of power is changing with it.

FrontlineSMS has always spoken to an approach I’ve long believed in, one where users are empowered to develop solutions to their own problems if they so wish. There are many reasons why FrontlineSMS continues to work – the decision of the new Management Team to shift software development to Nairobi is one of the more recent ones. But fundamentally it’s about what the platform does (and doesn’t do) that really resonates with innovators, entrepreneurs, non-profits and problem owners across the developing world. As the Guardian put it in the recent article, “As open-source technology for mobile platforms, innovations like FrontlineSMS are essentially a blank canvas for grassroots organisations to apply to any local context”.

That local context is becoming increasingly vibrant as university students across Africa graduate with Computer Science and Business Management degrees; as innovation hubs spring up across the continent meeting a growing, insatiable demand for places to meet, work and network with like-minded problem solvers and entrepreneurs; and as investors launch funds that show they’re starting to take young African tech startups seriously.

This activity hasn’t escaped big business. Google, IBM, Microsoft, Nokia, Hewlett Packard and Samsung have been opening offices across the continent, snapping up much of the talent in the process (ironically often at the expense – and despair – of locally-based NGOs). But while technology businesses take note and develop local capacity that enables them to develop more appropriate local solutions, the broader development ‘community’ seem trapped in an older mindset of technology transfer.

Technology transfer, of course, is big business – there’s no shortage of donor money out there for projects that seek to implement the latest and greatest proven Western innovations in a development context, and there are countless tens of thousands of jobs that keep the whole machine running. A lot has to change if the development community is to face up to all its new realities, yet it’s looking more likely that the destiny of the discipline lies in the hands of the very people it originally set out to help.

So, if the future of ICT4D is not university students, NGOs or business graduates devising solutions in labs and hubs thousands of miles away from their intended users, what is it?

Well, how about something a little more like this?

It seems rather obvious to put a local technology entrepreneur on a bus and have him chat to a rural farmer, but imagine what might be possible if this approach became the “new ICT4D”, not that the entrepreneur or the farmer would see it as that, or ‘development’ at all. You can see more of the fascinating TV series which linked local technologists to local problems on the TVE website. There’s a lot that’s right with this approach, particularly if you consider what would usually happen (hint: it involves planes).

I’m not usually one for making predictions but it is that time of year, after all, and it is my ten year anniversary in mobile. So here’s a biggie.

Development is changing, powered by accessible and affordable liberating technologies and an emerging army of determined, local talent. A local talent that is gradually acquiring the skills, resources and support it needs to take back ownership of many of its problems – problems it never took original ownership of because those very skills and resources were not available.

Well, now they are. The ICT4D community – education establishments, donors and technologists among them – need to collectively recognise that it needs to ajdust to this new reality, and work with technologists, entrepreneurs and grassroots non-profits across the developing world to accelerate what has become an inevitable shift. Or it can continue as it is, and become increasingly irrelevant. “Innovate or die” doesn’t just apply to the technologies plied by the ICT4D community. It applies to the ICT4D community itself.

[This post was edited down and republished in the Stanford Social Innovation Review in January 2013 here].

Further reading
m4d: The fun is over. Time to get tough?

In search of an ICT4D mantra

In many sectors of international development it’s hard to imagine how you’d have much impact if you weren’t out in the field. After all, teachers want to be in-class. Doctors want to be in-clinic. And conservationists want to be in-situ. There’s only so much any of them can do when they’re not. Getting ‘stuck in’ is largely what it’s all about.

So why are so many ICT4D professionals happy to work remotely? And why does much of the ICT4D sector not find that odd?

In an article due to be published this week on BBC Future, I write about how technology has ‘democratised development’ and that there are “likely more people working on solving social and environmental problems in the world today than ever before in human history”. The spread of mobile technology and the Internet has made all of this possible. These are exciting times, make no mistake.

But  just because these tech-based opportunities have literally come to us in the comfort of our own homes, we mustn’t kid ourselves into believing that we don’t need to make any effort to lay the groundwork to our apps and ideas by getting out and spending time in the field. Just because the very technologies we use, by their very nature, allow us to work at-a-distance – remotely – that doesn’t mean we have to. If that doctor, or teacher, or conservationist could do their work without stepping into that Malawian clinic, or Lusaka classroom or Namibian national park, would they? I doubt it.

Last night I caught sight of a tweet from Tony Roberts. Although it sounds like something an anthropologist (or philosopher) might say, it perfectly describes an approach the ICT4D sector might like to adopt.

The beauty of the Internet, and the spread of mobile technology, is that anyone anywhere can quickly develop and distribute a mobile-based solution to a social or environmental problem, and start picking up users immediately. The technology is in place, and the distribution channel is there. All that’s needed are good, solid ideas and a drive and passion to fix a problem somewhere – and, let’s face it, there are plenty of those. All-in-all, the barriers to entry are lower than they’ve ever been.

But they’re so low we end up with a different problem.

For the doctor, teacher or conservationist, understanding the context of their patient, student or endangered species is critical for the work they do if they’re to do it well. With few exceptions, they can only get that by spending time in the field. This isn’t perceived to be the case for a programmer or coder. The result? A majority of apps written in isolation which have little chance of success.

Maybe that doesn’t matter. With the barriers to entry so low the cost of building and distributing these apps is minimal. The fact that so many people are taking an interest in fixing things should be encouraging enough. But there’s no doubt that spending time with your users, understanding their context, discussing what they need and then building a tool based on all of those things gives you the greatest chance of success.

Further reading
Social mobile: Myths and misconceptions
Mobile applications development: Observations
Rethinking Schumacher.