Can DOD's stance on open source change the status quo?

Reader reaction to our coverage of new Defense Department guidance that puts open-source software on equal footing with proprietary software has ranged from cheers to questions about whether the move will change anything.

“All I can think of is 'about time',” wrote a reader from Northern Virginia. “The commercial world has made these decisions and assumptions years ago, and finally the government comes around. Kind of scary on one hand, kind of expected on the other. At least the slow-moving change of heart is in the right direction. It would be disheartening to quantify the amount of lost dollars and efficiencies with the decisions that were forced away from the direction of open source over the last several years based on previous 'guidance.' ”

“The fact that our own Department of Defense is recommending open source and Linux is huge,” wrote another commenter. “Even they realize the tremendous benefits of open source. Personally, I have migrated away from Microsoft years ago, and I couldn't be happier. Not only is Linux much more secure than Windows, but it doesn't have all of the maintenance headaches of Windows (removing spyware, viruses, having your personal information stolen, etc).”

Observers say the new guidance, which formally states DOD’s position, could have a significant impact, even though use of open-source software has been around in the military for some time. In 2007, for instance, the Navy approved the use of open source.

One anonymous contributor offered an example – along with a caveat that some open source doesn’t mean all open source: “We have developed a Navy enterprise application that is completely built on open source and currently deployed on a large number of ships at a very low cost, yet the Navy leadership wants to force the very expensive SAP software solution on everything rather than allowing or encouraging interfacing to it. SAP has cost the Navy over a billion dollars and will continue to cost an exorbitant amount that ever increases, just as [the Navy Marine Corps Intranet] has. Of course, the fact that it is all but impossible to do real work on the NMCI system and its security has been repeatedly breached doesn't matter to the senior management that insists we continue to do it wrong.”

Open-source software could offer maintenance advantages over other commercial software, wrote Frank Gearhart in Colorado. “As a network/systems admin, I deal with Army systems where, every time we have a problem and try to get some information to solve it, we run into ‘that's proprietary information,’ or ‘just send us the system and we'll fix it,’ or ‘just reimage it.’ I've sometimes resorted to using a packet sniffer to see what normal traffic looks like (we run a closed network) so I can better diagnose ‘they're not talking, and I've gone through the manual’ problems. Using open standards (without nonstandard extensions, as Coner suggests) and publishing data formats would, in my opinion, go a long way toward making these systems truly interoperable.

The Conor mentioned in Gearhart’s note is reader Conor Brankin, who drew a distinction between vendor lock-in and platform lock-in.

“While I fully support the use of open source in the DOD, I am a bit confused by the statement that open source will provide ‘the freedom from potential vendor-lock in,'” he wrote. “The issue with vendor lock-in is that applications are architected, designed and coded to a specific platform. ‘Platform’ is the problem with lock-in, not vendors. Virtually every platform that describes itself as being ‘standards compliant’ will have extensions to standards that provide enhanced flexibility, scalability, ease of development or ease of production time administration. The use of nonstandard extensions lock applications to the platform regardless of whether the platform is purchased from a software vendor or is a ‘free’ open-source platform coupled with a support contract. Therefore, using an open-source platform, coupled with nonstandard extensions, locks the application to the vendor selling support contracts. If the goal is to move away from lock-in, the DOD needs to mandate the use of standards without extensions. “

“Conor, I agree with you!” added Jeryl Cook in Washington, D.C. “I do believe perhaps the author means also when he says “vendor lock-in” is related to how a commercial product is implemented as related to interoperability with other external systems. In the simplest example, suppose a system is implemented in a closed architecture and produces a data format that is proprietary to the vendor and not based on any open standard like XML, etc. This can cause problems down the road if consumers are implementing solutions based on this to this proprietary standard.”

Several others, however, suggested the problem might not be software or platforms, but the institution using them.

“Does anyone really believe that this will matter?” wrote a reader identified as "Tired of the same ol’ stuff." “When an organization makes a choice about operating systems that is so insecure that they can't use a USB drive on their computer, do you really believe that they can get this right? Why doesn't someone ask why the Navy Simulation world why it is using RTI-NG and not RTI-S? They have an open-source solution for transport of simulation data. Yet, they chose to use a proprietary version of software that DMSO paid to develop.”

“I've spent a lot of time in the DOD and it gets to be a real headache with all computers in the DOD running Windows…with NO FIREWALL!” contributed an anonymous reader. “Not even the default Windows Firewall is turned on. They are running naked on a cold winter’s night hoping to dodge frostbite! Great to see they are finally getting a little smarter now.”

And other commenter concluded that it’s all about what works: “Who cares if the applications are in Open Source, GOTS or COTS as long as they are secure and support the mission? Anyone that calls out a particular manufacturer as the opponent to open source these days is misinformed. Or old. Younger developers are sick of the fight and are looking for interoperability. Our developers all need jobs, open sourceies (all flavors), Microsofties, et al. And BTW -- if you are having such headaches with MS -- get some training!”