United States Releases Draft National Open Source Software Policy

IMG_1256On September 23, 2014, the White House announced that the United States would create an official policy for open source software. Today, the nation took a big step towards making more software built for the people available to the people.

“We believe the policies released for public comment today will fuel innovation, lower costs, and better serve the public,” wrote U.S. chief information officer Tony Scott in a blog post at WhiteHouse.gov, announcing that the Obama administration had published a draft open source policy and would now take public comments on it online.

This policy will require new software developed specifically for or by the Federal Government to be made available for sharing and re-use across Federal agencies. It also includes a pilot program that will result in a portion of that new federally-funded custom code being released to the public.

Through this policy and pilot program, we can save taxpayer dollars by avoiding duplicative custom software purchases and promote innovation and collaboration across Federal agencies. We will also enable the brightest minds inside and outside of government to review and improve our code, and work together to ensure that the code is secure, reliable, and effective in furthering our national objectives. This policy is consistent with the Federal Government’s long-standing policy of technology neutrality through which we seek to ensure that Federal investments in IT are merit-based, improve the performance of our Government, and create value for the American people.

Scott highlighted several open source software projects that the federal government has deployed in recent years, including a tool to find nearby housing counselors, NotAlone.gov, the College Scorecard, data.gov, and an online traffic dashboard. platform, and the work of 18F, which publishes all of its work as free and open software by default.

The draft policy is more limited than it might be: as noted by Greg Otto at Fedscoop, federal agencies will be required to release 20 percent of newly developed code as open source.

As Jack Moore reports at NextGov, the policy won’t apply to software developed for national security systems, a development that might prove disappointing to members of the military open source community that has pioneered policy and deployment in this area.

The draft policy sensibly instructs federal agencies to prioritize releasing of code that could have broader use outside of government.

The federal government is now soliciting feedback to the following considerations regarding its use of open source software.

Considerations Regarding Releasing Custom Code as Open Source Software

  • To what extent is the proposed pilot an effective means to fuel innovation, lower costs, benefit the public, and meet the operational and mission needs of covered agencies?
    • Would a different minimum percentage be more or less effective in achieving the goals above?
    • Would an “open source by default” approach that required all new Federal custom code to be released as OSS, subject to exceptions for things like national security, be more or less effective in achieving the goals above?
    • Is there an alternative approach that OMB should consider?
  • What are the advantages and disadvantages associated with implementing this type of pilot program? To what extent could this policy have an effect on the software development market? For example, could such a policy increase or decrease competition among vendors, dollar amounts bid on Federal contracts, or total life-cycle cost to the Federal Government? How could it impact new products developed or transparency in quality of vendor-produced code?
  • What metrics should be used to determine the impact and effectiveness of the pilot proposed in this draft policy, and of an open source policy more generally?
  • What opportunities and challenges exist in Government-wide adoption of an open source policy?
  • How broadly should an open source policy apply across the Government? Would a focus on particular agencies be more or less effective?
  • This policy addresses custom code that is created by Federal Government employees as well as custom code that is Federally-procured. To what extent would it be appropriate and desirable for aspects of this draft policy to be applied in the context of Federal grants and cooperative agreements?
  • How can the policy achieve its objectives for code that is developed with Government funds while at the same time enabling Federal agencies to select suitable software solutions on a case-by-case basis to meet the particular operational and mission needs of the agency? How should agencies consider 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 support?

If you have thoughts on any of these questions, you can email sourcecode@omb.eop.gov,
participate in discussions on existing issues on Github, start a new one, or make a pull request to the draft policy on Github. You can see existing pull requests here and view all comments received here.

With this policy, the White House has fulfilled one of the commitments added to the second National Action Plan for open government in the fall of 2014. While there has been limited progress (or worse) on of the dozens of other new and old commitments made in the three action plans published to date, this draft open source policy is a historic recognition of the principle that the source code for software developed by government agencies or contractors working for them can and should be released to other agencies and the general public for use or re-use.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.