In fact, [I can not say I personally know this - but have read internal memos that make the claim], Intel pays for more Linux developers and now LLVM developers than any firm. What's interesting is that Intel does not really directly sell its HW product to end-users. We sell to others than use our chips to make their products. We have finally moved to the support model for the compilers (I've personally been fighting that battle for 15 years).

So back to my basic point ... while giving the *behavior* a name, the *idea *of "Open Source" is really not anything new.

The thing which Linux has managed to achieve, however, is the fact Although from a somewhat different perspective, it's also why the Linux kernel syscall interface is so unruly, right? You've got your...some number in the small dozens of common syscalls, which are already present for the most part in v6 or v7. These are the ones I, at least, think of when I think of the Unix manual, section 2. And then you've got all the other calls added in by (usually) this database vendor or that storage vendor or the other display adapter vendor to make their stuff work more efficiently. And obviously there's a tradeoff there. Elegance departs, and you've probably introduced some security risk because these syscalls are not nearly as well-exercised as the common ones, but on the other hand you have these large companies paying to work on the kernel, and you have them supporting their product on Linux systems because the system can be bent into accommodating them more easily, and it will run better there than on OSes where they don't get to introduce features that benefit their products, which further drives adoption.

*idea I do think there is something which is radically new --- which is that it's not a single company publishing all of the source code for a particular OS, whether it's System/360 or the PDP-8 Disk Operating System, or whatever.

On Thu, Jul 15, 2021 at 04:30:15PM -0400, Clem Cole wrote: I remember looking at the DECUS program catalog for the PDP-8, and I seem to recall that for the most part, individuals were sharing their programs with others. In that way, it wasn't all that different from say, CPM/UG, and HUG (Heathkit Users Group). But the thing is, for the most part, it was a single author sharing individual programs, and often changes were not accepted back. Consider the history of Bill Jolitz and 386BSD, and the collection of patches that eventuallya became NetBSD and FreeBSD, which was formed because they were frustrated that they couldn't get their patch sets back into Jolitz's code base. Technology plays a part, in that it enables the change. But it's not just about technology. There is also a very strong social component. Even when you were richly interconnected at the network level, this does not guarantee that will be willing to be richly interconnected in terms of accepting patch sets from people who you may not know across the Internet, into *your* program, for which you are the author and high priest. I don't remember the exact date, but it would have been in the early 90's, when at the time I was already contributing patches to Linux, and where ftp and e-mail and applying patches via context diffs was very much available. At that time, we were interested in getting support for MIT Project Athena's Hesiod extenstions into the BIND distributions (we had just been carrying patches against BIND for many years). In order to get those patches integrated, Paul Vixie invited me to his house in Redwood City, and so I flew from Boston to San Francisco, carrying my Linux laptop with the BIND patches, and we got the patches integrated into master BIND sources. Paul was a gracious host, and it was lovely that I got to spend some time with him. But it was interesting that my physical presence was needed, or at least highly useful, in terms of getting those patches into BIND. Requiring physical presence to get patches integrated.... doesn't scale. And so it wasn't a matter of technology, since the technology for Linus, who didn't know me from Adam in 1991, to accept patches from me implementing BSD Job Control, was certainly available when I was working with Paul to get the Hesiod changes integrated into BIND. But like with Jolitz and 386BSD, it's a mindset thing, not just technology. I also want to emphasize again, the question of business model is also something which I think is different, and *important*. It's one thing for Academics and Researchers to be willing to give changes away to anyone who wants. It's quite another for a company to give away their intellectual property in such a way that it can actually be used by their competitors, either because that's the social convention, or because it's enforced by the license. Was the practices we use today for Linux built on the traditions of comp.sources.unix, and BSD, and AT&T Research, and IBM making sources available for System/360, yadda, yadda, yadda? Of course! I'm not denying that. But at the same time, to claim that nothing is new under the Sun, and *all* of this had been done decades earlier, is also not the whole story. And to call IBM releasing System/360, when they retained control of the license, and wasn't accepting any changes back, and *darned* well would have sued anyone trying to use that code on non-IBM computers into a smoking crater, as "Open Source" can be highly misleading, because that is not what most people associate with the term "Open Source" today. And if we take a look at what AT&T Lawyers did with the Unix source code, at some point, it most *defintely* was the antithesis of "Open Source". Which would lead me to assert that Unix was never really released under what today we would call, "Open Source". Cheers, - Ted