For 15 years, open source has functioned as something close to scripture in ICT4D.
- Principles for Digital Development enshrined it as Principle 6.
- Digital Public Goods Alliance built a global movement around it.
- UNICEF Innovation declared that it would only build open source in 2026
- Donor procurement guidance treats “we’ll open source it” as proof of sustainability.
Anyone who has tried to defend a proprietary tool in a proposal review knows the social cost of confronting Open Source software true believers.
So I paid attention when NetHope published Harnessing AI for Humanitarian Impact – a synthesis of 11 humanitarian AI deployments at IRC, Mercy Corps, ICRC, GiveDirectly, and others. Buried in the cross-cutting analysis is a sentence that quietly takes a hammer to one of our sector’s foundational beliefs.
Here it is, verbatim from the report:
- “Open-source does not eliminate cost, it redistributes it. Licensing fees are replaced by coordination demands: maintaining codebases, documenting tools, onboarding contributors, and governing shared infrastructure. For resource-constrained NGOs, these coordination costs can equal or exceed the price of a commercial license.”
Read that again. Seriously. Its a bold statement that deserves a moment’s reflection.
NetHope, an organization that has spent two decades helping NGOs adopt technology, is telling us that the total cost of ownership math we have been using to justify open source mandates may be wrong for the typical operational humanitarian organization.
Sign Up Now to understand Open Source TOC
Before You Quote This Report
I am going to give you the contrarian argument that this finding deserves. But first, the disclosure that the report itself does not foreground.
The NetHope Center for the Digital Nonprofit, which produced this analysis, lists four partners on the inside cover: Box, Okta, PagerDuty, and Microsoft.
- Box sells proprietary cloud storage.
- Okta sells proprietary identity management.
- PagerDuty sells proprietary incident response.
- Microsoft does not need an introduction.
Every funder of this report has commercial reasons to want NGOs spending less time on open source and more time on commercial licenses.
This does not make the report’s findings wrong.
NetHope is a serious organization, the case studies are well-documented, and the open source critique is one paragraph in a 13-page analysis that also praises fAIr and POMELO for publishing their code on GitHub.
But when a research product funded by proprietary vendors has a finding that proprietary software may be cheaper than open source for NGOs, intellectual honesty requires naming the conflict before citing the conclusion.
Hold both things in mind. The funding source is a real reason for skepticism. The argument may still be correct.
The Argument Is Probably Correct Anyway
When NetHope’s vendor-funded report says coordination costs can equal or exceed commercial licensing, we should listen because they are echoing what four different organizations have already said with their own money on the line.
1. OpenLMIS
The OpenLMIS community came to almost the same conclusion six years ago, and they were funded by USAID and the Gates Foundation, not Microsoft. When OpenLMIS went looking for sustainability, they ended up with three options:
- Charge implementations for ongoing maintenance,
- Expand to private clinics as paying customers,
- Hand core software maintenance to a private partner.
They chose option three and partnered with a commercial firm called Vitalliance in 2021. The “free” open source supply chain tool was kept alive by a private company that needed it integrated into its commercial value chain.
2. DEEP
DEEP, the humanitarian data analysis platform documented in NetHope’s report, did not get that lucky. It shut down in 2024 not because it failed but because its funding cycle ended. Open source did not save it. Nobody was paying the coordination tax.
3. Norwegian Red Cross
Mikael Hailu of the Norwegian Red Cross made the same point in August 2025, warning that most Global South open source tools are “mission-specific, tightly bound to domains like public health, education, or social services” with narrower user bases than the Apache or Linux comparisons we love to invoke.
Foundation-backed open source works for Kubernetes because Google, IBM, and Red Hat assign full-time engineers to it. Nobody is assigning full-time engineers to your mHealth tool in Malawi.
4. Development Gateway
Development Gateway argued bluntly last year that “open source is seen as an inherently sustainable option. This is a misunderstanding of both the value of open source and technology lifecycles.”
They had watched an internationally-applauded system go offline because the government did not budget for server costs. Open source did not prevent that. It may have made it more likely, by allowing everyone in the funding chain to assume someone else was carrying the maintenance load.
What This Means for Software Procurement
Three things should change in how the sector talks about open source in 2026, and none of them require abandoning the principle.
First, stop letting “we will open source it” function as a sustainability plan.
It is not one. A real sustainability plan names who pays for coordination, maintenance, retraining, hosting, security patching, and contributor governance for the next five years, in dollars, with a named funder. If your software development proposal does not have that, the open source clause is decoration.
Second, budget the open source coordination layer explicitly as a line item.
NetHope’s framing of open source as a “cost-reallocation strategy” rather than a cost-reduction strategy is the right mental model. The cost did not vanish. It moved from a vendor invoice to your staff calendar, where it is harder to see and easier to underfund.
Third, stop treating commercial vendors as a moral failure.
Sometimes a managed commercial software services with a service-level agreement, a security team, and a contractual obligation to maintain the product is the cheaper, more sustainable, more accountable choice for a particular humanitarian use case.
The open source maximalist position, that NGOs funded with public money should never use proprietary tools, has produced real casualties: tools that died because nobody was paid to keep them alive, and procurement decisions made on ideology rather than fit.
Open Source Is Great – In Specific Cases
Open source remains essential for digital public infrastructure, for tools that need to outlive any single vendor, for code that should not be held hostage to one company’s pricing decisions.
fAIr and POMELO publishing on GitHub is genuinely good. The community-generated training data fAIr uses to correct Global North bias is exactly the kind of public good the sector should be building.
But for the operational software tools sitting in front of an NGO right now, the question is no longer “open or proprietary.” It is “who is funding the coordination layer, and for how long.” The honest answer to that question will determine whether the tool exists in 2030. The license attached to it will not.
