Gray Brooks on the U.S. government and the GSA Open Data Intiative

Gray Brooks has served at the Federal Communications Commission the last three years as part of the digital team overhauling the agency’s web presence and standing up their current Drupal site. In the lead-up to the release of the Digital Government Strategy, he transitioned to the General Services Administration (GSA) to serve as Senior API Strategist. As part of the agency’s recently launched Innovation Center, his role is to promote the role of web services in government and to support federal agencies in their implementation of the Strategy’s milestones.

API Economist: Back in May 2012, the White House launched their Digital Strategy: Building A 21st Century Platform To Better Serve The American People. One of the key tenets of that strategy was to make open data content and web APIs the foundation of the platform. How is the GSA [General Services Administration] doing on implementing this strategy, and what are some of the biggest challenges you face?

Gray Brooks: Along with all the other agencies actually implementing the Digital Strategy, GSA reports on its progress at GSA.gov/DigitalStrategy. There's also a JSON and XML version available at /DigitalStrategy.json and /DigitalStrategy.xml. We use those because we want to have the progress that agencies are making per‑item and per‑subsection parsed out very clearly, so that information is available not only to the OMB [Office of Management and Budget] and the White House, but also to everyone else.

If you go to APIEvangelist.com and click on their federal government section, they've got a mash‑up showing some of the progress that's going on with API production as part of the Digital Strategy. GSA is on schedule, and over the next two months, you're going to see GSA as well as the rest of the agencies following up and updating their 12-month milestones. I definitely recommend keeping an eye on that. As far as challenges go, it's the same with all agencies; honestly, it’s a question of institutional inertia.

Across the Federal Government, every agency is at a different point of progress with API adoption as a concept and as a philosophy. For those who haven't really started or have only just begun, it's still a matter of transforming how they think about their web presence and their infrastructure. But people are getting it and are making forward progress.

API Economist: Talk about some of the APIs that the GSA has released.

Gray Brooks: As part of the Digital Strategy, and just because it's one of the best practices that's emerging across government, the GSA has not only stood up new APIs, but also a developer hub. We want that to be a place where anyone can get access to all of the APIs that are being produced, no matter which section they're being produced from. You don't need to know which unit or agency within GSA is producing them. Some of the ones that are actually part of the Digital Strategy roll out include the Per Diem API, which is something that a lot of government employees use on a regular basis. We arrived at that, in part, by looking at the site search, looking at the analytics, and realizing that this is a data set that a lot of people are interested in on a daily basis. The other was the Federal Agency Directory API - the most thorough directory information that you can find in the government presence is USA.gov and their agency directory. We wanted to activate an API for that.

The Federal Jobs API allows you to tap into a list of current job openings with the government. It’s great for job websites or applications, job banks, and career counseling and placement applications.

API Economist: As the senior API strategist for the GSA, how do work with other agencies on API strategies and best practices?

Gray Brooks: I was brought over from the Federal Communications Commission (FCC) to that very end, to support agency adoption of the Digital Strategy. The Digital Services Innovation Center, of which I'm a part, was stood up to support agencies doing APIs, analytics, and a number of important forward-leaning efforts. Basically, if any agency within the executive branch is doing APIs or has an interest in doing APIs, we have sought to be in touch and to find out how we can help and make solutions that scale.

We also have a lot of great training content on APIs in government at Howto.gov/api. That's where we're continuing to try to add resources and material to memorialize a lot of the conversations that we have with agencies so that other agencies can forward it around and can arrive at it without having to wait on us to meet with them in person.

We work to try to provide a customized set of counsel and support for each agency, depending on where they're at. For those who have not started, we've really encouraged them to go ahead and just start somewhere. One of the things I like to tell people is that the fourth API they make is going to be easier than the third, the fifth will be easier than the fourth.

Once they get started, it's kind of like an engine that starts to be able to sustain itself. We tell them to think about their web presence as discernible chunks of information that are being presented to the public, and to conceive of those individual chunks as the potential candidates for producing those APIs. Once they understand the role that APIs can play, they should basically look for low-hanging fruit to get started. They should also look at their site search logs and analytics and ask, "What's something discreet and discernible that we can provide a solution for?"

API Economist: Are there any departments or agencies that stand out?

Gray Brooks: A number of them have started scaling out intermediate or advanced API production. The Department of Labor definitely stands out as being a thought leader in government. They have a very fleshed out developer community that's a model for other agencies. The Energy Department and HHS (Health and Human Services) are really important examples because of the sheer volume of APIs they're producing, and how comprehensively that's taking place across their departments.

Then there is Census Bureau, Federal Register, and EPA. Although not as large as entire cabinet-level departments, they're doing really, really good work in the APIs they're already producing as well as how they're conceiving of their future APIs.

API Economist: Hackathons are actually quite popular in the commercial and public sectors. What’s the Federal Government doing around sponsoring or participating in hackathons?

Gray Brooks: Over the last four or five years, over a dozen agencies have actually hosted hackathons. Some call them "datapaloozas" while others call them developer days. We did a couple at the FCC when I was there. What we found was that it serves a few ends. It helps to drive the interest in the data. But it also helps to acculturate the staff of that agency to a more collaborative relationship with third‑party developers. Of the ones I've seen, a number definitely had capacity crowds. Some of them are bigger than others. When the White House hosts an event, they get particularly large attention. But also, HHS and their datapaloozas have been so well fleshed out as far as the presentations and the projects that people are working on. They're really setting the bar high. I think a lot of other agencies are trying to replicate that.

API Economist: Across everything you have seen in the Federal Government, what stands out or what achievement embodies the innovation you are trying to achieve?

Gray Brooks: One definitely comes to mind. The Federal Register's API receives some really worthwhile praise because the Federal Register has a fairly straightforward mission and they basically set about building an API that supports that full expanse of their mission. The complete Federal Register is available now through a RESTful API. The Sunlight Foundation took that and uses it to power an app and a web presence called Scout. It allows really much more functionality than you would otherwise be getting directly from the government. It allows people to set up a series of alerts and notifications through email or text messaging or whatever works best for them to track the progress of issues that matter to them. To me, it's a very good model of the role of government and the role of third-party businesses or nonprofits who do want to provide cool services to citizens in a way that is very empowering for government data.

Then there is weather data from NOAA at Weather.gov. It's a market success for government. Every citizen now has an expectation that they can pull out their phone and instantly have all the weather data they need.

​The GSA's Digital Services Center offers improved government web services.

API Economist: How has OAuth being adopted in the Federal Government?

Gray Brooks: The Federal Government has well‑instituted security policies in place and those policies are robust enough to address the role of APIs. Existing policy really does work here. Also, what you can see across agencies adopting APIs is that they understand there's not a need for them to reinvent the wheel here so, I would track it with the adoption of OAuth in the private sector as well. What I tell agencies is that the private sector has fleshed this out very well already. It's coalescing around norms and the government should realize that that technology works well.

API Economist: What technology trends excite you most in the Federal Government?

Gray Brooks: Straight‑up API adoption in our agencies is what excites me most. As far as the Digital Government Strategy, for the first time we're on track to provide an aggregate catalog that stays up to date automatically. We are consuming the API catalogs of agencies so that there's one place where a citizen can find all the APIs of government and then start to consume those. That's really cool to me and I find that binary. To me that's something which, once we have that and start growing it out, the game's going to change in a really positive way.

You are also going to see agencies go from experimenting with their first set of APIs to building more applications with APIs that they themselves consume at the presentation layer. That's roughly the same level of effort for building an application as the traditional model of just procuring that application.  Going forward, that's going to allow significant efficiencies and benefits when it comes time to update that program or expand or modify that system. Once we start shifting to a world where APIs are the default, agencies are going to get real benefits from being able to prototype new projects, innovate, and do things very easily because they've put in the effort at the start for APIs.

API Economist: On the subject of device adoption, the Federal Government has traditionally adopted the Blackberry. What about devices such as iPads, iPhones, and Android phones and tablets?

Gray Brooks: Speaking anecdotally, both at the Federal Communications Commission and GSA, there have been first pilot programs, then actual enterprise efforts that allow bring‑your‑own‑device programs. Many agencies are starting to scale out programs where in addition to offering Blackberries, they offer Android devices and iOS in some places as well. There's a lot of recognition that tablets, for instance, have a role in the workplace, and that bring‑your‑own‑device has a role in the workplace. As far as the Blackberry versus iOS versus Android aspect goes, a major underlying component to that is the catalog of apps that's available for each platform. One of the things we're trying to encourage agencies to understand is that the reason for Android's and Apple's success has been because of those app catalogs...and that those apps are made possible by APIs. The more that agencies start unlocking their material via web services, it's going to allow easier and easier consumption of those services through third-party apps, which reinforces a virtuous cycle of lower costs and greater efficiency.

API Economist: What devices and apps do you like using?

Gray Brooks: Just as a personal citizen, I own a Nexus 4 for my phone and a Samsung 10.1 tablet. I also have a Chromebook now. I use my calendar, my email, and maps everywhere. I use Chrome for my mobile browser.

Also, I use Car2Go -  they have a very good mobile experience. I listen to music on Grooveshark. Then, one which is just very fundamental and basic is the Google Authenticator app. For as many of my personal services as I can get to accept two‑factor authentication through that, it's great being able to have, right at my hand, much greater security.

API Economist: Gray, thanks for your time!

Gray Brooks: My pleasure!