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