A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 3.9KB

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

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.

Disclosed source

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.

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.