title: Disclosed source is not the same as open source
url: http://ben.balter.com/2014/09/29/source-disclosed-!=-open-source/
hash_url: e1639a7ed3ce867487716129008f7901

<p>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, <a href="http://ben.balter.com/2012/10/15/open-source-is-not-a-verb/">efforts to “release” source code, in reality, often fall short of actually being open source</a>.</p>

<p><a href="http://ben.balter.com/2014/09/22/open-source-is-not-insecure/">The argument</a> for open source <a href="http://ben.balter.com/2014/06/02/beyond-open-government/">in government</a> is <a href="http://ben.balter.com/2012/06/26/why-you-should-always-write-software-as-open-source/">well documented</a>, but open source <a href="http://ben.balter.com/2014/01/27/open-collaboration/">is about more than having access to the software’s human-readable code</a>. Open source is a philosophy, a workflow, and most importantly a collaborative community, the basis of which is the opportunity to participate.</p>

<h3 id="disclosed-source">Disclosed source</h3>

<p>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.</p>

<p>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.</p>

<h3 id="growing-communities-around-shared-challenges">Growing communities around shared challenges</h3>

<p>Agencies that simply publish code with no intention to foster community involvement, curate community feedback, or accept community contributions find themselves, almost without exception, <a href="http://www.theverge.com/2013/10/18/4852720/why-the-government-unpublished-the-source-code-for-healthcare-gov-github">engaging in an unsuccessful endeavor</a>. 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.</p>

<p>At the most simple level, this is a matter of communicating the project’s goals and status to <a href="http://ben.balter.com/2013/08/11/everyone-contributes/">potential contributors</a>, <a href="http://ben.balter.com/2013/08/11/friction/">explaining how to contribute</a>, 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.<sup id="fnref:1"/></p>

<h3 id="free-like-a-puppy">Free like a puppy</h3>

<p>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.</p>

<p>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.</p>
