Browse Source

Merge pull request #1 from ttx/master

Changes from my draft review
changes/58/617958/1
Chris Hoge 3 years ago
committed by GitHub
parent
commit
b9c3be47f9
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
  1. 23
      docs/opendesign.rst
  2. 4
      docs/opendevelopment.rst
  3. 13
      docs/opensource.rst

23
docs/opendesign.rst

@ -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
organization to release it has developed under an open source license. While
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
design decisions being made by organization leaders and implemented by their
employees. The principle of "Open design" takes this one step beyond and
process, they still frequently maintain control of the software with most of
the design decisions being made by organization leaders and implemented by
their employees. The principle of "Open design" takes this one step beyond and
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
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",
"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
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
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
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
delays can have differing and significant impacts, particularly on vendors who
rely on release schedules for delivering software. Release delays can create
tension in the community, and raise the barrier of entry for contributors by
creating an unknown cost.
delivery. If you're encouraging a large community of diverse developers, it
gets pretty difficult to get commitments and coordinate activities, leading to
significant delays. Those delays can have differing and significant impacts,
particularly on vendors who rely on release schedules for delivering software.
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
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

4
docs/opendevelopment.rst

@ -9,7 +9,9 @@ Open Development
"Open development" refers to the adoption of transparent and inclusive
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
contributor. A successful open source project will adopt a set of standards
that clearly states the metrics and standards that a contribution will be

13
docs/opensource.rst

@ -51,7 +51,7 @@ The "Open Source" Principle in Practice
---------------------------------------
"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
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
@ -63,7 +63,7 @@ In practice, individual and corporate contributors need to understand the
consequences of contributing code to an Apache Licensed project, particularly
the granting of copyright and patent licenses to all users of the software. To
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
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
@ -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
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
----------
.. [#OSI] https://opensource.org/licenses/alphabetical

Loading…
Cancel
Save