Comment by stonogo

I could name some arguable candidates: XFree86/x.org, mplayer/mplayer2/mpv, and xchat/HexChat. In many cases the catalyst was some kind of licensing disagreement, but the reason people were drawn to the fork was the dev culture of the original project. What they have in common is the original project tends to (but does not always) wither and die, at which point the quiet fork becomes the main focus.

But to be clear, this is the normal, daily-basis operation in the name of distro packaging, too. Some distros (Slackware, e.g.) try to hew as close to upstream as possible, but others (Red Hat and Debian, e.g.) significantly modify the upstream code, and development of this private not-a-fork-just-a-set-of-massive-patches is absolutely invite-only. There are weird rituals around not calling a given distro's effective forking "a fork," but in essence that's exactly what it is. "We can't get this patch accepted upstream," they'll say, and then the fork is live. It leads to heated and sometimes inimical clashes between the upstream dev and the packaging entity (c.f. xscreensaver, firefox/iceweasel, etc).

The only difference between some of these "packaging efforts" and the article's "shadow ecosystem" is how many users they have, really.