Step 4: Establish Governance
Projects that use OTD need to be governed. The governance process for each project needs to encourage collaborative development, but it must also allow the rejection of contributions where warranted. The OTD governance process must enable multiple organizations to work together to improve each component undergoing shared development (including its software, tests, and documentation), instead of re-developing separate independent components with similar functionality. Before discussing different governance models, it is important to note that forkability is necessary, as described next.
Forkability: A fork is a competing project established using a copy of an existing project’s software.
It is critically necessary that an OTD project be forkable. That is, it must be possible to create a viable competing project using a copy of the existing project’s software source code. Creating a fork is similar to a call for a “vote of no confidence” in a parliament. The fork creator is essentially asking developers and users to stop supporting the original project, and support the new forked project instead (supporting both projects is typically impractical over time).
Forks can also occur because the existing community doesn’t plan to include a feature set part of the community deems important, reasons could include: support for a different operating system or middleware or inclusion of a new programming language. Whatever the reason, every effort should be made to keep forked projects somewhat as coordinated as possible.
Forkability is a necessary part of OTD governance. As long as a project is forkable, project leadership will strive to be responsive to users and developers. This is because if leadership decisions are particularly egregious, a forked project can be started under more responsive stewardship. Easy forkability actually reduces the risk of a fork, because leadership will be forced to listen to users and developers (because if they do not, a viable fork will emerge). In addition, easy forkability increases the likelihood of contributions; easy forkability provides significant protection to would-be contributors, because if they later disagree with project governance, they can create a fork.
Regardless of the governance model, the decision-maker(s) must avoid making a decision between alternatives too soon. If there is a disagreement, there may be a compromise or alternative approach that would be better than the immediately-obvious options. Therefore, decision-makers should try to get parties to find those compromises and alternatives. However, if a reasonable compromise cannot be found and a decision must be made, the decision-maker(s) should make that decision after listening to all sides. That decision should be announced clearly, along with sound rationale. The decision-maker(s) must also be willing to change a decision given important new information, new options, or a change in circumstances.
A key to any governance approach is that the project must be forkable. Any governance model can eventually fail if the decision-makers have no need respond to others. If the project is forkable, then the leadership (regardless of the governance model) must in the end respect the needs of users and developers. More information can be found in [Fogel2009] chapter 4 and [Bacon2010] chapter 8.