Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1a631328115eaecbfebf8e435b9224bf2ff248af.camel@HansenPartnership.com>
Subject: Re: [Tech-board-discuss] [PATCH] Documentation: Linux Contribution
 Maturity Model and the wider community
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Finn Thain <fthain@linux-m68k.org>
Cc:     linux-doc@vger.kernel.org,
        tech-board-discuss@lists.linux-foundation.org,
        gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Date:   Tue, 20 Jun 2023 18:52:42 -0400
In-Reply-To: <7fef2bbb-4c5a-52b8-8e85-400a8fbb8786@linux-m68k.org>
References: <e78eef83a50a558aae765baafcf9c571788a02a5.camel@HansenPartnership.com>
         <7fef2bbb-4c5a-52b8-8e85-400a8fbb8786@linux-m68k.org>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, 2023-06-20 at 13:50 +1000, Finn Thain wrote:
> On Mon, 19 Jun 2023, James Bottomley wrote:
> 
> > On Mon, Jun 19, 2023 at 07:41:57PM +1000, Finn Thain wrote:
> > > The Linux Contribution Maturity Model methodology is notionally
> > > based on the Open source Maturity Model (OMM) which was in turn
> > > based on the Capability Maturity Model Integration (CMMI).
> > > 
> > > According to Petrinja et al., the goal of the OMM was to extend
> > > the  CMMI so as to be useful both for companies and for
> > > communities [1][2].   However, the Linux Contribution Maturity
> > > Model considers only companies and businesses.
> > 
> > That's not a correct characterization.  The model is designed to
> > measure and be useful to businesses, but it definitely considers
> > the community because it's progress is built around being more
> > useful to and working more effectively with the community.
> > 
> 
> You're right, the characterization I gave does exaggerate the bias. I
> shall moderate that if I resubmit the patch.
> 
> > > This patch addresses this bias as it could hinder collaboration
> > > with  not-for-profit organisations and individuals, which would
> > > be a loss to  any stakeholder.
> > 
> > I don't really think changing 'Businesses' to 'Organizations'
> > entirely addresses what you claim is the bias because individuals
> > would still be excluded from the term 'Organizations'.  I also
> > don't really think it matters.  Part of the reason this whole thing
> > doesn't matter is that sometimes people do know who a contributor
> > they work with works for, but most of the time they don't.
> 
> This is not just about patches, it's also about incentives and
> influence.

I mentioned contributor interaction, which covers influence.  I'm not
sure what you mean by incentives or how it is covered by changing
Businesses -> Organizations.

> 
> > If you really want this to be inclusive, you could change it to
> > 'other contributors' but I'm still not sure it's worth it.
> > 
> > > 
> > > Level 5 is amended to remove the invitation to exercise the same
> > > bias i.e. employees rewarded indirectly by other companies.
> > 
> > I also wouldn't remove the bit about seeking upstream feedback on
> > employees; I know from personal experience it happens a lot.
> > 
> 
> If it happens a lot already, why compel employers to seek it?

Because it's a sign of open source maturity on behalf of a company. 
Lots do it, but lots don't.  By putting it in the maturity model we
want to encourage it.

> It's worth noting that the model compels employers to seek "community
> member feedback" which is not the same as the "upstream feedback"
> that you describe.

It isn't?  How else does a community express itself except by its
agents which are ipso facto community members?  Not all community
members have identical opinions, but if you talk to several you'll get
a good sense of community feedback.

James