This post will try to be frank. If we are wrong, please tell us.1
There’s several factors that are pulling open source projects in different directions. Here’s a recap from the previous posts (1st here 2nd here and 3rd here ) along with some other factors.
These factors are:
The current situation demands a focus on Effectiveness.
The “current situation” being the evaporation of a large chunk of development funding from a country that is now looking inwards instead
Countries want to step up and take more responsibility for their own systems.
This is good! Here’s our take: if you have a model of “external experts do it, then experts train locals, then expert hands it over to local teams and goes away” it will fail. Fail fail. This is not a reflection on the local teams. It’s because:- Big complex systems can’t be handed over that easily. There is too little attention given to building management skill, and organisational infrastructure to support such systems.
- Sometimes the so-called experts have actually made a mess. Just last month (we’re writing in July 2025) we visited a country in Africa where they were running 6 vertical supply chains to each health facility. We understand why a disease program (EPI, TB, HIV, etc) might create a vertical supply chain, but to think that that’s an end state that you can hand over to a country with limited resources is nuts. Donor’s fault. Expert’s fault.
There’s a better way: partnership. We’ll get to that below
Open source is here to stay
Yes, there’s a good case for competition, markets and the role that creative destruction plays in getting the best products & services at the best price, but that’s not the world that most countries have chosen. They want (often mandate) open source systems, and we need to figure out how to create robust, effective, durable systems that are open source.
If something’s a public good, it needs ongoing funding.
This is hardly controversial. We discussed it here .
The Solution
Of course there’s no single solution. Here’s our take.
Partnership
Yes, aim to hand over as much as possible to local teams, but at the same time the aim is to work out what’s best for the country.
Typically, partnership will have the country doing what they’re good at (train, deploy, support, manage), and the open source project doing what it’s good at.
Transfer the high cost, lower complexity work to country teams.
This is the training, deployment, level 1 and level 2 support, along with the management of these functions and of everyday users of the system (which always has to be done by local staff).
This work is entirely within the skillset of local teams, and also represents bulk of the costs of running a system.
The mSupply Foundation is developing what we aim to be a comprehensive set of learning materials at https://learn.msupply.foundation – This is all offered as part of our open source program (but consequently, needs ongoing support to develop and maintain).
Accept that complex software development doesn’t make sense to do in-country, and won’t be done by a community of developers working for free.
Firstly, the community of developers.
Let’s use DHIS2 as an example as they have 80 contributors to their project2 but how many of those are from an independent, volunteer community? Either one or zero, depending on how you count. Open source projects that rely on volunteers are either huge and prestigious (think Linux) or dying. The reason is explained in the next point:
It takes a year or more to get up to speed with a large project. That means that if you’re a country wanting to build your own core team, you have to fund a team, offices and management for a year before the team is doing valuable work.
This is not about skill levels. There are lots of highly skilled developers in low income countries. It’s about the cost of spending that much time in training, and having to keep on spending as staff leave the project, because hardly anyone stays in the same job their whole life…
Share the cost of core software development.
When it comes to software development, we can tell you what isn’t best: suggesting that a country develop or maintain their own core software systems. It’s hugely expensive, high risk and low value. Sharing that cost amongst lots of users is by far the best solution. [2]
And how do we share it? The problem of not paying your share is so pervasive in the open source community, it has a name: the maker and taker problem. We think the better answer is (for now at least) for the donor community to take on this small cost, and see it as a saving on the orders-of-magnitude larger cost of donor-funded health commodities.
In the longer run, we need to give countries the tools and management skills to understand why funding core open source projects the country relies on is good management. We can’t expect those decisions to be good until the tools and skills are in place. Do that first.
—-
fn1. If you disagree or there’s errors, please contact us, and we’ll respond (and maybe update the post)
2 As we write we are tendering for a health supply chain system in a country that is in the top 20 in the world for GDP per capita. They don’t want to pay the cost of maintaining a core system, so how on earth can it be cost-effective for a low income country to do so? If a low income country does have software developers that are skilled enough to do that, they should be getting high income jobs – not replicating the work already being done to maintain an open source system.
3 https://github.com/dhis2/dhis2-core/graphs/contributors
We have 40 so far as our project is newer