Maintaining Chromium downstream: how can upstream help?
As I write often, maintaining a downstream of Chromium is not easy. A lot of effort falls on the shoulders of the teams embedding Chromium, or creating products on top of the upstream Chromium project.
We covered this in the previous chapters of my series of blog posts about maintaining Chromium downstreams. Now, this post is going to be a bit different.
I start with a question:
What can upstream Chromium do to help downstreams?
This very same question was discussed in the Web Engines Hackfest breakout session that originated most of these posts. In this blog post, I will share some of the most interesting answers that came up in that session.
Better componentization #
One of the ideas was to move code around more aggressively to make it easier to reuse. Specifically, refactoring to move more and more code from //chrome to //components.
Chromium has gone a long way in that direction. Each of these changes allows downstreams to directly use only the components they need, instead of working on top of //chrome. But there is still room for improvement.
Some parts of //chrome are still not refactored and could be very useful, especially for downstreams shipping a browser. Some examples:
- Tabs implementation.
- Profiles.
- Synchronization.
Improve extensibility #
In the same direction, supporting easier ways to provide alternative implementations, and add custom software components, was considered important.
Some examples:
- Making it easier to support Chrome extensions without using
//chrome, would allow implementing new browsers without bundling the Chromium UI. - Going further in the direction of what has been done with Ozone: the Chromium platform abstraction layer that helps to implement the support for a variety of OS (including Linux and X11). Similar steps could be taken at other levels to improve OS integration (system hardware encryption, accelerated video codecs, system IPC, and so on).
Downstream advocacy #
A very interesting proposal was to create the role of downstream advocates in the Chrome community.
They would act as an entry point for downstream projects wanting to interact with the Chrome community and be an official communication channel for downstreams to report their needs.
This would also increase awareness of the different ways Chromium is used by downstreams.
Today there are two channels that are somewhat similar: the Chromium Embedders mailing list and the #embedders Slack channel.
A two-way problem #
So far, three different problems raised by downstreams have been covered, and they seem like fair requests to the Chromium community.
But there is also work to do on the downstreams side.
Can downstreams contribute more of their work to upstream? Not only in code, but also in all the maintenance activities.
There is also code written for very specific downstream needs that could land upstream, as long as it does not become a burden to the common project. That means ownership and enough work bandwidth need to be in place.
Where are we now? #
There is a major change in the Chromium community: the creation of the Supporters of Chromium Based Browsers. What does it mean for embedders? Could it be a good way to channel requirements from the different downstream projects?
Two years after the Web Engines Hackfest session, we can see some improvements. But the general question is still valid:
What can upstream Chromium do to help downstreams?
The last post #
The next post in this series will be the last one. It will cover some typical problems downstream projects are facing today.