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 

The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.

One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?

On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:

I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> 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).

 

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 

 

 

 

 

 

Good points Matt.  Helm is well run and provides a useful model of one successful pattern.  

I don't think there is one true governance rule for who is on the SC.  IMHO it is critical to include non code maintainers, focus on people who have a real stake in success of projects and community, and avoid creating bureaucracy.  Asking maintainers "how could an SC help?" is a good starting point in regard to the latter point.

On Tue, 25 Aug 2020, 16:45 Matt Farina, <matt@...> wrote:

The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.

One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?

On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:

I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> 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).

 

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 

 

 

 

 

 

On 8/25/20 1:42 AM, alexis richardson wrote:
>
> 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) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

On 8/25/20 1:42 AM, alexis richardson wrote:
>
> 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) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea. 

On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus <jberkus@...> wrote:

On 8/25/20 1:42 AM, alexis richardson wrote:
>
> 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) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

--

Kris Nova

Chief Open Source Advocate

85 2nd Street

San Francisco, CA 94105

nova@...

It isn't but it has aspects we can learn from (good and bad) as do other projects (eg apache kafka to name one).

This thread is specifically about steering committees, and what they can help with especially governance over direction.  And avoiding open core feature withholding. 

Istio just launched a Steering Committee and that's why it is relevant. 

On Tue, 25 Aug 2020, 20:00 Kris Nova, <kris.nova@...> wrote:

Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea. 

On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus <jberkus@...> wrote:

On 8/25/20 1:42 AM, alexis richardson wrote:
>
> 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) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

--

Kris Nova

Chief Open Source Advocate

85 2nd Street

San Francisco, CA 94105

nova@...

On 8/25/20 11:57 AM, Alexis Richardson wrote:
> Josh, feel free to highlight the negative aspects of Istio's history and
> governance on another thread.  I may well join you.  But please let's
> also give them credit for moving forward with improvements.  As i said
> in the email you quoted, their SC illustrates some of the positives.  I
> never said it is a panacea!
>

Others have already gone over the issue of having positions and
contributions accrue to companies and not individuals.

Second, there's the fact that the 3 biggest corporate contributors get
100% of representation, and smaller contributors get none in practical
terms.  This is presently causing some of the smaller contributors to
leave Istio.  Overall, the Istio SC is a great example of how not to do
an SC.

I'm not saying SCs are bad, particularly as someone who is currently an
elections officer for the Kubernetes SC.  What I'm saying is that SCs do
not work as a substitute for having balanced technical leadership.  I
big, successful project can often use an SC to supply leadership beyond
the technical, but that doesn't do anything to fix technical leadership
that is concentrated into too few hands (whether corporate or individual).

What I'm particularly opposed to the TOC doing is imposing an SC on
projects that have governance problems.  If a project has broken
governance, adding extra committees will just make it more broken --
particularly since unbalanced governance problems are often reflective
of other issues like contributor recruitment issues, i.e. if you can't
recruit outside contributors to your maintainer group, why would you
suddenly have the ability to recruit knoweldgable non-technical people
to your SC?  The solution is to fix the recruitment problems, not add an
SC if the project doesn't otherwise need one.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

On 8/25/20 12:10 PM, Alexis Richardson wrote:
> Josh, please disentangle your feelings about istio from the constructive
> discussion i can see you want to have.
>

Then pick a better example of a steering committee.

I don't know of a single example of a steering committee successfully
evolving otherwise broken leadership within a project.  Maybe you do?
I've never seen it in practice.


--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO

Agree that SC should (if suggested) remain a known good option, and Not Compulsory.

Agree that some projects are "small" - but i would have said Helm is small!  My belief is that SCs can help growth. Many projects now have numerous repos and moving parts.  The direction may not be clear.  End users may want more of a say.  Contributors and maintainers should welcome this, and most do.

On Tue, 25 Aug 2020, 20:30 Josh Berkus, <jberkus@...> wrote:

On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people.  But you still
> get benefit from org level direction over the top.

And for large projects like Helm, an SC has these benefits.  Just like
Kubernetes.  But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups.  Unless you add someone from outside the project, in which case
you have different problems.

For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.

Of course, it's really up to what the project wants.

> Fwiw, i don't believe in imposing or forcing things either.  Apologies
> if I have given that impression.

We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.

BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee.  Other members of the SIG may
well disagree with me.  I am also not speaking for Red Hat.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO