In March of this year, the Obama administration created a draft for Federal Source Code policy to support improved access to custom software code. After soliciting comments from public,  the administration announced the Federal Source Code policy in August.

One of the core features of the policy was the adoption of an open source development model:

This policy also establishes a pilot program that requires agencies, when commissioning new custom software, to release at least 20 percent of new custom-developed code as Open Source Software (OSS) for three years, and collect additional data concerning new custom software to inform metrics to gauge the performance of this pilot.

In an interview with ADMIN magazine, Brian Behlendorf, one of the pioneers of Apache web server and Executive Director of the Hyperledger Project at The Linux Foundation, said that any code developed with taxpayers’ money should be developed as open source.

The White House opens its doors

This month, the Obama administration delivered on their promises and launched www.code.gov, which hosts open source software being used and developed by the federal government.

Tony Scott, the US Chief Information Officer, wrote in a blog post, “We’re excited about today’s launch, and envision Code.gov becoming yet another creative platform that gives citizens the ability to participate in making government services more effective, accessible, and transparent.  We also envision it becoming a useful resource for State and local governments and developers looking to tap into the Government’s code to build similar services, foster new connections with their users, and help us continue to realize the President’s vision for a 21st Century digital government.”

The news received accolades from the open source community. Mike Pittenger, VP of security strategy at open source security company, Black Duck, is among those industry leaders that praise these efforts.

“The federal government spends hundreds of millions of dollars on software development. If agencies are able to use applications built by or for other agencies, development costs are minimized and supporting those applications is simplified, while delivering needed functionality faster,” Pittenger said.

There are many reasons why the US government chose to embrace the open source development model. Lower costs, greater efficiency, improved security and transparency, and more access to developer talent are just some of the reasons companies choose open source software. The government will likely see these same benefits.

When asked about the possible reasons behind this move, Pittenger said, “The obvious reasons are to reduce costs of building and maintaining applications across agencies. In any business, a goal is to minimize the number of components required. In manufacturing, this may result in standardizing the size and type of fastener used to build a product.  In software, this means standardizing on the open source component (and version) being used across applications.”

While not arguing for the “given enough eyeballs, all bugs are shallow” theory, Pittenger said that security eyes are undoubtedly useful and are the source of virtually all open source vulnerability disclosures in the National Vulnerability Database (NVD). It would be beneficial for the government to institute a bug bounty program and encourage responsible disclosure.

Pittenger also added that beyond access to the source code, this policy will also bring more transparency. “Understanding what is being ‘custom built’ can shed light on inside deals where commercial solutions may already exist. Bulgaria takes this a step further than the US in that all contracts for custom software will be available online for public review,” he said.

It will also drive innovation as cross-pollination of talent from different government agencies and external developers will create a massive talent pool. Open source enables collaboration between bright people working for different companies or agencies.

Some caveats

So far, the government is emphasizing the release of at least 20 percent of its custom code as open source. That may not be enough from the perspective of an open source community, but Pittenger argues that  “20 percent is a good start. We need to balance the benefits from open sourcing code with the risks associated with vulnerabilities. Keep in mind that outsourced code may have been written by the lowest-cost bidder. For example, we don’t know if any secure development practices were followed, such as threat modeling, security design reviews, or static analysis. We also don’t know whether the contractors building the software closely tracked the open source they used in the code for known vulnerabilities. My advice would be to risk-rank the applications covered by these policies, and start by open sourcing the least critical. I would argue strongly against releasing code that manages sensitive taxpayer information or code for defense and intelligence agencies.”

All said and done, this is a good start, and we hope that the federal government will remain committed to its open source promises.

To learn more about open source best practices, check out the Introduction to Linux, Open Source Development, and GIT course from The Linux Foundation.