It’s not uncommon for government agencies to contact GitHub, looking for advice on how best to “publish” government-funded source code for “consumption” by the open source community. While a necessary and admirable first step, efforts to “release” source code, in reality, often fall short of actually being open source.
The argument for open source in government is well documented, but open source is about more than having access to the software’s human-readable code. Open source is a philosophy, a workflow, and most importantly a collaborative community, the basis of which is the opportunity to participate.
Government agencies and individual developers are free to make their projects’ underlying source code available for others to review, inspect, or reuse as they wish. This can be as simple as posting a zip file to an agency-owned FTP server, responding to a FOIA request by email, or even posting the source code to a code-sharing service like GitHub. Source code release under this paradigm is traditionally referred to as source disclosed, and is the first, not the final step in “open sourcing” government-funded code.
In addition to disclosing the underlying source code, in order to conform to with what we traditionally think of as open source today, publishers must properly license their code (generally not an issue with government), and should seek to create a community around the shared challenge the project sets out to solve.
Growing communities around shared challenges
Agencies that simply publish code with no intention to foster community involvement, curate community feedback, or accept community contributions find themselves, almost without exception, engaging in an unsuccessful endeavor. Rather than abandoning the code on the open-source community’s collective doorstep, the agency should expend effort, post-release, to ensure the project’s continued success.
At the most simple level, this is a matter of communicating the project’s goals and status to potential contributors, explaining how to contribute, and ensuring relevant stakeholders within the agency are empowered to review and accept such contributions. But, successful projects go a step further, and take steps to ensure there is no imbalance of information between developers on opposing sides of the agency firewall.1
Free like a puppy
It’s often said that open source is free as in speech, not as in beer, but I prefer to take that a step further, and note that open source is free like a puppy. You’ll get a lot out of the relationship, but you also have to put a lot in, the biggest contribution being a base level of trust.
Agencies are welcome (and encouraged) to disclose the source code that powers the day-to-day workings of our shared democracy, but they should know that that’s neither the last step, nor is that truly open source. Open source is a symbiotic relationship, a shared partnership, not a one-way, one-time, set-it-and-forget-it broadcast.
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →