4.3 KiB
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.