Chromium, the web browser open source project Google Chrome is based on, can be considered nowadays the reference implementation of the web platform. As such, it is the first choice when implementing the web platform in a software platform or product.
Why is it like this? In this blog post I am going to introduce the topic, and then review the different reasons why a downstream Chromium is used in different projects.
A series of blog posts
This is the first of a series of blog posts, where I am going through several aspects and challenges of maintaining a downstream project using Chromium as its upstream project.
They will be mostly based on the discussions in two events. First, on The Web Engines Hackfest 2023 break out session with same title that I chaired in A Coruña. Then, on my BlinkOn 18 talk in November 2023, at Sunnyvale.
Some definitions
Before starting the discussion of the different aspects, let’s clarify how I will use several terms.
Repository vs. project
I am going to refer to a repository as a version controlled storage of code strictly. Then, a project (specifically, a software project) is the community of people that share goals and some kind of organization, to maintain one or several software products.
So, a project may use several repositories for their goals.
In this discussion I will talk about Chromium, an open source project that targets the implementation of the web platform user agent, a web browser, for different platforms. As such, it uses a number of repositories (src, v8 and more).
Downstream and upstream
I will use the downstream and upstream terms, referred to the relationship of different software projects version control repositories.
If there is a software project repository (typically open source), and a new repository is created that contains all or part of the original repository, then:
- Upstream project will be the original repository.
- Downstream project is the new repository.
It is important to highlight that different things can happen to the downstream repository:
- This copy could be a one time event, so the downstream repository becomes an independent fork, and there may be no interest in tracking the upstream evolution. This happens often for abandoned repositories, where a different set of people start an independent project. But there could be other reasons.
- There is the intent to track the upstream repository changes. So the downstream repository evolves as the upstream repository does too, but with some specific differences maintained on top of the original repository.
Why using Chromium?
Nowadays, web platform is a solid alternative for providing contents to the users. It allows modern user interfaces, based on well known standards, and integrate well with local and remote services. The gap between native applications and web contents has been reduced, so it is a good alternative quite often.
But, when integrating web contents, product integrators need an implementation of the web platform. It is no surprise that Chromium is the most used, for a number of reasons:
- It is open source, with a license that allows to adapt it for new product needs.
- It is well maintained and up to date. Even pushing through standardization for improving it continuously.
- It is secure, both from architecture and maintenance model point of view.
- It provides integration points to tailor the implementation to ones needs.
- It supports the most popular software platforms (Windows, Android, Linux, …) for integrating new products.
- On top of the web platform itself, it provides an implementation for many of the components required to build a modern web browser.
Still, there are other good alternate choices for integrating the web, as WebKit (specially WPE for the embedded use cases), or using the system-provided web components (Android or iOS web view, …).
Though, in this blog post I will focus on the Chromium case.
Why downstreaming Chromium?
But, why do different projects need to use downstream Chromium repositories?
The main simple reason the project needs a downstream repository is adding changes that are not upstream. This can be for a variety of reasons:
- Downstream changes that are not allowed by upstream. I.e. because they will make upstream project harder to maintain, or it will not be tested often.
- Downstream changes that downstream project does not want to add to upstream.
Let’s see some examples of changes of both types.
Hardware and OS adaptation
This is when downstream adds support for a hardware target or OS that is not originally supported in upstream Chromium project.
Chromium upstream provides an abstraction layer for that purpose named Ozone, that allows to adapt it to the OS, desktop environment, and system graphics compositor. But there are other abstraction layers for media acceleration, accessibility or input methods.
The Wayland protocol adaptation started as a downstream effort, as upstream Chromium did not intend to support Wayland at that time. Eventually it evolved into an upstream official Ozone backend.
An example? LGE webOS Chromium port.
Differentiation
The previous case mostly forces to have a downstream project or repository. But there are also some cases where this is intended. There is the will to have some features in the downstream repository and not in upstream, an intended differentiation.
Why would anybody want that? Some typical examples:
- A set of features that the downstream project owners consider to make the project better in some way, and want them to be kept downstream. This can happen when a new browser is shipped, and it contains features that make the product offering different, and, in some ways, better, than upstream Chrome. That can be a different user experience, some security features, better privacy…
- Adaptation to a different product brand. Each browser or browser-based product will want to have its specific brand instead of upstream Chromium brand.
Examples of this:
- Brave browser, with completely different privacy and security choices.
- ARC browser, with an innovative user experience.
- Microsoft Edge, with tight Windows OS integration and corporate features.
Hybrid application runtimes
And one last interesting case: integrating the web platform for developing hybrid applications: those that mix parts of the user interface implemented in a native toolkit, and parts implemented using the web platform.
Though Chromium includes official support for hybrid applications for Android, with the Android Web View, other toolkits provide also web applications support, and the integration of those belong, in Chromium case, to downstream projects.
Examples?
What’s next?
In this blog post I presented different reasons why projects end up maintaining a downstream fork of Chromium.
In the next blog post I will present one of the main challenges when maintaining a downstream of Chromium: the different rebase and upgrade strategies.