Jump to: navigation, search


OIF Project Confirmation Guidelines

NOTE: This content has been migrated to the new OIF Board Wiki.

A pilot project wishing to be confirmed as an Open Infrastructure Project at the Open Infrastructure Foundation shall be reviewed by the Open Infrastructure Foundation Board of Directors in accordance with the bylaws of the Foundation.

In order to provide guidelines for potential Open Infrastructure Projects, the Board has developed a process and series of discussion points that have been defined to represent the overall interests of the Foundation projects and communities. These guidelines were developed as a reflection of the charter and mission statement of the Foundation, are aligned to what it means to be a Foundation project, and represent what we believe contributes to long term sustainability.

Many factors go into the decisions of the Board and it should not be construed that if an applicant documents competency and demonstrated historical performance in each of the areas in the guidelines that they will be automatically confirmed as an Open Infrastructure Project. The Board provides these guidelines in an effort to help pilot projects seeking confirmation gather relevant information in their application, to support the decision making process. The Board and other confirmed projects are available to give feedback on governance and technical best practices for pilot projects as they are being drafted, so the projects don't have to wait until they apply for confirmation.

During the course of considering pilot projects, the Board has broad discretion to consider any and all factors in its decision, however the following factors have been identified as being important considerations that the Board will take into account:

1. Strategic focus

  • Project continues to be aligned with the Foundation’s mission and brings value within the scope of one or more of the Foundation's approved strategic focus areas for open infrastructure.
  • Where it is mutually beneficial to the pilot project and other projects involved, the project has taken advantage of opportunities for integration and complementarity with other open source projects both inside and outside the Foundation.

2. Governance

  • Project has defined and documented governance procedures, and has been operating under those procedures for a period of time and with a level of activity sufficient to demonstrate the effectiveness of the model.
  • The Foundation does not prescribe a specific governance model for projects. The Board will be looking for evidence that the governance model the project has chosen meets the project's organizational needs and grants developers and users a voice in project governance.
  • Projects may find existing documents on project governance models helpful when deciding what practices to adopt, such as Mozilla's Open Source Archetypes.

3. Technical best practices

  • Project has established technical best practices, such as documentation, code review, testing, CI/CD, bug handling, security considerations and vulnerability management.
  • Projects may find existing documented standards to be helpful when deciding what practices to adopt, such as the Core Infrastructure Initiative's best practices.

4. Open collaboration

  • Project policies and practices provide a level playing-field where open collaboration can happen.
  • Project has adopted the philosophy of The Four Opens: open source, open development, open design, open community.
  • Project and its community adhere to the Open Infrastructure Foundation Community Code of Conduct.
  • Project behaves as a good neighbor to other confirmed and pilot projects.
  • Project distributes software under an open source license that the Board has approved for use, and that has been approved as an open source software license by the Open Source Initiative.
  • Project distributes documentation under a license that the Board has approved for use. This includes open source software licenses, as above, and also non-software licenses for open content, like Creative Commons.

5. Active engagement

  • Project has a diversified developer base. A project that is built with a broad developer base both in number and stakeholders is more likely to be sustained over the long term.
  • Project has demonstrated momentum in adoption by users and a path for continued growth. We view this as validation that the technology solves real problems for real users.
  • Project is part of an evolving and healthy ecosystem. We view this as confirmation that the technology is broadly applicable to different use cases. The Board will consider activities such as available training and user support, hiring by vendors or users, and commercial products and services.

These factors will be evaluated in a project confirmation process that has the following steps:

  • The Foundation staff will work with projects through their pilot phase to meet the expectations and guidelines above.
  • Pilot projects will submit an application to the Foundation.
  • Representatives of the pilot project will attend a discussion meeting with the Board that may include an informal or formal presentation to the Board.
  • Representatives of the Foundation staff will attend the discussion meeting, which may include discussion of funding and staff allocated to the pilot project on confirmation. The Board will seek an evaluation and recommendation from the Foundation staff who supported the pilot project to this point.
  • The Board will review the project's application, and vote whether to confirm it.