Github

Government, citizen developers join forces to build new Federal Register 2.0 Website

Federal Register 2.0The Federal Register has launched a re-design of its Website, federalregister.gov. The new site is XML-based and was developed using open source code (now available on GitHub).

“The Daily Journal of the United States,” the FR is managed by the Office of the Federal Register (OFR) of the National Archives and Records Administration (NARA) and the U.S. Government Printing Office (GPO) and serves as “the legal newspaper of the U.S. government and contains rules, proposed rules, and public notices of federal agencies, as well Presidential documents.”

U.S. Archivist David Ferriero said this about Federal Register 2.0 on the White House Blog:

“Federal Register 2.0 takes into consideration the 21st century user and turns the Federal Register website into a daily web newspaper. The clear layout will have tools to help users find what they need, comment on proposed rules, and share material relevant to their interests. In addition to greatly improved navigation and search tools, the site will highlight the most popular and newsworthy documents and feature each agency’s significant rules.”

The idea for the re-design originated from Sunlight Labs’ Apps for America 2 contest. Developers Andrew Carpenter, Bob Burbach and Dave Augustine from WestEd Interactive built GovPulse.us, “The Federal Register at your fingertips” and won second place. They caught the attention of OFR, who contacted them to help with the official re-design.

A list of new features can be found here and more information about GovPulse and its technology can be found here here.

Video history of the Federal Register and overview of Federal Register 2.0:

Video overview with GovPulse.us developers:

Government, developers need to build a more structured, scalable approach to leveraging technology

The time has come to build a reliable, open platform that allows local governments to post development requirements and give private developers the ability to respond and build these applications for free.

Going a step further, we need to build a free, open source platform specifically for government, making it easier for government to install and implement and leverage plugins or modules for anything from standard contact forms to 311 citizen requests applications.

Fundamentally, we need a central repository for code and a governing organization, private or non-profit, that coordinates specifications and provides a reliable management process for deployment. Additionally, there needs to be sample usage and, ideally, implementation case studies that highlight how government is leveraging this tool and how others can follow suit.

We need a GitHub meets Taproot meets WordPress or Drupal for government.

Matthew Burton’s A Peace Corps for Programmers, comments like Kevin Curry’s recent “We need craigslist for government” tweet and inside open government baseball chatter echo these sentiments.

To date, contests to create killer Web and mobile applications from open data combined with developers with gumption have spearheaded much of the tech efforts. This approach has showed positive results, however, they don’t effectively address a customer-driven approach to product development (see Steve Blank), where the customer (government) defines the specification, instead of developers building applications of no direct benefit to government.

Government must begin to define the specification. Instead of putting it out to bid, government needs to put it out to BUILD.

Government needs to break the mold and take advantage of what Clay Shirky calls the cognitive surplus, leverage the enthusiasm of the civic developer and significantly lower the cost of its technology projects. Government must also move away from a ‘build our own’ approach to technology. This mindset is a waste of time and resources and financially irresponsible.

Sure, there are procurement hurdles around non-licensed software, but many of these can be re-defined, as done in places such as San Francisco, Portland, Vancouver.

Philanthropists or foundations with deep pockets need to step up and support a new organization or a current one truly dedicated to making this happen. Government could also ‘pay back’ with funding of its own, at a significant discount to what it would otherwise pay. Something like this needs sustainable investment and support.

If the private or non-profit sector and government could each eliminate any hurdles and actively engage an idea like this, we’d change the way government uses technology and how it serves its citizens.

Who can make this happen and how do we get started?

OpenGov APIs: Interfacing with Open Government

There has been lots of good talk (and a good deal of action) lately around open government APIs (Application Programming Interface) at events like Transparency Camp, Where 2.0 and on the Twitters.

So, as a prelude to a talk I’ll be giving at eComm next month, I wanted to write a post surveying the landscape of recent government API developments, and also to describe evolving efforts to construct standards for government APIs.

A Rundown of Recent State and Local API Developments

At Transparency Camp in DC last weekend, Socrata – a firm that hosts open data sets for governments – open sourced their API for accessing and querying public data. The Socrata Open Data API (or SODA) is a specification for running queries against public data sets. Currently, Socrata hosts data sets for the City of Seattle and others – code samples for working with the SODA spec can be found on Github.

The Open311 API recently implemented by the City of San Francisco (and being implemented by others) got some well deserved attention at the recent Where 2.0 conference. Other cities are starting to take note, and some (like Edmonton and Boston) look set to be next in line.

One of the early adopters of government APIs – the NY Senate – recently announced a new release for their OpenLeg API, which includes some important new changes. Today the NY Senate remains one of the few (if not the only) state legislative body to adopt an API to open up access to legislative information and proceedings, but other will hopeful soon follow. (Certainly the work done in Albany by NY Senate CIO Andrew Hoppin and his team has opened the door for work on other government APIs.)

That’s a lot of good stuff in just the last few weeks – I’ve probably missed some stuff, but I’m sure there is more to come in the weeks and months ahead.

Towards API Standards

The work being done on the Open311 API, the OpenMuni Project, and certainly the move by Socrata to open source the SODA spec will have significant implications for the open government data movement.

Standards for open data and APIs will make it easier for developers to build things – an app that works for one municipality can work for others if both adhere to a common standard that the app can run against. But they’ll also make it easier for governments to open up their data – standards will offer governments assurance that the time and effort they expend to maintain and publish data or stand up APIs will provide the most return on investment.

The move towards open data and government API standards is an important one that may influence the long-term success of the open government movement.

What’s Next?

As these standards develop, and as more and more municipalitiesstart to embrace open data, we’ll move closer to the idea of government as a platform.

More and more open data will be published by governments in this country and others. These newly opened data sets may be hosted on infrastructure maintained by governments, or by third parties like Socrata. Enterprising governments in different regions or states may decide to team up and jointly host data that is of interest or value to constituents served by multiple governments or jurisdictions.

The applications that allow citizens to communicate with governments and consume public services will increasingly be built outside of government. (By outside, I mean outside the control of government and the government procurement framework.) Governments will increasingly become the collectors and maintainers of data and information and will focus less on building applications that use such data (or contracting for such applications to be built).

The applications built to consume public data and communicate with government will increasingly be designed as multitenant applications, able to service constituents in multiple jurisdictions that adhere to common data or API standards. They will also be built using more open source components and Web 2.0 technologies.

And (hopefully) the ranks of civic coders will continue to swell, as technologists looking to “scratch their own itch” are empowered to make a difference far beyond their own wants or needs.

All hail the transformative power of standards!