Slashdot Mirror
DoD Wary of That "Open" Word
joabj writes, "Why is the U.S. Defense Department still reluctant to use open source software, despite assurances from within the DoD itself? Blogging for Government Computer News, I found at a recent D.C. conference that to some extent the roadblock might be with that word 'open'."
I work in a military environment. Recently our computers were transitioned to NMCI. Result: All open source is strictly prohibited. My workspace had designed a really awesome database powered by MySQL and other open source technology. When NMCI came online we were SOL. When we asked for help, we were advised we could spend a $xxx,xxx and purchase a Microsoft SQL Server license instead. When we pushed the issue, we were told that we were welcome to submit MySQL to NMCI for approval but that no one knew how to file the paperwork and no one had ever seen any software approved before. My take: It's a money scam. Somehow NMCI and Microsoft profit from each other with an exclusive agreement.
While this is frequently the case, it isn't necessarily the case.
Far too many people think that FOSS is just something you download off the web. Something that someone else creates, but which you, as the customer, have no control over. That choosing an Open Source product is like going to the grocery store, and that you only get to pick whatever products are being offered, and that you otherwise have no say in their design.
However, this isn't necessarily the case. I've spoken to a number of groups on this subject at length, and what a lot of people don't realize is that you can continue to use your existing sources of software, but that you simply have to demand that the developer provide it to you under an Open Source license. That's it. You can still contract out the development work to the companies you're using for custom development. You can still buy from your approved vendors list. The license that the software is provided under is a contractual issue, and thus is something that can be negotiated.
Yes, the vendor may want more money in order to provide their software as OSS. However, if you're a really large corporation or organization (like the US DoD), in generally you'll be able to specify these requirements. Either your vendors meet them, or they don't (in which case you take your business elsewhere). Same as any other requirement specified in the tendering process.
FOSS doesn't have to mean "downloaded from some guys website". For a big organization like the US DoD, this probably isn't terribly desirable (unless the software does exactly what you want, and you can either form a business relationship with the developer, do continued development in-house, or are willing to contract out feature additions and bug fixes to a third party -- this is, after all, the biggest strength of FOSS).
(I wonder what would happen if a really big organization like the US DoD went to Microsoft when it comes time to renew their bulk licensing contract and specified that the software must be licensed as OSS, and in return offered them twice the amount of the previous contract. What would win out? Greed and good business sense, or jealous protection of the code and the loss of a major customer?)
Yaz.
1) Liability. Contractors want somebody to sue if something goes wrong. The DoD will blame the contractor.
2) Specs. Usually, the system is being developed is meant to replace another system that is in-place. The only things to be changed are what are specced out. This doesn't prevent things from being entirely rewritten, but it usually stays on an existing DoD platform.
3) Speaking of platforms, check out the existing specced out platforms. Lots of people go with DIICOE, or GCCS for various reasons. Some might include a desire to get something included as a DIICOE segment, which is profitable, or GCCS, because it's ubiquitous.
4) STIGs. If there isn't a STIG written for it, you're going to have a harder time getting approval to operate it on a classified network. Even if all of your major apps are covered, you'll have to get extensions regarding applications that are not covered. Extensions are not intended to be waivers... so, you're only supposed to get an extension if you intend to replace it. It is hard to justify an extension for new software. Why not just write it in a compliant fashion? Because the security audit will be more of a PITA, they avoid any step into the unknown. Some of this is just inertia.
5) Security through obscurity. It sounds asinine, but the DoD doesn't rely on security through obscurity.... they rely on anything that is considered a good practice, obscurity is just one of those many practices. It's not that they are using telnet or anything silly like that. It's just that they want as many layers as possible.
6) Common open source is embraced. Everyone runs Apache. It's as ubiquitous as IIS. It's the things that are considered more "out there" that aren't.
All of that aside, there have been open source initiatives, but contractors have been reluctant to bite. Reasons vary, but this is the essential dynamic. The DoD retains the rights to most of the source code for projects that they fund, so, they already have the source code... they give it to anybody that they please, including the next contractor to work on the project. Contractors don't want to share source with each other for competitive reasons. Since they're all bidding to produce identical products, giving other contractors the ability to develop experience with a product can only hurt their business, this experience is their primary bargaining chip when bidding (that and the ability to undercut their competitors, or qualify for special considerations, such as being a small business).
Then there is the concern of enabling foreign interests to develop commensurate technologies. Nobody wants to share code to decode IFF signals, or to build similar systems. Thinking that the government would publish code to do these things is just asinine.
You always have your crumudgeons who also will just resist open source... which is the same even outside of DoD interests, but the DoD comes with a host of other concerns. All of these in mind, I'm not sure that the DoD is necessarily stilted against open source. Some sectors of the DoD have embraced it quite readily... these are just the faster-moving sectors who adopt technologies more readily. The DoD is a very large entity, and, as such, slow adoption, when combined with very well established platforms results in this exact behavior.