Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Comments from GitHub #165

bkeepers opened this issue Apr 12, 2016 · 0 comments


Copy link

commented Apr 12, 2016

I'm Brandon Keepers and I lead up GitHub's open source efforts. GitHub is home to the largest community of open source developers in the world, with over 14 million people contributing to 35 million projects on GitHub since 2008. We've seen the principles of open source—like transparency and code reuse—transform companies and governments alike.

Congrats to the Federal CIO, the team, and all in the government who are investing in crafting a thoughtful and complete source code policy. This is a great step towards a more open and involved government. Bringing the conversation to the citizens in an open and transparent fashion, on venue that many of the stakeholders already use, provides a great insight into Democracy in action. Thanks for all of your hard work with this policy. Now, for some specific thoughts:

Key Points

  • In OSS Pilot Program (L26), the percentage of Government funded code that should be required to be dissemenated as part of the pilot is listed as 20 percent.
    • We believe, like many others have said (#73, #90), that all Government code should be open source be default. We understand that exceptions will still require that not all code be Open Sourced, but we believe that without restrictions, the public will benefit most from access to all software product.
    • However, we understand that such change to many goverment programs will be a process, so we would instead suggest a more reasonable amount of 50 percent used for the pilot instead.
      • This provides a larger sample size than the initial 20 percent to include more complex and problematic projects.
      • This also provides a greater incentive for agencies to think Open Source first, not as a by-product.
      • This will also support a more accurate comparison between non-released code and provide a more representative sample of released code.
      • Finally, this continues to get closer to where only Exceptions are allows to be exempt from the policy, which will have the facility to provide proper oversight over these decisions.
  • In Implemenation, Exceptions(L38), the policy allows for exemptions for code that is not requried to be released as open source or reusable internally.
    • This policy does not present a maximum number of projects that may meet this threshold. In the past, exceptions and waivers have proven to be easier to obtain than envisioned, and this policy could better protect itself from that by making explicit their expectations.
    • While this policy does allow for some metadata to be redacted when describing for inter-government usage, it does not say what metadata can not be redacted. While the full set of metadata has not yet been decided, this policy should reserve the right to require certain fields be completed accurately.
    • By having accurate metadata, only then will each CIO be able to accurately measure the 20% of open source requirement. By redacting details about un-provided projects, any calculation will be inaccurate.
    • Discussion #86 also provides good points on this topic.
  • In Implemenation, Exceptions(L38), source code is divided into two groups, that which can be released, and that which meets exception criteria and can not.
    • Much like the government has already established that patents are not permanent, require renewal, and eventually will expire into the Public Commons, so should these exceptions.
    • Ways to encourage more release to Open Source would be specify that certain exceptions apply for a set period of time, and upon their expiration, the code shall be released.
    • Additional options would be to require each exception to be re-evaluated after a set period of time to see if the exception is still necessary.
    • These techniques continue to place the burden of effort on those who wish to maintain an exception, not those who wish to release federal funded effort to the public.
  • In the Index(L44), the question is raised about how best to handle security and privacy of this policy and its outcomes.
    • A portion of this is in education, and recognizing outliers as just that. We highlight the comments expressed in #89
    • This policy separates the pilot programs code release (5.1) from the Government's responsibility in Open Source participation and membership (5.2). This should be listed as an expectation of the code release, not as a separate task. This should be edited to include discussion about participating, maintaining, and growing all open sourced codebases. We highlight the comments expressed in #121.
  • In OSS, Pilot Program(L24), this policy is extended to all covered agencies.
    • We support #91 and extending the open sourcing and code reuse ideas, requirements and protections of this policy to any state or local government that is developing software paid for by Federal funds.
    • As each state or local government may not have the expertise to implement the necessary systems themselves, the federal government should provide the necessary mechanisms for them to comply, including centralized version control, metadata repository with discovery capability, and guidance on how to participate in the open source community.
  • In OSS,Overview(L10), it is discussed how releasing APIs is a recognized goal of this policy.
    • Releasing and Maintaining an API should be given the same resources and expectations as maintaining released source code.
    • This includes Governance and Open Source best practices for not just the government participants but the new community as a whole.
    • The government has not always been successful with this in the past. In #125, the discussion about the Common Map API is an example of a community that did not grow to its full potential
  • In Implementation, Project Open Source(L14), Project Open Source is described as a new endeavor to provide guidance, metrics, and a community resource. We believe that this may be a tougher that is to be expected.
    • Metrics will be very hard to evaluate when comparing the success of released code to non-released code. Much of the return from the released code won't be realized with the Govt itself, but instead the citizens and other organizations who can reuse the code.
    • Open source creates intangible benefits (e.g, transparency, good will), and facially counterintuitive tangible benefits (e.g., if the number of bugs go up, that's likely because more were detected, not because more were created), thus any objective metric is inherently flawed
    • The Government by definition, a group that has traditionally not embraced inner- and open-sourcing of software, will not have the breadth of subject matter expertise to execute on this tasking. We would encourage Project Open Source to include a mix of members from within the Government and the Public. Organizations that have done these tasks successfully in the past should be involved to share their insight explicitly.
  • In Government Open Source, membership(L34), responsibility is defined for covered agencies. We believe this responsibility should be better defined, and encouraged to be solidified in a agency-level role or office, who can better advocate for these requirements.
    • Commerce has shown success with their Chief Data Officer and their Commerce Data Service to implement the Open Data Policy.
    • The National Geospatial Agency (NGA) has provided guidance and shown success in promoting their public releases via the GEOINT PathFinder initiative.
  • In Objective 2(L14) and other sections, there is mentions of source code, but this should be clarified to not include documentation, tests, and all other related software assets. This should also include metadata used for code inventory and discovery as well.
  • In Procurement, Alternative Analaysis(L14), it is not mentioned who has the oversight to ensuring a thorough analysis has been completed, and what the repercussions are for failure to do so.
  • In Procurement, Customer Development(L18), provisions are outlined when procuring new solutions to preference that which the government already has license for. However, often solutions are unique in their sum, but made up of common pieces. The policy in it's current form does not provide any incentive or requirement for code reuse in those situations.
  • In Reuse, Requirement 1(L14), delivery should be clarified in a digital, editable format (no pdf, no hard copy). As mentioned in #123, this would ideally be in a valid, modern version control format where full history can be provided, and additionally all meta-data, issues, feature, and conversation related to the source code. Being more specific will reduce confusion during implementation

We thank you again for your work with this policy, and look forward to the released policy incorporating the great feedback over the last month.

❤️ :octocat:

@chasingamy chasingamy closed this Apr 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.