|
Re: "Steering committee" discussion
Stefano Maffulli <stefano.maffulli@...>
On Thu, Oct 1, 2020 at 11:17 AM Alexis Richardson <alexis@...> wrote: Graduation is not meant to be some kind of super impossible bar. My argument is that it shouldn't be intended as a final destination.
How can you not? The power balance is shifted towards those who produce the software. The ones who make the software are natural monopolists, and generally they operate in winner-take-all markets. It's one of the fundamentals of open source to rebalance that power between those who produce and those who consume, by enabling the consumer to be a producer, breaking that barrier. I know that for some software the collaboration aspect is less important though (the monopolistic threat is non-existent or has limited impact). That's why I'm suggesting to explore the software maturity model rather than a simple step like it is now with "graduation". -- Stefano Maffulli Sr. Dir. Digital and Community Marketing | stefano.maffulli@...
|
|
|
|
Re: "Steering committee" discussion
alexis richardson
Graduation is not meant to be some kind of super impossible bar. It
should be pretty easy to go from successful Incubation to Graduation, provided social conditions are met. Let's not assume that all "collaboration" must be between multiple sellers of the same software. On Thu, Oct 1, 2020 at 6:54 PM Stefano Maffulli via lists.cncf.io <stefano.maffulli=scality.com@...> wrote:
|
|
|
|
Re: [VOTE] Rook Graduation
Ken Owens
+1 NB
|
|
|
|
Re: "Steering committee" discussion
Stefano Maffulli <stefano.maffulli@...>
On Tue, Sep 29, 2020 at 10:43 AM Liz Rice <liz@...> wrote:
I think it's a serious mistake to de-emphasize diversity of employment among project maintainers in a consortium that is all about collaboration. I'd love to explore other venues before throwing the towel. Maybe the problem is with the word "graduation" and the way it's portrayed as a destination, rather than one of the criteria to assess longevity and community control of the roadmap. Pieces of the conversation from Matt and Alexis hint at a source of misinterpretation of what "graduation" means. The fact that CNCF is showing a linear progress from incubation to graduation maybe is contributing to the confusion. Alexis says: On Wed, Sep 30, 2020 at 4:27 AM alexis richardson <alexis@...> wrote: CNCF Incubation tests for production use and technical DD. It has a Sustainability, governance and production use are correlated but quite independent variables. IIRC the Eclipse and Apache Foundation played have experience exposing a series of indicators in a maturity model. Some adopters of software may have more tolerance than others for things like "employment diversity of maintainers". How about rethinking the flow from incubation to graduation not as a ladder but rather as criteria for a decision-support matrix? /stef
|
|
|
|
Re: [VOTE] Rook Graduation
Bhaarat Sharma
From: cncf-toc@... <cncf-toc@...> on behalf of Barak Stout via lists.cncf.io <bstout=goraft.tech@...>
Sent: Thursday, October 1, 2020 1:48 PM To: Kevin.Ryan@... <Kevin.Ryan@...> Cc: sheng@... <sheng@...>; gamanjie@... <gamanjie@...>; aprokharchyk@... <aprokharchyk@...>; Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...> Subject: Re: [cncf-toc] [VOTE] Rook Graduation +1 NB !
Barak Stout
|
|
|
|
Re: [VOTE] Rook Graduation
Barak Stout
+1 NB !
toggle quoted messageShow quoted text
Barak Stout
|
|
|
|
Re: [VOTE] Rook Graduation
Kevin.Ryan@...
+1 !!
K
From: cncf-toc@... <cncf-toc@...>
On Behalf Of Sheng Liang via lists.cncf.io
Sent: Thursday, October 1, 2020 10:44 AM To: gamanjie@...; aprokharchyk@... Cc: Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...> Subject: Re: [cncf-toc] [VOTE] Rook Graduation
+1 binding
From: <cncf-toc@...> on behalf of "Katie Gamanji via lists.cncf.io" <gamanjie=gmail.com@...>
+1 binding Great addition to the graduated suite of CNCF projects!
On Tue, Aug 25, 2020 at 7:35 PM Alena Prokharchyk via lists.cncf.io <aprokharchyk=apple.com@...> wrote:
|
|
|
|
Re: [VOTE] Rook Graduation
Sheng Liang <sheng@...>
+1 binding
From: <cncf-toc@...> on behalf of "Katie Gamanji via lists.cncf.io" <gamanjie=gmail.com@...>
+1 binding Great addition to the graduated suite of CNCF projects!
On Tue, Aug 25, 2020 at 7:35 PM Alena Prokharchyk via
lists.cncf.io <aprokharchyk=apple.com@...> wrote:
|
|
|
|
Re: [VOTE] Open Policy Agent from incubating to graduated
Johan Tordsson
+1 NB Johan Tordsson Den 2020-09-30 kl. 18:00, skrev Amye
Scavarda Perrin:
-- Johan Tordsson, PhD CTO & Co-founder www.elastisys.com
|
|
|
|
Re: [VOTE] Open Policy Agent from incubating to graduated
Jeremy Rickard
+1 NB
On Wed, Sep 30, 2020 at 10:02 AM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|
|
|
Re: [VOTE] Open Policy Agent from incubating to graduated
Magno Logan
On Wed, Sep 30, 2020 at 12:11 PM Emily Fox <themoxiefoxatwork@...> wrote:
|
|
|
|
Re: "Steering committee" discussion
On Wed, Sep 30, 2020 at 04:27 AM, alexis richardson wrote:
It may just be me, but there seems to be a lot of focus on the possibility of "bad actors" and mitigating the possible harm that they can cause. When we build tools like surveys, questionnaires, and templates to help us in evaluative processes, we need to be aware of biases that they can introduce or reinforce. These biases can be both beneficial and harmful. If you ask too much about bad actors, it can cause or introduce a perception that open-source has a pervasive problem with bad actors, when in fact (based only on my personal experience) it is a very rare circumstance. I think each of those rare circumstances are exceptionally complex, and addressing the problem will likely require a set of unique corrective actions, potentially in multiple areas. There's no magic solution to fixing a dysfunctional community. In terms of attracting contributors: complex topic, but the SC canImplementing the SC concept may be one way that a project community builds to be a healthy, well functioning community. I'm not aware of good examples of how this has been demonstrated in practice, and I think that the TOC should expand the areas where evaluating what is Perception vs Reality beyond the small mention in the DD review template [1] that exists today * Perception vs Reality: Is there lots of buzz, but the software is flaky/untested/unused? Does it have a bad reputation for some flaw that has already been addressed? Reputation/perception is usually rooted in some kind of reality about how things are functioning in practice, like was the case in my Xen project example. You can check all the boxes for CNCF graduation and still get off course. The exceptionally rare (as far as I'm aware) circumstances where people want to capitalize on the common goodwill and brand equity of Open Source and the CNCF (along with all the valuable benefits and services that CNCF is able to provide to its member projects) without being committed to building an inclusive, well functioning, non-discriminatory community and ecosystem won't be blocked by a multi-organization contributor requirement, a steering committee, a longevity plan, a contributor ladder, or a quarterly roadmap. --msw [1] https://github.com/cncf/toc/blob/master/process/dd-review-template.md#users
|
|
|
|
Re: [VOTE] Open Policy Agent from incubating to graduated
+1 - Emily Fox @TheMoxieFox (personal handle)
On Wed, 30 Sep 2020, 12:03 Ken Owens, <kenchristineowens@...> wrote:
|
|
|
|
Re: [VOTE] Open Policy Agent from incubating to graduated
Ken Owens
+1 nb
On Wed, Sep 30, 2020 at 11:01 AM Amye Scavarda Perrin <ascavarda@...> wrote:
|
|
|
|
[VOTE] Open Policy Agent from incubating to graduated
Amye Scavarda Perrin
The Open Policy Agent project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520) The due diligence document can be found here: https://docs.google.com/document/d/19M5fTpe57rQIMNxawRl5wSWvJUapuzY-CkV4O5pvieU/edit Brendan Burns has called for public comment: https://lists.cncf.io/g/cncf-toc/message/5281 Please vote (+1/0/-1) by replying to this thread. Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support! Amye Scavarda Perrin | Program Manager | amye@...
|
|
|
|
Re: "Steering committee" discussion
alexis richardson
Matt
toggle quoted messageShow quoted text
Thanks. A few quick comments (topline for speed). CNCF Incubation tests for production use and technical DD. It has a high bar. Graduation is oriented towards sustainability including some of the matters you touch on below. Graduation is more about sustainability and governance, than about production use. Those are all related in the end of course. I am a big fan of regular Q&A surveys with maintainers and users "and more". They are a good way to assess health, eg "do you think the project will make more progress in the next 12mo than in the last 12mo? why", and "are you aware of any bad actors". In terms of attracting contributors: complex topic, but the SC can help by being a lighthouse showing many ways to get involved, by showcasing what direction and features need building, and by having clear contributor paths. a
On Wed, Sep 30, 2020 at 8:16 AM Matt Wilson <msw@...> wrote:
|
|
|
|
Re: "Steering committee" discussion
On Tue, Sep 29, 2020 at 11:05 AM, Liz Rice wrote:
The start of your original email was clear, but the addition of the word "plan" did make it a bit less so. Thank you for the clarification! I've taken the liberty to re-format the thread below to inline replies from earlier messages. I hope that the context doesn't change the meaning of any quoted text from others. On Tue, 29 Sep 2020 at 18:52, Alexis Richardson <alexis@...> wrote:I (speaking only for myself) would like to understand the functionOn Tue, Sep 29, 2020 at 10:48 AM, Bob Wise (AWS) wrote: better. As I understand it, CNCF graduation is a signal that the project has attained a certain level of "maturity". This is like a "Good Housekeeping Seal of Approval" that gives users/customers a signal that they can confidently adopt the software. Maintaining a high quality bar for graduation is important in building the ongoing strong brand of the CNCF, which I think plays a key role in supporting beneficial ecosystems that are part of building and sustaining open-source software. However, I currently view graduation milestones with the same kind of skepticism of some engineering "qualification" practices I've seen, where a product or service is very intensely tested before it is released using tools and procedures that are not integrated into a continuous automated testing system. "Qualification" around a major milestone event gives you a snapshot-in-time view of quality, but modern software changes more rapidly, so you need to be qualifying continuously. So too open-source projects need to change. Communities evolve. Practices change and adapt. Communities that are not able to change and evolve are more likely to become dysfunctional. Rather than obsessing about if a vendor's interest is holding back features, I think you should investigate how contentious decisions are made, and how disputes are resolved among stakeholders. The roadmap/features is only one thing that a development community, or other stakeholders, might disagree about. Liz clarified (above) that a proposed concern is to require functional community control over the roadmap. I would shorten it: require a functional community (in contrast to a dysfunctional community). I think you (the CNCF TOC by applying the graduation seal-of-approval) need to understand what community processes look like in practice, and if is a healthy dynamic that aligns well with what we've learned so far about building sustainable open-source software development communities and commercial ecosystems. That'd be a hard job that I do not envy. One tool that can help assess how well a community is functioning is a free-form response template. But more deeply than how is it functioning, a response template can help trigger, and demonstrate, more mindfulness in community architecture. One I like is included in Python PIP-8002, https://www.python.org/dev/peps/pep-8002/#annex-1-template-questions I think that a well functioning community is one that has a process that enables the evolution of its policies and practices over time. I like that this template asks these questions: 3. How do you like the process? * Which parts work well? * Which parts could work better? * When it doesn't work well, how does it look like? * What would you change if it were only up to you? [...] 5. Process evolution * How did this process evolve historically? * How can it be changed in the future? The SC model could generateFrom my perspective, I care very little about any of these things (though I may not understand what you actually mean). An open-source license is my ultimate contingency plan. What I'm looking for otherwise is a strong, welcoming, self-governing community, along with committed companies participating in a growing commercial ecosystem around the software. Yes, there are a number of reasons why a project may not attractProjects struggling to get maintainers when the owning entity isThis mostly does not happen. Although due to some bad actors, it can. contributors. There are a number of case studies where the overall sentiment and perception was that an open-source project was too closely held by a single commercial entity. Sometimes that has practical impacts in the sustainability of the ecosystem that builds, maintains, and supports the software. In my opinion (biased from my experience and perspective), a key case study in Linux Foundation history is the Xen project. We are fortunate that the late Lars Kurth documented this case study well, see http://slideshare.net/xen_com_mgr/lceu13-xen-project-lessons-learned. When we formed the Xen Project as a Linux Foundation collaborative project, there were a number of _symptoms_ that indicated that the community, the project, and the ecosystem around it were trending toward unhealthy. This was a sustainability concern for many stakeholders, including me. Forming the Xen Project was only _part_ of addressing the problem. People who were most familiar with the Xen community were aware of some the underlying causes of these symptoms, which were reflected in a larger "image" problem for the project. Over many years the project and its community gained a reputation of being difficult to work with, inwardly focused, and not collaborative with other significant parts of the open-source software ecosystem on which Xen was built--namely Linux and QEMU, both of which were extensively modified and maintained as separate "out of tree / not upstream" development branches for many years. Some would call the software "forked". At the time we formed the Xen Project at LF, it already had core maintainers for multiple organizations, despite having earned a reputation of being too closely held by Citrix. There are examples of healthy projects with a small number of people from one organization with "commit bit" access to the canonical repository, and also examples of unhealthy projects that have people from multiple organizations with "commit bit" access. So, I generally agree that the "multi-organization" criterion is not a good one on its own. It _might_ be a symptom that there's something else going on that deserves additional investigation. So, TL;DR? Building a sustainable community is complex. The things that may be the actual underlying risk factors in sustainability/longevity may not be obvious in a surface level inspection. A plan is no guarantee of future success. I think it takes applying mindful, intentional community-building practices and a willingness to adapt. --msw
|
|
|
|
Re: "Steering committee" discussion
Josh Berkus
On 9/29/20 10:43 AM, Liz Rice wrote:
1. longevity of the project (in the event that a vendor is acquired orWe talked about requiring three things from projects reaching Graduated level: 1. A sustainability/longevity plan 2. A process for community feedback on the roadmap 3. Requiring "contributor ladder" process & documentation If these three things are things that the TOC plans to require, SIG-Contributor Strategy can work on writing guidance for them. The "longevity" portion will require quite a bit of work, though, because there's no real precedent for this that I know of. -- -- Josh Berkus Kubernetes Community Red Hat OSPO
|
|
|
|
Re: FOSS Governance Library
Paris Pittman
we have been building this for our research and references for the guidance we are creating. the foss governance library is an amazing resource.
On Tue, Sep 29, 2020 at 12:42 PM Chris Aniszczyk <caniszczyk@...> wrote:
|
|
|
|
Re: FOSS Governance Library
Nothing outside of the PDF, but it's been on the TODO list to convert it to markdown and put it somewhere. I'll look at getting this done though if people find it useful.
On Tue, Sep 29, 2020 at 2:39 PM Josh Berkus <jberkus@...> wrote: On 9/29/20 9:45 AM, Chris Aniszczyk wrote: --
Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
