Last month, the Consumer Financial Protection Bureau (CFPB) released two statements summarizing their software policies:
The first sentiment dominates the discussion around open source and the civic sector: How can governments leverage open source tools in their operations? An April 2010 study by the Center for Strategic and International Studies surveyed government open source policies “as reported in the press or other media” and found 354 policies. The results are shown on the map below, categorized by region and progress—approved, proposed, or failed (click on region marker to display totals).
But it’s the the CFPB’s second statement that is truly groundbreaking. I propose three reasons that every country, city, and state should follow CFPB’s lead and make customized IT solutions publicly available.
First, open models can produce better products. The current products of large IT procurements are too often bespoke, closed, and expensive. With the rise of Code for America and a growing community of civic technologists, government can engage citizens to produce better products. As Eric Raymond put it, "Given enough eyeballs, all bugs are shallow." A github account for every city and state agency would create an opportunity for hacker-citizens to participate in improving government at almost no cost.
Second, since taxpayer dollars are used to create source code, the taxpayer should have access to it. Just as many governments proactively release data and information to the public, so should they proactively release their code to the public. This may seem scary—governments operate under heightened scrutiny and critics have ways of repackaging mistakes as scandals. Code, however, should be thought of as just another type of public record that, like all records in the public domain, are open to scrutiny.
Finally, positive network effects occur when one entity’s use of a good increases the value of that good for others. For an example, Wisconsin is currently procuring a new student information system. If the state required the developer of that system to release it under an open source license, each consecutive city or state that needed a similar tool could save millions by adapting WI’s tool for their own use. Better yet, Wisconsin would not have had to spend so much on a new system if another state released the bulk of their code for an existing similar system.
There is no compelling reason for most government software to be closed source. IT contracts are often customized solutions built by large developers or consultancies and could easily include public access provisions. Ottawa-based Getting Open Source Logic Into Governments (GOSLING) argues that because of redundant development, the Canadian government spends “$1.5 billion buying software that could cost only a third of that.” The amount of unnecessary expenditures in larger national governments is likely even higher. Governments could share and adapt solutions, thus driving down the costs for the entire civic sector.
Zac Townsend is co-founder and Executive Director of OpeningData.org
I love the idea. Two practical questions, though.First, and most simply, I assume there are areas of government for which this proposal would not be suitable. National security, e.g. Have you given much thought to those sectoral boundaries?Second, and more fundamentally, wouldn't this proposal drop the bottom out of the public sector software industry? That is, wouldn't it mean that any given software solution could only be sold once, since it enters the public domain as soon as the sale's completed and every other potential customer will just adopt the open-source version?
Post a Comment