Open Government and Open Source at the Department of Defense - Part 1 - Washington DC Technology

Dan Risacher

An interview with Daniel Risascher, Office of the CIO, Department of Defense

Open source can be defined as a development method for software that harnesses the power of distributed peer review and transparency of process, and the promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in (from The Open Source Initiative). The US Government, including DoD, is taking a new look at open source as a way to achieve cost savings, and improvement in quality. Scott McNealy, in a BBC interview in January of this year, said that he had been asked, by the new administration, to write a paper on open source. OSI President, Micheal Tiemann, also claimed that the US government could save around $400bn dollars through use of open source.

With all this hype, it becomes all the more important to take a closer, and a more pragmatic look at open source. Within the federal government, the Department of Defense is a major advocate for the open development model and is a major use of open source software. In 2006, DoD defined an open technology roadmap. In 2007 the Navy CIO issued a memo said that open source fits in with the definition of commercial software. In 2008 the annual defense budget re-authorization bill encouraged open source software solutions. In 2009, forge.mil was launched, a site that will host the military’s public open source software projects (inspired by SourceForge). The DoD CIO’s office is current working on updated guidance for open source that should be signed soon by Deputy CIO, Dave Wennergren (who replaced John Grimes, former CIO now retired).

With that in mind, I talked to Dan Risacher, who is the lead on Open Source issues in the Department of Defense. Dan is not only the Open Source policy wonk at DoD, but is also an open source evangelist in his personal life, having been a programmer himself and written some open source code himself. He has a Masters in Engineering from MIT, and has seen active duty as an Air Force Second Lieutenant (promoted to First Lieutenant in two years). He started at the Office of the Assistant Secretary of Defense (Networks and Information Integration)/DoD CIO in 2004, and has been the lead on the draft DoD policy on open source. This document clarifies DoD policy on open source, clarifying the advantages of open source, clarifying DoD policy, and some things that have been misinterpreted. This document should be formally issued in the coming months. His wife, Suzette, who he is very proud of, is a firefighter in Virginia, and they have two children, Luke and Jamethiel.

Dan, how would you define open source vs. free software? Where do you stand in the free software and open source movements?

The Free software movement is a social movement advocating individual liberties in software use and software development. Open source much more a development methodology and has very pragmatic business processes that are very much focused on how do you do software development better, rather than advocating the concept of individual liberty that is really associated with the free software movement. All the same, there is a tremendous amount of overlap between those two in terms of the licensing and practices that have been developed. From the government’s perspective there is not a more ardent supporter of liberty than the Department of Defense (DoD) - that’s what we do, we support liberty and support and defend constitution of the United States. That having been said, we don’t choose battles that we will fight. Other branches of government tell us when and where to engage on things, so in general it is not appropriate for DoD to be choosing on its own to engage in the social movement that is represented by the free software movement. However the very pragmatic open source software movement that says that look, this is a development methodology that has certain benefits associated with it in trying to be good stewards of taxpayers and the public resources and trying to leverage those benefits associated with the open source software methodology. Historically, looking at various policy memos and things that have come out of government, specifically DoD, but also the federal space, have focused on open software and stayed away from the somewhat more politically charged term of “free software term” and appropriately so. If someone wants to promote the values of the free software movement and promote individual liberty that is something that should be coming from elected officials, from Congress or President and not some workers from within a specific executive branch agency. That’s how I would split that baby. We are the ardent supporters of the same concept of liberty that the free software foundation is promoting, but we have bosses that tell us what to do, our mission is to support and defend the constitution, protect the united states, and not necessarily to promote individual liberty in the social arena

What are some of the risks and opportunities for the federal government in using open source? How can the risks be managed?

There are two opportunities that I can see. One is that there is a tremendous opportunity in that there is a fairly large body of existing open software that we can go use, but that has been historically under-appreciated because of the lack of understanding of, or guidance on business processes related to open source, such as how we go out and acquire capabilities and buy stuff. . For instance, we might go out and look at a marketplace, and say “how much does that cost?” “I need one of those” and we hire a contractor to go out and build us a system that doesn’t make use of this existing body of software. It’s just not considered, it’s not part of the analysis that goes into the purchase decision. This is prevalent both in the commercial space and in the government space. We’ve become more aware of the fact that, hey, I can buy an existing system from proprietary vendors such as Microsoft, OR from Red Hat or any of the open source vendors.

The other opportunity, is that there is this development methodology of how we collaboratively develop software, which has been seen to be very effective in open source world, and we want some of that, we want to figure out how do you achieve that level of collaboration within the defense enterprise. And that turns out to be very difficult because most of the software development that we do is done through contractors, systems integrators, and there are some challenges in the way that some of the federal acquisitions laws were written. In general, if I go pay a defense contractor to develop some software, they own the copyright to that, and the govt may get the rights to use that for any legitimate govt purpose (depending a lot on the details of how the contracts work), but they have the right to commercialize that property. So if I want to share it, I may be able to share it in specific cases with other defense contractors but to be to share it more broadly and to really establish a community of people who are developing around a specific base on software code turns out to be challenging. It’s not impossible but it is hard because of the restrictions. In some case the government owns all the rights, this is called having unlimited rights, in such cases, the government can do whatever it wants, but in a lot of the cases we still end up with government purpose rights, which is still fairly broad, but has enough restrictions that it becomes challenging to achieve a measure of re-use from one program to another. So we are trying to figure out that opportunity-how do we do collaborative software development the way that the open source community is doing it for defense specific problems ?

Risk

From a risk standpoint, along with looking at the opportunities I talked about, we need to develop a set of competencies, of methodologies, perhaps in terms of evaluating the maturity of software. Both for open source, and proprietary software – how do I determine that it is any good? We may do evaluations or some experiments with it but we don’t necessarily spend too much time understanding things like, “well how well is that company going to support that software?” And that is even more complicated in open software where it may not even be a company; it may be a foundation or user group or people who use that software – a fairly loose federation.

There is a perceived risk of open source from a security standpoint, people are very concerned about using software and it’s either “I don’t know where it comes from”, or “what backdoors have been put in the software”. I think it is largely a red herring, people don’t know where their proprietary software was written either nor do they know where the backdoors are in that. In open source, there is usually very robust version control, and you can see every line of code where it came from, who put it there and who made changes to it. The ability to do that inspection and do security audits is much greater in open source than in proprietary software.

Then it would be as safe if not safer? Yes..certainly there is a long standing acceptance in the academic security world of the importance of openness as a principle of security. You really don’t want to trust your house to a puzzle lock that nobody know how to solve but you. Sooner or later the guy is going to come along who is smarter than you are and he is going to solve the puzzle. You want that security to be part of the key. The mechanism of how the clock works is well understood but people still don’t know what the key looks like, so that is a much better way to do security. There’s a great paper from 1974 by Jerome H. Saltzer and Michael D. Schroeder, called “The Protection of Information in Computer Systems”. The authors said that openness is an important characteristic for security. This strikes people as hard to understand. I want to know how it works so that I know it is secure. If I am relying on obscurity and the fact that this is a little known system to really guarantee that there is no weakness in it – if anything that is driving in the wrong direction. The more secretive it is, the more likely it is that it was designed by one guy or a small team of people and there is probably something they overlooked, vs. if I have something that is widely publicized - algorithms code and mechanisms - then the obvious and sometimes the not so obvious flaws will be discovered by somebody if it is open. Security researchers will comb it over, looking to make a name for themselves and you benefit from that review. So it is really the process of review helps you achieve better security and open source software enables that review to take place in a way that is very difficult or can’t be necessarily matched by the proprietary software development world.

How can we ensure quality in open source software? Can we borrow from models such as the Software Engineering Institute’s (SEI) process maturity models that were built for closed source software?

I am sure you can derive the open software equivalent of the CMM processes and best practices are probably there are people who have done it. I tried to do so myself – when some years ago when I was still in the air force active duty, I took the Capability Maturity Model (CMM) processes (from SEI) and tried to derive from that, a process model for open source software

But more generally, from a quality standpoint, one of the arguments in favor of open source is openness itself. Let me use an analogy – if you have a room full of people and you ask them “how many of you when you wash your car, open your hood, and wash the engine?”, and usually if you ask a big enough room full of people, there will be a couple of people will usually raise their hands and say “absolutely”. And can bet a dollars to donuts that if you ask them “what kind of a car do you have?”, it will be a classic antique, it will be a show car, it is a car that they are proud of, and they want to show it off, and they expect to take it to a show and open the hood and have people looking at the engine. I don’t wash the hood of my car, my car takes me to work and back and that’s it. The point of that the analogy is that when you expecting someone to take a look at the internals, you take a little bit more pride of ownership, and you are going to make sure that is clean, and the open source software, and this backed up by statistics.

All the same, you can’t make broad generalizations on quality that open software is higher quality than proprietary software as it depends on the specifics. There’s open source software which is open source because someone wrote it in an hour and threw it out there and it’s not very good. I have written some myself, I took some existing code and added one feature I needed - it worked but wasn’t very good. This is because 4-5 people worked on it, somebody wrote it, somebody enhanced it and that was it. Compare this process, on the other hand to linux or Apache, something that had a lot of developers involved, and a lot of review processes involved, in these cases, I think that software tends to be very high quality, I think you would find a similar range in quality in closed source, for instance crown jewels written by someone who was very smart and diligent, to things that were written in one afternoon and did not get properly reviewed before being pushed out of the door. So it’s hard to make generalization, I can say principle of openness helps drive quality into the software through that process of review.