Page History

...

• how governance is occurring on public lists;
• progress in participation from additional individuals or organizations;
• how

  How release processes follow ASF infrastructure;

• steps taken to improve transparency or independence;
• any risks or concerns being addressed.

...

• using public mailing lists for governance and decisions;
• maintaining ASF-compliant branding;
• encouraging participation from multiple individuals and organizations;
• declaring affiliations in votes and discussions;
• supporting independent contributors as they take responsibility.

16. Responsibility for Monitoring Neutrality

The PPMC is responsible for monitoring whether project governance remains open, public, and independent. All PPMC members are expected to notice and draw attention to anything that may limit participation or suggest that decisions are occurring outside ASF channels. Mentors also help identify neutrality risks, especially early in incubation when an external perspective can highlight issues that may not be visible to project participants.

Other parts of the ASF may surface relevant signals, including:

• trademarks@apache.org during branding reviews
• infra@apache.org when reviewing websites or build processes
• IPMC reviewers when assessing podling reports

Anyone may raise a neutrality concern, but the PPMC is accountable for evaluating it and taking any necessary steps to ensure that the project continues to operate through public, documented governance.

17. Raising, Escalating, and Resolving Neutrality Concerns

Neutrality concerns should be raised on the public lists with enough detail for the PPMC and mentors to understand the issue. The purpose is to clarify the situation, review the relevant processes, and ensure that governance remains public and accessible.

When a concern is raised, the PPMC should:

• provide context if available
• review whether project processes, tooling, or communication patterns require adjustment
• agree on necessary changes and document the outcome on the list

If further assistance is needed, escalation paths include:

• mentors, if they are not already involved
• the IPMC, for broader guidance on incubation expectations
• trademarks@apache.org for branding issues
• infra@apache.org for infrastructure or release-process issues

Escalation is intended to support the podling and clarify expectations.

18. Cultural Considerations

Organizational or regional norms may influence contributor behaviour. Podlings should reinforce that ASF projects value individual participation, open discussion, and public collaboration.

...

19. Branding Requirements

Podlings must comply with ASF trademark and branding policies. Project names, documentation, and communication must not imply ownership by any individual or organization. See the ASF Trademark Policy.

...

20. Graduation Requirements

To graduate, a podling must demonstrate:

• community-led, publicly documented governance
• participation from more than one individual or organization, or a clear progress toward this
• ASF-controlled, repeatable release processes
• branding aligned with ASF policy

...

21. Graduation Concerns

Graduation may be delayed if:

• governance is dominated by a single individual or organization without evidence of change
• independent contributors do not participate meaningfully
• project direction follows external priorities rather than community discussion
• branding conflicts with ASF policy

...

22. Consequences of Stagnation

Lack of progress toward neutrality may lead to extended incubation, additional Board scrutiny, declining participation, or, in rare cases, retirement from the Incubator.

...

23. Summary

Vendor neutrality is a core ASF governance principle. Podlings do not need equal representation among all contributors or organizations. They must, however, demonstrate public decision-making, independence from any single individual or organization, and consistent progress toward a sustainable community-led model.

...

24. Related Resources

• Vendor Neutrality - Ensures Apache projects are community-controlled, not dominated by a single company or contributor, supporting sustainability and trust.
• Incubator Case Studies - Compiles case studies of podlings that illustrate patterns of success, retirement, and challenges such as vendor dominance in the Apache Incubator.
• Expanded Incubator Case Studies - Provides more detailed and in-depth examples of the successes, challenges, and outcomes of various Apache Incubator podlings.  
• Practicing The Apache Way - Explains the fundamental principles, values, and practices (like meritocracy and open communication) that govern how all Apache projects operate.
• ASF Release Policy - Documents the required process, approval, artifacts (source packages, signatures), and licensing compliance for making an official Apache Software Foundation release.
• ASF Trademark Guidelines -  Outlines the rules for the allowable use of ASF-owned trademarks, service marks, and logos by other parties to protect project brands and ensure vendor neutrality
• Training Scenarios. - Offers fictional but realistic situations and discussions to train mentors and PPMC members on applying ASF policies in practice.
• PPMC Onboarding Guide -  A guide to help new Project Management Committee (PPMC) members understand their responsibilities, ASF culture, and governance duties within an Incubator podling
• Mentor Quick Reference - Common Red Flags. - A checklist for mentors to quickly identify potential problems, such as governance issues or lack of community diversity, that could prevent a podling's graduation.
• The Employer Dominated Podling  - A scenario describing the challenges and steps required to diversify a podling whose contributions and governance are overwhelmingly controlled by a single company.