Comment by jancsika
7 years ago
> There could be an entire "shadow ecosystem" of invite-only source repos being shared among friends who are responsible for those they invite, including possibly having whole "trees" pruned if they turn out to be troublesome.
That could certainly be evidence that FLOSS projects need to do a better job of mentoring newcomers, and of combating abusive and anti-social behavior on their lists and issue trackers. That people are squirreled away on "shadow ecosystems" in sizable numbers would be a sign that FLOSS projects are failing at those tasks.
But it is not evidence that the artifacts these shadow ecosystems are producing have much value. If there are indeed a sizable number of participants there would be an example of a fork that releases binaries/tarballs of significantly higher quality than the original project.
Does anyone have such an example?
* tarball/binary available for fork
* fork is significantly improved over the original project
* FLOSS dev community for fork is invite only
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.
> I could name some arguable candidates: XFree86/x.org, mplayer/mplayer2/mpv, and xchat/HexChat.
Sorry, I left out the bullet about development being done in a private, invite-only group. That's what I'm curious about, and I don't think there are any examples of that.
No, there's no reason to do it in private. If you look around there are plenty of people who publicly fork code bases and work together independently of the original project with no drama. It could be they just want to go in a different direction, or to play, or didn't like the original group etc. They own their repo(s), get to decide who's invited in and if they even have a forum/mailing list/whatever. Been that way for decades.
That's not to say there aren't very public forks of important projects: they happen all the time. (just a few: Emacs/XEmacs, GCC/EGCS, FFmpeg/Libav, Cyanogenmod/LineageOS) If those who did the fork are right, the new project tends to supersede the original. And when there's a fork because one or more of the controlling personalities is an asshole, it tends to be public, noisy and messy. Note: the Linus/lkml thing barely moves the needle on this scale. (i.e. it's public, but there really hasn't been a lot of noise or mess to date.) Also, Linus is a complete gentleman compared to some of the situations I've read about.
There is a reason to do it in private: So you don't have to deal with the general public and the questions they might ask.
There's no requirement that projects listen to feedback or provide support, though the most successful ones generally do. There are many projects that simply ignore user and developer feedback. That's often a reason people fork.