DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Purpose, Practice, and Lessons Learned
Why Incubation Exists
Incubation exists to ensure new projects align with ASF values such as community, meritocracy, transparency, and vendor neutrality. It provides structured support for projects beginning their ASF journey, guiding them as they build sustainable communities and governance before becoming Top-Level Projects (TLPs). The Incubator also serves as a way to test readiness. Some projects graduate as TLPs, while others are retired if they cannot establish a sustainable community.
Most importantly, the Incubator is not just about process. It is where projects learn and practice the Apache Way, transparency, consensus, meritocracy, and community over code, so these values are embedded before graduation.
How the Incubator Evolved
The Incubator was created in the early 2000s to handle the influx of external projects wanting to join the ASF. Initially, its role focused mainly on license compliance and the legal vetting of incoming code donations.
In its early years, many podlings were brought in as part of large umbrella efforts, such as Jakarta, XML, and WS. This approach sometimes hid weak or vendor-driven subprojects, and over time, the ASF learned that independent podlings with clear accountability were a better fit.
Vendor dominance also proved challenging in the mid-2000s, shifting the emphasis toward community building and ensuring that projects were not dependent on a single company. Around the same time, some podlings experimented with drafting their own bylaws, but these conflicted with ASF-wide norms. The practice was phased out, and podlings now adopt the ASF governance model for consistency and a smoother graduation process.
As incubation grew, the Incubator PMC (IPMC) developed into a more structured body for oversight, rather than relying on ad-hoc monitoring. This included the introduction of regular monthly and quarterly reporting cycles to ensure podlings remained active and visible, and to catch issues before they grew. Over time, graduation templates, release checklists, and clearer documentation were also introduced to replace the once-oral tradition and scattered practices.
Mentor roles were clarified as well. Early podlings sometimes assumed mentors would “do the work” of incubation. Still, experience showed the importance of mentors guiding rather than leading, so that podlings themselves built the capacity to operate independently.
In recent years, podlings have also become increasingly global. New projects often involve contributors from multiple regions, cultures, and time zones, reflecting the ASF’s increasingly international community. This shift has made cultural awareness and inclusive practices an even more important part of incubation.
Finally, the scope of podlings has broadened. Where early projects were often Java-based and infrastructure-focused, today’s podlings encompass a wide range of languages and domains, including machine learning, cloud infrastructure, and data engineering.
Taken together, these changes demonstrate the Incubator’s evolution: from a lightweight legal checkpoint to a mature, global, and culturally diverse gateway. Today, it acts as both a gateway and a training ground - supporting projects while testing if they are ready to self-govern the Apache Way.
Connection to ASF Governance
The Incubator is a formal Project Management Committee (PMC) of the ASF, with its own charter and oversight responsibilities. Its governing body, the Incubator PMC (IPMC), is responsible for voting on podling releases, reviewing reports, and approving graduation. While the IPMC holds authority, much of the day-to-day guidance is delegated to mentors, who work closely with podlings. In effect, podlings “borrow” ASF resources under the Incubator until they graduate and form their own TLP, at which point they assume complete independence.
Lessons Learned
The Incubator’s structure is shaped by lessons gathered over many years. Vendor dominance once compromised community independence, leading to heightened expectations for diverse governance. The umbrella project model diluted accountability, so the ASF shifted toward podlings graduating as independent TLPs with clear responsibility. Drafting bylaws at the podling level created confusion and inconsistency, so projects now adopt the ASF’s established governance framework. Experience showed that projects without regular releases often stalled, making them an important checkpoint. And while some communities looked active in GitHub statistics, they struggled with participation in the ASF culture, highlighting the need for reporting and oversight.
Taken together, these lessons demonstrate that the Incubator’s rules are not arbitrary bureaucracy, but rather guidelines that have proven effective in helping projects succeed.
Success Stories
Incubation has been the entry point for many of the ASF’s most widely used projects. Apache Hadoop, Apache Kafka, Apache Spark, and Apache Airflow all began as podlings. Each of these projects faced challenges in community growth and governance, but they matured into successful, sustainable Top-Level Projects. Their journeys demonstrate that incubation is not simply about filtering projects but about supporting them as they grow into healthy, independent communities.
Diversity of Podlings
Podlings come into the Incubator with very different starting points. Some arrive with strong vendor backing and dozens of contributors, while others begin with just a handful of volunteers and an idea. Both approaches are valid. The Incubator provides a consistent framework for all, offering cultural guidance, governance practices, and community-building support, so that every podling has the opportunity to become sustainable within the ASF model.
Not every podling’s journey looks the same. Some graduate quickly, others take longer, and a few may decide to retire. The Incubator provides flexibility as long as the core principles of the Apache Way are being learned and practised.
Common Misconceptions
Purpose of Incubation
It’s easy to assume incubation is only about licenses or checking code. While license review is essential, the ultimate goal is to help projects build independent communities that can self-govern according to the Apache Way. Code matters, but it’s the people and governance practices that ultimately determine whether a project thrives in the long term.
Process of Incubation
Some people think that graduation occurs automatically after a certain amount of time, or that mentors will guide a podling through the process. In reality, there is no fixed timeline; graduation depends on the community demonstrating readiness. Mentors guide, but podlings must learn by doing: running their own votes, managing releases, and reporting openly.
Governance and Rules
New podlings sometimes want to invent their own bylaws or keep their company’s branding. In practice, podlings adopt ASF governance and branding, allowing them to stand on their own as neutral, community-driven projects. Infrastructure support is provided, but podlings are expected to own their builds, releases, and CI.
Perceptions of Incubation
From time to time, the Incubator is described as heavy, bureaucratic, or even “where projects go to die.” In practice, many of the ASF’s most successful projects, including Hadoop, Kafka, Spark, and Airflow, all came through incubation. Retirements do happen, but they serve an essential role: ensuring only communities ready to self-govern graduate.
Graduation and Beyond
Another myth is that graduation is the end of oversight, or that it means a project is perfect. Graduation signifies that the community has acquired sufficient knowledge to self-govern within the ASF model. Oversight continues through the ASF Board, and like all open source efforts, projects continue to evolve and face challenges even after graduation.
Perceptions & Criticism
The Incubator is occasionally discussed critically, both within and outside the ASF. Concerns are sometimes raised about bureaucracy, reporting, or whether the process is suitable for all types of projects.
Some of these observations have led to real improvements, for example, ending the umbrella project model, phasing out podling-specific bylaws, and clarifying mentor roles. Other comments reflect broader debates about ASF culture and governance.
What’s vital for podlings and mentors to know is that the Incubator is not static. It has evolved many times in response to experience, and it continues to balance two goals: supporting new communities and protecting the ASF brand. Retirement is also a valid outcome when a community does not achieve sustainability, and while it can be disappointing, it reflects the ASF’s commitment to the long-term health of its projects. Criticism is part of the conversation, but the track record of successful graduates shows the process works.
Why This Matters
Understanding the history and context of the Incubator helps podlings see incubation as a supportive growth process that prepares them for independence. It also explains why rules exist, they reflect lessons learned across many projects. By addressing common myths and misconceptions, this background reduces frustration and sets clearer expectations.
Not every podling’s path is the same, and that flexibility is deliberate. The Incubator continues to adapt as the ASF grows, reflecting both lessons learned and the needs of future communities. Most of all, this reinforces the Apache Way as the foundation for long-term project sustainability.