As fair warning, this post is part rant, part confession, part promotion (see links below!), and part call to action for increased investment in local innovation in low- and middle- income countries.
I spend a good deal of my time raising money, working on budgets, and generally championing open source software designed to be used by health workers in low-income countries. Most of this ‘eHealth’ software ends up being developed by extremely talented and dedicated software developers from the United States and other wealthy countries. I spend a relatively small portion of my time trying support and strengthen local software development capacity.
For example, we’re working with a small, all Tanzanian innovation company called ITIDO. While equally talented and motivated, ITIDO’s staff has less training and, consequently, less expertise than those of the organizations I’m affiliated with. However, it’s hard to shake the feeling that in the long run, Tanzania needs successful ITIDOs more than it needs organizations I’ve helped create. It seems that a well-functioning ITIDO is more likely to build lasting, relevant, solutions that will actually be used in Tanzania.
A key challenge is time. We often feel the need to deliver results in a few months. And, indeed, there is no time to waste in developing and deploying technologies that have the potential to improve desperately needed healthcare. Given limited funds and the need to deliver quickly, the most efficient approach is almost always to go with highly experienced software developers. And this becomes more and more true once you start building software with one group of experts. The people who know the current software best are the ones who can most quickly extend it. Capacity building takes time.
One approach we advocate is establishing a “Coded in Country” (CIC) label for software, akin to a Fair Trade label for projects. There is ongoing discussion about the best definition of CIC, and if there should be an official certification process, but the original idea was that a software application or module is CIC if at least half of the money goes into local development. CIC nodes will provide capacity strengthening and opportunities for international exposure to talented local developers. The idea has generated a good deal of enthusiasm from many groups, especially those deploying eHealth software for use in Sub-Saharan countries in Africa.
CIC and other related topics will be discussed during an online panel hosted by GHDonline on the topic of local development of global eHealth software from July 19-30 (sign up now!)
Of course, these ideas are not new and there are many organizations doing a pretty good job of local capacity development already. And, of course, there are many individuals and businesses from low-income countries that are innovating without any help from abroad.
However, I see a missed opportunity here. The last five years or so have seen a dramatic rise of funding for global health corresponding with a rise in funding for software systems to support healthcare. The ultimate success of these efforts depends on more than the quality of the software. That is often the easiest part of the solution. Success depends on how well this software is integrated into health systems, on how well it can be maintained, how it can be adapted as needs change, and how well feedback from the field is reaches those who can act on it. We should use the resources we have to do more than build software, but to strengthen local capacity and expertise to make these other critical factors more likely to happen.
One might take this as an argument for countries only using software that is locally developed, leading to an absurd scenario in which every country is encouraged to make its own web browsers, word processers, and email clients. This is not what I advocate for, of course.
I think health software is different—at least currently. There is a great deal of innovation, configuration, and integration yet to come. Particularly in the mobile space, the technology landscape is changing so fast that the software we’re using a few years from now may be quite different than what we are working on now. This all points to a need to unleash the creativity that exists in every low-income country on these problems rather than just try to deliver the software we think they will need.
My argument touches on a larger and more complex issue of the role of experts and who should be leading development projects. I’m very proud to be part of a new micro-granting initiative that is based on the idea that people often have the best ideas of how to solve the problems they face. We are experimenting with different models around a simple idea: put resources in the hands of community members to solve their problems. We work with a local facilitator to identify a problem with a clear, quantifiable metric and then help refine ideas from local community members to address it, eventually funding one or more.
Even though we have just started, I’ve found this to be some of the most rewarding and by far the best impact-for-the-money efforts I’ve been part of. One of our primary motivations is the common observation that any solution must be embraced by its users and beneficiaries in order to be successful, and our belief that this is vastly more likely to happen when the ideas come from the community as well.
I don't know where we going from here exactly. However, it sure seems that technology is continually becoming less of the problem, and that innovative energy needs to be focused on the organizational models and ecosystems that deploy the technology to be sustained and improved. The best way to address this is to start leveling the playing field. Groups such as the Open Mobile Consortium have a key role to play, and a responsibility to be an eager partner in this necessary change.
Creative Commons Photo Courtesy Frerieke.
4 Comments
Output versus Impact
You are correct that many of these ideas are not new, but also that greater awareness and action are needed to change the paradigm.
After more than 27 years of ICT4D work, I've seen amazing results from long-term mentoring of local developers by experienced foreign developers willing to pass on their skills, and then step back out of the way. That's doing with, not doing for, and is an effective use of short-term technical assistance. I've experienced many instances where local students surpass their foreign mentors before the end of a project. That's working yourself out of a job, and is success. I've seen government employees, long ignored, blossom when given the tools and opportunities to learn, show what they can do, and then move on to contribute to the economy via the private sector. That's opportunity, and it's good. I've seen local experts undervalued when their skills surpass those of foreign experts. That's unjust, and demoralizing.
Short project cycles, short-term project objectives, and success measured almost entirely in project outputs counter efforts to use local capacity to build locally sustainable software designed to achieve long-term impact. We need to communicate, advocate, and demonstrate that only a longer-term, more sustained approach then engages all stakeholders can address root causes.
CIC
I think this is a great approach indeed. I have come across equally motivated and skilled Malawians in this space. And I have seen them do amazing things in this mobile space. This would really strengthen local contribution to projects and increase success level of projects.
I could hug you,...ohh well i just hugged my PC instead,
I could not have put this blog any better; i have just had an extend rant about this with some friends. i am African, working in Africa, and it does drive me up the wall when 'developers' come do there thing and go away to publish and publicize their good deeds while the community they were working on rather with remain the same in terms of skills level. Finally, I would propose the CIC probably stand for coded in context (community) to ensure that the actual community benefits not some urbanites who have been put into the project...:-) my 2 cents
Time to reconsider how we work is long overdue
I am an NLM research fellow at University of Washington and I have been introduced to the idea of "CHANGE" at the campus. The issues you raise are at the core of what is really capacity building. Most programs, from economic to health care, that are started in poor resource settings are a form of export that lack key important component like "capacity building" which reads sustainability. The idea of software development vis-a-vis poor countries is central to how the issue of sustainability can be tackled.
Whether it is cultural or something else, the notion of quick results seems to have permeated not only our personal lives but also how we conduct philanthropy. Most of the problems experienced by least developed countries (LDCs) are a product of many events that some of which have taken a long time to manifest themselves. For instance, iliteracy, poor governance, and often poor health can all be attributed to colonialism, greed and corruption, etc.
To really solve the myriad of problems evident in LDCs, we in the West need to stop treating the symptoms and address the root causes. The question of software development, as a case in point, is an apt example of how we can simultaneously solve a problem while developing capacity that is critical after our funds run out. Long-term and sustainable solution to this problem is giving "meaningful assistance" to those few organizations or institutions that have basic infrastructure to deliver training curriculum - to local software engineers and students - that has been collaboratively designed by and with locals. The in-country training should not be myopic in the sense that there is this one problem we need to solve so let us train a bunch of people to do just that. What is required is training managers, analysts, and technicians who have the capacity and wherewithal to assess, analyze, and design a project from beginning to end.
Financial or human-resources aid given to LDCs needs to be evaluated using novel performance and outcome measurements in which the concept of "Meaningful use" is both explicit and implicit from design, implementation, to evaluation. I totally agree with you that there is an urgent need to address not only how we work but also determine in very clear terms what is that we want to accomplish
Post new comment