I dunno, I've maintained a personal fork since around Chrome 100 or so. I am only targeting builds on Linux, I don't care about branding, and my patches are limited to about 300 lines total. The initial fork and figuring out the build process took probably 20 hours. After that, I've only had to spend on average around one hour per release of "engineering time" to keep my patches current. The build takes about an hour of machine time on my 5950x.
I'm not saying it's trivial by any means, but I don't think it's outside the range of a motivated hobbyist or a small startup. I don't think you really need "very capable engineers" personally. I barely know C or C++ and I haven't had too much trouble working with the codebase.
What kind of changes have you made with your patches? Did you make them yourself? I wanted to locate the code responsible for chromium's manifest v2 support so I could patch it back in once it's removed but I just couldn't get very far.
Manifest v2 is a bit tricky, because there are really three changes overlapping with each other:
- Manifest v3 site permissions changes
- Removal of protected APIs (like the blocking version of chrome.webRequest)
- Chrome Store code review changes that prohibit remotely loading sources
For now, you can either do nothing (as the rollout is not yet complete), or set the ExtensionManifestV2Availability policy to 2, which will still allow Mv2 extensions to be loaded.
>The other option is to follow their issue tracker and git history, and just revert whatever patches you don't like.
Yeah, the first thing I tried was to look at the issue tracker but as you stated they haven't rolled this out yet. So I tried to find the code myself.
Google's documentation didn't really help that much for this and seemed to be outdated in many sections. So I went and tried to do some experiments on places that seemed like they may have something to do with extension APIs.
I remember there was some build generated code that I was looking into because it related to the extension APIs but I was never able to test my guesses very well since my machine is not super fast and compiling takes so long. So eventually I threw in the towel.
I'm not saying it's trivial by any means, but I don't think it's outside the range of a motivated hobbyist or a small startup. I don't think you really need "very capable engineers" personally. I barely know C or C++ and I haven't had too much trouble working with the codebase.