Originally posted by @fureigh; formatting not preserved
(I’m Fureigh, a developer at 18F, an office in the U.S. General Services Administration that provides in-house digital services consulting for the federal government. I’m commenting on behalf of 18F; we’re an open source team and happy to share our thoughts and experiences. This comment represents only the views of 18F, not necessarily those of the GSA or its Chief Information Officer.)
Following on to our previous comments on “open source by default”, this comment outlines several ways in which the draft policy’s proposed 20 percent target increases the risk that the overall policy won’t have the opportunity to succeed at its stated goals.
“20 percent” could incentivize sharing less-useful software
Because 20 percent is a relatively low threshold, agencies may be tempted to meet this requirement by releasing only software that they use the least often, that’s updated least often, or that’s least important. If they do that, their core software won’t benefit from public inspection and what’s publicly released will be less useful and less likely to be reused.
Further, if agencies are required to release only a minority portion of their procured software, rather than a majority, that may not be enough to cause noticeable change in how they approach software development. Any perceived drag from the differences of working with open source practices would therefore be unnecessarily exacerbated and perpetuated.
“20 percent” limits the value and quality of contributions
Opportunities for meaningful reuse and contribution could be reduced by the fact that these projects are likely related to the other 80 percent of the agency’s projects in important ways. For example, if 18F released our timesheet reminder tool without releasing our corresponding timesheet tool, though improvements to that reminder tool could technically work on their own, they won’t be as useful or reusable as improvements made in the larger context could have been. If you’re only able to work with a component that’s part of a larger collection of components, you won’t have an opportunity to understand, much less improve, the whole system.
Say you give me 20 percent of a car and I propose an improvement to one wheel. It’s possible that had I been able to see the entirety of the car, I’d have been able to propose a higher-level improvement that would have been even more valuable. As it is, I’m still only able to improve one wheel with my proposed change(s), not all four.
Additionally, if I can’t test my improvements with the rest of the car, there’s no way to know whether my proposed change (a wheel of a different size, say, or a different load-bearing capacity) could work or be made to work with the rest of the system.
“20 percent” increases maintenance costs and technical debt
Continuing the car example: the wheel improvement I proposed to the one wheel I could see could have implications for the car’s undercarriage or other parts of the car. If the project’s maintainer merges my improvement but doesn’t have the capacity, time or resources to extend (or think to extend) that improvement to the remaining components, the codebase will become divergent. That divergence could continue and cause workarounds for years to come. This kind of technical debt can be avoided by allowing contributors to see 100 percent of the codebase.
“20 percent” limits the opportunity for contributions
Perhaps it goes without saying, but by definition, code that’s hidden won't have the opportunity to inspire improvements from outsiders.
“20 percent” limits the ROI on necessary investments
Lastly, at any percentage target, the overall policy will require some investment from agencies in internal policymaking, training staff, and related work. Doing this amount of work for 20 percent may be less effective at lowering costs than doing this work for a larger percentage.
In sum, a 20 percent target will:
Increase complexity
Add unnecessary process burden up front (to identify which 20 percent), for contributing developers (to stand up and test the code), and on an ongoing basis for maintenance
Reduce the influx of improvements
The combination of these factors will make it difficult for the pilot to succeed. As written, the policy will increase the investment of time and money required for open source project management and lower the return by limiting the potential scope of contributions.
Moving to an “open source by default” policy would allow the government and taxpayers to reap the full intended effects of the policy.
Originally posted by @fureigh; formatting not preserved
(I’m Fureigh, a developer at 18F, an office in the U.S. General Services Administration that provides in-house digital services consulting for the federal government. I’m commenting on behalf of 18F; we’re an open source team and happy to share our thoughts and experiences. This comment represents only the views of 18F, not necessarily those of the GSA or its Chief Information Officer.)
Following on to our previous comments on “open source by default”, this comment outlines several ways in which the draft policy’s proposed 20 percent target increases the risk that the overall policy won’t have the opportunity to succeed at its stated goals.
“20 percent” could incentivize sharing less-useful software
Because 20 percent is a relatively low threshold, agencies may be tempted to meet this requirement by releasing only software that they use the least often, that’s updated least often, or that’s least important. If they do that, their core software won’t benefit from public inspection and what’s publicly released will be less useful and less likely to be reused.
Further, if agencies are required to release only a minority portion of their procured software, rather than a majority, that may not be enough to cause noticeable change in how they approach software development. Any perceived drag from the differences of working with open source practices would therefore be unnecessarily exacerbated and perpetuated.
“20 percent” limits the value and quality of contributions
Opportunities for meaningful reuse and contribution could be reduced by the fact that these projects are likely related to the other 80 percent of the agency’s projects in important ways. For example, if 18F released our timesheet reminder tool without releasing our corresponding timesheet tool, though improvements to that reminder tool could technically work on their own, they won’t be as useful or reusable as improvements made in the larger context could have been. If you’re only able to work with a component that’s part of a larger collection of components, you won’t have an opportunity to understand, much less improve, the whole system.
Say you give me 20 percent of a car and I propose an improvement to one wheel. It’s possible that had I been able to see the entirety of the car, I’d have been able to propose a higher-level improvement that would have been even more valuable. As it is, I’m still only able to improve one wheel with my proposed change(s), not all four.
Additionally, if I can’t test my improvements with the rest of the car, there’s no way to know whether my proposed change (a wheel of a different size, say, or a different load-bearing capacity) could work or be made to work with the rest of the system.
“20 percent” increases maintenance costs and technical debt
Continuing the car example: the wheel improvement I proposed to the one wheel I could see could have implications for the car’s undercarriage or other parts of the car. If the project’s maintainer merges my improvement but doesn’t have the capacity, time or resources to extend (or think to extend) that improvement to the remaining components, the codebase will become divergent. That divergence could continue and cause workarounds for years to come. This kind of technical debt can be avoided by allowing contributors to see 100 percent of the codebase.
“20 percent” limits the opportunity for contributions
Perhaps it goes without saying, but by definition, code that’s hidden won't have the opportunity to inspire improvements from outsiders.
“20 percent” limits the ROI on necessary investments
Lastly, at any percentage target, the overall policy will require some investment from agencies in internal policymaking, training staff, and related work. Doing this amount of work for 20 percent may be less effective at lowering costs than doing this work for a larger percentage.
In sum, a 20 percent target will:
Increase complexity Add unnecessary process burden up front (to identify which 20 percent), for contributing developers (to stand up and test the code), and on an ongoing basis for maintenance Reduce the influx of improvements The combination of these factors will make it difficult for the pilot to succeed. As written, the policy will increase the investment of time and money required for open source project management and lower the return by limiting the potential scope of contributions.
Moving to an “open source by default” policy would allow the government and taxpayers to reap the full intended effects of the policy.