DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
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 projects with strong corporate roots have adapted to ASF governance and built vendor-neutral communities.
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 with company origins
- compare your project’s governance model with earlier examples
- support six-month reviews or graduation discussions
- reflect on how visible independence and vendor neutrality are developing
Together, these examples build a shared record of ASF experience in developing independence and neutral governance.
Purpose and Context
Many podlings begin as company projects with strong internal support. This can accelerate technical progress but also shape culture, priorities, and communication patterns. To succeed at the ASF, these projects must learn to make all important decisions on public lists, share responsibilities, and recognise contributors as individuals rather than as company representatives.
For mentors, this case study shows how to support that cultural shift without discouraging corporate investment. For PPMC members, it shows how to strike a balance between company participation and visible independence, as well as vendor-neutral governance in community decisions and releases.
This case study draws on five real examples: Iceberg, Kafka, Cassandra, Pulsar, and Airflow. Each began with strong company backing and learned how to establish open, ASF-style governance that could continue beyond its corporate origin.
Quick Check
Think about your own podling.
- Do discussions and votes take place entirely on the public list, or are they reviewed internally first?
- Who proposes releases and starts [VOTE] threads? Is it always the same company?
- Do independent contributors feel confident to lead activities?
- Do contributors from all organisations have an equal voice in decisions, regardless of employer?
- Are company brands mentioned more often than the Apache project name?
- Does everyone understand that the ASF owns the project and its trademarks?
If these questions raise uncertainty, the examples below show practical ways to demonstrate independence, neutrality, and balance.
How to Use These Case Studies
The case studies highlight common practices and turning points from past podlings that began as company projects.
You can use them as reference material when mentoring, preparing reports, or assessing community independence.
They can help you:
- recognise early steps toward transparent and vendor-neutral governance
- support independence while maintaining goodwill with sponsoring companies
- identify when private coordination is limiting progress
- apply ASF values of transparency, community consensus, and individual merit
Case Studies
These examples show how company-backed podlings achieved visible independence and vendor neutrality while maintaining healthy collaboration with their sponsors.
Iceberg
Iceberg entered the Incubator in 2018 after being created at Netflix.
It quickly attracted contributors from Apple, Alibaba, Adobe, LinkedIn, and independent developers.
Mentors supported the community’s focus on branding, mailing-list transparency, and balanced release processes.
Integrations with Spark and Flink began during incubation, and later adoption by Trino expanded visibility.
Key Point: Openness and early inclusion of other organisations built credibility and vendor-neutral participation.
What Mentors and PPMCs Can Do: Encourage public discussions and recognise independent contributors in votes and releases.
Kafka
Kafka, created at LinkedIn, joined the Incubator in 2011.
Its first ASF release appeared the same year, and regular cadence followed.
Contributors from Netflix, Yahoo, and independents joined early, and mentors reinforced consistent communication and voting practices that became reference points for later podlings.
As the ecosystem grew commercially, the community continued to reflect on the balance of governance as the commercial ecosystem expanded.
Key Point: Neutrality is an ongoing practice, not a milestone.
What Mentors and PPMCs Can Do: Reinforce that ASF decisions happen on public lists, and revisit governance balance as ecosystems expand.
Cassandra
Cassandra began at Facebook and entered the Incubator in 2009.
It shipped its first incubating release within months and grew contributors from Digg, Rackspace, and independents.
Mentors encouraged mailing-list-based decision making and formal ASF voting norms.
This early shift to transparency helped the community remain resilient, balanced, and vendor-neutral as new companies joined.
Key Point: Early adoption of transparent processes protects independence and neutrality later.
What Mentors and PPMCs Can Do: Ensure voting and discussion habits are established before graduation.
Pulsar
Pulsar was developed at Yahoo and joined the Incubator in 2017.
The community maintained a steady release cadence and open communication, with contributors from Splunk, StreamNative, Tencent, and independents.
Mentors reinforced open governance and the clear separation of company and community decision-making.
Key Point: Consistent transparency builds trust across corporate boundaries and sustains neutrality.
What Mentors and PPMCs Can Do: Keep technical coordination public and record all governance decisions on mailing lists.
Airflow
Airflow started at Airbnb in 2014 and entered the Incubator in 2016.
Mentors helped move all discussions to dev@, encouraged contributors from Google, Polidea, and independent developers, and promoted the rotation of visible responsibilities, such as release coordination.
By graduation, it had become a broad, multi-company community with balanced decision-making.
Key Point: Sharing visible responsibilities shows that leadership is collective, not corporate.
What Mentors and PPMCs Can Do: Invite different contributors to coordinate releases and assist with reporting to reinforce vendor-neutral practice.
Across these examples, one lesson is consistent:
Corporate support can help a project get off to a strong start, but lasting success depends on public decision-making, balanced visibility, and vendor-neutral governance, where all contributors act as individuals.
Common Patterns Seen in Podlings
| Pattern | What It Looks Like | Why It Matters |
|---|---|---|
| Public discussion replaces internal coordination | Plans and releases decided on mailing lists | Builds trust and visibility |
| Multiple companies in key roles | Contributors from several organisations lead votes | Demonstrates shared ownership |
| Independent contributors recognised | Non-corporate participants acknowledged in reports | Reinforces inclusivity and balance |
| Mentors guide, not manage | Mentors explain ASF process without directing work | Encourages community learning |
| Corporate identity balanced with ASF identity | ASF brand leads communication and websites | Reduces confusion over ownership |
| Vendor-neutral governance | Votes and discussions include multiple organisations with equal weight | Prevents dominance or perception of bias |
These patterns show practical ways for podlings to demonstrate independence and shared responsibility.
Early Warning Signs
- The same company staff initiate most [VOTE] and [DISCUSS] threads
- Private coordination happens before public discussion
- Mentors receive updates privately rather than through public lists
- Company branding dominates project materials
- Independent contributors hesitate to propose releases or lead discussions
- A company expects committer status as part of employment performance rather than merit
- One company’s views regularly prevail without consensus or explanation
When these appear, mentors should raise the topic early and frame independence and neutrality as shared goals.
Reviewing Your Community’s Independence
This table helps mentors and PPMCs reflect on where visible independence is strong and where it may need attention.
It is a self-review tool, not a formal ASF checklist.
| Area | What to Ask | Signs of Healthy Independence | Signs That Need Attention |
|---|---|---|---|
| Transparency | Are all decisions on dev@? | Votes and decisions traceable publicly | Private coordination remains common |
| Diversity of Roles | Who leads releases and reports? | Visible rotation of responsibilities | Same people or company each time |
| Decision Making | Are votes and discussions well documented? | [DISCUSS] and [VOTE] threads link to outcomes | Decisions happen informally or are unclear |
| Governance Balance | Are company and community goals clearly separated? | ASF-first communication and vendor-neutral decision making | One company dominates votes or governance discussions |
| Recognition | Are independents visible and thanked? | Independent contributions appear in reports | Only corporate staff credited |
| Mentor Engagement | Are mentors guiding policy use, not decisions? | Mentors reinforce openness and culture | Mentors substitute for PPMC leadership |
Using These Examples
For Mentors
- Identify where company coordination is still influencing public process.
- Encourage open discussion about governance expectations.
- Help companies understand that transparency and vendor neutrality benefit credibility.
For PPMC Members
- Review mailing list activity and identify where decisions need to move to public discussion.
- Invite contributors from other organisations to lead visible tasks.
- Explain ASF governance internally so that company management understands the independence and neutrality of the project.
Optional reuse: This material can also be used later in joint mentor–PPMC discussions.
Mentor and PPMC Reference Actions – Building Corporate Independence
Move private coordination to public lists
Post summaries of internal discussions or plans ondev@to invite community input. (Cassandra, Iceberg)Share visible responsibilities
Alternate release coordination, vote initiation, and report authorship among contributors. (Airflow, Pulsar)Acknowledge independent contributors
Thank them publicly in reports and invite them to take lead roles. (Iceberg)Clarify ownership and governance
Make clear that the ASF, not any company, owns the project’s trademarks and direction. (Kafka)Keep branding neutral
Review websites and documentation to ensure ASF identity comes first. (Cassandra)Encourage open mentor coordination
Mentors should discuss guidance in public to maintain shared understanding. (Pulsar)Promote vendor-neutral participation
Encourage balanced discussion and visible decision making that reflects input from multiple organisations. (Kafka, Pulsar)
Common Mentor and PPMC Pitfalls
- Accepting internal company consensus before public discussion (Kafka)
- Using company communication tools instead of public lists (early Airflow)
- Assuming financial support equals leadership (early Iceberg)
- Overlooking independent contributors or failing to highlight their roles (Pulsar)
- Relying on mentors to arbitrate company issues rather than community process (Cassandra)
Linking to ASF Oversight
Mentors and PPMCs should highlight visible signs of independence and vendor neutrality in podling reports. The IPMC looks for evidence of balanced governance, transparent decision-making, and individual recognition.
Examples of Evidence for Podling Reports
- Release managers from multiple organisations (Airflow)
- Public votes and design discussions replacing private coordination (Cassandra)
- ASF branding and disclaimers clearly shown (Iceberg)
- Open community dialogue about vendor influence and neutrality (Kafka)
- Clear separation between company and community decisions (Pulsar)
These demonstrate that a podling is operating as an independent and vendor-neutral ASF community.
ASF Cultural Perspective
Independence is central to ASF culture. It is not the absence of company participation but the presence of balance, transparency, and respect for individual merit. Corporate support can strengthen a project when it aligns with ASF principles of open governance and community consensus. Mentors and PPMCs share responsibility for making this independence and vendor neutrality visible and sustainable. Independence within the ASF means open decision making, shared consensus, and recognition of contributors as individuals who earn trust through contribution.
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.