[TUHS] 3 essays on the ujnix legacy

[Theodore Tso via TUHS]

On Sat, Nov 01, 2025 at 12:45:14PM -0400, Clem Cole via TUHS wrote:
> Hrrmph. IMO: This is trying to fit the data over the graph you want.
> 
> I never agreed with ESR's model.  Linux was (and continues to be) a
> Cathedral.  It just has different master builders than BSD, SunOS, SVR4,
> VMS, and NT did.

Speaking as someone who was working on Linux from the beginning (I was
the first North American Linux kernel hacker, and the first US FTP
redistribution site for Linux was my desktop workstation at MIT (a
Vaxstation 3100 M38 running Ultrix), I never agreed with ESR's model
either, and I agree that Mr. Garcia's graph is also... not reflective
of reality.

First of all, ESR never spoke for the Linux community; certainly not
all of it.  And the whole "with enough eyeballs, all bugs are shallow"
might be true for some bugs, but it is *most* definitely not true for
all; especially in the kernel or multi-threaded programs.  More
generally, ESR's thesis was only really applicable or interesting for
projects in a relatively narrow band of complexity.  Projects which
are too small/simple aren't inteersting enough to have sufficient
gravitational pull to create a viable development community.  And
that's why there are a huge number of abandoned trivial projects in
github or sourceforge.  The plausibility of ESR's Cathedral and Bazaar
essay relies on survivorship bias.

The Cathedral model also falls apart for projects that grow beyond
that a certain complexity, when it requires a non-trivial of engineers
working full-time, or at least a significant percentage of their time
on the prjoect.  At that point, it's not just about a devloper wanting
to scratch their personal itch, but what their employer is willing to
fund --- since unless the developer is independently wealthy, most
developers do prefer to have food with their meals.

At that point, what gets attention is very strongly affected by what
one or more companies have a business case to fund.  An especially
talented project leader with Product Management team, can sometimes
stich together develop programs where different engineers working for
different companies can work together on different features that
benefit all of their employers.  But not everyone has that particular
combination of technical, social, and business skills.

Most people who try to create their models how "the open source
community" tend to forget both needs of the companies who fund
projects, and passion and commitments of the engineers in those
projects, many of whome sacrifice a certain amount of career or
financial prospects because they care about the commuity of which they
have become a part.  Many of these engineers have worked for more than
one company, and have known colleagues who have worked at multiple
company.  So these engineers tend to have a group loyalty which is not
precisely mapped to their employer; but at the same time, they know
that they need to add enough value to their employer so that (a) their
company stays in business, and (b) the company is willing to continue
to pay their salary.

It's complicated(tm).

On Sat, Nov 01, 2025 at 10:05:47AM -0700, Alan Coopersmith via TUHS wrote:
> On 11/1/25 07:42, A. P. Garcia via TUHS wrote:
> > Linux took the opposite path. Its ecosystem is messy, distributed, and
> > loud, a bazaar where competing ideas coexist until one wins by survival,
> > not decree. It doesn’t import technologies wholesale. It reinvents them
> > from first principles.
> > 
> > That’s why instead of adopting DTrace, Linux built eBPF, a programmable
> > virtual machine for tracing, networking, and observability. It’s more
> > complex, less elegant, but more adaptable.
> 
> Except of course, Linux built eBPF on top of BPF, a technology imported
> wholesale from BSD.  The difference between how Linux looked at Dtrace &
> BPF is one of license terms, not philosophy - they were willing to accept
> BSD-licensed imports, but not CDDL-licensed ones.

Absolutely.  Linux is quite willing to take ideas and code from
everywhere, so long as (a) it's good, and (b) the copyright license is
compatible.  For example, Read-Copy-Update (RCU) was a technique that
was created and patented by Sequent, and after IBM purchased Sequent,
IBM donated the patent to Linux, and had former Sequent engineers
(working for IBM's Linux Technology Center) implement RCU for Linux.

We'll take code and ideas from whereever we can get them. 

If Oracle hadn't outbid IBM to purchase Sun Microsystems (and some of
us believe that some executives at Sun leaked details of the
negotiation to the Wall Street Journal to draw competitors such as
Oracle to bid on Sun; certainly IBM had no incentive to leak what came
out in the press), it is very likely that I would have been on the
teams sent to Sun, and we would have tried to relicense DTrace and ZFS
from the CDDL to the GPL or some GPL-compatible license.

It's interesting to consider what the alternate history might have
been if we could have merged the best of the Solaris technology into
Linux, and if we could have welcomed some of the Solaris team into the
Linux community.  I certainly had nothing but respect for them, and I
always thought that they had been badly let down by their management
and sales teams.   They deserved better.

My personal belief is that Oracle's acquisition of Sun Microsystems,
while it may have represented a better deal for Sun's shareholders,
was ultimately a tragedy for the industry as a whole.

Cheers,

					- Ted