Ushahidi for Services

I had the rare privilege of being tested for Ebola last week (short story: blood poisoning, near death, asked where my office was, said Kenya, drips, intensive care, recovering fine etc), and have been looking today at designs for upcoming V3 features to help improve service provision (monitoring poverty levels, rural water, electricity etc).  And it struck me in juxtaposing these, that when we talk about poverty and services, we talk so much about their absence and presence that we forget that these are sliding scales; gradations of have and have-not. When we talk about rural emerging-world healthcare, my first image is always that of a nurse doing her rounds on a bicycle.  As in, what it takes to maintain health in a system - checking in on sick children, dressing wounds etc etc.  Ditto with poverty: although every few years another politician proves that they can live for a week (or heroically a month) on their country’s social “handouts”, most of the time poverty work is about the long haul and helping people stay out of it.  This long haul is what a lot of the V3 service provision features (things like uptime tracking, push messaging and the dataviz modules) are about: making it easier for communities and organizations to monitor and measure their steady-state activities.But the real test of all these systems - the nurse on a bicycle, the waterpumps sending SMS updates, the generators for hire - isn’t in monitoring the steady state: it’s in the vulnerabilities that happen when parts of the systems fail, or are pushed to their extremes, and in how to systems that we build to monitor them can help. In my case, a well-resourced hospital saved my life when my own system failed, but that's not always available: with our service provision features, we need to help build maintainable systems whose vulnerabilities can be both visible and addressable before they become failures.