Why open source projects does not fork themselves to merge their powers?

Off Topic
1

Why open source projects does not fork themselves to merge their powers?

I read this article: Servo vs Ladybird

As far as I remember ladybird has got 1 million dollar from a rich man. Like signal messenger which needs more then 50 million dollars per year for maintenance and development.

I just need your opinion why we have so many projects and they don’t merge their power? Let me give more specific examples/topics:

  • Why session and signal and simplex has really different theme on UI? I use all of them, on all platforms. If you ask me: they may have the same UI with very very simple differences. But they are so different now, I can not understand the reason. Source code of UI development has really huge maintenance especially apps which works on multiple platforms (linux,mac,android,ios etc…). One of them always have a UI bug (by the way this is why I use all of them). If they had simple differences on UI, I think they will decrease the maintenance and they will have less bug-free UI. And why they don’t? I’m really thankful those people, but I’m just curious.

  • Why mullvad and librewolf not merge their power? Or they don’t use fork themselves?

  • Why ladybird does write everything from zero? Why they don’t fork librewolf, or mullvad, of mozilla’s firefox? We all know why we don’t like mozilla. But the issues with them can be fixed via forking it. If not, then why we use open source?.. only to see the source code if they spy to us?

    But writing from zero a complete web browser? it is like writing an OS from zero. Android, ios, linux, mac, web security, JS engine, HTML engine, implementations of extension APIs (only here we have thousand of functions)… its sound crazy to me. It’s not realistic. In a long term they will need too much money for it. I don’t think this can be donated 5 - 10 - 15 years. Even if will be donated, don’t you think it would be better to fork mozilla’s firefox and solving their issues with new brand? (like the most critical issue which is “isolation”).

    To write and create a stable browsers will takes more then 4-5 years… After 4 years we will wait for a advanced settings page like “about:config” which has thousand of configs. We will not be able to use personal chrome-css files. We will wait for that feature too. Maybe after 8 years. To using only mozilla’s UI will save about 4 years.

It seems Im wrong :slight_smile: But I need your opinions. Thank you.

1 Like
2

People don’t merge projects simply because they don’t want to check and validate other people’s work.

Its like doing other house’s chores. Its their responsibility, not yours…

I do see your point in that it is wasteful of the resources of the planet. But the feeling is like… playing someone else’s saved game. On a personal level, it doesnt feel right, it doesnt feel “yours”.

1 Like
3

I think you have completely discounted the power and preference or even need for a project to be independent to develop how they want with what they want and at the rate they want.

And once the project is developed, a team of devs don’t have many people to answer to and they can leverage that power for more funding, better developments with larger teams that’s still focused.

4

Semi relevant xkcd:

image
image1000×567 48.7 KB

The best analogy I can give for all the browsers is it’s like a bunch of kids playing with legos. Billy builds a house that looks like a castle. Tommy doesn’t like castles, he likes modern architecture so he decides to build a house that’s new and modern. Tommy could use the same foundation and pieces that Billy used for his castle but it would result in a house that looks a lot like a castle so Tommy builds a completely new house. Tommy also has an easier time building his house because he doesn’t need to accommodate decisions that Billy made.

Houses = browsers
Pieces = code
Foundation = browser engine

Hopefully this helps you make sense of it.

5

That’s actually a very good question.

For that to happen, people would need to:

  • Acknowledge that they’re not always right and negotiate certain conditions.
  • Accept that others might have authority over them.
  • Work with people they don’t like or who think differently from them.

And they already experience all of this at work. Sometimes there are simply deep and insurmountable technical discrepancies, but in my opinion, this happens far less often than one might think.

In any case, the best projects are always the ones that take themselves seriously, and for that, the conditions I’ve described above are essential for great progress.

3 Likes
6

Mullvad browser is already using slightly modified Tor Browser, which is a modified Firefox. Mozilla is handling the browser development. Tor Project is handling the Mullvad browser’s fingerprint protection systems, and Mullvad is paying Tor Project from its VPN subscription fees.

But as for the development, GUIs are developed with libraries, and different projects may use very different libraries even though they might look the same. There isn’t that much overlap.

Also, the more you know about software engineering, the more you know it’s not just logic. GUI design and UX design are both artisan skills, and simply writing readable code is its own skill. Each function and class has its own interface, and since all written for the app’s specific needs, they don’t automatically work with another program, and other programmers won’t like using them just because. In fact, it’s highly likely programmers will much rather write new one from scratch, than deal with “crappy code” written by someone else.

Then there’s the security side of things. All projects try to protect against some threat model and they have their own ways of doing things, and that changes what’s under the hood, and the user interface must cater to that.

There are some reusable blocks like Signal protocol, Flutter for UI etc., but those are already used.

As for working together, small teams are agile, large teams are the opposite of that. My favorite example is OpenPGP and their v5 fingerprint standard. As SHA-1 - Wikipedia states, “SHA-1 hasn’t been considered secure since 2005”. The OpenPGP workgroup bikeshedded the algorithm choice for years. They apparently got something decided at some point since there’s apparently a --with-v5-fingerprint flag. But it doesn’t work, and there STILL isn’t a way to print your PGP key’s fingerprint in gpg. So PGP fingerprints have been weak for closer 20 years, broken since 2017 with SHAppening. Any 256-bit hash function would’ve been enough.

As an independent developer, it took me a day or two to hack my way around this issue with an installer one-liner that uses pinned BLAKE2 fingerprint.

So collaborating might help reduce workload, but the amount of coordination it requires slows it down even more.

2 Likes
8

You are asking why they don’t merge, when they can just fork.

With forking, the developers can ensure they have control of their project, accepting only commits they want while benefiting from upstream work and resource, e.g. Brave works on top of Chromium, Mullvad works on top of Firefox.

With big projects, forking will make you reliant on upstream.

When existing engines suck, building a new one will be easier than spending time getting Google/Apple/Mozilla to fix things.

They could use the same libraries like Qt, GTK underneath but they must have different UI… to differentiate from each other.

1 Like
9

I have yet to see proofs that having big unique projects will be better than many small projects in FOSS.

1 Like
10
11

On FOSS, forks can happen at a dispute of ideologies on the direction of the project. I.e., SearxNG was forked from Searx as the original maintainers were against introducing engine metrics of any kind, which massively hindered addressing issues in the project.

In these cases, I think of it as evolution, and both can exist while moving in different directions. Same reasoning for having multiple Linux distros, and derivatives of Linux distros, and so on, also apply.