The White House and the federal government will begin to make a major commitment to open-source software this summer. While the government has long used open-source software and tools, a new proposal out of the White House last weekend suggests that governmentally written or commissioned software should be released under free and open-source licenses.

The paper, titled “Federal Source Code Policy — Achieving Efficiency, Transparency, and Innovation through Reusable and Open Source Software,” specifically calls for all governmental agencies to begin open-sourcing and sharing their code, starting this July: 90 days after the release of this paper.

“Furthermore,” read the report, “even when agencies are in a position to make their code available on a Government-wide basis, they do not routinely make their source code discoverable and usable to other agencies in a consistent manner. These shortcomings can result in duplicative acquisitions for the same code and inefficient spending of taxpayer dollars. This policy seeks to address these challenges by laying out steps to help ensure that new custom-developed Federal source code be made broadly available for reuse across the Federal Government.”

From the paper: “Within 90 days of the publication date of this policy, the Administration will launch Project Open Source, an online repository of tools, best practices, and schemas to help covered agencies implement this guidance. Project Open Source will be accessible at https://project-open-source.cio.gov.

Project Open Source isn’t just about releasing code to the public, either. It’s about getting the government’s repositories in order, and about engaging with existing open-source communities while contributing back to them. This all plays into the desire to share code across government agencies.

“Accessible repositories for the storage, discussion, and modification of custom code are a critical portion of both the Government-wide reuse and OSS pilot program portions of this policy,” read the paper. “Covered agencies should utilize existing code repositories and common third-party repository platforms as necessary to comply with this policy. Project Open Source will contain additional guidance on using custom code repositories as related to achieving the objectives of this policy.”

While this new policy does not cover all source code — there are a number of exceptions that will keep sensitive software out of the public domain — it does stipulate that all participating agencies shall release at least 20% of their custom software each year. Covered agencies are strongly encouraged to publish more than simply 20%.

This is all part of a pilot program that will be running for the next three years. This program across agencies will be evaluated in two years for possible continuance, based on metrics that will be established this summer.

Within the United States General Services Administration, 18F is a growing group of technologists, designers, and researchers from around the country who are committed to making government services simpler and easier to use. The group has created a number of federal-level applications, such as College Scorecard, a website and API for federally held college information that had previously been inaccessible to families at large.

18F content designer Britta Gustafson commented on the White House’s policy on the 18F GitHub page. Specifically, she called for changes to section 5.2f of the policy, which stipulates all governmentally created open-source repositories include, at a minimum, a README-like file that describes the purpose, status, expected engagement level, license details and technical details on how to build/make/install the software.  

Gustafson asks that these requirements be loosened to lessen developers’ workload. “When this policy is finalized and agencies begin implementing it, … agencies will learn a lot about effective open source project management through real life experience, and it’ll be helpful to be able to quickly iterate on these documentation requirements. Listing detailed requirements in the policy is risky — it means the policy can’t respond to real-world experiences in a flexible and agile way. Writing good documentation requires iterating a lot based on user needs and user testing, like good software development, and these components are good ideas but seem to be untested at a large scale.” ( https://github.com/WhiteHouse/source-code-policy/issues/85 )

Jeffrey Hammond, vice president and principal analyst at Forrester Research, said of the policy paper, “One of the things that jumped out at me was the goal 20% open source use in the next two years as part of their pilot program. That’s a big commitment. The big thing is that they put open source on equal footing with commercial software here. They say there should be no preferential treatment because of the license type.”

But just as telling were the omissions, he added. “They didn’t talk about what licenses to use. One of the things I advise clients to do is take a look at the licenses and put some policy statements together for what licenses are usable under what terms,” Hammond said.