On Wed, Sep 2, 2020 at 09:22 AM, Josh Berkus wrote:

On 9/1/20 1:58 PM, Matt Wilson wrote:

Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?

This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.

I'm not personally aware of a good example of a strict quorum voting
structure that provided an empowering voice or an ability for people
who are not technically as deep. But I am definitely curious to learn
more about effective practices put in place by communities, keeping in
mind that effective practices for one group of humans may differ for
another. Is there one I should study more closely?

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.

This is one of the areas where I continue to struggle to understand
the concern. To me, open-source licenses make it difficult to hold
users/adopters "captive." When vendors make an attempt to do so, it
can result in others stepping up to create better, more "open"
conditions. Sometimes (historically, rarely) that means starting a new
community, since that is something that open-source licenses enable.

The voices of "freeware" users is an important and valuable. When it
comes to how a vendor invests their time, I think that paying
attention to paying customers is a natural thing to do. Paying
attention to non-paying customers can be a very important part of your
business, especially in growing your business. I do not think that a
vendor has an obligation to provide free services or development for
"freeware" users. Also, I do not think that there needs to be some
structural element to open-source governance recommendations, to
"ensure" that a project is being "open enough."

I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459.

I would like to make a suggestion: none of what I have seen proposed
can _guarantee_ that "the project is open to contributions regardless
of employer" as was summarized as the objective in
https://github.com/cncf/toc/issues/459#issuecomment-641550257.

It seems that what is being asking for is evidence, or perhaps
"proof", as embodied a project's documentation (as proposed with the
SC concept) or commit history (as it currently stands in the
graduation criteria), that they are open to contributions from
all. What matters far more to _me_ is what happens in cases where a
project is faced with disagreements, and how they are resolved
constructively and collaboratively. And it may be that a community has
never faced any material disagreement.

Rather than focusing on various tests and studying past events, I
would rather see the TOC and (only in the very rarest of
circumstances) GB be able to act as an ombudsman for those rare
significant disagreements that reach an impasse, because each
circumstance of disagreement is going to be unique and can require a
collection of facts before judgment.

--msw