With the presidential election season upon us, I’m often asked whether the U.S. government efforts to encourage use of open source software (OSS) will continue when a new administration comes into office in January.

As I’ve written before, there has been a shift, going back almost a decade, away from the debate over whether to use open source to a focus on the how to. The release by the Office of Management and Budget (OMB) of the U.S. Federal Source Code Policy on August 8th is the latest manifestation of this shift. It achieves the goal laid out in the Obama administration’s Second Open Government National Action Plan (PDF) for improved access to custom software code developed for the federal government. The plan emphasized use of (and contributing back to) open source software to fuel innovation, lower costs, and benefit the public. It also furthers a long-standing “default to open” objective going back to the early days of the administration.

Some have called this an “open source policy.” Certainly, open source is a key element of the policy. But at its core, it is a focus on reducing reliance (and spending less money on) development of custom software. And when custom software is used, the policy encourages steps to make it as widely reusable as possible by contributing back the code that was procured.

The pilot program

Most of the attention during the draft comment period focused on the requirement that “each agency shall release as open source software at least 20 percent of its new custom-developed code each year while the pilot program is in operation,” (Unless reauthorized by OMB, the pilot expires in three years). To achieve this objective, the policy requires that “agencies must obtain sufficient rights to custom-developed code to fulfill the open source release objectives of this policy’s pilot program.”

It is up to the agencies (DOD is not included) to decide which custom-developed code projects to release (after prioritizing the release of custom-developed code that it considers potentially useful to the broader community). But, OMB strongly makes clear that “agencies are strongly encouraged to release as much custom-developed code as possible to further the Federal Government’s commitment to transparency, participation, and collaboration” and “expects all agencies to satisfy the requirements of this pilot program without exception.”

In recognition that the success of an open source project depends on a variety of factors, the policy emphasizes that when agencies release custom-developed source code as open source software to the public, they should develop and release the code in a manner that (1) fosters communities around shared challenges; (2) improves the ability of the open source community to provide feedback on, and make contributions to, the source code; and (3) encourages Federal employees and contractors to contribute back to the broader open source community by making contributions to existing open source projects.

In the end, this specific policy encouragement may be its most important, long-term impact, articulating “practices that provide an environment in which open source can flourish and be repurposed.”

There will be more information to come on licensing at code.gov. Red Hat and others in the community have (and continue) to urge the use of existing licenses, and avoid going down the path of creating government-unique licenses, which would be an impediment to the policy’s overall goal of broad reuse and acceptance, make it more difficult to build developer support for projects, and risk a go-it-alone government-off-the-shelf (GOTS) outcome.

Three-step analysis

As I wrote last spring, the draft on this point appeared to be an attempt to restate current policy, but potentially raised confusion, even the inadvertent risk of encouraging government-off-the-shelf (GOTS) solutions over commercial solutions.

The three-step analysis appears to have been cleaned up. It still includes a reference to preference for an existing federal software solution, and now includes a footnote explaining that “existing federal software solutions” are those for which appropriate rights are already held by the government, which may include commercial or custom-developed software solutions.” Note that the U.S. government has made clear that commercial software includes open source.

The central thrust is to restate long-standing policy to focus on “procurement of existing commercial solutions through best-in-class vehicles identified by category management policies.”

Notably, the published policy emphasizes the wide variety of policies that agencies also need to consider at “each stage of the three-step analysis” in their procurement decision, including hybrid solutions (meaning a mixture of existing federal, commercial, and/or custom-developed solutions); modular architecture (as discussed in the Digital Government Strategy, “modularity can reduce overall risk and cost while increasing interoperability and technical flexibility”); cloud computing; open standards; and targeted considerations (which the policy describes as a software solution that “best meets the operational and mission needs of the agency, taking into consideration factors such as performance, total life cycle cost of ownership, security and privacy protections, interoperability, ability to share or reuse, resources required to later switch vendors, and availability of quality support”).

Conclusion

Kudos to the White House and Federal CIO Tony Scott on getting this published. It is the latest step in the legacy of this administration in recognizing the power and innovation of open source, and decreasing duplicative costs for the same code and reducing federal vendor lock-in.