This is Part II of a three part series. In Part I, I briefly motivated Open Government and Government as a Platform, and used Madison Metro as an example of how we could do better. Unfortunately, we’re not doing much better elsewhere in the city, but there are ways to change that.
The application that perhaps most of the readers of this blog are familiar with is Legistar, our public process tracker. Legistar, I suppose, is better than nothing, but it is sort of a piece of shit. Slow, clunky, and ugly, it has limited features and state-of-the-art search, if today was 1997. It has only been recently that it worked really at all with my Mac, and it is completely useless on an iPhone or iPad because its scroll controls are broken. Its default view is unreadable, unless you switch to ‘print view’. There is an inexplicable schizophrenia between item discussion data sometimes being in meeting minutes and other times being in Legistar itself. (Lord help you if it’s Legistar, or at least pray for good vision.) Basic features that should be standard after about 2003, like an RSS feed for individual items are far beyond anything that I would expect, and I would be dreaming if I wanted things a little more close to best practices, like commenting directly on an item or finding links that point back to the item across the Internet (like, “what newspaper stories reference it?”). Worse, it doesn’t appear that there is anything in the way of an API exposed, so even if I wanted to build a real system on top if, I’m in for a world of hurt.
Madison Report-A-Problem is much better, but still not great. The list of different problems you can report is good, and they collect most of the information that you might want, but there are some oddities. Some comment fields are character limited, others are not. There’s no way to add any extra information, like uploading a picture or video.
The real problem is what happens to the data after the report is made. After a large snowstorm, it’s probably safe to assume that there will be a number of reports of inadequate snow removal. A few years back, after a similar run of bad snowstorms and poor snow removal, there were a rash of problem snow reports. One of the TV stations asked for a list of reports that had been made, and being curious about original source documents, I asked for a copy too. City staff was courtesy in their reply, and gave me the list that they had pulled, but it was a bit of a challenge for them to assemble the data in the first place, and I felt bad and never asked for updated information. However, I’d love to see updated information – are certain areas being plowed well? Do different property management companies do better or worse than the norm? After a report, do future snow removals go better or does one report predict that there will be more reports? How many reports are duplicates?
Looking forward, I’m not any more hopeful. The next “big thing” in City software is the ELAM system, or the Enterprise Land and Asset Management system. Alder Mark Clear assures me that it can do some cool stuff, but when I asked about raw data and APIs, he wasn’t so confident. The City is buying ELAM from a company in California named Accela. Their website is here and this is their Twitter stream. Their Lead User Experience designer has a website with a portfolio. Looking through their website and Googling a bit, I don’t see much in the way with regards to things like “APIs” or data exports. I’m afraid we’re buying another monolithic piece of software that’s not meant for people to build on top of it, though I’d be very happy to be wrong.
There is a better way. When buying these enterprise software systems, we can insist on API access and open standards as a condition for consideration. As an example, look at SeeClickFix, which we could use as a replacement for ReportAProblem. Just from a user experience standpoint, it’s about a billion times better than ReportAProblem, or even any of the screenshots I’ve seen of ELAM. (Think Hotmail 2001 versus Gmail of today, or Geocities versus Facebook of today.) Not only that, but they offer an API and raw data, and even more importantly, support the emerging Open311 Standard.
311 is one of a series of standard N-1-1 three digit phone numbers – the most famous of course being 911 for emergency services, followed by 411 for directory assistance. 311 is typically non-emergency government services, though as you might expect much of it can be just as easily handled over the web.
Madison built its own ReportAProblem website, or it could have bought SeeClickFix – or any number of other Report an Issue website packages. But imagine if you want to build an application that interfaced with whatever Problem Reporting website we buy, and you want it to work with multiple cities. You’d have to build it specifically for each city, and if the city ever changed software, you’d have to rebuild it. The Open311 Standard is an API that all of the software vendors have agreed to support, so an application for one city’s system will work with other cities. This is important, because Madison should be able to bring in applications that other cities may have developed for their citizens without having to completely rewrite them, and it should retain the freedom to switch to other software vendors. If Madison completely relies on a single software provider for much of its operations, we run a real risk of being trapped with that software vendor and limited by its whims. The issue of Who Controls The Smart Cities is real, and affects not only the financial bottom line, but also the privacy and livelihoods of our residents.
The Open311 standard is not just a couple of folks selling snake oil; it has the backing of the White House.
Of course, we may not always buy our software. Occasionally we build our own, like the ReportAProblem website. Other cities might make the same decision, and might they build their own software to accomplish the same goal. A logical question to ask: can we all work together and stop duplicating work? Not surprisingly, the answer is yes.
Civic Commons is an exchange where cities can work together to find a common “Civic Software Stack.” Taking a cue from the Open-Source world, they hope to make high-quality civic software available to all cities and citizens, reduce costs, and improve quality. In their own words:
In the face of budget crises, government entities at every level must cut costs and find efficiencies. An enormous opportunity lies in their IT infrastructure — the technology they require to provide their citizens essential services. For the most part, each city, county, state, agency and office builds or buys their technology solutions independently, creating huge redundancies in civic software and wasting millions of tax-payer dollars. They should be able to work together. An independent non-profit organization, Civic Commons will help these institutions share code and best practices, reform procurement practices, and learn to function not only as a provider of services but as a platform to which an ecosystem of industry can add value for government and its citizens.
CivicCommons is only five months old, it already has the backing of the New York State Senate, which is often raved about as the best citizen engagement and transparent website of any state legislative body, and the Enterprise Addressing System from the City of San Francisco, which is a system for “managing the city’s master database of physical addresses, tied to Assessor’s parcels and the City’s street centerline network.” (Admittedly, it may not work for Madison or anywhere else, depending on how hard it would be to get it to work with our Assessor and street database.) I don’t know if Madison has any software that it can share through Civic Commons, but we should definitely be searching there first when we look to implement new software.
Finally, what should we do if we look to Civic Commons but don’t find a system that matches what we need? Well, we could buy one, or we could build one – and if we build one, we should look for some help, and turn to Code For America. In their own words:
Code for America was founded to help the brightest minds of the Web 2.0 generation transform city governments. Cities are under greater pressure than ever, struggling with budget cuts and outdated technology. What if, instead of cutting services or raising taxes, cities could leverage the power of the web to become more efficient, transparent, and participatory?
Code For America is closely related to CivicCommons, but actually precedes it. Code For America is meant to create apps and systems for cities – which then, if it makes sense, could be deposited to become part of the Civic Commons. The name is meat to evoke Teach For America, and the process is similar – some exceptional talent applies to be part of the program, and CfA matches them with host cities.
The competition is two parts: first, cities apply to be part of the program. In 2010, four cities were selected: Boston, Washington DC, Philadelphia, and Seattle. The cities were selected on the basis of project proposals – what did they want CfA to come do in their city? Second, 20 “fellows” were selected – I assume it will work out to 5 Fellows per city. They spend some time in their “host” city, and spend time developing applications back at CfA headquarters. The projects are fairly audacious: Boston is building a platform for Educational Services, Seattle and Philly on large neighborhood engagement project.
This isn’t a project that they funded, but they included it as a sample project to get people thinking:
The Urban Forestry Department of a major US city is facing significant budget cuts. How do they continue to maintain the same number of trees on a smaller budget? Because the trees must be pruned and watered on particular schedules, it has up until now been too cumbersome to ask citizens to take on some of the care of the trees near where they live, and the incentives of citizens to do so has been unclear. But the city keeps detailed records of the maintenance schedules for each individual tree in their care, and it’s now relatively easy to publish that data in a format that citizens can access. Code for America imagines a combination web app/mobile application that lets citizens look up any given city tree and either report back data about the tree’s condition or take the prescribed next action (watering, pruning, etc) and report that back. Citizens could earn badges or points for their actions, become “mayor” of certain trees, brag about their service on Facebook or any other social network, and even tie into a rewards system supported by the city. Every tree that is adopted, even partially, by a citizen, would represent a savings to the city’s urban forestry department.
The application process for 2012 cities is opening now, and Madison should consider applying. It’s not a dead-simple good idea, and we should think about it before we apply. First, there’s the cost: $250,000. Now, that goes to cover the salary cost of the fellows, and I assure you, if the 2012 class is anywhere near as good as the 2011 class, for basically five Full-Time-Employees of their caliber it’s a hell of a bargain. Then, there’s the question of what do we ask this team to do? I could suggest the EDC development proposal contact tracking software, and I’ll come back to it later in part III. However, we need to have a good idea of what we’d like our application to include, and we need to have that discussion as part of a community. As cool as the Tree Example above is[2], and I’d love to see something like it in Madison, I have a hard time seeing how I’d talk anyone into spending $250,000 on “FourSquare for Trees.”
Then, the really hard question – how do we prepare the city to actually do this? Do we have a culture in City Hall that would allow a cutting edge Gov 2.0 project to go from conception to deployment in 9 months? I still haven’t met Paul Kronenberg, the “new” IT director, but his council questioning on Web 2.0 makes me nervous, but I like to think that the city has a good track record of hiring smart people who can grow quickly in their leadership roles. Finally, we have a Mayoral election in April, right after the application is due. Is this a priority with Cieslewicz? Would it be a priority with Soglin?
The applications are due on March 1st. I think we have the civic capacity to pull this off: Capital Entrepreneurs, Mad-Tech, DaneNet, Sector67, the MadFiber Cabal – there’s community out there that gets it. On the EDC, Younkle and (I think) Clarke get it, as do Alders Clear and Schmidt, and add Rhodes-Conway once you get to the full Council. We could of course, wait a year and apply for the 2013 cycle: that would give us time to really evaluate how the 2011 cycle worked all the way to the end, and a better sense of how the 2012 cycle is working. But I’d rather us go for 2012, as a point of pride. Madison is a city of leaders, and that means getting things done, and taking some risks.
The way to get started is to have a discussion about what we might want to see as a project or end result. Code for America would likely help us start this discussion, too, and they have a few broad themes of project ideas they’d like to fund in 2012 –all things that I believe line up nicely with Madison’s goals. I have a few ideas, too, which will be in Part III.
[2] Or, as simpler example, SFTrees – an app from San Francisco, which puts the SF Tree Map on a mobile phone, and uses GPS to tell you what type of tree you’re looking at.
