119 lines
6.7 KiB
ReStructuredText
119 lines
6.7 KiB
ReStructuredText
===========
|
|
Open Design
|
|
===========
|
|
|
|
In the previous section we established the concept of Open Community, which
|
|
requires transparency in every step of creating and maintaining artifacts;
|
|
Open Design is an essential part of this.
|
|
|
|
In order to provide access to everyone to all steps and decision points of the
|
|
design process, no one person, group of people or organization can maintain
|
|
control over the project.
|
|
|
|
It is a common practice for companies to develop software in-house and then
|
|
release the code as open source and start to form a community around it. As
|
|
part of their actions on the way they often fail with letting go of the control
|
|
over the software and processes within the community. This can easily result in
|
|
a single-vendor community as the leadership positions and decisions are mainly
|
|
controlled by this organization and therefore other contributors cannot take
|
|
ownership and feel as being equally involved in the community.
|
|
|
|
Single-vendor projects don't have a good reputation as both the design
|
|
directions and maintenance are highly dependent on the controlling organization
|
|
which puts high risk on the project for users and other companies to depend on
|
|
it. At the same time contributors, who are not part of that one company, can't
|
|
feel to be equal members if they don't have the option to be involved in all
|
|
steps and decisions, which will discourage them from participating.
|
|
|
|
By opening up the design process for everyone to participate in and have their
|
|
voices heard, you will get more innovative ideas and more robust solutions.
|
|
|
|
On the other hand, you need to be aware that opening up the design and decision
|
|
making process to a larger group can slow down to come to consensus in some
|
|
cases. However, by electing leaders from the community and by the community
|
|
based on merit, you can ensure that the decisions will always reflect and
|
|
represent the community, whether the contributors made them or their elected
|
|
leaders. While the decision making process might still be longer than in case
|
|
of a smaller group, it is a tradeoff that will benefit the whole community on
|
|
the long run.
|
|
|
|
The community also needs to ensure that the processes and timelines they use
|
|
are clearly defined and made available for anyone to access publicly without
|
|
any restrictions. This will ensure that both newcomers and established
|
|
contributors know how they can participate, when and where decisions are made
|
|
and will make it easier for them to participate and help improving and
|
|
maintaining the project.
|
|
|
|
To provide you an example, we will discuss the approach the OpenStack community
|
|
took with their release process.
|
|
|
|
The Open Design Principle in Practice
|
|
-------------------------------------
|
|
|
|
Open Design involves to define the lifecycle of the software development
|
|
process, which boils down to define a release process to be able to evolve and
|
|
maintain the project artifacts. A release process defines the "when", "where"
|
|
and "how" the design process happens.
|
|
|
|
To define the "when", you need to define a release cadence to put out new
|
|
versions of the software and related items, such as documentation. To make this
|
|
step more complicated, you need to decide between a feature-based or a
|
|
time-based release model.
|
|
|
|
With the former approach, the community needs to identify a set of features
|
|
that needs to be complete in order to be able to cut a release. In most cases
|
|
this results in the inability to provide a good estimate on when the new
|
|
version of the artifacts will be available. With delays in the estimated
|
|
delivery time, users will likely look for alternatives after some time as it
|
|
is harder to plan downstream with this model. A larger community with a more
|
|
complex structure will likely have a hard time to commit to a set of
|
|
functionality and coordinate the steps needed to deliver them as estimated.
|
|
However, projects with a higher number of external dependencies or with a
|
|
larger refactoring activity this option can still be something to consider even
|
|
if only on a temporary basis.
|
|
|
|
A time-based release model commits to a release cycle and adapts the
|
|
development process to ensure to produce stable and reliable software and
|
|
artifacts on time. This model has a lot of advantages compared to the previous
|
|
one in case of open source communities of any size. Most importantly, it gives
|
|
predictability which is important for those who depend on the release
|
|
downstream as well as to those who are participating in the community. In
|
|
addition, it also makes it easier for newcomers to start participating in your
|
|
community, as they can identify which phase of the release cycle the community
|
|
is going through and that makes it easier for them to find a task or activity
|
|
to start to contribute. This model provides a higher level of transparency with
|
|
being able to define deadlines for processes throughout the cycle.
|
|
|
|
This approach makes it a little harder to commit, when it comes to features and
|
|
functionality. The community will prioritize work items and will include the
|
|
items that are ready by the time of the release. In some cases a feature might
|
|
only get partially complete and users need to wait until the next release to be
|
|
able to use it. While this can be inconvenient, by looking at the roadmap for
|
|
the project you can still get a good picture about when you get new
|
|
functionality that you need. If a feature is important to you, you can also
|
|
always decide to participate in the making, if you are not doing so yet.
|
|
|
|
In addition, time-based release cycles provide you and the community the
|
|
ability to plan events and activities, like hackathons around the cadence to
|
|
boost the planning phase, bug fixing or share news and updates with those
|
|
who are interested or new to the project.
|
|
|
|
While choosing time-based release process is not a criteria of the Open Design
|
|
principle, it is a more natural choice to create good dynamics for a community
|
|
with processes that are easy to discover and follow.
|
|
|
|
The OpenStack community chose this model and has been practicing it
|
|
successfully since the launch of the project. The community picked a 6-month
|
|
release cadence as that fits best to the size and complexity of the project.
|
|
The community gathers at the beginning of every release cycle, either in person
|
|
or virtually, to provide an environment for more efficient discussions that can
|
|
help with faster planning and better maintenance. The events are open to
|
|
everyone to participate, let them be contributors, users, new comers, and so
|
|
forth.
|
|
|
|
In order to remain inclusive to those who cannot participate in an event the
|
|
community avoids making decisions at these events. Contributors rather making
|
|
meeting notes available and share thoughts and proposals on the mailing list
|
|
and other channels to provide an opportunity to engage in the discussion to
|
|
those who didn't have access to the event.
|