Closed jackiekazil closed 8 years ago
This proposal will make a great difference with respect to the long term viability of the overall proposal. Forcing individuals or project managers to select an arbitrary 20% of a code base to be published in open source would, I my opinion, be counter productive to the goals of the initiative.
John Teeter
impressive!
I used to work at a national science lab as a software developer. The policy in the national labs is "open by default."
I saw firsthand that this policy was a boon to collaboration, sharing, software quality, and long-term sustainability. I believe it should be adopted throughout the government.
Outstanding, pushing the limits, a great example for other countries to follow , +1!
Yay!!
Code for America supports open source as the default. We and 18F recently worked with the State of California on an RFP which used the following language:
The Child Welfare System will use open standards, commodity open source components and tools when they're available. All new source code will be made open and reusable and published with an appropriate license. Where there aren't open standards or open source components, we'll consider proprietary standards against the tradeoff of a long-term open, maintainable system that the state can direct and control. We intend to release the code created under this effort as an open source product.
This sets a higher goal than 20% and this community should think about this as precedence for federal, state and local policies.
This is excellent! Woot woot
Well done, "open sourcing" 20% of a working system is not open sourcing the system.
I could understand a directive to organizations who have not operated in a free software/open source context before, allowing them to try one major project in an open source manner to learn the practices and challenges. This would be preparatory to an open-by-default strategy, as people on this thread have recommended. But 20% is totally arbitrary and provides no help for agencies who need to learn open source practices.
I believe that making souece code FOSS licenced by default will reduce the barrier to entry. Adding an arbitrary 20% target adds an additional managerial burden that would be better spent on only identifying the core, truly sensitive parts of a code base.
Agreed that "open by default" should be the policy. 20% is arbitrary and seems like it could become yet another quota to meet.
Another thing to consider in both "open by default" and "at least 20%" is the guidelines for which it is acceptable for a piece of software to be not FOSS. The process for determining what is released as open and what is not should be unambiguous.
As one of the above-signed members of the inaugural class of Presidential Innovation Fellows, I would like to further expand upon why government software should be open by default, rather than the government only making a small subset of taxpayer-funded and taxpayer-owned code available to the taxpayers who made its development possible and for whom the software is intended to benefit:
Open source is in your best interest, whether you're an individual, a corporation, a small business, a non-profit, or a government agency:
Lower total cost of ownership (TCO) - Using open source software yields a lower total cost of ownership when compared to closed source and proprietary alternatives. Adopting open source software generally has a lower up-front cost (because the software often comes at no cost or relatively low cost), and shifts the cost center from licensing (an operating expense) to customization and implementation (a capital expense). Additional costs like training, maintenance, and support are sunk costs. You're going to be paying for both regardless of if the software is open or closed source, the cost often being baked into the license in the case of commercial, off-the-shelf software (COTS). What makes open source unique is that you're not paying for the right to use the underlying intellectual property.
Cost | Open source | Proprietary |
---|---|---|
Licensing | :x: | :heavy_check_mark: |
Implementation | :heavy_check_mark: | :heavy_check_mark: |
Maintenance | :heavy_check_mark: | :heavy_check_mark: |
Support | :heavy_check_mark: | :heavy_check_mark: |
GitHub Cofounder Tom Preston-Werner (@mojombo) lays out some additional arguments in his post Open Source (Almost) Everything:
By combining and augmenting parallel or related efforts, open source makes a society more efficient at producing higher quality software:
The formal name for open source is free/libre open source software. As such, open source motivations have a strong moral component:
Free as in speech, not as in beer - Open source software is not without cost. When open source software is called "free", it is a reference to the rights the software consumers receive, not the cost they must pay. Adobe's Flash player, for example, is free software in the economic sense, but is still at the core of proprietary (non-free) software (and formats). Specifically, free software refers to four core freedoms: the freedom to run the software, the freedom to study and modify the software, the freedom to redistribute the software, and the freedom to distribute your modifications.
As the Free Software Movement argues, non-free software risks software that can control the user (with the publisher controlling the software). This creates the potential for the software becoming an instrument of unjust power. Today, it's not uncommon for proprietary software to spy on users (e.g., phoning home), to restrict them (e.g., DRM), to censor them (e.g., corporate firewalls), or to take advantage of them (e.g., unskippable commercials). This becomes even more important as the internet of things emerges, and risks turning the world into "the internet of telemarketers" or "the internet of snoopers". Free software places power back in the hands of users and ensures users control the software they use, not the other way around.
Open source allows for greater transparency of process, whether that's the transparency necessary to check a government action or the quasi-governmental function of a private company's software.
Open source affords software stakeholders, both technical and non-technical, the opportunity to shape any given software development project:
If you're a developer (or an aspiring developers), open source can provide an easy (and free) onramp to and path for personal growth within the software development community:
Additionally, I would also like to include @david-a-wheeler's canonical paper, "Why Open Source Software", by reference as part of my comment.
Open source isn't the next big thing. Open source is already here.
Also to note, it is unclear, what percentage of new government software projects, today, are open source. Anecdotally, I'd suspect that of new projects, as many as 10-20% may already be open source. Thus, a 20% open source mandate (potentially only a 10% increase over the status quo) may not provide an accurate experiment, if it does not sufficiently differ from the control. While, as stated above, I believe the policy should be "open by default", both politically, and in terms of adequate testing, requiring that 50% of all software be open source would provide a more accurate A/B test to gauge the impact of the experiment on government IT and the broader software development ecosystem.
I'd like to suggest one additional reason why the policy should mandate that code be "open by default", rather than creating a three-year, 20% pilot to evaluate its effects of such a policy. In September 2014, the president, at the United Nations, expanded his commitments under the Second Open Government National Action plan to include the following:
Adopt an open source software policy. Using and contributing back to open source software can fuel innovation, lower costs, and benefit the public. No later than December 31, 2015, the Administration will work through the Federal agencies to develop an open source software policy that, together with the Digital Services Playbook, will support improved access to custom software code developed for the Federal government.
(Emphasis original)
That comittment, along with the statement that "open source software can fuel innovation, lower costs, and benefit the public" is repeated in the very first line of this policy. There are two reasons why the policy, as currently stated, fails to live up to the president's commitment:
Open by default has its advantages as noted by many comments above. However, there are important considerations project managers must appreciate when promoting the policy. A few of those are:
beyond just open by default, this policy needs to be looked at as a way to simplify delivery for the contractor AND the contracts officer and government technical folk. Make it easy and everyone wins
I'm Ian, a Computer Engineer at Lawrence Livermore National Laboratory, working on consolidating and showcasing the open source development performed by our staff. This comment represents my views, not necessarily those of LLNL.
From @benbalter comment: https://github.com/WhiteHouse/source-code-policy/issues/90#issuecomment-208013645
Also to note, it is unclear, what percentage of new government software projects, today, are open source. Anecdotally, I'd suspect that of new projects, as many as 10-20% may already be open source. Thus, a 20% open source mandate (potentially only a 10% increase over the status quo) may not provide an accurate experiment, if it does not sufficiently differ from the control.
Another issue with the 20% rhetoric which I was going to open as a separate issue before I found #47, #106 and item # 14 of https://github.com/WhiteHouse/source-code-policy/issues/152#issuecomment-208538722, is how to define this 20%? Even if a metric can be decided upon (# of projects and SLOC are two mentioned in #47), how would these be measured / reported / verified? And how does one define a "project" or even a line of code? Etc, etc...
Therefore I believe that a greater push towards "open by default" language is a good one. That said, I do believe that if the policy does move in that direction there should be clarification given to what is excluded (there will always be some things excluded, such as for national security or internal infrastructure (think passwords, database connections, etc) reasons) and who would review such exclusions. Something similar to the 18F Open Source Policy Exceptions would be a good first cut.
This policy should say open source software by default. I think also including 20% is a good idea, but it would be far better to do both. It is important to define how to measure 20%. I think that the best metrics is dollars. Dollars are easy to measure, and easy to add up.
@CGIFederalInc if tax dollars sourced from the American public are spent on software contracted by and used by the government, why wouldn't it be open by default? Photographs taken by Presidential photographers are public domain, photographs created by NASA are public domain, and there's a huge amount of information available under the public domain through US Government Works.
I understand that this would add overhead to projects, but it would also likely improve much of the software used by the government. If security vulnerabilities are discovered, reported, and fixed by open source contributors, then they are well worth the tax dollars. If usability issues are easier to report, or even for external parties to fix, that's a great use of tax dollars as well!
If a project doesn't have a community grow up around it, there is minimal governance overhead to worry about. Government open source projects would be able to reuse the same rules across most, if not all, projects.
That said, thank you for offering a counter-argument, open source is certainly not a perfect solution, but I do believe it's far better than the current situation.
(I am Patrick Dufour, a Humanitarian Information Specialist & Data Engineer with about 5 years experience working with government contracting and open source software. My comments only represent my views.)
In regards to comments made by @CGIFederalInc, I have a few comments.
Within the policy under consideration, I do agree that "OSS Governance overhead" is worth explictly mentioning since government managers may bring it up. However, it should be mentioned as a cost inherent in following modern best practices and the policy should also mention that it shall not be construed as a valid reason for not open sourcing code
.
Additionally, if following modern devops workflows (Ansible, Packer, etc.), the publishing of project-related artifacts should be a trivial task and not require extra undue burden.
In regards to "open by default", I have a few comments.
There have been tangible limitations to the effectiveness of the "open by default" principle on open data. "Open by default" provides some negative incentives for discovering all the silos (leads to more work). However, the benefits of "open by default" have been incalculable. For open data, what's most important is not releasing ALL the data, but releasing the highest-value datasets. The White House "open by default" directive provides significant support to the pro-release side in internal deliberations about a dataset. Alltogether, "open by default" provides the right incentives.
For open source software, what should be most important is releasing the best reusable code. A 20% mandate will necessarily incentivize centralization of open source code management to reduce the reporting burden on IT management (e.g., 1 GitHub organization). It will also provide negative incentives for modularizing code.
On the other hand, "Open by default" increases support for a decentralized approach, which appreciates that many agencies and offices are already sharing opensource code. "Open by default" will incentivize broad engagement with open source communities at a developer-level, which is more inline with the spirit of the policy. "20%" provides no similar positive incentives.
Open by default is far superior to 20%.
The Presidential Innovation Fellows Foundation (PIFF) has been following this conversation very closely. As the current member-elected President, I wanted to share that an overwhelming majority of respondents to an internal dialog stand by the following statement:
The PIF Foundation membership strongly believes that it is in the best interest of increased government efficiency and taxpayer savings for the OMB to set a policy of 'open by default' for custom software developed by the Federal Government rather than setting a goal of at least 20% OSS as originally proposed in the source code policy: https://sourcecode.cio.gov/ .
This statement was supported by 34 of our members, opposed by 1, with one abstention.
More about PIFF: The PIFF has approximately 120 members. The PIFF is a membership corporation registered in Washington DC with 501c3 Status. Our bylaws restrict our membership to Presidential Innovation Fellows serving for at least 6 months. Fellows are industry-leading innovators chosen via a very competitive process. Many Fellows have gone on to retain important positions in the Federal government, and others have returned to private industry.
Sincerely, Jackie Kazil Member-elected President Presidential Innovation Fellows Foundation