Open Design chapter
This commit is contained in:
parent
bb24181a8d
commit
bc8cc22e25
|
@ -0,0 +1,72 @@
|
|||
===========
|
||||
Open Design
|
||||
===========
|
||||
|
||||
We are committed to an open design process. Every development cycle the
|
||||
OpenStack community holds face-to-face events to gather requirements and
|
||||
write specifications for the upcoming release. Those events, which are open
|
||||
to anyone, include users, developers, and upstream projects. We gather
|
||||
requirements, define priorities and flesh out technical design to guide
|
||||
development for the next development cycle.
|
||||
|
||||
The community controls the design process. You can help make this software
|
||||
meet your needs.
|
||||
|
||||
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
|
||||
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
|
||||
community.
|
||||
|
||||
This is not easy to do. Design is an opinionated process. Design by committee
|
||||
can be inefficient. It's easier and faster to keep design and feature
|
||||
development in the hands of a happy few, behind closed doors, than to get
|
||||
consensus across a community around desired features and priorities. But that
|
||||
would be choosing to go fast in the short term with a small group rather than
|
||||
going far in the long term with a larger group. Community-agreed design will be
|
||||
slow, but it will lead to a better product that better answers the need of the
|
||||
users.
|
||||
|
||||
In this section we'll cover how to set up your project and your development
|
||||
cycle in a way that enables and encourages Open Design.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
Because of those disadvantages, time-based releases are strongly preferred for
|
||||
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
|
||||
release. A time based release means that everybody who depends on the software
|
||||
has a clear expectation of how to contribute to the software, and what to
|
||||
expect at any given step in the software development process. An additional
|
||||
benefit is the ability to schedule events around aspects of the development
|
||||
cycle.
|
||||
|
||||
A time-based release cycle becomes critical for the success of "Open Design".
|
||||
Once the schedule is set, contributors know exactly when they can add their
|
||||
voice to the design process. Part of the OpenStack design process is to have
|
||||
face-to-face events at the beginning of every release cycle to begin the design
|
||||
process for the next release. This in-person meeting focuses the attention of
|
||||
the community in a neutral environment. These events are open to anyone,
|
||||
including developers, users, and vendors.
|
Loading…
Reference in New Issue