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:   Thu, 22 Jun 2023 13:39:13 -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: <20230622173913.GA34229@mit.edu>
References: <20230620212502.GI286961@mit.edu>
 <5490402b-8b9f-f52d-3896-41090e639e51@linux-m68k.org>
 <2023062144-hefty-why-305d@gregkh>
 <04cd7204-cdee-c333-8815-57acbab82721@linux-m68k.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04cd7204-cdee-c333-8815-57acbab82721@linux-m68k.org>
Precedence: bulk

On Thu, Jun 22, 2023 at 05:02:10PM +1000, Finn Thain wrote:
> 
> You mentioned wasted resources. If you want to generate e-waste, remove 
> drivers from the kernel. If you want to prevent e-waste, add drivers for 
> obsolete hardware and then watch the user count climb from zero as devices 
> get pulled from drawers and dusted off.

You seem to making a lot of assumptions here, with no evidence to back
up your assertions.  The driver question is from twenty years ago, and
talks to SCSI cards using LVD (low-voltage diferential) SCSI 3 cables
(for 160 MB/s).  SCSI Disks from that era are typically 20GB to 30GB.
Compare that to modern SATA disks today that are 10-18 TB in size, and
SATA-3 transfers data at 600 MB/s.

So you are assuming (a) that people just "happen" to have ancient, 20
year old cards justlying around in drawers, (b) they have 20 year old
SCSI disks and SCSI cables that these cards would actually talk to,
and (c) they would think it would make sense from a power, space, and
cooling perspective to take this kind of antique storage solutions are
use it for actually storing data.

> Anyway, your reaction is an interesting example of strong feelings in the 
> community as to how contributed code should or should not be used. E.g. 
> some get upset if their code runs on weapons systems, others get upset if 
> the latest release might not run on suitable hardware in the immediate 
> future. Some add or remove licence terms according to their convictions.

Um, I don't even know where this came from.  In any case, the Linux
Kernel is licensed under the GPL2, which, like all Open Source
compliant licenses, does not distribute against fields of endeavor
(such as weapons systems, etc.)

As far as getting upset if the latest release doesn't run on "suitable
hardware", if they are upset they can submit a bug report, or better
yet, submit a patch to address the situation.  What people seem to
forget is that free software does not mean that people will fix your
software for your use case for free.  It means that *you* are free to
fix the software, or to pay someone to fix the software in question.

> If there was consensus, it might be feasible to give a formula for 
> "recognized usage" which could be quantified. From there we could create a 
> kind of heat map to show which commits, maintainers, processes, models, 
> modules etc. were the most "useful" within some time interval.

The best we have is we can see what users submit bug reports about
(especially, for example, when we discover that some driver was
accidentally broken a few years ago due to the need to upgrade code to
use newer API's as we improve and refactor code, and no one has
complained about the driver being used --- that's a good hint that no
one cares), and what individuals and companies choose to spend time
working to improve certain parts of the kernel.  If code is under
active maintenance, then it's worth *someone's* time to keep
maintained.

And of course, if remove a driver because it is unmaintained and is
for obsolete hardware, if someone shows up saying (a) they care about
that driver, and (b) they are willing to volunteer to maintain the
driver, or are willing to pay someone to maintain the driver, and they
have contracted with XYZ developer working for ABC company, then it's
super simple to revert the driver removal.  It is, after all, only a
"git revert" away.

I do have to concur with Greg that relying on this as way to get new
people to be work on Linux kernel is a *terrible* idea.  The number of
people who are interested in retro-computing is quite small, in my
experience.

Cheers,

					- Ted