“What this world needs is a new kind of army - the army of the kind."
Humanitarian free and open source software (HFOSS) represents the application of free and open source software (FOSS) to the coordination problems faced in the humanitarian and disaster-response domains. FOSS has found a natural home serving the humanitarian domain because of certain problem patterns that promote the use of an open source approach. HFOSS also integrates two volunteer-rich communities that have much in common: the humanitarian community and the open source community. HFOSS is not distinct from the free and open source approach, but is rather a specialization of its principles. This article explores and elaborates on that natural alignment by presenting the concepts of HFOSS and the ecosystem that sustains it.
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.
The HFOSS Ecosystem for Sustainability
Despite the best of intentions, volunteerism will not easily deliver to standards and best practices in a sustainable and consistent way. What we often find is that there is a peak in capacity in HFOSS projects during a disaster response event, but it soon tapers away, leaving solutions that are sometimes not being maintained actively. There is also an imbalance in the different tasks required from development, documentation, quality assurance, and training based on available volunteer capacity. There needs to be an economic model to sustain a core group of people around the deployed solution to cater to its stability, usability, documentation, and training.
However, at the same time, it is rather inappropriate to be seeking business opportunities in the midst of a disaster response, where most private and public institutions are found donating goods and services. This is why most of the organizations that work in humanitarian response are non-profits, NGOs, and government funded groups. Some of the HFOSS projects themselves are funded non-profits, such as InSTEDD and Ushahidi, and they sustain core teams for disaster response. However, even they cannot manage all events and there needs to be a transition to other providers, especially in building up local capacity for support. Ushahidi, for example, transitioned the maintenance of the Haiti Ushahidi deployment to a private company based in Haiti.
Thus, business and social entrepreneurship opportunities lie in pre-disaster and post-disaster events, when the efforts of volunteer and non-profit organizations are insufficient to maintain tailored solutions for either the recovery or preparedness phases of disaster response.
A Proposed Public-Private Partnership Model for HFOSS Projects
An effective economic model has still to evolve that sees non-profits, for-profits, corporate social responsibility programs, and volunteers all working towards a common goal in delivering HFOSS solutions. A business model the author would like to propose for this domain is that of an HFOSS project governed by a funded, central non-profit organization with a paid core team to manage contributions and assure the quality of the core product releases. This same team would be funded for disaster response efforts. However, once the initial support is provided, a suitable transition needs to be made, preferably to a local for-profit or non-profit organization that will maintain the solution in the long term. A certification and corporate sponsorship program can in turn help maintain the essential tenets of quality and fund the core non-profit for its maintenance activities.
Delivering global public goods in the form of free and open source products has become a popular norm in the humanitarian response domain. HFOSS projects and the communities that surround them have become the natural homes for the “software engineers without borders” of the world. However, these projects need further growth to assure the sustainability and quality of products being deployed due to the mission-critical nature of the applications and their requirements for a high degree of quality, especially aligned to stability, fault-tolerance, and usability. One approach to delivering sustainability can be through a healthy economic ecosystem around an HFOSS project that involves funded non-profits, for-profits, corporate social responsibility programs, and volunteers working together to bring efficiencies to the disaster response efforts that will help save lives and alleviate human suffering.