Processes can be copied; culture must be learned

Sustaining a project requires more than code

ASF values guide how communities make decisions, grow, and resolve conflict

Best followed in sequence, but each stands alone

Embedded in podling training, checkpoints, and mentor discussions

Reflection questions are prompts for mailing list or mentor conversations

Quizzes are for self-check, not grading

Technical and governance discussions happen on public lists

Private channels (chat, calls, Slack) are fine for brainstorming, but outcomes must be written back to the list

Mailing lists are the source of record for project decisions

“If it didn’t happen on the list, it didn’t happen.”

Ensures accountability and trust within the community

Allows new contributors to follow history and context

Prevents “insider” and “outsider” dynamics

Protects ASF’s reputation for open governance

Everyone on the mailing list can contribute to discussions

Objections must be heard and addressed — not ignored

“Lazy consensus”: silence is treated as agreement unless someone objects

Votes are public, transparent, and archived

Ensures decisions reflect the whole community, not just one group

Builds durable buy-in and trust

Reduces surprises and prevents domination by any vendor or individual

Protects ASF’s reputation for neutral, open governance

Contributors gain responsibility by demonstrating commitment

Merit is judged by community, not employers

Roles: contributor → committer → PMC/PPMC

Contributions can be code, docs, reviews, community work

❌ “Meritocracy means the loudest voice wins”

❌ “Only code counts”

❌ “Seniority at a company equals merit at Apache”

✅ Reality: Merit is earned through consistent, constructive contributions across many forms

Encourages open participation — anyone can rise through contribution

Builds a sustainable pipeline of new leaders

Prevents concentration of control in a small group or one company

Demonstrates ASF’s fairness and openness to the wider community

Strong communities can always fix weak code

Weak communities cannot sustain even great code

Decision-making, mentoring, and inclusivity are as important as technical output

Graduation depends on community health, not just releases

Ensures projects outlast individual contributors or companies

Encourages collaboration and mentorship

Builds resilience against burnout or “bus factor” risks

Reinforces ASF’s mission of sustainable, diverse communities

No single company controls the project or its direction

Contributors act as individuals, not company representatives

Technical merit matters more than employer or sponsorship

Governance is balanced across diverse participants

Protects ASF’s reputation for independence and fairness

Encourages outside contributors to join without fear of corporate control

Reduces legal and trademark risks tied to company ownership

Builds long-term sustainability as companies come and go

The ASF owns project names and logos

Podlings must follow ASF branding guidelines

Names, marks, and domains cannot be controlled by individuals or companies

Projects must consistently use the “Apache <Project>” name in all materials

Consistent use of ASF trademarks protects both the project and the Foundation

Safeguards ASF’s credibility and independence

Ensures users know they are getting the official ASF project

Prevents legal disputes and confusion

Reinforces the project’s status as a community-driven effort

ASF values are as important as technical milestones

Healthy communities grow through transparency and consensus

Responsibility is earned by merit, not granted by employers

Projects thrive when community comes before code

Neutrality and branding protect the ASF and its projects

Apply these principles in your podling community

Discuss reflection questions with your mentors and peers

Use these as a reference throughout incubation

Remember: incubation is about learning the Apache Way, not just checking boxes