ASF Incubator Case Study: Community Growth and Diversity

DRAFT – FOR REVIEW
This content is subject to review by the IPMC and the project community. This material was developed by individuals outside the individual podling communities, who may view events differently than those directly involved. Some content was AI-generated and may contain errors; however, the material has been reviewed and verified by a human for accuracy. It is provided for training and discussion purposes and may contain minor simplifications or adjustments for clarity.

About the ASF Incubator Case Studies

The ASF Incubator Case Studies collect real lessons from podlings across the Incubator. Each case study groups together projects that faced similar challenges and shows how mentors and communities addressed them.

These case studies are intended as reference material for mentors, PPMC members (Podling Project Management Committees), and contributors who want to understand how communities have grown and matured during incubation.

Each case study includes:

• examples based on verified ASF records and reports
• common challenges and how they were handled
• short questions to think about for your own project
• direct links to ASF policies and guides

You can use these pages to:

• prepare for mentoring or helping lead a podling
• compare your project’s progress with earlier examples
• support six-month reviews or graduation discussions
• reflect on community growth and transparency

Together, these examples build a shared record of ASF experience in community development.

Purpose and Context

Most podlings begin as small teams from one organisation. To become a successful Apache project, the team must expand to include contributors and decision-makers from diverse backgrounds and locations. Learning to work openly and inclusively is the heart of incubation.

For mentors, this case study shows how to support that change without taking control. For PPMC members, it demonstrates how real projects fostered participation, shared responsibility, and prepared them for graduation.

This case study draws on five real examples: Pinot, Superset, Airflow, ECharts, and APISIX. Each example demonstrates how openness and shared responsibility contributed to a project's growth into a healthy, balanced community.

Quick Check

Think about your own podling.

• Are discussions and decisions happening on public lists, as Pinot learned to do after sharing regular summaries?
• Who usually starts votes and releases — always the same people, as in early APISIX before rotation was encouraged?
• When did someone new last lead a review or proposal, as Superset did when it welcomed outside contributors?
• Do contributors from other regions or languages take part, as ECharts achieved through bilingual updates?

If these are challenging to answer, the following examples provide simple steps to encourage participation and share responsibility.

How to Use These Case Studies

The case studies highlight common practices and turning points from past podlings.
You can use them as references when mentoring, preparing reports, or reflecting on community progress.

They can help you:

• recognise behaviours that show community maturity
• support practices that build independence, not dependency
• spot early signs of burnout or imbalance
• describe visible progress in openness and participation
• apply ASF values of transparency, consensus, and trust through contribution

Case Studies

These examples show how different podlings have built openness and shared responsibility in their own unique ways.
Each faced similar challenges, from private discussions to unbalanced leadership, and solved them through small, visible steps.

Pinot

Pinot entered incubation in 2018 with strong support from LinkedIn.
Most discussions initially took place in Slack and GitHub comments.
Mentors reminded the team that decisions should be made on dev@.
Regular public summaries replaced private chats.
By 2020, contributors from Uber, StarTree, and independent developers were active on the list, and more people joined in release votes.

Key Point: Open communication builds trust and inclusion.
What Mentors and PPMCs Can Do: Keep all decisions public and encourage regular summaries.

Superset

Superset joined the Incubator in 2017. Many outside pull requests were waiting for review.
Mentors encouraged regular, open reviews of external work on dev@.
Within a year, contributors from several companies were active, and new committers were added from outside Airbnb.

Key Point: Timely, public feedback invites participation.
What Mentors and PPMCs Can Do: Create habits for reviewing outside contributions quickly and visibly.

Airflow

Airflow experienced rapid growth after its founding in 2016.
Mentors saw that votes and decisions were being made in issue comments.
The community adopted clear [DISCUSS] and [VOTE] threads linked to JIRA issues.
This kept decisions clear and supported healthy growth.

Key Point: Clear process supports growth.
What Mentors and PPMCs Can Do: Keep mailing lists as the official place for decisions and link them to issues.

ECharts

ECharts entered incubation in 2018, originating from Baidu, with discussions primarily conducted in Chinese.
Mentors and PPMC members started bilingual documentation and summaries of local chats on dev@.
Contributors were encouraged to post in English, even if imperfectly, and volunteers assisted with translations.
Participation widened to include developers from many regions.

Key Point: Inclusion can grow gradually while staying transparent.
What Mentors and PPMCs Can Do: Support bilingual summaries and be patient with contributors learning ASF communication norms.

APISIX

APISIX joined in 2019 with strong support from one company.
Mentors encouraged rotating release managers and inviting outside contributors to lead tasks.
Public planning threads made leadership visible.
By graduation, several independent contributors were leading releases and features.

Key Point: Shared roles show independence.
What Mentors and PPMCs Can Do: Rotate visible roles like release leads and report authors to demonstrate shared leadership.

Across these examples, similar lessons appear:
Making discussions public, inviting wider review, and sharing visible roles all help new communities grow stronger.

Common Patterns Seen in Podlings

These patterns can appear in different forms, but each one shows visible learning of The Apache Way.

Early Warning Signs

• The same people start most [DISCUSS], [VOTE], and release threads
• Proposals come mainly from one organisation’s staff
• Outside contributors rarely get replies or feedback
• Only one or two people post summaries or updates
• Reports mention code changes but not community activity

Check recent mailing list archives or votes to see if responsibility is shared.

Reviewing Your Community’s Growth

This table helps mentors and PPMCs discuss what is working and where openness can improve.
It is a self-review tool, not an ASF checklist.

Using These Examples

For Mentors

• Read one or two examples that resemble your podling.
• Choose one improvement from the Reference Actions to encourage this month.
• Use the Early Warning Signs to check progress before each report.

For PPMC Members

• Review one example with your team.
• Use the table above to identify an area to improve.
• Try one visible change, such as rotating a role or posting regular summaries.

Optional reuse

This material can also be used later in joint mentor–PPMC discussions.

Mentor and PPMC Reference Actions – Building Community Growth and Diversity

1. Make decisions public
   If any issues arise off-list, post a brief public summary and continue the discussion on dev@. (Pinot)

2. Share who leads
   Rotate the next vote initiator, release lead, or report author. (APISIX)

3. Welcome new contributors
   Post open invitations for small recurring tasks. Thank contributors publicly. (Superset)

4. Support multiple languages and time zones
   Post bilingual summaries and encourage contributors to ask for translation help. (ECharts)

5. Keep governance visible
   Use mailing lists for all [DISCUSS] and [VOTE] threads, with clear links to issues. (Airflow)

6. Track people, not just commits
   Note how many unique names join votes or reports each quarter. Mention this in reports. (Airflow, Superset)

7. Recognise openness
   Thank those who bring discussions back to dev@ and highlight shared effort. (Pinot)

Common Mentor and PPMC Pitfalls

• Doing the work yourself instead of helping the PPMC lead (Airflow’s early stage)
• Asking for transparency but not showing how to achieve it (Pinot before public summaries)
• Pushing for faster releases instead of wider participation (Superset)
• Treating ASF process as rules instead of shared learning (ECharts’ early adjustment)

Linking to ASF Oversight

Mentors and PPMCs should include visible signs of community growth in podling reports. The IPMC looks for clear examples of transparency, collaborative work, and independent decision-making.

When preparing for graduation, describe specific behaviours, not just activity counts.

Examples of Evidence for Podling Reports

• Different contributors leading votes or releases (APISIX)
• Outside developers reviewing and merging pull requests (Superset)
• Public summaries replacing private coordination (Pinot)
• Bilingual participation improving communication (ECharts)
• Rotating leadership in releases and reports (Airflow)

These show that the community is learning ASF’s open and sustainable approach to working.

ASF Cultural Perspective

Community growth is not management. It is built on trust and public contribution. Mentors and PPMCs share responsibility for making those habits visible. The PPMC leads by example; mentors guide and support. Diversity means sharing decisions so that no single group has control over the project.

A Shared Record of Experience

This case study summarises information from ASF public mailing lists, podling reports, and status pages. It was written from the perspective of observers outside the individual podling communities. Community members may hold differing views on events or timelines, and minor simplifications may be made for clarity or training purposes. It includes historical information drawn from public ASF sources and does not represent the current state of any project mentioned. This content may contain errors or omissions due to AI-generated elements. However, the material has been reviewed and verified by a human for accuracy. These factors do not reduce its value as a reference for understanding patterns of incubation and global collaboration.