I have been a Government contractor and software developer for over 15 years. I have worked on projects where code wasn’t shared with anyone outside the development team to open source projects funded by the government (Ozone Platform). The Federal Source Code Policy could be monumental for advancements in technology and innovation by empowering open communication and collaboration with the largest producer of software in the world.
Below is my feedback on the policy (https://sourcecode.cio.gov/) which was posted to GitHub at https://github.com/WhiteHouse/source-code-policy/issues/237
Feedback on Potential Challenges:
- Prevent all from Actively Protecting Silos
Both government employees and contracting companies’ aggressively protect their silos of information. Contracting companies stamp proprietary information on documents or code they produce in an attempt to prevent other companies from gaining technical knowledge and experience on specific projects. They believe this gives them an edge on competition when in reality it only contributes them producing lower quality software. The policy should address how to incentivize both federal employees and contractors to do the opposite and prevent unnecessary labeling of proprietary information on documents and code that should be sharable throughout the government. - Secure the data Free the Code
In my 15 years of working on multiple software projects, I have never seen a line of code that couldn’t be publicly released or declassified. I am sure there are a few but in my experience it’s the data that needs to be secure and not the code. Project that are built with open source in mind can set configuration files/variables that enable different setting for open source and other custom deployments use by the government. - Innersource
For those projects that have code that can’t be made publicly available via an open source model they should be required to follow an innersource model and leverage open source principles within their organization/agency – https://www.inner-sourcing.com/ . This would at least give the government the benefit of sharing code and information internally. Unfortunately because of the silos mentioned above it is not uncommon to find to large development efforts building the same thing without either team even knowing the other one exist. - Culture Change
This should focus on all agencies as focusing on specific agencies would certainly be less effective. Small groups within agencies can show the benefits and successes and start to change the culture for the better. Start small and grow organically.
Last week I received a copy of a software project that a government agency shared and was requesting feedback on. While I was excited to see the effort was being shared and feedback was being requested the source code was being shared via a zip file. 1 step forward, 2 steps back. How can we openly collaborate and share when we continue to share code via email and zip files. Public repositories for source code enable government developers to write code at their government office just like they would at home with all the power and collaboration of the internet. - Rapid Release Cycles could be problematic for budgeting and acquisition
Budgets and acquisition are typically done in 5 or more year increments. This is one of the main reasons many government project and programs are still doing waterfall software development. They need specific version numbers for software that will be released over the next 3 years so they can get approvals for deployments. More education and training needs to be done in the area of DevOps specifically continuous deployments with zero down time. - Difference between Contractors and Federal employees
Some contractors aren’t allowed to release code to open source – Is this true? Why? How can we change this so that all government contractors can contribute to open source while actively supporting a government program. Currently, the majority of software solutions used in the Federal Government are developed by contractors or third parties. How can this policy be expanded to all Federal employees and include third party contractors that develop software for the Government? Can contracts be written specifically to allow employees of companies that win software development contracts to contribute to open source?
Section 6 Code Inventories and Discovery
I would encourage those that implement this policy to look at the Ozone Platforms implementation of a search and discovery application store. The Ozone platform is a government funded open source project that provides a virtual environment for cataloging and sharing applications for search and discovery of enterprise assets, similar in functionality to commercial App Stores.
90% or more of the functionality needed to host a search and discovery website for government open source projects is already there. If this were to be used it would have the added benefit of being something the government already paid to implement. https://github.com/ozone-development/ozp-documentation
Feedback from others that I agree with
- GitHub is great, I used it for work, for play, and for education. I do agree with FSF recommendation to be cautious of becoming dependent on one specific commercial website.
- Open by Default makes more sense the an arbitrary 20% that would be extremely hard to track
- Why is this only being considered as a Pilot?
