The Relevance of IT for Humanitarian Response
The humanitarian response domain aims to help save lives and alleviate human suffering in responding to: i) rapid-onset natural disasters, such as tsunamis, earthquakes, and pandemics; ii) slow-onset natural disasters, such as global warming, droughts, and famine; and iii) human-instigated disasters, such as civil wars. The humanitarian response domain consists of an ecosystem that is strongly represented by non-governmental organizations (NGOs), civil society organizations, and state-based institutions. The larger organizations in this ecosystem are the non-profit agencies such as Save the Children, the Red Cross, World Vision, Oxfam, and organizations of the United Nations such as the World Food Programme (WFP), the Office for the Coordination of Humanitarian Affairs (OCHA), the World Health Organization (WHO), and the United Nations Children’s Fund (UNICEF). There are also tens of thousands of smaller NGOs serving the domain in different regions and areas of specialization. Most of these institutions survive on donations from society, corporate sources, and various states, and they are governed as non-profit bodies. The domain is also complemented by a great deal of voluntarism that peaks during disaster events. Organizations like Doctors Without Borders/Médecins Sans Frontières or Engineers Without Borders are volunteer professional groups that provide capacity to humanitarian response events.
As much as food, shelter, medical aid, and security are important for the affected victims in a disaster, so too is the information needed to identify those needs in the first place and create the essential connections for recovery. Correct and timely information is critical to effective response, especially during the first three days following an event, when there is an opportunity to save lives with timely action. However, as is often the case during a disaster, the scale of the event overwhelms the effectiveness of information gathering and dissemination using traditional approaches. For example, in the 2004 Asian Tsunami, governments found themselves, all of a sudden, dealing with responding to the needs of millions of people. Managing information at this scale is a problem for which information technology was built. Typical large-scale data management problems include finding missing persons, tracking displaced people, tracking medical facilities, situation mapping, effective distribution of aid and resources, reporting hazards or violence, and many more.
Open Source Communities as Software Engineers Without Borders
In the humanitarian response domain, the free and open source approach has become prevalent for distributing software solutions as public goods. Popular FOSS projects and organizations delivering open source public goods specifically for this domain include:
And there are many more institutions contributing to these projects. These FOSS communities and the global communities that work around them effectively provide “software engineers without borders.” Most of these products depend on open source platforms built from open source components such as Apache, Linux, PHP, Python, MySQL, and these projects in turn have become inadvertent donors towards the goal of delivering these essential software public goods.
Open Source Alignment to Humanitarian Values
Why does open source find such a natural home here? There are multiple reasons particular to the humanitarian response domain where open source software freedoms and practices align to the principles in the humanitarian domain. Over the years, these principles have been captured in codes such as the Red Cross Code of Conduct. The principles that align to FOSS in particular include:
1. No discrimination on access: From the time an open source package is available online, it becomes a global public good that anyone, irrespective of race, station, or creed, can download and use, customize, and apply to serve their respective relief effort.
2. Ability to leave technology behind: Irrespective of the support group that brought the technology to help the response effort, open source is a product that can be left behind and maintained by local groups if required.
3. Empowering local capacity: Most disaster response activities work around the local capacity on the ground. The local community is the most tuned-in to the priorities of disaster response and thus they are the best suited group to modify the software for the response effort. Local open source community groups, such as local Linux User Groups, are recommended as a support mechanism.
4. Lower cost: Open source reduces the cost of software for disaster response, which means more funds are available for essential aid.
5. Transparency and neutrality: The software design and mechanism for building FOSS is transparent and neutral. These characteristics are particularly important for countries that mistrust the origins and affiliations of technology. With FOSS communities that are mature, global, and diverse, the software has no specific alignment to a particular political agenda.
In addition, FOSS also has the following added advantages in humanitarian response:
6. Rapid localization and adaptability: No two disasters are alike; often localizations and customizations are needed for the software before it can be applied effectively to a disaster. Furthermore, no two nations handle the humanitarian response in the same manner. Free access to the code and the freedom to modify it are essential benefits provided by FOSS.
7. Open standards and data exchange: With many different systems in operation during a disaster response, it can be a significant issue if they do not share data. To avoid confusion and inefficiencies, it is essential for systems to be able to share information through open standards. Open source has a track record with open standards from TCP/IP and it helps promote the spread and implementation of open standards.
8. Shared inter-organizational development: NGOs and humanitarian relief groups all need software tools to be effective and competition is not as rife as in other industries. Sharing the development of their IT infrastructure is a natural way to reduce costs and promote integrated response efforts.
Does HFOSS Differ from FOSS?
Rather than differing from FOSS, HFOSS recommends certain best and standard practices due to the critical nature of the humanitarian response environment and the impact solutions can have. These best practices include:
1. HFOSS software is mission critical: The HFOSS products that are delivered can have a significant impact on saving lives and alleviating suffering, thus the systems are mission critical and there can be no compromises on quality and stability. Information loss or corruption due to the system is completely unacceptable.
2. High usability and low learning curve are essential: The entire disaster response community is diverse and ranges from trained emergency responders to untrained volunteers. Most of these users have not seen or used the HFOSS system before; they should be able to understand how to use it in as little time as possible.
3. No administrators and superusers are expected: Chances are there will not be strong linux-savvy administrators around to help set up the software. Even if there were, they probably will not have the time. A normal IT-literate user should be able to install the software and a version that runs on Windows is essential.
4. Data sharing through import and export: Data will arrive and be needed in many formats, thus import and export mechanisms, especially using open standards, are important to make the software effective.
5. High resilience and avoidance of single points of failure: Humanitarian response solutions have to be fault tolerant to issues like a lack of Internet access, throughput, and even power. Additionally, the community should be diverse enough that there are multiple people to support a particular solution so that no one becomes a bottleneck.
The HFOSS Consortium
HFOSS, or the approach of delivering open source products in the humanitarian response domain, is a model that is now widely accepted by many of the key institutions. However, there are often shortcomings, mostly due to the infancy of these volunteer developer communities, that need to be addressed before the model becomes widely adopted. Some of these concerns can be resolved in partnership. A good example was between InSTEDD, Ushahidi, Sahana, Crowdflower, Google, and the Crisis Mappers Network in the establishment of the “4636” SMS short code as a free aid service for response during the Haiti Crisis Response. Enabling this partnership, however, required system-to-system data exchange between systems, which required some last-moment hacks and rapid enhancements. A reflection of this partnership following the Haiti response initiated an informal grouping of HFOSS projects that includes InSTEDD, OpenStreetMap, Ushahidi, Sahana, One Laptop per Child (OLPC), and Google. This group was established to work towards better integration between systems and be better prepared for collaborative response. To help encourage more collaboration, an HFOSS code of conduct capturing development and deployment best practices has also been drafted and accepted. Recognizing all areas for improvement, an HFOSS maturity model is also being developed as a yardstick for growth to deliver to the demands of disaster response with more rigor, efficiency, and sustainability.