openinfra/four-opens
Code Issues Proposed changes

Merge pull request #1 from ttx/master

Browse Source 
Changes from my draft review
This commit is contained in:
Chris Hoge 2018-11-10 07:12:57 -08:00 committed by GitHub
commit b9c3be47f9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 27 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
docs/opendesign.rst
View File

@ -16,9 +16,9 @@ The Four Opens are all about the acceptance of letting go of control over an
open source project. One popular open source development model for an open source project. One popular open source development model for an
organization to release it has developed under an open source license. While organization to release it has developed under an open source license. While
most of them will also commit to a transparent and inclusive development most of them will also commit to a transparent and inclusive development
process, the still frequently maintain control of the software with most of the process, they still frequently maintain control of the software with most of
design decisions being made by organization leaders and implemented by their the design decisions being made by organization leaders and implemented by
employees. The principle of "Open design" takes this one step beyond and their employees. The principle of "Open design" takes this one step beyond and
guarantees a transparent and open process for planning and designing the guarantees a transparent and open process for planning and designing the
software. It's about letting go of the control of the design of the software software. It's about letting go of the control of the design of the software
and its feature road-map, and accepting that it should be driven by the and its feature road-map, and accepting that it should be driven by the
@ -40,20 +40,23 @@ The "Open Design" Principle in Practice
--------------------------------------- ---------------------------------------
Open Design begins with the establishment of a structure to guide the "when", Open Design begins with the establishment of a structure to guide the "when",
"how", and "where" of the design process. Then "when" refers to the "how", and "where" of the design process. The "when" refers to the
release-cadence of the software, particularly if it is a feature-based or release-cadence of the software, particularly if it is a feature-based or
time-based release. A feature-based release allows the community to reach a time-based release. A feature-based release allows the community to reach a
consensus on required capabilities a release should have, then only deliver the consensus on required capabilities a release should have, then only deliver the
next version of the software when those features are complete. While there are next version of the software when those features are complete. While there are
many processes that can help estimate the time and effort it will take to many processes that can help estimate the time and effort it will take to
deliver a set of requirements, feature-based releases often result in delays in deliver a set of requirements, feature-based releases often result in delays in
delivery. If you're encouraging a large community of diverse developers, these delivery. If you're encouraging a large community of diverse developers, it
delays can have differing and significant impacts, particularly on vendors who gets pretty difficult to get commitments and coordinate activities, leading to
rely on release schedules for delivering software. Release delays can create significant delays. Those delays can have differing and significant impacts,
tension in the community, and raise the barrier of entry for contributors by particularly on vendors who rely on release schedules for delivering software.
creating an unknown cost. Release delays can create tension in the community, and raise the barrier of
entry for contributors by creating an unknown cost.
Because of those disadvantages, time-based releases are strongly preferred for Rather than adopting feature-based releases and doing a bad job at them, it
is healthier to adopt time-based releases and embrace their benefits. Knowing
when a release will be cut gives you predictability that is key to a
healthy collaboration. With a time-based release, there's no single group that healthy collaboration. With a time-based release, there's no single group that
decides what feature can or can't be included in a release. The features that decides what feature can or can't be included in a release. The features that
are complete at the release deadline are the features available in that are complete at the release deadline are the features available in that

4
docs/opendevelopment.rst
View File

@ -9,7 +9,9 @@ Open Development
"Open development" refers to the adoption of transparent and inclusive "Open development" refers to the adoption of transparent and inclusive
development processes that enable everyone to participate as an equal on a development processes that enable everyone to participate as an equal on a
level playing field. Open development means that all patches are welcome for level playing field. Publicly-accessible services means that everyone can see
everything about development activities, without even needing to sign up to a
service. Open development also means that all patches are welcome for
consideration, whether that patch is from a project founder or a first time consideration, whether that patch is from a project founder or a first time
contributor. A successful open source project will adopt a set of standards contributor. A successful open source project will adopt a set of standards
that clearly states the metrics and standards that a contribution will be that clearly states the metrics and standards that a contribution will be

13
docs/opensource.rst
View File

@ -51,7 +51,7 @@ The "Open Source" Principle in Practice
--------------------------------------- ---------------------------------------
"Open Source" begins with the choice of license a community applies to its "Open Source" begins with the choice of license a community applies to its
project. In the case of the OpenStack Foundation, we use v2.0 of the Apache project. In most cases at the OpenStack Foundation, we use v2.0 of the Apache
License [#apachev2]_. The license meets the requirements of being able to modify and License [#apachev2]_. The license meets the requirements of being able to modify and
redistribute a work. It includes a number of provisions that also protect redistribute a work. It includes a number of provisions that also protect
end-users by granting copyright and patent licenses to all end users, while end-users by granting copyright and patent licenses to all end users, while
@ -63,7 +63,7 @@ In practice, individual and corporate contributors need to understand the
consequences of contributing code to an Apache Licensed project, particularly consequences of contributing code to an Apache Licensed project, particularly
the granting of copyright and patent licenses to all users of the software. To the granting of copyright and patent licenses to all users of the software. To
acknowledge this, many projects require that all contributors sign a acknowledge this, many projects require that all contributors sign a
"Contributor License Agreements" (CLA) [#OSCLA]_ or "Developer Certification of "Contributor License Agreement" (CLA) [#OSCLA]_ or "Developer Certificate of
Origin" (DCO). Typically, a CLA is a stronger statement, attesting that a Origin" (DCO). Typically, a CLA is a stronger statement, attesting that a
contributor has a right to submit work to the project and that they are contributor has a right to submit work to the project and that they are
granting copyright and patent licenses in accordance with the Apache License granting copyright and patent licenses in accordance with the Apache License
@ -95,6 +95,15 @@ successfully demonstrate compatibility by passing a suite of interoperability
tests, run against the public API of the product. In this way, the scope of tests, run against the public API of the product. In this way, the scope of
modifications is limited. modifications is limited.
Furthermore, in the case of fast-evolving infrastructure software, it's worth
noting that keeping local changes private is not a great long-term strategy.
Maintaining a delta between code running in production and fast-evolving
upstream open source code is very costly, and gets more difficult as time
passes. Technical debt adds up quickly to a point where paying it back is
impossible. Engaging upstream to propose your local improvements and finally
getting most of them in the open source project itself is the only sane
way forward over the long run.
References References
---------- ----------
.. [#OSI] https://opensource.org/licenses/alphabetical .. [#OSI] https://opensource.org/licenses/alphabetical