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.

[jberkus]

In discussion with the TOC this morning, it seems that the primary reason for the requirement is (2), that is we want to make sure the project is open to contributions regardless of employer.

[thisisnotapril]

Are there any current projects that aren't open this way?

[jberkus]

To clarify: we want to make sure that projects are open to contributions regardless of any company's individual product strategy. That is, is should be possible for a contributor to push a change that doesn't help, or even hampers, the internal product strategy of any individual sponsoring company.

The primary way to demonstrate this is to have project leaders with code/docs merge rights, and/or the ability to grant merge rights, who do not all work for the same company.

[lizrice]

That is, is should be possible for a contributor to push a change that doesn't help, or even hampers, the internal product strategy of any individual sponsoring company.

To be very clear, this isn't about contributors being able to push any change they like; it's about ensuring that the strategy for the project is independent of the strategy of any individual company. A project is entitled reject changes if the project leadership don't believe it's in the interests of the project.

[lizrice]

I do think we should also document item 1 from your list as a second factor. It's a logical follow-on from "independent project strategy" but worth stating that having project leaders from more than one organization de-risks the possibility of a project being shut down (for example, if there is one company running the project and it gets acquired, and the acquiring company no longer wishes to sponsor the project)

[monadic]

I think maintainer diversity is a positive but it should NOT be used to gate start-ups from having a successful route to building a business. I see this thread heading in that direction.

[kfox1111]

@monadic I think that's not quite a fair comparison....

There are two sides that a potential start-up could be on.

1. The startup producing a technology they want to provide under the cncf.
2. The startup producing something, that relies on a technology that is part of the cncf.

If the latter bets their business on a graduated project, and the single startup behind the technology is bought by another company that isn't terribly interested in its continued development, the second startup could suffer greatly. Potentially even a business ending situation.

So this is why folks are concerned with the situation. Its not an anti start-up thing. Its trying to balance the concerns and attempt to make it as good as possible for as many folks as possible. Start-ups included.

[lizrice]

Section 1 of the CNCF charter talks about "sustaining an ecosystem of open source, vendor-neutral projects" and maintainer diversity is a measure of vendor neutrality, no?

[monadic]

@lizrice technologies like the hashicorp tools (not cncf) and Prometheus (at cncf) have diverse maintainers but are not really vendor neutral. Prometheus is heavily influenced by RH and Grafana Labs for example. I think the key question is how to encourage vendors to act as good stewards of their own projects.

[monadic]

@kfox1111 I did not say it was an anti startup thing. I implied it would make it harder for startups to build a business and put them off investing projects in cncf. That would remove one of the most important sources of valuable projects and sustained innovation in the industry. Cncf needs to work with the grain of economic interests from small vendors, or only deal with large vendors.

If you are worried about projects losing maintainers then make it easy for them to add them, through strong incentives.. And provide a backstop for edge cases eg acquisition, liquidation, and other failures

[kfox1111]

@monadic That's a very interesting idea. If there was a mechanism in place for the CNCF to provide funding for dealing with the edge cases of acquisition, liquidation, and other similar failures of Graduated projects, then perhaps the needs around maintainer diversity could be reasonably lowered.... That would still protect start-ups of the second type while allowing more contributions from start-ups of the first type.

I have no idea what changes it would take organizationally within the CNCF to support that kind of thing though. It may be easy or may be incredibly difficult. Who would we even ask if that's possible within the org? Is that a TOC thing?

We may be off a bit on a tangent though. The primary concern the TOC seems to have raised is:

In discussion with the TOC this morning, it seems that the primary reason for the requirement is > > (2), that is we want to make sure the project is open to contributions regardless of employer.

I think that means the overarching question is how can that concern be addressed when only one company is involved? Maybe there are other options then maintainer diversity.

[monadic]

@kfox1111 the TOC can act as an ombudsman to audit project behaviour and hear complaints. If it is doing that, complaints will be infrequent and well justified

[kfox1111]

The TOC could, but they would have to commit to that. When I was contributing to the OpenStack community, the same issue came up and the TOC explicitly decided that activity was out of scope for them. They had no other mechanism to deal with it. Is that something the CNCF TOC would be willing to commit to?

[monadic]

It's better than the alternatives IMO

[jberkus]

technologies like the hashicorp tools (not cncf) and Prometheus (at cncf) have diverse maintainers but are not really vendor neutral. Prometheus is heavily influenced by RH and Grafana Labs for example.

There is a HUGE difference between "heavily influenced" and "controlled". Any company that employs maintainers and contributors is going to have influence. That's part of the reason you employ them, after all.

Here's an example of the distinction:

Influence: (current reality) Prometheus is highly compatible with Openshift, because a bunch of Red Hat people work on it.

Control: (hypothetically) Prometheus only works with Openshift, because all of the maintainers work for Red Hat and block any PRs that would support GKE or K3S.

The second is what we don't want, and what we've seen all over the ecosystem with a lot of the startups in the database realm outside the CNCF. And, speaking from 22 years of experience doing open source, no amount of written rules or ombudsmanship is going to be a substitute for making sure that your decision-making body is diverse. For that matter, the existence of leadership working for multiple companies is itself a litmus test for what kind of changes are allowed in a project -- it's easy to say "we accept everyone" while actually doing something completely different behind the scenes.

Last I checked, for that matter, Hashi projects accept contributions from all over the internet, but project leadership is 100% Hashi employees. I only deal with Nomad and Teraform, though, so things may be different on their other projects. So this isn't the equivalent of Prometheus at all. You yourself could become a Prometheus maintainer if you wanted to, and then you'd have as much influence as anyone else.

[jberkus]

@kfox1111

The TOC, historically, has only just kept up with its workload for reviewing projects (it's a big workload). What you're talking about would be an order of magnitude more work for them.

[monadic]

@jberkus thanks for your excellent comments.

We should learn from the past. We should also adapt and innovate -- we do not need to be bound by the past.

I don't think the TOC having an ombudsman role should be dismissed. I spent a lot of time discussing this with early TOC members like @jonboulle and we thought it was potentially extremely valuable. Adding value to projects is more important than selecting them.

And, regardless of the maintainer diversity topic, the CNCF should make an effort to help projects + community do good and healthy things and help them avoid anti-patterns.

So I do not agree that it is obvious that maintainer diversity is so great. In several projects I have been involved with closely (rabbitmq, spring and, less so, redis) we did not have maintainer diversity in the sense set out here and it was GREAT.

Moreover I do not think small ISVs should be at risk of pressure from large ISVs who want to "just have a maintainer on the project". This is usually followed by the large ISV starting up a competing commercial offering.

Do not turn CNCF into a losing play for small ISVs.

[lizrice]

I'd say there is a whole separate debate to be had (broader than the TOC) about whether the CNCF can do more to support ISVs in the community.

As to the ombudsman role... we should have a process for people to raise complaints when they think maintainers have (for example) blocked change for what appear to be strategic reasons aligned with company rather than project. We'd need to figure out how to balance this so that it's not a crazy amount of work for anyone, but that bad behaviour doesn't get tolerated simply due to lack of process for dealing with it. The TOC is supposed to be "light touch" with individual projects ideally resolving their own issues, but I think we could serve as arbitration of a last resort.

Coming back to the original purpose of this issue, the maintainer diversity requirement is already there today and this issue is about documenting the rationale behind it, as understood by today's TOC (which should be useful for the TOC of tomorrow who will have to make judgements in future). @jberkus are you thinking that rationale could be added directly to the graduation criteria?

[monadic]

@lizrice

I'd say there is a whole separate debate to be had (broader than the TOC) about whether the CNCF can do more to support ISVs in the community.

Respectfully.

There is absolutely a debate to be had since the CNCF can do more. Using its budget (GB) and non-budget resources (TOC & EUC & Community).

That debate is not and cannot be 'separate' when maintainer diversity is unclear and possibly becoming a major constraint on ISVs participating in CNCF. I do not think all current ISV-led projects are happy about this. I think many are not. And I think many ISVs on the sidelines are not happy either. Please let's not bury this, but bring it into the light.

"Vendor neutral" should not automatically mean "Multi-Vendor". That's just model but often not the best for a specific project. All the best projects I have been involved with in eg 2006-2014 have been ISV led with participation from end users and partners but not competitors. Note that I am not saying multi-vendor is bad. It is mostly good for k8s for example. But it is not the only way.

Have a look at the ASF website and then at the Kafka community. 1) ASF is all about "vendor neutral", their website makes this clear 2) Kafka is almost all Confluent plus a handful of people. IIRC no other company has >1 maintainer, except LinkedIn.

As to the ombudsman role... we should have a process for people to raise complaints when they think maintainers have (for example) blocked change for what appear to be strategic reasons aligned with company rather than project. We'd need to figure out how to balance this so that it's not a crazy amount of work for anyone, but that bad behaviour doesn't get tolerated simply due to lack of process for dealing with it. The TOC is supposed to be "light touch" with individual projects ideally resolving their own issues, but I think we could serve as arbitration of a last resort.

I think this is the right direction.

• TOC is last resort plus hard consequences of going this far
• Managed by CNCF Exec Staff, and maybe a WG
• Projects could have Steering Committee with End Users represented strongly (this could also provide a contingency plan against project de-funding)
• Model is applicable to multi-vendor too: eg k8s and prometheus, both of which have had issues with blocking changes

To be clear, this would mean foundation software rules out "blocking improvements that make the project better", which could be proposed by end users or by contributors creating bigger offerings on top of the OSS (eg a SaaS).

CNCF stands in favour "end users want their projects to be open and have the features they want". We are against the open core model where the OSS is deliberately missing stuff that the community obviously wants. In CNCF the ISVs must align with the community and not compete with it.

This also helps End User led software projects. There MUST be an incentive for small ISVs to get involved otherwise consumers cannot get support until a big ISV bundles it with their product (which is inevitably a larger and more expensive 'package' of some kind).

Coming back to the original purpose of this issue, the maintainer diversity requirement is already there today and this issue is about documenting the rationale behind it, as understood by today's TOC (which should be useful for the TOC of tomorrow who will have to make judgements in future). @jberkus are you thinking that rationale could be added directly to the graduation criteria?

Confession - this may be my fault. We wanted Graduation to include clear project governance. We saw governance as creating a clear model for contributors and end users. We saw 'being open to external contributions' as a way to prove that governance was working. That is why the maintainer diversity requirement is there. It is not there because of the CNCF charter. It is not there for ideological reasons be they good or bad.

And I note again that ASF is 'vendor neutral' not 'multi vendor'. There is a whole other conversation about why End Users may benefit from multi vendor software. Mainly this is about creating a marketplace for support, and no "lock in". I think this is a valid commercial question but NOT IN ANY WAY a requirement for a well governed OSS project. As evidenced by all the "mostly single vendor led OSS projects" eg Spring, Redis, that have fully-functional OSS, and find complementary commercial models that don't compete with their communities.

[monadic]

@lizrice please can I raise a separate point relating to this thread. I suggest changing the phrase 'maintainer diversity' to another one. Two reasons for this: (1) diversity is a word we use when we talk about fair treatment of under-represented minorities not only in tech but in society; (2) it is ambiguous as shown by the graduation requirement being discussed at such length.

[wmorgan]

I can only offer my perspective as a small ISV (Buoyant) who is the creator and primary sponsor of a CNCF project (Linkerd). Despite huge amounts of prod adoption, a continuous stream of third-party contributions, active participation in GSoC and CommunityBridge, a public commitment to open governance, a formalized RFC process, and a very healthy and engaged community--despite all that, it's been difficult to add non-Buoyant maintainers to Linkerd. We finally added one earlier this year, for a specific part of the codebase, but that was after a lot of luck.

I believe one reason is simply the nature of the project. Linkerd not a framework; requires no integration with specific cloud providers, APM vendors, etc; has no module/plugin system (though this is starting to change)--so many of the context-limited ways of code ownership available in other projects are simply not there in Linkerd. I think the TOC would do well to recognize that the ease of adding maintainers can vary significantly by the nature of the project.

More critically, the goal of increasing corporate diversity of maintainers has frequently been counter to the goals of making Linkerd better. On multiple occasions Buoyant has hired contributors from the Linkerd community because we wanted them to continue their Linkerd efforts full-time. We did this knowing full well that it would reduce corporate diversity of maintainers but we felt it was what was best for the project.

So this requirement has been frustrating, and describing these intricacies has been part of my counsel when I advise other projects considering the CNCF. And regardless of what happens from this discussion, Linkerd will and must continue to prioritize what's best for the project, even if it hinders our ability to move this metric.

[chira001]

This is an important enough discussion that is probably beyond the scope of the original question and should merit it's own issue and perhaps an agenda item in a TOC meeting.

I agree with @monadic - there is nothing wrong or less good with a project having a primary focus on a single ISV - sometimes that is the only way to get a critical mass on the innovators for a project to get together (with some sort of commercial imperative), and trying to force multiple vendors does not actually help the project OR the community.

Sometimes we deploy process or rules to achieve a desired objective - but now that we know more, we can consider evolving the criteria for the benefit of the projects and the community.

[jberkus]

@lizrice see document

My desire for this is to:

1. Reword the current requirement so that it is more clear
2. Add a separate, backing document explaining the rationale, relevant metrics, and guidance on fulfilling the requirement.

Eventually I envision doing this for all requirements.

[monadic]

" The primary reason for this requirement is to ensure that all quality contributions are welcome in the project, regardless of the employer of the contributor. Diversity in contribution of all sorts is extremely valuable, and single-organization projects limit use cases and potential contributors. By requiring leadership from more than one organization, we ensure that no entity is able to confuse its project vision with its commercial product strategy."

This is not the reason for the statement being used for graduation, as I have explained. And the statement about single org projects is highly subjective and contentious. Please do not put such value judgements out there if you want cncf to be taken seriously as supporting innovation and great projects.

[jberkus]

@monadic both Kafka and Redis are great examples of problematic projects, though. In both cases, the single-vendor nature of the projects has caused trouble and pain for their communities, particularly in the area of closing the source for formerly open-source features. I think those are both great examples of what the CNCF should NOT want.

What you seem to be asking is "Should the CNCF take steps to specifically accomodate open core business models" and my personal opinion is "no".

There's also the question of point (1), namely "if the vendor quits the CNCF, then what happens to the project?". Things happen to individual companies. Changes in strategy, acquisitions, bankruptcies, etc. Explicitly allowing/encouraging single-vendor projects means that the CNCF will be dealing with "orphan" projects not as an exceptional event, but as a regular occurance.

[jberkus]

@wmorgan Yes, and the End-User requirement has been challenging for many projects as well.

The reason I've been trying to get the TOC to endorse a rationale for the requirement -- as well as backing metrics and information -- is that it creates a basis for evaluating borderline cases. If the main reason for the requirement is diversity of contribution, then the project having trouble with maintainer recruitment might get a principled exception. For example, a project whose current maintainers all work for the same company, but has a large flow of accepted contributions from diverse contributors, and a clear path for those contributors to become maintainers, could ask have a discussion with the SIG.

[monadic]

@jberkus please reread what I said because I am also advocating against open core. I am not in favour of foundation oss projects turning down features to put them into a closed source version. Such projects put the vendor in competition with their own community. For cncf we want the Best projects and one issue is that features should not be withheld. That means vendors need alternative commercial strategies (of which there are several).

Redis was not problematic when I was involved at vmw/PVTL. Maybe that changed at garantia data / redis labs. But it has always been best in class. And if it isn't, there will be competitors.

I mentioned kafka because Liz said cncf is vendor neutral. Asf is also vendor neutral. According to the logic of what Liz said, kafka, and projects like it, should be at home in cncf.

Then I suggested that the maintainer diversity rationale wasn't due to vendor neutrality but due to establishing governance. I know this is true because I proposed the requirement with Chris and Dan ages ago.

[jberkus]

Alex: It changed radically with Redis Labs. Read up on that; it's a good cautionary tale, expecially for this discussion. That is, how can we be more flexible with this requirement without enabling a Redis Labs?

[parispittman]

+1 to using another word outside of diversity in this context.

something like: maintainer/contributor affiliation?

[parispittman]

Do the projects that don't meet the current requirements have a community manager and/or a community/contributor growth intentional space (special interest group, working group, etc.)? People focusing on the people really helps with this growth initiative. ("people focusing on people" is a hippie hacker quote :) )

[monadic]

@parispittman people people!

CNCF should fund fractional community managers for projects. This has been a long standing ask from TOC to GB along with budget transparency & more.

[monadic]

@jberkus ugh, that's too bad about Redis.

Anyway, it is my opinion that:

• as shown by ASF, these maintainer level requirements can be gamed even in vendor neutral foundations
• and they are often unfair to good faith projects like nats and linkerd (to name two)

A much much better way to make users happy and prevent "broken open source, functional paid source" is to have proper oversight.

• Projects could have Steering Committee with End Users represented strongly (this could also provide a contingency plan against project de-funding)
• Model is applicable to multi-vendor too: eg k8s and prometheus, both of which have had issues with blocking changes
• CNCF Ombudsman function with real teeth

[mattklein123]

(I'm sure I will regret typing this, but away we go. Also, I'm speaking for myself, and not the entire TOC.)

My 2c on this topic is that ISVs that control an OSS project that do not ultimately desire to have contributors, steering committee members, etc. from multiple organizations are joining the CNCF purely for marketing and commercial reasons, because let's be honest, joining the CNCF increases the likelihood of venture success, for better or worse.

If an ISV wants a neutral trademark holding ground, there are many vehicles that can do that outside of the CNCF.

My personal opinion is that the CNCF has done a good job of valuing community and project sustainability as part of its graduation criteria, and I am not personally in favor of relaxing that. If there are ISV controlled projects that are not willing or able to reach a state of healthy contribution and steering from multiple orgs, I don't think they deserve to elevate beyond the incubating level. If they are frustrated by this we should look into potential alternative holding foundations entities outside of the CNCF that serve the same purpose, but come without the marketing benefits and the implicit graduation requirements.

[jberkus]

I am unaware of any issues in either Kubernetes or Prometheus with changes being blocked for any reasons other than technical or shortage of reviewers. Links?

[monadic]

@jberkus I can try to dig out some links if you need, but let me respond slightly more generally.

Prometheus has two examples one 'good', one 'bad'. The 'good' one is that for many years some people wanted to add different storage modes & models but this was rejected again and again as 'not in line with the design philosophy of simplicity', but the gatekeepers of the project. That's now changed, yay. The 'bad' is to do with one maintainer getting overwhelmed and (often) shutting down conversations. This led to some negative feedback and intervention. FWIW, I saw this happen at Cloud Foundry too (i.e. not just at CNCF). Now if you put the good & bad together, we had a situation where contributions were being rejected and potential maintainers being pushed away. Worse, early maintainers were leaving. A potential disaster -- much of the credit for helping out must go to Chris/CNCF. Takeaway: ALL of this happened and can happen again no matter what the rules are for number of maintainers and who employs them. BECAUSE the problem was not the maintainer mix! It would have been solved by a different oversight model especially if more end users were involved.

Kubernetes disputes have arisen when two or more cloud providers have had conflicts over supporting valuable features in the OSS. An example is auto-scaling which has to be implemented in different ways based on what the underlying cloud does. Sometimes the "right design for kubernetes" turned out to be the same as "the right design for one service provider".

I'll also mention Spring and RabbitMQ. The maintainers would frequently rewrite contributions. This definitely led to better code and a better project / product. But the contributing users were happy because the feature was added even if not always using code they had originally proposed.

Another (sad) example: projects that died at ASF because of the insistence on broadening the mix. Eg. cloudstack.

In summary

• The problem we want to solve is rejection of features users need
• Varying maintainer mix does not solve the problem, and can make things worse
• Examples vary along a wide spectrum from harmful to beneficial
• Having users in an SC plus an Ombudsman would be a better solution

[monadic]

@mattklein123 thanks.

I am proposing that CNCF help users as its main goal, and it does this by helping projects. And I do think we need Steering Committees for this (see below).

CNCF exists in an economy of big and small ISVs, as well as end users. Each must play their part.

• Big ISVs

Big ISVs are great for all sorts of reasons! I am not against them. CNCF can't make life harder for small ISVs and leave the economics in the hands of big ISVs alone. A world of only big ISVs is not sustainable. IMHO: past foundations dominated by big vendors have often stagnated. Also, we used to get to pick between IBM & RHAT, then they merged!

• End Users

End Users play a bigger role at CNCF than in prior cases (IMO) and this is great. We live in a world where end users make more OSS projects. That is also great. But then we sometimes need ISVs to spring up and support those projects. End users may not want to be "in the support business". I do not think big ISVs can rescue this situation on their own, because they will tend to support small OSS projects as part of their bigger offerings, which is not always what the users want.

• Small ISVs

I think CNCF should help ISV led projects succeed all the way from start up to graduation. I think users will WIN here if the best projects live at CNCF, not the second best projects. We want innovation and quality -- this comes from well motivated companies that form around projects, or are spun out of end users, or from many other places. WE NEED THEM.

• Open Core is bad

IMO -- CNCF should take a strong stand against open core, specifically meaning the model in which the open source is missing features that are "held back". To get the useful features you must buy the closed product. Users lose when the OSS doesn't work unless you are forced to pay for the thing that works. A better commercial model is for vendors to sell complementary services: SW products with complementary features, or SaaS products, or HW appliances, or bigger SW bundles, or support, training and pro-services.

• The problem

I have argued in this thread that forcing more maintainers into projects can be actively harmful and does NOT solve the tendency to hold back features.

• What should we do?

Graduating CNCF projects that have a concentration of maintainers in 1-2 companies (ISV or end user firm) should have a steering committee.

(I am not the first to suggest this.)

Key goals of a project SC could be --

• Represent user interest and other partners, without requiring hands-on maintainership
• Maintain a good roadmap, community, etc, and don't "unfairly" block features that users want, provided that they can feasibly be added without breaking the project or the people
• Work with TOC as ombudsman
• Schedule governance & project reporting
• Develop the 'escape hatch' against project failure scenario

[mattklein123]

I have no conceptual objection to a steering committee approach to satisfying this requirement, but the details of the implementation matter. This is the solution that has been proposed for NATS (and likely gRPC) so we can see how this evolves.

[monadic]

@mattklein123 agreed, the SC concept has to have teeth and be well formed.

[jberkus]

@monadic that is not an example of Prometheus denying a PR for company reasons.

You continue to back up your arguments by making unsupported allegations, calling substantially different things the same, and defining projects in black and white, often based on outdated information. It makes it hard to believe in your goodwill, or take your ideas seriously. Might I suggest focusing on your ideas for how to improve contributor diversity in a positive way, instead of making overgeneralizations about projects?

[monadic]

@jberkus my point was that features get pushed back for all sorts of reasons and in some cases, a hostile atmosphere is created. This isn't correlated to whether a company is involved, and it isn't prevented by insisting on maintainers belonging to a plurality of companies or allegiances.

[monadic]

"You continue to back up your arguments by making unsupported allegations, calling substantially different things the same, and defining projects in black and white, often based on outdated information. It makes it hard to believe in your goodwill, or take your ideas seriously. Might I suggest focusing on your ideas for how to improve contributor diversity in a positive way, instead of making overgeneralizations about projects?"

Please address my arguments instead of making (incorrect) generalisations and attacking me personally.

Please stop suggesting i am acting in bad faith without specific evidence.

[monadic]

For those following at home, I should explain that Github emailed me this comment from @jberkus "@monadic that is not an example of Prometheus denying a PR for company reasons. I'll thank you to not cast aspersions that aren't warranted.", which I responded to without realising it had been edited, presumably to tone it down.

[monadic]

Also, we should STOP using "diversity" in relation to this matter, this insults URM.

The real issue seems to be "A plurality of commercial allegiances".

[lizrice]

Let’s move this to the next TOC meeting and have the discussion in person (and keep it constructive, folks!)

• TOC is fine with the steering committee model, so there is likely to be some existing use of the word “maintainer” that needs updating. This is all less about actual code commits and more about project oversight and direction.

• As we stand today, the current TOC sees it to be a graduation requirement for project oversight not to be in the hands of a single company. From the length of this thread, there is clearly contention around that, so let’s open it up for real-time discussion and hear everyone’s views.

[jberkus]

Thank you @lizrice!

[monadic]

I wrote a proposal which is here

https://docs.google.com/document/d/11Hiz1dGYRS7GcjedpRVnSlDjIj0AVjeTa0-Td7aW-Lk/edit?usp=sharing

[mswilson]

Something that is far more important to me is a declaration of intent, and an agreement on how disputes that reach an impasse can be resolved. This is more important to me than past history as "proof." When you set criteria like "Have committers from at least two organizations" you are accepting somethings as proxy for something that you are really seeking: a commitment to be collaborative, inclusive, and fair in the activities of the project. A Steering Committee is the same kind of proxy. Neither are any sort of guarantee of the future.

Rather than trying to guarantee the future based on either (1) "demonstration" that a project is open because there is a diversity of sponsorship for committers and maintainers or (2) documentation of a Steering Committee to ensure that no one vendor has "control", I would rather have well established and agreed upon norms and expectations. These should be clear to any person or organization that seeks to gain access to the services and benefits of being part of CNCF. I think it is reasonable to expect a project, and its participants, to agree to arbitration via the TOC, or some other trusted party, to help resolve disputes that have reached an impasse.

This plans for the unexpected future, rather than trying to "prove" you have met a bar at a point-in-time.

[jberkus]

"I think it is reasonable to expect a project, and its participants, to agree to arbitration via the TOC, or some other trusted party, to help resolve disputes that have reached an impasse."

This assumes that a potential contributor who is blocked will report that to the TOC, and that the TOC is in a position to differentiate between the legitmate rejection of a contribution due to lack of technical merit, vs. blocking for corporate politics reasons. The only way this would work is if the TOC had active contributors in every single project.

As for any conflict-based model, many of us work for publicly traded companies, and cannot simply file a complaint with the CNCF if we feel we are being discriminated against by employees of a rival (or worse, partner) company. Any such complaints would need to be first escalated to our own senior management, which means that the chances of the TOC every hearing them are slim at best.

The same goes for leadership; many smaller projects have a self-selecting council system of governance, which makes a lot of sense for smaller projects. And without being party to every deliberation of that council, an outsider from the TOC cannot know why someone working for a particular minority contribution company was not selected. And we do not want to mandate public elections for all projects.

No complaint-based approach towards ensuring nondiscriminatory governance can possibly work.

[mswilson]

No complaint-based approach towards ensuring nondiscriminatory governance can possibly work.

I am reasonably confident that you know that this is why a foundational component of the social and political system of collaborative OSS communities, open-source licenses, are inherently non-discriminatory.

Historically speaking, technical direction disputes have been reasonably managed by the mere possibility of the forks (ref: Producing Open Source Software) that OSS licenses enable.

I think that many people are conflating the rejection, or "slow walking," of contributions to the code, or other tangle artifacts, as a problem area that needs a written governance solution. OSS licenses, and "forkability" are the solution for that, and I do not think we need a new one. We know, empirically, that this works. You are probably right that the TOC is not in a position to have all the relevant facts to help settle a dispute like "my PR is not getting merged, and I think it is for discriminatory reasons based on competitive dynamics and my employment affiliation."

It is my personal opinion that these matters should be discussed openly at the scope of the project itself, and if parties are unsatisfied with the resolution they should mindfully consider if they should maintain their changes "out-of-tree" (to use Linux Kernel terminology, e.g., AppArmor and others) as a development branch long term, or if they want to permanently change direction (see the helpful guide on how to do this).

[jberkus]

Wait, wait, wait: are you arguing that CNCF projects should be allowed to systematically block contributions from the staff of other member companies they don't like? Because it sure sounds like you are.