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.
Named one of the top 25 most influential people in government and technology and Fed 50’s Disruptor of the Year, described by the US Chief Technology Officer as one of “the baddest of the badass innovators,” and winner of the Open Source People’s Choice Award, Ben Balter is a Product Manager manager at GitHub, the world’s largest software development network, where he oversees a team of product managers responsible for the company’s business-to-business and community and safety products. Previously, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage government at all levels to adopt open source philosophies for code, for data, and for policy development. More about the author →