Message-ID: <20240118024922.GB1353741@mit.edu>
Date: Wed, 17 Jan 2024 21:49:22 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>, Greg KH <greg@...ah.com>,
        Mark Brown <broonie@...nel.org>, Neal Gompa <neal@...pa.dev>,
        Kees Cook <keescook@...omium.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
        Nikolai Kondrashov <spbnick@...il.com>,
        Philip Li <philip.li@...el.com>, Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [GIT PULL] bcachefs updates for 6.8

On Wed, Jan 17, 2024 at 08:03:35AM -0500, James Bottomley wrote:
> Actually, this is partly our fault.  Companies behave exactly like a
> selfish contributor does:
> 
> https://archive.fosdem.org/2020/schedule/event/selfish_contributor/
> 
> The question they ask is "if I'm putting money into it, what am I
> getting out of it".  If the answer to that is that it benefits
> everybody, it's basically charity  to the entity being asked (and not
> even properly tax deductible at that), which goes way back behind even
> real charitable donations (which at least have a publicity benefit) and
> you don't even get to speak to anyone about it when you go calling with
> the collecting tin.  If you can say it benefits these 5 tasks your
> current employees are doing, you might have a possible case for the
> engineering budget (you might get in the door but you'll still be
> queuing behind every in-plan budget item).  The best case is if you can
> demonstrate some useful for profit contribution it makes to the actual
> line of business (or better yet could be used to spawn a new line of
> business), so when you're asking for a tool, it has to be usable
> outside the narrow confines of the kernel and you need to be able to
> articulate why it's generally useful (git is a great example, it was
> designed to solve a kernel specific problem, but not it's in use pretty
> much everywhere source control is a thing).

I have on occasion tried to make the "it benefits the whole ecosystem"
argument, and that will work on the margins.  But it's a lot harder
when it's more than a full SWE-year's worth of investment, at least
more recently.  I *have* tried to get more test investment. with an
eye towards benefitting not just one company, but in a much more
general fasion ---- but multi-engineer projects are a very hard sell,
especially recently.  If Kent wants to impugn my leadership skills,
that's fine; I invite him to try and see if he can get SVP's cough up
the dough.  :-)

I've certainly had a lot more success with the "Business quid pro quo"
argument; fscrypt and fsverity was developed for Android and Chrome;
casefolding support benefited Android and Steam; ext4 fast commits was
targetted at cloud-based NFS and Samba serving, etc.

My conception of a successful open source maintainer includes a strong
aspect of a product manager whose job is to find product/market fit.
That is, I try to be a matchmaker between some feature that I've
wnated for my subsystem, and would benefit users, and a business case
that is sufficientlty compelling that a company is willing to fund the
engineering effort to make taht feature happen.  That companmy might
be one that signs my patcheck, or might be some other company.  For
special bonus points, if I can convince some other company to find a
good chunk of the engineering effort, and it *also* benefits the
company that pays my salary, that's a win-win that I can crow about at
performance review time.  :-)

> Somewhere between 2000 and now we seem to have lost our ability to
> frame the argument in the above terms, because the business quid pro
> quo argument was what got us money for stuff we needed and the Linux
> Foundation and the TAB formed, but we're not managing nearly as well
> now.  The environment has hardened against us (we're no longer the new
> shiny) but that's not the whole explanation.

There are a couple of dynamics going on here, I think.  When a company
is just starting to invest in open source, and it is the "new shiny"
it's a lot easier to make the pitch for big projects that are good for
everyone.  In the early days of the IBM Linux Technolgy Center, the
Linux SMP scalability effort, ltp, etc., were significantly funded by
the IBM LTC.  And in some cases, efforts which didn't make it
upstream, but which inspired the features to enter Linux (even if it
wasn't IBM code), such as in the case of the IBM's linux thread or
volume management, it was still considered a win by IBM management.

Unfortunately, this effect fades over time.  It's a lot easier to fund
multi-engineer projects which run for more than a year, when a company
is just starting out, and when it's still trying to attract upstream
developers, and it has a sizeable "investment" budget.  ("IBM will
invest a billion dollars in Linux").  But then in later years, the
VP's have to justify their budget, and so companies tend to become
more and more "selfish".  After all, that's how capitalism works ---
"think of the children^H^H^H^H^H^H^H shareholders!"

I suspect we can all think of companies beyond just IBM where this
dynamic is at play; I certainly can!

The economic cycle can also make a huge difference.  Things got harder
after the dot com imposiion; then things lossened up.  Howver,
post-COVID, we've seen multiple companies really become much more
focused on "how is this good for our company".  It has different names
at different companies, such as "year of efficiency" or "sharpening
our focus", but it often is accompanied with layoffs, and a general
tightening of budgets.  I don't think it's an accident that
maintainwer grumpiness has been higher than normal in the last year or
so.

	    	       	  	      	     	- Ted

Powered by blists - more mailing lists