Stories



The Elixir of Life for Open Source Projects

This post will try to be as brutally honest1

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:
  1. 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.
  2. 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.

Hand over the high cost, lower complexity work

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

A relentless focus on good management.

This is (in our opinion) the missing secret. Management isn’t just “acting on data insights” – it’s a combination of motivation, setting a clear understanding of the tasks, holding people accountable, and reflecting on the system performance to adjust future actions. It’s more about people than data. We need to work out how to train a cohort of managers who can ensure that all the good work done in training health workers isn’t wasted.

We’ll be working hard to include management courses too at https://learn.msupply.foundation – watch this space.

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 donated 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.