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.
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'.
@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...
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!
yeah. agree.
in the best world we can just make things modular and offer alternative paths if something is contentious. Those all or nothing big forks are result of architecting projects, so there are only those options.
also, if it was highly, early nodejs/npm spirit style of modular, the community wouldnt need to hard split and maybe after some time, things are even more likely to merge again, because rhey dont have to drift further apart than necessary 🙂
agree 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
@mawr @joepie91 sounds to me like a very narrow definition of success for open source projects. I "successfully" maintained a fork of a piece of software for years, because I disagreed with how they handled Env variables (not) overwriting config file settings.
I kept my version up to date, rebased my changes on top of the latest releases and just ran with it.
No need for competition. I disagreed with how they handled one detail and so I forked it to modify that bit.
NB: I did discuss it with the community and most did in fact not see a need for my suggested change, which was fine by me.
@cmw @joepie91 that's perfectly fair. I should clarify that I'm not denouncing Forks as a concept. I feel that forking repositories is an exceptionally useful tool in this modern age for precisely the sort of use case you just mentioned.
Presenting forking as a solution to a widely shared Community preference (as is the case with Mastodon in many circumstances) is the sort of thing I was speaking to in my reply. Success in that area might be measured in popularity and longevity.
@cmw continuing that thought: Even so - in your example, the project maintainer could potentially provide configurable environment variables as a deliverable. You could offer a pull request to implement that as a feature, thus making it unnecessary to create a fork.
The choice of whether or not to include that feature is made by the project lead(s).
If enough of the community wants something and a project serves its community, they should have it.
If it's just for a few, that's different.
@mawr @joepie91 interesting. Isn't there specifically such a case for mastodon with glitch-soc(, if not hometown)?
I never went deep into the distinctions there, but had the impression that both are (or have been) successful (by these criteria) for a while.
On principle I agree however: Forking and maintaining said fork is not the common solution to differences. You'd more commonly see rewrites or competing implementations, like is the case with most fediverse server software, even those that start out as forks.
@joepie91 "if you disagree then you can just fork it" is a response that you'd only get from a developer to shut down genuine complaints often made by users who are themselves not developers and never will be developers.
It's a callous cop-out at best and a refusal to acknowledge and address poor design or critically missing features at worst.
@joepie91 @gsuberland
"Never" is a hard thing to say. Node.Js -> io.js -> Node.js is
a great example where this worked. As is ownCloud/Nextcloud. I would also consider MariaDB relatively successful, but there I don't know much about the backstory. @hedgedoc hard-forking from CodiMD/HackMD is also (IMO) a success story.
@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.