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.