Pentagon is preparing guidelines for open-source adoption

Given the widespread adoption of open-source software within the US federal government, including the US Department of Defense, it's perhaps not surprising that the regulation-heavy federal government is finally getting around to issuing guidelines for open-source adoption within the US Department of Defense:

One of the primary issues to be addressed is if open source software is a form of commercial off-the-shelf software (COTS)....The memo should also dispel lingering ideas that open source software may not be used because it is a form of shareware or freeware....The memo will also confirm that it is acceptable for an agency to contribute source code back into a public open source project....In addition to defining the relationship open source has with COTS, shareware and copyright, the memo may also articulate some of the possible advantages of deploying open source.

What a profoundly important step forward for the US federal government, and for corporate open-source adoption more broadly. A range of software vendors like IBM and HP have policies as to employee contributions to open-source projects, for example, but in this case we have a major organization defining the parameters in which its employees can contribute to open source.

Will this be contagious? Let's hope so, because it could help to bring a massive flood of open-source software into the industry, given that most enterprise software is written for use by enterprises, not for sale by vendors.

In the narrowest sense, however, this memo potentially portends the proliferation of open-source adoption within the US Department of Defense on a grand scale.

[kit_plummer]

Matt,

The problem with the pending CIO memo is this blurb: "that releasing the code is in the government's interest". As an Open Source contributor under Federal contract, I can tell you that the problem isn't the government...it is the Federal contractors. Unless government provides some incentive for contractors to push Open solutions, there's no reason to expect anything to change. For example, my employer Accenture, is willing to let me commit to Open projects if I get approval from the customer (govt. or otherwise) AND sign-off from program leadership, legal, and a senior executive (which requires unreal overhead for which there's no justification).

A previous employer of mine, Raytheon, can't even grasp the issue. Not only is there suffering in the form of "not built here", but the lawyers can't even comprehend what is IP, let alone make some kind of contractual decision based on what Open means. Until the money sources provide "win-checks" for being Open...

The best interest of the government is defined by the top-5 contractors, and they surely can't rationalize sharing their efforts (even if it will benefit themselves later.) Open Technology Development, as defined by the DoD's channels is struggling to fix the perceptions of open standards - versus proprietary, vendor-locked solutions. So, while I think an updated "memo" will help create some conversation it is just that, a memo.

Kit
(Great blog BTW.)

[1974joel]

I have a high level meeting with OSD next week. If you could ask the DoD to change 3 things, what would those be? Email me at [e-mail] please.

[vanlindberg]

This is great - and the DoD *is* doing more to support open source. On the government level, the problem in many cases is not the DoD, it is the state department and export regulations. This is a thorny issue that most people haven't looked at.

That aside from any issues from contractors, as discussed by the previous commenter.

[PVescuso]

Black Duck Software sees the efforts the government is making to provide clear cut OSS adoption policies as a step in the right direction, but as your readers point out, policies aren?t enough. We believe the incentives to use open source as an alternative are the benefits (choice, access to source code, flexibility, etc.) and cost-savings that can be gained. As you point out in your blog, government agencies have long been proponents of OSS use, and in some cases, have been first adopters. What is new, and necessary, are the guidelines. We believe that clear cut guidelines coupled with a comprehensive solution for managing open source use, vulnerabilities, and license obligations, are key to following best practice guidelines for its inclusion.

Today?s hybrid software development processes, where OSS is integrated with proprietary and other code, introduces new challenges to government organizations looking to maximize the value of open source in their confidential and mission critical software assets. ?Copy and paste? code use will exist and continue as long as developers are connected to the Internet. Empowering developers with the tools necessary to detect and mitigate open source license concerns and vulnerabilities, enables them to do their jobs while better protecting the interests of their organizations.

--Peter Vescuso, Black Duck Software