Dreaming Bigger in the Civic Technology Movement
A vibrant technical community has recently coalesced around creatively solving civic problems. Code for America is just the best example of the burgeoning group of organizations building well-designed, well-executed, and modern web or mobile apps that solve civic issues. Apps for Democracy, BigApps in New York City, and other App competitions, as well as hackathons, have all engaged developers and designers in engaging social and civic data, while Boston, San Francisco, and Philadelphia have led the way in building mobile and web apps to engage citizens outside the traditional information technology structures.
Yet, despite their promise, these applications are often at the periphery of government services and citizen need. Of course we should know where our children’s school buses are, whether our streets have been plowed, and what vacant properties exist in our cities. But, though useful, these tools are small fry. The civic technology movement can – and therefore must – dream bigger, and attempt to remake how technology is used in the core functioning of government.
Before I explain two complementary paths toward remaking technology in government, let’s look at the purpose of technology in government, and the current path toward building and using it.
Technology in government should serve one of two purposes: it should either improve the services that government provides its citizens, or it should more efficiently (i.e. more cheaply) provide those services. The difficulty is that while technology is core to the business of government, it is not core to the mission of government (a description I first heard from Brett Goldstein). To the outside observer, it isn’t obvious how a dollar spent on technology could also be a dollar spent on supporting low-income families, or putting more police on our street.
So how do local governments procure technology? They do one of two things. On the one hand, cities can purchase a closed-source, proprietary solution from a large vendor, who then charges them to service the system, to upgrade regularly, and to customize the solution to the city. On the other hand, cities can either procure, or deploy internally, development resources to build a bespoke solution. In either case, the resultant systems often will not use cutting-edge technologies or best practices in service delivery. They are closed-source, expensive, and lack the user-centric or agile approaches that permeate the private IT sector. This current technological ecosystem has led to interoperability problems, legacy systems up to thirty years old, and a service sector dominated by large players with little incentive to innovate. As a result, technology is often – and unnecessarily – the bottleneck to implementing innovative or best-practice non-technological ideas in government.
This ecosystem is unacceptable, and must be disrupted. Not at the edges. Not through relatively superficial apps. But through holistic change.
Every local government has some core technology systems – systems like human resources, budgeting and financial, customer relationship management (often based around 311), contract management, legislative, asset and property management, tax assessment and collections, and others. All are currently procured or built by each local government separately and at great expense, diverting resources away from critical services.
I propose two paths forward to disrupt the ecosystem: combined purchasing power through standards, and an open source suite.
Despite the fact that cities ultimately need many of the same systems, we currently purchase our software separately and without coordination. One option is for a collection of cities across the country to draft and agree to a set of core principles in government technology that includes interoperability and some standard of openness. Crucially, if this were coupled with a commitment from the Mayors of those cities to procure most of their technologies based on which products best met these principles, and to write these principles into most requests for proposals, then the ecosystem would begin to shift. It would take time, but the combined purchasing power of ten or fifteen large cities would slowly shift technology in government in a direction that better favors the consumer – that is, us. Standards are a viable, low-cost, low-commitment path forward. Complete change would take time – maybe decades – but standards would likely lower costs and improve services quickly, benefits that would only increase over time.
To jump-start civic innovation in core government systems, a suite of open-source software should be created which has components that address each of the systems I listed above. This suite should be designed from the start with a citizen-centric view. It should have open data and transparency at its core. It could have best practices built in. It could allow any city to share code openly with other cities, and for upgrades to be propogated—for free—to cities based on others work.
Ideally, a collection of foundations and private funders would invest to have these systems built. Two or three small- or medium-sized cities could serve as pilot sites, and some minimal viable versions of the entire suite should be built. Initially, the suite should be built not to integrate with legacy systems, but as a complete suite of alpha products. The pilot cities would agree to switch completely over to the new system on a specified day. This wouldn’t be possible in New York, San Francisco, or Chicago, but the suite could easily be launched incrementally at, for example, alpha.newark.gov and then one day there could be a complete switchover. These products could be built with an agile software development approach, where one iterates quickly through newer versions over weeks or months instead of years. Ultimately, there would exist a complete open-source suite that any government could implement as its core IT systems.
To steal an analogy from my open-source advocate friends, think of a plumber. You hire a plumber because he’s a skilled worker, not because he builds you a custom pipe system. It would be foolish to have your own unique pipe system. One still needs to hire someone to fix and improve the plumbing, but there is a basic system from which all plumbers are working. Just as standardized pipes are the basis of a thriving private plumbing sector, an open-source suite would not curtail private companies or the excellent work of skilled civic servants in information technology. Rather, by investing in building a common core set of applications, foundations and private funders would be building a pipe system that all cities could use at lower cost, built on the bedrock of best practices and modern IT standards.
Zac Townsend is Senior Technology Policy Adviser and Mayor’s Office Fellow in Newark, New Jersey. The opinions reflected in this post are his own.