Recent searches
Search options
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.
Soff
@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'.
@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!
