docs(hami): HAMi incubation due diligence

[angellk]

NOTE: Open for public comment until June 29, 2026

HAMi Incubation Due Diligence

Application issue: #1775
DD file: projects/hami/hami-incubation-dd.md
Checklist: cncf/toc-private#123

Summary

Due diligence for HAMi applying for Incubation. All criteria evaluated; three adopter interviews complete across education, cloud platform, and tech platform verticals.

Distinctive findings:

• Product Security Team documented with ~48h response target
• Five maintainers across four organizations; multi-vendor GPU scope TOC-verified
• LFX Insights overall health Excellent — 100 quarterly active contributors, 360/365 active days
• Five independent CNCF case studies with production narratives across distinct verticals

TOC assignees: @angellk (primary), @kevin-wangzefeng (co-sponsor, adopter interviews)

Non-blocking recommendations are documented in the DD across all sections.

Files

• projects/hami/hami-incubation-dd.md — full incubation DD
• projects/hami/project-metadata.md — project metadata index

[pmady]

i've contributed to HAMi, merged PR #1893 (unit tests for nvinternal info, mig, and watch packages). a few things i noticed as a contributor:

the codebase is well-structured and the review process was thorough — maintainers gave detailed feedback and the CI pipeline caught real issues. the multi-vendor GPU support (NVIDIA, AMD, Cambricon) is genuinely useful, not just checkbox support, the abstraction layer actually works across vendors.

HAMi fills a gap that nothing else in the CNCF ecosystem covers right now. projects like KEDA handle autoscaling and Volcano handles scheduling, but neither does GPU sharing and virtualization at the device level. i've worked with both and HAMi is complementary to everything else in this space.

supportive of incubation.

[mesutoezdil]

I've been contributing to HAMi for a while across HAMi core (15+ merged PRs), HAMi-DRA (15+ merged PRs), and the website (200+ merged PRs). I'm a member of the Project-HAMi GitHub organization.
Beyond code contributions, I've written several hands-on articles about HAMi on my Substack (AR-Kube) covering real production deployments on an NVIDIA L40S node, and built a lab integrating HAMi with kagent on Kubernetes (kagentWithHami). Every post is based on actual cluster output, not documentation summaries.
From that work: the codebase is well-maintained, the review process is genuinely rigorous, and the DRA integration is the most important technical direction the project is pursuing right now. HAMi-DRA positions the project as the reference implementation for GPU sharing on top of Kubernetes DRA, which nothing else in the CNCF ecosystem covers.
Supportive of incubation. Thanks @angellk!

[rootsongjc]

I've been involved with HAMi primarily from the community and ecosystem side.

Over the past year, I've seen HAMi grow from a project known mainly for GPU sharing into a broader community around AI infrastructure and heterogeneous computing. What stands out to me is the diversity of contributors, adopters, GPU vendors, and ecosystem partners participating in the project.

HAMi has built a healthy and active community with real user adoption, regular community engagement, and growing ecosystem collaboration.

Supportive of incubation.

[maishivamhoo123]

I've been involved with HAMi and the HAMi-Project for a while and have 20+ merged PRs. I'm also a member of the Project-HAMi GitHub organization.

As a student, I've been impressed by several aspects:- the codebase is well-structured and the review process is genuinely rigorous—maintainers provide detailed feedback and are really helpful. The documentation is really nice and easily understandable, which makes contributing smooth and approachable.
.
What's most impressive is that HAMi fills a unique gap in the CNCF ecosystem. While projects like KEDA handle autoscaling and Volcano handles scheduling, neither addresses GPU sharing and virtualization at the device level. HAMi is complementary to everything else in this space and solves a real problem.

Supportive of incubation

[haitwang-cloud]

I've been contributing directly to HAMi in this repository since January 2024, with more than 60 commits in the project history.

Two years ago, while working on NVIDIA GPU virtualization, I came across HAMi and was immediately struck by how much more flexible it was than the official k8s-device-plugin. At that time, the community was still in its early stages. Since then, it has been exciting to watch HAMi grow into a CNCF Sandbox project and mature alongside the rapid development of the broader GPU ecosystem.

What stands out most to me is HAMi's unique role in the cloud native ecosystem. Projects like KEDA and Volcano solve important problems around autoscaling and scheduling, but neither addresses GPU sharing and virtualization at the device level. HAMi fills that gap. With HAMi as a single control plane, it becomes possible to orchestrate NVIDIA GPUs alongside a wide range of domestic accelerators such as Cambricon, Hygon, Ascend, Iluvatar, and Moore Threads under one unified layer. That kind of operational simplification is extremely valuable in real-world environments.

To me, HAMi is a great example of how open source can accelerate practical infrastructure innovation. Based on my experience contributing to the project and seeing its technical direction firsthand, I’m supportive of HAMi moving toward incubation.

Thanks @angellk!

[DSFans2014]

Over the past year, I have contributed extensively to HAMi, with more than one hundred PRs merged across multiple repositories. I started as a contributor and eventually became an Approver, a journey that gave me deep insight into both the codebase and the community.

Throughout this process, I have experienced firsthand the project's maturity and strong engineering practices. The codebase is clean and well-structured, the review process is rigorous and professional. The CI pipelines are reliable and effective at catching issues early in the development cycle.

As a heterogeneous computing middleware project, HAMi primarily addresses device virtualization and resource sharing challenges. It provides production-ready solutions with support for multiple GPU vendors, including NVIDIA, AMD, Cambricon and so on. Today, many users are running HAMi in production environments, where it has helped them significantly improve resource utilization and reduce infrastructure costs.

The HAMi community is now healthy and mature. Contributors from diverse organizations, geographies, and experience levels collaborate effectively. Newcomers are welcomed and mentored, the documentation is approachable and easy to get started with, and the community has established a healthy, sustainable pipeline for growing contributors.

Supportive of incubation

[saiyam1814]

I have been working in the AI infrastructure space and have been implementing and writing solutions, especially around GPU sharing.
HAMi is a great project. I used it for my homelab on DGX Spark, raised PRs, and also used it as part of my keynote at KubeCon India. I started contributing more to the project because I believe in its mission and vision.
This is a very good project for AI factories. Getting it into Incubation will add even more confidence.

[elezar]

Have we confirmed the affiliation of the maintainers? For example in the case of NVIDIA we see:

 The repo has one commit authored with an nvidia.com email:

  52060db129f4098e9885af63d8afe1898675c535
  Author: Anand J <anjayarajan@nvidia.com>
  Subject: Add local-deploy target in Makefile (#1760)
  Signed-off-by: Anand Jayarajan <anjayarajan@nvidia.com>

  It modifies Makefile:104, hack/deploy-helm.sh:59, and version.mk:13. git blame still attributes current lines in those files to that
  commit, so this is not just stale history.

  I checked all local refs for author/committer emails and commit trailers; this was the only @nvidia.com contributor email I found.

This does not align with the affiliations listed under the maintainers.

[archlitchi]

william-wang(https://github.com/william-wang) was in HUAWEI Cloud when he became maintainer, he was and still is Volcano maintainer, and helped a lot when this project in early stage especially community management, for example, community regulations, security experiences, OpenSSF best experience, governance, features on volcano-vgpu-device-plugin, arranging test devices(Ascend device) for HAMi community, etc..
He may not directly submit PR himself, but deeply involved, and participate in all community decisions(request on become approver, request on become new maintainer), etc.