Internal:Public Policy/Federal government Open Source Policy

Workspace: Public policy

In early March 2016 OMB announced a new Open Source Policy applying to federal agencies. Public comment is invited till April 118 (after an extension) Wikimedia DC should comment.

Draft comment for review by public policy committee

This <draft> post represents Wikimedia DC, the chapter affiliated with the Wikimedia Foundation in Washington DC, Maryland, Virginia, Delaware, and West Virginia.’'

We think the proposed policy is an excellent step forward. There is much value to be gained broadly in the free and open source ecosystem from greater federal staff and contractor participation in communities such as those developing the Wikimedia projects. Using such software and participating in its development helps bring open standards into use quickly and broadly.

Designers of the policy left substantial space for government agencies to make the decision not to open source a variety of software projects, and to focus on 20% of projects or code beyond the exceptions. This makes sense to us. There is no great benefit from posting code that its authors do not wish to post, descending sometimes from much older projects in languages that are not in wide use among open source communities. The great opportunity here lies in the the many government staff who are ready to post code that matches up with broad external free and open-source projects and standards, but whose agencies do not yet encourage it.

<Public policy committee, please comment!>

Preparatory notes

What we're commenting on

• The invitation for public comment -- they're inviting the format of github issues which we might or might not find convenient
• Source Code Policy draft -- 15 page PDF. I think this is the main thing we are supposed to comment on. Lines are numbered inviting precise commentary.
• Tangentially, the draft policy fills in a promise in the 2nd "Open Government National Action Plan" which slots it into a venue for other national governments to copy it or count it as admirable progress toward open government. We do not need to follow up on this angle for this comment period, but Peter may add links or notes.

Questions we are asked to consider

• 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?

Peter's comments, mostly done already

• See old versions of this page or Peter's posts to the issues list on github
• on page 1, line 23: "challenges" doesn't quite describe what's to be addressed ; perhaps "opportunities for improvement" is better
• page 1, footnote 7: "vendor lock-in" is a bit narrowly defined here; we might note also that it can create mismatches in hiring ; they might cite Varian & Shapiro's Information Rules here
• Peter to invite comment from Open Source Practices team at work and possibly also Public Policy listserv from the foundation.
• the policy refers to source code procured by the govt meaning custom-developed ; and to source code developed by the govt
• line 174: agencies procuring software source code must make it available to other agencies. interesting.
• footnotes 8 and 24 are too much the same
• record definition of OSEHRA, line 208
• three year pilot program pushing the agencies hard toward OSS:

• line 229: each agency shall release 20% of newly-developed source code -- and some agencies develop a lot
• lines 240-242: "all new custom code developed by covered agency employees as part of their official duties shall be released to the public—subject to certain exceptions—as enumerated in Section 6" -- but wait, what about one-time research? you mean all CPI code too?

• line 414-5: "Excepted software must still be listed in the agency’s enterprise code inventory" -- this suggests that a public database will have this inventory, but I didn't catch that elsewhere in the document
• line 415-6: "certain redactions allowed. Please refer to Project Open Source for additional guidance on this topic." -- when we find the relevant sections at Project Open Source, list them above as source materials for possible comment
• lines 465-466: the binding definition of “Open Source” is coming from the Open Source Initiative (https://opensource.org/osd).