Prepare advisory document on vendor neutrality

[TheFoxAtWork]

We allow for flexibility in the “how” of governance (TOC principle on self-governance) so long as specific outcomes are capable of being achieved.

Regardless of the kind of governing body (maintainers, committee, council, etc.) for a project, Could we articulate what those governing bodies are minimally accountable for with regard to the project beyond the technical direction? perhaps even recommend representation from Adopters that are also end users?

Of particular focus in my request, ensuring the public presence of the project (website, docs, blogs, tweets) is vendor neutral and (edit) if it contains references to commercial offerings or companies such references are structured to refer to companies leveraging the project within their offerings should other non-service providing adopters require support beyond what the project provides. We need to ensure the guidance on this particular item is appropriately balanced for adopters that need support and are aware of the projects but not necessarily supported solutions that could assist them, without the project endorsing any particular company or organization. It should align with the website guidelines. (end-edit)

There have been a few occasions as of late where project’s blog was written such that adopters where recommended to use a vendor (literally welcoming them to the vendor), or that the project's website was hosted by a vendor and failed to separate the components and capabilities of the open source project from the commercial offerings. In both of these examples, the public presence of the project is in conflict with the Definition of Cloud Native, most specifically with the function of the CNCF described within that definition (lines 16-18).

[jberkus]

Apologies for late response on this; it slipped by in the various requests we had.

This sounds like less of a problem of "who's accountable" and more of a problem of "we aren't emphasizing to projects that they need to be vendor-neutral". As in, this feels like more of a matter of project onboarding than of templates.

What I can imagine is an advice doc on "how to be vendor-neutral" for contribute.cncf.io. But this also requires action by staff/TOC/TAGs.

[TheFoxAtWork]

Is there a specific action you are seeking from the TOC in order to provide that supporting guide/doc for projects? I suspect it will link to several templates already available to support vendor neutrality throughout the project (the Steering Committee template comes to mind). Some areas that come to mind:

• Communications
• Project direction
• Decision resolution

[jberkus]

We'd want a specific doc on vendor neutrality. This doc would be included in incoming projects' onboarding. TAG-CS could definitely work with TOC members on drafting this, but it's not something that already exists. To date, the requirement for vendor neutrality has never really been spelled out in terms of what it means.

Once we had an approved policy & doc we could add it to the various templates.

[TheFoxAtWork]

Gotcha, something along the lines of: Actively promoting vendor-neutrality for projects 101.

Regarding defining vendor neutrality - It covers a few areas, and is definitely worth a discussion to firm up perspectives about what it means.

• What does communicating in a vendor-neutral manner mean? Fair representation, no single vendor is promoted in communication over others, objective information is provided
• How to drive project direction while ensuring vendor neutrality? Governance on project direction should allow opportunities for contributors and adopters (see definition here) to receive consensus on their features, PRs, etc. that would not promote one organization over another. For projects that work on plugins for various vendors, platforms, cloud providers, etc. providing clear information on how this is done, how they are objectively reviewed, and how the project brings balance to what areas it covers for different ecosystems/platforms/providers/etc.
• How does the project ensure no single vendor is the deciding authority? if the majority of the maintainers are from one organization, potentially introducing decisional schemas in the event that the initial decision's dissenting vote is from the non-majority org, to ensure fairness in decision making.

[jberkus]

Renamed issue based on what the deliverable is for TAG-CS.

[TheFoxAtWork]

Thanks Josh!

[mestadler]

I recognize the issue at hand, but I believe we're overlooking a key aspect: our projects do not currently offer a formal method to provide users the choice of support options should they seek assistance. It's crucial, from my perspective, to inform users about the potential support they could receive for each project. Naturally, users can begin with the open-source project, but they should have the opportunity to, for instance, hand off their developed solution to part of their organization that does require support. Of course, other users may never need support, but I think we should at least provide them with options.

Moreover, I worry that our declaration of vendor neutrality, without providing a platform for vendors to advertise their support and service options, might deter some vendors from incorporating their open-source projects into the CNCF.

Restricting value adds that some users will want, seems to be counter to the success of all the CNCF projects. We should accommodate for both and provide choice.

To be more clear, I am stating that the website guidance doc, in particular point 3 There should be no... and point 4 Links to companies offering... needs to be revised, needs a template, should be in each project page (if their is no vendor, then say so), and is not left ad hoc, as it is today.

[monadic]

wondering if this is still useful?

https://docs.google.com/document/d/11Hiz1dGYRS7GcjedpRVnSlDjIj0AVjeTa0-Td7aW-Lk/edit#heading=h.nhcqyz291adk

as a general point:

• maintainers are overworked and stressed, so adding stuff to their todo list can break sustainability
• often vendors and users want to help out but are not sure how --> it does not need to be coding

the CNCF talk of vendors should not assume that all vendors are equal size. hyperscale and big infra players can get involvd in all kinds of OSS but for most vendors, it is an existential bet. everyone has to thrive or OSS is doomed.

[xmulligan]

I noticed the help wanted label. Can I take a first stab at writing this up?

[geekygirldawn]

@xmulligan that would be great! Maybe we can work on this together, but if you wanted to do a first pass, that would be great.

[xmulligan]

Sorry just catching up after vacation. Would be happy to work together on this! I'll let you know once I have a first pass

[xmulligan]

I've created the first draft here. Please leave comments in the doc.

[xmulligan]

There have been no comments on the doc in the past two weeks so I think it is time to open a PR for it.

Where should the document go? Will this be under TAG Contributor Strategy or the TOC repo?

[TheFoxAtWork]

Apologies, I haven't had a chance to look. This is on my list for today.

[TheFoxAtWork]

Left a few comments. I think this should go to contribute.CNCF.io but an open to other thoughts, effectively where projects go to look for resources.

[xmulligan]

Ok, should I add it as a page here https://contribute.cncf.io/maintainers/community/?

[geekygirldawn]

Can we wait to merge this until @jberkus or I can review it? I’ll be back from holiday and can review on Wednesday or Thursday.

[xmulligan]

Sure no worries

[geekygirldawn]

@xmulligan Thanks so much for pulling all of this together! I made a few minor suggestions, but overall this looks really good!

[jberkus]

This feels ready for a PR. Great work, Bill.

[xmulligan]

Opened the PR