Re: Istio Steering Committee

alexis richardson

Thanks for all those thoughts Matt and for reviewing the steering
committee proposal and GH issue I'm going to topline you here
for brevity but LMK if you would like a detailed response on any

At this point, I am just really keen to hear from teams and associated
ISVs like Nats & Synadia, Linkerd & Buoyant, Crossplane & Upbound,
etc. Ultimately my motivation in helping CNCF get started, putting in
time on the TOC and our Principles, is to get to a place where users
benefit from a family of projects that are truly sustainable and
useful, and where innovation is based on a fair and level playing
field for many different ways to make projects succeed.

I'm worried that we've lost sight of some of the "ends", eg good
projects, and are becoming fixed on "means", eg how maintainers are
employed. Let's hear more from people on the challenges they are
seeing here.

The SC model is really intended as ONE way to help. I like it because
it promotes participation from non-coding roles alongside coding
maintainers, and focuses on healthy outcomes.

On Tue, Sep 1, 2020 at 12:54 AM Matt Wilson <msw@...> wrote:

+1 to messages that Kris and Josh have sent on this thread.

On Tue, Aug 25, 2020 at 12:04 PM, alexis richardson wrote:

It isn't but it has aspects we can learn from (good and bad) as do other
projects (eg apache kafka to name one).
I am not familiar with specific concerns or complaints about Apache
Kafka. But I have also not experienced how the project is operating
from a first hand perspective. From a distance, it seems that the
Apache Kafka PMC is welcoming to newcomers, and the work is done in
the open. The committer roster, and the Project Management Committee,
is made of individuals from many different backgrounds and employment
sponsorship. The employer of the majority of committers and PMC
members is on the record as being "committed to maintaining a good
relationship with the Apache Software Foundation as well as the Apache
Kafka community." [1]

I definitely agree that there is much to learn (good and bad) from
other projects, and welcome other perspectives on this. My intuition
(biased by my limited sampling history, and various conversations) is
that the ASF is going to _trust_ PMCs to operate in accordance with
the philosophies and policies of the top level ASF. In those rare
cases where concerns of undue commercial influence peculate up to the
Board of Directors of the ASF (e.g., through the auditing process of
quarterly reporting to the BOD), corrective actions are taken (like
those in the frequently cited Apache Cassandra / DataStax event [2]).

This thread is specifically about steering committees, and what they can
help with especially governance over direction. And avoiding open core
feature withholding.
I think it's good that you highlighted a *specific* concern about
open-core feature withholding. Highlighting concerns can help focus a
conversation toward how they can best be addressed. To me, it is not
obvious that Steering Committees, Governing Boards, Advisory Boards,
and Technical Oversight Committees are a good way to avoid the "slow
walking" of capabilities that a vendor wants to hold as a proprietary

To me, much of what is generally desired is "insurance" that protects
corporate interest in some piece of open-source software, and any
valuable assets around it. It's not wrong to have corporate interests,
or to seek conditions where corporate interests can be represented in
a multi-stakeholder system. Personally, I find it easier to talk about
them plainly and clinically.

There is a lot of focus on having "a seat at the table" because you
don't want another person to work against your interests. There's a
lot less focus on what conversations are had and what decisions that
are made around that table, and if the table is behind closed doors. I
would like this to be better understood in across multiple communities
and projects.

My advice about open-core feature withholding is a pretty simple one:
deliberations on how to best build software should be done in the
public, in a way that puts the common good ahead of any particular
company's priorities. Setting the culture, and expectations, should
receive the most attention and continuous reinforcement. I think that
signs point to Kubernetes getting that generally right: "Community
over product or company" [3].

When making a deliberation about a feature or direction for the
software, wear your "individual hat" most often, and if you find that
you need to advocate on behalf of your employer, make it explicit by
declaring that you're wearing employee-of-company hat.

If we think that a committee or decision making board is required to
make sound decisions that are free from conflicts of interest (like if
a feature should be withheld because it is to the advantage /
disadvantage of a particular company with a commercial interest in the
software), I'd say that we need more attention on community building.

Istio just launched a Steering Committee and that's why it is relevant.
I think it is too soon to say much about this development. I've
already made some less verbose views of mine (and mine alone) known on
Twitter. Personally speaking, I think that the current seat allocation
formula is problematic, as it can encourage gaming statistics. And
that doesn't address a more fundamental question: what does a Steering
Committee *do*, exactly? And why must it be done privately? Without
getting a seat at the table, or at least being allowed in the room,
you don't know.

I think this all leads to conditions that weaken trust bonds through a
sense of uneven power dynamics. And then everyone starts competing so
they can be in The Room Where It Happens [4].

--msw (wearing his "individual" hat)


Join to automatically receive all group messages.