76 lines
4.3 KiB
ReStructuredText
76 lines
4.3 KiB
ReStructuredText
===========
|
|
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, 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
|
|
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. 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, 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.
|
|
|
|
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
|
|
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.
|