Been a while since I’ve been able to post… thanks to a glut of internal planning and meetings… my head may be getting above water now, I hope. I had the chance to respond to a post up on GovLoop (http://www.govloop.com/profiles/blogs/gov-20-is-open-source) – and wanted to cross post here… I know there are a lot of strong feelings on this topic, and it’s more than worthy of debate:
Sharing government-developed solutions, particularly solutions that have repeatable value throughout many agencies, is absolutely the right thing to do. It allows for more scalable use of technology, better cross-government collaboration, and fiscal efficiencies through shared costs. In addition, one could argue that code developed in agencies really belongs to the public and needs to be open, and you also have the added benefit of better transparency.
Thus, publishing government-developed solutions as open source can make a lot of sense, as it can be a good model to foster shared use and collaboration.
That said, it’s important to note that publishing code as open source also comes with a great deal of responsibility and potentially a good amount of overhead. Putting code into the public arena and incorporating code from outside resources can introduce issues around IP ownership, use, and licensing, not to mention the need for thorough processes to guarantee code security, quality, and integrity. You can also add the complexity of managing branched projects and complex versioning. These are not easy issues, and if not done correctly, can lead to damaging repercussions that will erode any potential benefits.
Net net: doing open source right can require some strong engineering discipline and legal oversight – particularly when done for an institution (e.g., a government agency) that has significant exposure (and therefore, significant risk). So, while we all agree that sharing government code through open source can be a very good thing, it’s important not to be naïve about what it takes to do right.
Another note: There’s a bit of ambiguity in the article between submitting government-developed code to open source and using products that are open source. While I strongly advocate the sharing of government-created projects via open source, I think that agencies (and everyone, really) just need to be pragmatic in the decision of whether to use open source or commercial products in their environment and as part of their solutions, as there are benefits and complexities on both sides. There are some outstanding commercial technologies that provide significant benefit to Gov 2.0 initiatives – and they shouldn’t be discounted because they aren’t open source.
For example: should an agency choose not to use a really valuable iPhone solution – even if it would provide significant benefit to its constituents – just because it’s not open source? Should a great application built on SharePoint that would provide real cost benefits not be considered if it isn’t open source?
In each case: of course not. Products and technologies should be selected based on the capabilities and value they provide to Gov 2.0 solutions, whether they’re open source or commercial technologies. Cutting out either side of the equation severely restricts the options available to agencies, and diminishes the overall quality of Gov 2.0 solution for citizens.
Net net (again): it’s wrong to say that Gov 2.0 is open source (just as it’d be wrong to say that Gov 2.0 is “commercial”), as both open source and commercial software can provide great benefits to Gov 2.0 scenarios. Gov 2.0 is bigger and broader than individual technologies, development, and licensing models – and we’ll miss out on a lot of opportunity if we pigeon-hole it to any one thing.