5 ms·

To me, having worked with OSS for multiple decades, but only ever having dipped my toe into the dev waters, the amount of forks happening seems ridiculous. (1)

To me, having worked with OSS for multiple decades, but only ever having dipped my toe into the dev waters, the amount of forks happening seems ridiculous. (1) the 'subdivision of the estates' problem that primogeniture solved for inheritance is very well and alive in OSS. If you fork a project often enough most forks will have such a thin developer base, they wither. (2) this then channels quite a bit of development into projects that will soon die, thus effectively depriving the surviving versions of dev hours. (3) it's ridiculously complicated for non-technical people to keep up with what project formed from what and which fork is the most current/secure/convenient/otherquality of the bunch. I am genuinely asking, with all this being known, why hasn't there been a bigger push towards modularity. This was the idea of Unix pipes, and i don't see why it is a bad idea 40+ years later. Have a 'Gecko' module, have an 'UI' module, have a 'telemetry' module, ..... this would allow people to build Firefox 'flavors' instead of forking everything. Everyone would contribute to the same project/ecosystem, users can discover the big project, and immediately download 'vanilla', but also get info on whatever flavors there are and in what way they differ? What is the real problem here? Edit: autocorrect-correction

Thiez 4y ago
What is the incentive for the main project to build their software this way? It would likely be a lot of work to split up the software in modules like that. They would either regularly break backwards compatibility, negating the advantages of these modules, or they would have to bind their hands forever, unable to evolve the design and module boundaries. All to support forks that probably never get merged back into the main project, so from the main project perspectives the dev time is no less wasted than before. Except that they now wasted a lot of dev time to do this thing that doesn't bring them much, if anything. This RPC stuff would likely also be slightly slower, so people would just say Firefox is slow and use Chrome.
- layer8 4y ago
  Separation of concerns and improved testability could be an incentive for such modularization.
- funcDropShadow 4y ago
  Being able to join forces with more co-developers can be an incentive ... and a burden, to be honest. But for some it situations it could be an incentive.
- omniglottal 4y ago
  The comment to which you are replying points out the obvious value of such a proposal. Your not seeing immediate value, else suggesting it is not valuable, seems to be your error. All projects benefit more from those who see value in an effort, who are willing to put in that effort, than those discouraging or subverting such effort, given their ignorance of such value.
Sunspark 4y ago
This makes me think of the problem text messengers have. Do they have one central server, or do they have a federation of independently run servers with differing software versions? If they have the latter, how do they encourage everyone to maintain a minimal standard level of compatibility? What if someone wants to introduce a great new feature? Does it take years because of the non-centralized nature and people refusing to update? What you envision about modularity in a small way has already happened with the Skia graphics api. "The library is used as of 2021 in Google Chrome, Chrome OS, Chromium OS, Mozilla Firefox, Mozilla Thunderbird, Android, Firefox OS, LibreOffice (from version 7.0), Flutter and Avalonia (from Alpha 4)."
throwaway0x7E6 4y ago
>What is the real problem here? $500M that Mozilla gets from Google every year. there's no incentive to develop a better product, only to maintain an appearance of competition. I don't know if it's a secret agreement or an implicit mutual understanding, but that's what it is. the only alternative explanation I have for Mozilla's actions in the past 8 or so years is incompetence to the degree of profound mental retardation of all decision makers there.
- hansword 4y ago
  Yeah, thank you. Not what I wanted a reminder of. Surely what I needed a reminder of.
- kaba0 4y ago
  That’s just false. The $500M is just as much worth it for Google (to prevent a huge huge lawsuit) then for Mozilla. I really don’t see why would it incentivize bad things (I would worry much much more about a browser vendor having the biggest adnetwork, but to each their own).
  - hansword 4y ago
    No one is arguing Google (Chrome) is better than Mozilla (Firefox), at least until now. Of course, living in the house of big G is much worse for privacy. But we were talking about why Mozilla is such a mess (not compared to G, but to its potential). And knowing big Daddy G is the main funding source might just make one a tiny bit suspicious. Just saying.
    - kaba0 4y ago
      I don’t know whether it is fair to call it a mess. It is a very decent browser, but so are the others. Why would someone choose Firefox over Chrome on their androids, when the latter has system level integration/sync even for completely tech illiterate people? Similar story applies to ios, where you don’t even get a true non-safari browser.
orangeoxidation 4y ago
> Have a 'Gecko' module, have an 'UI' module, have a 'telemetry' module, ..... this would allow people to build Firefox 'flavors' instead of forking everything. Everyone would contribute to the same project/ecosystem, users can discover the big project, and immediately download 'vanilla', but also get info on whatever flavors there are and in what way they differ? What is the real problem here? People are doing this. Brave and Edge are "Chrome flavors". See also https://servo.org/ https://servo.org/ or the npm and cargo ecosystems. That said interfaces are incredibly hard to get right. They take an unreasonable amount of work to make and will often end up being unsuitable or obsolete leading to a world of breakage, inefficiency and pain.
pessimizer 4y ago
> If you fork a project often enough most forks will have such a thin developer base, they wither. Spurious forks are a vector for attack. If your commercial product has FOSS competition, just encourage (finance) two or three forks of it, along the lines of any contentious issues. It's like splitting the opposition vote with fake candidates. It's not necessary for Firefox because it is a completely captured opposition, but it could be happening to other projects.

Thiez 4y ago

What is the incentive for the main project to build their software this way? It would likely be a lot of work to split up the software in modules like that. They would either regularly break backwards compatibility, negating the advantages of these modules, or they would have to bind their hands forever, unable to evolve the design and module boundaries. All to support forks that probably never get merged back into the main project, so from the main project perspectives the dev time is no less wasted than before. Except that they now wasted a lot of dev time to do this thing that doesn't bring them much, if anything. This RPC stuff would likely also be slightly slower, so people would just say Firefox is slow and use Chrome.

layer8 4y ago
Separation of concerns and improved testability could be an incentive for such modularization.
funcDropShadow 4y ago
Being able to join forces with more co-developers can be an incentive ... and a burden, to be honest. But for some it situations it could be an incentive.
omniglottal 4y ago
The comment to which you are replying points out the obvious value of such a proposal. Your not seeing immediate value, else suggesting it is not valuable, seems to be your error. All projects benefit more from those who see value in an effort, who are willing to put in that effort, than those discouraging or subverting such effort, given their ignorance of such value.

Sunspark 4y ago

This makes me think of the problem text messengers have. Do they have one central server, or do they have a federation of independently run servers with differing software versions? If they have the latter, how do they encourage everyone to maintain a minimal standard level of compatibility? What if someone wants to introduce a great new feature? Does it take years because of the non-centralized nature and people refusing to update? What you envision about modularity in a small way has already happened with the Skia graphics api. "The library is used as of 2021 in Google Chrome, Chrome OS, Chromium OS, Mozilla Firefox, Mozilla Thunderbird, Android, Firefox OS, LibreOffice (from version 7.0), Flutter and Avalonia (from Alpha 4)."

throwaway0x7E6 4y ago

>What is the real problem here? $500M that Mozilla gets from Google every year. there's no incentive to develop a better product, only to maintain an appearance of competition. I don't know if it's a secret agreement or an implicit mutual understanding, but that's what it is. the only alternative explanation I have for Mozilla's actions in the past 8 or so years is incompetence to the degree of profound mental retardation of all decision makers there.

hansword 4y ago
Yeah, thank you. Not what I wanted a reminder of. Surely what I needed a reminder of.
kaba0 4y ago
That’s just false. The $500M is just as much worth it for Google (to prevent a huge huge lawsuit) then for Mozilla. I really don’t see why would it incentivize bad things (I would worry much much more about a browser vendor having the biggest adnetwork, but to each their own).
- hansword 4y ago
  No one is arguing Google (Chrome) is better than Mozilla (Firefox), at least until now. Of course, living in the house of big G is much worse for privacy. But we were talking about why Mozilla is such a mess (not compared to G, but to its potential). And knowing big Daddy G is the main funding source might just make one a tiny bit suspicious. Just saying.
  - kaba0 4y ago
    I don’t know whether it is fair to call it a mess. It is a very decent browser, but so are the others. Why would someone choose Firefox over Chrome on their androids, when the latter has system level integration/sync even for completely tech illiterate people? Similar story applies to ios, where you don’t even get a true non-safari browser.

orangeoxidation 4y ago

> Have a 'Gecko' module, have an 'UI' module, have a 'telemetry' module, ..... this would allow people to build Firefox 'flavors' instead of forking everything. Everyone would contribute to the same project/ecosystem, users can discover the big project, and immediately download 'vanilla', but also get info on whatever flavors there are and in what way they differ? What is the real problem here? People are doing this. Brave and Edge are "Chrome flavors". See also https://servo.org/ https://servo.org/ or the npm and cargo ecosystems. That said interfaces are incredibly hard to get right. They take an unreasonable amount of work to make and will often end up being unsuitable or obsolete leading to a world of breakage, inefficiency and pain.

pessimizer 4y ago

> If you fork a project often enough most forks will have such a thin developer base, they wither. Spurious forks are a vector for attack. If your commercial product has FOSS competition, just encourage (finance) two or three forks of it, along the lines of any contentious issues. It's like splitting the opposition vote with fake candidates. It's not necessary for Firefox because it is a completely captured opposition, but it could be happening to other projects.