Requirements for Healthy Subprojects

oVirt’s goal is to have strong, diverse well functioning projects. It is also believed that those closest to the details and code make the best decisions in how to move things forward, however in delivering a complete management stack integration and coordination is required which can provide context. The Eclipse community is a good example of where they have many projects and coordinate around named frameworks and APIs. For anyone familiar with Eclipse, the two rules for projects have been modeled from that community. When projects are new and developing, the boards role is to encourage and help in every way possible to grow the project. The oVirt board uses the following basic life phases of projects to move from more involvement through to an autonomous project.

• Developing; x < 3 maintainers, y < 3 releases; oVirt board has ability to make decisions on behalf of the project.
• Maturing; 3 <= x < 10 maintainers, y > 3 releases; project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
• Mature; x >= 10 maintainers, project is autonomous and can write its own governance documents. These documents need to be public and voted on by the oVirt board.

This provides a lightweight incubator model where oVirt helps a projects grow and gets out of the way once it reaches critical mass while still providing the coordination for oVirt CS releases and architecture discussions.

If an existing project wants to join oVirt, the board is free determine where they are on the maturity scale and join that project at the appropriate tier.

Indications of a Healthy Project

One main factor that indicates graduation is clear indication of a “healthy” project. There are many ways to measure this, but oVirt takes its lead from the ASF. The below list some factors that represent a high measure of health:

• At least three active contributors, since code commits and releases require at least 3 +1 votes.
• A high level of diversity within the developer community. This ensures that not a single vendor or company has undue influence over the project.
• A high level of self-reliance and self-direction. The project is able to handle conflicts on its own without intervention by the oVirt board or other external entities.
• A high level of shown consensus building. The project must show that it is able to work within itself and build consensus on not only code (e.g., which patch to apply), but also regarding future direction, etc…
• Growth of the developer community. This indicates the ability of the project to attract new developers.
• Growth of the project itself. This indicates that the project is able to recognize the efforts of new developers and add them to the roster of those with both commit privileges as well as voting rights within the project.