[TUHS] 3 essays on the ujnix legacy

[TUHS] 3 essays on the ujnix legacy

[A. P. Garcia via TUHS]

I wanted to share three brief essays I wrote on LinkedIn. I hope it's
appropriate to share them here.

The Cathedral, the Bazaar, and the Marketplace

People sometimes say Linux suffers from a “Not Invented Here” problem. They
pnt to technologies like DTrace and ZFS — born in Solaris, admired by
Linux, but never fully adopted. FreeBSD, macOS, even Windows embraced
DTrace. Linux went its own way, creating eBPF and Btrfs instead.

At first glance, it looks like stubbornness. But look closer, and you see a
deeper truth about how different systems and their communities evolve.

The Cathedral: Solaris and the Dream of Perfection

Solaris and the BSDs were cathedral projects: elegant, coherent, and built
to last. Their philosophy was architectural: design it perfectly once, and
maintain it forever. That stability made masterpieces like ZFS and DTrace
possible.

Cathedrals are slow to change. They preserve beauty, not momentum.

The Bazaar: Linux and the Art of Reinvention

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.

This isn’t “Not Invented Here.” It’s “Invented Anew, Every Time.” It’s a
culture that prizes autonomy over elegance, vitality over symmetry.

The Marketplace: Microsoft and the Pragmatism of Scale

Then there’s Microsoft, once the cathedral’s rival, now a marketplace of
its own. Its genius has never been invention but absorption: taking good
ideas from elsewhere and integrating them into something cohesive.

PowerShell drew from Unix shells and .NET reflection. NTFS inherited DNA
from VMS. Today, Microsoft ships Linux inside Windows, Edge on Chromium,
and hosts GitHub — the beating heart of open source.

Yet the uptake of Microsoft’s own open-source tools among Linux users has
been modest. You can install PowerShell on Ubuntu or .NET on Debian, but
few do. Not because the tools are bad, but because open source isn’t just a
license, it’s a language.

Microsoft’s tools still speak in the idioms of Windows. They solve problems
that feel foreign in Unix hands. You can open-source the code, but you
can’t open-source the culture overnight.

Three Philosophies, One Ecosystem

-  Solaris / BSD: Design it perfectly, then preserve it.
-  Linux: Rebuild it constantly, and let it evolve.
-  Microsoft: Adopt it broadly, and make it familiar.

Each model has its genius, and its limits. Solaris gave us clarity but
stagnated. Linux gave us chaos but endurance. Microsoft gave us cohesion,
and at times, a touch of the blasé.

But in 2025, the walls between them have thinned. Linux runs in Azure. eBPF
runs on Windows. Solaris’s spirit lives on in every file system that
promises self-healing storage.

The world has evolved since ESR first told us about the Cathedral and the
Bazaar.



Before the Bazaar
The lineage of open collaboration from Bell Labs to the AI Lab to Linux.

In the early days, Unix was a community. Not a corporate product or a
stealth research project, but a loose fellowship of programmers trading
code through tape reels. Thompson and Ritchie gave it away for a nominal
fee, and universities adopted it because it was small, elegant, and
instructional. The code moved by post and by modem; ideas moved even
faster. Every new utility carried someone’s initials in the source
comments, a quiet signature of a gift freely given.

Meanwhile, at MIT, another tribe of hackers lived by a similar rhythm,
though they worked on different machines. Their home was the AI Lab, and
their world ran on PDP-10s under ITS, a timesharing system they had shaped
to their own image. It was a place where curiosity outranked hierarchy,
where anyone could read or patch any program, and where a clever hack was
its own kind of currency.

For a while, both cultures thrived on openness. But while the Unix world
diffused into hundreds of campuses and companies, the AI Lab was a more
fragile ecosystem. When the hardware aged and the market closed in, that
ecosystem broke. What had been an everyday freedom, editing each other’s
code, suddenly became trespass.

The lab was dying, and everyone could feel it. The old PDP-10s hummed like
relics, and the laughter that used to spill from the terminals had thinned
to the occasional keystroke. A printer driver had been locked away behind a
corporate contract; a colleague left for a company that paid him to keep
quiet. The code that once bound the room together was vanishing into sealed
disks and nondisclosure.

Richard Matthew Stallman stood in the middle of that silence and made a
decision that would outlast the machines. If the lab was gone, he would
build another. One not bound by walls or employers. One where the source
itself would be the meeting place.

For all the talk of freedom you may have heard from rms, GNU wasn’t born
from utopia; it was born from grief. It was his hope that a community could
be written back into existence, line by line.

Before him, long before the Internet turned collaboration into a torrent,
there was a room at Bell Labs Center 1127. That was the first bazaar:
quiet, fluorescent, lined with a PDP-11 and teletype terminals. The people
who used Unix were the same ones who built it.

When Ken Thompson or Dennis Ritchie wrote a tool, it wasn’t for customers;
it was for the colleague one door down. Brian Kernighan would stop by with
an idea for a text filter. Joe Ossanna needed better document formatting.
Doug McIlroy wanted to teach the machines how to speak in little,
composable verbs. By lunchtime, half the lab was using the new tool, and by
evening, someone else had improved it.

The same impulse stretches now across continents instead of offices. The
bazaar simply scaled up the Unix room: at Bell Labs, at the AI Lab at MIT,
and now in your every git pull.



The Rhetoric of the Bazaar

How Eric S. Raymond sold open source as a process improvement.

When The Cathedral and the Bazaar appeared in the late 1990s, it read like
field notes from a new frontier. Raymond seemed to be explaining why
Linux’s sprawling, volunteer army had outpaced corporate software. But the
essay was more than observation. It was persuasion dressed as ethnography,
a cultural revolution disguised as engineering advice.

The narrow slogan

“Given enough eyeballs, all bugs are shallow.”

The line became gospel. Short, clever, and apparently scientific, it
reduced open collaboration to a form of distributed debugging. Many eyes,
fewer bugs. Collaboration, in this light, was not a creative act but a
safety net.

It was a perfect slogan for the audience he needed. Managers could measure
defects. Executives could chart release velocity. You could sell that to a
boardroom. “Open source fixes bugs faster” sounds like efficiency; “open
source changes how humans organize” sounds like insurrection.

The trade

So Raymond made a trade. He gave up the movement’s breadth for credibility.
The grand claim, that transparency breeds better design and deeper
understanding, became a smaller, safer one about quality assurance. And in
doing so, he made the revolution sound replicable.

It worked. Netscape opened its code. “Open source” replaced “free
software.” Corporations joined the bazaar without ever entering the
community. They adopted the method, not the meaning.

The diary as proof

Even the long detour through fetchmail fits the pattern. It reads like
autobiography, but it’s really evidence: if this model works for me, it can
work for you. The diary is a case study, not merely an exposition. Raymond
wasn’t just documenting open development. He was demonstrating it.

The legacy

The quiet compromise of the essay is that by focusing on bugs instead of
ideology, Raymond made the unfamiliar familiar. He turned rebellion into
best practice. And in doing so, he helped open source escape the lab and
enter the market—but also stripped it of its soul.

It split the movement. The free software camp clung to ethics; the open
source camp to efficiency. Each accused the other of missing the point.

Perhaps both did.

The real power of the bazaar wasn’t in its license or its process. It was
in the way it made people feel seen, the way a thousand strangers could
build something together and call it theirs. That’s what made the terminals
hum and the mailing lists sing.

The real birth wasn’t a method or a manifesto. It was a new community, just
another example of what happens when people share a common need and work
together to make it happen. And it didn’t belong to either banner. It
belonged to everyone who showed up.

[TUHS] Re: 3 essays on the ujnix legacy

[Larry McVoy via TUHS]

These are definitely rose colored glasses versions of history.
I'd argue that SunOS was far closer to a perfect kernel than Solaris.
Solaris wanted to have that title but never did.  It tried but the soul
of the OS sort of left when they switched to System 5.

As for ZFS, I'm the guy that hired Bonwick away from Stanford to
come to Sun and I'm personal friends with Bill Moore.  ZFS is a giant
disapointment to me.  Why?  It undid _years_ of work to have a reasonable
architecture for the page cache.  In BSD, before mmap() came along,
there was just the buffer cache, blocks, inodes, directories were all
in the buffer cache.  mmap() introduced the concept of a page cache,
similar to blocks but not quite the same.  Blocks were read/write
and pages were mmap().  This model sucked because you could have two
copies of a page, one in the page cache and one in the buffer cache.
Creates the classic cache coherency problem, I can stuff in an mmap()ed
page and someone else can change the buffer cache copy of the page at
the same time.

Sun didn't like that model so they did a shit ton of work to redo the
VM system and the I/O system so that there was just one copy of the 
truth: the page cache.  Read/write/mmap all worked on the same pages.
The buffer cache stuck around only for inodes and directories.

ZFS kind of messed with the model because they allowed for compressed
files.  All of the rest of the system knew the size of page.  For example,
in the block list in the inode, it's assumed that each entry (other than a
possible frag at the end which is handled by ino->length) is block sized.
Compression kills that idea, you need more information.

ZFS decided that it was too hard to have compression on top of a page
cache and put back their own buffer cache.  Unforgivable in my mind
after SunOS did such a nice job of unifying everything around the page
cache, ZFS reintroduced a known coherency problem.  I'd give ZFS credit
for a lot of other stuff, but I would have flunked it in the OS course
I was teaching at Stanford.

I get to say that because in BitKeeper we implemented the compressed
(and CRCed and XORed) layer underneath mmap().  We proved that it could
be done, you needed 2 ints per block rather than 1, but there is a body
of code that shows it can be done and it works for read/write/mmap (not
on Windows, that was a shit show).  So when I talked to Bill about it
and he said it was too hard I was hugely disappointed.

These days, there doesn't seem to be anyone who cares enough about clean
OS architecture and wants to fix it.

On Sat, Nov 01, 2025 at 10:42:14AM -0400, A. P. Garcia via TUHS wrote:
> I wanted to share three brief essays I wrote on LinkedIn. I hope it's
> appropriate to share them here.
> 
> The Cathedral, the Bazaar, and the Marketplace
> 
> People sometimes say Linux suffers from a ???Not Invented Here??? problem. They
> pnt to technologies like DTrace and ZFS ??? born in Solaris, admired by
> Linux, but never fully adopted. FreeBSD, macOS, even Windows embraced
> DTrace. Linux went its own way, creating eBPF and Btrfs instead.
> 
> At first glance, it looks like stubbornness. But look closer, and you see a
> deeper truth about how different systems and their communities evolve.
> 
> The Cathedral: Solaris and the Dream of Perfection
> 
> Solaris and the BSDs were cathedral projects: elegant, coherent, and built
> to last. Their philosophy was architectural: design it perfectly once, and
> maintain it forever. That stability made masterpieces like ZFS and DTrace
> possible.
> 
> Cathedrals are slow to change. They preserve beauty, not momentum.
> 
> The Bazaar: Linux and the Art of Reinvention
> 
> 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.
> 
> This isn???t ???Not Invented Here.??? It???s ???Invented Anew, Every Time.??? It???s a
> culture that prizes autonomy over elegance, vitality over symmetry.
> 
> The Marketplace: Microsoft and the Pragmatism of Scale
> 
> Then there???s Microsoft, once the cathedral???s rival, now a marketplace of
> its own. Its genius has never been invention but absorption: taking good
> ideas from elsewhere and integrating them into something cohesive.
> 
> PowerShell drew from Unix shells and .NET reflection. NTFS inherited DNA
> from VMS. Today, Microsoft ships Linux inside Windows, Edge on Chromium,
> and hosts GitHub ??? the beating heart of open source.
> 
> Yet the uptake of Microsoft???s own open-source tools among Linux users has
> been modest. You can install PowerShell on Ubuntu or .NET on Debian, but
> few do. Not because the tools are bad, but because open source isn???t just a
> license, it???s a language.
> 
> Microsoft???s tools still speak in the idioms of Windows. They solve problems
> that feel foreign in Unix hands. You can open-source the code, but you
> can???t open-source the culture overnight.
> 
> Three Philosophies, One Ecosystem
> 
> -  Solaris / BSD: Design it perfectly, then preserve it.
> -  Linux: Rebuild it constantly, and let it evolve.
> -  Microsoft: Adopt it broadly, and make it familiar.
> 
> Each model has its genius, and its limits. Solaris gave us clarity but
> stagnated. Linux gave us chaos but endurance. Microsoft gave us cohesion,
> and at times, a touch of the blas??.
> 
> But in 2025, the walls between them have thinned. Linux runs in Azure. eBPF
> runs on Windows. Solaris???s spirit lives on in every file system that
> promises self-healing storage.
> 
> The world has evolved since ESR first told us about the Cathedral and the
> Bazaar.
> 
> 
> 
> Before the Bazaar
> The lineage of open collaboration from Bell Labs to the AI Lab to Linux.
> 
> In the early days, Unix was a community. Not a corporate product or a
> stealth research project, but a loose fellowship of programmers trading
> code through tape reels. Thompson and Ritchie gave it away for a nominal
> fee, and universities adopted it because it was small, elegant, and
> instructional. The code moved by post and by modem; ideas moved even
> faster. Every new utility carried someone???s initials in the source
> comments, a quiet signature of a gift freely given.
> 
> Meanwhile, at MIT, another tribe of hackers lived by a similar rhythm,
> though they worked on different machines. Their home was the AI Lab, and
> their world ran on PDP-10s under ITS, a timesharing system they had shaped
> to their own image. It was a place where curiosity outranked hierarchy,
> where anyone could read or patch any program, and where a clever hack was
> its own kind of currency.
> 
> For a while, both cultures thrived on openness. But while the Unix world
> diffused into hundreds of campuses and companies, the AI Lab was a more
> fragile ecosystem. When the hardware aged and the market closed in, that
> ecosystem broke. What had been an everyday freedom, editing each other???s
> code, suddenly became trespass.
> 
> The lab was dying, and everyone could feel it. The old PDP-10s hummed like
> relics, and the laughter that used to spill from the terminals had thinned
> to the occasional keystroke. A printer driver had been locked away behind a
> corporate contract; a colleague left for a company that paid him to keep
> quiet. The code that once bound the room together was vanishing into sealed
> disks and nondisclosure.
> 
> Richard Matthew Stallman stood in the middle of that silence and made a
> decision that would outlast the machines. If the lab was gone, he would
> build another. One not bound by walls or employers. One where the source
> itself would be the meeting place.
> 
> For all the talk of freedom you may have heard from rms, GNU wasn???t born
> from utopia; it was born from grief. It was his hope that a community could
> be written back into existence, line by line.
> 
> Before him, long before the Internet turned collaboration into a torrent,
> there was a room at Bell Labs Center 1127. That was the first bazaar:
> quiet, fluorescent, lined with a PDP-11 and teletype terminals. The people
> who used Unix were the same ones who built it.
> 
> When Ken Thompson or Dennis Ritchie wrote a tool, it wasn???t for customers;
> it was for the colleague one door down. Brian Kernighan would stop by with
> an idea for a text filter. Joe Ossanna needed better document formatting.
> Doug McIlroy wanted to teach the machines how to speak in little,
> composable verbs. By lunchtime, half the lab was using the new tool, and by
> evening, someone else had improved it.
> 
> The same impulse stretches now across continents instead of offices. The
> bazaar simply scaled up the Unix room: at Bell Labs, at the AI Lab at MIT,
> and now in your every git pull.
> 
> 
> 
> The Rhetoric of the Bazaar
> 
> How Eric S. Raymond sold open source as a process improvement.
> 
> When The Cathedral and the Bazaar appeared in the late 1990s, it read like
> field notes from a new frontier. Raymond seemed to be explaining why
> Linux???s sprawling, volunteer army had outpaced corporate software. But the
> essay was more than observation. It was persuasion dressed as ethnography,
> a cultural revolution disguised as engineering advice.
> 
> The narrow slogan
> 
> ???Given enough eyeballs, all bugs are shallow.???
> 
> The line became gospel. Short, clever, and apparently scientific, it
> reduced open collaboration to a form of distributed debugging. Many eyes,
> fewer bugs. Collaboration, in this light, was not a creative act but a
> safety net.
> 
> It was a perfect slogan for the audience he needed. Managers could measure
> defects. Executives could chart release velocity. You could sell that to a
> boardroom. ???Open source fixes bugs faster??? sounds like efficiency; ???open
> source changes how humans organize??? sounds like insurrection.
> 
> The trade
> 
> So Raymond made a trade. He gave up the movement???s breadth for credibility.
> The grand claim, that transparency breeds better design and deeper
> understanding, became a smaller, safer one about quality assurance. And in
> doing so, he made the revolution sound replicable.
> 
> It worked. Netscape opened its code. ???Open source??? replaced ???free
> software.??? Corporations joined the bazaar without ever entering the
> community. They adopted the method, not the meaning.
> 
> The diary as proof
> 
> Even the long detour through fetchmail fits the pattern. It reads like
> autobiography, but it???s really evidence: if this model works for me, it can
> work for you. The diary is a case study, not merely an exposition. Raymond
> wasn???t just documenting open development. He was demonstrating it.
> 
> The legacy
> 
> The quiet compromise of the essay is that by focusing on bugs instead of
> ideology, Raymond made the unfamiliar familiar. He turned rebellion into
> best practice. And in doing so, he helped open source escape the lab and
> enter the market???but also stripped it of its soul.
> 
> It split the movement. The free software camp clung to ethics; the open
> source camp to efficiency. Each accused the other of missing the point.
> 
> Perhaps both did.
> 
> The real power of the bazaar wasn???t in its license or its process. It was
> in the way it made people feel seen, the way a thousand strangers could
> build something together and call it theirs. That???s what made the terminals
> hum and the mailing lists sing.
> 
> The real birth wasn???t a method or a manifesto. It was a new community, just
> another example of what happens when people share a common need and work
> together to make it happen. And it didn???t belong to either banner. It
> belonged to everyone who showed up.

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: 3 essays on the ujnix legacy

[Clem Cole via TUHS]

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.

In all cases, there were two core drivers: 1.) control [he got to say what
was going to be there] and 2.) the economics of the time when each became
popular.

e.g., Richard Hamming's parody of Isaac Newton's famous quote: "Mathematicians
stand on each other's shoulders and computer scientists stand on each
other's toes,"  is the driver for each team; and the outcome is less driven
by design and architecture than it is by being *the most cost-effective
solution to something a user of the technology requires.*

On Sat, Nov 1, 2025 at 10:42 AM A. P. Garcia via TUHS <tuhs@tuhs.org> wrote:

> I wanted to share three brief essays I wrote on LinkedIn. I hope it's
> appropriate to share them here.
>
> The Cathedral, the Bazaar, and the Marketplace
>
> People sometimes say Linux suffers from a “Not Invented Here” problem. They
> pnt to technologies like DTrace and ZFS — born in Solaris, admired by
> Linux, but never fully adopted. FreeBSD, macOS, even Windows embraced
> DTrace. Linux went its own way, creating eBPF and Btrfs instead.
>
> At first glance, it looks like stubbornness. But look closer, and you see a
> deeper truth about how different systems and their communities evolve.
>
> The Cathedral: Solaris and the Dream of Perfection
>
> Solaris and the BSDs were cathedral projects: elegant, coherent, and built
> to last. Their philosophy was architectural: design it perfectly once, and
> maintain it forever. That stability made masterpieces like ZFS and DTrace
> possible.
>
> Cathedrals are slow to change. They preserve beauty, not momentum.
>
> The Bazaar: Linux and the Art of Reinvention
>
> 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.
>
> This isn’t “Not Invented Here.” It’s “Invented Anew, Every Time.” It’s a
> culture that prizes autonomy over elegance, vitality over symmetry.
>
> The Marketplace: Microsoft and the Pragmatism of Scale
>
> Then there’s Microsoft, once the cathedral’s rival, now a marketplace of
> its own. Its genius has never been invention but absorption: taking good
> ideas from elsewhere and integrating them into something cohesive.
>
> PowerShell drew from Unix shells and .NET reflection. NTFS inherited DNA
> from VMS. Today, Microsoft ships Linux inside Windows, Edge on Chromium,
> and hosts GitHub — the beating heart of open source.
>
> Yet the uptake of Microsoft’s own open-source tools among Linux users has
> been modest. You can install PowerShell on Ubuntu or .NET on Debian, but
> few do. Not because the tools are bad, but because open source isn’t just a
> license, it’s a language.
>
> Microsoft’s tools still speak in the idioms of Windows. They solve problems
> that feel foreign in Unix hands. You can open-source the code, but you
> can’t open-source the culture overnight.
>
> Three Philosophies, One Ecosystem
>
> -  Solaris / BSD: Design it perfectly, then preserve it.
> -  Linux: Rebuild it constantly, and let it evolve.
> -  Microsoft: Adopt it broadly, and make it familiar.
>
> Each model has its genius, and its limits. Solaris gave us clarity but
> stagnated. Linux gave us chaos but endurance. Microsoft gave us cohesion,
> and at times, a touch of the blasé.
>
> But in 2025, the walls between them have thinned. Linux runs in Azure. eBPF
> runs on Windows. Solaris’s spirit lives on in every file system that
> promises self-healing storage.
>
> The world has evolved since ESR first told us about the Cathedral and the
> Bazaar.
>
>
>
> Before the Bazaar
> The lineage of open collaboration from Bell Labs to the AI Lab to Linux.
>
> In the early days, Unix was a community. Not a corporate product or a
> stealth research project, but a loose fellowship of programmers trading
> code through tape reels. Thompson and Ritchie gave it away for a nominal
> fee, and universities adopted it because it was small, elegant, and
> instructional. The code moved by post and by modem; ideas moved even
> faster. Every new utility carried someone’s initials in the source
> comments, a quiet signature of a gift freely given.
>
> Meanwhile, at MIT, another tribe of hackers lived by a similar rhythm,
> though they worked on different machines. Their home was the AI Lab, and
> their world ran on PDP-10s under ITS, a timesharing system they had shaped
> to their own image. It was a place where curiosity outranked hierarchy,
> where anyone could read or patch any program, and where a clever hack was
> its own kind of currency.
>
> For a while, both cultures thrived on openness. But while the Unix world
> diffused into hundreds of campuses and companies, the AI Lab was a more
> fragile ecosystem. When the hardware aged and the market closed in, that
> ecosystem broke. What had been an everyday freedom, editing each other’s
> code, suddenly became trespass.
>
> The lab was dying, and everyone could feel it. The old PDP-10s hummed like
> relics, and the laughter that used to spill from the terminals had thinned
> to the occasional keystroke. A printer driver had been locked away behind a
> corporate contract; a colleague left for a company that paid him to keep
> quiet. The code that once bound the room together was vanishing into sealed
> disks and nondisclosure.
>
> Richard Matthew Stallman stood in the middle of that silence and made a
> decision that would outlast the machines. If the lab was gone, he would
> build another. One not bound by walls or employers. One where the source
> itself would be the meeting place.
>
> For all the talk of freedom you may have heard from rms, GNU wasn’t born
> from utopia; it was born from grief. It was his hope that a community could
> be written back into existence, line by line.
>
> Before him, long before the Internet turned collaboration into a torrent,
> there was a room at Bell Labs Center 1127. That was the first bazaar:
> quiet, fluorescent, lined with a PDP-11 and teletype terminals. The people
> who used Unix were the same ones who built it.
>
> When Ken Thompson or Dennis Ritchie wrote a tool, it wasn’t for customers;
> it was for the colleague one door down. Brian Kernighan would stop by with
> an idea for a text filter. Joe Ossanna needed better document formatting.
> Doug McIlroy wanted to teach the machines how to speak in little,
> composable verbs. By lunchtime, half the lab was using the new tool, and by
> evening, someone else had improved it.
>
> The same impulse stretches now across continents instead of offices. The
> bazaar simply scaled up the Unix room: at Bell Labs, at the AI Lab at MIT,
> and now in your every git pull.
>
>
>
> The Rhetoric of the Bazaar
>
> How Eric S. Raymond sold open source as a process improvement.
>
> When The Cathedral and the Bazaar appeared in the late 1990s, it read like
> field notes from a new frontier. Raymond seemed to be explaining why
> Linux’s sprawling, volunteer army had outpaced corporate software. But the
> essay was more than observation. It was persuasion dressed as ethnography,
> a cultural revolution disguised as engineering advice.
>
> The narrow slogan
>
> “Given enough eyeballs, all bugs are shallow.”
>
> The line became gospel. Short, clever, and apparently scientific, it
> reduced open collaboration to a form of distributed debugging. Many eyes,
> fewer bugs. Collaboration, in this light, was not a creative act but a
> safety net.
>
> It was a perfect slogan for the audience he needed. Managers could measure
> defects. Executives could chart release velocity. You could sell that to a
> boardroom. “Open source fixes bugs faster” sounds like efficiency; “open
> source changes how humans organize” sounds like insurrection.
>
> The trade
>
> So Raymond made a trade. He gave up the movement’s breadth for credibility.
> The grand claim, that transparency breeds better design and deeper
> understanding, became a smaller, safer one about quality assurance. And in
> doing so, he made the revolution sound replicable.
>
> It worked. Netscape opened its code. “Open source” replaced “free
> software.” Corporations joined the bazaar without ever entering the
> community. They adopted the method, not the meaning.
>
> The diary as proof
>
> Even the long detour through fetchmail fits the pattern. It reads like
> autobiography, but it’s really evidence: if this model works for me, it can
> work for you. The diary is a case study, not merely an exposition. Raymond
> wasn’t just documenting open development. He was demonstrating it.
>
> The legacy
>
> The quiet compromise of the essay is that by focusing on bugs instead of
> ideology, Raymond made the unfamiliar familiar. He turned rebellion into
> best practice. And in doing so, he helped open source escape the lab and
> enter the market—but also stripped it of its soul.
>
> It split the movement. The free software camp clung to ethics; the open
> source camp to efficiency. Each accused the other of missing the point.
>
> Perhaps both did.
>
> The real power of the bazaar wasn’t in its license or its process. It was
> in the way it made people feel seen, the way a thousand strangers could
> build something together and call it theirs. That’s what made the terminals
> hum and the mailing lists sing.
>
> The real birth wasn’t a method or a manifesto. It was a new community, just
> another example of what happens when people share a common need and work
> together to make it happen. And it didn’t belong to either banner. It
> belonged to everyone who showed up.
>

[TUHS] Re: 3 essays on the ujnix legacy

[A. P. Garcia via TUHS]

Damn, Clem. Lay down the truth. I really appreciate this perspective. It
grounds the idealism of ESR’s framing (and mine, to an extent) in the
practical realities of control and economics.


On Sat, Nov 1, 2025, 12:45 PM Clem Cole <clemc@ccc.com> 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.
>
> In all cases, there were two core drivers: 1.) control [he got to say what
> was going to be there] and 2.) the economics of the time when each became
> popular.
>
> e.g., Richard Hamming's parody of Isaac Newton's famous quote: "Mathematicians
> stand on each other's shoulders and computer scientists stand on each
> other's toes,"  is the driver for each team; and the outcome is less
> driven by design and architecture than it is by being *the
> most cost-effective solution to something a user of the technology
> requires.*
>
> On Sat, Nov 1, 2025 at 10:42 AM A. P. Garcia via TUHS <tuhs@tuhs.org>
> wrote:
>
>> I wanted to share three brief essays I wrote on LinkedIn. I hope it's
>> appropriate to share them here.
>>
>> The Cathedral, the Bazaar, and the Marketplace
>>
>> People sometimes say Linux suffers from a “Not Invented Here” problem.
>> They
>> pnt to technologies like DTrace and ZFS — born in Solaris, admired by
>> Linux, but never fully adopted. FreeBSD, macOS, even Windows embraced
>> DTrace. Linux went its own way, creating eBPF and Btrfs instead.
>>
>> At first glance, it looks like stubbornness. But look closer, and you see
>> a
>> deeper truth about how different systems and their communities evolve.
>>
>> The Cathedral: Solaris and the Dream of Perfection
>>
>> Solaris and the BSDs were cathedral projects: elegant, coherent, and built
>> to last. Their philosophy was architectural: design it perfectly once, and
>> maintain it forever. That stability made masterpieces like ZFS and DTrace
>> possible.
>>
>> Cathedrals are slow to change. They preserve beauty, not momentum.
>>
>> The Bazaar: Linux and the Art of Reinvention
>>
>> 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.
>>
>> This isn’t “Not Invented Here.” It’s “Invented Anew, Every Time.” It’s a
>> culture that prizes autonomy over elegance, vitality over symmetry.
>>
>> The Marketplace: Microsoft and the Pragmatism of Scale
>>
>> Then there’s Microsoft, once the cathedral’s rival, now a marketplace of
>> its own. Its genius has never been invention but absorption: taking good
>> ideas from elsewhere and integrating them into something cohesive.
>>
>> PowerShell drew from Unix shells and .NET reflection. NTFS inherited DNA
>> from VMS. Today, Microsoft ships Linux inside Windows, Edge on Chromium,
>> and hosts GitHub — the beating heart of open source.
>>
>> Yet the uptake of Microsoft’s own open-source tools among Linux users has
>> been modest. You can install PowerShell on Ubuntu or .NET on Debian, but
>> few do. Not because the tools are bad, but because open source isn’t just
>> a
>> license, it’s a language.
>>
>> Microsoft’s tools still speak in the idioms of Windows. They solve
>> problems
>> that feel foreign in Unix hands. You can open-source the code, but you
>> can’t open-source the culture overnight.
>>
>> Three Philosophies, One Ecosystem
>>
>> -  Solaris / BSD: Design it perfectly, then preserve it.
>> -  Linux: Rebuild it constantly, and let it evolve.
>> -  Microsoft: Adopt it broadly, and make it familiar.
>>
>> Each model has its genius, and its limits. Solaris gave us clarity but
>> stagnated. Linux gave us chaos but endurance. Microsoft gave us cohesion,
>> and at times, a touch of the blasé.
>>
>> But in 2025, the walls between them have thinned. Linux runs in Azure.
>> eBPF
>> runs on Windows. Solaris’s spirit lives on in every file system that
>> promises self-healing storage.
>>
>> The world has evolved since ESR first told us about the Cathedral and the
>> Bazaar.
>>
>>
>>
>> Before the Bazaar
>> The lineage of open collaboration from Bell Labs to the AI Lab to Linux.
>>
>> In the early days, Unix was a community. Not a corporate product or a
>> stealth research project, but a loose fellowship of programmers trading
>> code through tape reels. Thompson and Ritchie gave it away for a nominal
>> fee, and universities adopted it because it was small, elegant, and
>> instructional. The code moved by post and by modem; ideas moved even
>> faster. Every new utility carried someone’s initials in the source
>> comments, a quiet signature of a gift freely given.
>>
>> Meanwhile, at MIT, another tribe of hackers lived by a similar rhythm,
>> though they worked on different machines. Their home was the AI Lab, and
>> their world ran on PDP-10s under ITS, a timesharing system they had shaped
>> to their own image. It was a place where curiosity outranked hierarchy,
>> where anyone could read or patch any program, and where a clever hack was
>> its own kind of currency.
>>
>> For a while, both cultures thrived on openness. But while the Unix world
>> diffused into hundreds of campuses and companies, the AI Lab was a more
>> fragile ecosystem. When the hardware aged and the market closed in, that
>> ecosystem broke. What had been an everyday freedom, editing each other’s
>> code, suddenly became trespass.
>>
>> The lab was dying, and everyone could feel it. The old PDP-10s hummed like
>> relics, and the laughter that used to spill from the terminals had thinned
>> to the occasional keystroke. A printer driver had been locked away behind
>> a
>> corporate contract; a colleague left for a company that paid him to keep
>> quiet. The code that once bound the room together was vanishing into
>> sealed
>> disks and nondisclosure.
>>
>> Richard Matthew Stallman stood in the middle of that silence and made a
>> decision that would outlast the machines. If the lab was gone, he would
>> build another. One not bound by walls or employers. One where the source
>> itself would be the meeting place.
>>
>> For all the talk of freedom you may have heard from rms, GNU wasn’t born
>> from utopia; it was born from grief. It was his hope that a community
>> could
>> be written back into existence, line by line.
>>
>> Before him, long before the Internet turned collaboration into a torrent,
>> there was a room at Bell Labs Center 1127. That was the first bazaar:
>> quiet, fluorescent, lined with a PDP-11 and teletype terminals. The people
>> who used Unix were the same ones who built it.
>>
>> When Ken Thompson or Dennis Ritchie wrote a tool, it wasn’t for customers;
>> it was for the colleague one door down. Brian Kernighan would stop by with
>> an idea for a text filter. Joe Ossanna needed better document formatting.
>> Doug McIlroy wanted to teach the machines how to speak in little,
>> composable verbs. By lunchtime, half the lab was using the new tool, and
>> by
>> evening, someone else had improved it.
>>
>> The same impulse stretches now across continents instead of offices. The
>> bazaar simply scaled up the Unix room: at Bell Labs, at the AI Lab at MIT,
>> and now in your every git pull.
>>
>>
>>
>> The Rhetoric of the Bazaar
>>
>> How Eric S. Raymond sold open source as a process improvement.
>>
>> When The Cathedral and the Bazaar appeared in the late 1990s, it read like
>> field notes from a new frontier. Raymond seemed to be explaining why
>> Linux’s sprawling, volunteer army had outpaced corporate software. But the
>> essay was more than observation. It was persuasion dressed as ethnography,
>> a cultural revolution disguised as engineering advice.
>>
>> The narrow slogan
>>
>> “Given enough eyeballs, all bugs are shallow.”
>>
>> The line became gospel. Short, clever, and apparently scientific, it
>> reduced open collaboration to a form of distributed debugging. Many eyes,
>> fewer bugs. Collaboration, in this light, was not a creative act but a
>> safety net.
>>
>> It was a perfect slogan for the audience he needed. Managers could measure
>> defects. Executives could chart release velocity. You could sell that to a
>> boardroom. “Open source fixes bugs faster” sounds like efficiency; “open
>> source changes how humans organize” sounds like insurrection.
>>
>> The trade
>>
>> So Raymond made a trade. He gave up the movement’s breadth for
>> credibility.
>> The grand claim, that transparency breeds better design and deeper
>> understanding, became a smaller, safer one about quality assurance. And in
>> doing so, he made the revolution sound replicable.
>>
>> It worked. Netscape opened its code. “Open source” replaced “free
>> software.” Corporations joined the bazaar without ever entering the
>> community. They adopted the method, not the meaning.
>>
>> The diary as proof
>>
>> Even the long detour through fetchmail fits the pattern. It reads like
>> autobiography, but it’s really evidence: if this model works for me, it
>> can
>> work for you. The diary is a case study, not merely an exposition. Raymond
>> wasn’t just documenting open development. He was demonstrating it.
>>
>> The legacy
>>
>> The quiet compromise of the essay is that by focusing on bugs instead of
>> ideology, Raymond made the unfamiliar familiar. He turned rebellion into
>> best practice. And in doing so, he helped open source escape the lab and
>> enter the market—but also stripped it of its soul.
>>
>> It split the movement. The free software camp clung to ethics; the open
>> source camp to efficiency. Each accused the other of missing the point.
>>
>> Perhaps both did.
>>
>> The real power of the bazaar wasn’t in its license or its process. It was
>> in the way it made people feel seen, the way a thousand strangers could
>> build something together and call it theirs. That’s what made the
>> terminals
>> hum and the mailing lists sing.
>>
>> The real birth wasn’t a method or a manifesto. It was a new community,
>> just
>> another example of what happens when people share a common need and work
>> together to make it happen. And it didn’t belong to either banner. It
>> belonged to everyone who showed up.
>>
>

[TUHS] Re: 3 essays on the ujnix legacy

[Alan Coopersmith via TUHS]

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.

-- 
         -Alan Coopersmith-                 alan.coopersmith@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[TUHS] Re: 3 essays on the ujnix legacy

[Marc Rochkind via TUHS]

You say about Linux: "It doesn’t import technologies wholesale. It
reinvents them from first principles."

Maybe that's true of the implementation, but the design is a copy. I'd say
that about GNU also. The design is the hard part, and that's what the UNIX
invention was. Remember that even Thompson and Ritchie implemented UNIX
twice.

Regarding that statement about eyeballs and shallow bugs, I don't think
there's much evidence to support it. (Very few, if any, principles of
software development have been subjected to scientific  study, unlike, say,
medicine or civil engineering.) With open source, bugs tend to be
discovered by users, who might also be developers. It's better for bugs to
be discovered by testers.

Marc Rochkind

[TUHS] Re: 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

[TUHS] Re: 3 essays on the ujnix legacy

[Warner Losh via TUHS]

On Sat, Nov 1, 2025, 8:13 PM Theodore Tso via TUHS <tuhs@tuhs.org> wrote:

> 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.
>

Also, in large part eBPF and BPF share only three letters of their name.
Extending it meant completely redoing it in the end, with a lot of learning
by fire as the exploits came out.  But you can't deny that it's easier to
use than dtrace and has gone well beyond Dtrace could easily be used for
(it could in theory, but practicalities made it hard to be a firewall much
less a portable one).

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.
>

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.

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.
>

FreeBSD would have loved a BSD or MIT license for both of these. :).

At one point an engineer/manager at Oracle announced at a conference that
ZFS would be relicensed as GPL. He was fired a few days later. Oracle
really doesn't want to relicense.

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.
>

Indeed. I tried to get some of them interested in working on FreeBSD after
all that, but the damage was done... while they had jobs with Oracle, they
were happy to make Solaris better and did a damn fine job at it. Once it
fell apart, though, everyone was too burned out...

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.
>

Agreed. Sun had cool technology and moved a lot into open source. It was an
interesting experiment that may have had a hand in their fall from
profitability... though that whole path was rather complicated.

Warner


Cheers,
>
>                                         - Ted
>

[TUHS] Re: 3 essays on the ujnix legacy

[steve jenkin via TUHS]

Ted Tso is IMHO a definitive commentator for the Linux kernel.
I’m not qualified to comment on the kernel or its development.

ESR, RMS & the FSF haven’t addressed or publicly reimagined
the Open Source model for the modern world.

Money matters.
In the long term, all, not just the best talent, needs to be paid decent wages.

Most democracies don’t rely on Churches & Charities to provide all their Social services. 
It’s seen as a ‘Public Good’ to feed & house people when in need.

Short term unpaid volunteerism is fine - a little altruism isn’t invasive.

Open Source has turned out to be a marathon, not a sprint,
and the original simple unpaid volunteer model is failing.

Here are three gaps I think need to be urgently addressed:

 - paying wages gives large commercial players control of features

 - multiple unfunded critical projects exist with few new maintainers 

 - supply chain & other security attacks need to be countered

> On 2 Nov 2025, at 13:13, Theodore Tso via TUHS <tuhs@tuhs.org> wrote:
> 
> 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.

> <snip>
> 
> 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

——————

1. the Copyleft / GPL / LGPL were a major innovation,
   it’s allowed the Linux kernel to become what it is,
   by enabling many large commercial firms
   to pour money & ‘resources’ (people) into it,
   and to fund the Boring but Essential Bits like testing.

  Open Source isn’t a ‘Commercial Project’,
  people do what they want not directed, by definition.

  Uninteresting stuff doesn’t get done, no matter how useful
  And He Who Pays Wages decides what is done. 

   I don’t believe either ESR or RMS foresaw
   the role of commercial firms & 
   the size of the Linux code base ( 40M LoC, Feb 2025 )

	<https://www.linuxtoday.com/blog/linux-kernel-source-code-surpasses-40-million-lines-january-2025-update/>

——————

2. ESR / RMS never came up with a model to collect ‘donations’ and pay volunteers,
    immortalised in XKCD ‘Dependency’. 
    Unpaid volunteers works at very small scale, but doesn't scaled very large codebases.

	<https://xkcd.com/2347/>
	<https://imgs.xkcd.com/comics/dependency.png>

	Lists multiple examples
	<https://xkcd.wtf/2347/>

Alt-text description:
	Someday ImageMagick will finally break for good 
	and we'll have a long period of scrambling 
	as we try to reassemble civilization from the rubble.

Image text:
	A project some random person in Nebraska 
	has been thanklessly maintaining since 2003

	Google AI claims "XKCD ‘Dependency’: 25 July 2013, 1354th comic”, 
		but I can’t confirm that claim.

——————

3. OSS doesn’t have a good security model across all products,
    assumes all those random volunteers are ‘good faith’ actors.

    Supply Chain Attacks are a live threat that has to be managed / mitigated.

    Since 2013, when Mandiant published details of “APT1”,
    it’s not been theoretical that patient, skilled, well-funded Actors
    could & would target commercial organisations.

    The almost successful XZ utils attack, under a GPL,
    demonstrated that ‘bad faith’ patient & skilled actors
    are a real risk to Open Source.

	<https://en.wikipedia.org/wiki/XZ_Utils_backdoor>

Project:
	<https://tukaani.org/>

——————

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: 3 essays on the ujnix legacy

[A. P. Garcia via TUHS]

> 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.

I gave my little book report to the class. Somewhere in the room, a
throat cleared. And then Ted Tso began to speak...

What can I say? I once read a literary criticism of Conrad’s Nostromo
titled Record and Reality by Edward Said, about how the stories we
tell about events eventually diverge from how they actually happened.
I think that’s what happened here too. I told the record, and then
reality showed up.

Thank you, Ted. I stand corrected on many things.

[TUHS] Re: 3 essays on the ujnix legacy

[Arnold Robbins via TUHS]

> Open Source has turned out to be a marathon, not a sprint,
> and the original simple unpaid volunteer model is failing.

That's for sure.

>  - multiple unfunded critical projects exist with few new maintainers 

There's an XKCD cartoon about this.  Chet Ramey maintains Bash, I maintain
gawk, and there are other important/critical GNU tools with just a few
maintainers who have

- been at it for decades,

- are getting older and wouldn't mind scaling back (speaking at
  least for myself),

- are having trouble finding people willing to take over (also, speaking
  at least for myself).

I have heard similar things from the current Emacs maintainer who is
even older than I am (he's in his late 60s).

I suspect there are multiple reasons for this, but the bottom line
is that if the next generation of maintainers doesn't step up to
the plate, a lot of important tools are going to start suffering
bit-rot.

Arnold

[TUHS] Re: 3 essays on the ujnix legacy

[Warner Losh via TUHS]

On Sat, Nov 1, 2025, 11:11 PM Arnold Robbins via TUHS <tuhs@tuhs.org> wrote:

> > Open Source has turned out to be a marathon, not a sprint,
> > and the original simple unpaid volunteer model is failing.
>
> That's for sure.
>
> >  - multiple unfunded critical projects exist with few new maintainers
>
> There's an XKCD cartoon about this.  Chet Ramey maintains Bash, I maintain
> gawk, and there are other important/critical GNU tools with just a few
> maintainers who have
>
> - been at it for decades,
>
> - are getting older and wouldn't mind scaling back (speaking at
>   least for myself),
>
> - are having trouble finding people willing to take over (also, speaking
>   at least for myself).
>
> I have heard similar things from the current Emacs maintainer who is
> even older than I am (he's in his late 60s).
>
> I suspect there are multiple reasons for this, but the bottom line
> is that if the next generation of maintainers doesn't step up to
> the plate, a lot of important tools are going to start suffering
> bit-rot.
>

Yes. When we started with open source, it was a passion project. That
passion was infectious. Others caught it too. They sent patches and some
became passionate.

As things grew, more and more people got paid. Even though the passionate
folks got money or patches or both. But the money fueled development, but
people got passionate at a much lower rate so the talent pool has dried up
a bit, especially where there isn't a lot of money flowing in.

It also made it harder to build a name contributing to open source
causally. Competing with paid professionals is hard and getting noticed to
have a chance became more difficult via that route.

So the benches are shallower as people do other things with their passion
time and the reward equasion has shifted.

Imho, volunteers built the open source movement, but couldn't sustain it on
volunteerism. The money sustains it now, but the dynamic that started and
nutured it has shifted. Nothing really replaced the "we are all in this
together" aspects of the early days.

I'll totally admit this is a bit of a simplification, but tracks decently
well with my involvement with open source over the last 40 years...

Warner

Arnold
>

[TUHS] Re: 3 essays on the ujnix legacy

[Arnold Robbins via TUHS]

Warner Losh <imp@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.

> I'll totally admit this is a bit of a simplification, but tracks decently
> well with my involvement with open source over the last 40 years...

Yes, I'll agree.

Arnold

[TUHS] Re: 3 essays on the ujnix legacy

[Cameron Míċeál Tyre via TUHS]

Good morning!

I have followed this thread with great interest. The comments about unpaid volunteers and naintainers, I agree with.

My own "drop in the ocean" solution is to donate to individuals or groups that create/fork/maintain things I consider essential to my daily FOSS-centered life.

Every dollar I give, I hope and pray there are at least ten other people giving a dollar also. It's often advertised as "buy the creator a coffee" but I'm sure "buy the maintainer some server space" might often be more on the mark.

To all the creators, maintainers, everyone that keeps essential, much used projects alive, thank you.

Cameron



Sent from Proton Mail for Android.

-------- Original Message --------
On Sunday, 11/02/25 at 05:12 Arnold Robbins via TUHS <tuhs@tuhs.org> wrote:
> Open Source has turned out to be a marathon, not a sprint,
> and the original simple unpaid volunteer model is failing.

That's for sure.

>  - multiple unfunded critical projects exist with few new maintainers

There's an XKCD cartoon about this.  Chet Ramey maintains Bash, I maintain
gawk, and there are other important/critical GNU tools with just a few
maintainers who have

- been at it for decades,

- are getting older and wouldn't mind scaling back (speaking at
  least for myself),

- are having trouble finding people willing to take over (also, speaking
  at least for myself).

I have heard similar things from the current Emacs maintainer who is
even older than I am (he's in his late 60s).

I suspect there are multiple reasons for this, but the bottom line
is that if the next generation of maintainers doesn't step up to
the plate, a lot of important tools are going to start suffering
bit-rot.

Arnold

[TUHS] Re: 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@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

[TUHS] Re: 3 essays on the ujnix legacy

[Hauke Fath via TUHS]

On Sun, 02 Nov 2025 00:25:16 -0600, Arnold Robbins via TUHS wrote:
> 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.

From somebody who finds himself increasingly gravitating to awk in 
daily work the more he is getting familiar with its ins and outs -- 
thank you for your work.

<https://xkcd.com/2347/> applies, I guess.

Cheerio,
Hauke

-- 
Hauke Fath                        <hauke@Espresso.Rhein-Neckar.DE>
Linnéweg 7
64342 Seeheim-Jugenheim
Germany

[TUHS] Re: 3 essays on the ujnix legacy

[Arnold Robbins via TUHS]

Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> wrote:

> On Sun, 02 Nov 2025 00:25:16 -0600, Arnold Robbins via TUHS wrote:
> > 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.
>
> From somebody who finds himself increasingly gravitating to awk in 
> daily work the more he is getting familiar with its ins and outs -- 
> thank you for your work.

You're welcome!

> <https://xkcd.com/2347/> applies, I guess.

That's the cartoon I first mentioned. Very applicable to this discussion.

Arnold

[TUHS] Re: 3 essays on the ujnix legacy

[Steffen Nurpmeso via TUHS]

Arnold Robbins via TUHS wrote in
 <202511021551.5A2FphUD012218@freefriends.org>:
 |Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> wrote:
 |> On Sun, 02 Nov 2025 00:25:16 -0600, Arnold Robbins via TUHS wrote:
 |>> 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.
 |>
 |> From somebody who finds himself increasingly gravitating to awk in
 |> daily work the more he is getting familiar with its ins and outs --
 |> thank you for your work.

I concur; also in hindsight that you put lots of effort in "the
one, true implementation of AWK" (and, not at last, at minimum,
given your "38 years", and despite who it was who "did it", you
know, .. helping out in the "one and true" implementation).

 |You're welcome!
 |
 |> <https://xkcd.com/2347/> applies, I guess.
 |
 |That's the cartoon I first mentioned. Very applicable to this discussion.

You may find it funny that his address resides at the foot of
a hill called "Frankenstein", a magnet at a certain day for the
lots of american soldiers who were stationed here: buses as far as
could be seen.
Regarding the myriads of little modules or crates or however they
are called, of the modern Unix software world, worth mentioning
i thought.

 |Arnold
 --End of <202511021551.5A2FphUD012218@freefriends.org>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)