Re: [PATCH] Documentation: Linux Contribution Maturity Model and the wider community

[Finn Thain]

On Mon, 19 Jun 2023, Theodore Ts'o 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).
> 
> So from a historical/factual basis, this is not true.  It was *not* 
> based on the Open Source Maturity Model; in fact, as the principal 
> author of this document, I wasn't even aware of the OMM when I wrote it.  
> The general framework of Maturity Models[1] is a very long one, and goes 
> back well beyond Dececmber 2022, which is when the folks in the banking 
> sector launched the OMM[2].
> 
> [1] https://en.wikipedia.org/wiki/Maturity_model
> [2] https://www.finos.org/blog/open-source-maturity-model-launch
> 

Thanks for that background, and thanks for your work on the Linux model. I 
appreciate the basic aim of the Linux model though I am highly skeptical 
of the relevance of a top-down goal-oriented methodology to a bottom-up 
compromise-oriented collaborative effort.

With regard to that mismatch, though somewhat off-topic, I'll note that 
the Linux model has departed quite a distance from the CMMI. E.g. CMMI 
level 5 is about continuous improvement, whereas Linux level 5 is 
basically level 4 "only louder". In the CMMI, the elements that make up 
the lower levels are strictly required by those of the upper levels; so 
it's not a question of degree but necessity.

> The reason why the language in the Linux Contribution Maturity Model 
> (LCMM) focused on companies was that was where the problem was perceived 
> to be.  That is, the *vast* majority of Linux Kernel contributors work 
> at companies, and because of many companys' focus on reducing costs and 
> increasing profits of their products which are part of the Linux kernel 
> ecosystem, some of them enagage in anti-patterns which are not healthy 
> either for their own role in the Linux Kernel ecosystem, and for the 
> Linux Kernel ecosystem at large.
> 
> For example, if you look at the 6.3 contribution report[3], you'll see
> that by changesets (git commits), 85.4% of the contributions came from
> companies, 6.6% were unknown, 4.8% were "None" (e.g.,
> hobbists/students), and 1.1% were from the Linux Foundation.
> 
> [3] https://lwn.net/Articles/929582/
> 
> In actual practice, we get *very* few commits from non-profit 
> organizations such as, say, the Mozilla Foundation, the Eclipse 
> Foundation, or even community distributions such as Debian or Arch. And 
> so the concerns around software engineers not getting the permission and 
> encourage they need so they can contribute to the Linux kernel community 
> at large, is primarily coming from companies.  The only non-profit 
> organization that even shows up at the contribution reports is the Linux 
> Foundation, and I'm pretty confident in how enlightened the LF 
> management vis-a-vis kernel contribution.  :-)
> 

I suspect that counting commits may be the wrong metric (I can think of 
better ones). But if that's what we have, the lack of commits from 
non-profit organizations is a situation that might actually be improved by 
changes like the ones I'm advocating.

> As far as individuals are concerned, things like performance reviews, 
> the ability for overly paranoid corporate Corporate General Counsel not 
> allowing their engineers from contributing to Open Source (in general) 
> and the Linux Kernel (in particular), yes, those things aren't really 
> applicable.  But again, there is a specific problem that we are trying 
> to solve, and it's not with individual contriduals.
> 
> > 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'm not sure how this document would "hinder collaboration" with 
> non-profit organizations and individuals.  Could you say more about your 
> concern regarding how this undesireable outcome would happen in 
> practice?
> 

I believe that I've now addressed this in my message to Greg.

> I'm not against making using wording which is more general, such as 
> perhaps "companies and organizations" instead of "companies", but it's 
> important that we don't dilute the message the primary audience --- 
> which is pointed-haired management types, who are familiar with the 
> Maturity Model framework, who are *primarily* working at for-profit 
> companies, and who could make it easier for those Linux developers whose 
> day job involves Linux kernel development.
> 

If employers are going to make those day jobs easier, IMHO it will be quid 
pro quo or not at all. That's why I am wary of bias.