Beyond Transparency — 2013 Code for America
Open data programs provide a number of important benefits for governments and the citizens they serve. At the most basic level, these programs provide important insights into government activities—a fundamental ingredient for a well-operating democracy.
In addition to enhanced government transparency, these programs also provide a means for developing new applications and solutions—built on top of the data released by governments—that can be leveraged to deliver public services. These programs also highlight some of the longstanding problems with incumbent processes that are used by governments to procure technology solutions and services and provide insight into how these older processes might be improved.
The concept of “government as a platform”—an idea best, and most famously, articulated by Tim O’Reilly (2010), the founder of O’Reilly Media and a leading proponent of free-software and open source movements—often references the iPhone as an example of a platform done well. The decision in 2008 by Apple chief executive Steve Jobs to allow independent developers to build apps that would work on the iPhone “platform” has made the now ubiquitous device the success that it is. As noted in a 2012 New York Times article by David Streitfeld:
The App Store opened in July 2008 with 500 apps. In an interview, Mr. Jobs laid bare the company’s goal: “Sell more iPhones.” Thanks to the multitude of apps, the goal came to pass. More iPhones... were sold in the next three months than in the entire previous year, and that was just the beginning of the ascent. (Streitfeld, 2012)
The idea of turning a phone into an application platform has since been copied by other hardware and software companies, and it has informed the idea of turning government itself into a platform. Providing public access to government data in machine-readable formats (i.e., open data) is the foundation of the efforts being taken by governments around the world. They are essentially copying Apple’s approach to stimulate innovative new apps and ideas that can run on their government “platform.”
Open government data is at the heart of a change that is taking place in government. Since the inception of the internet and its now central role in how governments deliver services and information to citizens, governments have used data as an input into a finished product delivered by them for those they serve. Open data, for many governments, has now become the finished product that is delivered to its end-users—independent developers who can use open government data to develop innovative and valuable new solutions.
This kind of change in government can be long, complex, and fraught with risks. It requires a rethinking of government’s traditional role of sole solution provider (the entity that builds, or contracts for, the customer-facing components through which public services are delivered) to that of a data steward. A 2012 report by the Center for Technology in Government noted the transformational dynamics created by open data programs:
Open data initiatives disrupt government’s traditional role as holder or owner of the data. In thinking about open data governance, we need to rethink government’s role in relation to the entire set of new stakeholders. One possibility is to characterize government, as well as all other stakeholders, as stewards [of data]. (Helbig, Cresswell, Burke, & Luna-Reyes, 2012, p. 13)
The clearest example of how open government data can be used to encourage the development of useful new applications comes from the world of public transit. There are numerous examples of applications built using transit data released by governments with the GTFS specification, which is an open data format initially developed by Google in cooperation with Portland, Oregon’s public transit agency. While initially designed to allow easy integration of transit data into the Google platform, the GTFS data specification has spawned a cottage industry of new transit apps. Websites like citygoround.org list hundreds of transit apps, many built using GTFS data.
These applications have fundamentally changed the way that riders on public transportation systems consume transit data, as well as the role of transit authorities in relation to how these applications are developed. In the past, the transit agencies themselves would have been the entity that designed, developed, and delivered the apps used by riders to get information—and many still do. However, an increasing number of transit agencies are getting out of the business of developing these kinds of customer-facing apps and are letting the new app market (fueled by the open GTFS data they release) meet rider demand instead.
In addition, some transit agencies—like the Southeastern Pennsylvania Transportation Authority, which serves the Philadelphia area—are now actively advertising apps built by independent developers to their riders.
This fundamental shift away from government as the sole solution provider to a data steward is now taking hold outside the world of transit data, fostering the growth of new ideas and solutions.
Leveraging open data to encourage the development of useful applications and services holds many benefits for governments. With this approach, new ways of building software and deploying solutions are developed without them having to make bets on specific technologies (something that governments do not do well). Independent developers operating outside of the normal government procurement process are often better positioned to leverage new advances in app development or service deployment.
Open government data is one way that governments can, in a sense, go around the traditional procurement process to encourage the development of useful software. However, this approach does have some limitations. Implicit in the idea of open data is the fact that governments can’t dictate what users of the data actually do with it (provided they don’t misrepresent the data or otherwise violate terms of use). Publishing open data and engaging outside developers can be a less-than-effective strategy if governments hope to achieve the development of specific tools or solutions.
The open data approach works best to generate emergent (rather than prescriptive), customer-facing applications that are related to particular kinds of data that have established communities or constituencies of enthusiasts (like transit data). Releasing open data and engaging outside developers to organically develop solutions is not the right approach for the development of all government IT systems. For example, this would be less than ideal for the development of a back-end accounting or financial management system, which requires specialized knowledge of government processes and would likely need to be built to exacting specifications. When governments have specific needs or detailed requirements for how a solution or app should be built and operated, standard government procurement is probably a better way to acquire this technology than hackathons or apps contests.
However, the government procurement process as it exists today is not ideal for acquiring optimal technology solutions that take advantage of the latest thinking on how software and services are developed and deployed. Viewed as cumbersome and complex, the process used by public sector entities to procure goods and services is often cited as a major barrier to introducing innovation—particularly the use of new technologies—into government operations.
Advancing the innovation agenda within government often means confronting the harsh reality of the government procurement process. This is not a new problem, and there are a number of initiatives underway in governments around the country aimed at “streamlining” or “overhauling” the government procurement process to support the acquisition of new technologies and projects that engage smaller and more nimble companies with new solutions.
The City of Philadelphia, in particular, is engaged in some progressive efforts to use the government procurement process as a means to develop an ecosystem of smaller companies that offer innovative new ideas to longstanding city problems. If the goal of using the procurement process to stimulate (or at least not hinder) innovation inside government is to be realized, reformers in Philadelphia and elsewhere will need to face some hard truths about procurement reform.
In addition, advocates of procurement reform must expand their thinking about the nature of reform and their methods to bring about change by focusing on open government data as a foundational component for systematic change in how governments deliver services and information to those they serve.
The arguments in favor of reforming the government procurement process bear a striking similarity to arguments used by advocates for overhauling the federal income tax system. Both sets of advocates point to the problem of unnecessary complexity as an element that can stifle innovation or even harm participants. In many instances, the same verbs are used when calling for reform—words like “overhaul” and “streamline” can be used almost interchangeably when talking about tax reform and procurement reform.
The federal income tax system is a useful reference for talking about procurement reform. It is often used by governments as a vehicle for achieving desired outcomes that (as many economists will quickly point out) have nothing to do with an efficient tax system. We imbue our tax code with certain provisions that, we hope, will help achieve outcomes deemed to have broad societal value.
A perfect example of this is the federal income tax deduction for mortgage interest. As a country and a society, we value homeownership over other kinds of investments, so our tax system “rewards” this investment with a special deduction. The objective is to encourage more homeownership because it is highly correlated with desired outcomes, like higher property values and more stable neighborhoods. This deduction comes with a cost, however: it increases the complexity of tax forms, and it increases the effort required both to process these forms and to audit taxpayer compliance.
There are many other examples of income tax provisions that are specifically engineered to produce outcomes with broad social benefits—a myriad of deductions and credits for married couples, particularly those with children; deductions for contributions made to charities; and deductions for interest on student loans. Each of these examples shares two characteristics: they are designed to encourage specific outcomes, and they increase the overall complexity of the system. On an individual level, the cost of these broader societal benefits manifests as more time and effort to comply with income tax requirements.
Procurement processes are similar in many ways. Governments imbue these processes with requirements and other stipulations that they hope will lead to outcomes that are deemed desirable. Each of these requirements adds to the complexity of the process and the burden of firms that choose to respond to government RFPs.
For example, almost every government has purchasing requirements for minority- and women-owned businesses, and many have requirements that local companies receive preference over firms from outside the jurisdiction. The objective is to drive more government procurement dollars to minority- and women-owned businesses and to local businesses that create local jobs and pay local taxes.
There are also larger, overarching values embedded in the procurement process. For example, fairness and transparency are values that inform requirements like the public posting of bids and related materials, ample public notice of vendor meetings, and the clear specification of when and how bids must be submitted.
Risk aversion is another value that impacts the complexity and cost of the public procurement process. It is this value that informs requirements like performance bonds, vendor insurance, scrutiny of company financial statements, and requirements for financial reserves—all things that seek to reduce the risk assumed by governments from engaging with a company to provide a good or service. Each of these requirements can make the procurement process more complex and burdensome for bidders, particularly smaller companies.
All of this underscores the point that many of the factors that make government procurement processes complex and slow are also things that are intended to produce desired outcomes. These features of the procurement process were designed with a specific intent, and few people would argue with the laudable goals they seek to encourage. Yet, one of the side effects of these requirements is that they make the process slower, more complex, and harder for smaller and more nimble firms to participate in.
Efforts to overhaul or streamline the procurement process will undoubtedly run up against the provisions just discussed. Are there ways to streamline the procurement process that don’t require provisions of this type to be relaxed or removed, or are there ways to relax these provisions without compromising the laudable outcomes they seek to encourage? This remains to be seen.
The great myth in government IT is that the private sector is always way ahead of the public sector in how technology is used.
In between two tours of duty in state and local government, I spent about ten years in the private sector working for both large and small technology firms. Before joining Code for America as Director of Government Relations in 2011, I worked for four different technology companies headquartered in places as different as Horsham, Pennsylvania; Blacksburg, Virginia; and San Francisco, California. I learned a lot about technology and how to be a software developer during this time, but I also learned that—as far as technology is concerned—the grass is not always greener on the other side.
There are plenty of examples of poor technology decisions in the private sector. We just hear about them less often because they are usually not a matter of public record or visible to the public through a budget submission or legislative hearing.
To be sure, governments around the world have issues with implementing technology, but some of the things I’ve seen in the private sector have been shocking—inexcusably bad decisions made by people who should know better, a complete lack of strategic thinking about how technology is used to benefit the company, and dragging old legacy technology along far past its point of usefulness simply because upgrading would be tricky and complex—the list goes on. The private sector has all of these problems and more. We just don’t hear about them as much.
What my experience in the private sector made exceedingly clear to me is that it is entirely possible (and not very unusual) for private sector organizations, unshackled by complicated procurement processes like those used by governments, to make lousy choices and invest poorly in technology.
Simply making the government procurement process “simpler” won’t guarantee that better IT decisions get made. Governments will still need to think more strategically about how they invest in technology and become better at learning how it can be used to make the delivery of public services more efficient and effective.
My experience working as a software developer for several years, and continuing to work with other developers from a variety of disciplines for years after that, has affected the way I approach problems. Whenever I hear about an application or service or an idea someone has for one, I’m often privately thinking (as I think most people who have worked as developers are), how would I build something like that? This is probably true of most people who have built things for a living.
Understanding how things work and how to build them can be a useful skill when evaluating the level of effort required to perform a service or to solve a problem. This is something software developers do often—estimate the amount of time it will take them (or their team) to complete a series of tasks they have not yet begun. It’s hard to do well. Even software developers who do this often will sometimes underestimate or overestimate the amount of time required to complete a task.
The ability to translate a problem into a series of steps that a person can imagine herself doing is the specific byproduct of making things. This is a problem in government, where, in general, there is a woeful lack of awareness about how things are made and what resources and materials are required to build things. In short, there is a critical lack of makers in government.
This problem is particularly acute when it comes to technology and how governments acquire it, even for needs that should be simple and relatively cheap, like content management systems for websites and web-based applications. The web is now an essential component of how governments deliver services and communicate with citizens, and yet, there are far too few people inside government (including those in the technology discipline) who have a solid understanding of how the internet works.
In just the last few years, the world of software development has seen a sea change that has transformed how web and mobile applications are built. Never before has it been easier or cheaper to build these applications. Yet governments continue to overpay for them (or the services of those firms that build them) because there is very little in-house knowledge of how these things are built.
This is not to suggest that effective websites and useful web applications are easy to build and don’t require skill. They certainly do, but without a fundamental understanding of what the technologies behind these applications are, how they work, and how they are changing, governments cannot distinguish the skilled vendors offering reasonably priced solutions from the shysters.
In a way, it’s not dissimilar from the experience many people have when going to an auto mechanic—if you don’t know anything about how cars work, how do you know for sure if you’re getting a fair price? It calls to mind the classic episode from the sitcom “Seinfeld,” where George Costanza sums up the typical approach to auto repair like this:
Well of course they’re trying to screw you! What do you think? That’s what they do. They can make up anything; nobody knows! ‘Why, well you need a new Johnson rod in here.’ Oh, a Johnson rod. Yeah, well better put one of those on!
If the people who work for government don’t have a clear enough sense of how things get made, they are ill-equipped to evaluate RFP responses from individuals or companies that want to do work on behalf of the government. This is especially important for technology procurement, where new software development paradigms can evolve rapidly.
Governments need to place an emphasis on recruiting and hiring people who have experience making things. In addition, governments need to focus on developing the “maker skills” of existing employees. This, by extension, will enhance the ability of governments to evaluate the estimates for work provided by respondents to RFPs.
Government open data programs and the independent apps they help generate provide tremendously helpful ways of fostering new approaches to old problems. They also support the application of new technologies and app development strategies for delivering public services.
However, even the most robust open data program is not a suitable replacement for a well-designed and properly functioning procurement process—one that fosters innovation and the risk that is inherent in it. Open data programs can—and should—complement well-designed procurement processes.
Open data programs have opened the door to new ways of thinking about how public services are delivered. They also help highlight some of the deficiencies in the existing processes used to acquire solutions by government and deliver services and information.
The job of overhauling existing government procurement processes to encourage innovation will not be an easy one, but one of the many benefits of open data is that it has led to this important discussion.
Mark Headd is a writer, speaker, teacher, and thought leader on web development, open government and civic hacking. Self taught in programming, he has been developing telephone, mobile, speech recognition, and messaging applications for over ten years and has deep experience in communication technologies.
In August 2012, Mayor Michael Nutter selected Mark to become the City of Philadelphia’s first Chief Data Officer, to lead the city’s open data and government transparency initiatives. He previously served for three years as the chief policy and budget advisor for the State of Delaware’s Department of Technology and Information, and as technology advisor to Delaware Governor Thomas Carper.
Mark has built open government software applications for the District of Columbia, the Sunlight Foundation, the New York State Senate, and the cities of New York, San Francisco, Toronto, Baltimore, and Philadelphia. He is an organizer, judge, sponsor, and participant in civic hacking events across the country, including Philadelphia and Baltimore.