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.
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:
You can use these pages to:
Together, these examples build a shared record of ASF experience in community development.
Many 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.
Think about your own podling.
If these are challenging to answer, the following examples provide simple steps to encourage participation and share responsibility.
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:
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 entered incubation in 2018 with strong support from LinkedIn.
Most discussions initially took place in Slack and GitHub comments.
Mentors encouraged the team that decisions should be made on dev@.
Regular public summaries replaced private chats.
By 2020, contributors from organisations such as Uber and StarTree, as well as several 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 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 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 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 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.
| Pattern | What It Looks Like | Why It Matters |
|---|---|---|
| Public discussion replaces private coordination | dev@ is active and decisions are visible | Transparency builds trust |
| External pull requests receive timely replies | New contributors stay engaged | Respect for contribution improves retention |
| Rotating roles | Different people lead releases and votes | Reduces dependency on one group |
| Cross-region participation | Names from different countries appear on lists | Diversity improves continuity |
| Questions over instructions | Mentors and PPMCs invite discussion | Builds independence and shared understanding |
These patterns can appear in different forms, but each one shows visible learning of The Apache Way.
Check recent mailing list archives or votes to see if responsibility is shared.
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.
| Area | What to Ask | Signs of Healthy Growth | Signs That Need Attention |
|---|---|---|---|
| Transparency | Are discussions and decisions on dev@? | Decisions and votes are traceable | Important work happens off-list |
| Participation | Who joins votes and design talks? | People from several organisations contribute | The same group dominates discussion |
| Decision Making | How is consensus recorded? | [DISCUSS] and [VOTE] threads are consistent | Decisions made informally |
| Shared Responsibility | Who leads releases and reports? | Roles rotate and are public | The same people or company lead every time |
| Recognition and Inclusion | How are new contributors supported? | New participants are thanked and invited to help | Outside work goes unnoticed |
This material can also be used later in joint mentor–PPMC discussions.
Make decisions public
If any issues arise off-list, post a brief public summary and continue the discussion on dev@. (Pinot)
Share who leads
Rotate the next vote initiator, release lead, or report author. (APISIX)
Welcome new contributors
Post open invitations for small recurring tasks. Thank contributors publicly. (Superset)
Support multiple languages and time zones
Post bilingual summaries and encourage contributors to ask for translation help. (ECharts)
Keep governance visible
Use mailing lists for all [DISCUSS] and [VOTE] threads, with clear links to issues. (Airflow)
Track people, not just commits
Note how many unique names join votes or reports each quarter. Mention this in reports. (Airflow, Superset)
Recognise openness
Thank those who bring discussions back to dev@ and highlight shared effort. (Pinot)
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.
These show that the community is learning ASF’s open and sustainable approach to working.
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.
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.