The Civic Hacker Hacked

“The countercultural trickster has been pressed into the service of the preppy tech entrepreneur class. It began innocently, no doubt. The association of the hacker ethic with startups might have started with an authentic counter-cultural impulse on the part of outsider nerds tinkering away on websites. But, like all gentrification, the influx into the scene of successive waves of ever less disaffected individuals results in a growing emphasis on the unthreatening elements of hacking over the subversive ones.”

— The Hacker Hacked, by Brett Scott

Ever since I read Brett Scott’s engrossing piece on what he refers to as the “gentrification of hacker culture” I’ve been thinking about how this idea might apply to the world of civic hacking. The lament about the loss of the subversive nature of hacking resonates – Scott repeatedly uses this word in describing the origins of hacking and its focus on being antiestablishment and decentralized.

Read More

Getting More Civic In Our Apps

Uber is not generally characterized as “civic technology” company. But the recent announcement their request API seems like a real game changer to me.

Today, the Uber API team is excited to announce the public release of our Request endpoint. With the Uber API’s initial launch last August, we made it easy to surface information about Uber products within third party applications, but getting a ride always required deep-linking to the Uber app. With the Request endpoint, you can now build applications that incorporate the entire Uber experience.

There are a number of very practical applications that can be built on the Uber platform which have a clear civic value that are now within easy reach of developers.

Read More

Enabling the Enterprise

Its not often that I run across posts about enterprise architecture that get me excited. This one – by Tariq Rashid – did. Very much so.

This issue interests me because its one that, as a former state IT executive and policy advisor, I have personal history with. I also believe its an issue that will have great impact on how successful governments are at redesigning services around users, and embracing civic technology and open data.

Read More

Realtime Open Data

I’ve been thinking a lot lately about data being collected about cities through remote sensor networks.


It’s never been easier to build DIY sensors, and some cities are starting to look seriously at how sensor data can inform better policy decisions and better investment of public resources.

It strikes me that this is a very relevant issue for those in the open data movement, as the data generated by urban sensor networks is likely to be mashed up with publicly available data from cities on crime, land use, service requests and a host of other things to drive better decision making. There’s a natural connection between the kinds of data we find in open data portals and the kind of data that is generated by emerging sensor networks.

Read More

The Collaborative State

“Civic Hacking” is the awareness of a condition that is suboptimal in a neighborhood, community or place and the perception of one’s own ability to effect change on that condition. The apps are incidental.

In 2008, civic hacking was the furthest thing from my mind.

Read More

The Promise and Pitfalls of Government APIs

Fresh off a week in San Diego for the annual Accela Engage conference (where Tim O’Reilly gave a keynote presentation) and some stolen hours over the weekend for hacking together an entry in the Boston HubHacks Civic Hackathon, I’ve got government APIs front of mind.

Getting to hear the Godfather of “Government as a Platform” speak in person is always a treat, and Tim was kind enough to share the awesome slide deck he used for his talk. The chance to follow up on an event like Engage with some heads down time to bang out a quick prototype for the City of Boston was a great opportunity to frame some of the ideas discussed at the conference.

For me, this quick succession of events got me thinking about both the promise and the pitfalls of government APIs.

APIs: The Promise

The thing I love the most about the Boston Civic Hackathon is the way the city approached it. Prior to the event, the organizers took time to clearly articulate issues the city was trying to address. Materials given in advance to participants provided exhaustive information about the permitting process and clearly listed the things the city needed help with. Additionally, a few experimental API endpoints were stood up for participants to use during the event.

These APIs weren’t the easiest to use but they were helpful in creating prototypes that would allow city leaders to see the possibilities of collaborating with outside developers. It should be noted that Code for Boston – the local Code for America Brigade – was heavily involved in the event. This was a smart move by the city to include the leadership in the local civic hacking movement in the event right from the start.


So, out of the gate, this event provided immediate tangible benefits for the city – without even one line of code being written. The city benefits immensely from the time and effort that went into describing and documenting the current permitting system and the many shortcomings it has. This is a process that far too few governments undertake, even when they are crafting expensive and elaborate RFPs.

There appeared to be a healthy level of participation, despite the fact that there was another hackathon happening in Boston on the same weekend, indicating that the message from City Hall was being taken seriously by the local technology community. In all, nine apps (including one of my own) were submitted for review – each of these submissions provides powerful insights for city officials into what is possible when governments leverage the talents of outside developers using an API.

But at the same time, I think this event helps to highlight some of the pitfalls that governments (particularly municipal governments) face when deploying APIs and moving towards government as a platform. These challenges can derail efforts to collaborate with local civic hackers to improve the quality of services that governments provide, so its important to understand what they are.

APIs: The Pitfalls

To it’s credit, the City of Boston took steps to create new APIs for it’s legacy permitting system – to allow civic hackers to create prototypes that can help illustrate what is possible. And, as it turns out, a good people want to take them up on this.

Boston is one of the most progressive cities in the country when it comes to engaging civic technologists. But building and managing a custom API can be a challenge for any government and it is an endeavor not to be undertaken lightly. In addition, along with the new role of managing a production-grade API for external development, governments face the relatively new challenge of building and managing developer communities around them. To put it lightly, this ain’t easy – particularly for governments that haven’t done it before.

It looks like Boston’s current vendor doesn’t supply a baked-in API for their permitting system, so the city stood up a few custom endpoints for developers to work with over the weekend. This is a great approach to support a weekend hacking event, but if the city is serious about coaxing developers into investing time and money building new civic apps on top of an API, the demands can increase dramatically.

Production APIs done right require stewardship – this includes ensuring adequate reliability, authentication, versioning and a host of other things that building a demo API does not. If developers perceive that an API is unstable or lacks proper stewardship, they won’t invest the time building services that take advantage of it.

Another potential issue for Boston is that – even if they are able to create and manage a robust API for developers – the API for their permitting system will likely differ from the APIs of other cities. So, they may not be able to leverage talent outside of those interested in building an app specifically for the City of Boston.

The more that cities can share common platforms and APIs, the more they can amplify the benefits of collaborating with outside developers – an app built in one city can more easily be deployed to another, making the benefits to developers that build apps exponentially greater.

It’s great to see the City of Boston actively organizing hackathons to solicit ideas for how government service can be improved. I hope this event, and others to come, can help focus attention on the significant issues governments face in developing and managing open APIs for civic hackers.

Turning Governments into Data Stewards

The civic entrepreneurs behind Open Counter recently launched a new service called Zoning Check that lets prospective businesses quickly and easily check municipal zoning ordinances to determine where they can locate a new business.

This elegantly simple app demonstrates the true power of zoning information, and underscores the need for more work on developing standard data specifications between governments that generate similar kinds of data.

In a recent review of this new app, writer Alex Howard contrasts the simple, intuitive interface of Zoning Check with the web-based zoning maps produced by different municipal governments. Zoning Check is obviously much easier to use, especially for its intended audience of prospective business owners. And while this certainly is but one of many potential uses for zoning information, it’s hard to argue with the quality of the app or how much different it is than a standard government zoning map.

But to me, more than anything else, this simple little civic application provides an object lesson in the need for governments to invest less time and resources building new citizen-facing applications themselves and more time and resources mustering the talents of outside developers that can build more effective citizen-facing apps better, faster and cheaper.

To do this, governments need to reimagine their place in the civic technology production chain. In short, governments need to stop being app builders and start becoming data stewards.

There are a number of reasons why the role of data steward is a better one for governments – most importantly, governments don’t typically make good bets on technology. They’re not set up to do it properly, and as a result its not uncommon to see governments invest in technology that quickly becomes out of date and difficult to manage. This problem is particularly acute in relation to web-based services and applications – which outside civic technologists are very good at building – because the landscape for developing these kinds of applications changes far too rapidly for governments to realistically stay current.

Governments that focus on becoming data stewards are better able to break out of the cycle of investing in technology that quickly becomes out of date. It is these governments that are moving to release open data and deploy APIs to enable outside developers to build applications that can help deliver services and information to citizens. But in addition to procurement and recruitment hurdles that make it difficult for governments to get the technology of citizen-facing apps right, governments may also lack the proper perspective to develop targeted applications that expertly solve the problem of a specific class of users.

The truth of it is this – even if the processes by which businesses find out where they can locate, and what permitting and licensing requirements they need to comply with are terrible, there typically isn’t much they can do about it. Government’s lack proper incentives to get apps like this right because no one is competing with them to provide the service. If government’s change their role to that of a data steward, they can foster the creation of multiple apps that can deliver information to users in a much more effective way. Assuming the role of data steward would set up a competitive dynamic that would foster better interfaces to government information.

Look at what happened in Philadelphia when the city released crime data in highly usable formats – the city went from having one mediocre view of crime data that was developed with the sanction of the city to having a host of new applications developed by outside partners, each providing a new an unique view of the data that the city’s app simply did not provide.

The city even incorporated one of the apps built by outside developers into the official site for the Philadelphia Police Department.

Zoning Check is a great app to help center this conversation, and highlight the benefits that governments can reap if they work to transition way from being app builders and towards becoming true data stewards.

The Hacker Ethos and Better Cities

The thing I’ve always loved about hackathons is how they make it possible for anyone to build something that can help fix a problem facing a neighborhood, community or city.


Going to a hackathon isn’t like going to a government-sponsored meeting, or legislative hearing – those are places where people offer testimony to others, who may or may not take the advice given and implement some policy or legislative action. Hackathons are where people go to build actual solutions that help fix real problems.

The hacker ethos attracts people who don’t like layers of bureaucracy between the problems they see around them and the solutions that want to implement. We live in a time when it has never been easier for people without title, station or office to affect real change in the lives of people in their neighborhoods – to build solutions to fix problems they care about. This is an attractive draw for people that want to make a difference and its why the number of hackathons has grown in recent years, and continues to grow.

I see these same sentiments in an exciting project developed by Kristy Tillman and Tiffani Bell. They built the Detroit Water Project to help Detroit residents in danger of having their water service cut off get paired up with people that can make a payment (or partial payment) on their behalf.

This is the kind of project I would expect to see at a hackathon – it has very few rough edges but looks like it was put together rapidly. It effectively leverages powerful, cheap online tools like Google forms and social media to engage with people that want to get involved.

And it is absolutely brilliant in its simplicity and effectiveness.

Here’s the elevator pitch – there are folks in the City of Detroit (a city facing significant challenges) in danger of having their water service cut off because they are unable to pay their bill. This is an issue affecting thousands of people in real need and galvanizing a movement to help prevent it. The Detroit Water Project enables people anywhere in the country to help with just a few mouse clicks and at the cost of a night out on the town. Boom.

This is how people with the hacker ethos want to invest their time, talents and energy. They are surfacing the question that more people need to step up and help answer – are we going to sit by and let cities like Detroit crumble, or are we going to get off our asses and pitch in?

This project wasn’t built at a hackathon, but it’s everything a hackathon project can be (and should be). Kristy and Tiffani are hackers – and I mean that as the highest compliment I can pay someone.

This is how our cities are going to get better.

[Note – water icon courtesy of the Noun Project.]

Making Room For Science

Interesting things are happening at Philly Hackathons.


Increasingly, participants at local events are opting to work on what would best be described as “citizen science” projects – projects not focused on the development of an app as a final product, but where an app or device constructed at the event is the means to a loftier end.

The goal of these projects – a better understanding of how our city works and ways that we can improve it. Some great examples of these citizen science projects being worked on by Philly hackers are:

Project GreenSTEM – Originally developed as part of last year’s AT&T EduTech Hackathon, this project is focused on the development of an Arduino-powered urban sensor network. It’s currently being integrated into the curriculum at four of Philadelphia’s public schools.

CyclePhilly – Though this project is centered on an app, the ambitions of its sponsors are as big as the Delaware Valley. The goal of the project is to get as many bikers as possible to use the app to generate data on how they travel, which will inform planning decisions made by the City of Philadelphia and the Delaware Valley Regional Planning Commission.

Climate Tracker – Another mobile sensor network project, this one is focused on bus-mounted devices that will collect climate and air quality information from around Philadelphia. The data generated will be used in conjunction with other data sets to inform both citizens and researchers.

These citizen science projects still make up a minority of the things worked on at hackathons and local hack nights, but understanding why participants are opting to work on them can give us insights into how we might alter the structure of hackathons – to make them more effective and to help ensure the work being done at these events is sustained over the long haul.

Opting for Science

One of the unifying characteristics of the project listed above is that each is focused on the generation of data – data that can be used by others to make better decisions. The apps and sensors developed as part of these projects are incidental to a larger, more important goal. Generating data that can be used as part of scientific or administrative processes.

This is a fairly dramatic departure from the usual app-centric focus of hackathons.

The reasons that we are seeing more citizen science projects turn up at hackathons is the result of a couple of different factors. First, the availability of cheap, powerful microcomputers and sensors technology. Products like Arduino, Raspberry Pi, BeagleBone, Ninja Blocks others are making it incredibly cheap to obtain, work with and create powerful new devices.

It’ also becoming easier for mainstream programmers to start to work with hardware, robotics and other kinds of physical device technologies. These developments are putting pressure on the traditional structure of hackathons, which are set up to produce apps.

Most hackathons are set up to run over a specific period of time – much like a sprint in agile software development. And many of the conventions used in hackathons (like demoing a workable prototype at the end) conform to the practices of software development methodologies like Scrum. (This isn’t surprising since hackathons originally came out of the world of software development.)

In short, hackathons are almost always structured in a traditional way – one designed to deliver apps, not citizen science projects. So the fact that we are starting to see these projects developed at hackathons despite the structural bias toward apps is noteworthy.

Making Hackathons Better

So what do all these citizen science projects tell us about how we should structure hackathons going forward – in short, we need to make room for science.

We need to rethink the typical weekend hackathon and the focus on building narrowly focused apps. We need to find structures that support the development of different ideas with longer term goals, that may not have a finished app that can be loaded in a web browser or pulled up on a mobile device at the end of a weekend. We need to encourage projects that are focused on collecting data, from all over our city, that can help us better understand how it works – data that can be used by others to conduct research, or build apps of their own.

This is starting to happen in Philly, and in other places as well. One notable example here is the upcoming EcoCamp event being sponsored by Azavea. It features a hackathon that is paired with an unconference and workshops – a pretty cool idea that I hope leads to some interesting citizen science projects. Code for Philly’s weekly hack nights have also been instrumental in helping these science projects move along the path to viability as well – another reason to love (and support) your local Code for America Brigade.

This doesn’t mean that the standard weekend hackathon for building apps is going away. Just that we need to think clearly about the kind of events we want, and what we hope to get out of them.

Looking forward to more hackathons in Philly, and more citizen science projects.

APIs : To Charge or Not to Charge

There’s a discussion starting on the U.S. Government API Google Group on the subject of charging for the use of government APIs.

This is an interesting discussion (one that governments should pay attention to as they develop their API strategies) and is a nice follow up to my last post on sustainable civic technology.

Clearly the decision about whether to charge users for accessing an API – whether to query an open data source, or to conduct some transaction with government – is one that each government needs to come to on their own after factoring in the potential benefits and consequences. But there are at least a few economic reasons that governments might want to consider whether charging for access to APIs makes sense.

I don’t have any definitive answers here, but I think there are a few questions worthy of further discussion.

Identifying who is using government APIs

In economic parlance, public goods are characterized by two different factors – “rivalry” and “excluability.” Rivalry refers to the idea that some goods can be consumed simultaneously with other consumers without a diminished experience. Public goods are those that I can enjoy myself along with my neighbors and our simultaneous enjoyment of such a good doesn’t diminish the experience for any one of us, or anyone else.

Excludability refers to the idea that consumers of a good can be identified with relative ease, and that their consumption of a good may easily be conditioned on something. Such goods are often referred to as “toll goods” and the most often cited example of such a good is a toll road – a turnpike or highway.

Its fairly easy to restrict access to a toll road and condition the use of the resource on paying a tool (that’s what toll booths are for). This arrangement has the additional benefit of directing the cost for building and maintaining the resource on those that are actually using it. People that don’t drive aren’t subject to tolls, and there is a pretty strong argument that they shouldn’t be (because they’re not consuming the resource).

It’s also fairly trivial to restrict access to a government API by requiring an API key or other credentials. Because API consumption shares much in common with the consumption of other toll goods, is there a justification for governments to charge for access? How strong is the argument that the cost to build and maintain the infrastructure behind APIs should be borne more directly by those that actually use them?

APIs as a shared resource

Another rationalization for charging for the consumption of certain goods and services is that price is an effective way of rationing a scare resource. APIs – particularly those that expose open data – are fundamentally different than something like a static data download. APIs are shared services with finite resources – my use of an API has the potential to impact other users of an API, depending on how I consume it.

Is it fair to allow one user, or a few users, of an API to potentially diminish the experience of other users by using it with enough frequency to impact performance? Even the most elegantly and expansively engineered APIs have limits – is price a way that governments can help ensure responsible use of an API?

It’s worth noting that many SaaS and PaaS service providers offer a free tier for relative less intensive use of their platforms or APIs, and charge users at different levels based on the amount of usage for what is essentially a shared resource. Is this an approach that governments should emulate?

Sustainability of IT infrastructure

Ultimately, if and how a government employs a fee structure for access to APIs should be connected to plans for long-term sustainability of the IT infrastructure support the API. As I’ve said before, far too often governments do not budget properly for the long term care of IT assets.

Could charging for access to government APIs generate a reliable revenue stream to help ensure resource for upkeep, maintenance and improvements to the systems behind these APIs?

At a minimum, governments should consider deploying a test environment for their APIs. If governments charge users for access to their APIs, they should allow new users and developers to experiment and build new apps without incurring costs, until they are ready to go to production.

I think a far more interesting question for governments is how many are deploying test environments that allow users to build new things without impacting production users. This is an area that I think many governments should spend some time exploring as they develop their API strategies.