I think we’ve all read our fair share of reports about lessons learned and the challenges and opportunities for governments taking up open source software. Frankly, many of them seem a bit dry, and often repetitive.

But one study I recently came across (that has not received much media coverage) stood out. Its predicate was different that most, recognizing the positive: open source software (OSS) “is being used in [the U.S.] government, as well as being released by the government (as both minor improvements and whole new projects), and the government is receiving benefits from doing so. However, many in government are unaware of this.” In short, it appears to find the glass half filled—or better—rather than half empty.

The report, Open Source Software in Government: Challenges and Opportunities, was produced in 2013 by the U.S. Department of Homeland Security (DHS), not your typical IT government agency. It also stood out because one of the authors, Dr. David A. Wheeler, is one of the most knowledgeable about use of OSS in the U.S. government (USG) and has been deeply involved in this area for over a decade.

It looks not only at usage of OSS by U.S. federal agencies, but also explores the issue of government-developed software. The U.S. government “should require sharing software and release software as OSS by default if it was developed with public funds.”

Through interviews conducted with experts, suppliers, and potential users (where users included both government contractors and government employees), Dr. Wheeler and his co-author, Tom Dunn (at the Georgia Tech Research Institute) sought to dig deeper than a simple survey about OSS use in the USG. It wanted to get at “what the real problems actually were … to help determine what the real challenges were, as well as to identify approaches for resolving them.” The report was sponsored by the DHS Science and Technology Directorate’s Homeland Open Security Technology (HOST) project.

Half-full or half-empty?

So, what did Wheeler and Dunn find in their report?

As one interviewee stated, “The more OSS is used, and the more success stories are out there, the more people will use it and truly save time and money.” That theme showed up throughout the report. Indeed, many interviewees recommended that “the government should require sharing software and release software as OSS by default if it was developed with public funds.”

One of the central challenges identified is plain inertia. “That is, resistance to change … A government employee said that the government’s ‘rejection of OSS is a combination of fear and inertia. [They] don’t like to move outside of their comfort zone, and [there’s] the fear of the unknown.’ An OSS expert stated, ‘For OSS in the government, the biggest impediment is habit; they’re used to buying what they’ve bought before.’” While not explicit in the report, as newer generations of IT professionals who grew up on OSS come into the government, it is likely that this assumption will shift. To some degree, we are already seeing it in agencies.

The authors also emphasized a need to “refocus certification & accreditation (C&A) efforts on risk management instead of implementing inflexible processes.” This area, I will note, will only grow as more emphasis is placed by agencies on security and reliability. The report urges that, where possible, “greater sharing of C&A data and authorization to operate” data should occur (e.g., by hosting a “summer of C&A” event). The report points especially to the need to “ensure that all relevant parties, including OSS suppliers, are involved when the government is developing related specifications (e.g., Common Criteria Protection Profiles).”

And a key theme I’ve seen with other governments is the critical step to have agencies “switch from proprietary formats and protocols to modular systems and open standards, as this enables the transition to alternatives, including OSS.” The report goes on to urge USG technical staff to “take a more active role in developing these open standards and developing OSS implementations of them,” citing examples such as the Security Content Automation Protocol (SCAP) and Open Vulnerability and Assessment Language (OVAL) specifications which have become essential tools in both USG and private sector IT implementation.

Not surprisingly, the procurement process gets some criticism. The offices and officials responsible for developing “Request for proposals … should not presume that respondents have a particular business model and should not impose unnecessary paperwork burdens.” And when it comes to releasing OSS software developed in-house or by contract, it certainly “may require changes to contracting strategies.”

Education vs. New policies

But notably, the report emphasizes that many challenges identified in their research regarding use of OSS don’t require policy changes, but instead are a lack of education or guidance, including “education on OSS in general.”

“The government does have some OSS policies,” the report states. “The Office of Management and Budget (OMB) has released a federal government-wide memo that acquisition rules apply to all software, whether it is proprietary or Open Source Software [citing the July 2004 OMB Software Acquisition memo] placing OSS on an equal footing. The Department of Defense (DoD) has a more detailed OSS policy that makes it clear that OSS is acceptable and must be considered, as well as supporting frequently asked questions (FAQs) and best practices documents.” They conclude: “There is a lack of awareness or understanding of the federal government’s definition of OSS and not really a lack of policy.”

An important theme coming through the report is that agencies need to work, often with the private sector, to know the differences in and attributes of various OSS. “There were many comments about commercial support and warranties. We recommend the government educate their employees and contractors about the many options for support and warranty of OSS; often there are commercial support vendors for OSS.”  This becomes especially important in the C&A area, as the report notes, where security evaluations (e.g., through Common Criteria and FIPS 140-2) can be costly but essential.

Citing OSS experts inside and outside the USG, “A lot of [the problems stem from] the government not understanding how the OSS model works. … In terms of [OSS] use, the barriers are most typically education. People have a lack of information, [there’s] still some FUD at the management level, [and] they think that OSS may be insecure (that’s still out there).”

Interestingly, on this last point, the authors “expected many challenges to relate to security or perceptions of security. We did find these, but many of the challenges were in other areas.” These expectations included fears about low quality or malware insertions. But as they point out, “software can have low or high quality, regardless of whether it is OSS or not.” As several users put it:

“There can be good and bad OSS, but there are metrics to figure out which is which. … [OSS] can assert higher quality in a more transparent way; they can show their source code is quite solid through the use of software quality assurance tools … You can do an automated verification that you conform to government-style policies, let alone other policies, so that source code is less likely to have memory issues, or whatever the case may be. Being able to assert those quality metrics would have a lot of value … [With OSS you’re] able to assert in a transparent way that you’re producing quality code, especially when securing people’s data.”

The report noted praise for OSS’s supply chain transparency “as it enables countering risks. … You can get more trust in OSS origins than proprietary software.”

Risks in government forking

One of the more intriguing “challenges” identified in the report is the tendency, and associated risks with government agencies creating an independently governed project by copying an existing OSS project—commonly known as “forking.” It’s a subject that David has written on previously (e.g., see my interview with him last year).

One of the benefits of OSS is that it is commercial-off-the-shelf software, and it can be supported by potentially a variety of vendors, as well as serving as an agile, reusable modular approach to software use by agencies. “A project fork is typically far more expensive for the government to maintain in the long term because the government must pay for every change (instead of sharing sustainment costs with others), and the fork is also cut off from the future innovations in the main OSS project.” This is consistent generally with the tenets of the OSS literature which “strongly recommends avoiding creating a project fork wherever possible. Yet the government and its contractors often unnecessarily encourage creating project forks, instead of discouraging it.”

Thus, they find that “since project forks dramatically reduce the value proposition of OSS, the government should strongly discourage creating project forks” even as the report identifies “perverse incentives” to do otherwise.

What’s changed since the report was produced?

It has been some time since the report was prepared. So, I asked Dr. Wheeler his thoughts on what has changed or what he would recommend differently, if anything, today?

“What’s changed? I think that everything that we said in the paper “Open Source Software in Government: Challenges and Opportunities” is still true. However, it’d be misleading to say nothing has changed. The U.S. federal government doesn’t change quickly, but I do see a slow shifting towards more use and development of OSS in the U.S. federal government. Concrete data is hard to come by, but I’m seeing more questions about “how” to use or release OSS instead of “may I” do something. There are also an increasing number of OSS projects that are being developed by the U.S. government; you can see a partial list via http://www.dwheeler.com/government-oss-released/. Far more people in government, or supporting government, have GitHub accounts. Increasingly people are getting “authority to operate” OSS, they’re integrating more OSS into larger systems, and they’re co-developing OSS.

“People are increasingly realizing that there are ways to address their concerns about OSS. For example, in the paper we noted many concerns about support and warranties; many people incorrectly believed that commercial support is never available for OSS. Yet many vendors provide support for OSS, and in some cases self-support is perfectly viable. People should examine their support options, instead of assuming there are none. Some worried about the risk of low quality or malware in OSS, without understanding that proprietary software has exactly the same risks. As noted in the paper, the solution for both OSS and proprietary programs is clear: particular programs need to be evaluated on their own merits.

“The government is not new to OSS; the Internet exists in part because the government paid for the development and release of the TCP/IP protocol stack as OSS. But instead of isolated incidents, people are starting to seriously consider applying OSS approaches in many other areas, and that’s encouraging.”

Not whether, but how

The report released by DHS is definitely worth a read. While focused on real problems and challenges facing use of OSS by the USG, it has very useful insights for governments around the world. It confirms my growing view, as I’ve written previously, that we are past some of the old debates about OSS. Instead, many governments are today increasingly focused on the “how tos” of open source choices; not “whether” to use it.