Checkbook NYC advances civic open source

New York City Comptroller John Liu is about to do something we need to see more often in government. This week, his office is open sourcing the code behind Checkbook NYC, the citywide financial transparency site—but the open-sourcing itself is not what I'm referring to. After all, lots of governments open source code these days.

Rather, the release of the Checkbook NYC code, planned for this Thursday, is significant because of a larger initiative that accompanies it. Long before the code release, the Comptroller's Office started a serious planning process to ensure that the code could be easily adopted by other municipalities, supported by other vendors, and eventually become a long-term multi-stakeholder project—in other words, the very model that advocates of civic open source always cheer for but only rarely see happen in practice.

I have no knowledge (and do not claim) that this is the first instance of a government agency doing such long-range planning for an open source release. But it will at least be an important instance: CheckbookNYC.com is the main financial transparency site for the largest city in the United States, a city with an annual budget of $70 billion. Giving other cities a chance to offer the same user interface and API support, at a fraction of what it would have cost to build it themselves, is already good news. But it's even more important to show that the project is a safe long-term bet, both for those considering adoption and those considering participation in development.

The steps the Comptroller's Office took are pretty smart and worth examining. (Full disclosure: I'm working with the Comptroller's Office on this release, though most of these plans were laid well before I got there.)

First, some background:

Most cities run an internal financial management system (FMS) of some kind. The FMS manages the city's expenses, revenue, contracts, payroll, and budget, and naturally allows authorized access only. New York City's FMS just exports its non-sensitive data fields on a regular basis to Checkbook NYC—the export is filtered so that any sensitive data never even goes into the public-facing Checkbook system.

Most cities just buy their internal FMS from one of a few major software vendors. The norm right now is that the FMS is proprietary, but of course it has APIs, since many other systems in the city have to interact with it.

So, if you wanted to get other cities and vendors on board with adopting and supporting Checkbook, what would you do?

You'd approach the major FMS vendors and ask them to help build the exporters that would allow their systems to talk to Checkbook, and ask them to contribute in-kind resources to Checkbook maintenance and development—especially to smooth the Checkbook deployment process. That way you'd lower the bar to Checkbook adoption for many cities at one stroke, and at the same time get multiple vendors involved in the code base. The latter is a win because the healthiest open source projects are often the ones with a variety of distinct, commercially-motivated participants.

This is exactly what the New York City Comptroller's Office did. And because export support for Checkbook could become a selling point for an FMS, the vendors readily agreed. Also, on its own, the City started talking to other jurisdictions that might want deploy Checkbook. This creates pressure—in a good way—on the vendors to really get behind the product: they're going to be asked about it by current and potential customers. It's not just about vendors adapting their proprietary systems to talk to Checkbook, after all. It's also about them deciding that offering Checkbook deployment as a service might be a good business to get into.

New York City's release of Checkbook is the opposite of dumping code over a wall. It's a planned effort to seed an open source ecosystem along with the code, and it's a relief from the magical thinking that too often plagues civic open source releases. No one is expecting new Checkbook deployments to spring up like mushrooms after a spring rain the moment the code is open sourced. Indeed, there's still plenty of work to be done to make the code easily deployable by other jurisdictions. The City simply decided that it made more sense to conduct that work out in the open [1].

The reason I call this (perhaps optimistically) "stage two" of civic open sourcing is precisely that absence of magical thinking and the presence of experienced calculation. The Comptroller's Office started out with the assumption that there are many forces working against reuse, and against attracting other contributors to the project, and they set out to methodically address those concerns, with the knowledge that doing so would require some up-front investment and even political risk. I'm hopeful that their investment will pay off for New York City and everyone else—but I'm certain that it is more likely to pay off than just putting the code out there and waiting for cities to pick it up.