It occurs to me that this is rarely said out loud, but it probably should be:
The ability to fork open-source software is important, *but* the idea of "if you disagree then you can just fork it" is basically a lie. It has never worked that way and it will never work that way.
In reality you're dealing with project governance and so there are a lot of social factors (community support, motivation to 'compete' with the established name, etc.) that are critical to not having a fork wither on the vine.
And it's very difficult to pull that off, and usually requires a long history of growing resentment about the leadership of the forked project. This means a fork is rarely the best solution.
@joepie91 in my opinion, a fork isn't a solution, it's physical evidence of a project's failure to include the needs of its user base.
When a fork survives for years after, that's evidence that the missing feature or change of direction was necessary for a statistically significant number of users.
Successful forks running alongside original projects are often examples of a project lead's failure to priorize the needs of their community over their own selfish and egotistical desires.
i think good open source is very modular, so you can more easily fork only the parts you want to fork. otherwise, a fork can also mean a different philosophy or direction and both can be explored in parallel.
it might be a good thing and stuffing features for both directions into a single project wont make it good for anyone, so it dont think its always project leadership failure.
big mono repos are anti fork culture though imho
@serapath @joepie91 if a project is truly modular, it does not need to be forked in order to change components of its core functionality. As much as they are looked down upon in the Limelight right now because of the project owner's decisions, WordPress is a great example of this. You can make a WordPress website do literally anything. You can make a WordPress website into a fediverse server.
Mastodon is an excellent example of the opposite end of that Spectrum. Zero customization allowed.
@mawr @serapath Hm, I'm not sure that's entirely true, I guess it kind of depends on how you define 'fork'. For highly modular code, where a package does exactly one thing, it can make sense to fork it to fix a bug (if upstream is no longer actively maintained) or do some sort of project-specific optimization, for example.
But that's more a 'fork' in the sense of 'making a derived project', not so much in the sense of 'supplanting the original for community adoption'.
yeah, we need better infrastructure around forks and also better UX.
i think it needs to be more social.
So all forks around a project should be discoverable from the original, but to avoid spam, it should be displayed based on you networks of peers (who else you know or follow uses or bookmarked a fork - and which other projects you might use use a fork - or who you know made the fork)
...
@serapath @joepie91 If every project is single serving, then every platform is a combination of thousands of tiny projects and stability is a dream requiring labor that simply will not materialize without some kind of incentive.
That's the way the world of software development is heading. It's no dream, it's a nightmare!
@joepie91 @serapath Yeah, there are cases where that makes sense.
If your project converts excel to CSV, forks might convert open office format files as an example. Similar but outside of initial scope.
If your fork continues a dead project (youtube-dl vs yt-dlp for example), that still falls under my argument IMHO: The lead abandoned the work without naming a successor; forking is your only recourse.
One would hope the original project would at least link to the alternatives in such cases...