Istio Steering Committee
toggle quoted messageShow quoted text
Thank you everyone who’s putting such thought into this topic. I would like to get a discussion on this onto the TOC meeting agenda at a point where the SIG Contrib Strategy folks have had a chance to discuss and think through the issues (are we at that point yet?) and, since he made the original proposal, when Alexis is available.
On Tue, 1 Sep 2020 at 22:29, Matt Farina <matt@...> wrote:
On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*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
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
Red Hat OSPO
On Wed, Sep 2, 2020 at 09:22 AM, Josh Berkus wrote:
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'sThis 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
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.
On 9/2/20 2:49 PM, Matt Wilson wrote:
I think this is an interesting conversation, but it doesn'tYeah, I would love to see more of the other discussion on the gov-wg ML.
Pick it up there?
I would like to make a suggestion: none of what I have seen proposedThe "proof" is where it is. If there are people who are allowed to
merge code/docs for the project and work for multiple organizations,
that's probably the strongest proof we can obtain that contributions are
not limited by employer.
It is definitely true that there are other possible demonstrations of
openness to contributions. That's why I asked the TOC to rule on a
rationale; by making the *reason* paramout, SIGS/TOC are a position to
judge borderline cases. And if open source is good for anything, it's
creating borderline cases.
Rather than focusing on various tests and studying past events, I...not quite sure what you're saying here, in practical terms.
Red Hat OSPO