Crisis Commons, and the challenges of distributed disaster response

Heather Blanchard, Noel Dickover and Andrew Turner from Crisis Commons visited the Berkman Center Tuesday to discuss the rapidly growing technology and crisis response space. Crisis Commons, Andrew tells us, came in part from the recognition that the volunteers who respond to crises aren’t necessarily amateurs. They include first responders, doctors, CEOs.. and lately, they include a lot of software developers.

Recent technology “camps” – Transparency Camp, Government 2.0 Camp – sparked discussion about whether there should be a crisis response camp. Crisis Camp was born in May, 2009 with a two-day event in Washington DC which brought together a variety of civic hackers who wanted to share knowledge around crisis technology and response. The World Bank took notice and ended up hosting the Ignite sessions associated with the camp, giving developers a chance to put ideas for crisis response in front of people who often end up providing funds to rebuild after crises.

The World Bank wasn’t the only large group interested in working with crisis hackers. Google, Yahoo! and Microsoft came together to found the Random Hacks of Kindness event, designed to let programmers “hack for humanity” in marathon sessions around the world.

While these events preceded the earthquake earlier this year in Haiti, that crisis was the seminal event in increasing interest in participating in technology for crisis relief efforts. A crisis camp to respond to the Haitian earthquake involved 400 participants in five cities and pioneered 13 projects. Over time, the crisis camp model spread to Argentina, Chile and New Zealand, with developers focused on building tools for use in Haiti, Chile and Pakistan. Blanchard explained that the events provided space for people who “didn’t want to contribute money – they wanted to do something.”

The camps had some tangible outcomes:
– I’m Okay, a simple application that allows people to easily tell friends and family that they’re okay, in an emergency situation, was developed at Random Hacks of Kindness
– Tradui, an English/Kreyol dictionary for the Android was developed during the Crisis camps
– Crisis camps also developed a better routing protocol to enable point to point wireless between camps in Haiti, writing new drivers in 48 hours that were optimized for the long ping times associated with using WiFi over multi-kilometer distances

Perhaps the most impressive collaboration to come from the Crisis Camps was work on OpenStreetMap for Port au Prince. Using satellite imagery released by the UN, a team created a highly detailed map, leveraging the work of non-programmers to trace roads on the satellite images and diasporans to identify and name landmarks and streets. As the map improved in quality, the volunteers were eventually able to offer routing information for relief trucks, based on road damage that was visible on the satellite imagery. A convoy would request a route for a 4-ton water truck, and volunteers would use their bird’s eye view of the situation – from half a continent away – to suggest the safest route. Ultimately, the government of Haiti requested access to the information, and Crisis Camps provided not only the data, but training in using it.

The conversation turned to the challenges Crisis Camps have faced in making their model work:
– About 1/3rd of the participants are programmers. The others range from the “internet savvy” to those with complementary skill.
– Problems and requirements are often poorly defined
– It’s challenging to match volunteers to projects
– There’s a shortage of sustainable project management and leadership
– Projects often suffer from undocumented requirements and code, few updates on project status.
– Little work focuses on usability, privacy and security.
– Code licensing often isn’t carefully considered, and issues can arise about reusability of code on a licensing basis.
– Projects can be disconnected from what’s needed on the ground
– Disconnection happens in part because relief organizations don’t know what they want and need and are too busy to work with an untested, unproven community
– Volunteer fatigue – the surge of interest after a disaster tends to dissipate within four weeks
– There’s a lack of metrics and performance standards to evaluate project success.

The goal is to move from a Bar Camp/Hackathon model to a model that’s able to build sustainable projects. This means bringing project management into the mix, and asking hard questions like, “Does this project have a customer? Is it filling a well-defined need?” It also means building trust with crisis response organizations and groups like the World Bank and FEMA, who can help bring volunteer technology groups and crisis response groups together.

Crisis Commons see themselves as mediating between three groups: crisis response organizations like the Red Cross; volunteer technology organizations like OpenStreetMap; and private sector companies willing to donate resources. Each group has a set of challenges they face in engaging with these sorts of projects.

Crisis response organizations have a difficult time incorporating informal, ad-hoc citizen organizations into their emergency response plans. There’s a notion in the crisis response space of “operating rogue” if you’re not formally affiliated with an established relief organization… which further marginalizes volunteer tech communities. Many CROs have little tech understanding, which means they aren’t able to make informed decisions about collaboration with technical volunteers. In a very real way, crises are economic opportunities for relief organizations – that reality doesn’t breed resource sharing, which in turn, gets in the way of sharing best practices and lessons learned.

Volunteer tech communities frequently don’t understand the processes used by CROs, and frequently fail to understand that there’s often a good reason for those processes. While VTCs provide tremendous surge capacity that could help CROs, if there’s no good way for CROs to use this surge capacity, it’s a waste of effort on all sides. At the same time, tech communities inevitably suffer from the “CNN effect” – when crises are out of sight, they’re out of mind, and participation slumps. This is particularly challenging for managing long-term projects… and tech communities have massive project management and resource needs. Finally, successful VTCs can find themselves in a situation where they have a conflict of interest – they’re seeking paid work from relief organizations and may choose to cooperate only with those who can support them in the long term.

Private sector partners are usually participating in these projects led by their business development or corporate social responsibility divisions… while cooperation with the other entities often requires technical staff. Response organizations are often the clients of private sector players – the Red Cross is a major customer for information systems – which can create financial conflicts of interest. And working with large technology companies often raises intellectual property challenges, especially around joint development of software.

Meeting with a subset of crisis response organizations, Crisis Commons understands that there’s a need for long term relationships between tech volunteers and relief organizations, tapping the innovation power of these charitably minded geeks. But this requires relief organizations to know what solutions are already out there and what are reasonable requests to make of volunteers. And volunteer organizations need to understand the processes CROs have and how to work within them.

The hope for Crisis Commons is to become an “independent, nonpartisan honest broker” that can “bridge the ecosystem and matrix the resources.” This means “translating requirements of the CRO to the crisis crowd, helping the public understand CRO requirements,” and the reasons behind them. This could lead towards being able to set up a service like “Crisis Turk”, which could allow internet savvy non-programmers to engage in data entry tasks during a crisis.

In the long term, Crisis Commons might emerge as an international forum for standards development and data sharing around crises. Building capacity that could be active between crises, not just during them, they could direct research projects on lessons learned from prior disaster relief, could build a data library and begin preparing operations centers and emergency response teams for future crises. Some scenarios could involve managing physical spaces to encourage cooperation within and between volunteer tech teams and providing support for future innovation through a technology incubation program.

Starting from the shared premise the Crisis Commons founders presented us with – “Anyone can help in a crisis” – the discussion at Berkman focused on the structure Crisis Commons might take. The goal behind a “commons” structure is to be able to be an independent and trusted actor in the long term, to be able to be objective source of tech requirements, and to be able to bring non-market solutions to the table. But the founders realize that this is an inherently competitive space, and that volunteer organizations might find themselves in conflict with professional software developers in providing support to relief organizations, or with relief organizations if volunteer organizations began providing direct support.

It’s also possible that another player in the space could compete with Crisis Commons in this matchmaking role. Red Cross could develop an in-house technology team focused on collaborating with technology volunteers. Google could use the power of their tech resources to provide services directly to relief organizations. A partnership like Random Hacks of Kindness could emerge as the powerful leader in the space. Other volunteer technology organizations – Crisis Mappers, Strong Angel – might see themselves providing this bridging function. FEMA could start a private-public partnership under the NET Guard program. What’s the sweet spot for Crisis Commons?

One of our participants suggested that Crisis Commons could be valuable as a developer of standards, working to train the broader community about the importance of standards, and on the challenge of defining problems where solutions would benefit a broad community.

Another participant, who’d been involved with several Crisis Camp events worried that “the apps, while neat, never really made it into the field,” suggesting that the problems raised are real, not theoretical. It’s genuinely very difficult for tech volunteers to know what problems to work on… and hard for relief organizations under tremendous pressure to learn how to use these new tools.

This, I pointed out, is the problem that could prove most challenging for Crisis Commons in the long term. When crises arise, people want to help… but it’s critical that their help actually be… helpful. Clay Shirky told the story of his student, Jorge Just, who’s worked closely with UNICEF to develop RapidFTR, a family tracking and reunification tool. It’s been a long, engaged process with enormous amounts of time needed for the parties to understand each other’s needs and working methods… and it’s easy to understand why it might be difficult to convince volunteers to participate to this depth in a project.

I offered an observation from my time working on Geekcorps – I meet a lot of geeks who are convinced that the tech they’re most interested in – XML microformats, mesh wireless, cryptographic voting protocols – are precisely what the world needs to solve some pressing crisis. Occasionally, they’re right. Often, they’re more attached to their tech of choice than to addressing the crisis in question.

As such, the toughest job is defining problems and matching geeks to problems. At Geekcorps, it often took six months to design a volunteer assignment, and a talented tech person needed to meet several times with a tech firm to understand needs, brainstorm projects and create a scope of work, so we could recruit the right volunteer. While that model was expensive – and ultimately, made Geekcorps unsustainable – I think aspects of it could help Crisis Commons find a place in the world.

I ended up suggesting that Crisis Commons act as:
– a consultant to relief organizations, helping them define their technical needs, understand what was already available commercially and non-commercially and to frame needs to volunteer communities who could assist them
– a matchmaking service that connected volunteer orgs to short term and long term tech needs, preferably ones that had been clearly defined through a collaborative process
– a repository for best practices, collective knowledge about what works in this collaboration.

Unclear that this is the right solution for Crisis Commons or the road they’ll follow, but I came away with a strong sense that they are wrestling with the right questions in figuring out how to be most effective in this space. Very much looking forward to discovering what they come up with.