+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
capability.

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)

[1] https://www.confluent.io/apache-guidelines/#the_importance
[2] https://sdtimes.com/afs/apache-foundation-board-reining-datastax/
[3] https://github.com/kubernetes/community/blob/master/values.md#community-over-product-or-company
[4] https://www.youtube.com/watch?v=WySzEXKUSZw