How the American Red Cross built an open source disaster-response application for and with volunteers

How the American Red Cross built an open source disaster-response application for and with volunteers

Nonprofits and public sector organizations worldwide are focused now more than ever before on building software to scale programs and their impact.

The Red Cross is no exception.

While technology may not be the first thing that comes to mind when you think of the Red Cross, it’s an essential part of how we deliver our mission to help people in need.

With software, we can help more people, more quickly, and react with agility when situations change. Further, these are benefits that every mission-oriented organization can benefit from.

But getting started can feel daunting for those who have never built software. To assist in those first steps, I’d like to share a few of the things I learned along the way that have allowed us to succeed in developing software for our programs.

Why the Red Cross builds software

Our mission at the American Red Cross is to prevent and alleviate human suffering. It’s that simple.

While most people associate Red Cross disaster response with large-scale incidents (such as hurricanes, tornadoes, and wildfires), we actually respond to 60,000 disasters annually, most of which are house fires.

Every day, we ensure those affected by disasters big and small have immediate access to food, shelter, clothing, medication replacement, emotional support, and other essential resources in these moments of crisis.

Back in 2014, most Red Cross regions were dispatching volunteers manually, entering data into Microsoft Excel spreadsheets or Word documents to track responses. In the field, our volunteers were using LOTS of paper to manage casework needs of our clients. In Chicago, we were responding to 1,100 disasters a year—more than three a day—all through this time intensive process.

This manual approach slowed response time and taxed our volunteers. We knew we needed a better way to scale our services and provide more timely services.

So we decided to build it ourselves.

In partnership with volunteer software developer John Laxson and a Red Cross staffer Michael Hersher, both working in San Francisco, we created Disaster Cycle Services Operations (DCSOps), an open source software application designed to log disasters, dispatch volunteers, and track outcomes.

It worked—and continues to work for us today! We’ve reduced our dispatch times by 50 percent and enabled our teams to help thousands more people by using Google maps to locate incidents and volunteers, and Twilio SMS to communicate with them in real time.

What started with just a couple of people in San Francisco and Chicago has grown into a service used in 10 regions across the US, that enables 11,500 volunteers to quickly provide help to people in crisis. Through this service, we’ve responded to nearly 100,000 disasters as of June 2020. Through the new approach, we have not only been able to respond faster, we’ve also become more agile.

A novel challenge: COVID-19

Most recently when COVID-19 hit, we knew we’d need to adjust our tactics.

Instead of sending people out to the field in person as we’ve historically done, volunteers now respond virtually by gathering damage assessments from fire departments, photos from clients, and meeting with people over video conferences.

But since DCSOps is entirely cloud-based, we can still manage incidents the same way. Even as we updated logic around how volunteers are assigned, the core functionality has remained unchanged.

That’s the power of using software for us at the Red Cross. Let’s look deeper at what we’ve learned along the way.

Start with a minimum viable product

It’s tempting to try to boil the ocean at first: list every feature you want, create a big RFP and hire someone to build your dream application. It’s software, right? Let’s get something that does everything we want!

This approach has not been successful in my experience at the Red Cross. So for DCSOps, we began by embracing the terrific GOV.UK government design principles and started simply with a minimum viable product (MVP) and then began iterating from there.

As we evolved DCSOps, we ensured the product was always functional and could be used by volunteers. We started with a bare bones application and gradually added features as we learned more about user and program needs. For example, at first our solution didn’t include Twilio SMS communications and Google Maps was only used to identify incident locations, not help dispatch or find volunteer responders.

By starting with an MVP, we also learned things early and often that changed our roadmap and prioritization that wouldn’t have been possible if we’d tried to build the entire application at once.

For example, we learned early on that many volunteers didn’t have access to traditional computers (or chose not to use them) and, instead, preferred their phones. Identifying this need and solving it early on allowed us to focus on the actual needs of our volunteers by not ‘getting ahead of our users’ and letting their experience teach us as we went.

Consider open source

At the outset, we made the decision to keep DCSOps open source.

This was controversial, because for many people at the Red Cross, open source sounded risky and unsecure. On the contrary; building open source has enabled us to build a more secure product.

Open source development means that more people are reviewing the code and can help find vulnerabilities. Not only does this transparency help us identify bugs, but anyone can contribute to helping fix vulnerabilities, which is essential for an organization like the Red Cross that relies on volunteers not only for disaster response, but software development as well.

In fact, the majority of the contributions to DCSOps since its inception have been from volunteer developers—it’s truly an application by and for volunteers.

Lastly, being open source helps us ensure that there is no single point of failure. If someone leaves the project, we can always hand development to the next person. In fact, open source development and the need to document and track contributions across contributors & time removes any ‘hidden knowledge’ in one person’s head.

Volunteer development can work

In case you read the note above about developing an application with volunteers with skepticism, I want to ensure you it’s possible.

That said, we don’t build software with volunteers specifically because it’s cheaper. We do it because it aligns with our mission and delivers better long-term results.

Here are a few things we’ve learned along the way—through the development of DCSOps and other applications—that help us ensure that volunteer contributions can result in high quality software development.

1. You’ll need project managers, not just developers. Your PM could be a staff member, a consultant or a volunteer, but you’ll want to ensure you have people working on the project who are committed for a longer period of time and can help manage the user needs and roadmap. They help volunteers set up their working environments, review pull requests, lead virtual stand-ups and provide general, overall continuity. To build DCSOps, we’ve handled project management using a combination of volunteers, Red Cross staff and paid consultants.
2. Document user needs—or “stories”—as product requirements—or “issues”—and connect developer code contributions to those requirements. Maintaining traceability between issues and code contributions, will help your developers track code changes over time, who made them, and identify what issues drove those changes.
3. Have a plan in case your service goes down. We work with an open source support company named Open Tech Strategies on a limited engagement. When things go awry—and they do—we call them in. We don’t always need them on a regular basis, but when we do, they are a lifesaver!
4. Provide a variety of opportunities to contribute. We’ve found that some people want to show up and work on a specific task for a weekend, and others will contribute regularly. When we create tasks for volunteers, we take into account the range of commitment levels so that there are opportunities for more people to contribute, and ultimately more can get done.

Use hackathons wisely

Hackathons are an important activity for software development at the Red Cross. These events have enabled us to achieve significant development milestones and also recruit ongoing contributors.

In my experience, I typically see two kinds of hackathons used by organizations to inspire or support application development.

First, there are the “big idea” hackathons: people come together for a weekend, brainstorm some ideas to solve a significant problem, build a bunch of discrete solutions and then then go home. They all agree to continue the work but over time, as life happens, the project falls off everyone’s priority list.

Second, there are highly technical hackathons where developers drill deep to solve a specific coding challenge. While real work gets done, these hackathons lack the “change the world” optimism that inspires volunteers to join your cause in the first place.

At Red Cross hackathons, we try to split the difference between the feel good and the coding execution.

We host events where we have a specific problem to solve that will attract people who want to engage in a project that will actually help people. We also ensure that the outcome of the event advances the application so that meaningful product development takes place. This balance of impact and specific code requirements helps ensure that the event is worthwhile for both participants and the Red Cross.

Partnerships with tech companies can help you succeed

Early in our project, we learned about programs that Twilio.org and Google for Nonprofits offered that would help us build and scale DCSOps. Through their social impact teams, we’ve benefitted from technical expertise and product support that shaved time and cost out of our application development. (Pro tip: Twilio and Google are part of the Impact Cloud, a coalition of cloud tech companies that all offer product donation programs for nonprofits).

Working with leading tech companies has also helped build recognition for the Red Cross as a leader in nonprofit digital transformation. When I tell new volunteers or funders that we’re using the same SMS API as Lyft, or the same Google Maps API that you use on your mobile phone get directions from point A to point B, this provides instant credibility.

I’ve also had the opportunity to present at events with our tech partners about the ways we use software to scale our mission, allowing the Red Cross to reach new audiences and elevate our impact.

Getting started on your first application

I hope all this inspires you to consider building your first application or taking a project you’ve already started and turning into something that can really deliver on YOUR mission. Your results are important, but don’t let the process deter you. It will be slow. It will be challenging. You’ll make mistakes and your first effort may fall short of your expectations. But you will learn (and hopefully achieve) more by trying and doing it yourself.

Are you a developer who wants to get involved in a humanitarian, open source project? Visit our DCSOps repository on GitHub.

Finally, If you’d like to learn more about the Red Cross and how we’re building software to scale disaster response, watch our session from the Good Tech Fest, with Meredith Delich, Program Manager at Google for Nonprofits, and Jacob Talbot, Senior Marketing Manager at Twilio.org.