Good comments Joe. I also don't adore every aspect of the Istio
toggle quoted messageShow quoted text
model. eg I agree that "credit for contributions accrue to companies,
not individuals" isn't optimal. But I still like what they are trying
to do overall.
On Tue, Aug 25, 2020 at 3:05 PM Joe Beda <email@example.com> wrote:
It is great to see a model that limits the influence of a single vendor. The explicit split between coding and non-coding contributions is.. interesting.
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors. If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).
From: firstname.lastname@example.org <email@example.com>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <firstname.lastname@example.org>
Subject: [cncf-toc] Istio Steering Committee
Hi TOC community
I saw this news and wanted to highlight it. With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
Istio is highlighting some benefits of an SC model
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases)
I think we should arrange for a TOC session to discuss SCs.