Definition of "percent code released" is ambiguous. When will it be defined?

[rafael5]

Section 5.1: Pilot Program: Publication of Custom-Developed Code as OSS states:

"Agencies should calculate the percentage of source code released using a consistent measure—such as real or estimated lines of code, number of self-contained modules, or cost—that meets the intended objectives of this requirement. Additional information regarding how best to measure source code will be provided on Code.gov."

Without a clear, enforceable metric, it will be easy for each agency to either provide meaningless statistics which each agency makes up differently, or at worse agencies will simply ignore the policy, all without any consequence.

Do we have any when the team at code.gov is going to create this clear, measurable, enforceable technical language regarding percent code released?

[mattbailey0]

Hi again. Per section 7.3 of the policy Code.gov is required by the policy to be launched "Within 90 days of the publication date of this policy."

[rafael5]

This would leave agencies only 30 days to implement the policy, since they have only 120 days from the publication date of the primary policy, but have to wait 90 days for code.gov to complete the definitions and requirements?

Or will agencies have 120 days to implement the policy after the code.gov site is fully operational, with all technical definitions, requirements, and metadata requirements resolved?

[mattbailey0]

Happy to discuss at length but the general requirement for agencies in section 5 (Open Source Pilot) is annual:

Each agency shall release as OSS at least 20 percent of its new custom-developed code29 each year for the term of the pilot program

[mchogan]

Basing the 20% definition on packages or modules (things managed by package management software like yum, apt or npm) fits well with the goal to increase reuse of software.

Lines of code is an inappropriate metric, ambiguous, subject to inflation and seems unaligned with the reuse objective of Code.gov.

[mikeBeviBevi]

Question, are we ignoring all new code that is made on existing projects? I'm not sure if we want to do this or not. For one, sometimes new projects end up being folded into existing systems for business purposes and could end up masking actual new work.

Also, the content of packaging and modules is very dependent on the subjective design of the code base. I can guarantee you that their is allot of source code that is not broken up neatly into reusable packages. In many cases it would not make any sense, from a business stand point, to invest the time and funding into re-designing that software. I think it would make more sense to try to enforce this on some percentage of new source code, but again, how the designer breaks the code up into modules is subjective. This policy did talk about the XML used to catalog software, and agencies are to use that to make their reports. I believe:

1. First, the agencies will report their source code inventory through XML

2. Then enforce this OSS rule on 20% of the entities reported in the XML.

Also, without some waiver program I do not think the current 120 days is not enough time with current employee base, imo.

Is their a plan for developing training material and administering that training agencies on how to comply with this order?