humanitarian.info

Tales from the Hood lays out the harsh reality of aid work - lots of manual data entry. How does that stack up against Robert K’s Talking Papers?

About two thirds of the form was numerical, and so entering that data got to be pretty mechanical after the first hour or two. But that last third was all qualitative stuff: open-ended interview questions where at times the respondents appeared to have rambled or gone on wild tangents.

The first two thirds could be covered more easily by automation (although you’d still need somebody to feed the machine and to check the OCR) but that last third – the qualitative stuff is never going to fit into the machine comfortably.

But let’s forget the information management and keep in mind the “description of chronic, always-in-the-back-of-your-mind hunger by someone who’d lost everything” that the Hoodie passes on to us from a scrap of paper in Port-au-Prince:

The hunger is… a hole beneath our hearts.

Now that I think about it, that’s the reality of aid work – that and these lessons from Catherine at AIDG. Sometimes it helps to have non-aid workers tell the rest of the world what it’s really like…

Professor Jeff Sonstein has contributed to discussions about Sahana in the past, and I’ve found those contributions to be very useful. His approach is very much from the user side rather than the developer side, which to be perfectly honest has been a big gap in the Sahana community. He sent around a message on the sahana-user mailing list, with a link to this page of feedback on the Sahana UI.

One of the classes I am again teaching this term here at RIT is called Website Design & Implementation… Sahana was conceived during a real emergency to meet real needs. Over time, the great work done by the initial and follow-up development teams has fleshed out the system to add needed functionality. This is a great start, but one major area needing work now that Sahana has grown so is that of the “user experience”. I wanted to comment on four (4) areas which came up in today’s in-class discussion of Sahana, all of which pertain to the “user experience” encountering Sahana.

All of these comments are worth considering – very specific to Sahana, but rooted in good practice in usability. We could use more feedback like this which can help developers to move towards a more usable version of Sahana – so if anybody out there has anything like that, then please feel free to join the community at sahana-user. It’s difficult to engage non-technical people in the Sahana effort, but this kind of feedback can be a useful contribution from anybody.

UPDATE: another good example of non-technical contributions to Sahana is the translation process, which has a home at Sahana Online Translation, thanks to the astonishing commitment of Dominic Konig – thanks Dominic!

(This post is cross-posted at TalkSahana.)

As some light relief from the news from Burma and China, it looks as if the One Laptop Per Child project is falling apart under the weight of – well, mainly under the weight of Nicholas Negroponte. Ivan Krstic explains in a fascinating essay on his reasons for leaving his position as security director of OLPC:

In fact, I quit when Nicholas told me — and not just me — that learning was never part of the mission. The mission was, in his mind, always getting as many laptops as possible out there; to say anything about learning would be presumptuous, and so he doesn’t want OLPC to have a software team, a hardware team, or a deployment team going forward.

Yes, that’s right – welcome back to Magic Future Kingdom, where technology will solve everything! One thing that’s interesting is that Krstic (and I think many of the OLPC team) didn’t share this view – for them, the public mission of improving education in developing countries was what fired their hard drives up. However I’m not sure that this focus on education is any different in terms of misplaced idealism – even Krstic admits that

As far as I know, there is no real study anywhere that demonstrates constructionism works at scale. There is no documented moderate-scale constructionist learning pilot that has been convincingly successful; when Nicholas points to “decades of work by Seymour Papert, Alan Kay, and Jean Piaget”, he’s talking about theory.

I’ve never said exactly what I thought about OLPC on this blog, for three reasons. First, my opinion is irrelevant. Second, my opinion is frequently wrong. Third, everybody deserves a chance to test their idea against reality and see if it breaks. However as far as I was concerned, OLPC was broken as soon as it ran into the reality of logistics – actually distributing these laptops to their intended recipients – but nobody seemed to want to talk about this aspect of the project, as if it would somehow corrupt the purity of the vision.

Peru’s first deployment module consisted of 40 thousand laptops, to be deployed in about 570 schools across jungles, mountains, plains, and with total variance in electrical availability and uniformly no existing network infrastructure. A number of the target schools are in places requiring multiple modes of transportation to reach, and that are so remote that they’re not even serviced by the postal service. Laptop delivery was going to be performed by untrusted vendors who are in a position to steal the machines en masse. There is no easy way to collect manifests of what actually got delivered, where, and to whom… Other than the incredible Carla Gomez-Monroy who worked on setting up the pilots, there was no one hired to work on deployment while I was at OLPC, with Uruguay’s and Peru’s combined 360,000 laptop rollout in progress. [my emphasis]

What I don’t understand is that I could have told them about all these problems. Anybody with any experience working in the development sector could have told them about all these problems. Hell, anybody who’s ever been outside of the G8 countries could have probably have told them about all these problems, which raises the tricky question of – why didn’t anybody tell them? There are two possibilities. The first is that the people they asked only told them what they wanted to hear – this seems very likely, especially if they were mainly listening to governments, who don’t like to admit that they haven’t in fact been able to extend basic services to rural areas. The second is that they didn’t bother to ask anybody, which in light of Krstic’s essay seems to be equally likely – he quotes from a memo that he sent in December 2007:

We still have not a single employee focusing on deployment, helping to plan it, working with our target countries to learn what works and what doesn’t. Evidently our “deployment plan” is to send whichever hotshot superhacker we have available to each country such that he may fix any problems that arise on the spot. If that is not in fact our plan, then we have no plan at all.

To his credit, Krstic recognises that the

the last key problem, transforming laptops into learning is a non-trivial leap of logic, and one that remains inadequately explained.

What I don’t quite understand is who he thinks is going to do that explaining. It seems clear – not just from this essay, but from general observation of the way in which OLPC has been built up and the claims that it’s made – that this project was not in fact designed to meet the educational needs of poor children around the world. Instead it was about proving a series of ideological points – about private versus public sector, about Open Source software, about constructivist learning – and the impact that it’s had on the technology sector (and it has had a not insignificant impact) has been incidental to proving those points. Now, slowly but surely, each of those points has been tested against reality – and broken. At least now we know what doesn’t work – but we knew that before.

One Laptop Per Child has been a textbook example both of the worst kind of development (broadly, rich white people believe that they know what’s best for poor black people) and the most egregious kind of technotopianism (broadly, complex social problems can be solved if only we have the right technology). These two strands of thought were summed up in a comment by Guido van Rossum:

I’ve thought for a while that sending laptops to developing countries is simply the 21st century equivalent of sending bibles to the colonies.

Amen.

Nigel Woof at MapAction has just circulated a briefing paper entitled Google Earth and its potential in the humanitarian sector [pdf], which outlines most of the key issues around the use of GE (and other geospatial visualisation tools). I was particularly pleased that Nigel recognises the way in which GE is a disruptive technology, something which I discussed a couple of years ago in Here comes the Geographic Information Revolution (in fact I made a bet on it, but needless to say nobody noticed).

There were a couple of points which I thought were worth picking up on. Nigel notes that it is difficult to work with polygon attributes in GE, despite the fact that these are frequently the most useful basic patterning tool. This is absolutely right, and until Google addresses this issue, it’s going to be the single largest obstacle to its effective use for operations. I ran straight into the problem in Bangladesh – built the polygons for administrative boundaries from a shapefile, but adding the attributes that I wanted to was just more effort than it was worth, so I stuck with the Scrappy Maps.

Pull quote:

When producing anything other than a very simple map, Google comes nowhere near GIS for sheer efficiency and flexibility of cartography. But the huge advantage of using Google Earth is that non-experts can use it in an intuitive way to visualise relatively simple data, without having to worry about georeferencing or editing complex geometry.

Absolutely, and we should all welcome the massive benefits that GE brings with this simplicity. However I am also fairly certain that these benefits do have a cost – and that cost is properly managed geospatial data. Anybody who’s worked with spatial data knows how much work goes into maintaining it, but GE creates a disincentive to manage data in a systematic manner.

While this is fine in the short term, it doesn’t bode well for the creation of spatial data infrastructure that can be put at the service of a wider range of users. This is an ongoing discussion that won’t be resolved soon – discussions of the type that OpenStreetMap are having right now. A completely distributed approach to geospatial data won’t work, but neither will a wholly centralised approach; we need to navigate somewhere inbetween.

There seem at present to be two distinct groups of humanitarian practitioners: those who are already, albeit tentatively, exploiting Google Earth and related geospatial methods in their work, and those who will be, as soon as they see their first demonstration of its potential.

I am a little less optimistic – I think there’s a third group that will reject all attempts to introduce GE as a tool into their work, based on the experience of trying to get people to participate in GIS development at even the most basic level. There are a large number of people who want maps but have no interest in the process itself. We can’t assume that everybody will jump on the GE bandwagon, beyond the initial “wow, that’s cool” moment when they first see it.

So where are we, and where do we go from here? Nigel’s paper is not very specific, beyond recommending that we invest in GE as a tool as the basis for more user-oriented mapping activities. He’s absolutely right of course, but saying that GE has little to no cost is not true – there are plenty of hidden costs such as the one described above. We should welcome the potential that GE has for turning everybody into a mapmaker – but we should remember that different people’s maps don’t always agree with each other.

[UPDATE: Christiaan Adams has posted Nigel's paper at the Google.org blog, which is great - more visibility for this sort of analysis in the wider world!]

Okay, everybody try not to laugh when you read the quote from this Network World article:

Big Blue this week said its researchers had created specialized algorithms to help model and manage natural disasters such as wildfires, floods and diseases…. The model allows all unforeseen challenges to be solved, mostly within an hour, and has very good scalability that promises to gracefully manage even larger models in the future.

It’s good to know that in Magic Future Kingdom we’ll be able to solve all unforeseen challenges within an hour. That’ll make our lives a lot easier.

Well, not yet, but they will [pdf]. Janet Ginsburg explains the development of the idea of the Humanitarian Technology Review, while Bruno Giussani covers the recent TED breakfast, where Eric Rasmussen gave an update on InSTEDD.

Initially the idea of a Humanitarian Technology Review sounds like a good idea – if it’s done right. The first two questions – remember the first two questions, everybody! – are: who is the target audience, and what do you want them to do with the information you’re providing? The briefing paper I linked to above says

The Review’s readers, like the Review itself, span many niches: medical researchers, software developers, policy-makers, funders, doctors, veterinarians, communities trying to prepare for or reeling from disasters – even other media.

The one group that is noticeable by its absence is – well, me. People like me, anyway, who seem to fall under the catch-all term “practitioner”. I see doctors and veterinarians in there, but which doctors and veterinarians, exactly? I think it’s likely that I’ve misunderstood – the briefing is explicit that this is about building connections between disciplines, and it’s clearly aiming at a wider audience than the humanitarian community.

If we look at the disciplines that they’re talking about, it’s a wide selection, so it’s probably easier for me to focus on the technology examples given in the review:

• lightweight fabric + satellite technology = a cheaper portable satellite dish
• software + cell phones = real-time surveillance for bird flu
• GIS + interactive mapping = real time tracking of fires and floods
• solar panels + refrigerator = reliable field transport for vaccines
• filter + straw = a mobile water purification device
• open source water tech + microfinance = funding for small water projects
• genetic sampling + fast data analysis = identifying a pathogen in hours

I’m going to think about those examples over the next few days, but I’m struggling to see how a publication can cover all of these and still appeal to a coherent audience. That’s why communities of practice exist around epidemiology, water and sanitation, and the like – because they’re focused enough to hold peoples’ attention.

The success or failure of the HTR will be in the delivery, and on that front I’m very positive about their proposal to combine different delivery streams. At the very least, InSTEDD’s deep pockets will enable them to experiment and see what works, although I’d warn them not to expect collaboration to magically appear – two years on ECB teaches you that for nothing.

(NOTE: Full disclosure – I thought about a similar idea a few years ago, but gave it up because I didn’t think it was viable. Two attempts have been made to develop this sort of thing previously – ReliefWeb’s HIN and CMI’s PeaceIT [pdf] – but the InSTEDD concept is much wider.)

No sooner had I written yesterday’s post about digital security than the New York Times has a piece by Nicholas Kristol on how the Save Darfur campaign website has been under attack recently – from Chinese IP addresses.

As the coalition’s China advocacy campaign has intensified, officials have noticed increasingly sophisticated and subversive attempts to intercept emails and infect computers with malicious programs.

Kristol relies mainly on innuendo to suggest that the Chinese government might be behind the attacks, with very little evidence to support the accusation. From a technology point of view, though, it’s irrelevant who’s responsible – this is a cautionary tale for NGOs and other organisations. We can enjoy the benefits that technology brings – but we also need to guard against the dangers. The price of liberty, and all that…

Public transport doesn’t often provide pointers for the humanitarian community. The recent cracking of the London OysterCard (following hot on the heels of the earlier crack of the Dutch transit card system) came as no surprise to digital security experts, but it should teach us fundamental lessons about information security and personal privacy issues.

Security researchers say they’ve found a way to crack the encryption used to protect a widely-used smartcard in a matter of minutes, making it possible for them to quickly and cheaply clone the cards that are used to secure office buildings and automate the collection of mass transportation fares.

No electronic identification scheme is secure. It doesn’t matter how good your technology is, any system which is built by humans can be cracked, and the only defense is to make the cost of cracking it as prohibitive as possible. (The kicker is that you never know if you’ve successfully achieved that – until somebody cracks it and it becomes embarrassingly obvious that you haven’t.) On top of that, the more complex and expensive a system is, the more difficult it is to fix it when something like this happens.

In themselves, these obstacles aren’t insurmountable – largely because they’re technical in nature – but you see the real issues when you look at how these schemes are implemented. Governmental (and intergovernmental) organisations are notorious for a) thinking that technology can fix problems which are not technical in nature (for example, running a public transport system) and b) frequently mismanaging technology projects, often with the assistance of the vendor.

In a public transport system, this is not a life-and-death issue. What if this was a tracking system for food aid, though, where RFID has begun to be introduced as the solution to our logistics inefficiencies? Or a refugee registration database in a country where human rights abuses are endemic? Or an employee identity card scheme in a country where terrorists are targeting UN and NGO offices? You start to see where this might be going…

There was also related news that MI5 have requested “full automated access” to the OysterCard database. In a liberal democracy where the rule of law holds, that might not be too worrying – but there are a number of countries in the world that don’t fit that description, and where giving access to this sort of information to the government might not be in the best interests of the beneficiaries.

The fear of cyber-warfare has climbed Whitehall’s agenda since last year’s attack on the Baltic nation of Estonia, in which Russian hackers swamped state servers with millions of electronic messages until they collapsed. The Estonian defence and foreign ministries and major banks were paralysed, while even its emergency services call system was temporarily knocked out: the attack was seen as a warning that battles once fought by invading armies or aerial bombardment could soon be replaced by virtual, but equally deadly, wars in cyberspace.

It’s only a matter of time before humanitarian organisations come under similar attack – and we’re not prepared for it in the least. None of this means that this technology shouldn’t be used – it absolutely should be. What it means is that we need to be a lot more savvy not just about the technology issues but about the entire range of processes – procurement of the system, implementation within the organisation, sensitivity to the situation (including security concerns), and so forth – in order to make sure that we’re prepared to address these situations when they arise.

Tom asked me to elaborate on a point about NGO technology choices and (despite the fact that he’s failed to deliver the blog posts he promised, ahem) I think it’s worth putting something out there. I haven’t seen anything written about the issue of NGO technology markets anywhere else, but it seems to be a key issue given the recent development of some key applications and platforms. Basically the problem is this: the humanitarian community (but particularly NGOs) seems to make quite poor choices in terms of software. We then have to live with legacy software and all sorts of compatibility issues, while we lag behind developments such as Web2.0 and tend to deploy the sort of technology that only increases the gap between ourselves and our beneficiaries.

To some extent this pitiful state of affairs is the result of four linked factors. First, we’re public organisations, and although we’re perennially strapped for cash our decision-making is (ironically) not lead by concerns of efficiency. Second, it’s only recently that some of the larger NGOs have put in place good IT governance and management – based on a strategic vision of how technology supports their work – so that most NGOs still make decisions about technology without adequate decision-making processes. Third, we are (in general) not particularly well-informed about technology, and slow to adopt new technology which might lead to serious improvements in efficiency and effectiveness. Fourth, and as a result of the above three factors, we have not historically formed a coherent market that would lead private companies to develop software that targets our needs.

What this means in practice is that we get really excited any time that anybody proposes a new software that appears to meet our needs. The key word is “appears” – it seems to me that much of our excitement is based on the look of the software (ooh, maps!) rather than a sober assessment of the capacities and costs of the software. As a result, we’ve seen a lot of genuine attempts to develop software founder, particularly when the specific needs of the end user aren’t taken into account until very late in the development game. So what’s the solution? There seem to be two possible paths to take:

1. The “Follow the Leader” model, where a single key actor or consortium leads the development process of a single well-targeted application for end users.
2. The “Let a Hundred Flowers Bloom” model, where a range of organisations develop a range of alternatives, and others choose which one suits them.

Now personally, I think option 2 is better, on the basis that diversity is better than a single solution, no matter how perfect that solution is (I’m definitely willing to be challenged on that one, though). The problem is that option 2 hasn’t worked very well – there just isn’t a big enough market (apparently), it’s difficult to mobilise support to those projects and the cost of failure is ridiculous (in some cases, literally life or death). In addition, our sector doesn’t pay close enough attention to technology developments that we actually track software that might be useful for them – so even if something is developed, getting it in front of people is hugely difficult.

That leaves us with option 1. Clearly this has potential, particularly when there are budget constraints (and when aren’t there?) – by allowing organisations with more funding to take a lead (preferably together), development costs are borne by those who can afford it the most, and by working together we can leverage economies of scale. The problem is that this doesn’t work very well either: the needs of the larger organisations are not often identical the needs of smaller organisations (they’re at different stages of development), there’s no guarantees that a) the developers will release it to other end users (or at least not without trying for costs recovery) or that b) the end users will accept it without at least some customisation – for which there’s no cash available.

Having said that, option 1 has been the favoured one so far, and will probably continue to be so. Part of the inclination of Sahana – and more so with the humanitarian-ICT community – was to encourage people to explore option 2. So far, progress on that front has been slow indeed, but perhaps that’s because we’re only really starting to develop a mature market for software.

(Note: Slightly related is a fantastic blog post at Humanized last year, Ten Ways to Make More Humane Open Source Software, where Jono DiCarlo lays out the ways in which he thinks we can get to better (read: more useable) Open Source solutions. A number of the things he discusses are germane to this discussion in terms of managing the development process itself – but none of them address the problem that I outline above.)

Word reaches my inbox from the Fritz Institute, who have been field-testing the Helios software program for the last two years with a few NGOs, particularly in east Africa. For those of you keeping track, Helios is the second generation of Fritz’ Humanitarian Logistics Software which was developed and implemented with IFRC.  By all accounts, the IFRC implementation was a tricky devil, and Fritz learnt a lot of hard lessons in that process. Those lessons have been put to good use, and everything I’ve heard about Helios so far has been positive.

The real question, of course, is how many NGOs will take them up on the offer – Fritz will provide a Helios license free of charge, while implementation costs will be borne by each organisation. Now this works for the big-hitter organisations such as World Vision International and Oxfam GB – who by sheer coincidence are the first two NGOs to take up the Fritz platform – but it’s a lot more difficult for smaller organisations who can’t necessarily afford those costs (particularly where they lack dedicated logistics staff).

It doesn’t matter how good your software is on its own terms – there are a lot of other factors that determine why an organisation does or doesn’t pick it up. One of the things that I think will be critical is for Fritz to encourage the development of a Helios community, where NGOs can share experiences and possibly even costs, as well as enabling better co-ordination in the field. Watch the Humanitarian Emergency and Logistics Professionals to see what sort of discussion starts to happen around Helios, if logistics is your thing.