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