[TUHS] 3 essays on the ujnix legacy

[Theodore Tso via TUHS]

On Sat, Nov 01, 2025 at 08:47:24PM -0600, Warner Losh wrote:
> Indeed. At times, though, part of what it takes to get good code into the
> tree has an element of politics about it. It's another aspect of open
> source ESR's model fails to capture.

Any time you have people involved, there will always be politics.  But
one of the reasons why it can be especially challenging to get "good
code" into a project is because it's not just about the source code in
isolation.  It's also about the team behind the source code.

Unfortunately, the Linux kernel code has been plagued by drive by code
submissions.  Unfortunately, a lot of compaies have wanted to get code
into the kernel --- and then disappear.  If users then start to depend
on the code, and the original code submitters have disappeared,
perhaps because their company has reassigned the team to next two or
three generation mobile handsets, then the open source community is
left holding the bag.

This is why people who have a known track record are given more
latitude; people who are trusted that they will stick around, even if
they need to use their own personal time to keep the code mintained.
That's why unknown deevlopers might be required to wait until their
code is code to perfect before being integrated, both because if they
*do* disappear, it won't be that disastrous, and because that way
people can be more comfortable that their personal (not just
corporate) dedication to their code base is keep them around even if
they get laid off or reassigned.

Another issue is when the code requires massive change outside of the
subsystem.  I've heard ZFS (at least when it was first developed for
Solaris) described as not exactly a file system, but a massive memory
management subsystem with one hell of a backing store.  If the code
require changes in other subsystems, there will of course need to be a
lot of negotiation, since the maintainers of the adjacent subsystems
would have to support the new abstractions, and in some cases, the new
file system (cough, *bcachefs* cough) would have put entirely new
demands on the subsystem --- and of course, the core developers of
that new subsystem often believe their needs are more important anyone
elses', including other file systems....

And finally, there if the developers of that new subsystem are
sufficiently toxic, that a large number of maintainers in adjacent
subsystems start refusing to attend in person because that person is
an arrogate S.O.B., denigrating other people's code, compentence, and
paternity, that subsystem might need to be ejected from the code base
after it had been accepted.  That's always painful, full of drama, and
while it might be good for view counts on various YouTube chanels, and
clicks on Phoronix, it's better if that can be avoided.  And that's
can be another reason why a project might be hesitant to accept code
contribution sight unseen.  It's *never* just about the source code.

I will say that, speaing personally, there were attempts to recriut me
into working on GNU HURD and NetBSD in the early 1990's.  However,
there were at least one or two people in the Cambridge, Massachusetts
that were *actively* toxic, or otherwise unpleasant to work with, that
this was never an option for me.  So it's always interesting to hear
people talk about the supposed rough edges of Linus Torvalds; compared
to some of the personalities that I've experienced, and broken bread
with, I would prefer to work with Linus any day of the week.


On Sun, Nov 02, 2025 at 12:25:16AM -0600, Arnold Robbins via TUHS wrote:
> Warner Losh <imp at bsdimp.com> wrote:
> 
> > As things grew, more and more people got paid. Even though the passionate
> > folks got money or patches or both.
> 
> I never got a job doing Free Software, even though I tried a time
> or two. Maybe once or twice (in 38 years!) someone paid me to do something
> on gawk for them.  't'would have been nice to have made a living
> with this passion.

This is another way in which people who opine about winning Open
Source strategies are very much influenced by survivorship bias.
Projects like GCC and the Linux Kernel have enough surplus value that
companies who invest a relatively small amount of information can see
multiple times the initial investment.  That's why Cygnus Support was
often able to sell the same GCC improvement to multiple companies, and
then only develop the feature once.  But that's not true for all
projects.

Even if the project is super important, such as say, for example, xz
or openssl, even if many companies depend on the software component,
if there aren't potential improvements that would result in return on
investment in terms of something that a company could sell as a
product or service --- most companies won't invest in the open source
project for its own sake.  This why I stress that it's extremely
useful for an open source maintainer to have product management skills
as part of their toolset.

And it's not just xz, but it's also projects like.... gawk, bash,
emacs, etc.  So just because a particular model works for gcc and the
Linux kernel, we should be careful not to assume that it's just
because of the particular development practices of that component.  It
very might be that the projects that have been extremely successful
were just outliers, based on where they fit inside the ecosystem, and
the business leverage that might have.

							- Ted