{"action":"opened","issue":{"url":"https://api.github.com/repos/WhiteHouse/source-code-policy/issues/236","repository_url":"https://api.github.com/repos/WhiteHouse/source-code-policy","labels_url":"https://api.github.com/repos/WhiteHouse/source-code-policy/issues/236/labels{/name}","comments_url":"https://api.github.com/repos/WhiteHouse/source-code-policy/issues/236/comments","events_url":"https://api.github.com/repos/WhiteHouse/source-code-policy/issues/236/events","html_url":"https://github.com/WhiteHouse/source-code-policy/issues/236","id":149237485,"number":236,"title":"Email Comment: Accenture Federal Services Comments on Pilot Program, Metrics, and other considerations","user":{"login":"OMBPublicComments","id":15910675,"avatar_url":"https://avatars.githubusercontent.com/u/15910675?v=3","gravatar_id":"","url":"https://api.github.com/users/OMBPublicComments","html_url":"https://github.com/OMBPublicComments","followers_url":"https://api.github.com/users/OMBPublicComments/followers","following_url":"https://api.github.com/users/OMBPublicComments/following{/other_user}","gists_url":"https://api.github.com/users/OMBPublicComments/gists{/gist_id}","starred_url":"https://api.github.com/users/OMBPublicComments/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/OMBPublicComments/subscriptions","organizations_url":"https://api.github.com/users/OMBPublicComments/orgs","repos_url":"https://api.github.com/users/OMBPublicComments/repos","events_url":"https://api.github.com/users/OMBPublicComments/events{/privacy}","received_events_url":"https://api.github.com/users/OMBPublicComments/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-04-18T18:47:32Z","updated_at":"2016-04-18T18:47:32Z","closed_at":null,"body":"On behalf of Accenture Federal Services, please find the below feedback on the OMB’s OSS Policy.\r\nThank you for reviewing and considering this feedback.\r\n\r\n*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?*\r\n\r\nA smaller, targeted pilot leveraging a handful of government agency projects should be able to provide an effective means to fully understand the costs and benefits associated with a full implementation.  As there is significant effort to execute the pilot across all government agencies, a more focused pilot would allow for a faster identification of the impacts associated with contracting, releasing, managing, and maintaining OSS at a government agency.  There exists the potential that application contracts may need to be adjusted or lengthened to account for these additional efforts.\r\n\r\nDue to those potentially significant efforts, this effort could also be achieved with the evaluation of existing source code at a smaller sampling of agencies to identify the cost feasibility and value of releasing it as OSS.  The identified outcomes of that process could then be evaluated against the costs of achieving better decisions in procurement and the encouragement of government-wide reuse of government procured code.\r\n\r\nStarting small and moving to a broader set would allow early refinement of the process to open-source software.  There is a potential that each government agency could take a different approach to the execution of the pilot and achieve vastly different results.\r\n\r\nIn the section regarding government reuse of code, the policy states:\r\n“Government-wide reuse of custom-developed code shares some of the same benefits as OSS, it does not meet the definition of OSS and should therefore not be mislabeled as such.”\r\nThis indicates that the primary benefit of this policy should be toward promoting government reuse and secondarily, when it does make sense, to OSS licensing of government source code.  The establishment of a cross-agency open source initiative should lend to the identification of liquid, reusable components across agencies.  Achieving this goal may be best accomplished by developing more detailed guidance and criteria that will ensure accessibility and reusability of source code across agencies, rather than setting a specific percentage of software that must be maintained as OSS.\r\n\r\nAlso, the smaller the code segments (objects, micro-services), the more re-usable they will likely be for the next agency or development team looking to assemble like functionality. To incent construction and use of these more consumable widgets, the government may consider requesting that style of development in its requirements statements.\r\n\r\n*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?*\r\n\r\nWhile the draft policy has many benefits, there is a potential for unanticipated risks that should be considered.\r\na) Bad Actor\r\nThe policy describes several \"good actor\" benefits related to bug discovery and contributions of open source software.  The potential damaging impacts related to \"bad actors\" should also be considered. Broad distribution of source code may enable \"bad actors\" to identify and exploit errors in released code with potentially damaging impact to government. These exploits can range from security holes providing unauthorized access, to execution paths that could defraud the government or deny government service. Systems providing government benefits could be exploited to provide benefits to unverified recipients or denial-of-service activities could be performed by actors through the use of an unidentified vulnerability.\r\nb) OSS Release Timing\r\nOpen source projects are born and fostered by communities that typically have an agreed upon set of outcomes for the development roadmap. Most often these communities are very small groups that take the time to nurture and build the offering through alpha and beta releases and work to address publicly identified issues through a governance model.  It is also well known that it may take years for an OSS project to move beyond the alpha and beta releases into proven, stable releases.  OSS sponsors and communities are careful to make sure they are not endorsing their code as stable before it is ready. The timing and approach that the proposed policy has for open-sourcing source code is not clear.  If a project is not afforded the right level of care and time based growth then a recently deployed application could result in faster enablement of the “bad actor” while the “good actor” works to become part of the community.  More eyes on source code is typically a beneficial thing, but if the reviews only begin after an application is live then the potential for damaging impacts is high.  Due to the potential impacts to a project’s schedule and contractual delivery, it is not clear if integrating the release into the development lifecycle is the solution to this.  Yet, to help mitigate the likely scenario of the “bad actor”, releasing the source code prior to a production implementation (like is typical of OSS) would be the better approach.  The OMB should consider open source release guidance as part of this policy.\r\n\r\n*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?*\r\n\r\nThe establishment of quantifiable metrics is a key component to the effectiveness and durability of this policy. The analysis of an existing agency project to determine its reuse and OSS viability would be a best first step to determine the criteria to measure the effectiveness of the policy.\r\n\r\nMetrics that could be used to evaluate the effectiveness of the policy include:\r\na) Community speed to adoption measured in both community size, source code pull requests, and feedback\r\nb) Identified reuse of components in other industries (this may prove difficult to measure) and within the government (as identified by a vendor)\r\nc) Community contributions of both fixes and enhancements\r\nd) The benefits to the government system from the fixes and enhancements in areas such as security, operability, and performance\r\n\r\nThe government may also wish to consider an automated janitor function to eliminate those code packages that have accomplished no reuse over some period (e.g. after two years) to remove the sprawl and focus on highlighting those items in greatest demand.\r\n\r\n*What opportunities and challenges exist in Government-wide adoption of an open source policy?*\r\n\r\nThere are several items relating to the adoption:\r\na) The potential for reuse of government software from between agencies may be lower than expected for most software components as they are typically functional in nature.  The primary value would be in the utilities and periphery components that are used by all agencies including: file transfer components, application frameworks, and integration components.   Placing a focus on categories of components for both government agency reuse as well as OSS would be far more beneficial than applying an arbitrary percentage to all code.  This could be combined with an opt-in program that would allow the government to achieve much of what is desired with this policy.\r\nb) Management of the library and inventory of code will be considerable whether it be for government reuse or OSS.  The government should look to better understand how the OSS will be packaged, distributed, and managed for internal and external consumption. The government could leverage GitHub, BitBucket, Sourceforge, Google Code, or a comparable platform, but an evaluation should be performed regarding longevity and the best approach for ongoing management by agencies.\r\nc) As noted by many responses on GitHub, the selection and application of the correct OSS license for a project is a non-trivial exercise.  The policy should possess guidance to government agencies for the selection of an OSS license for each source code release.\r\n\r\n*How broadly should an open source policy apply across the Government? Would a focus on particular agencies be more or less effective?*\r\n\r\nBeyond the exceptions that the policy has already identified, the fundamental intent of the policy should be universal across all government agencies.  Yet, in the execution of the policy there will be security concerns identified when applying it government agencies that maintain a higher level of security.  These concerns could come in the form of exposure of the public’s personal information lending to fraud or process gaps/loopholes that would only be transparent when reviewing the complete system’s source code.\r\n\r\nA suggestion to help mitigate this concern would be to design the policy to more eagerly encourage the reuse and open-sourcing of source code at FISMA Low entities and implement something less eager for FISMA Moderate and FISMA High entities.  Although this does not fully align with the spirit of the policy, it would aid to reduce the risk of accidental and unintended exposure of sensitive system information.\r\n\r\n*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?*\r\n\r\nThe incremental cost and resource needs for administration of OSS projects would need to extend through to the grant recipient or cooperative agreement participant.  Cost-benefit analysis would be appropriate to determine if the added complexity is justified by the policy’s objectives.\r\n\r\nFScott Van Velsor, Jr"}}