Q&A: Gunnar Hellekson on open source adoption in government

Open source software received a high-profile vote of confidence when WhiteHouse.gov chose to use Drupal as it's web content management system. Agencies also warmed to open source solutions when the Defense Department released a 2009 memo dispelling some common misconceptions around open source software. And just a few months after being urged to embrace open source for its electronic health record system by an industry group, the Veterans Affairs Department says it's investigating the possibility of using open source software for VistA.

Gunnar Hellekson, Red Hat Government lead architect and co-chair of Open Source for America recently talked with FierceGovernmentIT about where and how open source is being adopted across the federal government and what could be done to encourage adoption.

FierceGovernmentIT: Since around 2000, various committees within government have been recommending the use of open source software and promoting the development of open source software, saying: "It should be taking off any day now." How should we be viewing the rhetoric of federal open source adoption versus what is really happening?

Gunnar Hellekson: It's funny; there was the MITRE study for the DoD that happened back in 2001, where the Department of Defense suddenly realized how much open source software it was already using.

Now, almost ten years later, people still have a misunderstanding that open source software is something that may be dangerous to use. Or they think that they're not allowed to use it, when in fact open source is being used all over government at the federal, state and local levels.

I know at Red Hat, we're at every cabinet-level agency and the adoption really is widespread. So, whereas five years ago, seven years ago, the message may have been: "Yes, it's okay to use open source software," I think that part of the fight is over.

People definitely understand that not only is it safe to use, it's legal for the government to use open source software. There are now fairly sophisticated policies. One at the DoD is a good example, which lays out the terms with which you can use open source software, special considerations you need to make. And if you read their memo from last year...

FGIT: The one that lists it as a commercial computer software? The memo from Oct. 16, 2009?

Hellekson: Yes, that's right. So, the actual content of the memo said open source software is commercial software for the purpose of procurement. Case closed, right?

But then there was an appendix to that memo which goes on to describe all of the things that open source software can bring to the department, and that includes things like flexibility, and avoiding vendor lock in. And that appendix reveals a really sophisticated understanding of what open source has to offer and all the benefits of its development.

At the same time it was very careful to not say, "We have a preference for open source software." But it was there to make sure that PMOs and contracting officers understand that open source does have a huge advantage, which they should be evaluating in the regular process of acquisition.

And that attitude is now common at all the departments, all the agencies. I think everyone understands, now, what open source can do for them because they're using it. What's really interesting is that we're now seeing more and more agencies very comfortable with starting open source projects and contributing back to open source. And that's really exciting. I really like the open source development process as a catalyst for inter-agency collaboration and public-private as well.

FGIT: You mentioned collaboration, and collaboration and developer engagement are at the core of the open source movement. But, I'm under the impression that there aren't a ton of developers in the IT departments across government. Also, collaboration isn't typically seen as a strong suit of government because agencies and departments can be so siloed. Do these factors combined create sort of an ideological hurdle for open source?

Hellekson: First of all, I don't think the lack of developers is a structural problem. Certainly, it would be great if agencies had open source developers. The DoD is an example where they do, and they built forge.mil. So yes, there are developers collaborating together in that way. Where there are developers, it works well.

But even if there are not a lot of developers in-house, the government is able to articulate the requirements-which is often enough. Look at the example of HHS, which has the CONNECT project, where it wanted to promulgate this standards that would allow healthcare providers, insurers and clinics to exchange health records. And HHS and NHIN knew that just publishing standards really did no good, as far as adoption.

So they launched an open source project called CONNECT which allows vendors and individuals--as well as some developers contracted by NHIN--to get together and work on a reference implementation. So, NHIN provided the expertise, the direction, the vision and provided access to developers. It was able to catalyze the community around the specification and as a result it is now a lot easier to participate in what they call a "superhighway for electronic health records."

So while developers certainly help catalyze the community, it's not necessarily imperative. It can start just by formulating a vision.

FGIT: So, with Red Hat and in your role with Open Source for America, your mission is to promote the use of open source within government. What do you think needs to happen at a policy level in order to facilitate that?

Hellekson: There are a few challenges that remain for open source and a few of them are around intellectual property. As agencies are now beginning to experiment with creating open source projects and contributing code back to the community, there are questions around strength of the licenses, since the U.S. government, as you may know, is not able to assert copyright.

The regular mechanics of the open source community are changed when the government contributes. So, there are going to be clever ways around this, which DISA has encountered with its OSCMIS project. What they've done is they've released the code in the public domain, and then a private organization took the code, altered it enough to insert a copyright on it, and then licensed it under an open source license.

There are all kinds of paths around the existing regulations that will allow the contribution of code. But the path there is still being found. There are all kinds of rules and bars and people are still struggling to understand what the consequences are.

What we're doing with Open Source for America, in collaboration with a number of other organizations, is to articulate a clear path for a government PMO who wants to release their code and say, "You can go through this checklist and you will be free and clear." There could definitely be more guidance and interpretations around that.

So, we're actually at a really interesting time, where people are starting to get the hang of it. We're seeing models emerge and that's making it easier for agencies to contribute and create.

FGIT: So, what departments and for what purpose are at the forefront of open source adoption right now?

Hellekson: You have the example of agencies contributing for almost moral or ethical reasons, in that they're thinking, "We're using this software and taxpayer dollars were used to develop this." In fact, I think that's one of the reasons for contributing back to Drupal, the content management system that's being run at the White House.

There's also some self interest in this, because by releasing the code out into the public, they not only have a technical obligation, but they're now able to leverage the collective developments of the entire group. Whereas before they would have kept those improvements to themselves and made changes over time, they've now shared them with the community.

I mentioned earlier about using open source promulgating standards. I just learned today about a really interesting project. The DoD has created a common platform for technology to be developed for their unmanned ground vehicles. Based on this joint architecture, there is actually an open source community where that gets implemented called OpenJAUS.

That's a great example of a public-private partnership where the government can provide direction and the open source community can lead the execution.

Again, you've got the NHIN CONNECT project. One of the reasons they started that project is not just for the ubiquity of standards, but also to make it easier for folks to implement. So, Congress has now set aside a bunch of money for clinics to adopt electronic health records, so having the CONNECT project, as an open source project, they've also lowered the cost of adoption for many of these clinics. Many of them don't have money to spend on very big, elaborate, interoperable health records.

FGIT: You mentioned the WhiteHouse.gov giving back code. It's my understanding that it enhances security as well, in that making sure other developers are up to speed on what you're doing helps raise awareness of vulnerabilities.

Hellekson: That's exactly correct.

FGIT: You also talked about cost and the benefits of using open source as a less expensive solution. So, if it is, you know, more robust as far as security and it's less expensive, I do have to play devils advocate and ask: What gives? Why would anyone say "no" to open source if it's cheaper and more robust?

Hellekson: Sure. So, on the security side you might remember that when the White House released the Drupal code, a short time afterwards they found a vulnerability. And a lot of people said, "Ah-ha! Open source is dangerous. And now everyone knows about a vulnerability on the WhiteHouse.gov website!"

Well, I actually turn that around and say, "Good. Now we know there's a vulnerability in the WhiteHouse.gov website. Now we can all work together to fix it."

If the White House had not released that out into the open, nobody would have known--or rather, only our enemies would have known--about that vulnerability. So obscurity-driven security is really no security at all. I think that's now well understood.

So yes, security is definitely one of the reasons why government has been slow to adopt. And back to what you said, if it is better security, better software and cheaper, why isn't everybody using it? I have to agree with you.

But one of the barriers to adopting open source is the lack of commercial support. At Red Hat for example, what we do is make open source software more usable for enterprises by providing regular fixes, or if there's a problem, there's an 800 number to call.

For a lot of open source software that commercial-level, enterprise support isn't available. And if you do use that software, as many do, you are at risk. In some cases that risk is totally appropriate. In other cases that risk is so great that folks choose to get the software through the commercial option. But if there were no commercial option, they'd rather not use open source at all.

FGIT: So does that have implications as far as needing to ramp-up the number of developers within government, in order to be more confident in managing these open source programs that do not have the customer-service aspect?

Hellekson: It's certainly true for government agencies that have a specific open source project, for example a certain geospatial program, certainly if you have a real interest in using open source software and there is no commercially available support for it, then, yes, you might need to hire additional developers.

At the same time, you're seeing the huge demand for open source offerings. There are open source projects starting up everyday, especially with the cloud and content management systems. Acquia provides enterprise support for Drupal, for example.

So, while the government may be forced to take on an additional developer for one of these, there are also many more options available in the private sector from companies that can help.

FGIT: Back to the security, and what can live in open source code. As far as the Air Force, for example, wanting further research on tools for detecting malicious insertions in supply chains somewhere prior to the acquisition of software, is there any threat there-is that a concern or hurdle-for open source adoption?

Hellekson: Security in the software supply chain is something everybody should be worried about. And certainly the threat is not reserved for open source or just proprietary software. It really is everyone's problem. If you have a piece of software, you want to be sure that it's functioning properly that there is no malware or Trojan horses and so on. It is a complicated problem.

There is some work being done by NIST on SCAP and CWE  standards, which help companies search for and identify common vulnerabilities. The open source development model actually helps with this a lot.

In open source communities, there are two kinds of developers-one is your basic engineer who contributes patches, and then there are the project leaders who have the right to actually update the software. They're the committers. They're the only people who are officially allowed to apply a patch. And so there's always an audit trail in the open source community. You always know the identity, you can always trace back the origin of the patch, and it has to be associated with a certain issue number.

So, the open source community, mainly because it needs to coordinate an extremely fragmented and chaotic community, has a really sophisticated process in place to figure out when something changes something, what the origins are, and so on. So this entire infrastructure that the open source community has built up is extremely useful when it comes to looking at security in the supply chain because we have very good traceability.

FGIT: You mentioned NIST a little bit earlier. I'm somewhat familiar with SCAP, but I don't know anything about OpenSCAP. So can you talk a bit about that and NIST's involvement with the security aspect?

Hellekson: This is another really good example of the government encouraging--even if they're not explicitly involved in open source communities--the government is providing the terms and direction for open development.

So, SCAP is a protocol, where basically I can say, "This is what I want my security posture to be like." I can take that SCAP content and I can feed it to an SCAP tool, and the SCAP tool can then audit my system and tell me whether I'm in compliance or not.

In the future we'll have SCAP tools that cannot only identify but can also remediate problems. So it's a really powerful standard. And because NIST wrote it, it's not just for the open source community. It works for Windows, network devices, and printers. At Red Hat we got really excited about this.

We're a huge fan, not only of standards, but also the security of IT. So we started an open source project called OpenSCAP, and what it does is all of the kind of complicated, gnarly, boring formatting stuff required to actually build tools that implement SCAP. It's a downloadable library that takes care of a lot of the dirty work for you. It makes it a lot easier to build more sophisticated tools on top of it. OpenSCAP is an enabling technology.

Our hope is that OpenSCAP will actually encourage SCAP adoption, not just Red Hat or Linux, but the OpenSCAP library should make it easier to build those kinds of tools on Apple and Windows computers, too.

FGIT: That's it from me. Is there anything else you wanted to add?

Hellekson: Yes, in the second week of September, Open Source for America is going to release a report card on agency performance with regard to open source. It's going to be talking not just about their use of open source, but also evaluating their policies on contribution, policies on terms of use and we'll talk a little bit about open data, which is a great enabler of open source projects. The early results I've seen are really fascinating. In some cases, we're much further ahead than we thought we were, and in other cases we're really lagging.

Related Articles:
VA investigates VistA EHR open source
VA's Baker: No wholesale dumping of MUMPS
Industry group urges VA to embrace open source
Department of Commerce looking to Drupal, as well
Why WhiteHouse.gov chose Drupal