Was rereading this old essay <http://linuxmafia.com/faq/Licensing_and_Law/forking.html> that I
found some years ago. It’s a commentary on the status of the Free
Software movement (unfortunately referred to as “freeware” at one
point) as of late 1999, at a point when various parties (*cough*
proprietary software propagandists *cough*) were still trying to
spread FUD about how “forks” of software projects could leave them fragmented and users without a coherent support framework. He recaps
the unfortunate history of Unix, and the swallowing up of essentially
its entire market by Microsoft:

Those companies bought the right [from AT&T] to make their own
Unixes: IBM released AIX. Apple did A/UX. DEC did Ultrix[8],
OSF/1, and Digital Unix (later renamed "Compaq Unix" and now
"Compaq Tru64 Unix"). Data General did DG/UX, SGI did IRIX, HP did
HP/UX, and SCO did Xenix[9] which eventually mutated into SCO Open
Server. And we could cite others, but I'll spare you.

The point is that these were the jokers who ruined Unix. Every one
of them marketed his mutant Unix as "Unix plus" — everything the
other guys have and more. Needing to create differentiators, they
deliberately made their Unixes incompatible while giving lip
service to "standards".

For customers, this was simply a mess, and Microsoft drove right
through these guys' disunity like a Sherman tank. It is the
classic instance of forking that sticks in people's minds. Which
is why you folks are expected to assure customers that the same
won't happen to GNU/Linux. We'll return to this point later.

Among various other examples, the author tries to explain why this is
not a serious possibility with the Linux kernel, and how even the BSD
forks were not really forks, and would stay largely in sync.

Well, he was mostly right on the first of those cases, but somewhat
wrong on the second one. As to how the release of Open-Source BSD came
about:

One fine day in 1991, grad student Keith Bostic came to the BSD
lead developers, inspired by Richard M. Stallman's (remember him?)
[13] GNU Project, and suggested replacing BSD's remaining AT&T
work to create a truly free BSD. Dreading the confrontation likely
to result with AT&T, they tried to stall by assigning Bostic the
difficult part of this task, rewriting some key BSD utilities.
This backfired when he promptly did exactly that. So, they
grumbled but then completed the job[14], and tried to prevent AT&T
from noticing what they had done.

AT&T did notice[15], panicked, and sued. That, too, is a long
story best omitted. Under the stress of the lawsuit, freeware BSD
split into three camps (FreeBSD, NetBSD, and OpenBSD).[16] But
there were also several proprietary branches[17], made possible
because U.C. Berkeley's "BSD Licence" allowed creation of those:
Sun Microsystems's SunOS, Tenon Intersystems's MachTen, BSDI's BSD
OS [18], and NeXT Computer's NeXTStep OS all came out for sale
without public access to source, and were all based on the
Berkeley BSD source code.

For one thing, I thought *every* proprietary Unix was based on code
licensed from AT&T; but this is saying that SunOS and NeXTStep, among
a few others, came from BSD and owed nothing to AT&T.

A word about the three free BSD variants: All three were splinters
from a now-dead project called 386BSD. All have talked about
re-merging in order to save duplication of effort, but they now
persist as separate projects because they've specialised: FreeBSD
aims for the highest possible stability[19] on Intel x86 (IA32)
CPUs, NetBSD tries to run on as many different CPU types as
possible, and OpenBSD aims to have the tightest security possible.
In other words, the 386BSD project remains forked because there
are compelling reasons that make this a win for everyone.

Also, where possible, these three sister projects collaborate on
tough tasks — and they also collaborate with GNU/Linux
programmers. Some of the best hardware drivers in the Linux kernel
are actually BSD drivers. There's a high level of compatibility
among the three BSDs and between them and GNU/Linux: Unlike the
proprietary Unix vendors, BSD and GNU/Linux programmers have an
incentive to eliminate incompatibility and support standards.

But as we know from more recent history, the BSDs don’t cooperate that
much at all, at least not any more. As of today, they are well and
truly fragmented.

As for the AT&T lawsuit, it seems it had no legal basis at all:

At the time, the lawsuit's allegation of infringement of AT&T
source-code copyright cast a shadow over not just Berkeley's BSD
and BSDI's BSD OS, but also William and Lynne Jolitz's
free-software 386BSD project, which was a patchkit of about 180
patches based on Berkeley's "NET/2" BSD release. (In retrospect,
there is grave doubt about whether AT&T's complaint ever had
merit, on several grounds, but this was not clear at the time.
Kirk McKusick told me that defendants ultimately agreed in the
settlement that seven BSD files were encumbered by AT&T copyrights
only to let AT&T save face on what would otherwise have been a
dead loss, allowing that concession because the seven files were
dreadful spaghetti code and overdue for replacement anyway.)
Apparently in part because of the legal threat, the Jolitzes
withdrew from the project, leaving copyright questions and a
leadership vacuum on top of the project's other problems.

Anyway, there are other examples of forks that were successful versus
those that were not so successful. I don’t think the pattern the
author claims to see holds up; I think it is far more an issue of
management culture: if the original project leaders try to be too
controlling and reject useful-looking ideas, then forks will happen.
The new ideas in the forks may or may not succeed; but of course that
success (or not) is key to the success of the fork.

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)