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.
