Lesson in Longevity

Since our time as fellows is a short 11 months, we must be cognizant of how our work can lead to greater impact months, maybe even years after we’ve moved on from the fellowship. We call this “application sustainability,” and together, we came up with a short list of pros and cons to three different categories of development strategies: a “redeploy/reuse” strategy, a “multi-municipality” strategy, and a “single municipality” strategy.

I’ll discuss the “single municipality” strategy first, since this is often the easiest way to tackle a problem: the application is custom-written in a short amount of time to address a specific civic problem, enabling us to quickly demonstrate our abilities to our municipality.

Unfortunately, this method has the lowest potential for application sustainability, as a one-off that loses the benefit of a wider community to maintain the project once it’s complete.

While it’s true that many Code for America applications begin as a single-municipality app, in part because of our need to prototype rapidly within a short development cycle, we can create a better environment for application sustainability with the “redeploy/reuse” strategy, where an app that works well for one municipality could be easily redeployed for another municipality and with little or minimal editing of the code base. Adopt-a-Hydrant, a 2011 project originally built for Boston, is one such app that has been adopted by other jurisdictions, in one case turning into Adopt-a-Siren for Honolulu.

The final strategy, “multi-municipality,” is a service that any municipality can take advantage of without needing to redeploy a separate instance of it, which is easier in terms of staffing on the municipality side. Textizen, for instance, was originally created for Philadelphia but could be used anywhere in the U.S. However, this tends to work well only for general problems that don’t need to connect to existing city services or databases.

Because our municipalities have different challenges and the solutions are still to be determined, it’s hard to predict which applications will pursue which strategy from the get-go. After this discussion, however, we now have a sense of how each of our teams might strategically engineer our projects early on toward a particular framework to create the greatest impact post-fellowship.

Next, Steve Spiker, a co-captain of OpenOakland (a Code for America Brigade) and the research and technology director of the Urban Strategies Council, came in to speak with us about open data and the questions and issues that municipal governments may have in adopting open data policies.

In decades past, “open data” was known as “data democratization” and essentially entailed just putting information online through a web portal. Unfortunately, it proved to be “not good enough” since the information was usually neither helpful nor usable. After a while, open data as a concept evolved out of the open source movement and adopted many of the same principles to improve the accessibility and usability of civic data, making information freely available for others to use, analyze, and connect with other data sources.

But it’s an uphill battle. The default position for many is to close data off, either because they are charging for access or believe that opening data might result in people using it for evil.

And it turns out neither are good reasons for opposing open data. By making that data completely open, a municipality is more likely to make it easier for businesses to start, for affordable housing to obtain funding, for communities groups to engage, or for departments or other municipalities to share information—just to name a few outcomes. The net positives that accrue will be far greater in the long run than a one-time fee for access to data, and it makes politicians look really good when they accomplish a policy that’s basically free to implement.

Hopefully, that’s something we can prove this year!

Questions? Comments? Hit us up @codeforamerica.