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;
Date:   Mon, 19 Jun 2023 15:42:16 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Finn Thain <fthain@linux-m68k.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jonathan Corbet <corbet@lwn.net>,
        tech-board-discuss@lists.linux-foundation.org,
        Kees Cook <keescook@chromium.org>,
        Dan Williams <dan.j.williams@intel.com>,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation: Linux Contribution Maturity Model and the
 wider community
Message-ID: <20230619194216.GB286961@mit.edu>
References: <cd1786eadd1ff05d9ca053b72eb5f06ceb0c470d.1687167717.git.fthain@linux-m68k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cd1786eadd1ff05d9ca053b72eb5f06ceb0c470d.1687167717.git.fthain@linux-m68k.org>
Precedence: bulk

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