Chromium is the technical foundation for Chrome, Edge, Brave, Vivaldi and other browsers. It is open source, which means that you can download its code to create your own browser. Exciting stuff! But some of our startup customers who did this eventually had to shut down because they failed to address the associated challenges. This article explains some of the things you should consider to save you from the same fate. It grew out of our years of experience of offering automatic update solutions to browser vendors such as Brave.
Compiling Chromium is actually very easy. Just follow the official instructions to install the necessary dependencies, check out the source code with Git, and compile. A few hours later, you will have a browser that looks like Chrome with all the Google-specific bits removed. Now you can start making changes to the code to fit the browser to your liking.
One of the first things you will probably want to do is to change the name of your browser, so it shows up on user's system as something cool like "Browser of Bliss" instead of as "Chromium". You will find that this is already hard to do. The browser name is hard-coded in many places in the millions of lines of Chromium source code. Our friends and customer Viasat are offering an alternative Chromium fork called Rebel that makes this easier. Instead of having to modify many different files to change the name, you can do it in a small number of places.
Chromium misses several key features that are present in Chrome. This is a non-exhaustive list.
Widevine is a DRM technology that sites such as Netflix use to make sure that users cannot pirate their content. The way this works is that Widevine gets loaded into the browser and checks its integrity. If this check passes, then Widevine signals to the server that the browser can be trusted. The server then serves higher-quality content than it would otherwise.
Widevine is proprietary technology and its licensing terms do not allow redistribution. It is disabled by default in Chromium, which means that (out of the box) your users cannot play DRM-protected content at the highest quality. You need to enable Widevine and find a way to distribute its binaries to your users' systems. Typically, this means installing them from Google's servers.
Chrome stores users' saved bookmarks and passwords on Google's servers. This is disabled in Chromium. If you want your users to have a similar experience, for example to share passwords between desktop and mobile, you need to set up your own server that securely handles this.
You can produce offline installers by compiling Chromium, but your users will not automatically receive new versions. Enabling automatic updates requires changes in Chromium's client code and an update server. This is our specialty. If you'd like help with this, get in touch.
Chromium is developed very actively. It receives many changes every day. Some of these are important for security. Unless you are creating a pure hobby project, you will need to regularly integrate the improvements from upstream into your fork.
Because of the large number of upstream changes, at least some of them will clash with the modifications you have made - for example for branding. One of the biggest decisions you will make when forking Chromium will revolve around how you plan to avoid or deal with merge conflicts between your changes and upstream's. A failure to address this question is what sometimes makes us see Chromium forks fail.
The typical approach for making changes to an open source project is to fork it, then merge new commits from upstream into your fork. Some of our customers do this, but it is hard and painful. The reason is that the Chromium code base and necessary changes for things such as branding are so extensive that there are too many merge conflicts. We recommend a more dynamic approach.
Instead of maintaining a fork (in Git's sense of the word), consider using automation for taking a Chromium revision and programmatically applying changes on top of it to apply your customizations. Another customer of ours, Brave do this with great success. They only use a very minimal number of patches of small sizes. The majority of their changes are in separate files that are intelligently weaved into Chromium. While still hard, this approach makes keeping up-to-date with upstream much more feasible. Vivaldi use a somewhat similar approach (source). And also Edge has specialized automatic mechanisms for making this problem more tractable.
Depending on the depth of changes you need to make, an additional approach can also be to put your customizations into browser components. These are pieces of functionality that run in the context of the browser and can be updated separately. (Note: They are not the same thing as extensions, which have far fewer capabilities.) You can pre-load the component into Chromium, or update it on-the-fly with a component update server. Here too, get in touch if you'd like our help with this.
Compiling Chromium is computationally very expensive, especially if you want to do it for multiple platforms such as Windows and macOS. Your engineers will need strong hardware, but you will also need a CI infrastructure for building the browser, running tests etc. This requires an investment, but is crucial to save your engineers' precious time.
A technology that can also save your engineers a lot of time is distributed compilation in the cloud. Chromium includes the necessary facilities for this under the names "Goma" (old) and "Remote Execution" (new). The idea is that instead of compiling code only on the engineer's machine, it gets sent to a distributed fleet of build machines that then run the build in parallel. This can speed up build times massively. While Chromium has the associated client-side code, the server implementation is not available. The only company that offers this as a service, and which most major browser vendors other than Microsoft and Google use is EngFlow.
It obviously depends on the number of customizations your browser has, and on how quickly you want to incorporate security fixes from upstream. Chromium is one of the world's most complex pieces of software, and you need very capable engineers and powerful hardware to match this. It is going to be expensive. And not just once, but also on an ongoing basis.
We covered some of the challenges that come with forking Chromium. The most important question to answer is how to make changes in such a way that minimizes conflicts with future upstream versions. While creating your own browser with Chromium is extremely rewarding, it also comes with big technical challenges and associated costs. Finding solutions that achieve your desired use cases while being technically and financially sustainable will be crucial in determining your project's success.
If you liked this article and would like to chat more about Chromium, get in touch. We will be happy to help.