Open Source in Humanitarian Response: Case Studies, a Decision Matrix, and What LLMs Are Changing

Open source in humanitarian response is most valuable when it gives an operation practical control over its data, workflows and long-term ownership without creating an unsupported system. Select it using data sensitivity, lifecycle cost, local capacity, interoperability, field conditions and a realistic exit plan.

Published 2025-09-23 · Updated 2026-09-23 · By Shahzad Asghar

Open source in humanitarian response is most valuable when it gives an operation practical control over its data, workflows and long-term ownership without creating an unsupported system. The right choice depends on data sensitivity, total cost of ownership, local capacity, interoperability, speed and a realistic exit plan.

When a crisis hits, the first hours decide a great deal. Teams need maps that do not yet exist, assessment forms that work offline and a way to share data across agencies using different systems. Some of the most reliable tools behind that work are open source.

I have seen this from several sides: working on data systems during the 2010 Pakistan flood response with OCHA, leading information management for a UNHCR operation in Jordan serving more than one million refugees, and running data and digital services for ESCWA across 22 Arab member States. My professional profile provides the wider context. One lesson repeats everywhere: open source is not automatically the right answer, but when it is, it can change what an operation can do with limited money and time.

This guide explains where open source has worked in humanitarian response, how to decide when to use it, and how large language models are changing the decision.

What open source means in a humanitarian context

Open source software makes its source code available under a licence that gives users the freedom to use, study, modify and share it. In humanitarian work, that definition has practical consequences.

First is ownership. A government ministry or local NGO can continue to operate and adapt an open system after a donor-funded project ends. Second is interoperability. Open standards and documented interfaces make it easier for agencies to exchange data during coordinated response. Third is scrutiny. Public code can be inspected, tested and improved, although visibility alone does not make a deployment secure.

The Digital Public Goods Alliance standard makes the point well: openness is only one requirement. Privacy, security, documentation, clear ownership, portability and appropriate data handling also matter. A digital public good is not merely a public code repository.

Open source case studies in humanitarian response

OpenStreetMap and the Humanitarian OpenStreetMap Team

After the 2010 Haiti earthquake, the OpenStreetMap community began tracing roads within hours. Once post-earthquake imagery was released, volunteers expanded the map quickly; HOT records that more than 600 people contributed information in the first month and that it became a working basemap for responding organizations, including UN and World Bank teams. HOT's Haiti activation record is still one of the clearest examples of an open data community filling an urgent information gap.

Lesson: open data and open tools can let a distributed community contribute when official geographic data is incomplete or unavailable.

KoboToolbox and ODK-compatible data collection

KoboToolbox is widely used by humanitarian and social-impact organizations for mobile data collection. It was designed for offline use and inexpensive devices, and it supports XLSForm and ODK XForms for portability between compatible platforms.

At ESCWA, one practical change I introduced was an intake step that asked whether a request genuinely required a custom build. Many one-off field-data requests were better served by a mature tool such as Kobo, paired with training and sensible form governance, rather than consuming scarce developer time.

Lesson: the best open source decision is often to adopt a mature product, not to start a new build.

DHIS2 and national health information

DHIS2 is used by health authorities in more than 80 countries. Its value in emergencies is not only the application itself. When humanitarian health actors align with an existing national information system, emergency reporting can be designed to transition into national ownership rather than ending with a parallel database.

Earlier in my career, on the CIDA-funded HIV/AIDS Surveillance Project in Pakistan and later on a hospital information system with Caritas Switzerland, I saw how much value comes from systems that national teams can own, adapt and sustain.

Lesson: open source can support the handover from emergency response to national ownership, but only when governance and capacity transfer are designed from the beginning.

Primero for child protection and GBV case management

Primero is an open-source platform for protection-related information management. It supports child protection and gender-based violence case management, incident monitoring, and family tracing and reunification. Its documentation and service model are a useful reminder that the most sensitive data requires more than a good licence: role-based access, secure configuration, hosting, auditability and appropriate operational practice are essential.

Lesson: open source can support high-sensitivity services, but security depends on how the system is implemented and governed.

RapidPro, U-Report and two-way communication

RapidPro supports SMS and messaging workflows without requiring every programme team to build its own communications system. Two-way communication matters in accountability to affected people work. In projects such as DigitalAAP at UNHCR, listening channels were as important as dashboards: communities need a practical route to ask, report and receive information.

Lesson: open tools can reduce the cost of maintaining accessible communication channels at scale, but content ownership, consent and escalation paths still need named operators.

HDX, shared data and humanitarian standards

OCHA's Humanitarian Data Exchange gives responders a shared place to find and use humanitarian datasets. Its relationship with the Humanitarian Exchange Language illustrates a broader point: open platforms are more valuable when agencies also agree on common ways to describe and exchange information.

Lesson: an open platform without shared standards still leaves each organization translating the same data repeatedly.

The real costs: where open source fails

Open source is free to download. It is not free to run.

Humanitarian projects usually fail for operational reasons, not because the licence was wrong:

• No maintenance plan: a pilot is built, the consultant leaves and no one owns patches, backups or upgrades.
• Unsafe self-hosting: a server holding sensitive data is deployed without hardening, monitoring, security updates or recovery testing.
• Customization debt: local changes become so extensive that the organization cannot accept upstream releases.
• Weak project health: a project has documentation but no meaningful maintainer activity, releases or support path.
• Missing local capacity: the intended government or partner owner has no funded staff time to operate the service.

Good governance matters more than the licence. In my experience, the recurring gaps are demand management, ownership and service management rather than technical ability alone. The same discipline belongs in AI governance for the United Nations: identify the owner, data boundary, assurance requirement and stopping condition before deployment.

Decision matrix: when to use open source in humanitarian response

Use the following matrix before committing to a solution. Score each option from 1 (poor) to 5 (strong), multiply it by the weight and compare the totals. Adjust the weights to the context: a protection programme should normally weight sensitivity and sovereignty more heavily than a low-risk logistics tracker.

Compare three options for each need: open source self-hosted, open source managed by a provider or shared service, and proprietary or commercial software.

Practical decision rules

• Choose open source self-hosted when data is highly sensitive, there is a capable hosting team and national or local ownership is a long-term goal.
• Choose open source managed when you want transparent technology and portability but do not have infrastructure staff. A managed Kobo or DHIS2 deployment can be more responsible than an unsupported server.
• Choose proprietary software when the capability is a commodity, the vendor offers suitable security commitments and humanitarian pricing, and exit risk is acceptable.
• Do not build anything new when a mature open source tool or digital public good already covers most of the need.

The matrix is not an approval form to complete after a decision has been made. It is the decision record. Keep it with the business case and revisit it when the operating context changes.

How LLMs are changing open source adoption

Large language models have changed the open source discussion in five ways.

1. Open-weight models expand deployment choices

Some models are released with downloadable weights that an organization can run in a controlled environment, subject to their licence, hardware and operational capacity. That can reduce the need to send prompts and documents to an external model provider.

However, open weight is not the same as open source AI. The Open Source Initiative's Open Source AI Definition requires the freedoms to use, study, modify and share, alongside the code and sufficient information about training data needed to make meaningful modifications. Before using an open-weight model, review the actual licence, permitted use, data processing path, update policy and support model.

2. AI can lower, but not eliminate, customization cost

Coding assistants can help a small team write integrations, explain unfamiliar code, create documentation and localize interfaces. That can make adaptation more accessible to a two-person NGO IT team.

It does not eliminate review. AI-generated code can introduce security flaws, licensing confusion and dependencies that nobody owns. Treat generated changes as contributed code: review them, test them, scan dependencies and keep a record of what entered production.

3. Open data becomes more valuable when it is trustworthy

LLMs are most useful when they are grounded in approved sources. Retrieval-augmented generation can help a staff assistant answer questions from controlled policy documents, situation reports and datasets while showing the source behind its answer.

That is not a reason to connect every repository to a chatbot. Access controls, information classification and purpose limitation must continue to follow the data. The AI security and assurance guidance explains why exposure normally sits in the data path and the authority granted to the system, rather than in the model alone.

4. Sector-specific open components can be reused

Open mapping, data-collection and case-management communities already offer reusable building blocks. The more useful AI pattern is usually to add a constrained capability to a proven workflow, such as translation, document classification or duplicate detection, rather than replace an accountable operational process with a general chatbot.

5. AI adds governance and supply-chain risks

AI raises the stakes on familiar governance questions:

• Accuracy: an incorrect answer about service locations, eligibility or legal rights can harm people.
• Data protection: prompts and outputs can contain sensitive personal information.
• Supply chain: models, packages and dependencies must come from verified sources and be assessed before use.
• Regulation: obligations may apply to partners and deployments under relevant laws and contracts.
• Community sustainability: maintainers need funding, documentation and high-quality contributions, not a flood of unreviewed AI-generated pull requests.

Human review remains essential where a system can influence protection, rights or access to assistance. The controls in AI ethics in humanitarian action apply equally to open and proprietary technology.

A practical roadmap for humanitarian organizations

1. Start with demand, not a tool. Confirm the operational problem and whether a build is necessary.
2. Check mature digital public goods and open tools before commissioning custom software.
3. Score open-source, managed and commercial options with the decision matrix, then record why the choice was made.
4. Budget for the complete lifecycle: hosting, security, monitoring, upgrades, training, support and exit.
5. Plan handover to local partners or government from day one, including funded staff responsibility.
6. Pilot open-weight AI only on low-risk, non-personal data tasks before considering sensitive workflows.
7. Contribute back through bug reports, translations, documentation, funding or reviewed code.

Conclusion

Open source has shaped humanitarian response, from collaborative maps after the Haiti earthquake to protection case-management systems used today. In the age of LLMs, its value is growing because controlled model deployment and AI-assisted development can give organizations more choices over data and software ownership.

The winning approach is neither “open source always” nor “open source never.” It is disciplined decision-making: clear criteria, honest cost estimates, strong data governance and a named owner for the system after the emergency phase ends.

Frequently asked questions

What are the most used open source tools in humanitarian response?

Widely used examples include KoboToolbox and ODK-compatible tools for data collection, OpenStreetMap for mapping, DHIS2 for health information, Primero for protection case management, RapidPro for messaging, and HDX-supported data-sharing practices.

Is open source secure enough for sensitive humanitarian data?

It can be. Security depends on hosting, configuration, patching, access control, monitoring and operating practice more than on the software licence. Public code enables review; it does not remove the need for security engineering.

Are open-weight LLMs safe for humanitarian use?

Open-weight models can keep processing within an organization's controlled environment when properly deployed, but they still require licence review, accuracy and bias testing, data-protection controls, supply-chain checks and human oversight for decisions affecting people.

How should an NGO decide between open source and commercial software?

Use a weighted decision matrix covering data sensitivity, total cost of ownership, local maintenance capacity, interoperability, speed to deploy, project health, offline capability, available support and exit cost. Compare self-hosted, managed and commercial options against the same criteria.

What is the difference between open source AI and open-weight AI?

Open-weight AI makes model parameters available. Under the Open Source Initiative's definition, open source AI requires broader freedoms to use, study, modify and share the system, with code and sufficient training-data information to make meaningful modifications.

Sources and further reading

• Humanitarian OpenStreetMap Team: Haiti post-earthquake response
• KoboToolbox software and humanitarian use
• DHIS2
• Primero
• Humanitarian Data Exchange
• Digital Public Goods Standard
• Open Source AI Definition

← All articles