White House misses big opportunity with open source push

Editor's Note: GitHub product manager Ben Balter posted multiple comments as part of a ranging public discussion in response to a White House move to establish a new open source software policy. At the request of FCW, Balter condensed his views into this essay, which is also available on GitHub.

In September 2014, President Barack Obama committed to creating a federal open source policy to improve citizen access to software developed by the federal government. On April 11, public comments are set to close on a federal source code policy proposal that initiates a three-year pilot program to make as little as 20 percent of new government software available to the taxpayers who fund it and for whom the software's intended to benefit.

In a world increasingly dominated by the success of open source, requiring that the world's largest producer of code release only 20 percent of its software is a missed opportunity to modernize government.  It also fails to live up to the president's National Action Plan commitments.

Open source as a political and technical imperative

To me -- as a lawyer, a software developer, and a former government technologist -- the question of open source versus closed source when it comes to government software shouldn't even be a question. With a few obvious exceptions for things like national or operational security, if taxpayers fund the creation of software, they should have the right to access that software. This is increasingly true as government agencies automate the traditionally human-based process they use to regulate industry and deliver citizen services each day. When such processes begin to be shielded behind commercial copyright or self-induced bureaucratic necessity, our government quickly becomes a black box.

Beyond these political and legal motivations, there's a laundry list of well-established reasons affirming why government should and the private sector does embrace open source. Open source shifts developers from low-value to high-value work, enjoys a lower total cost of ownership, prevents vendor lock-in, produces better quality software, reduces duplication of effort, attracts competitive talent, and overall, serves as a force multiplier for the taxpayer (or shareholder) dollar.

Imagine the impact of potentially doubling the amount of software freely available to students and startups over the next three years. As the president himself stated in his commitment to creating an open source policy, "[u]sing and contributing back to open source software can fuel innovation, lower costs, and benefit the public."

Open source isn't the next big thing. It's already here

It's no secret that government agencies lag behind the private sector with regard to technology, and the proposed source code policy hesitantly testing the waters of open source is no exception. Open source software isn't a potential fad to be cautiously evaluated as part of a three-year pilot program, nor are the benefits unknown or unproven in large enterprises. Open source is simply how industry builds software today. You'd be hard-pressed to find a startup worth its venture capital funding that isn't based, at least in part, on open source software.  The same holds true of most industry leaders, already embracing open source as a core part of their business strategy, including Microsoft, Apple, Google, IBM, SAP and Adobe to name a few.

The government's proposed open source policy creates a three-year pilot program, whereby as little as 20 percent of new taxpayer-funded software will be made available to taxpayers. It's unclear why policymakers chose this arbitrary goal, other than as a potential compromise between forward-thinking technologists overwhelmingly asking for an "open by default" policy and the bureaucracy's old guard demanding that all code remain proprietary.

"Open by default" is the administration's policy for machine-readable information, so it's unclear why that same standard doesn't apply to information that is both machine and human readable -- namely software source code.  Nor is it clear why source code should be treated differently than other government information that comes with strong transparency and participatory requirements to ensure efficiency and accountability.

Open source has already undergone a two-decade pilot

The proposed three-year pilot program will likely not yield actionable results, at least not beyond those we already know. For one, technology moves too quickly to be evaluated in three-year controlled experiments. By 2019, the inevitable move to open source will be even further overdue, as we're already seeing that shift take successful foothold in the private sector and in forward-thinking government agencies.

For another, the impact of open source is nearly impossible to measure, as successful government open source should give rise to an entire disruptive technology ecosystem. How would one have measured the economic impact of the space race? How does one measure the good will, transparency, accountability, public confidence, or civic engagement participation in open source provides? Even open source's quantitative metrics may be misleading, as a project with more known bugs doesn't necessarily imply lesser quality, and, in fact, often implies the opposite, as bugs are more quickly surfaced and remedied.

Finally, although a move to "open by default" is preferable, even a move to make 50 percent of software open source would serve as a better experiment than 20 percent, as it is unclear if the current goal would be a statistically significant improvement over open source efforts today.

Open source as a vehicle for organizational change

For our country to realize the benefits of open source, several parallel modernization efforts are required, both inside and outside the agency firewall, and in a world of competing agency priorities, the exclusion of those requirements all but guarantees that the pilot's open source efforts will fail.

For one, behind the firewall, agencies must adopt more modern, more open development philosophies and methodologies, even if that code is ultimately never made public. Agencies cannot continue the practice of multi-year, waterfall procurement processes internally, and presume to enjoy the benefits of modern software development (or point to its absence as a failure), just because the resulting code is later published.

For another, outside the firewall, agencies must adopt open source, rather than disclosed source development, release and maintenance practices. If code is so purpose-built as to yield no value beyond its particular use case, or if once released, development teams hold in-person, exclusionary standing meetings to discuss project priorities, the project is unlikely to gain open source adoption, and will only further establish the case for preserving the status quo.

The White House Open Source Policy is an opportunity to fold the map in half, and bring the innovation of Silicon Valley a bit closer to the Beltway. Limiting the impact of open source to a time- and scope-constrained pilot forgoes a unique and long-needed opportunity to modernize government. Whether you're a lawyer, a technologist or just a citizen that uses government services, I encourage you to read through the policy's ongoing and informative discussions, and comment or provide a +1 before the comment period closes on April 11.