The Apache Petri (as in “petri dish” –where cultures are grown and bloom) committee assists external project communities interested in becoming an Apache project to learn how The Apache Software Foundation (ASF) works, its views on community, and how to build a healthy community for the long -term.
Petri’s mission is to mentor existing external communities (“cultures”) about “The Apache Way” by focusing on community governance that includes discussions about ASF policies. The mentoring and education is conducted on a mailing list.
The primary goal is to reach a point where a recommendation to the ASF Board can be made to construct a new Apache Project Management Committee (PMC) for the external community.
In the Incubator model, projects graduate to become Apache Top-Level Projects (TLPs). Under Petri, projects can become TLPs under a process described as “direct to TLP”, which is an alternative path to that used by the Apache Incubator. Apache Petri aims to shepherd projects and their communities to a point of confidence that the ASF Board will welcome the community to the Apache family of projects as a Top-Level Project.
Apache Petri provides an alternative process to Incubation that would be suitable for some projects and their communities. Petri provides educational resources, and mentors external groups on their path to becoming an official project of the ASF. The primary goal is to reach a point where a recommendation to the ASF Board can be made to construct a PMC for the community.
“Podlings” in the Apache Incubator are provided a complete set of Foundation-based resources upon their acceptance into the Incubator. Since Petri will begin mentoring the community “where they live”, it will not provide an initial set of resources. Over time, as part of the education process and shift of the community towards the Foundation, resources will be provided as appropriate. It is expected that once a PMC is constructed, any resources not hosted at the Foundation will be the new PMC’s first order of business (i.e. a transition plan would be part of the presentation to the Board).
The Apache Way is the ASF’s process of community-led development is the backbone of all Apache projects, and emulated by many Open Source foundations. The Apache Way comprises:
For more information, see The Apache Way.
The Apache Software Foundation's mission is to provide software for the public good.
Quoting from The Apache Way to Sustainable Open Source Success:
To allow us to deliver on this part of the mission, it is critical that we adopt a license that uses the law to protect the software curated here at the Foundation. For us that license is the Apache License, Version 2. In addition, we adopt an inbound licensing policy that defines which licenses are allowable on software reused within Apache projects. This policy can be summarized as:
- The license must meet the Open Source Definition (OSD).
- The license, as applied in practice, must not impose significant restrictions beyond those imposed by the Apache License 2.0.
The Board makes the ultimate decision, and generally ensures that the project has:
If you are:
And you are:
Petri would help the community learn how to integrate governance and development “The Apache Way” without interrupting the project’s velocity.
In keeping with the ASF’s slogan of “Community Over Code”, we are unable to accept projects that are not supported by some form of community.
In March 2015 Apache Zest (now Polygene) became the first project to enter the ASF as a Top-Level Project — without entering the Apache Incubator. As part of the discussion, the project chose to review itself (private link) against the Apache Maturity Model, that addresses the integrity of a project's code, copyright, licenses, releases, community, consensus building, and independence, among other qualities.
The Apache Maturity Model will not be a requirement for communities (as the Model does not have broad consensus as a true and thorough viewpoint), but the Model may provide a helpful guide for some.
There’s no “one size fits all” answer here. Some external projects have applied to the Apache Board to become TLPs, and have become TLPs without going through either Petri or the Incubator. Historically, every project’s experience and time spent in the Apache Incubator varies, depending on its specific needs and circumstances; this has ranged from less than one year to more than three years.
Similarly, some projects undergoing Petri mentorship will take longer than others. Petri is more about education about The Apache Way of project governance and Apache Policy, and less about process.
No, unless the projects intend to apply for TLP status and migrate their source control to ASF hardware. This applies both to Incubator podlings and direct-to-TLP applicants.
There is more than one way to do so: not all incoming projects will be mentored by Petri. Traditionally, the Apache Incubator has been the entry path for external projects, codebases, and communities wishing to become a part of the ASF.
Petri's primary goal is preparing a community for Direct-to-TLP; moving from Petri to become a podling undergoing development in the Apache Incubator is a possibility, but not mandated.
That depends. First, there have to be available mentors. Second, the Petri PMC may have to rate-limit intake, especially at first, in order not to stretch itself too thin with its oversight duties. This is true of the entire ASF: the Board may put intake of new TLPs on hold from time to time, though it has never yet done that to date.
We anticipate 2-3 communities in the first year, with one per year likely following that.
This list is only complete in that we are considering what the Board currently seems to require and it is as always up to the Board the requirements for any particular TLP. In addition to the list of items shared above, in the What does “Direct to TLP” entail section:
This assumes that the Mentor is no longer interested in the community once it is assessed. Even if this were true TLPs have a range of Apache committees and resources available. If necessary the Board can provide additional guidance through the normal reporting process as the Board does for every PMC.
Email discuss@petri.apache.org (public list; if you're not subscribe, ask explicitly to be Cc'd on replies) or private@petri.apache.org (private list, only Apache Petri PMC members and Apache Members can subscribe) and introduce yourself! We don’t have any forms or questionnaires, but may introduce these should the need arise.
We don’t recommend leaving the Incubator, if the podling is already established there; podlings should strive to graduate. In the event a community is unwilling to wait for graduation, and Petri has accepted them, then the Incubator will need to retire the podling. Petri will then take responsibility for the podling’s resources, and perform any needed changes to make that happen.