Add Meshery incubation due diligence

[angellk]

This adds the incubation due diligence document for Meshery, sponsored by Karena Angell (TOC Chair), at projects/meshery/meshery-incubation-dd.md.

Incubation application: #1386

Meshery has been a CNCF Sandbox project since June 2021 and applied for Incubation in March 2024. The due diligence consolidates the criteria-by-criteria evaluation, the merged governance review (Satisfactory), the security self-assessment review (#2264), and three independent adopter interviews. All incubation blocking items are resolved; the remaining recommendations are non-blocking, with several set on the graduation track.

Opening this PR begins the two-week public comment period on the due diligence. Community and TOC feedback is welcome here during that window. After the comment period closes, the due diligence proceeds to a TOC vote.

[craigbox]

I object to the promotion of the Meshery project to Incubation at this point.

While substantial work has clearly taken place in this area, I do not believe that Meshery currently meets the CNCF vendor neutrality standard. Specifically, I do not believe it yet demonstrates sufficient independence from Layer5, its primary sponsor/contributor.

I want to be upfront about why I'm raising this and why it matters, since an objection at this stage could be read as adversarial toward maintainers who have clearly put in substantial effort. To be clear: my concern isn't with Meshery's technical merits or the good faith of its contributors. There is genuine, substantive work reflected in this application. My concern is narrower and more procedural: does this specific project meet the vendor neutrality standard the community and TOC apply to every project?

Incubation status is a signal adopters use specifically to de-risk single-vendor dependency, and it's a bar that other projects have done real, sometimes costly work to clear honestly. If a project can retain vendor branding and hosting infrastructure and still clear that bar, the message to every project doing the harder work of genuine separation is that it was optional. That outcome, rather than any judgment about the code or community governance of Meshery specifically, concerns me, and it's why I raised the issue privately as early as October 2023, rather than waiting for this vote to make it public.

On vendor neutrality

A vendor-neutral project is one that does not favour one vendor over another. Critically, "another" here should not be read as requiring an existing competitor. A project can equally fail vendor neutrality by structurally foreclosing the emergence of one, which is the more relevant test for a project with a single historical contributor. Incubation is often the signal for other vendors to adopt, support or distribute a project.

This principle is anchored in the CNCF Charter:

"We avoid influence, biased behavior, “pay-to-play” decision-making, and other activities that favor one project, individual, or organization over another."

It is also codified in more concrete, project-specific form in CNCF's Vendor Neutrality Guidelines and Website Guidelines, both cited below.

My yardstick for this metric is: Does the project grant a systematic advantage to one particular vendor, and, acknowledging that nearly every project is contributed by a single company, does it maintain a level playing field for other companies to integrate, host, or sell services based on the project?

I have two concrete concerns where the project currently fails this test.

1. Trade dress and brand entanglement with Layer5

Comparing meshery.io/brand with layer5.io/company/brand, three entities — a commercial vendor, a CNCF project, and "an enterprise-grade distribution" of that project — retain virtually identical trade dress: the same colour palette, the same typography, and matching visual aesthetics throughout.

_{Layer5, Meshery, and Kanvas marks share typeface, colour palette, and geometry. The Kanvas mark is built from the same triangle tessellation used in the Meshery globe.}

This creates an implied connection that no other vendor can reasonably replicate. A prospective competitor cannot adopt "the Meshery look" for their own commercial distribution without appearing to be affiliated with Layer5, while Layer5 itself faces no such barrier — a structural advantage the vendor-neutrality standard is meant to prevent.

Meshery is a Linux Foundation-held mark, and the Trademark Usage Policy states that "a trademark should not be incorporated into your company's logos or designs." The Kanvas mark appears to do exactly this — Layer5's own brand kit includes a 15-second video showing the Meshery logo morphing directly into the Kanvas logo.

The CNCF Website Guidelines state that beyond a brief factual note on project origin, "the origin company should not otherwise be referred to on the project homepage." Shared trade dress functions as a persistent reference to the origin company on every page of the site — it doesn't need to name Layer5 in text to constantly signal it.

These trade dress concerns were specified in the incubation thread, but were raised privately as far back as October 2023.

2. The Meshery Playground and the Kanvas project

Meshery properties promote Kanvas (formerly MeshMap) via a hosted "Playground" at cloud.meshery.io. Kanvas appears to be a proprietary Layer5 commercial offering, though because it shares identical trade dress with both Meshery and Layer5, end users cannot easily distinguish whether it is part of the CNCF project or not.

Signing up for the Meshery Playground triggers an email from no-reply@layer5.io, asking the user to click a confirmation link at cloud.layer5.io to continue. This suggests that playground.meshery.io / cloud.meshery.io are aliases fronting a Layer5-hosted application — not CNCF or neutrally-hosted project infrastructure.

This is a direct instance of what CNCF's Vendor Neutrality guidelines caution against under "Hosting": where a project sponsor must self-host a resource, they should "separate resources affiliated with the CNCF project from resources attached to their products." Whether or not Layer5 uses these accounts for commercial outreach, a user signing up on a CNCF project domain is effectively required to grant identity and auth authority to Layer5 — a blurring of boundaries that the shared trade dress makes almost impossible for an end user to notice.

Kanvas separation concerns were raised with the project here and marked as addressed, ostensibly by fronting cloud.layer5.io with Meshery-brand aliases. However, the shared trade dress and logo derivation shown above suggest this was a rebrand rather than a substantive separation — the hosting, authentication, and visual identity remain tied to Layer5.

What would resolve my concerns

To ensure a neutral foundation before Incubation status is granted, I recommend the TOC ask:

(a) Brand and visual independence: The Meshery project adopts a logo, typeface, colour palette, and general web presence that is visually distinct from Layer5 and any of its other products.

(b) Playground separation: Either cloud.meshery.io is removed, replaced with genuinely neutral hosting, or clearly and prominently labeled as a Layer5 vendor playground. If the latter, it should sit on a page structured so other vendors have equal opportunity to list their own equivalent offerings, consistent with the alphabetical, all-vendors-listed approach the Website Guidelines already require for commercial/enterprise pages.

Why this matters

Promoting projects to Incubation while fundamental brand and infrastructure boundaries remain blurred creates a challenging precedent for CNCF governance. Short of flagging trademark usage violations, it is not in CNCF's gift to directly police how Layer5 markets its relationship with Meshery on Layer5's own properties — but the neutrality of the project itself should be sacrosanct. Resolving these points before granting the badge of approval would help Meshery mature on a genuinely level playing field. It would also be fairer to other community contributors, whether that be another vendor trying to compete fairly around supporting the project or another CNCF project that held itself to a higher standard.

Separately, this case perhaps signifies a gap in CNCF processes: trade dress, brand entanglement, and hosting/vendor-lock-in questions are legal and business concerns that sit somewhat outside the TOC's usual technical remit. It is a broader problem than any single application, and worth attention independent of how this particular objection is resolved.

[angellk]

Thank you for your feedback @craigbox - your repeated objections to project Meshery over the years has been noted and considered.

As the TOC member conducting the Due Diligence of this project, the project has been consistently responsive to any requests made of the project to ensure they are ready to move to the next maturity level within the CNCF.

The project will continue to mature on its path to Graduation.

[craigbox]

Thanks for the reply, @angellk. Instead of "repeated objections" I might have said "request to uphold the Linux Foundation Trademark Policy and the CNCF Website Guidelines."

As the person who performed the due diligence (and/or as the chair of the TOC), could you help me understand if the TOC considers the trade dress and hosting entanglement (a) acceptable, (b) acceptable for Incubation but expected to be resolved before Graduation, (c) not something due diligence is scoped to evaluate, or (d) something left for individual TOC members to weigh in their vote?

[angellk]

Thank you for your concern @craigbox

These are non-blocking for Incubation and will be re-evaluated when the project is ready to apply for Graduation. The CNCF continually reviews projects for any trademark concerns. Also, the project has already been advised on recommendations for rebranding the project since it has moved away from being a project focused on Service Mesh. As the project continues to discuss rebranding, the logos, fonts and coloring may change. That will be up to the project as they work with the CNCF on any new artwork.

The playground is not a blocking concern for Incubation and the project addressed the governance concerns raised during governance review. The entire project would be reassessed when the project is ready to apply for Graduation.

[brandtkeller]

lgtm - minor comments but none that would block.

[brandtkeller]

Not blocking: All documentation has been met for each of these. Although I don't personally see an Emeritus maintainers listed in the MAINTAINERS.md as the #emeritus-maintainers section documents.

[brandtkeller]

#1264 is the original incubation proposal issue - cncf/sandbox#241 is the sandbox acceptance issue I believe. I am a bit unclear on the specific date.

[brandtkeller]

I don't believe Consul is a CNCF project

Suggested change

	| **Consul** (service mesh adapter) | yes | [meshery-consul adapter](https://github.com/meshery-extensions/meshery-consul) |
	| **Consul** (service mesh adapter) | no | [meshery-consul adapter](https://github.com/meshery-extensions/meshery-consul) |