1. Purpose

This guide explains vendor and other neutrality requirements for Apache Incubator podlings. It describes why neutrality matters, what the Incubator looks for during incubation, and how podlings and participating individuals or organizations can support community-led governance. The goal is to provide clear and practical guidance consistent with ASF principles and Incubator expectations. Additional background is available in the Incubation Policy, and a general overview of The Apache Way is also helpful.

2. What Neutrality Means

Neutrality means that no single individual, company, or other organization controls or directs an Apache project. Individuals contribute in their own capacity, decisions are made publicly, and the project’s identity, processes, and governance belong to the community. Participation from organizations or vendors is welcome, provided governance and releases remain community-based and independent.

3. Why It Matters

Neutrality ensures:

  • long-term sustainability even if a vendor or organization changes priorities;
  • trust from users and contributors;
  • broader participation and viewpoints;
  • a clear Apache identity separate from external products or initiatives;
  • readiness for graduation as a community-led project.

These expectations reflect ASF governance norms and IPMC evaluation criteria.

4. Neutrality as a Process

Many podlings begin with most contributors associated with a single entity. This may be a company or a group around an individual founder. This is normal in early incubation. Over time, podlings are expected to broaden participation, move governance to the public lists, and build processes that are not tied to any one person or organization. The focus is on visible progress toward independence.

5. Participation from Individuals and Organizations

Strong involvement from one entity, whether a company, individual maintainer, or other group, is not inherently a neutrality problem. Common early-stage patterns include:

  • most contributions coming from one source;
  • internal or private coordination for routine engineering work;
  • organization- or individual-funded development effort;
  • use of private tooling for day-to-day work (not governance).

Neutrality issues arise only when these patterns constrain participation or obscure community governance.

6. Common Misunderstandings

Neutrality does not require:

  • equal contributions by all organizations or individuals;
  • rotating roles by affiliation or employer;
  • removal of internal chat systems;
  • reduced participation from a strong contributor or organization;
  • slowing development to enforce “balance”.

Neutrality is based on transparency, governance structure, and independence, not numerical representation.

7. How Neutrality Issues Arise

Neutrality concerns often come from inherited habits rather than deliberate behaviour. These include:

  • decision-making in private tools or meetings;
  • roadmaps set by an individual or organization before public discussion;
  • release artifacts created with internal or inaccessible infrastructure;
  • branding influenced by a product, research project, or employer identity;
  • contributors aligning with internal or organizational direction rather than public consensus.

8. Early Signs to Watch

Indicators that neutrality may require attention include:

  • governance dominated by a single individual or organization;
  • low mailing list activity despite active private communication;
  • release steps dependent on tools or systems inaccessible to others;
  • priorities or schedules tied to an external organization’s goals;
  • independent or unaffiliated contributors who do not engage or stay.

These indicators warrant review, but they are not problems in themselves.

9. Subtle Neutrality Risks

Some neutrality issues may be less visible:

  • internal or private alignment before public discussion;
  • reluctance to disagree with a dominant individual or group;
  • branding language that implies ownership by a person or organization;
  • technical or workflow dependencies accessible only to one entity;
  • consolidation of influence in a single longstanding project founder.

Addressing these issues fosters stronger community trust and increased participation.

10. Issues That Must Be Corrected

The following must be resolved for graduation:

  • decisions made privately and later announced on lists;
  • release candidates produced using private or internal infrastructure;
  • roles or privileges tied to employment or organizational membership;
  • branding implying ownership by any specific person or organization.

Relevant ASF policies include the ASF Release Policy and the ASF Trademark Policy.

11. Characteristics of a Neutral Community

A neutral project demonstrates:

  • public, archived decision-making;
  • participation opportunities not limited to a single individual or organization;
  • release processes reproducible by multiple contributors;
  • project naming and identity consistent with ASF branding policy.

What matters is that the project is open, transparent, and not dependent on a single entity.

12. Practices That Support Neutrality

12.1 Public Governance

Design, planning, roadmap decisions, and elections must take place on ASF mailing lists. Private tools (e.g., Slack, Teams, WeChat, Discord) may be used for informal coordination, but not for governance or decision-making. See ASF mailing list guidance and Communication in ASF projects.

12.2 Release Independence

Official releases must be produced using ASF infrastructure and follow the ASF Release Policy. Internal or private infrastructure may assist development, but must not produce release candidates.

12.3 Developing the PPMC

PPMC membership should reflect sustained participation in the project. Over time, podlings should show:

  • contributors from outside the dominant individual or organization participating meaningfully;
  • clear opportunities for new contributors to take responsibility;
  • decision-making not tied to a specific entity.

There is no numeric requirement, only evidence of progress and openness.

12.4 Multi-Organization but Dominant-Organization Situations

Some podlings involve contributors from several organizations but still rely heavily on one organization or one individual. This is acceptable early in incubation. Over time, the project must show that others can participate in governance, discussion, and release activities. The key question is whether contributors outside the dominant entity can influence the project’s direction.

12.5 Responsibilities of Participating Organizations and Sponsors

Organizations and individuals participating in a podling should:

  • act transparently and direct governance to public lists;
  • avoid internal coordination of votes or decisions;
  • follow ASF branding rules;
  • avoid presenting the project as owned or controlled by the entity;
  • support contributors working in the public community context.

These expectations apply equally when the dominant influence comes from an individual acting alone.

12.6 Adjusting Established Practices

If neutrality concerns arise, useful adjustments include:

  • moving all planning and governance discussions to the lists;
  • improving documentation and accessibility of build and governance processes;
  • reviewing naming and marketing to ensure ASF compliance.

12.7 Effective Mailing List Practice

Proposals should include context, be raised early, and avoid referencing private discussions. Discussion should occur on the lists to allow broad participation.

12.8 Transparency When Using Private Tools

Internal or private tools can be used for convenience, but require transparency:

  • decisions must not be made privately;
  • private discussions influencing decisions should be summarised on the lists;
  • no contributor should depend on private channels to follow or participate in project direction.

12.9 Explaining ASF Requirements Internally

Contributors may need to explain ASF expectations to managers or organizational leadership. Key points:

  • individuals act independently of their employer or group;
  • decisions must be public and archived;
  • releases must follow ASF processes and infrastructure;
  • community-led governance strengthens adoption and credibility.

See the ASF overview.

12.10 Reasonable Pace of Work

Work should proceed publicly and allow time for input. Decisions should be recorded clearly on the lists.

12.11 Indicators of Openness

Openness may be shown through:

  • clear and accessible documentation;
  • responsive communication on mailing lists;
  • public review of proposals;
  • assignment of responsibilities based on participation, not affiliation.

12.12 What the IPMC Evaluates

The IPMC evaluates:

  • whether decisions are public and archived;
  • whether participation is expanding or shows progress toward broader involvement;
  • whether releases follow ASF policy and infrastructure;
  • whether branding complies with ASF rules;
  • whether governance is sustainable and not dependent on one entity.

13. Reporting Neutrality in Podling Reports

Podling reports should briefly describe:

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

  • How release processes follow ASF infrastructure;

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

Reports should focus on clarity and progress rather than numerical summaries.

14. Role of Mentors

Mentors help identify neutrality issues early, reinforce public governance, onboard new contributors, and provide informed assessments to the IPMC regarding progress and risks.

15. Podling Responsibilities

Podlings are responsible for:

  • 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.
  • No labels