It depends on how fat the fork is. While I haven’t worked on Blink, as a developer who works on other people’s very large codebases, including one from Google, I disagree. There are free tools for build automation. That’ll take care of being up-to-date with upstream in terms of security. Patching things can be done using conflict-minimizing strategies. I used to work at an Android OEM and I’ve seen it done with great success. Thinking of Blink specifically, there have been lots of forks during its WebKit days. If I remember correctly there are also thin forks of Firefox maintained by some open source developers. This is all to support thay I don’t think it’s that big of a deal. Especially if most of it is rebranding and restoring some deprecated or deleted functionality. Could be wrong. I think we’ll see, because I have a feeling the cost of maintaining a Chromium fork could be cheaper than patching apps to work well on Firefox. Some corpos might even pitch in. Not to mention that it isn’t at all obvious for how long Firefox will be developed by Mozilla. If they drop the ball at some point we’ll be faced with implementing new features in Firefox vs patching features of Chromium. ⚖️
The Debian community already maintains a Chromium fork. How much does that cost?
The human time needed should grow with the number of patches that need to be applied to the upstream code base, because some will fail now and then. This is what I refer to as “fatness” of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work. Testing is done by the users as it always has been in Debian and its derivatives. You’re referring to a few full-time developers and I simply don’t see the need. Maybe I’m missing something obvious. 😅
Add into that, I’m betting googie will actively try to make downstream forks difficult to maintain without accepting the components they want to force on everyone like manifest v3
I have no interest in giving them the benefit of any doubt, they not only haven’t earned it but actively squandered and destroyed the trust they had earned in the past.
They’ll actually have to do something to make themselves trustworthy again, and even if they do, there will always be the threat of them reverting to what they are now or worse looming over every good thing they do.
They not only became what they set out to oppose, they’ve become so much worse.
Maintaining a fork of Chromium would cost millions to do it responsibly.
It depends on how fat the fork is. While I haven’t worked on Blink, as a developer who works on other people’s very large codebases, including one from Google, I disagree. There are free tools for build automation. That’ll take care of being up-to-date with upstream in terms of security. Patching things can be done using conflict-minimizing strategies. I used to work at an Android OEM and I’ve seen it done with great success. Thinking of Blink specifically, there have been lots of forks during its WebKit days. If I remember correctly there are also thin forks of Firefox maintained by some open source developers. This is all to support thay I don’t think it’s that big of a deal. Especially if most of it is rebranding and restoring some deprecated or deleted functionality. Could be wrong. I think we’ll see, because I have a feeling the cost of maintaining a Chromium fork could be cheaper than patching apps to work well on Firefox. Some corpos might even pitch in. Not to mention that it isn’t at all obvious for how long Firefox will be developed by Mozilla. If they drop the ball at some point we’ll be faced with implementing new features in Firefox vs patching features of Chromium. ⚖️
deleted by creator
The Debian community already maintains a Chromium fork. How much does that cost?
The human time needed should grow with the number of patches that need to be applied to the upstream code base, because some will fail now and then. This is what I refer to as “fatness” of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work. Testing is done by the users as it always has been in Debian and its derivatives. You’re referring to a few full-time developers and I simply don’t see the need. Maybe I’m missing something obvious. 😅
deleted by creator
Add into that, I’m betting googie will actively try to make downstream forks difficult to maintain without accepting the components they want to force on everyone like manifest v3
deleted by creator
I have no interest in giving them the benefit of any doubt, they not only haven’t earned it but actively squandered and destroyed the trust they had earned in the past.
They’ll actually have to do something to make themselves trustworthy again, and even if they do, there will always be the threat of them reverting to what they are now or worse looming over every good thing they do.
They not only became what they set out to oppose, they’ve become so much worse.