Should we do this?

[jessesuen]

I believe I've already expressed some of my opinions in conversations and discussions regarding this topic, but just wanted to put forward some of my concerns out in the open, and where I currently stand with this program. What's still unclear to me is: what are our motivations/goals for a conformance program and how do we expect it to benefit the project? And is a conformance program the best avenue for achieving these goals or should we explore other means?

I understand Kubernetes/Prometheus are being used as examples where this process is being put in place. But unlike Kubernetes and Prometheus, Argo is much more than just an API specification and set of defined behaviors that can be caught in a test suite. I actually consider API compatibility as a pretty low bar to meet with respect to conformance. Would UI fall into conformance? Why or why not?

Second, we must absolutely address the issue of project forks, product variations, and contributions back to the core project (or rather the lack thereof). I am concerned about the inevitable "enterprise" forks of Argo, and the low incentive for contributions being given back to the core project. How do we incentivize vendors to contribute the features back to core instead of their own offering?

Lastly, I feel there is a big risk here with Argo brand dilution. It took us literally years to clear the confusion between the various Argo sub-projects, and train our community and users that Workflows and CD were actually two completely separate things. To this day, I still talk with customers about this confusion and need to repeat this message again and again. I predict the situation to become worse, once we start allowing things like: Acme Argo CD XXX, Bacme Argo Pipelines, etc...

Just wanted to put down where I stand on this, as it seems we are rushing the process and this is a decision that we need to tread very carefully on.

[todaywasawesome]

Thanks @jessesuen I agree with you on your points about treading carefully and not rushing this. We'll want to make sure we do this in a way we all feel good about and benefits the community and Argo project.

Argo has a very open license and today anyone can take Argo, package it, fork it, sell it etc. They can say it's built on Argo and they aren't required to have any relationship with the project. We can't do anything to stop anyone from doing that. The one thing we do control with the CNCF is how the Argo brand can be used. While anyone can say they're selling a product for Argo, or built on Argo, they can't sell a product with the Argo name in it without approval and conformance. This means we can set the parameters that need to be met which means we can go beyond just API compatibility, we can ensure the UX is kept intact, and even that vendors have some level of return contribution in the project.

In short, conformance helps us keep consistency and protect the Argo brand. As we build the program we have a high bar to meet and we won't take any shortcuts.

[todaywasawesome]

@jessesuen I think this is resolved by #3 are you ok if we close this issue?

[jessesuen]

In the interest of moving forward, I promised in last Thursday's (Oct 21) conformance meeting to summarize my updated position here, also since not all stakeholders were in the meeting:

1. Unlike any other CNCF project, "Argo" is unique because Argo does not refer to an installable/runnable product. It is a collection of products. As such, there's no such thing as "conformance" testing of Argo since it cannot be tested. This makes Argo conformance different than, say, Kubernetes or Prometheus conformance, which is versioned, installed, testable product.

On the other hand, conformance testing can be done against any of the four main subprojects under the Argo umbrella. Specifically:

• Argo CD
• Argo Workflows
• Argo Rollouts
• Argo Events

2. Regarding the naming of vendor offerings using the name Argo, I don't believe that any vendor should be allowed to name their product as "Argo ______." The word following "Argo _____" should be a decision reserved for the project and not any vendor. Passing conformance on one or more subprojects is not a blank check to then be allowed to then name their vendor offering as Argo XXXX. Here is a theoretical example:

Vendor Acme wishes to offer Argo Workflows as their vendor offering. Their version of workflows passes conformance. It would be unacceptable for the vendor to name their product:

• Acme Argo Pipelines

What would be acceptable to me is:

• Acme Argo Workflows
• Acme Argo Workflows Enterprise (perhaps subject to approval)

(note the inclusion of Workflows in the above acceptable names)

On the same note, I think we are currently too liberal with the use of Argo even in argoproj-labs ecosystem projects, and I would like for us to tone down that practice unless they are specifically related to an existing subproject (e.g. argo cd notifications, argo cd image updater).

3. In the interest of moving forward, I am agreeing to the existence of this program with the caveat on what I feel should be the end state after the program is in place.

	Today	After Conformance
Acme Cloud for Argo	✅ allowed	✅ allowed
Acme Platform for Argo	✅ allowed	✅ allowed
Acme Argo Cloud	❌ not allowed	❌ not allowed
Acme Argo Platform	❌ not allowed	❌ not allowed
Acme Argo CD	❌ not allowed	✅ allowed
Acme Argo CD Enterprise	❌ not allowed	✅ approved by project maintainers
Acme Argo CD Sucks	❌ not allowed	❌ rejected by project maintainers

In short, I approve of the conformance of individual subprojects and allow the incorporation of subproject names (e.g., Argo CD) into vendor offerings, but not the umbrella project (i.e. Argo XXX). This is me speaking with my project maintainer hat on and not my vendor hat. I would have this same viewpoint even if I were not a vendor, but I care much more about this subject because I am.

[todaywasawesome]

We agree on most of the points here. I think we are at a point where we are good on the goals. I will open a separate issue for if Argo should be considered a whole where we can collect discussion (and will reference this discussion). But as for the question of "should we do conformance," we agree we should do it for Argo Workflows, Events, CD, and Rollouts.

Closing the issue.