Define rationale for "maintainer multi-org" requirement

[jberkus]

TOC,

For graduation, projects are required:

Have committers from at least two organizations.

No rationale is given for this criterion. We need the TOC to define a goal for this requirement, which will allow us to figure out what to do in borderline cases.

Here are four possible rationales we've come up with in the Governance WG. We need the TOC to pick which one is the real rationale (or write one if it's none of these):

1. Continuity: we want assurance that maintenance on the project can continue even if one of the major involved companies pulls out of the project (so that the CNCF will not be in a position of hiring developers to maintain the project).

2. Openness: Because written governance and actual governance can be different, we want a tangible demonstration that the project is really open to all contributors, by having actual leaders that are not associated with the same company.

3. Member Benefit: CNCF is a trade association whose property is supposed to exist for the benefit of all members. Having maintainers from more than one member company shows that the project does not exist for the sole benefit of a single member company.

4. Utility: as a compliment to the end-user requirement, recruiting maintainers from a 2nd company is another thing that proves a project is generally useful and not just as part of one specific vendor's toolchain.

Of course, there are additional possible rationales. But we need the TOC to decide on a primary rationale, together with what other reasons they care about. That will let us write explicit guidelines to projects so that they can meet the criteria.

[mswilson]

No, I'm not suggesting that should be "allowed."

I am suggesting that no amount of "governance" is absolute protection if all parties are not committed to the open collaborative community approach (as featured at a top level of the CNCF TOC Principles. Resolving "blocked contribution" concerns is something that should be addressed in open, collaborative discussion in the public. That is what CNCF should require, in my personal opinion.

And what happens if there is evidence that not all parties that are stakeholders in a project accepted into incubation (or graduated) are, at a given moment of time, so committed? I do not think that a Steering Committee is how that's fixed. And I don't think that a point-in-time evaluation of "are there committers from multiple organizations?" provides sufficient evidence that guarantees "good behavior" in the future.

[monadic]

I think a Steering Committee is a good place to make these matters public. You need a higher authority than the repo level maintainers, and you want the TOC as an escalation threat. You can also bring in other users who may have an SC voice even without maintenance rights, and their opinions will help.

Try to see this from the POV of how a good product led ISV needs to work. But in the open.

[mswilson]

Constructing a Steering Committee can create power dynamics in the community that can work against the formation of peer trust relationships among collaborators (where collaborators should include developers, users, project managers, community managers, etc.). Yes, these power dynamics already exist in "commit bits" or other earned or appointed positions, but these grouping structures (especially as implemented in some places) can actually result in "stimulating centralization of opposition" (as described in the advice to "appear as many, not as one").

[monadic]

That objection may also be made against the TOC and SIGs. Yet we have those.

At a project level, eg Kubernetes, Prometheus or Nats, the dynamics you describe exist, and are easier to hide if there is no SC to push them into the public eye. That's not great.

[mattklein123]

My take on this conversation can be summarized as: idealized OSS vs. often politicized OSS when substantial money is on the line often via large vendors.

There is never going to be a "right" answer to how to handle ^ and I personally think that we need to: 1) Retain some level of subjective of assessment from the TOC as to what qualifies as "graduated" because having a firm rubric is going to be almost impossible. 2) Have some different tools in our toolbox that will guide projects and the TOC on how best to approach the clearly subjective rubric of graduation requirements around "diversity." I think that multi-org commit, SC, etc. are some tools in this toolbox.

[monadic]

+1, works for me

[mswilson]

That objection may also be made against the TOC and SIGs. Yet we have those.

Indeed, and I observe many downsides that are caused when these structures take on a sense of authority, power, and "oversight", rather than a sense of trusted guide, advisor, or coach. I do not observe as many of these downsides with SIGs, in practice.

At a project level, eg Kubernetes, Prometheus or Nats, the dynamics you describe exist, and are easier to hide if there is no SC to push them into the public eye. That's not great.

While there is a lot of study of positive and negative online community dynamics, including those in open source communities, I do not know of a lot of great examples of the "steering committee" idea, as proposed in draft, applied in practice. And there are new SCs that have been formed that are meaningfully different from what has been drafted. I am skeptical that a SC that meets in private can push the type of issues into the public eye that I think TOC has historically had concerns about when evaluating various project proposals.

[amye]

Closing for end of year clean (and also this discussion causes some process improvements), can be reopened if there's still relevant pieces.