I feel duty-bound to direct you towards two exciting articles which are also quite brief, so they won’t take up too much of your day. I realise that you’re busy.

First up, it’s Sahana getting a mention in the Wall Street Journal, in an article with the snappy title of (sigh) Managing Disaster. Actually it’s just a puff piece written by the Business Roundtable, but it’s nice to see IBM and Sahana getting mentioned for the Chengdu earthquake deployment.

Second, it’s another insightful article by me for ICT Update magazine, entitled Communicating Peace. In it, you’ll find words of wisdom like ” What is important is not the technology itself, but how people use it.” It will only take 5 minutes of your time to read it - but a lifetime of enlightenment will follow.

• MapAction and BrightEarth both feature in an article in the Independent entitled “Mapping the disaster zones” - how they think up the intensely creative titles for these articles, I just don’t know. Interesting enough, but these articles always leave me with a sense that the writer just doesn’t get it - apparently “Within 48 hours: The latest field information is combined with accurate 1:5,000,000 “base maps” to form the first complete maps of disaster-zone data”, which is news to me.

• At the bottom of the press release Intel, Grameen Announce Joint Business Venture to Fuel Social and Economic Development Opportunities Empowered by Technology, we learn that Intel have teamed up with NetHope to develop new solutions for the field, the first (and possibly last) of which is the Aid Station, a “rugged, purpose-built, low-cost technology platform suitable for use in harsh, remote locations”.

• Jon Thompson sends me links to two initiatives which mainly force me to ask the question “Why?” NGO Post and Commkit are both well-intended, but both seem to be hell-bent on reinventing the wheel. If Digg works, why not just create an NGO channel on it rather than build an entirely new NGO version of it? If you need “a humanitarian communications platform that is autonomous (works with very little infrastructure) and accessible (anyone can use it)”, then why not use the internet with Sahana running on it? OTOH, it’s standard NGO practice to reinvent the wheel, so maybe I shouldn’t be surprised - however if anybody can shed any light on either of these, I’ll be more than happy to revise my opinion.

• Development Gateway have launched two new dgCommunities - one for Disasters Prevention and Response and one for Stabilization & Reconstruction, both with the Center for Strategic and International Studies. This partnership seems to have emerged out of CSIS giving up on the idea of launching their own community, the Hub, which explains the inclusion of S&R (terminology which the US military loves and the humanitarian community does not). I’ve nothing against community sites, but I’m waiting to see one in this sector which works as a community (particularly following my own experience with AidWorkers Network).

• The OLPC XO2 is announced. Quoth OLPC news:

On top of that it seems as though a new UN Millennium Development Goal is in the works. The press-release quotes Nirj Deva, Member of the European Parliament, as saying: “One Laptop per Child and the XO laptop are crucial to the fulfillment of the proposed UN Ninth Millennium Goal: to ensure that every child between the ages of 6 and 12 has immediate access to a personal laptop computer by 2015.”

Somebody shoot me. Or better still, send me more news for this section.

Stuff I should have blogged at the time:

• What if? - New York emergency housing competition results: Last September, New York City launched “What if? “, an open competition to find innovative designs for high-density emergency provisional housing for 38,000 households in the aftermath of a hurricane and flood disaster in afictional, one square mile neighbourhood of the city called Prospect Shore. Ten winning entries would get US$10k to develop their ideas further. The competition issued some useful materials about NYC’s vulnerability to hurricanes, and created a really rich scenario for designers to get stuck into. All submissions are now online, and it’s a headfunk of gorgeous design and ingenuity. The ten winning entries were announced in January, and can be viewed here . My own favourite is the gloriously mental S.C.A.F.F.O.L.D. , designed by Jay Lim.
• Intravenous Facebook : Takes all Types is a US charity which has developed a Facebook app for supporting blood donation drives. The idea is to give Facebook your blood type and zip/postcode, and Takes all Types will email you when a local blood bank needs you. What tweaks humanitarian.info’s curiousity is their claim that the app will be “a powerful way to save lives in a blood emergency”. I think that’s overcooking its potential to improve on existing systems in a meaningful way, particularly given the enduringly complicated motives of blood donors. Thanks to sociologist Richard Titmuss, it’s conventional wisdom that paying money to blood donors decreases both the quality and quantity of blood in a bank. This isn’t set in stone though. For example, blood donation schemes in parts of the Former Soviet Union have never been run on a voluntary basis, and renumeration remains necessary to sustain bloodbanks; there is also some research suggesting that non-direct rewards for donors, such as tax credits, may encourage more blood donation. I wonder if the indirect rewards gained through online networking sites can provide sufficiently compelling motives for people to do more than simply sign-up; it seems to lack a “ladder of engagement”, and asks too much of people too early.
• Church and solid state : 400,000 mosques in Malaysia are to get high speed broadband, delivered over the power lines. This “Smart Mosque” project is being delivered by Velchip Sdn Bhd, will cost US$14 billion and aims to provide affordable Internet access to 60 million people. Breathtakingly large aggregate numbers, for sure, and I leave it to better minds to look at the possible effects this may have. Out of interest, in England Anglican churches outnumber broadband exchanges by a factor of 2.88 (16,157/5,600): perhaps the Church of England should be cutting a deal with British Telecom.

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

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.

The O’Reilly Emerging Technology conference is another one of these confabs that I watch from a distance, filled with a mixture of awe and dread. (Awe at the sheer brainpower that you can see in the many presentations, and dread at what might happen next.) This year, Jesse Robbins and Mikel Maron gave a presentation on DisasterTech to the poor and huddled masses that attended, updating some of their earlier thoughts on areas such as SMS, open source and distributed approaches.

Now I like Jesse and Mikel, and I agree with the lines along which they’re thinking, but when I see slides that say “225,000 deaths preventable with existing technology”, I start to worry about whether the expectations of those poor and huddled masses from the technology world are being raised just a little too high… but I’d rather wait until I can hear the audio rather than just read the slides.

One point they did make that’s worth picking up (because as far as I know, this is the first time it’s been explicit) is that disaster technology tends to follow this pattern:

1. Disaster
2. Ad Hoc Adaptation
3. Championship
4. Iterative Improvement

That’s pretty accurate - most of the more interesting developments of the last few years have followed that model. However there are definitely problems with Championship - not as a concept, but in terms of where to target your “championing” efforts.

I believe that most technology dissemination in this sector isn’t through organisational adoption - there’s just too much autonomy at the local level - but through word-of-mouth. Somebody sees something working, tries it out and takes it forward (or not) - but only within their particular part of their organisation. What this might mean is that we need to take a viral approach to this, rather than seeking to get management (i.e. top-down) approval, particularly if we want to reach smaller groups on the ground.

With that in mind, we have to be anthropologists as well as technologists. Cultures are different, communities are different and people are different; what “works” in terms of viral dissemination in the US is simply not going to work in Bangladesh. It’s not just the technology that has to adapt to these different environments; it’s us as well. Hopefully the start-up jockeys at the conference realise that…

Ed Granger-Happ is taking a sabbatical from his job as CIO of Save the Children US, and spending the next few months as an executive fellow and the CIO-in-Residence at the Center for Digital Strategies at the Tuck School of Business at Dartmouth. This is great news for Ed, and for the Center as well, since Ed has a track record of innovation that will hopefully encourage some of the Tuck staff and students to get more engaged in our sector. Even better, he’s started blogging as he begins the residency (I have no idea who managed to persuade him to commit to that…) and I hope that he’ll keep posting on a regular basis at his Dartmouth Fellowship blog.

Cisco have done a lot of good in our sector through their support to NetHope and similar initiatives, no doubt about that. However the promo video on their Telepresence site manages to showcase the least useful way we could possibly use their technology, as well as putting the stereotypical “young white middle class aid worker” in the centre of the frame - instead of the people that we’re supposed to be helping.

UPDATE: Okay, so I got hit by the grumpy stick this morning.  On the other hand, the first draft of this post was far more vitriolic…

UPDATE 2: Also, did you catch the obscure Western reference?  This blog is in danger of becoming too much like my personal blog…

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