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