Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Everything that makes Firefox different would be lost, and have to be rebuilt. But let's talk about a different reason why forking Chromium to keep the features you like isn't as simple as it sounds.

Imagine upstream Chromium makes a decision like dropping Manifest V2 (hypothetically).

At first it is easy to simply not apply that patch series, and keep it enabled. But eventually things will start diverging, refactor after refactor, churn after churn. This creates merge conflicts for downstream forks, who very quickly stop being able to keep up with the firehose of changes from upstream Chrome.

Leashing yourself to a moving car driving in the wrong direction does not always get you to your destination quicker. Even if it saves you the cost of having your own car.



How is solving merge conflicts harder than developing an entire browser engine?

Plus Igalia, MS, Mozilla, Brave, Arc, Vivaldi etc could maintain a shared fork that kept stuff like Manifestv2 if they wanted.


The problem is that the difficult not only increases with time unbounded, but is on a steep curve. Eventually the manpower and resource required to keep up with upstream will eventually match and outstrip that required to develop and maintain a new engine.


Have you ever met a team that maintained a fork of a legacy codebase with more than 6 figures of code?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: