|
On 9/2/20 2:49 PM, Matt Wilson wrote: I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459. Yeah, 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 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. The "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
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. ...not quite sure what you're saying here, in practical terms. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
Matt Wilson
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
|
|
|
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. 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. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
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: If a steering committee is recommended then the reasons for it need to be well documented and articulated. There are a lot of assumptions and they are not shared. That is ripe for miscommunications.
Governance is often a reflection of the people involved, the culture they have, and needs they run into. If I were looking at different projects at different points in their lifecycles with different target audiences, I would likely recommend different governance structures that suit them. The goal is to make them and their users successful.
A recommendation for one particular form of governance then gets quite prescriptive. If someone doesn't follow it because it doesn't suit their culture and needs, how will people look at them?
I would hope that the people who make any recommendations around forms of governance have a lot of experience working with them and within them. That gives the people standing among developers to even suggest the items. Those who don't have heavy experience with community governance handing forms of governance to those on projects will likely not be met well by developers.
I would suggest starting with cultural elements that we would like to see present in any form of governance. If these are part of a steering committee than we would need to articulate them in detail so we can teach people about them. Those cultural elements can likely be suggested to many forms of governance.
I'm also reminded that something like 99% of those who use a project never contribute or say anything. If a vocal element in the 1% gets to push their direction than it may have an impact on the 99% that we often don't think about. I've been taught to give everyone a chance to voice their opinions and not let a small loud subset dictate things. Letting vocal end users have an out-sized voice could easily do that. That's why I think it's healthy for project leaders to go out to users and talk with them. This way you can learn from many users... many of which are not vocal in the day to day.
- Matt Farina
On Tue, Sep 1, 2020, at 5:12 PM, alexis richardson wrote:
Correct, I think that model is overly prescriptive to recommend for every project.
I'm proposing a pattern that can be instantiated in more than one way, depending on what the project team think it needs. Your model below could be one way.
On Tue, 1 Sep 2020, 21:58 Matt Wilson, < msw@...> wrote: On Tue, Sep 1, 2020 at 01:33 PM, alexis richardson wrote:
>
> Well, the nomenclature isn't completely new. But I think the practices
> include novel parts eg end users having a say in overall direction.
End users having a say in overall direction isn't novel. To me, the
communities and ecosystems that are the most resilient and sustainable
mindfully include everyone in the evolution of the software, and of
the working structure of the community / ecosystem around it.
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?
I don't think that's the kind of Steering Committee you are
proposing. But that kind of Steering Committee exists in the world,
with spotlights shining on it.
--msw
|
|
|
If a steering committee is recommended then the reasons for it need to be well documented and articulated. There are a lot of assumptions and they are not shared. That is ripe for miscommunications.
Governance is often a reflection of the people involved, the culture they have, and needs they run into. If I were looking at different projects at different points in their lifecycles with different target audiences, I would likely recommend different governance structures that suit them. The goal is to make them and their users successful.
A recommendation for one particular form of governance then gets quite prescriptive. If someone doesn't follow it because it doesn't suit their culture and needs, how will people look at them?
I would hope that the people who make any recommendations around forms of governance have a lot of experience working with them and within them. That gives the people standing among developers to even suggest the items. Those who don't have heavy experience with community governance handing forms of governance to those on projects will likely not be met well by developers.
I would suggest starting with cultural elements that we would like to see present in any form of governance. If these are part of a steering committee than we would need to articulate them in detail so we can teach people about them. Those cultural elements can likely be suggested to many forms of governance.
I'm also reminded that something like 99% of those who use a project never contribute or say anything. If a vocal element in the 1% gets to push their direction than it may have an impact on the 99% that we often don't think about. I've been taught to give everyone a chance to voice their opinions and not let a small loud subset dictate things. Letting vocal end users have an out-sized voice could easily do that. That's why I think it's healthy for project leaders to go out to users and talk with them. This way you can learn from many users... many of which are not vocal in the day to day.
- Matt Farina
On Tue, Sep 1, 2020, at 5:12 PM, alexis richardson wrote:
Correct, I think that model is overly prescriptive to recommend for every project.
I'm proposing a pattern that can be instantiated in more than one way, depending on what the project team think it needs. Your model below could be one way.
On Tue, 1 Sep 2020, 21:58 Matt Wilson, < msw@...> wrote: On Tue, Sep 1, 2020 at 01:33 PM, alexis richardson wrote:
>
> Well, the nomenclature isn't completely new. But I think the practices
> include novel parts eg end users having a say in overall direction.
End users having a say in overall direction isn't novel. To me, the
communities and ecosystems that are the most resilient and sustainable
mindfully include everyone in the evolution of the software, and of
the working structure of the community / ecosystem around it.
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?
I don't think that's the kind of Steering Committee you are
proposing. But that kind of Steering Committee exists in the world,
with spotlights shining on it.
--msw
|
|
|
Correct, I think that model is overly prescriptive to recommend for every project.
I'm proposing a pattern that can be instantiated in more than one way, depending on what the project team think it needs. Your model below could be one way.
On Tue, 1 Sep 2020, 21:58 Matt Wilson, < msw@...> wrote: On Tue, Sep 1, 2020 at 01:33 PM, alexis richardson wrote:
>
> Well, the nomenclature isn't completely new. But I think the practices
> include novel parts eg end users having a say in overall direction.
End users having a say in overall direction isn't novel. To me, the
communities and ecosystems that are the most resilient and sustainable
mindfully include everyone in the evolution of the software, and of
the working structure of the community / ecosystem around it.
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?
I don't think that's the kind of Steering Committee you are
proposing. But that kind of Steering Committee exists in the world,
with spotlights shining on it.
--msw
|
|
|
Matt Wilson
On Tue, Sep 1, 2020 at 01:33 PM, alexis richardson wrote:
Well, the nomenclature isn't completely new. But I think the practices
include novel parts eg end users having a say in overall direction.
End users having a say in overall direction isn't novel. To me, the communities and ecosystems that are the most resilient and sustainable mindfully include everyone in the evolution of the software, and of the working structure of the community / ecosystem around it. 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? I don't think that's the kind of Steering Committee you are proposing. But that kind of Steering Committee exists in the world, with spotlights shining on it. --msw
|
|
|
Well, the nomenclature isn't completely new. But I think the practices include novel parts eg end users having a say in overall direction.
On Tue, 1 Sep 2020, 21:06 Matt Wilson, < msw@...> wrote: On Tue, Sep 1, 2020 at 01:50 AM, alexis richardson wrote:
>
> Thanks for all those thoughts Matt and for reviewing the steering
> committee proposal and GH issue
> https://github.com/cncf/toc/issues/459. I'm going to topline you here
> for brevity but LMK if you would like a detailed response on any
> point.
Understood. I'm scattering comments all around, and zooming back out
makes sense to re-focus the thread toward a goal.
> 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.
When I review a lot of the framing material for CNCF, it resonates
well with me. Like the principles of self-governing projects [1] and
"minimum viable governance." With guiding principles, there is often
ambiguity. I've seen in many cases ambiguity causes a sense of
confusion and unease, and guiding principles are translated into
evaluative criteria to add comfort and safety.
I made an analogy during the CNCF SIG Contributor Strategy meeting
today: to me, it's like promotion criteria that is commonly found at
larger companies. In my experience, some corporate career ladders are
set up in ways that have some ambiguity to provide multiple paths to a
promotion. Both managers and employees sometimes ask, "can I have a
specific example of a work project, and generally quantifiable
evidence, that when completed will assure me a promotion?"
In the current incubation and graduation process, people associated
with the projects are bound to ask, "why aren't we getting promoted?
Just tell me what I have to do to graduate, and we'll do it. But we
_need_ to graduate."
> 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.
My intuition is that you're right.
> 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.
I worry that recommending a "Steering Committee" will be confusing,
especially because it is not a well-established set of practices that
are based in commonly held governance philosophies. It is a shorthand,
and a proxy, for something that gives us short term comfort, without
empirical evidence that implementing such a committee results in the
"ends" that we (in a broader community use of the word) want to
encourage. It might even be used for optical purposes to give an
appearance of openness, when in fact the rules are constructed to
favor particular players in competitive spaces.
So, I think that multiple things are true at once:
* the "Have committers from at least two organizations." requirement
for graduation may constrain the ways that projects evolve over
time, and act as an unnecessary barrier and bureaucratic requirement
that will slow them down, rather than help build a sustainable
project and diverse ecosystem around it
* finding ways to encourage that people in non-coding roles be
recognized as peers that are committed to a project's mission /
charter, and be able to take on responsibilities of leadership, is a
valuable time investment for the SIG
* using the term "Steering Committee" for this effort may cause
confusion, especially if there is a recommended structure and
practices that are not well understood and adopted across multiple
open-source projects and collaborative community settings.
--msw
[1] https://github.com/cncf/toc/blob/master/PRINCIPLES.md#projects-are-self-governing
|
|
|
Matt Wilson
On Tue, Sep 1, 2020 at 01:50 AM, alexis richardson wrote:
Thanks for all those thoughts Matt and for reviewing the steering
committee proposal and GH issue
https://github.com/cncf/toc/issues/459. I'm going to topline you here
for brevity but LMK if you would like a detailed response on any
point.
Understood. I'm scattering comments all around, and zooming back out makes sense to re-focus the thread toward a goal. 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. When I review a lot of the framing material for CNCF, it resonates well with me. Like the principles of self-governing projects [1] and "minimum viable governance." With guiding principles, there is often ambiguity. I've seen in many cases ambiguity causes a sense of confusion and unease, and guiding principles are translated into evaluative criteria to add comfort and safety. I made an analogy during the CNCF SIG Contributor Strategy meeting today: to me, it's like promotion criteria that is commonly found at larger companies. In my experience, some corporate career ladders are set up in ways that have some ambiguity to provide multiple paths to a promotion. Both managers and employees sometimes ask, "can I have a specific example of a work project, and generally quantifiable evidence, that when completed will assure me a promotion?" In the current incubation and graduation process, people associated with the projects are bound to ask, "why aren't we getting promoted? Just tell me what I have to do to graduate, and we'll do it. But we _need_ to graduate." 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. My intuition is that you're right. 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. I worry that recommending a "Steering Committee" will be confusing, especially because it is not a well-established set of practices that are based in commonly held governance philosophies. It is a shorthand, and a proxy, for something that gives us short term comfort, without empirical evidence that implementing such a committee results in the "ends" that we (in a broader community use of the word) want to encourage. It might even be used for optical purposes to give an appearance of openness, when in fact the rules are constructed to favor particular players in competitive spaces. So, I think that multiple things are true at once: * the "Have committers from at least two organizations." requirement for graduation may constrain the ways that projects evolve over time, and act as an unnecessary barrier and bureaucratic requirement that will slow them down, rather than help build a sustainable project and diverse ecosystem around it * finding ways to encourage that people in non-coding roles be recognized as peers that are committed to a project's mission / charter, and be able to take on responsibilities of leadership, is a valuable time investment for the SIG * using the term "Steering Committee" for this effort may cause confusion, especially if there is a recommended structure and practices that are not well understood and adopted across multiple open-source projects and collaborative community settings. --msw [1] https://github.com/cncf/toc/blob/master/PRINCIPLES.md#projects-are-self-governing
|
|
|
Thanks for all those thoughts Matt and for reviewing the steering committee proposal and GH issue https://github.com/cncf/toc/issues/459. I'm going to topline you here for brevity but LMK if you would like a detailed response on any point. 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
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
|
|
|
Matt Wilson
+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
|
|
|
+1 for async comms
For sync, I can't due any time after 10am PT due to family commitments.
On Mon, 31 Aug 2020, 19:25 Matt Wilson, < msw@...> wrote: On Thu, Aug 27, 2020 at 02:51 PM, Josh Berkus wrote:
Hey, all:
If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.
https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing
I'd like to participate in a discussion, but my calendar commitments at work make it very difficult to commit to appointed times to jump on Zoom. This makes asynchronous communication more accessible to me. I understand that this is not necessarily the same for others, and that that is a lot of value in "high bandwidth" direct conversations.
--msw
|
|
|
Matt Wilson
On Thu, Aug 27, 2020 at 02:51 PM, Josh Berkus wrote:
Hey, all:
If you want to continue this discussion, I wanted to invite anyone
interested to attend the Governance WG meeting on Tuesday at 10amPDT.
https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?usp=sharing
I'd like to participate in a discussion, but my calendar commitments at work make it very difficult to commit to appointed times to jump on Zoom. This makes asynchronous communication more accessible to me. I understand that this is not necessarily the same for others, and that that is a lot of value in "high bandwidth" direct conversations.
--msw
|
|
|
Kris Nova <kris.nova@...>
I can only make the governance meeting - we have our meetings with the EU during the TOC meetings unfortunately.
If we push the TOC discussion back until the next call I can make it.
On Sat, Aug 29, 2020 at 10:04 AM Alexis Richardson <alexis@...> wrote:
I'm keen to discuss this in the TOC, and then work out details in the various WGs and community. When is everyone back?
-- Kris Nova Chief Open Source Advocate
85 2nd Street San Francisco, CA 94105
|
|
|
I'm keen to discuss this in the TOC, and then work out details in the various WGs and community. When is everyone back?
|
|
|
|
|
|
On 8/25/20 12:53 PM, April Kyle Nassi wrote: I do echo Kris' comment about CNCF having an opinion on how projects
govern. It seems like as CNCF has grown, perhaps there is now a desire
to be more explicit about the types of governance we want projects to
have? This is something those of us on the Governance WG would love to
get more direction around so we can help make templates, etc and build
programs that would benefit projects. There's going to be a huge gap between the governance structures we *recommend* and the ones that are *acceptable to CNCF*. The CNCF was founded on having considerable autonmy for projects in governance, and that has to include adopting systems we think are "bad". -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
Kris Nova <kris.nova@...>
Not trying to create a fallacy - apologies - these threads seem to be glamorizing steering committees more and more - and I just wanted to advocate that not every project needs one.
On Tue, Aug 25, 2020 at 12:46 PM Alexis Richardson <alexis@...> wrote:
Nobody is suggesting imposing anything. That suggestion is a red herring.
+1 to Josh Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].
Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet.
I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>
TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing.
On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.
Agree that some projects are "small" - but i would have said Helm is small! My belief is that SCs can help growth. Many projects now have numerous repos and moving parts. The direction may not be clear. End users may want more of a say. Contributors and maintainers should welcome this, and most do.
On Tue, 25 Aug 2020, 20:30 Josh Berkus, < jberkus@...> wrote: On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people. But you still
> get benefit from org level direction over the top.
And for large projects like Helm, an SC has these benefits. Just like
Kubernetes. But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups. Unless you add someone from outside the project, in which case
you have different problems.
For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.
Of course, it's really up to what the project wants.
> Fwiw, i don't believe in imposing or forcing things either. Apologies
> if I have given that impression.
We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.
BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee. Other members of the SIG may
well disagree with me. I am also not speaking for Red Hat.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
--
Kris Nova Chief Open Source Advocate
85 2nd Street San Francisco, CA 94105
-- Kris Nova Chief Open Source Advocate
85 2nd Street San Francisco, CA 94105
|
|
|
Kris Nova <kris.nova@...>
+1 to Josh Speaking as a Falco maintainer here, our community just re-vamped our model for how we manage sub projects, official support, and decision making in the open. All of these seem like they would fit under a steering committee charter. [1] [2] We even mentioned this in our latest update [3].
Having a steering committee imposed on the project would just create more process and impair innovation for us. It's not that we are necessarily against the idea, we just aren't there yet as a project. Furthermore I doubt any of the engineers are going to be keen on introducing process to solve a problem that doesn't exist yet for the project. As far as end-users are concerned, we see them engaged in all of the community activities and contributing to the process outlined in the references below. Again -- we just aren't there yet.
I look at a SC like a tool. It's a well-known tool, that obviously works to solve well-known issues for folks. Can we just keep it at that? It's a tool. The tool works well, if you happen to need it and decide to use it. <click here to read more>
TLDR; I thought that the whole point of this was that the CNCF didn't impose rules/regulations on how projects self-govern? Maybe I am mistaken, but I thought that was -- like -- a thing.
On Tue, Aug 25, 2020 at 12:38 PM alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.
Agree that some projects are "small" - but i would have said Helm is small! My belief is that SCs can help growth. Many projects now have numerous repos and moving parts. The direction may not be clear. End users may want more of a say. Contributors and maintainers should welcome this, and most do.
On Tue, 25 Aug 2020, 20:30 Josh Berkus, < jberkus@...> wrote: On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people. But you still
> get benefit from org level direction over the top.
And for large projects like Helm, an SC has these benefits. Just like
Kubernetes. But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups. Unless you add someone from outside the project, in which case
you have different problems.
For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.
Of course, it's really up to what the project wants.
> Fwiw, i don't believe in imposing or forcing things either. Apologies
> if I have given that impression.
We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.
BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee. Other members of the SIG may
well disagree with me. I am also not speaking for Red Hat.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
-- Kris Nova Chief Open Source Advocate
85 2nd Street San Francisco, CA 94105
|
|
|
Thanks for bringing this up Stephen.
I would suggest that the structure (which includes SC or not) can't fix problems that may be cultural. For example, knowing ones audience is important. Taking the time to sit down with users, understand them, understand when one project ends and others begin, and work for the benefit of the people involved is a cultural trait.
I would like to see more that teaches this trait.
On Tue, Aug 25, 2020, at 3:42 PM, Stephen Augustus wrote:
(+ SIG ContribStrat)
I could see the overarching theme as "distilling what it could mean to be a 'good maintainer'".
SIG Contributor Strategy is exactly the kind of venue to have this discussion and we'd welcome (kind) discourse around this across our main meeting, WG Governance, and the soon-to-be-launched Maintainer's Circle.
-- Stephen
On Tue, Aug 25, 2020, 15:38 alexis richardson <alexis@...> wrote:
Agree that SC should (if suggested) remain a known good option, and Not Compulsory.
Agree that some projects are "small" - but i would have said Helm is small! My belief is that SCs can help growth. Many projects now have numerous repos and moving parts. The direction may not be clear. End users may want more of a say. Contributors and maintainers should welcome this, and most do.
On Tue, 25 Aug 2020, 20:30 Josh Berkus, < jberkus@...> wrote: On 8/25/20 12:20 PM, Alexis Richardson wrote:
> During the summer break it occurred to me that many of the advantages i
> could envisage in adding SCs would be achieved if the notion of
> Maintainer was broadened to include non coding people. But you still
> get benefit from org level direction over the top.
And for large projects like Helm, an SC has these benefits. Just like
Kubernetes. But in smaller projects, where you're looking at a couple
dozen regular contributors period, there's not a lot o benefit --
generally the exact same people are on the SC as are in the other
groups. Unless you add someone from outside the project, in which case
you have different problems.
For a small project, I'd recommend (were I advising them) trying to
broaden their maintainers group to include non-code maintainers (like
docs and advocacy), which is usually a better approach when dealing with
a small pool.
Of course, it's really up to what the project wants.
> Fwiw, i don't believe in imposing or forcing things either. Apologies
> if I have given that impression.
We have to recognize that if we make an SC an alternative for other
governance requirements, that will result in an SC being imposed on a
few projects where the contributors otherwise don't want one.
BTW, in this thread I am speaking as a single member of SIG-Contributor
Strategy, and not for the whole committee. Other members of the SIG may
well disagree with me. I am also not speaking for Red Hat.
--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
|
|
|
