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.
(
) @serapath@mastodon.gamedev.placeagree somewhat 
i still think it needs a fork ofnthe specific module/component you want to remove or change and it needs a change of all upstream dependencies to use the changed/removed component.
But the good thing is, maintainance is trivial, because ideally all the rest is still re-usable, so a small devteam or even single dev can actually maintain it.
@serapath @joepie91 If the platform is made modular enough that those changes can be made without modifying the original source, the modification itself can be managed by a single dev without the need of a team, or managing an entire fork of a project to ensure compatibility with every release.
Further, that customization can be released as its own project which can then be added to other projects using the original project fork without requiring a fucking computer science degree