Merge pull request #1 from ttx/master

Changes from my draft review

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

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

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