Buckeye Interactive at the National Day of Civic Hacking at the White House

This weekend I was among the lucky few in attendance at the National Day of Civic Hacking at the White House. About two months ago Brad forwarded an email from the White House announcing the impending release of an API for its We The People petition site. Brad encouraged the Buckeye developers to apply, so I submitted a pitch for a WordPress plugin that would allow users to easily embed petitions from We The People into their sites. On the first of May, the day of the API’s release, I received an email inviting me to participate in the second-ever hackathon at the White House.

For the uninitiated, an API allows third-party systems to talk to an application or service. It acts like a switchboard operator – you call a number, tell it who/what you’re trying to reach, and it patches you through. The operator can be given instructions to only connect people to certain endpoints and/or could route you to someone that will give you safe, publicly accessible information. APIs are the backbone of the modern web and what allow developers to embed tweets in a website, plot search results on a Google map, or sign up for a site with your Facebook account.

In the case of the We The People API, third-party applications are able to access the petitions and (sanitized) information about the people who have signed them. This allows developers to embed petitions in other places, run analysis on the data, and build new services on top of We The People. The We The People API is supported by President Obama’s Open Data Executive Order which calls for all newly-generated government data to be open and publicly available in machine-readable formats.

The hackathon

The hackathon began at 8:45 a.m. outside the southwest corner of the White House compound. After going through several rounds of security, we entered the Eisenhower Executive Office Building where we were ushered to room 430, a larger room with clusters of tables, ample power strips, a table with coffee (a must for any congregation of geeks) and donuts, and a screen for presentations at the front of the room. We found seats and introduced ourselves to the faces behind the Github usernames we’ve been communicating with over the past month.

Panoramic shot of the White House Hackathon
Photo credit: Anjelika Deogirikar

Once everyone has had an opportunity to grab some coffee and connect to the Wi-Fi, we take turns introducing ourselves to the room. Start-ups, agencies, researchers, government agencies, and Fortune 500 companies were all represented- around thirty developers in all. After introductions the room shuffled again as developers combined efforts, sought new experiences, or jumped at the chance to contribute to a new project.

In most hackathons the goal is to gather a group of developers, fuel them with food and/or drink, and let them go wild. Sometimes the hackathon is around a product (“let’s see what people can come up with using my technology”), other times its a goal (“how can we creatively solve this problem?”). Typically a hackathon means concepting and developing the project at the event, like a coding version of the 48 Hour Film Project.

At the White House, most developers had entered the hackathon with at least some amount of work completed. A few developers (myself included) arrived with near-production-ready applications, hoping to spend the time polishing and releasing our code, while some entered the EEOB without having looked at the API. The White House stated early on that the goal was to release production-ready applications on the 1st and encouraged us to get started as early as we had time.

After some opening remarks from the White House development team and NASA, the hackathon was under way. I spent a bit of time polishing my plugin and presentation before releasing it on WordPress.org (I had submitted it for approval from WordPress earlier in the week to ensure a June 1 launch). After officially launching the plugin in the late morning, I spent some time networking with the other developers before sitting down to start planning out version 1.1 of the We The People WordPress plugin.

After lunch the White House team offered any interested developers an opportunity to contribute to the planning of the write-portion of the API (at this time the API is read-only, meaning users have to visit the We The People site to create or sign petitions). We discussed scalability, increasing engagement, and the security measures that would need to be put in place to prevent the types of abuse and fraudulent behavior that practically come with the territory of a high-profile, government-backed application.

Steve presenting at White House Hackathon

Steve presenting at the White House Hackathon. Photo credit: @WHWeb

At the end of the day the developers were given a chance to present their hackathon projects. Most projects fell into three camps: plugins and widgets to embed petitions in other sites, visualizations and dashboards of petition information (“how did this petition do over time?”, “what zip codes have signed this petition the most?”, etc.), and applications that use the API to feed applications that gather even more data. The third category was a rather small portion of the hackathon projects but produced some very interesting results. For example, Yoni Ben-Meshulam built the We The Entities application and API that analyzes the title and body of a petition to detect the author’s sentiment (positive, negative, or neutral) towards an issue. Yoni’s API was then used in a few of the other hackathon projects to add another layer to their visualizations. Corinna Cohn, a developer at the AAAS put together a really slick application that enabled pollsters to gauge public support on a petition (“Agree”, “Somewhat agree”, or “Disagree”). These applications add new layers of valuable information atop the petition data.

What’s next?

Now that the hackathon is over and the plugin has been released, Buckeye Interactive intends to continue development on the project. We’re excited for the addition of a write API sometime in the near-future, enabling site owners to collect signatures directly from the embedded petitions. You can follow and contribute to the plugin’s ongoing development on Github.

Photos, resources, and other links