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