ba8cfec5a5
I found some of the phrasing a little awkward in the open design doc. This is an attempt to clarify some of it and hopefully make it flow a little better. Change-Id: Iafb023b0f0a955abb2533cff16803461b99e30d4 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
82 lines
4.7 KiB
ReStructuredText
82 lines
4.7 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. A common open source development model for traditional
|
|
software development organizations is to develop internally, then release
|
|
their project under an open source license once it is mostly complete.
|
|
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. This keeps control of the direction of the
|
|
project with the organization, but can result in missing out on unexpected
|
|
ideas from community members and may actually discourage others from getting
|
|
involved in what they may perceive as a company product rather than an open and
|
|
inclusive community project.
|
|
|
|
Using 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
|
|
roadmap, 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.
|