2 org requirement - Openness and Sustainability Discussion

[TheFoxAtWork]

Graduation [Requirement] Project maintainers from at least 2 organizations that demonstrates survivability.

This discussion is intended to capture community input on redefining the "2-org requirement" that considers the recommendations of the Projects Moving Levels Task Force

This criteria has often been interpreted two ways:

1. Openness - having a minimum of two organizations in the maintainership of a project provides distribution of accountability in the project's direction and decision making, such that no single entity can direct the project in their favor - it is done through consensus.
2. Sustainability - in the event that the primary contributing organization dissolves or detaches itself from the project, another organization is capable (through the governance and decision making structure) to continue the project.

The recommendation from the group is to break up the criteria to reflect openness and sustainability as both can be achieved by projects without mandating a quantity of maintainer organizations.

Openness has largely been discussed and is reaching consensus:

The project maintains and applies governance and decisions making processes where a single organization cannot exercise their majority to drive the direction of the project.

If applied as a criteria, projects need to have a decision making structure to ensure organizational voting caps are in place. This aligns with many governance structures of foundations and enables vendor-neutrality of the project, a core characteristic of the CNCF.

Sustainability however has an open item to resolve, key points from the Task Force discussion:

• We cannot assume maintainers from multiple orgs will ensure survivability as there is no way to ensure survivability, rather we need to mitigate and reduce the risk of projects encountering these issues with no mechanism to resolve them
• Will the project continue if the primary organization driving its development disappears immediately?
• What does a project "continuing" in that scenario look like when it is a graduated project with n adopters? How are the adopters notified?
  • the TOC sees this with several projects, the vc-backed start up goes under but it has adopters who are bought-in and need it. We usually kick off a process to solicit new maintainers from those adopters, but this isnt sustainable after the primary drivers of the project are gone and the crisis is before us.
• Does the project have sufficient governance to bring it back if the majority (defined by the project decision process) of the maintainers are not responsive/inactive?
• The bus factor… what happens if a primary leader goes away (e.g., won the lottery, went to a company that prohibits open source contribs, or ran off to start a new coding product)? How is that handled both in the governance and in practicality
• What happens, on a larger level, if the company sponsoring a large group of contributors goes away? Is there sufficient technical community to replace them (like OpenToFu had whole new people step up)? This is especially important for projects where a super majority of contributions come from one company. It requires either many technical users or some who are highly motivated to keep it going.
• Does the project have the means to replace people without those who left being able to mentor and onboard the new people? This requires things like documentation (practical and in code).
• Examples of how these situations come up and we should account for the criteria covering:
  • A VC funded company exits without being bought or going public. It closes and project maintainers go on to someplace else without time or motivation to continue the project.
  • Maintainers working for a large company leave and go do a startup in a different space. Leaving their previous work behind.
  • A company that has invested in open source to get things to maturity pulls back and focuses their efforts on their own products. The open source offering is then under staffed.
• we will not reach 100% assurance of project sustainability, but the criteria must allow the TOC to effectively evaluate this criteria in the context of the project undergoing review
• Devstats is not an answer to this

With all these points in mind, how should we best define criteria to reflect this in an outcome-oriented manner?

[caniszczyk]

We should also ensure there's some end user input here (not only from well meaning vendors). While there can be a lot of "healthy" open source projects that are single vendor, there's more risk on single vendor major contribution open source projects. As the End User TAB gets booted up, they could provide input here but I think the TOC should always have discretion.

[leonardpahlke]

Sounds like an important discussion. My two cents, without being too deep in the processes here.

In a graduated project, I would expect a diverse set of maintainers working on the project (also in terms of company affiliation). In that sense, I like that the 2 org requirement, as it is relatively simple and points in the right direction. As I understand from the discussion, the 2 org requirement does not go far enough to ensure a sustainable and open community around a project. I remember a couple of months ago the etcd maintainer team was very short on contributors and I remember especially @dims being very vocal about spreading the word and getting new folks onboard. Maybe there are some learnings of how they handled the situation.

In the event of core maintainers breaking off the project (reactive side)… spitballing ad-hoc questions a bit here that may be interesting to discuss…

• when is a graduated project in danger, and how do we know about it?
• what are the minimum required day to day / week by week contributions to sustain a graduated project short term (security and bug fixes?) (a bit of a sensitive topic) (could some kind of open-source cncf fire department help with this?)
• how long does it take to spread the word, engage & onboard new contributors (time horizon to react)
• is something like a maintainer contract for open source projects a thing somewhere? (so there is time to onboard and find new contributors)

I'm not sure how concerned we are about that the 2 org requirement in that sense that it does not set the bar good enough preventative. Maybe the reactive measures we can take & improve can be sufficient.

[TheFoxAtWork]

Notes from TOC call on 12/19 - could be simply making adopters aware of the risk for single organization-driven projects. But practical maintainer engineering - that knowledge is kept in "house" and not documented, making that transition so much more difficult. Accepting single organization-driven is more than risk, whereas pushing for more diversification allows this to be addressed early and forces that context of maintainer engineering into the open in a documented fashion. there is a larger problem: if you cant get 1 maintainer, you likely wont get 2 and they're usually not the creator maintainers, its really shifting those maintainers to the next generation to sustain the project.
Providing some form of governing body allows for some protections here, however someone would still have administrative permissions.
Is there a differentiation from maintainers from vendor organizations versus end user organizations?
There is a lot of history with this looking at NATS as an example.

[craigbox]

(Side note, I didn't know TOC used discussions, and I'm not sure when to use them vs. issues.)

Given this is back in the news, I am not sure how aware the current TOC is aware of the discussion around this issue that happened in the past.

[monadic]

The 2-org criterion was never intended to gaurantee sustainability because it can't. The purpose of the 2-org criterion was to ensure that governance is in some sense "objective" and "visible", as opposed to being hidden in a privtate company. For example the governance can't be "the CEO of company X told us to do this feature and not that one, or we get fired", if there is a person outside the org. I am not claiming this criterion is perfect or perhaps even suffiicient (for what?). But it is good hygiene. It also does not prevent a vendor from making a business out of selling an enterprise build, version, service, or product.

It would be nice to have a model that encourages small to medium businesses to invest in OSS for the hope of a return, without ending up like ASF where the total ban on all mentions of the OSS project in commercial matters makes it very expensive to run a business. That means the end state of projects is maintainer aggregation (eg Confluent/Kafka) or maintainer depopulation (eg Tomcat).

SUSTAINABILITY is what we as a community need to focus on. Let's look at the software industry and ask what is sustainable.

[angellk]

+1
From the issue @craigbox mentioned:

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. (Liz Rice)

[monadic]

I want to be clear that my comments are not 'due to' weaveworks. There are some lessons to draw, yes, but the main reason I am commenting is that I have some free time now.

Happy to discuss in Paris :-)

[monadic]

@craigbox these topics were addressed in the Steering Committee doc & discussion of a few years ago. I can dig it out if people can't find.

[craigbox]

(The Weaveworks part was really just something I added because I also saw your LinkedIn post this morning)

I assume the doc you refer to is this one. I was interested to see that much of it moved to a "vendor neutrality" document.

[monadic]

Correct doc. When I thought about this and spoke with others, the two things that came up as 'single vendor' risks were: Feature Holdback (aka "I want an improvement that is being blocked by the vendor to make me buy the paid version"), and Company Existence (aka "if one company does a lot of the work, is there a transition plan if that changes").

[craigbox]

On the topic of holdback: you asked the question, and while there was some discussion, the likely problem didn't really come up:

What happens if someone else does come along and volunteers to publish stable Linkerd builds to the linkerd repo? All the maintainers who could approve their publishing are from Buoyant, who already decided they did not want those things to exist for free.

[monadic]

@angellk I was wondering if it would help to start with examples from the industry at large first. Making any software or SaaS into a successful and self-sustaining thing is really hard, without OSS necessarily being present. In all cases, I think sustainability boils down to having a business model for matching the needs of software consumers and producers. The piece that I think we can lose sight of here in CNCF is that over time this matters more, if the project keeps adding users and their needs mature.

Or to put it in simple terms, who will be responsible for back-patching and rebuilding some project's version 1.6.2b with addons A, B, C, when a big end user's systems are failing at 2am, when all the cool kids want to work on the latest version 5.0? There is almost no intrinsic motivation to make up for the economics of sustainbility with mature software support, all the less with complex and boring infra that has a big integration surface.

Nor should there be. We wring our hands about 'maintainer burn out'. Well of course maintainers burn out, they don't get time off if there are always too few of them, and the "community" yells when they turn down a feature.

It is great to have big tech companies that can help, but there just isn't enough bigco bandwidth to support all the projects properly. Nor are they the right people in many cases.

We can wave at end users. Guess what, they don't want to support software either. Every company ends up spinning out any successful project into its own BU or into a partner company.

Success story -- LinkedIn makes Kafka. Then Confluent is set up. Or if you want one without a foundation, MongoDB, Gitlab, Grafana Labs. Ask their founders if they would work with CNCF, or start a new project there.

[monadic]

I have thought about the 2-tier model too. It's like when people talk about a two speed Europe: with central countries on the Euro, full EU commitment, IDs, and tax/bank/army whatever on the table if there is more convergence; or with outer countries in a loose trade association for single market benefits but also "more control".

Personally I'd rather get CNCF to work well for all industry stakeholders, than have two tiers though.

[angellk]

@craigbox there are already talks submitted (and accepted) to KubeCon that aren't "owned by the CNCF" - such as Sigstore and Tekton.

Also, projects can also list themselves in the CNCF landscape as "affiliated".

So, for Cat 3 vendors that want to use CNCF marketing resources - they can become members, or work with a member if they have those relationships.

Agree with @monadic about getting CNCF to work well for all industry stakeholders vs two tiers.

[craigbox]

there are already talks submitted (and accepted) to KubeCon that aren't "owned by the CNCF" - such as Sigstore and Tekton.

Sigstore and Tekton are both "owned" (ahem) by another LF project; OpenSSF and CD Foundation respectively.

There was a year when Istio was expected to be donated to the CNCF, and there were a lot of Istio talks at KubeCon. (This upset competitors who had a CNCF project.) Then, when it became clear Istio wasn't going to be donated, that privilege was quickly taken away, and any talk that was about Istio had to be couched as "an Envoy-based service mesh".

Today, it's not practical for a non-CNCF, non-LF project to expect to be promoted at KubeCon — and nor should it be.

[angellk]

@craigbox sounds like you're raising additional concerns that you experienced previously

yes, it's not practical - nor should it be expected - for non-LF projects to be promoted at KubeCon - though I expect companies (if any) that back those projects could look into booth space, etc.

This is such a great discussion - I will be in Paris as well and would love to continue it (not just in the TOC/TAG meeting) with yourself @craigbox and @monadic - as well as others. Perhaps we can find time to discuss Sustainability in person?

[craigbox]

@angellk I'm not raising a concern, because in the current model, as you called out - it's not normal for non-LF projects to be promoted at KubeCon. (I should mention here that there is a scale of benefits that increase as you move from sandbox to graduated.)

This model explicitly incentivises companies to home their project with in the LF.. That's the crux of the debate. Right now, this model is suitable for projects that want to be multi-vendor, but conflicts with vendors building a business model around software they have created. The result is that projects aren't being submitted (per Alexis), or projects that are in the foundation are looking to change their CNCF offering (Linkerd and others to follow.)

To change this situation, the CNCF would either need to change (a) the project track model or (b) the conference/promotion model.

I can't be in Paris, I'm sorry, nor, I imagine, can many other relevant stakeholders. I'd like to make sure this discussion continues in a fashion that accommodates those who are unable to attend the event.