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).



Joe



From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
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.



https://twitter.com/DanCiruli/status/1297945844767834112?s=09



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.



Alexis