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 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. :-) 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'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. Cheers, - Ted
