Repository navigation
Definition of "percent code released" is ambiguous. When will it be defined? #260
Description
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?
Activity
[-]Definition of 20% is undefined[/-][+]Definition of "20% code publication" is undefined. [/+][-]Definition of "20% code publication" is undefined. [/-][+]Definition of "percent code released" is undefined[/+][-]Definition of "percent code released" is undefined[/-][+]Definition of "percent code released" is undefined. When will it be defined?[/+][-]Definition of "percent code released" is undefined. When will it be defined?[/-][+]Definition of "percent code released" is ambiguous. When will it be defined?[/+]mattbailey0 commentedon Aug 26, 2016
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 commentedon Aug 26, 2016
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 commentedon Aug 26, 2016
Happy to discuss at length but the general requirement for agencies in section 5 (Open Source Pilot) is annual:
mchogan commentedon Oct 12, 2016
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 commentedon Dec 28, 2016
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:
First, the agencies will report their source code inventory through XML
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?