RE: [VOTE] Accept Maka into the Apache Incubator

Hi Mingcheng,

Thank you for clarifying your concerns. We agree that the risks you identified are worth discussing and tracking. To avoid talking past each other, I would like to explain how we currently view the four points you proposed.

First, regarding community independence: Maka is young, and we do not claim that the community is already mature. The proposal currently lists seven initial committers with seven different affiliations: four companies, two universities, and one individual contributor. It also acknowledges that some initial contributors have overlapping social and professional relationships.

We agree that meaningful independence must ultimately be demonstrated through sustained participation, review authority, release ownership, and public decision-making—not merely through a list of affiliations. We therefore see this as an important graduation criterion and something to track in podling reports, rather than something we should claim as already proven at entry.

Second, regarding a time box and exit condition: the proposal already acknowledges the risks associated with the project’s young age. It estimates that incubation may take approximately two years, while making graduation dependent on sustainable community growth, public governance, shared release ownership, and compliant releases.

If the project fails to develop a sustainable community, the Incubator’s normal reporting and retirement processes already apply. We do not currently believe that a Maka-specific automatic retirement trigger after 12 months is necessary, but we are willing to make community diversity and shared ownership explicit items in the podling’s early reports.

Third, regarding AI-assisted development: we agree that this deserves clearer explanation.

AI-assisted programming is already a common engineering practice across the industry and the open-source community. In Maka, it is not limited to Jie or to the initial bootstrap period. Multiple developers use LLM-based tools independently while working on different parts of the project. The resulting code is still proposed, reviewed, tested, integrated, and owned by human contributors.

For current collaborative development, Maka places particular emphasis on review quality. In addition to human peer review, we use LLMs adversarially: a separate review pass, often using a separate model or context, is instructed to challenge the proposed implementation rather than continue it. It looks for correctness problems, security risks, missing tests, maintainability issues, unsupported assumptions, and inconsistencies with the existing architecture.

This adversarial LLM review is an additional review layer, not a replacement for human judgment. Human contributors remain responsible for deciding whether a change is correct and acceptable. Automated tests, type checking, builds, CI checks, and, where relevant, runtime or visual verification provide evidence independent of either the generating model or the reviewing model.

For that reason, we believe the meaningful question is whether a contribution has accountable human ownership and sufficient review and verification—not what percentage of its text can be attributed to an LLM. The May 20–23 bootstrap period was heavily AI-assisted, but the repository does not preserve a reliable token-level boundary between machine suggestions, human edits, review-driven revisions, and subsequent integration. Providing a percentage would therefore imply a precision that we cannot substantiate.

We can instead document, to the extent that it can be reconstructed reliably:

- the primary tools used during the initial development;
- the areas and purposes for which they were used;
- the human and adversarial review practices applied;
- and the tests or other verification evidence supporting the resulting code.

Going forward, we are also willing to make AI-tool disclosure and review expectations explicit for contributions, consistent with ASF guidance. The contributor submitting a change will remain accountable for its correctness, licensing, and quality regardless of the tools used.

LLM-based review is not treated as license clearance. The proposal separately commits the project to reviewing the provenance of the initial codebase, checking source and dependency licensing, and removing, replacing, or reimplementing anything whose provenance or licensing cannot be established. Such code will not be included in an Apache release.

Finally, regarding public decision-making: we agree. The proposal already states that project-level decisions and voting will move to the public development mailing list after entering incubation. GitHub issues and pull requests may continue to support implementation-level collaboration, but they will not replace the mailing list for project and community decisions.

We are willing to improve the proposal by documenting the project’s AI-assisted development and review practices more clearly. At the same time, we believe that sustained community independence should be demonstrated during incubation, and that the normal Incubator oversight and retirement mechanisms are sufficient without introducing a project-specific 12-month exit rule.

Thank you again for making these concerns explicit.

Best regards,
Kun
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]