Last weekend, I participated in Hack for Change, a 24-hour codeathon sponsored by Change.org and Code for America where developers and designers were challenged to create apps for the public good. As my first hackathon, it was a tremendous experience in a number of ways, and some really cool applications came out of the process. Though we didn’t win, I’m very proud of the app my group built, Safehood — an entirely SMS-based anonymous communication channel for a neighborhood to discuss crime and potential safety threats, sort of a real-time backchannel for an existing neighborhood watch.
There was something that one of the groups said in their presentation, though, that kind of pressed my buttons. They made some very enthusiastic–grandiose, even–claims about how their application was going to change the world. But, I wondered, who would it change the world for, in whose interest? iPhone users, apparently–their app was iPhone-only. Well, this shouldn’t be a surprise, but even in San Francisco, most people don’t have iPhones. Most people don’t own smartphones, even. And for a significant–and radically underserved in many other aspects–segment of the local population, their only access to the Internet comes in thirty-minute increments at the public library.
Granted, there are many social problems that need addressing besides the digital divide. But it’s an issue that affects every entrant in this hackathon to at least some degree because of its very nature–trying to solve problems with technology. If a segment of the population can’t realistically use or access your app, your claims about the extent to which you successfully address your chosen cause should reflect that.
When my group started brainstorming what we wanted to do for our application, my teammate Michelle had a simple suggestion: let’s build something to help poor people, something to address at least one aspect of the cycle of [urban US] poverty. You wouldn’t think such a suggestion would be radical at an event called “Hack for Change”, but it totally was. All the app ideas I had thrown out previously were things that I could see myself using–an anonymous photo-submission police tipline-type service in response to the Vancouver riots, or an app for emergency response and resources in case of an earthquake or other natural disaster. Certainly they weren’t apps that only I would find useful, or even only people in my socioeconomic class. But that was a major bias in my thinking. Michelle’s suggestion took us out of that frame, and after further brainstorming and deliberation, Safehood was the eventual result: an application for helping communities collaborate to make their neighborhood safer, with a user interface designed from the beginning for a population that might not have a computer or smartphone at home. In our mental picture of how the app would be used, we now had Oakland in our head instead of Berkeley. I won’t go so far as to say that we succeeded in all this–there’s a million ways the app could be improved. But at least that’s where our heads were at.
Of the 16 or so applications at Hack for Change, I don’t know for sure, I wasn’t part of their brainstorming sessions, but I don’t think that a single other group had “Let’s build something to help poor people” or similar as their starting point. That’s not to say that some of the apps couldn’t be useful to poor people, or that they didn’t successfully address whatever their other chosen cause was. But still, that seems… off, somehow.
Most of my coding experience is on free and open source software projects, and most of the coders I know are part of that community. In FOSS, projects get started (and get continuing contributions and enthusiasm) because a developer wants to scratch his or her own itch. Which is understandable, and just fine most of the time. Hacking for “change” is different. Hacking for social change isn’t about scratching our own itch–it’s about scratching someone else’s itch, especially someone who may not have the resources to scratch it themselves. Being cognizant and deliberate about that difference is a challenge, but a necessary one, and one that I suggest that all designers, developers, and others think about taking on.