Change.org

Overview

I worked across teams during my internship at Change.org, eventually settling on a team that was just beginning to lay the groundwork for the company’s mobile play. At the request of many petition creators, I was tasked with exploring the viability of a mobile app suite that could be used to locally canvas for signatures. Working with stakeholders on the community management and design teams, I built a cross platform app on top of the internal API. In the process, I audited their API, specced out its expansion, and began efforts to rewrite it by decoupling it from the core Ruby on Rails app.

Background

While interning at Uber the previous summer, the company faced a significant amount of resistance from Taxi and Limousine Commissions around the country. To overcome the obtuse regulatory hurdles that were erected by the TLCs in attempts to thwart service expansion and competitive pricing, Uber successfully employed “guerilla” campaign tactics, collecting thousands of signatures from locals and presenting them to the governing bodies (1, 2, 3). Through these petitions, I saw first-hand that these crusades were highly effective and provided an agent for the voices of everyday people against ambiguous power structures.

Also around this time, many important movements started with a Change.org petition, including consumer protection advocacy that gave a voice to those who felt powerless against monolithic corporations, lobbying efforts that prompted a trial for the murder of Trayvon Martin, and progressive social action that saw the admittance of gay boys into the Boy Scouts. I sympathized deeply with each of these causes in addition to the many others that individual people have championed on Change.org, and I fundamentally wanted to do more than sign and share petitions.

It then occurred to me that with the web development skills I had gained, I possessed the tools necessary to contribute to such an important platform. So, I reached out and applied for an internship.

Canvasing App and API Audit

Situation

Change.org is best known for the national campaigns it hosts, but the platform is also successfully used by many local community organizers. These local organizers, and to some extent the national campaign organizers, had reached out to Change.org and expressed frustration that they couldn’t easily work their Change.org petition into their ground-game campaign of knocking on doors or tabling at local events.

The platform fundamentally lacked tooling for using one “client” to sign a petition multiple times as different people. This ability was originally curbed out of concern for botting, but unfortunately also limited legitimate use. I was tasked with exploring the use of mobile apps, particularly for the iPad that could both address the botting concerns and solve the problem faced by petitioners.

Contribution

I began by working with designers and a community manager at Change.org to figure out how the app should work, what functionality it should have, and how to best address the needs of the users. Once I had a good idea of the goals of the project, I explored my options for technology stacks to leverage for building the app. While I had significant prior experience building iPhone apps in Objective-C, I decided on using one of the then-novel libraries that allowed me to write the app using web technologies. I chose this path because the iteration time would be much quicker, expanding to other devices (like Android) would be trivial, and because someone from the majority-web-programmers engineering team would need to maintain the app once my internship was over.

As I began work, it quickly became clear that the scope was larger than expected. In order to build the app successfully, the internal API, which was built on top of the internal Ruby on Rails app, would need to be extended. In addition to lacking some necessary endpoints, engineers at Change.org had previously built in safe-guards against easily signing a petition multiple times from the same client. I worked with the engineers in charge of the API to spec out the needed additions, factor out the relevant components, and battle test the new endpoints.

Outcome

Ultimately I was successful in building out the necessary API improvements and had just enough time left in my internship to prototype the app and present it on my last day.

While it was eventually decided that the need wasn’t as large as expected, the project helped the engineering organization understand what would be needed to build out mobile support, and would lead to further API improvements down the road. My largest takeaway was the realization that, by extending the API, many more apps could be built. As I built out support for the canvassing app, I came up with other API-based ideas that could further the company’s mission and supplement their revenue. I also presented these learnings on my last day.