| Title: Apache Petri - FAQ |
| source_button: yes |
| <!-- Licensed under ALv2 --> |
| |
| [TOC] |
| |
| # General |
| |
| ## What is Apache Petri? |
| |
| 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. |
| |
| ## How is Petri different from the Apache Incubator? |
| |
| 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). |
| |
| <h2 id="whats-special">Why does this matter? What is special about The Apache Way? |
| <a class="headerlink" href="#whats-special" title="Permanent link">¶</a></h2> |
| |
| 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: |
| |
| * Earned Authority (merit); |
| * Community of Peers; |
| * Open Communications; |
| * Consensus Decision Making; and |
| * Responsible Oversight. |
| |
| For more information, see [The Apache Way](https://www.apache.org/theapacheway/). |
| |
| The Apache Software Foundation's mission is to provide software for the public good. |
| |
| Quoting from [The Apache Way to Sustainable Open Source Success](https://s.apache.org/GhnI): |
| |
| > 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](https://www.apache.org/licenses/LICENSE-2.0.html). |
| > In addition, we adopt an [inbound licensing policy](https://apache.org/legal/resolved.html) |
| > 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)](https://opensource.org/osd). |
| > * The license, as applied in practice, must not impose significant restrictions beyond those imposed by the Apache License 2.0. |
| |
| ## What does “Direct to TLP” entail? |
| |
| The Board makes the ultimate decision, and generally ensures that the project has: |
| |
| * Demonstrated |
| [vendor neutrality](https://community.apache.org/projectIndependence.html) |
| in the |
| [community](https://incubator.apache.org/guides/community.html); |
| * Demonstrated understanding of the |
| [Apache Release Policy](https://www.apache.org/legal/release-policy.html) |
| including [Applying the Apache License](https://infra.apache.org/apply-license.html); |
| * Completed |
| [Contributor Licence Agreements and Software Grant Agreements](https://www.apache.org/licenses/contributor-agreements.html); |
| * Performed a |
| [Suitable Name Search](https://incubator.apache.org/guides/names.html); |
| * Developed a |
| [Transition Plan](https://incubator.apache.org/guides/transitioning_asf.html) |
| to move the project's resources to the ASF; |
| * Shown how the community will |
| [recognize merit](https://incubator.apache.org/guides/community.html); and |
| * Shown auditable decision making on the provided mailing list. |
| |
| ## Is Apache Petri right for you? |
| |
| If you are: |
| |
| * An established, diverse community that already releases quickly; or |
| * A project with a single “leader” that seeks to grow to a community-driven |
| development model; or |
| * A company that has an Open Source project with other vendors and wants to |
| expand and diversify its community... |
| |
| And you are: |
| |
| * Willing to license your project's works under the [Apache License, Version 2](https://www.apache.org/licenses/LICENSE-2.0.html). |
| |
| 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. |
| |
| # Process |
| |
| ## What about the Maturity Model? Have other projects bypassed incubation by meeting these requirements? |
| |
| 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](https://mail-private.apache.org/members/private-arch/board/201502.mbox/%3CCADmm%2BKf9A1O%2B%3DKOd9__sDF2-kMh9b3iy3cf4NCRUnSDOPDq92w%40mail.gmail.com%3E) |
| (private link) against the |
| [Apache Maturity Model](http://s.apache.org/O4p), 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. |
| |
| ## How long does the Petri process take? |
| |
| 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. |
| |
| ## Do people involved in Petri-mentored projects need to sign ICLAs? |
| |
| 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. |
| |
| ## If our project wants to become an official Apache project, what is the best way to do so? |
| |
| 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. |
| |
| ## If I propose my project to be mentored by Petri, will it be accepted? |
| |
| 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. |
| |
| ## What is the expected intake rate for Petri? |
| |
| We anticipate 2-3 communities in the first year, with one per year likely following that. |
| |
| ## What should the Board expect from a Project that Petri Recommends to become a TLP? |
| |
| 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: |
| |
| * **Graduation Resolution**. If there are Apache Members involved or |
| recruited then they will be included in the resolution. Apache |
| Members like anyone else are certainly invited to contribute |
| to the project. |
| * **Transfer of Registered Trademarks**. If there are any registered |
| trademarks then the transfer agreement will be discussed with |
| the VP, Brand in advance. |
| * **Software Grant**. Petri should collect [software grants](https://www.apache.org/licenses/contributor-agreements.html#grants). |
| * **Committers**. Petri can collect ICLAs in advance of going to TLP. |
| Petri can make the committers from a prospective community |
| Petri committers in order to create accounts. |
| * **Resources**. Graduation proposals will include a **Transition Plan** |
| explaining the actions that the project has already taken or intends to take once |
| the PMC is established. This may include: |
| * Creating Apache project mailing lists |
| * Creating Apache issue trackers |
| * Creating Apache wikis |
| * Creating Apache code repositories |
| * Migrating code repositories to Apache |
| * Applying the Apache License |
| * Creating Apache web presence |
| * Migrating web presence from Project to Apache |
| * Rebranding web, code, documentation from Project to Apache Project |
| * Retiring external Project and redirecting to Apache |
| * Creating and migrating CI, build, release processes to Apache Project |
| * Establish processes for release distribution at Apache |
| * New TLPs should report on their progress towards completing |
| their Transition Plan in their Board Reports. |
| |
| ## Who will provide guidance once the Petri mentor is gone after the assessment? |
| |
| 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. |
| |
| ## How can our project/community apply for Apache Petri mentorship? |
| |
| 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. |
| |
| ## If a project wants to move out of the Apache Incubator and into Petri, what happens? |
| |
| 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. |