ICTworks

I am Karl Brown, Associate Director of applied technology at the Rockefeller Foundation, and at the recent Mobiles! convening, I gave a brief talk where I highlighted 10 theses on international development, software development, and the role of donors therein.

In the tradition of Martin Luther, these 10 theses were pinned to Wayan Vota’s chest, with an undercurrent of challenge to spark thoughtful debate on our too common pilotitis practices.

While the theses below may seem categorical, there are of course exceptions, and I regard them more as general philosophical approaches as opposed to hard and fast rules. They are based on our collective experiences in using eHealth and mHealth, and are applicable to the entire ICT4D ecosystem

10 Theses on Power and Efficacy of ICT4D Indulgences

1) When thinking of scale, national scale is not good enough – we need to think bigger.

Organizations which successfully scale technologies rarely focus on a single country. Why?

1. You get a diversity of financing/customer base across countries
2. You get a diversity of experience – “One is one, and two is many”
3. All that said, you still need a mechanism to learn across country deployments. Open source is a very useful modality for this.

For example, the Rockefeller Foundation worked with PATH and the Public Health Informatics Institute to develop requirements for logistics management information systems based on a study of four countries. These requirements were used in several other countries in the design of their LMIS systems. Based on these requirements, we have, in partnership with Village Reach, JSI, USAID, the Bill and Melinda Gates Foundation, and PATH, formed a new open source collaborative called OpenLMIS. This platform is currently being used in Tanzania and Zambia to bring LMIS to national scale, with ~85% overlap found between the global and local requirements, and now a shared common platform and code base between the two countries.

In many domains, countries have more similarities than differences, and such differences that exist can often be parameterized to allow reuse of a common core. In the domain of washing machines, this could be switching out the motor and plug for a different motor and plug that will work with the electrical system in a given country.

In the domain of software, this could involve localization to the local language/script, and customization of behavior based on institutional workflows. In both cases, the core underlying technology remains more or less the same.

This is not to say you shouldn’t try to scale a single country first, nor is it to underplay the challenges of scaling in a large country, especially federations like India or the United States. The point is, that to the extent possible (especially if you have operations or interests outside of one country) consider how the technology might be used in multiple countries from the get-go, and design for that explicitly.

2) Products, not pilots, scale beyond national borders

In general, I would posit that only products have scaled in any significant sense. Any technology that can be reused across multiple countries is a product, or close enough to a product to count. A product approach helps you to reduce, reuse, and recycle.

3) NGOs are not good at developing proprietary software products.

Institutions can rarely succeed outside of their areas of comparative advantage, which is based on the type of organization, the mission, the incentives, the staff, and the networks that organization is part of. There is value in having different organizations with different comparative advantages, but you need to understand those incentives.

NGOs that focus on delivery of services, consulting, technical assistance, and the like are in general not as good as the private sector in developing software. There are notable exceptions, but in general, NGOs are not that good at scaling their own proprietary software products, especially beyond the remit of projects their organization is directly involved with.

Many NGOs simply aren’t set up to deal with the sales, marketing, customer relations, maintenance, and other tasks required in servicing customers on a proprietary platform. In addition, they aren’t likely to license the technology to their competitors, who ultimately have the same goal – improving the lives of their constituents.

The fact that these NGOs may not charge money for the software does not make it any less proprietary. In fact, not charging may make the NGO less likely to invest in improving the product. (Benetech has an interesting hybrid model, whereby they charge a license fee for the compiled code, but the source code remains Open Source. RedHat Linux has a similar model.)

Thus, organization size, current contracts/relationships present a barrier to scale. Probably the biggest exception to this rule are NGOs whose sole focus is on developing technology, but many of them use Open Source vs. proprietary approaches.

If you’re an NGO, and you’re using an in-house technology for constituents as a comparative advantage to win a contract, you’re perhaps contributing to the problem. Your implementation expertise (and any internal systems you use to manage your own processes) should differentiate you, but it is much more in the interest of countries and end constituents to share the platform (see #5 below on TCO). The ehealth moratorium in Uganda is instructive on this matter.

4) Ownership and control is important.

What does it mean to own something? Do you own a refrigerator? Yes. Do you own Microsoft Word? No! You have a license to use it, but you do not own it.

Intellectual property is rarely owned by the end-user, it is usually licensed – and the form of the license matters, because the license says who has the right to make a change, and distribute those changes to others. Because change is inevitable in all software projects, understanding how the licensing regime controls change is crucial in understanding long-term scale and sustainability.

Open source upends the traditional copyright model; thus, instead of having to ask permission to make a change or redistribute the change, an Open Source license explicitly grants you freedom to change the software as you see fit, without having to ask permission of the person who originally wrote it. This massively reduces the friction and promotes sharing and modification of technology across organizational boundaries.

5) The long-term sustainability of a software technology is directly related to the total cost of ownership (TCO).

TCO deals with questions like, how much does it cost to set it up? How much does it cost for each additional seat? How much does it cost to change once it’s running? What sort of expertise is required, and how much must you pay for that expertise? In addition, TCO is also related closely to the number of lines of code you have to maintain by yourself. What is the size of your stack, and how are the costs of innovation amortized across deployments? How many thousands of lines of code are custom just to your implementation, vs. shared across dozens or hundreds of implementations?

For example, I saw a project where a new quasi-electronic medical records system had been written, roughly 30,000 lines of code with a brittle database schema that could only handle women and children and maternal/child health issues – no men, no other conditions. To change that EMRS going forward, they would have to pay the full costs to revise that database schema, and it will still be brittle, and they would have to maintain all of that code going forward.

A smarter solution may have been to pull an Open Source EMRS like <a href=http://openmrs.org>OpenMRS</a> off the shelf and take time to learn how it works, and modify the small bits needed for the programme.

Not Invented Here (NIH) kills sustainability, and NIH is an endemic disease of programmers and organizations the world over. As donors and implementers we need to be aware of it and fight against it.

A different example is Apache HTTP server, an Open Source server that powers 65% of websites on the Internet. Apache has 2.25 million lines of code, but to customize it to your particular website only requires maintaining a few hundred lines of a properties file. So your total cost of ownership of Apache is vastly reduced since maintenance and bug fixes are amortized across millions of deployments.

6) Open Source allows networked collaboration in the absence of formal agreements.

How many of your competitors are using the technology you’ve developed? That’s a very good measure of how reusable your technology is, and how much friction lies between that tech and someone who needs it. FOSS is not a silver bullet, but it’s gunpowder for cross-national, cross-institutional collaboration at the level of code, if the community is managed appropriately.

For example, there are several OpenMRS deployments that have had little contact with the OpenMRS leadership, and operate without contracts, formal MOUs, or licensing agreements with the OpenMRS leadership.

7) NGOs funded with public funds should not be writing proprietary software.

In a recent survey, we found three large development contractors (and many subs), who, over the past 10 years, have written or extended ~40 different applications for supply chain management in the health domain, often funded by USAID. There is significant overlap in the functionality of these tools, but since most are written for a particular deployment, there is little amortization of costs across deployments; and there are very few robust, reusable products that have come out of all of this investment.

Donors are partially responsible for this problem, and are an important part of the solution. Those investing public funds should support Open Source software and let private capital fund proprietary software development. The private sector seems to have done a pretty good job with proprietary software thus far.

8) Beware of pseudo-Open Source.

There are many projects that masquerade as Open Source – they will tell people: “Sure, the code is free, we will give it to the country, no problem.” If you ask for the code, you may get a zip file with some version of the code from a year ago that no longer compiles. This is not the same thing as Open Source.

I would not consider a project to be truly Open Source unless it has at least the following characteristics:

1. A clearly stated license that applies to the source code, ideally chosen from this list
2. A repository, on sourceforce, github, or the like, where the most recent (e.g. tip) of the source code is maintained.
3. A mailing list or other facility for the community to engage with the lead developers

A successful Open Source project will have the above, as well as:

1. A transparent governance system that explains how changes to the trunk are made, and by whom
2. Regular outreach to the community and explicit engagement of other deployments and attempts to bring in innovations from those deployments to the core
3. Someone whose job it is to manage the community
4. Evidence of commits to the codebase made by people outside the organization which started the project

9) If you develop software, use proven software development methodologies.

If you do want to develop software, you should focus on a product approach, and use proven software engineering techniques, like Agile, XTreme programming, etc. You should also use source control, automated unit and system testing, load testing, automated install, continuous integration, and code coverage measures.

Capability Maturity Model Integration is one structured approach to improving software engineering processes. Organizations that want to develop products in the domain of ICT4Dev should consider achieving a level 3 of the CMMI.

If you can’t do this, or don’t know what those things mean, you should partner with someone who can.

Donors are also partially to blame here. When a donor works with a pharmaceutical company to develop a new vaccine, they ensure that the company is following appropriate standards for production of vaccines. We need to have more rigor when we fund software development.

10) We need to stop reinventing the wheel.

Donors should focus on building public parks – in other words, the social good should outweigh the private good. In the domain of software, they should identify large-scale domains where solid, reusable, Open Source products do not exist, and then collaborate to fund expansion of these together.

You may say, why not let the market decide? Unfortunately, in many cases in ICT4D, there is a market failure – there is latent demand for much sophisticated software, but the private sector firms who are in this space are not interested in those markets. Thus, donors and NGOs and governments should collaborate to fill the gap.

I believe Open source is one of the best ways to do so, since it allows the low-friction collaboration and reuse across organizational boundaries without complex licensing agreements. All other things being equal, it would be better to invest in one, or a few, robust platforms that can be reused, rather than investing in thousands of custom deployments, which is what is happening today in many domains.