Why balanced governance keeps Apache projects healthy
Understand why vendor neutrality is essential for ASF project health and independence
Learn how to identify and prevent single-vendor dominance
Explore practices mentors and podlings can adopt to build balanced, sustainable communities
Vendor neutrality means an Apache project isn’t controlled by any one company or sponsor.
It supports three ASF principles:
Meritocracy: influence comes from contribution, not employment
Consensus: decisions reflect community agreement, not one company’s goals
Transparency: work and discussions happen openly on ASF lists
These principles turn vendor-led efforts into community-led Apache projects.
Vendor neutrality keeps Apache projects open, decisions belong to the community, not a company.
Projects that start under one sponsor succeed when they invite others to share ownership and grow together.
A single-vendor start is common and can bootstrap early success.
It becomes a risk when:
Committers or PPMC are mostly from one employer
Decisions are made privately, then rubber-stamped on-list
External contributors struggle to gain traction
What matters most is visible progress toward independence.
One vendor dominates with no plan to diversify
Chair and PMC majority from the same employer
Decisions happen off-list (Slack, internal meetings)
Brand confusion between company and project
One vendor drives outcomes despite numerical diversity
Visible roles (e.g., release managers) span multiple organizations
Independent individuals contribute and are recognized by merit
Roadmaps include externally proposed features
Lists show real debate and consensus across affiliations
Good practice
A contributor from another org proposes a feature and is later invited as a committer
Release management rotates across employers
Companies collaborate in public, not in private first
Bad practice
Roadmaps follow a company’s product cycle
Decisions drafted internally, then “announced” on-list
Marketing presents the Apache project as a company product
Mentors help podlings move from single-vendor control to balanced, community-led governance by:
Watching for dominance and raising concerns early
Encouraging rotation of leadership roles
Reinforcing that decisions happen on ASF lists
Helping identify and onboard outside contributors
Reporting progress and risks to the IPMC
Welcome contributors from multiple organizations
Keep decisions and discussions on ASF mailing lists
Disclose employer affiliations in nominations and votes
Rotate key responsibilities to distribute influence
Use Apache project names consistently and correctly
Mentor independent contributors toward committership
Encourage contributors to share their own views, not just their employer’s
Welcome global participation and different working styles
Value both paid and volunteer contributions
Open consensus prevents vendor-driven conflict
Keep all substantive decisions on-list
ASF brand policy requires clear separation between Apache projects and any company’s products or marketing.
Balanced PPMC: no single employer holds majority control
Independent perception: seen as an Apache project, not a vendor asset
Community-driven roadmap: consensus on-list, not corporate deadlines
Distributed leadership: roles shared across employers and individuals
Companies benefit from neutrality:
Builds community trust
Shares maintenance and innovation
Strengthens the ecosystem
Enhances open-source reputation
Independent contributors are vital:
They prove the project can outlast any one employer
They bring balance and fresh ideas
Graduation reviews look for:
Diversity across employers in the PPMC
Evidence of list-based decision making
Clear distinction between Apache identity and vendor branding
Delayed graduation
Board pushback
Possible retirement for vendor-dominated projects
Neutrality is inclusion - everyone can contribute, no one dominates. A balanced, diverse community is what makes Apache projects thrive and endure.
How can your podling show progress toward neutrality?
Which roles could rotate next to build balance?