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 gather it is because of the act of taking on the responsibility of making a solution fit the problem. In a commercial or consulting role, someone claims to have a solution ( or be capable of creating one) that will solve the problems at hand. When a manager ( especialy within the DoD) gives the okay for a canned solution, the responsibilites are already diluted, meaning that if the solution has already been working for others, it is safe to assume that it will work for your organization. If it fails to do so, the manager can point to the other successful implementations and list the differences between your actual needs and the products capabilities. The vendor can then tailor the app more closely to your needs and the manager still looks good.
If we apply the same standards to Opensource, we can look at established projects like Apache, Mysql or even Openoffice and they are still safe because others are successfully using the software, it is not really a matter of a central point for support. For a manager to okay a more obscure project for implementation means taking on a much greater and unknown responsibility.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Because the DoD allegedly likes freedom and wants to promote it. It is their reason for existance. If "Open Source" is hurting the adoption effort use the original name "Free Software".
...is why OpenBSD is so infamous for being insecure.
http://mediagoblin.org/
The problem is that an Open Source project would quickly become a proprietary project anyway. Take, for instance, VISTA (medical records). Yes, it's open source, hell, it was even developed by the government. However, since the VA's mission is decidedly NOT to provide tech support to the rest of the government, other departments that might use that system are left holding the bag to fully support it IN HOUSE, and that includes a metric ass-load of customization.
Where "Open Source" is really competing is in vertical, single-source support and in that department, it usually doesn't have an advantage. It's not that government is averse to using the stuff, it's just that they don't want to end up with something like the VA and VISTA where they have hundreds of full-time developers devoted to keeping it alive. They'd prefer to sign a vendor on to provide it as a service so they can get on with fulfilling their mission, not pretending to be a software development company.
The benefit of open source is that you "own" the code in the sense of having unfettered access to it and can continue developing it even if the original owner ceases to exist. However, owning the responsibility of perpetual development is precisely what government agencies DON'T WANT -- and, frankly, for good reason. They're not software companies and they're very bad at pretending to be so (take a look at the FBI case management system, for instance). When people make the case for open source on those grounds, you've just presented them with the worst nightmare imaginable, so don't be surprised if they scream and run away.
Fair enough in this specific case I suppose -- however, my comments apply to any organization, particularly any large organization (as they have more money, and thus more leverage).
By way of an example, back in 2005 I attended a Health Informatics conference in Toronto, where a colleague of mine asked a panel of self-described "doers" whether or not they had considered Open Source software. I blogged about it here. In essence, they too were treating Open Source software as if it were a product that sat on the shelf, and not as something that you, as a customer, can demand. It is interesting to note that they discussed all sorts of development and partnership problems that OSS could solve for them, however collectively their attitude was pretty much to look for an existing OSS solution to their problems, and when they didn't find one, go to a commercial developer and use whatever license that developer dictated to them.
This is where organizations are going wrong with OSS. There is nothing wrong with using a commercial developer -- just mandate that the development they do for you is licensed under an OSS license. Canada Health Infoway claimed at the time they had $1.8 billion to spend in the field.
And maybe it's just me, but the customer with $1.8 billion should be the one calling the shots. The problem isn't that they lacked the clout -- only that they lacked the knowledge to know what to ask for. They are at the whim of the development companies they contract out (which has bit these people on the butt before -- there have been a number of cases in this field where organizations have spent millions of dollars and spent years having a custom solution developed, only to find that it no longer suits their current needs (which have changed since development began), and/or won't run on their current deployment environment anymore, necessitating scrapping it and starting all over again).
Yaz.