The missed opportunity that is the White House Open Source Policy
A modified version of this post originally appeared as an Op-Ed on FCW.com.
In September 2014, the president committed to creating a federal open source policy that improved citizen access to software developed by the Federal government. I wrote back then about what I was optimistically hoping to see. Today, public comments close on a federal source code policy that initiates a three-year pilot program to make as little as 20% 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 releases only 20% of its software is a missed opportunity to modernize government that fails to live up to the president’s National Action Plan commitments.
Open source as a political and technical imperative
As a lawyer, a software developer, and a former government technologist, to me, when it comes to government software, the question of open source versus closed source 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 its benefits unknown or unproven in large enterprises. Open source is simply how the 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, and 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 proposed open source policy creates a three-year pilot program, whereby as little as 20% 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. While “open by default” is the administration’s policy for machine-readable information, it’s unclear why that same standard doesn’t apply to information that is both machine- and human-readable, namely software source code, or 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 not likely yield actionable results, at least not beyond those we already know, and merely punts an inevitable decision to the next administration. 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% of software open source would serve as a better experiment than 20%, 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, and for the open/closed bake-off to be representative of each development model’s potential, 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 unduly delays 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 
before the comment period closes later today.
If you enjoyed this post, you might also enjoy:
- Why open source
- 19 reasons why technologists don't want to work at your government agency
- The difference between 18F and USDS
- Five best practices in open source: external engagement
- The three biggest challenges in government IT
- Eight reasons why government contractors should embrace open source software
- Twelve tips for growing communities around your open source project
- A White House open source policy written by a geek
- Everything a government attorney needs to know about open source software licensing
- Why you probably shouldn't add a CLA to your open source project
- Four characteristics of modern collaboration tools
Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →
This page is open source. Please help improve it.
Edit