@aral
I have the feeling that people miss a important aspect if they suggest forks as a solution for the current "problem". A important part of long term success is building a healthy dev community. Hundreds of one-person forks aren't sustainable and will slow down progress. Think about a world where all KDE, Gnome or Linux devs would work on their own fork instead of working together. I hardly believe that this would result in a better and more sustainable ecosystem.
@bjoern @aral Agreed, however it can also be a healthy thing if the forkers are simply at odds with upstream and cannot peacefully cooperate. There's less of a problem with forks when federation is involved and they remain compatible. Also, most of the new features of Mastodon are still being developed by a single person, I don't think the fork is going to subtract from the Mastodon technical/contributor pool significantly. Also, they can also merge back in the future, see Node.js/io.js
@MatejLach @bjoern @aral Yes, the federation is the difference here. Activitypub is the core (or the KDE/Gnome here) and Mastodon is just one possible implementation. One of the applications that makes up the KDE.
Too big fragmentation is of course bad... but I don't really see much risk of it here.
@shellkr @MatejLach @aral The protocol is only the foundation, without any value if there are no implementations. Most likely ActivityPub would be already dead without Mastodon. In order to have good implementation(s) for many years to come you need a healthy (dev) community, and as said, that's not what one-person forks with a handful of users are, imho. I'd even go as far as to say, that forks as discussed right now could kill both Mastodon and ActivityPub in the long run.
@bjoern @MatejLach @aral Yes, you could be right if Mastodon was a single dev project... but it isn't. I think the last (some of the latest) version had like 20 contributors or something like that.
The typical issue with one man forks would be if Eugen burnt out or god forbid would experienced an accident and no longer capable to continue.
The thing here is that then a fork could continue as before.. Forks makes the "project" more resilient. It also prevents some of the pit holes.
@bjoern @MatejLach @aral You have a couple of other "strong or upcoming" forks too... like Pleroma and Pixelfed.
@raucao
I think this are not good counterexamples. First (highly personal opinion) I would be surprised if most of the GNOME/KDE forks you mentioned would still exists in 10+ years as healthy and active projects. Second, non of them split up in multiple one-person projects, most devs stick to the "original", same for most users and distributions. I don't think Mastodon has a size that can handle it. When 15 of the 20 devs split up, sustainability is at risk
@aral
@bjoern @aral Regarding the examples, MATE and Cinnamon are wildly popular desktop choices! And I think it's completely irrelevant what the landscape looks like in 10 years time. Software is way too dynamic to even plan that far ahead. Not even speaking of forks being the normal modus operandi for all Linux kernel development.
@bjoern That wasn't the point at all. It seems like you missed every single actual argument I made. Linux is forked by default. It's doing exactly what you fear they shouldn't do since they existed, and they literally invented Git in order to scale up forks to 7 commits per hour.
@bjoern The point is, what you say might be bad, is what made Linux so successful in the first place.
@bjoern Same with the forked desktops, like MATE. Ubuntu's Unity died before MATE, but by your logic it would have been more sustainable.
@raucao
I didn't followed the Linux development closely. But I think Linux was never and don't is in a state where it is spread across multiple one-person forks. Most development happens in the mainline, that's where all the companies contribute, and what most (all) distributions ship and with that also most users are using. If I'm wrong I would be curious for some pointers.
@bjoern On GitHub alone, there are currently 21789 forks. And that's not counting another tens of thousands of forks not living on GitHub. You really think they all run upstream kernel?
@raucao
Well, just because someone pressed the fork button on github is not exactly what I'm talking about.
@bjoern Again, completely missing the point. Enjoy your evening. I'm out of this one.
@aral
... A fork should always be the last resort and a well thought-out decision.