Open source browser engines run on a paradox. Their public roadmaps describe multi-year plans for rendering pipelines, layout engines, and JavaScript optimizations. But the money that keeps them alive increasingly flows through the merge queue. Sponsors, foundations, and even individual donors tend to fund what they can see merged, not what some document promises. The result is a quiet misalignment between the work that gets done and the work that gets funded.

Take Servo, for example. Servo is an experimental browser engine developed by Mozilla and later by the Linux Foundation. Its roadmap has long included ambitious goals like a fully parallel layout engine and a GPU-accelerated rendering pipeline. Yet, for years, the project's most visible output on GitHub has been a steady stream of small PRs: dependency updates, bug fixes, and incremental improvements to CSS support. When I looked at Servo's commit history in the months before the Linux Foundation took over, the merge queue was dominated by these small, reviewable changes. The big architectural pieces, like the WebRender integration, took years and required dedicated funding from Mozilla itself. That funding was not tied to the merge queue; it was tied to a strategic bet that Servo's approach would eventually pay off. The paradox is that Servo's roadmap was the reason for its existence, but the funding that kept it alive came from the merge queue's small wins.

The Tension: Funding Follows the Merge Queue, Not the Roadmap

Maintainers of projects like Chromium, Firefox's Gecko, and WebKit will tell you that their funding decisions rarely start from a roadmap. A sponsor wants to see progress, and progress in open source is measured in merged pull requests. A PR that lands is tangible. It shows up in the commit log, it ships in the next release, and it can be pointed to in a quarterly report. A roadmap item, by contrast, is just a paragraph of intent. It has no commit hash, no diff, no test results.

This dynamic is not new, but it has intensified as corporate sponsorship has become the dominant funding model for browser engines. When a company like Google or Mozilla allocates engineering time, it wants that time to produce code that lands. The merge queue becomes the de facto prioritization tool. The roadmap becomes a wish list that is revisited when someone remembers to update it.

The gap between the two is often wide. A roadmap might call for a new compositor architecture, but the merge queue is full of bug fixes and small performance tweaks. Those small changes are easier to review, easier to test, and easier to justify to a sponsor. They also happen to be the work that keeps the engine alive. But they are not the work that moves the engine forward in any structural way.

Sponsors are not irrational here. They are responding to the same information asymmetry that affects any funding decision. A merged PR is a low-risk signal. It means the code was written, reviewed, and tested. A roadmap item is a promise, and promises are cheap. The tension is that the merge queue rewards incrementalism and punishes the long, uncertain work that often matters most.

Why the Merge Queue Became the Real Budget Filter

Pull requests are the unit of measurable progress in open source. They are discrete, reviewable, and mergeable. They map cleanly to a funding cycle. A sponsor can say, "We funded 40 merged PRs this quarter," and that is a number that fits in a spreadsheet. A roadmap item does not fit in a spreadsheet. It is too vague, too dependent on interpretation, and too easy to game.

CI status and review cycles signal maintainer capacity in a way that roadmap documents cannot. When a project has a healthy merge queue, with PRs moving from open to merged in a few days, it looks active. It looks like a good place to invest. When the queue is stalled, with PRs sitting for weeks, it looks like a project in trouble. Sponsors read this as a health metric, even if the stall is caused by a deliberate focus on a long-term rewrite that will not produce merged code for months.

The result is that roadmap items without corresponding PRs stall indefinitely. I have seen this in several projects. For instance, in the WebKit project, there was a proposal to refactor the rendering tree into a more efficient structure. The design doc was written in 2019, and the initial PRs were small and merged quickly. But the core refactoring, which would have touched thousands of lines and required careful testing, sat in a branch for over a year. The maintainers were busy reviewing the steady stream of bug fixes and security patches that kept the merge queue moving. The refactoring eventually landed in a reduced form, but only after a corporate sponsor (Apple) assigned dedicated engineers to it. Without that dedicated funding, the roadmap item would have remained a design doc indefinitely.

This is not a conspiracy. It is a structural consequence of how funding works. When money is tied to visible, shippable changes, the invisible work of architecture, refactoring, and design suffers. The merge queue becomes the real budget filter, and it filters out exactly the work that is hardest to schedule and hardest to sell.

The Bus Factor: A Hidden Cost of Queue-Driven Funding

There is a hidden cost to queue-driven funding that rarely appears in budget discussions: the bus factor. The bus factor is the number of people who can be hit by a bus before a project collapses. In a queue-driven funding model, that number tends to shrink.

The reason is that the merge queue concentrates power in the hands of the reviewers. The people who review and merge PRs are the ones who control what gets funded, because they control what gets merged. In a small team, that often means one or two key maintainers. They become the bottleneck. Every PR has to pass through them, and every funding decision is effectively made by the pattern of their approvals.

This concentration is not malicious. It is just what happens when a project grows faster than its review capacity. The maintainers who have been there longest have the most context, so they are the ones who get asked to review the most complex changes. They become indispensable. The bus factor risk rises precisely because the funding model rewards the merge queue, and the merge queue depends on those few people.

Small teams juggle security and feature work in this environment. Security patches merge fast, because they are urgent and easy to justify. Architectural work waits, because it is not urgent and it is hard to justify. The result is a project that is secure in the short term but increasingly brittle in the long term. The bus factor risk is not just about losing a person. It is about losing the only person who understands the architecture well enough to do the work that the merge queue cannot fund.

The maintainer onboarding problem is directly connected to this. When the bus factor is high, onboarding new maintainers is the only way to reduce it. But onboarding takes time, and time is the one thing that queue-driven funding does not buy. A new maintainer does not produce merged PRs for months. They produce questions, mistakes, and requests for help. That is not the kind of progress a sponsor can report.

Case Study: Browser Engine Internals and the Funding Gap

Browser engine internals are a perfect case study for this funding gap. Rendering pipeline changes, for example, require long lead times. A new compositor or a reworked layout algorithm cannot be done in a single PR. It requires design, prototyping, incremental integration, and a long period of testing and tuning. During that time, the merge queue might show little or no activity from the engineers working on it. From the outside, it looks like nothing is happening.

Consider the WebRender project in Servo and Firefox. WebRender was a GPU-accelerated rendering engine that replaced the traditional CPU-based painting. It was a multi-year effort that involved a complete rewrite of how Firefox draws web pages. The initial design was done in 2013, and it took until 2017 for WebRender to be enabled by default in Firefox. During those four years, the core team produced a series of PRs, but they were often large, risky, and hard to review. Many were blocked for weeks waiting for review. The funding for WebRender came from Mozilla's strategic budget, not from the merge queue. If Mozilla had relied on the merge queue to justify the investment, WebRender would have been abandoned long before it was stable.

The merge queue favors incremental fixes over big rewrites for a simple reason: an incremental fix is a single, reviewable PR. It can be merged, tested, and shipped. A big rewrite is a series of PRs, each of which might be risky and hard to review. Sponsors see the risk and the delay, and they are less willing to fund it. They would rather fund the incremental fix that makes the page load 2% faster, because that is a win they can point to.

Engine contributors are often funded by corporate sponsors, and those sponsors have their own incentives. A company that funds a browser engine wants that engine to support its products. That means prioritizing the features that its users need, and the bugs that affect its own sites. Those needs are often incremental. They are not about reinventing the rendering pipeline. They are about making the existing one work better for a specific set of use cases.

This creates a funding gap for the architectural work that would benefit everyone but that no single sponsor can claim credit for. A faster, more robust rendering engine is a public good, but it is not a private good. No single company can point to it and say, "We funded that." So it does not get funded, or it gets funded only when a company like Apple or Google decides it is strategically necessary.

Research at Georgia Tech and other institutions has highlighted similar patterns in open source funding. Studies of maintainer behavior and sponsorship models consistently find that visible, mergeable work attracts funding, while invisible, long-term work is often neglected. The numbers vary, but the pattern is consistent. The merge queue is a powerful filter, and it is not always the right one.

The Pre-Google Web Lesson: Chaos as a Funding Driver

There is a useful historical parallel in the pre-Google web. Before Google, search was an experiment. There were dozens of search engines, each with its own quirks and limitations. The web was chaotic, and search was chaotic with it. That chaos was not a bug. It was a feature. It made incremental hacks visible. A small improvement to a search algorithm could be noticed and used, and that visibility attracted attention and eventually funding.

Take AltaVista, for example. AltaVista was one of the first search engines to allow natural language queries and had a massive index of the web. It was a product of Digital Equipment Corporation (DEC), and its development was funded by a corporate R&D budget, not by a merge queue. The engineers who built AltaVista had the freedom to experiment with ranking algorithms and indexing techniques. Some of those experiments failed, but others led to breakthroughs that made AltaVista the dominant search engine of the mid-1990s. The chaos of the early web meant that a small team could try something new and see immediately if it worked, because users would flock to a better search experience.

Modern funding rewards order, not exploration. The merge queue is a tool for imposing order on a chaotic process. It ensures that changes are reviewed, tested, and integrated in a controlled way. That is a good thing for software quality, but it has a cost. It makes it harder for experimental, exploratory work to survive. A PR that is a rough prototype is likely to be rejected. A roadmap item that is a vague idea is likely to be ignored. The chaos that allowed early web search to evolve is exactly what the merge queue is designed to eliminate.

As an analysis of GPU depreciation schedules shows, infrastructure funding often follows predictable patterns, but the creative work that drives innovation is harder to fund. The pre-Google web was a reminder that chaos can be a funding driver, because it creates opportunities for small, visible wins. The merge queue imposes order, and in doing so, it may be stifling the kind of exploration that leads to breakthroughs.

This is not an argument for abandoning the merge queue. It is an argument for recognizing the trade-off. The merge queue makes software safer and more reliable, but it also makes it more conservative. The funding model that follows the merge queue amplifies that conservatism. It is worth asking whether the web would have evolved the same way if the early search engines had been run like modern open source projects, with strict review processes and funding tied to merged PRs.

Practical Takeaways for Maintainers and Sponsors

For sponsors, the first takeaway is to fund outcomes, not just merged PRs. That means asking what the roadmap says the project needs, and then asking what it would take to get there. It means being willing to fund a design phase, a prototype, or a long-term refactor that will not produce a PR for six months. It means trusting maintainers when they say that the work is happening, even if the merge queue does not show it.

A concrete example of this is the Rust programming language. Rust is not a browser engine, but it is a critical piece of infrastructure for many open source projects, including Firefox. The Rust project has a roadmap that includes long-term goals like improving compile times and reducing memory usage. These goals are not easily broken into small PRs. They require design and experimentation. The Rust Foundation, which funds the project, has been willing to fund working groups that focus on these long-term goals, even when they do not produce a steady stream of merged PRs. This is a model that browser engine sponsors could follow.

For maintainers, the takeaway is to document the gap between the roadmap and the merge queue. If a roadmap item is stalled because it requires a big rewrite, say so explicitly. Show the sponsor the design doc, the prototype branch, and the reason why the work cannot be broken into smaller PRs. The more transparent the gap is, the easier it is to make the case for funding the work that the merge queue cannot see.

Investing in review capacity is the most direct way to reduce the bus factor. That means funding more reviewers, not just more feature developers. It means training new maintainers, even when they are not immediately productive. It means accepting that the cost of onboarding is a short-term reduction in merged PRs, but a long-term increase in resilience. The post-breach forensics article on this site shows what happens when a single point of failure is taken for granted. The same lesson applies here.

Sponsors should also use merge metrics alongside qualitative goals. A healthy merge queue is a good sign, but it is not the only sign. Look at the roadmap and ask whether the merged PRs are moving the project toward the stated goals. If they are not, the funding model is misaligned. It might be time to fund a project that is not producing many PRs but is doing the work that matters.

Finally, align funding cycles with realistic development time. A roadmap item that requires a year of work should not be funded on a quarterly basis. It should be funded as a project, with milestones that are not tied to the merge queue. That is a hard sell, because it requires trust, but it is the only way to fund the kind of work that the merge queue will never reward.

The tension between the merge queue and the roadmap is not going to disappear. It is a structural feature of open source funding. But it is not immutable. Sponsors and maintainers can choose to fund the work that is hard to see, and they can choose to value the long-term health of the project over the short-term signal of a merged PR. The choice is not easy, but it is the choice that determines whether browser engines continue to evolve or simply accumulate patches.

So, the next time you see a browser engine with a quiet merge queue, do not assume it is dying. It might be working on the things that matter most. And if you are a sponsor, consider funding the silence. Ask the maintainers what they would build if they had the resources, and then give them the resources. The merge queue will catch up, eventually.